[
http://jira.codehaus.org/browse/MAVENUPLOAD-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90232
]
Jason Dillon commented on MAVENUPLOAD-1220:
-------------------------------------------
Hrm... upon closer inspection of what is actually in these jars... I'm not
really sure that it is such a good idea to put in any dependencies in the pom.
>From their {{README.txt}}:
{quote}
+ mx4j-jmx.jar --> contains the JSR 3 javax.management.* classes
+ mx4j-impl.jar --> contains the mx4j.* classes that implements JSR 3
functionalities
+ mx4j.jar --> The mx4j-jmx.jar and mx4j-impl.jar packed together
+ mx4j-rjmx.jar --> contains the JSR 160 javax.management.remote.* classes
+ mx4j-rimpl.jar --> contains the mx4j.* classes that implements JSR 160
functionalities
+ mx4j-remote.jar --> The mx4j-rjmx.jar and mx4j-rimpl.jar packed together
+ mx4j-tools.jar --> contains the MX4J tools
+ mx4j-soap.war --> contains a sample web application that deploys a JSR
160 connector server over the soap protocol
+ mx4j-examples.jar --> contains the MX4J examples
{quote}
Based on this I don't believe that these artifacts need (or should have any
deps in the pom)... the reasoning behind this is that users may want to select
which jar they depend up.
For example, mx4j-tools.jar users may want to depend on mx4j.jar or
(mx4j-jmx.jar and mx4j-impl.jar), and *some* of the tools may also depend on
some of the remote classes, which could be in mx4j-remote.jar or (mx4j-rjmx.jar
and mx4j-rimpl.jar).
The mx4j-soap.war has all of the deps included, so it does not need any deps,
since they are included in WEB-INF/lib.
And mx4j-examples.jar has similar issues as mx4j-tools.jar does... in that
there are a few different ways to pick up the artifacts.
BTW, the graph attached is not really accurate, since it shows that mx4j-rimpl
and mx4j-rjmx depend on mx4j-remote, when mx4j-remote is an aggregation of the
contents of both of those jars. Same for mx4j-jmx and mx4j-impl.
Based on this... I don't think any dependencies should be added to these jars
and that they should be deployed to central ASIS in their bundled form here:
http://people.apache.org/~kevan/Mx4jUploadRequests
* * *
If that is not acceptable, then please advise what would be acceptable... as
based on the jars contents I don't see an obvious way to roll the dependencies.
Doing so makes some decisions for users which I am not sure we should be doing.
If mx4j was built with maven, perhaps it would reduce the number of jars with
duplicate classes and use the maven2 transitive dependency mechanism. But I
don't see that happening anytime soon... and its certainly not going to happen
for this release.
I have ping'd the mx4j dev list to enlist any advise they may have... but IMO I
think that the artifacts should be published how they are currently bundled
with no dependencies.
> Upload mx4j 3.0.2
> -----------------
>
> Key: MAVENUPLOAD-1220
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1220
> Project: maven-upload-requests
> Issue Type: Task
> Reporter: Kevan Miller
> Assigned To: Carlos Sanchez
> Attachments: dep.png
>
>
> The mx4j project has created a service release of mx4j. This release fixes
> problems found in Geronimo testing.
> I'm not a developer on mx4j, but have exchanged notes with Simone Bordet (who
> is). He requested that I submit the upload request.
> These new poms and jars mirror the 3.0.1 mx4j poms and jars already on
> ibiblio.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
