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 16:14:28 GMT
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 <ole_ersoy@yahoo.com> 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" <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 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Mime
View raw message