james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [JSieve] pom's in stage
Date Mon, 08 Oct 2007 07:55:33 GMT
Robert Burrell Donkin ha scritto:
> On 10/5/07, Stefano Bagnara <apache@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On 10/5/07, Stefano Bagnara <apache@bago.org> wrote:
>>>> Stefano Bagnara ha scritto:
>>>>> So the options we have are:
>>>> 4) Another option is to simply remove the poms and to not declare the
>>>> local stage folder as a maven repository in the main pom.xml.
>>>> This way our internal "maven based" procedures will need to be online,
>>>> but everything else is ok.
>>>> I refactored the lib folder to "stage" structure some weeks ago to have
>>>> a self contained build for maven and to have a common structure in our
>>>> product source folders and I saw no drawbacks at that time but having
>>>> found this "licensing" issue with poms we could even evaluate reverting
>>>> it (even if I still prefer #4 and #3 to #1, #2 or revert to lib folder).
>>> this sounds good to me
>> The revert to lib or the #4 option?
> #4
> comment out the local stage folder and add notes to BUILDING to
> explain that offline users can download poms and uncomment the line
> - robert

I was about applying #4 but I found another problem I didn't think
about, previously.
jsieve depends on some artifacts never deployed to a public repository, e.g:

So removing the local stage repository will make it fail because at
least this artifacts cannot be found.

Either we take care of deploying this jars to ASF maven repository
first, or we remove option #4 from the solutions.

Please note that the specified jars are part of previous Apache JAMES
Server releases but have never been prepared for a jar only
distribution, so I guess we cannot simply put them in the public
repository "as is" because they do not even contains LICENSE and NOTICE

If this is true and we don't want to work with releasing james-server
jars to maven then the only way to ship with #4 is to simply remove the
local stage folder and make it fail unless one downloads the missing
poms. This would be unacceptable if maven was the main build system, but
our users will probably never need maven for jsieve, so this will only
be used by us.

The alternative is still the #3 from the original post:
> 3) change the dependencies groupdIds/artifactIds for the "problematic"
> artifacts and move them to the new folders. Alter the pom to declare
> this new dependencies. E.g: move javax.mail/jars/mail-1.4.jar to
> org.apache.james.dep/jars/mail-1.4.jar or something similar. Even if we
> don't put there the poms mvn will work creating a "standard" pom with no
> dependencies and will deploy to the local repository our own "artifacts"
> without clashing with official poms/artifacts from central. This is make
> the offline build to work without placing bad stuff in the local
> repository but we will declare dependencies on artifacts not existing on
> central.



To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message