On 10/8/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: > > On 10/5/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > >> Robert Burrell Donkin ha scritto: > >>> On 10/5/07, Stefano Bagnara <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
