Dennis Lundberg wrote:
Srepfler Srgjan wrote:
Hi,
The problem I've bumped in is that commons-logging 1.1 has put a
dependency on the servlet-api library and left the default scope.
That means servlet-api gets right into my EAR which in turn makes my
web application unable to serve my jsp's as it's a library that is
provided by the servlet container. I don't declare commons-logging
explicitly but I've got a bunch libraries that depend on it
implicitly so it would be too hard to exclude the commons-logging lib
for all the particular libs and explicitly declare it. For the moment
I've manually modified the 1.1 pom but I think that even if the
commons-logging team ships a 1.1.1 release as my libs depend on 1.1
I'd still be having issues thanks to the don't replace releases
policy in the repository. I'd file a bug but the issue tracker tag in
the pom points to bugzilla and they are not listed, so this is a
public shout out hoping that it will get picked up.
If anyone can raise the issue with the c-logging guys or can make a
replace of only the pom in the repository it would be a great
community service.
Srgjan
The dependency on servlet-api has had the following added in the
current 1.1.1-SNAPSHOT version of the pom:
<optional>true</optional>
That is great but all the libraries that currently use c-logging and
bring in the dependency are breaking my build. I suspect this hasn't
been raised as an issue because many are still calling versions before
1.1 and it seems I've added some artifacts that called upon 1.1 and it
override the other versions where this problem didn't persist. I
wouldn't be surprised if more people discover this problem now (I
suspect either the latest version of hibernate or spring 2.0.2 brought
in 1.1 bu I could be mistaken). I know the repository policy and I
understand the reasoning behind it but modifying the pom would probably
not break of any build and the current one does.
I would be nice if maven would have a way to declare library aliases in
settings.xml so that one can say "use c-logging 1.1.1 instead of 1.1" or
"use the glassfish implementation of jta instead of the sun
implementation". That would allow quick fixes without the need to
disturb Carlos for these minor things.
Now if we go in that direction, a nice tangent would be if we can add an
automated feedback of these aliases which could be some sort of a
retroactive loop that could improve the quality of the artifacts. Let me
explan.
The repository remains the same. We know there are may flaws in the
current pom's but we don't change the pom's because that generally
creates more problems then benefits. I we would have this alternative
knowledge base of aliases or alternative pom's (that contain diff's of
the original pom), we could declare use that lib but also apply items
#234 and #543 from the knowledge base plus apply this local patch. Plus
you could even submit that back and people could use it as well.
To me this does seems like a complication of the maven model but it's
also a much more dynamic "bazaar'ish" model of development that combines
both the traditional approach and a dynamic, organic way of improving
the repository while retaining the declarative approach. I'm also aware
this would (perhaps) need a db that is much more difficult to replicate
then the current repository mirroring system and would probably require
more CPU power. It's just a tangent thought.
Srgjan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
