directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John E. Conlon" <jcon...@verticon.com>
Subject Re: ApacheDS Maven POM and inherited dependencies
Date Sun, 30 Jul 2006 20:19:52 GMT
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


Mime
View raw message