You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Nick Faiz <ni...@gmail.com> on 2005/09/06 13:33:47 UTC
upgrade nlog4j
Hi,
Could someone please look over DIREVE242 to think about upgrading nlog4j?
http://issues.apache.org/jira/browse/DIREVE-242
Hopefully it will get rid of the NoSuchMethodError I was seeing a few weeks ago.
Cheers,
Nick
Re: upgrade nlog4j
Posted by Nick Faiz <ni...@atlassian.com>.
Ok then, I'll write it.
>
> I agree as far as I don't have to write it... Jelly is not my cup of
> tea ;)
Really, once you learn a couple of tricks in Jelly you can find a way
to do most things. :) I
I'll add a preGoal to jar:jar which will warn, very loudly, if
different versions of the same jar are listed as dependencies in the
various project.xml files lying around.
I can't see any other solution although I dont think this is
particularly elegant.
I'll send something through to this list when it's running. If anyone
has a better solution please let me know.
Cheers,
Nick
On 07/09/2005, at 12:03 AM, Emmanuel Lecharny wrote:
>> Do you agree with a maven goal that will scan the project structure
>> for dependency clashes? Any alternative ideas for controlling version
>> havoc?
>>
>
> I agree as far as I don't have to write it... Jelly is not my cup of
> tea ;)
>
> Emmanuel
>
>
Re: upgrade nlog4j
Posted by Emmanuel Lecharny <el...@gmail.com>.
> Do you agree with a maven goal that will scan the project structure
> for dependency clashes? Any alternative ideas for controlling version
> havoc?
I agree as far as I don't have to write it... Jelly is not my cup of
tea ;)
Emmanuel
Re: upgrade nlog4j
Posted by Nick Faiz <ni...@atlassian.com>.
This sounds like a good move, as far as handling dependency madness
goes. It works quite well in apacheds/trunk/project.xml right now.
It'd be even better if we could have a parent POM above that, for all
of the projects.
Anyway, we can discuss this further tomorrow.
Cheers,
Nick
On 07/09/2005, at 12:06 AM, Enrique Rodriguez wrote:
> Nick Faiz wrote:
>
>> Hi Emmanuel,
>> Yes, I see your point now. Sorry, I had thought that nlog4j was
>> only listed as a dependency in the project.xml on the apacheds
>> trunk. After running a grep I can see that it is in ASN and in
>> quite a few places within standalone.
>> I had thought you were talking about versioning problems in
>> general when you added your comment previously to DIREVE-242.
>> Well, this problem is simply going to keep increasing, as you
>> have pointed out.
>> Do you agree with a maven goal that will scan the project
>> structure for dependency clashes? Any alternative ideas for
>> controlling version havoc?
>>
>
> 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.
>
> 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
>
Re: upgrade nlog4j
Posted by Enrique Rodriguez <en...@gmail.com>.
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.
>>
>>
>>
>
>
>
Re: upgrade nlog4j
Posted by Emmanuel Lecharny <el...@gmail.com>.
> 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
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.
>
>
>
Re: upgrade nlog4j
Posted by Enrique Rodriguez <en...@gmail.com>.
Nick Faiz wrote:
> Hi Emmanuel,
>
> Yes, I see your point now. Sorry, I had thought that nlog4j was only
> listed as a dependency in the project.xml on the apacheds trunk. After
> running a grep I can see that it is in ASN and in quite a few places
> within standalone.
>
> I had thought you were talking about versioning problems in general
> when you added your comment previously to DIREVE-242.
>
> Well, this problem is simply going to keep increasing, as you have
> pointed out.
>
> Do you agree with a maven goal that will scan the project structure for
> dependency clashes? Any alternative ideas for controlling version havoc?
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.
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
Re: upgrade nlog4j
Posted by Nick Faiz <ni...@atlassian.com>.
Hi Emmanuel,
Yes, I see your point now. Sorry, I had thought that nlog4j was only
listed as a dependency in the project.xml on the apacheds trunk.
After running a grep I can see that it is in ASN and in quite a few
places within standalone.
I had thought you were talking about versioning problems in general
when you added your comment previously to DIREVE-242.
Well, this problem is simply going to keep increasing, as you have
pointed out.
Do you agree with a maven goal that will scan the project structure
for dependency clashes? Any alternative ideas for controlling version
havoc?
Cheers,
Nick
On 06/09/2005, at 11:15 PM, Emmanuel Lecharny wrote:
> Hi think I have more than looked at DIREVE-242 ...
>
> My point is that we may upgrade to 1.2.17, without any problem, but we
> lust do it for the whole project. As a new version is still to be
> delivered really soon, it can be the perfect target.
>
> Alex ?
>
> On Tue, 2005-09-06 at 21:33 +1000, Nick Faiz wrote:
>
>
>> Hi,
>>
>> Could someone please look over DIREVE242 to think about upgrading
>> nlog4j?
>>
>> http://issues.apache.org/jira/browse/DIREVE-242
>>
>> Hopefully it will get rid of the NoSuchMethodError I was seeing a
>> few weeks ago.
>>
>> Cheers,
>> Nick
>> ---------------------------------------------------------------------
>> ------------------
>> 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.
>>
>>
>>
>>
>>
>
>
>
Re: upgrade nlog4j
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi think I have more than looked at DIREVE-242 ...
My point is that we may upgrade to 1.2.17, without any problem, but we
lust do it for the whole project. As a new version is still to be
delivered really soon, it can be the perfect target.
Alex ?
On Tue, 2005-09-06 at 21:33 +1000, Nick Faiz wrote:
> Hi,
>
> Could someone please look over DIREVE242 to think about upgrading nlog4j?
>
> http://issues.apache.org/jira/browse/DIREVE-242
>
> Hopefully it will get rid of the NoSuchMethodError I was seeing a few weeks ago.
>
> Cheers,
> Nick
> ---------------------------------------------------------------------------------------
> 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.
>
>
>