james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <robertburrelldon...@gmail.com>
Subject Re: [JSieve] pom's in stage
Date Mon, 08 Oct 2007 17:08:46 GMT
On 10/8/07, Stefano Bagnara <apache@bago.org> wrote:
> 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:
> org.apache.james:james:jar:2.3.1
> org.apache.james:mailet:jar:2.3
> org.apache.james:mailet-api:jar:2.3
>
> 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
> files.
>
> 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.

maven is used to build the documentation

> 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.
>
> opinions?

#3 introduces bad meta-data into the maven repository

what would maven do if we just removed all the pom's from the local repository?

- robert

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


Mime
View raw message