Hey Guys, (Brett - Could you please have a look at this as well - I've summarized issues we've been discussing, and Maven might have solved these very intelligently allready, or could be working to solve them - I think the Main one that we need help on is the duplicate jars issue).
First I think we should all agree on a general set of rules/process for creating maven builds so that everyone follows the same conventions. That way we all know what to expect. I think these were the core concerns: A) External API Breaks Library dependencies with a specific version change. So even though we think we are using the same library, someone updated it, without updating the version correspondingly. B) External Plugin Breakage Same as A but for plugins C) Duplicate jars in the build We end up with duplicate jars because sub project builds include the same jars in the build as the parent project, or other sub projects. D) Newer Versions of Plugins are downloaded by Maven and used F) Java File Encoding Issues - I think Emmanuel mentioned something about Java File on Windows vs. UNIX encoding...(I'm leaving this one to the experts...) I'll go ahead propose a process/solutions and we can refine/expand it as we go along. A) External API Breakage - Store a checksum for critical libraries (Emmanuel suggested I think) - A maven plugin could be written that does this - so it would be part of the projects reporting - Thus when someone builds the project - the checksums become part of the build... - Build thorough tests - So if an external API breaks the build, our tests tell us precisely where - Build a maven repository specific to ADS releases. So anyone who wants to build ADS, can just point maven to this repository and they can be certain that they are getting the correct dependencies. B) External Plugin Breakage - Same as A mostly. C) Duplicate jars in the build - It would be really sweet if Maven had some additional intelligence here. Something that analyzed the POMs and rewrote them automatically so that jars would not be duplicated. That way we would not have to examine external dependencies manually - at least not so much in the future. D) Newer plugins downloaded and used. We need to specify the plugin version we are using per build. This goes in the pom attribute project > build > plugins > plugin > version Here's some more comments about C) Dupliate jars in the build: - The master ADS build should specify the dependencies that should be included in the build. Thus this is the only project that specifies jars to include in the build. All the other projects should have the dependency scope set so that jars are not included (I have to run tests to make sure my assumptions are correct here - but I think these are "system", "test", and "provided" - For NOT including dependencies - so we would probably be using "test" and "provided" most of the time here.). So the set of jars to be included are the the jars that the ADS project builds and a mutually exclusive set of external dependencies. - So we need to make sure the set of external dependencies POMs are correct and use the same process we do, otherwise the external dependencies will result in duplicate jars. Cheers, - Ole --- Ole Ersoy <[EMAIL PROTECTED]> wrote: > Guys, > > I double checked the maven dependency scope values > again. I was wrong on the compile scope for maven. > Compile scope will result in the dependency being > included, so it looks like the OSGi plugin and maven > plugin do the same thing here. > > Here's the guide in case anyone wants a quick look: > http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html > > Based on this I would say that runtime, test, and > system for dependency scope result in the jar NOT > being included. However I need to validate this. > > Cheers, > - Ole > --- "John E. Conlon" <[EMAIL PROTECTED]> wrote: > > > On Sun, 2006-07-30 at 19:29 +0200, Emmanuel > Lecharny > > wrote: > > > Ole Ersoy a écrit : > > > > > > >Let me see if I get this on a more general > level. > > > > > > > >We have multiple projects. > > > > > > > >Each project has dependencies. > > > > > > > >When those projects are built, the dependencies > > > > >are included with the build. > > For the standard maven project the dependencies > > affect the classpath > > used for the various build tasks - compile, > > test-compile & execution, > > execution, etc. For details see: > > > http://maven.apache.org/guides/introduction/introduction-to-dependency- > > mechanism.html > > > > > > BUT... the scope element is handled differently > with > > OSGi projects using > > the OSGi maven plugin: > > > http://docs.safehaus.org/display/OSGI/OSGi+Plugin+for+Maven+2.0 > > > > "The OSGi maven plugin uses the Maven2 <scope/> > > dependency attribute in > > order to analyze which dependent JARs need to be > > embedded in the > > generated OSGi bundle. Maven2 dependencies > specified > > in the project's > > POM that have the scope of provided or test will > not > > be embedded in the > > OSGi bundle archive. Maven 2 dependencies that > have > > scope of compile or > > runtime will be embedded in the OSGi bundle > archive. > > Maven 2 > > dependencies have a default scope of compile when > > not explicitly > > specified in the POM." > > > > > > > > > >So when we combine all these projects we have > > > >duplicated dependencies on the classpath or at > > least > > > >duplicate dependency jars in the main build. > > (only in the case of OSGi) > > > ..because > > > >each sub project has overlapping dependencies. > > > > > > > >If my understanding is correct, then we should > > be > > > >able to resolve this by setting the dependency > > scope > > > >attribute to "compile" on the subprojects, and > > > >list all the dependencies in the main ADS pom, > > with > > > >scope set to "runtime". > > > > > > > >Cheers, > > > >- Ole > > > > > > > > > > > There is something I don't get. Let me clarify : > > > > > > if we have a parent project and N sub-project, > > which all use a common > > > dependency (let say commons-collection, or, in > our > > cas, ldap-shared), > > > then this dependency is to be declared and use > at > > compile time *and* at > > > runtime. > > If it is the default scope 'compile', then the dep > > is available on all > > the build tasks classpaths. > > > So it could be only declared in the parent > > project, all the > > > sub-project will inherit from their common > parent. > > Yes. > > > > > > It's not exactly the same thing with some other > > kind of dependency like > > > junit, which will be usefull *only* when > compiling > > the project. > > If junit is set to scope 'test', then it will be > > available on the > > classpaths at test-compiling and executing tasks > of > > the project no > > others. (And it will not be included in an OSGi > > bundle.) > > > > > > > > In our case, I don't think that shared-ldap > > dependency can be used only > > > with a compile scope (unless you just want to > test > > the compilation, > > > because without this jar, trust me, the server > > will simply fail very fast :) > > Setting to compile will make it available on all > the > > classpaths. > > > > > > There should be some other problem, I think. > > Sadly, I'm not very aware > > > of all those OSGI stuff, so I can't help a lot, > > but I don't think that > > > maven iytself is the problem. It seems to be > much > > more a problem of > > > project structure, IMHO. > > Right again. > > > > So... > > > > Lets move the OSGi directory up one level to a > > sub-directory of > > trunks/. > > > > No other projects will detect the difference. > > > > As for changing the root pom.xml as proposed in a > > previous email to: > > <modules> > > <module>mina</module> > > <module>apacheds</module> > > <module>shared</module> > > <module>osgi</module> <!--new--> > > <module>daemon</module> > > </modules> > > > > Let's hold off and add that line to modules at a > > future date - when the > > OSGi projects stabilize. > > > > cheers, > > John > > > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam > protection around > http://mail.yahoo.com > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
