directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: WARNING (II)
Date Sun, 09 Jul 2006 14:41:57 GMT
Emmanuel Lecharny wrote:
> Hi band again,
> there is a huge problem in branch/apacheds/optimization-trunks.
> The svn:externals property are set to a wrong version of mina :
> [elecharny@localhost optimization-trunks]$ svn pg svn:externals
> apacheds 
> daemon -r412564 
> shared 
> mina -r412559 

FYI I just started using http instead of https on mina and daemon 
release tag externals to prevent accidental commits to them.

> MINA-0.9.4  can't compile with shared trunk.

Oh?  Have we made changes to shared-asn1 which break the ability to 
compile MINA (namely the mina-asn1 modile) ?  I'm not seeing this :(.

> We have to fix this if we want to be able to merge the branch into the 
> trunk...

Yeah I just have to figure out how to reproduce this.

> Another point : it could be a very good idea to commit .classpath to 
> link projects between them, instead of depending on jars in the repo. So 
> far, as we have .classpath built by maven, each project point to a jar 
> in the repo, not to another project. So you may run the server without 
> using the piece of code you have just modified, because the jar that you 
> created by mvn install was not the one pointed in another .classpath.

Yeah we just spoke about this on IM but for the rest of you guys.

I'm very against committing compilation byproducts or stuff that is 
specific to a particular IDE into the svn repository.  It's against my 
religion :).  I don't want to clutter up SVN with this stuff or start 
becoming dependent on a particular IDE for a project.

> For instance, in optimization-trunks, the .classpath contains :
> <classpathentry kind="var" 
> path="M2_REPO/org/apache/directory/shared/shared-asn1/"/>

> but the current project shared-ldap pom.xml contains :
> <version></version>

That only means you have to update the project dependencies in the poms 
then rerun mvn eclipse:eclipse again.  After a release changes to the 
repo should force us to start using the next snapshot.  We must make 
sure the dependent projects move their dep versions to the snapshot or 
we'll be out of synch.

I'm guilty for this.  I have several times switched to using a snapshot 
like in shared but forgot to bump up apacheds poms which depend on 
shared modules to the latest snapshots.  I've got to start paying as 
much attention to this as when I do releases.

> So whatever modification you do in shared-ldap, even related to MINA 
> filter-codec-asn1 project, won't be used when you will test MINA. You 
> can mvn install shared-ldap how often you want, MINA will still use an 
> old jar ...
> And this is not Maven fault :)

Ahhhhhhhhhh I get it now.  Ok this was a problem I reported too a while 
back.  Legend: -> where left depends on right ...

mina-asn1[0.9.4] -> shared-asn1[]
apacheds[1.0-RC4-SNAPSHOT] -> mina-asn1[0.9.4] -> shared-asn1[]
apacheds[1.0-RC4-SNAPSHOT] -> shared-asn1[]

Sooooooo jeeze this is bad ...

apacheds[1.0-RC4-SNAPSHOT] ->
	shared-asn1[] ... directly
         shared-asn1[]          ... transitively

Depending on your classpath string (the order of jars/paths), you'll get 
a different set of classes for shared-asn1.

Bad, bad, bad ...

Pointing apacheds over to MINA trunk [0.9.5-SNAPSHOT] and bumping up 
mina-asn1's dep on shared-asn1 to [] will fix this problem.

Thanks for catching this problem E.  I'll fix things right away. 
However this reveals another problem.  Where does the generic ASN.1 code 

Perhaps it belongs not in shared but in MINA.  I'll leave this for 
another thread.


View raw message