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 repository. 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 central. 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! Stefano Robert Burrell Donkin ha scritto: > On 9/30/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote: >> Robert Burrell Donkin ha scritto: >>> On 9/30/07, Stefano Bagnara <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
