directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <ole_er...@yahoo.com>
Subject Re: ApacheDS Maven POM and inherited dependencies
Date Mon, 31 Jul 2006 00:09:22 GMT
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" <jconlon@verticon.com> 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 

Mime
View raw message