|
History
| Log In
|
|
|
|
they should add to the m1 pom
<properties> <optional>true</optional> </properties> The pom you are seeing in the repo must be something that is automatically converted from the M1 POM that we have in commons-logging. I'm not sure how that works exactly, but I'm sure that Carlos can tell you more. Commons-logging does not have an M2 POM itself yet.
Now to your questions about the dependencies. The current build for commons-logging is based on Ant. There are several reasons for that, that I will not go into detail about. But one of the reasons is that commons-logging does not follow the design guidelines set up by Maven and therefor it is not easy to Mavenize. The rule that we don't follow is that of one module - one artifact. There are several artifacts that form commons-logging:
These artifacts have different dependencies because they contain different classes. This makes it difficult to create one POM to rule them all, without putting everything in there. Log4j, avalon-framework, logkit and servlet-api are required to compile commons-logging and commons-logging-adapters. The artifact that most people should use as a dependency in their own products is commons-logging-api which doesn't require these dependencies, but there is no POM for that. I will disuss this on commons-dev with the rest of the team to see what the best approach would be. Basically all dependencies to other logger implementations are optional. Remember that c-l is "just" a wrapper that permits the user to choose. Selecting the JDK logger, the SimpleLogger or the NullLogger no further dep is required.
Ok but the real trouble is :
<dependency> <groupId>javax.servlet</groupId> <artifactId>servlet-api</artifactId> <version>2.3</version> </dependency> Include a servlet-api.jar in WEB-INF/lib doesnt' really works very well  But normally it's already included with a provided scope in the pom but.. For the others stuff I have a correct commons-logging.properties. What do you think about my first proposal ? If you're ok , just approve it and someone (Carlos ?) will apply changes. Thanks, Olivier Yeah, commons-logging is definitely a difficult beast to create a maven pom for
The commons-logging-api jar really should be called commons-logging-tomcat; IMO, it's not something for general use. Sorry about the name, but that's historical and can't easily be changed now. I don't see any benefits from anyone declaring a dependency on this api jar vs the complete jar (once the dependencies are marked optional); the size difference is trivial. commons-logging-adapters.jar should be the dependency for any code that will be deployed into a container that provides commons-logging.jar or commons-logging-api.jar at the container level. Yes, we know that's not terribly elegant, but blame the Java class resolution rules for that. In all other cases, commons-logging.jar is the correct dependency for projects. As Joerg notes, all dependencies should be optional [except the servlet-api dependency which probably should be *both* optional and provided :-]. Regards, hmm..actually, maybe a CLASSIFIER is what is needed here, to distinguish the different flavours. They really are the same artifact after all, just in slightly tweaked bundles. I'll leave that to the maven gurus to consider...
IMO the right way to approach JCL (in dependency terms) is as a virtual dependency.
To eleborate, when the majority of projects declare a dependency on JCL they don't actually care what implementation of the API they use, just that an implementation of the API is provided. The actual API itself (as opposed to the jar) has no difficult dependencies. Any artifact providing a binary compatible implementation (commons-logging.jar, commons-logging-api.jar, commons-logging-adapters.jar, no-commons-logging.jar or slf4j.jar) could be used to satifsy this dependency. In other words, JCL is best managed as a standard. In the same way that an library with a dependency on JMX could have that dependecy satisfied by any implementation library. Most packaging systems in the *nix word can cope with virtual dependencies. IMHO sooner or later maven will need to too. If maven can't handle virtual dependencies well ATM, it would probably be best to make every dependency optional in the Maven2 POM. For now dependencies have been fixed in the m1 pom, so next versions won't have this problem
http://svn.apache.org/viewvc/jakarta/commons/proper/logging/trunk/project.xml 
We can't change the already deployed version as it will be worst, causing non reproducible builds We've been using commons-logging-1.1.jar in our project for a very long time without needing logkit-1.0.1.jar or avalon-framework-4.1.3.jar or servlet-api-2.3.jar. (We have an explicit dependency on log4j-1.2.13.jar.)
What is really needed is a new Maven scope for "compile only" that says that an artifact is required at compile-time but is optional at runtime. In lieu of that... commons-logging-1.0.4.pom specifies <optional>true</optional> for the various logging implementations, so there is a precedent that should be upheld in commons-logging-1.1.pom. There is really no need to pull in all of these extra dependencies that may not actually be used by a project that uses JCL. Better to let each project decide which implementation to use by explicitly depending on one. Attached is a patch to make the various implementations optional in commons-logging-1.1.pom. As I said
dependencies have been fixed in the m1 pom, so next versions won't have this problem We can't change the already deployed version as it will be worst, causing non reproducible builds If you want you can ask commons-logging to release 1.1.1 with a fixed pom |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
bad dependencies in commons-logging-1.1.pom
I hope one will put a comment or an approvment.
Oliver