Emmanuel Lecharny wrote:
We could flatten the entire svn layout and put common deps like nlog in
a parent POM and multiproject it. I'm only half kidding. We could
probably flatten in a couple places and gain most of the benefit.
Hmmm... Seems to be a good idea. Plus the fact that it could help the
integration in Eclipse ;)
We should do it for some very common jars like :
- nlog4j
- junit
- commons-lang
I'm all for totally flattening it, as this is the best practice for
OSGi, as evidenced by the repos for Eclipse and Knopflerfish and
discussions in the last two weeks on Eclipse Equinox and Apache Felix
mailing lists. But, I was expecting push-back, so I was more thinking
of just cleaning up by maven groupId, resulting in 5-6 multiproject'ed
groups. For example, protocol providers all have the deps:
- nlog4j
- junit
- mina
So, really this just affects protocols, shared, and maybe standalone.
This applies best for the OSGi bundles since they have the most deps:
- ldap-common (org.apache.ldap.common.filter.ExprNode)
- apacheds-core (org.apache.ldap.server.configuration.Configuration)
- antlr (antlr.TokenStreamException)
- nlog4j
- junit
- osgi-framework
- osgi-service
- osgi-util
- servicebinder
- maven-osgi-plugin
Those first 3 we can probably remove someday. They occur due to bad
encapsulation, but that's another thread (I made a quick note of the
offending class).
Enrique
Those libraries count for 30% of all the dependencies of all ApacgeDS
projects
Just yesterday I put the nlog4j dependency in the parent POM of the OSGi
bundles in standalone, which has a flat structure, and removed the
dependency from any child POMs. So that reduces by about 10 the number
of instances. You may need to 'svn up' to see a reduction in the "quite
a few places within standalone" that you mention.
Enrique
---------------------------------------------------------------------------------------
Wanadoo vous informe que cet e-mail a ete controle par l'anti-virus mail.
Aucun virus connu a ce jour par nos services n'a ete detecte.
