Mailing-List: contact dev-help@stanbol.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stanbol.apache.org
Received-SPF: pass (nike.apache.org: domain of rupert.westenthaler@gmail.com
 designates 209.85.223.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAFvE7K5DR1Kt3aU7aW2s2BGV5NPYsovwJXkr+6kDSxfZcazEBw@mail.gmail.com>
References: 
 <CA+_sZ+gWSo9357ThbGzKx4=k5sZEdaZ5E_qhbNReGwLcR+gJuw@mail.gmail.com>
	<CAFvE7K5DR1Kt3aU7aW2s2BGV5NPYsovwJXkr+6kDSxfZcazEBw@mail.gmail.com>
Date: Fri, 9 Nov 2012 08:44:49 +0100
Message-ID: 
 <CAA7LAO1yWC9_ODJVUHiMvQnsbEVBd7rAj_paPnEA1z0SqG+=3w@mail.gmail.com>
Subject: Re: Enhancer engine deps problem for releases
From: Rupert Westenthaler <rupert.westenthaler@gmail.com>
To: dev@stanbol.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Fabian,

do you think that would also mean to change the package
structure/module names of those engine or do you think it is OK for
any EnhancementEngine that is managed by the Stanbol Community to use
"org.apache.stanbol.enhancer.engine.{engine-name}" as artifactId and
package name.

Regardless of that +1 from my side.

best
Rupert


On Thu, Nov 8, 2012 at 11:37 AM, Olivier Grisel
<olivier.grisel@ensta.org> wrote:
> Sounds reasonable to me. +1 for refactorings that improve the release
> flow and lower the maintenance burden.
>
> 2012/11/8 Fabian Christ <christ.fabian@googlemail.com>:
>> Hi,
>>
>> I am investigating the current SNAPSHOT deps of the Stanbol components i=
n
>> order to find out what can be released and in which order.
>>
>> In the enhancer we have the problematic situation that we have enhanceme=
nt
>> engines that rely on other components, like the refactor engine that rel=
ies
>> on rules.
>>
>> This is problematic to cut an Enhancer release because we would need to
>> release, e.g. the rules component first.
>>
>> I would like to prevent such situations. IMO it would be a more natural =
fit
>> if engines, that rely on a certain component, are removed from the Enhan=
cer
>> source tree and moved to the source tree of that particular component or
>> even to a third place.
>>
>> The Engines included in the enhancer/engines directory should only be
>> engines that do not have such dependencies. If this is the case, releasi=
ng
>> the enhancer with all independent engines raises no problems anymore.
>>
>> My proposal would be to create a new top level folder in the source tree
>> for engines that rely on the availability of other components. We could
>> call it "enhancer-thirdparty-engines". This could also be a place for
>> contributed engines that we do not want to be in the default
>> enhancer/engines structure. Such engines will be released independently =
and
>> are not part of an Enhancer release anymore.
>>
>> WDYT?
>>
>> --
>> Fabian
>> http://twitter.com/fctwitt
>
>
>
> --
> Olivier
> http://twitter.com/ogrisel - http://github.com/ogrisel


--=20
| Rupert Westenthaler             rupert.westenthaler@gmail.com
| Bodenlehenstra=C3=9Fe 11                             ++43-699-11108907
| A-5500 Bischofshofen