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 Fri, 05 Oct 2007 11:20:29 GMT
The poms are only needed for our "internal" website management and our
official build system for jSieve (ant) does not need them at all.

Removing only the pom while leaving the jar in place has the side effect
(when building offline) to deploy to the local repository a "maven
built" pom with only artifactId/groupId and no depenency to be able to
build (this is why I started adding the poms to our stages)

So the options we have are:

1) remove the poms and leave the jars: if the mvn command is run
"online" it will download the "right" poms from central and use the jars
from the stage folder. If we run offline we put "bad" poms in the local

2) remove the poms and move the jars somewhere else (a folder different
from groupId\jars\artifactId-version.jar) so that mvn will not find that
jars and will not build at all if not online (so we never corrupt the
local repository with "maven creates" poms.

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

If maven was our main build system I would probably "vote" for #2, but
being it used only for internal purposes (our website and my continuous
builds) so I prefer #3, but this is not a strong position, so feel free
to do what you think is better.

I think it worth understanding well the 3 different solutions because
we'll have to take a decision also for every of our other products.

Thank you for taking care of this and sorry if I've not been diligent
enough when I committed the poms (they are so small descriptors that I
never thought that they may be licensed under different terms, or simply
follow different clauses, from their associated jars). I will do it
right the next time!


Robert Burrell Donkin ha scritto:
> On 9/30/07, Stefano Bagnara <apache@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On 9/30/07, Stefano Bagnara <apache@bago.org> wrote:
> <snip>
>>> an alternative would be create our own pom's. the critical meta-data
>>> (dependencies) is probably not copyrightable. see
>>> http://www.softwarefreedom.org/resources/2007/originality-requirements.html.
>>> this probably needs raising on legal-discuss.
>>> - robert
>> If we choose this way then we probably should use also a different
>> groupId/artifactId because of the way maven works. Otherwise if our poms
>> declare different dependencies or have any other difference maven will
>> behave differently depending on random events (the artifacts are
>> permanently installed in the local repository, first win.. once they
>> have been installed by us they will be taken for "good" also from other
>> projects that probably will instead work with the "original" pom)
> we have
> category A - contains AL2.0 license header:
>  * james
>  * maven-skin
>  * excaliber
>  * avalon
> category B - derived from AL2.0'd source:
>  * commons beanutils
>  * commons logging
>  * commons digester
>  * log4j
> category C - minimal, no license:
>  * oro
>  * junit
>  * activation
> category D - full, probably copyright sun:
>  * mail
> A are no problem
> for B, i think that the best policy would be to use to originals
> (rather than the transformed copeis). the differences are likely to be
> minimal and IHMO the minimal chance of difference between online and
> offline builds is worth the risk
> for C, these contain so little information that we can safely create
> original works without a risk of difference between online and offline
> builds.
> for D, i think that we should approach sun for license clarification.
> in the meantime, we remove the pom and add a readme asking people to
> download it.
> opinions?
> - robert

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

View raw message