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 :
[EMAIL PROTECTED] optimization-trunks]$ svn pg svn:externals
apacheds
https://svn.apache.org/repos/asf/directory/branches/apacheds/optimization
daemon -r412564
https://svn.apache.org/repos/asf/directory/releases/daemon/1.0-RC2
shared
https://svn.apache.org/repos/asf/directory/branches/shared/optimization
mina -r412559
https://svn.apache.org/repos/asf/directory/releases/mina/0.9.4
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/0.9.5.1/shared-asn1-0.9.5.1.jar"/>
but the current project shared-ldap pom.xml contains :
<version>0.9.5.2-SNAPSHOT</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[0.9.5.1]
apacheds[1.0-RC4-SNAPSHOT] -> mina-asn1[0.9.4] -> shared-asn1[0.9.5.1]
apacheds[1.0-RC4-SNAPSHOT] -> shared-asn1[0.9.5.2-SNAPSHOT]
Sooooooo jeeze this is bad ...
apacheds[1.0-RC4-SNAPSHOT] ->
shared-asn1[0.9.5.2-SNAPSHOT] ... directly
shared-asn1[0.9.5.1] ... 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 [0.9.5.2-SNAPSHOT] 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
belong?
Perhaps it belongs not in shared but in MINA. I'll leave this for
another thread.
Alex
