|
[
Permlink
| « Hide
]
Andrew Perepelytsya added a comment - 09/Oct/08 02:22 PM
Didn't we bubble them up there before? To avoid duplication. As a minimum we should just use dependencyManagement section if not setup for these.
The logging issue is a result of slf4j-jdk14 being in the top-level pom, which is the the slfj4-to-java.util-logging-bridge
Another drawback of the toplevel, provided logging dependencies is brougth up by Ross:
Oh, one more while we're at it: the pom of the transports subdir also contains dependencies which are then automatically inherited - bad.
The transports POM has the dependencies needed to support XML Namespaces and Functional Tests, would you propose repeating those for each and every transport? Isn't that the purpose of having a hierarchy of POMs?
> When creating a new project based on Mule, the user needs to add the Logging JARs to their pom separately.
Is this necessarily a bad thing? If Mule is being used as part of a larger app., logging for the app. is probably already configured somehow. What if the app. is using log4j and Mule drags in clogging, then the app. will have both on their classpath or they'll have to explicitly exclude the clogging from Mule (once they figure out what's going on).
Maybe this is a valid case of dependencies on a parent POM then. But in most cases I've seen dependencies on "intermediate" poms, they've been just wrong in the past.
I think that's not a valid point: Mule has a compile time dependency on the clogging APIs and there's no way that Mule could operate without it so mule-core may as well have the slf4j stuff as direct dependency since all transports and modules will use that, too. As for the runtime dependency on log4j your point above may be valid, though. I still think it's better to have core depend on log4j directly and exclude that dependency in the rare cases we don't need it (the JCA bundle comes to mind). Travis, most of our customers and probably the same proportion of users, run mule as a stand alone application platform. This means that all those guys need to to add logging Jars to their projects which really is a bad thing. For the folks that have a conflict they can use the proper exclusion mechanism in Maven.
BTW, I think it makes sense for some libraries to be available in the parent POMs, there is no point bubbling up dependencies when they are needed by every child pom. However, I would expect that by pulling in the mule-core jar into my project would bring all its dependent jars. Right now it doesn't and that makes it seem broken. I would suggest putting logging in the mule-core pom and put a note on the wiki about how you can exclude them if you are embedding Mule and already have logging jars in your application. Merge to 2.1.x branch: http://fisheye.codehaus.org/changelog/mule/?cs=13500
 Merge to 2.1.2 release branch: http://fisheye.codehaus.org/changelog/mule/?cs=13501 Reopening this issue as the CI server complains about missing dependencies.
http://fisheye.codehaus.org/changelog/mule/?cs=13503
merge to 2.1.x branch: http://fisheye.codehaus.org/changelog/mule/?cs=13504 merge to 2.1.2 branch: http://fisheye.codehaus.org/changelog/mule/?cs=13506 more missing dependencies: http://fisheye.codehaus.org/changelog/mule/?cs=13505
merge to 2.1.x: http://fisheye.codehaus.org/changelog/mule/?cs=13507 merge to 2.1.2: http://fisheye.codehaus.org/changelog/mule/?cs=13508 more missing dependencies: http://fisheye.codehaus.org/changelog/mule/?cs=13509
merge to 2.1.x: http://fisheye.codehaus.org/changelog/mule/?cs=13510 merge to 2.1.2: http://fisheye.codehaus.org/changelog/mule/?cs=13511 more missing dependencies: http://fisheye.codehaus.org/changelog/mule/?cs=13512
merge to 2.1.x: http://fisheye.codehaus.org/changelog/mule/?cs=13513 merge to 2.1.2: http://fisheye.codehaus.org/changelog/mule/?cs=13514 The CI server just ran green on all tests - closing.
|
||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Closed
Major
Remove all top-level dependencies