www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <steve.lough...@gmail.com>
Subject Re: wtf happened to log4j?
Date Wed, 14 Nov 2007 17:08:37 GMT
On Nov 14, 2007 3:59 PM, Dennis Lundberg <dennisl@apache.org> wrote:
> Steve Loughran wrote:
> > On Nov 12, 2007 9:31 PM, Dennis Lundberg <dennisl@apache.org> wrote:
> >> I think that the 1.2.15 release is the first Maven 2 release of log4j.
> >> Perhaps we can offer them some help in getting their pom corrected.
> >
> > Looks like they've noticed
> >
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=43304
> >
> > but they need some consultancy to differentiate what is non-optional
> > to build log4j (their problem) with what is needed to run it (everyone
> > else's).
>
> I'll see if I can help out.


great!

> > Regardless of whose fault it is, its a strong argument against using
> > transitive dependency info from any third party project, no matter
> > which tool you use. Because you can't be sure that a point increment
> > wont introduce some version of something you don't want. I'm going to
> > have to go through all my ivy.xml files that use log4j and make sure I
> > only ask for the artifact itself, same as we do for commons-logging.
>
> Agreed, but I'm sure it was unintentional. Just hold back on upgrading
> log4j until a fixed version comes out. Unless of course there is
> something in 1.2.15 that you absolutely need.

Nothing pressing, but I do like to push forward on versions of things,
as they tend to have the latest bug fixes. And in OSS, its only
SVN_HEAD that tends to get any fixes at all.

>
> Give me one more week and I hope to have commons-logging-1.1.1 out the
> door. ;-)
>

excellent. Meanwhile, I patched my dependency metadata; it only
changed in one place . Within the project, we have a
no-duplicate-dependencies rule, so if you want commons-logging or
log4j, you have to depend on the sf-logging component. Change its
dependencies and everything is fixed. I wasn't planning for this kind
of problem when I set that policy up, but it  helps. It's really set
for RPM publishing, where every installed artifact is managed by only
one RPM. So you need to get the RPM dependencies set up to match your
artifacts, then create the rpms. Its a PITA but is nice in some
respects, brittle in other ways.

steve

Mime
View raw message