[jira] Commented: (MSHADE-90) Warn or error for signature files
[ https://jira.codehaus.org/browse/MSHADE-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=272274#comment-272274 ] Robert Burrell Donkin commented on MSHADE-90: - I had a think about whether turning on transformers by default would be a good idea (or not) but (on reflection) I agree with you that it's not. Yes, in terms of implementation then IMHO it would clearer to share the logic but not include a transformer by default. (If I understand correctly) I don't see off-hand how to make a transformer log or otherwise communicate. Do you? IIUY the point is that Transformers are (well) supposed to transform stuff, not verify. It's possible to use a Transformer then just throw an Exception but going forward, a separate verification would probably be better. Warn or error for signature files - Key: MSHADE-90 URL: https://jira.codehaus.org/browse/MSHADE-90 Project: Maven 2.x Shade Plugin Issue Type: Improvement Affects Versions: 1.4 Reporter: Benson Margulies If you shade a signed jar, the .SF files travel into the shaded jar. And then signature verification fails, and everyone gets consternated. It seems to me that shade should, by default, error when it hits one of these, and have a configuration option to strip them out. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSHADE-102) [DOCS] Added Basic Usage For ApacheNoticeResourceTransformer
[DOCS] Added Basic Usage For ApacheNoticeResourceTransformer - Key: MSHADE-102 URL: https://jira.codehaus.org/browse/MSHADE-102 Project: Maven 2.x Shade Plugin Issue Type: Improvement Affects Versions: 1.5 Reporter: Robert Burrell Donkin Attachments: maven-shade-plugin-notice-docs.patch Documents and example of the basic usage of ApacheNoticeResourceTransformer -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSHADE-94) NullPointerException on empty relocation pattern (default package)
[
https://jira.codehaus.org/browse/MSHADE-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=272179#comment-272179
]
Robert Burrell Donkin commented on MSHADE-94:
-
I think this problem exists. I'm creating some tests to verify and (if so) a
patch to fix.
NullPointerException on empty relocation pattern (default package)
--
Key: MSHADE-94
URL: https://jira.codehaus.org/browse/MSHADE-94
Project: Maven 2.x Shade Plugin
Issue Type: Bug
Affects Versions: 1.4
Reporter: J@ck
I need a few classes from a 3rd party jar that are declared in the default
package. Since usage of the default package should be avoided, I try to
relocate the classes to a named package:
{code:title=pom.xml}
...
relocation
pattern /
shadedPatternorg.example.foo.bar/shadedPattern
/relocation
{code}
The Shade Plugin crashes with a NPE:
{code:title=Stacktrace}
Caused by: org.apache.maven.plugin.MojoExecutionException: Error creating
shaded jar: null
at
org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:503)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: java.lang.NullPointerException
at
org.apache.maven.plugins.shade.relocation.SimpleRelocator.init(SimpleRelocator.java:52)
at
org.apache.maven.plugins.shade.mojo.ShadeMojo.getRelocators(ShadeMojo.java:616)
at
org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:440)
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSHADE-94) NullPointerException on empty relocation pattern (default package)
[
https://jira.codehaus.org/browse/MSHADE-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Burrell Donkin updated MSHADE-94:
Attachment: maven-shade-plugin-SimpleRelocator-NullPointerException.patch
This patch includes integration and unit test for the problem described. This
is narrow patch addressing only the reported NullPointerException.
For more sophisticated handling of default packages, IMHO extra functionality
is needed.
NullPointerException on empty relocation pattern (default package)
--
Key: MSHADE-94
URL: https://jira.codehaus.org/browse/MSHADE-94
Project: Maven 2.x Shade Plugin
Issue Type: Bug
Affects Versions: 1.4
Reporter: J@ck
Attachments:
maven-shade-plugin-SimpleRelocator-NullPointerException.patch
I need a few classes from a 3rd party jar that are declared in the default
package. Since usage of the default package should be avoided, I try to
relocate the classes to a named package:
{code:title=pom.xml}
...
relocation
pattern /
shadedPatternorg.example.foo.bar/shadedPattern
/relocation
{code}
The Shade Plugin crashes with a NPE:
{code:title=Stacktrace}
Caused by: org.apache.maven.plugin.MojoExecutionException: Error creating
shaded jar: null
at
org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:503)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: java.lang.NullPointerException
at
org.apache.maven.plugins.shade.relocation.SimpleRelocator.init(SimpleRelocator.java:52)
at
org.apache.maven.plugins.shade.mojo.ShadeMojo.getRelocators(ShadeMojo.java:616)
at
org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:440)
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSHADE-96) Build output log is littered with duplicate warnings
[ https://jira.codehaus.org/browse/MSHADE-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=272191#comment-272191 ] Robert Burrell Donkin commented on MSHADE-96: - I think this could be best solved by factoring out a MergerTransformer interface. I'm happy to development a fully tested solution if the consensus approves this approach. Build output log is littered with duplicate warnings Key: MSHADE-96 URL: https://jira.codehaus.org/browse/MSHADE-96 Project: Maven 2.x Shade Plugin Issue Type: Improvement Affects Versions: 1.3.3, 1.4 Reporter: Elisha Ezeugoh -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSHADE-87) Shade with respect of packaging-type
[ https://jira.codehaus.org/browse/MSHADE-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=272193#comment-272193 ] Robert Burrell Donkin commented on MSHADE-87: - Switching to commons-compress would allow shade to be applied to a variety of output formats. Given the ability to declare a structure (as suggested in this issue) this would make shade a powerful tool for application assembly. I would therefore favour a more general approach to the problem of structure, perhaps with convenience shortcuts for common formats. Not sure about the best way to describe it, though. Shade with respect of packaging-type Key: MSHADE-87 URL: https://jira.codehaus.org/browse/MSHADE-87 Project: Maven 2.x Shade Plugin Issue Type: Improvement Affects Versions: 1.4 Reporter: Robert Scholte The current version of the maven-shade-plugin only support jar and equal structured packaging types, but it would be great if it could shade war-files as well. At least the following should be changed: * shaded classes shouldn't be placed in the root, but in WEB-INF/classes * shaded artifacts should be removed from WEB-INF/lib -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSHADE-90) Warn or error for signature files
[ https://jira.codehaus.org/browse/MSHADE-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=272194#comment-272194 ] Robert Burrell Donkin commented on MSHADE-90: - Couldn't this be implemented by a new ResourceTransformer? Warn or error for signature files - Key: MSHADE-90 URL: https://jira.codehaus.org/browse/MSHADE-90 Project: Maven 2.x Shade Plugin Issue Type: Improvement Affects Versions: 1.4 Reporter: Benson Margulies If you shade a signed jar, the .SF files travel into the shaded jar. And then signature verification fails, and everyone gets consternated. It seems to me that shade should, by default, error when it hits one of these, and have a configuration option to strip them out. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSHADE-8) Shade plugin will cheerfully relocate your own classes
[ https://jira.codehaus.org/browse/MSHADE-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=272195#comment-272195 ] Robert Burrell Donkin commented on MSHADE-8: IMHO this isn't a bug. Shade plugin will cheerfully relocate your own classes -- Key: MSHADE-8 URL: https://jira.codehaus.org/browse/MSHADE-8 Project: Maven 2.x Shade Plugin Issue Type: Improvement Affects Versions: 1.0-alpha-15 Reporter: Dan Fabulich My relocation patterns were initially too relaxed, and so they wound up relocating my own classes, rather than just the classes I depend on. I could imagine somebody wanting to do this, but I think there should probably be a safety check or something to try to help you not do it by accident; it's probably not what you want. (After all, if you wanted your code to be in a different package, wouldn't you have just written it that way to begin with?) In my case I was working on a Maven plugin; when its classes got relocated, it broke the plugin metadata... definitely not what I wanted. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSHADE-36) Dependency reduced pom does not replace the packaged META-INF/maven version
[ https://jira.codehaus.org/browse/MSHADE-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=272201#comment-272201 ] Robert Burrell Donkin commented on MSHADE-36: - Would creating a ResourceTransformer be the best approach? Dependency reduced pom does not replace the packaged META-INF/maven version --- Key: MSHADE-36 URL: https://jira.codehaus.org/browse/MSHADE-36 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 1.1 Reporter: Mark Hobson The dependency reduced pom needs to replace the packaged pom at: META-INF/maven/groupId/artifactId/pom.xml This will allow tools that use this metadata to read the correct shaded dependencies (e.g. maven-runtime). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSHADE-90) Warn or error for signature files
[ https://jira.codehaus.org/browse/MSHADE-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=272204#comment-272204 ] Robert Burrell Donkin commented on MSHADE-90: - I agree that squawking would be the best behaviour. This is a special case of squawking whenever a resource matches a regex. A NotAllowedResourceTransformer might be generally useful. Warn or error for signature files - Key: MSHADE-90 URL: https://jira.codehaus.org/browse/MSHADE-90 Project: Maven 2.x Shade Plugin Issue Type: Improvement Affects Versions: 1.4 Reporter: Benson Margulies If you shade a signed jar, the .SF files travel into the shaded jar. And then signature verification fails, and everyone gets consternated. It seems to me that shade should, by default, error when it hits one of these, and have a configuration option to strip them out. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSHADE-8) Shade plugin will cheerfully relocate your own classes
[ https://jira.codehaus.org/browse/MSHADE-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=272205#comment-272205 ] Robert Burrell Donkin commented on MSHADE-8: IMHO debugging shade is distinct issue from verification rules for the completed build. Typically, better instrumentation with logging is a better solution to debugging problems than adding extra rules that may catch people expecting otherwise. But it's quite reasonable to want to verify that no original class has been relocated. Been thinking that it might be useful to track the origins of resources. This would allow (for example) generation of accurate licensing information. This would also allow application of verification rules... Shade plugin will cheerfully relocate your own classes -- Key: MSHADE-8 URL: https://jira.codehaus.org/browse/MSHADE-8 Project: Maven 2.x Shade Plugin Issue Type: Improvement Affects Versions: 1.0-alpha-15 Reporter: Dan Fabulich My relocation patterns were initially too relaxed, and so they wound up relocating my own classes, rather than just the classes I depend on. I could imagine somebody wanting to do this, but I think there should probably be a safety check or something to try to help you not do it by accident; it's probably not what you want. (After all, if you wanted your code to be in a different package, wouldn't you have just written it that way to begin with?) In my case I was working on a Maven plugin; when its classes got relocated, it broke the plugin metadata... definitely not what I wanted. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSHADE-48) Dependency reduced POM is missing XML comments like license headers
[ https://jira.codehaus.org/browse/MSHADE-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=272207#comment-272207 ] Robert Burrell Donkin commented on MSHADE-48: - dependency-reduced-pom is generated from the model for the original project. Comments are not retained within the model. They aren't available to be written. I don't think it's possible to implement this. In terms of addressing the specific use case (needing to add a license header), support for adding a header comment could be easily enough added if is good enough. Dependency reduced POM is missing XML comments like license headers --- Key: MSHADE-48 URL: https://jira.codehaus.org/browse/MSHADE-48 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 1.2 Reporter: Benjamin Bentmann Priority: Minor The dependency reduced POM is currently generated from the previously parsed model and as such misses any XML comments, including the license header. For example, see [mercury-util:1.0-alpha-5|http://repo2.maven.org/maven2/org/apache/maven/mercury/mercury-util/1.0-alpha-5/mercury-util-1.0-alpha-5.pom]. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSHADE-85) Multiple executions: second eats output of first
[ https://jira.codehaus.org/browse/MSHADE-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Burrell Donkin updated MSHADE-85: Attachment: maven-shade-plugin-2-shades.patch IMHO this is best resolved with a documentation patch. This adds a FAQ to cover this, though perhaps it's a little too brief... Multiple executions: second eats output of first Key: MSHADE-85 URL: https://jira.codehaus.org/browse/MSHADE-85 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 1.4 Reporter: Benson Margulies Priority: Minor Attachments: maven-shade-plugin-2-shades.patch this may just turn into a doc issue. I tried to add a second 'less shaded' execution to my pom. The first execution was set up to replace the main artifact. Sure enough, the shaded output of the first went into the second. I suppose that I'll have to make sure that both use classifiers so that the main artifact is left around for the second, but some notes in the doc might have saved me some confusion. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSHADE-101) ApacheNoticeResourceTransformer NullPointerException for some licenses when no parameters set.
ApacheNoticeResourceTransformer NullPointerException for some licenses when no parameters set. -- Key: MSHADE-101 URL: https://jira.codehaus.org/browse/MSHADE-101 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 1.5 Reporter: Robert Burrell Donkin Attachments: ApacheNoticeResourceTransformer-NullPointerException.patch For some dependencies, ApacheNoticeResourceTransformer throws a NullPointerException when no parameters are set. Included in the patch are * an integration test case which demonstrates the problem, * a unit test case (including tests around this problem) and * my proposed (narrow) fix for ApacheNoticeResourceTransformer. ATM no parameter is mandatory. This may indicate an intention to support a basic use case without parameters. So this patch opts for a reasonable default. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSHADE-100) [DOCS] Describe Available Resource Transformers
[DOCS] Describe Available Resource Transformers --- Key: MSHADE-100 URL: https://jira.codehaus.org/browse/MSHADE-100 Project: Maven 2.x Shade Plugin Issue Type: Improvement Affects Versions: 1.5 Reporter: Robert Burrell Donkin Attachments: describe-resource-descriptors.patch maven-shade-plugin includes many useful ResourceTransformer implementations. This patch add descriptions for everyone that worked well for me (expect patches with test cases later). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-562) [documentation] Add links to Maven Shade plugin
[documentation] Add links to Maven Shade plugin --- Key: MASSEMBLY-562 URL: https://jira.codehaus.org/browse/MASSEMBLY-562 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Affects Versions: 2.3 Reporter: Robert Burrell Donkin Priority: Minor Attachments: uber-jar-documentation.patch maven-shade-plugin provides superior support for uber-jars, and is a better choice when something more than jar-with-descriptors is required. This patch amends the documentation so that users are made aware that this plugin is available. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-159) Absolute URI rendered as relative URI if absolute URI related to domain of POM URI
[ http://jira.codehaus.org/browse/MSITE-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=189682#action_189682 ] Robert Burrell Donkin commented on MSITE-159: - Introducing buggy URL rewriting code just because some Maven users don't understand URLs is a poor design choice. Absolute URI rendered as relative URI if absolute URI related to domain of POM URI -- Key: MSITE-159 URL: http://jira.codehaus.org/browse/MSITE-159 Project: Maven 2.x Site Plugin Issue Type: Bug Components: relative links Reporter: Ted Husted Under site-beta5 if the POM references a URI like urlhttp://struts.apache.org/url absolute URLs used in the site.xml file are converted to relative references. For example a reference to to http://struts.apache.org/1.x; becomes 1.x, and a reference to just http://struts.apache.org; becomes an empty string. If the documentation is being used offline, there are many cases when we want to refer people back to the website, to be sure the current information is used. The best use case is a download page that determines the mirror via CGI. Another use case is referring to a sister site in the domain, that might refer to another version. If used locally, the other site might not be in the relative location. Switching back to beta4 cures the behavior, and absolute URIs remain absolute, as expected. -- 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
[jira] Commented: (MAVENUPLOAD-2503) Synchronize dnsjava-osgi Maven Repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=183123#action_183123 ] Robert Burrell Donkin commented on MAVENUPLOAD-2503: Done (hopefully) Thanks for taking a look Robert Synchronize dnsjava-osgi Maven Repository - Key: MAVENUPLOAD-2503 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2503 Project: Maven Upload Requests Issue Type: Wish Reporter: Robert Burrell Donkin This project was created to package an upstream dependency for Apache James (and probably other projects too) suitably for Maven (and OSGi). The upstream maintainer is not interested in maintaining meta-data for Maven so it was agreed that a separate downstream project made more sense. -- 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
[jira] Created: (MAVENUPLOAD-2503) Synchronize dnsjava-osgi Maven Repository
Synchronize dnsjava-osgi Maven Repository - Key: MAVENUPLOAD-2503 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2503 Project: Maven Upload Requests Issue Type: Wish Reporter: Robert Burrell Donkin This project was created to package an upstream dependency for Apache James (and probably other projects too) suitably for Maven (and OSGi). The upstream maintainer is not interested in maintaining meta-data for Maven so it was agreed that a separate downstream project made more sense. -- 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
[jira] Commented: (MAVENUPLOAD-2503) Synchronize dnsjava-osgi Maven Repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=182241#action_182241 ] Robert Burrell Donkin commented on MAVENUPLOAD-2503: net.sf.dnsjavaosgi,mavens...@web.sourceforge.net:/home/groups/d/dn/dnsjava-osgi/htdocs/m2,rsync_ssh,Robert Burrell Donkin,rdon...@apache.org,, Synchronize dnsjava-osgi Maven Repository - Key: MAVENUPLOAD-2503 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2503 Project: Maven Upload Requests Issue Type: Wish Reporter: Robert Burrell Donkin This project was created to package an upstream dependency for Apache James (and probably other projects too) suitably for Maven (and OSGi). The upstream maintainer is not interested in maintaining meta-data for Maven so it was agreed that a separate downstream project made more sense. -- 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
[jira] Commented: (MAVENUPLOAD-2503) Synchronize dnsjava-osgi Maven Repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=182242#action_182242 ] Robert Burrell Donkin commented on MAVENUPLOAD-2503: This is the first time I've tried to setup something like this at SourceForge so appologies in advance for any mistakes I've made Synchronize dnsjava-osgi Maven Repository - Key: MAVENUPLOAD-2503 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2503 Project: Maven Upload Requests Issue Type: Wish Reporter: Robert Burrell Donkin This project was created to package an upstream dependency for Apache James (and probably other projects too) suitably for Maven (and OSGi). The upstream maintainer is not interested in maintaining meta-data for Maven so it was agreed that a separate downstream project made more sense. -- 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
[jira] Commented: (MEV-392) bad dependencies in commons-logging-1.1.pom
[ http://jira.codehaus.org/browse/MEV-392?page=comments#action_66408 ] Robert Burrell Donkin commented on MEV-392: --- 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. bad dependencies in commons-logging-1.1.pom --- Key: MEV-392 URL: http://jira.codehaus.org/browse/MEV-392 Project: Maven Evangelism Type: Bug Components: Dependencies Reporter: Olivier Lamy Hi, I have trouble concerning dependencies in commons-logging 1.1 dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.3/version /dependency scope must be provided dependency groupIdavalon-framework/groupId artifactIdavalon-framework/artifactId version4.1.3/version /dependency as 1.0.4 scope must be optionnal dependency groupIdlogkit/groupId artifactIdlogkit/artifactId version1.0.1/version /dependency as 1.0.4 scope must be optionnal -- 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
