[jira] Updated: (MRESOURCES-56) use (and release) the maven-filtering component
[ http://jira.codehaus.org/browse/MRESOURCES-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MRESOURCES-56: --- Assignee: Olivier Lamy Fix Version/s: 2.3 > use (and release) the maven-filtering component > --- > > Key: MRESOURCES-56 > URL: http://jira.codehaus.org/browse/MRESOURCES-56 > Project: Maven 2.x Resources Plugin > Issue Type: Improvement >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 2.3 > > > A component in shared has been created to do the resources copy and filtering > job. -- 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] Closed: (MPLUGIN-80) Detection of report goals always fails due to class loader separation
[
http://jira.codehaus.org/browse/MPLUGIN-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton closed MPLUGIN-80.
--
Assignee: Vincent Siveton
Resolution: Fixed
Fix Version/s: 2.4
Fixed and snapshots redeployed
> Detection of report goals always fails due to class loader separation
> -
>
> Key: MPLUGIN-80
> URL: http://jira.codehaus.org/browse/MPLUGIN-80
> Project: Maven 2.x Plugin Tools
> Issue Type: Bug
> Components: API, Plugin Plugin
>Reporter: Benjamin Bentmann
>Assignee: Vincent Siveton
> Fix For: 2.4
>
>
> {{PluginUtils}} simply invokes {{Class.forName(String)}} to load a mojo class
> from the current project using its plugin class loader. However, as outlined
> in [Guide to Maven
> Classloading|http://maven.apache.org/guides/mini/guide-maven-classloading.html],
> Maven plugins have no direct access to the classes of the current project.
> Besides, wouldn't the maven-plugin-plugin's {{report}} goal need [EMAIL
> PROTECTED] phase="compile"}} in order to ensure the mojo classes are existent
> prior to try to load them?
> Not sure about that but maybe it's worth to extend the mojo descriptor with a
> flag "report" such that this info could be retrieved without reflection in
> some far future but is derived by the goal extractors.
> P.S: You don't need to instantiate a class just to do {{instanceof}}
> checking. To check for a report mojo simply do:
> {code:java}
> MavenReport.class.isAssignableFrom( clazz );
> {code}
--
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] Closed: (MPLUGIN-55) Maven (plexus?) doesn't recognize Mojo parameter setters defined in a base class
[
http://jira.codehaus.org/browse/MPLUGIN-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton closed MPLUGIN-55.
--
Assignee: Vincent Siveton
Resolution: Cannot Reproduce
Cannot reproduce
> Maven (plexus?) doesn't recognize Mojo parameter setters defined in a base
> class
>
>
> Key: MPLUGIN-55
> URL: http://jira.codehaus.org/browse/MPLUGIN-55
> Project: Maven 2.x Plugin Tools
> Issue Type: Improvement
>Reporter: David Jackman
>Assignee: Vincent Siveton
>Priority: Minor
>
> Create a Mojo class that extends some base class that itself defines a
> parameter that uses a setter. Here's an example:
> {code}
> public class Base extends AbstractMojo
> {
>/**
>* @parameter property="parameter"
>*/
>private String m_parameter;
>public void setParameter(String parameter)
>{
> m_parameter = parameter;
>}
> ...
> }
> {code}
> {code}
> /**
> * @goal mygoal
> */
> public class MyMojo extends Base
> {
> ...
> }
> {code}
> Maven can build the plugin just fine, but when I attempt to execute the goal,
> I get an error:
> org.codehaus.plexus.component.configurator.ComponentConfigurationException:
> Cannot access method: com.example.MyMojo.setParameter( java.lang.Class ).
> If I move the setter to the goal class, it works just fine. Maven (plexus?)
> should be able to access the method from the base class.
--
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] Updated: (MPLUGIN-51) Allow plugin annotations on mojo members' classes
[
http://jira.codehaus.org/browse/MPLUGIN-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton updated MPLUGIN-51:
---
Description:
Right now, you can design a plugin to take nested xml in its
section. For example:
{noformat}
...
com.whatever.Main
this.jar;that.jar
...
{noformat}
This indicates that the mojo class has a classPath member of type ClassPath,
and the ClassPath class has members named mainClass and cp.
Unfortuatenly, maven doesn't know anything more about mainClass and cp. It
would be nice if these fields could have the same tags as top-level fields, so
I could mark them @required, give them default-values, etc.
This would require changing the maven-plugin-plugin to read javadoc and add
more data to plugin.xml. I think the extra data should be within the containing
tag, since adding new top-level tags will probably
break things.
Then we'd need to change how maven uses plugins, so it looks for these nested
tags and honors them.
Then we should also change whatever auto-generates plugin documentation, so
that the table of plugin parameters include the javadoc of nested fields.
It seems like a lot of work, but I'd be happy to start on a patch.
was:
Right now, you can design a plugin to take nested xml in its
section. For example:
...
com.whatever.Main
this.jar;that.jar
...
This indicates that the mojo class has a classPath member of type ClassPath,
and the ClassPath class has members named mainClass and cp.
Unfortuatenly, maven doesn't know anything more about mainClass and cp. It
would be nice if these fields could have the same tags as top-level fields, so
I could mark them @required, give them default-values, etc.
This would require changing the maven-plugin-plugin to read javadoc and add
more data to plugin.xml. I think the extra data should be within the containing
tag, since adding new top-level tags will probably
break things.
Then we'd need to change how maven uses plugins, so it looks for these nested
tags and honors them.
Then we should also change whatever auto-generates plugin documentation, so
that the table of plugin parameters include the javadoc of nested fields.
It seems like a lot of work, but I'd be happy to start on a patch.
> Allow plugin annotations on mojo members' classes
> -
>
> Key: MPLUGIN-51
> URL: http://jira.codehaus.org/browse/MPLUGIN-51
> Project: Maven 2.x Plugin Tools
> Issue Type: Improvement
>Reporter: Paul Jungwirth
>Priority: Minor
>
> Right now, you can design a plugin to take nested xml in its
> section. For example:
> {noformat}
>
> ...
>
> com.whatever.Main
> this.jar;that.jar
>
> ...
>
> {noformat}
> This indicates that the mojo class has a classPath member of type ClassPath,
> and the ClassPath class has members named mainClass and cp.
> Unfortuatenly, maven doesn't know anything more about mainClass and cp. It
> would be nice if these fields could have the same tags as top-level fields,
> so I could mark them @required, give them default-values, etc.
> This would require changing the maven-plugin-plugin to read javadoc and add
> more data to plugin.xml. I think the extra data should be within the
> containing tag, since adding new top-level tags will
> probably break things.
> Then we'd need to change how maven uses plugins, so it looks for these nested
> tags and honors them.
> Then we should also change whatever auto-generates plugin documentation, so
> that the table of plugin parameters include the javadoc of nested fields.
> It seems like a lot of work, but I'd be happy to start on a patch.
--
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-1952) Upload easyb artifacts
Upload easyb artifacts -- Key: MAVENUPLOAD-1952 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1952 Project: maven-upload-requests Issue Type: Wish Reporter: Rod Coffin http://easyb.googlecode.com/files/easyb-0.7-bundle.jar http://easyb.googlecode.com/files/easyb-dbunit-plugin-0.7-bundle.jar http://easyb.googlecode.com/files/maven-easyb-plugin-0.7-bundle.jar http://www.easyb.org http://code.google.com/p/easyb/ I am a developer on the easyb project and this can be verified at http://code.google.com/p/easyb/ where I (username rfciii) am listed as one of the project owners. -- 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] Moved: (MNG-3425) Required parameters of self written Mojo configured in execution part of POM are ignored and causing error
[
http://jira.codehaus.org/browse/MNG-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton moved MPLUGIN-48 to MNG-3425:
-
Key: MNG-3425 (was: MPLUGIN-48)
Project: Maven 2 (was: Maven 2.x Plugin Tools)
> Required parameters of self written Mojo configured in execution part of POM
> are ignored and causing error
> --
>
> Key: MNG-3425
> URL: http://jira.codehaus.org/browse/MNG-3425
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
> Environment: Windows XP
>Reporter: Halil-Cem Gürsoy
> Fix For: 2.0.9
>
>
> Required parameters configured in execution part of POM are ignored if:
> the parameter ist set as required AND
> (no default value is set OR
> default-Value is set to "") AND
> configuration of parameter values are done in the execution element.
> Example:
> Parameter definition in Mojo:
> {code}
> /**
>* @parameter default-value="ATTENTION DEFAULT"
>* @required
>*/
> private File dummy1;
> {code}
> and snip from POM:
> {code:xml}
>
>
> myownartifact.plugin
> maven-myownartifact-plugin
> true
>
>
> extract
>
> c:/my files/test/dummy1
>
>
>extract
>
>
>
>
>
> {code}
> runs fine.
> If I change the definition of the parameter to
> {code}
> /**
>* @parameter
>* @required
>*/
> private File dummy1;
> {code}
> or
> {code}
> * @parameter default-value=""
> {code}
> then I got an error:
> [0] inside the definition for plugin: 'maven-myownartifact-plugin'specify the
> following:
>
> ...
> VALUE
> .
> In my opinion this is a bug because with @required I have already tagged this
> parameter as mandatory. So I'm already forced to configure it.
> BTW, if I configure the parameters outside the execution element evrything
> works fine as expected!
> More info:
> - the plugin is bind to the package phase
> If a runable example is needed it's possible to provide one.
--
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] Updated: (MNG-3425) Required parameters of self written Mojo configured in execution part of POM are ignored and causing error
[
http://jira.codehaus.org/browse/MNG-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton updated MNG-3425:
-
Fix Version/s: 2.0.9
Component/s: Plugins and Lifecycle
> Required parameters of self written Mojo configured in execution part of POM
> are ignored and causing error
> --
>
> Key: MNG-3425
> URL: http://jira.codehaus.org/browse/MNG-3425
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
> Environment: Windows XP
>Reporter: Halil-Cem Gürsoy
> Fix For: 2.0.9
>
>
> Required parameters configured in execution part of POM are ignored if:
> the parameter ist set as required AND
> (no default value is set OR
> default-Value is set to "") AND
> configuration of parameter values are done in the execution element.
> Example:
> Parameter definition in Mojo:
> {code}
> /**
>* @parameter default-value="ATTENTION DEFAULT"
>* @required
>*/
> private File dummy1;
> {code}
> and snip from POM:
> {code:xml}
>
>
> myownartifact.plugin
> maven-myownartifact-plugin
> true
>
>
> extract
>
> c:/my files/test/dummy1
>
>
>extract
>
>
>
>
>
> {code}
> runs fine.
> If I change the definition of the parameter to
> {code}
> /**
>* @parameter
>* @required
>*/
> private File dummy1;
> {code}
> or
> {code}
> * @parameter default-value=""
> {code}
> then I got an error:
> [0] inside the definition for plugin: 'maven-myownartifact-plugin'specify the
> following:
>
> ...
> VALUE
> .
> In my opinion this is a bug because with @required I have already tagged this
> parameter as mandatory. So I'm already forced to configure it.
> BTW, if I configure the parameters outside the execution element evrything
> works fine as expected!
> More info:
> - the plugin is bind to the package phase
> If a runable example is needed it's possible to provide one.
--
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: (SUREFIRE-464) Default for failIfNoTests should be false
Default for failIfNoTests should be false - Key: SUREFIRE-464 URL: http://jira.codehaus.org/browse/SUREFIRE-464 Project: Maven Surefire Issue Type: Bug Components: plugin Affects Versions: 2.4.2, 2.4.1, 2.4 Reporter: Dain Sundstrom In maven the surefire plugin executes by default when ever I build, and since the default for failIfNoTests is now true all of my modules must have at least one test or I must manually configure the plugin to not fail. This is a minor annoyance for single module builds but is a major pain when you have lots of modules. In my case it is extremely annoying since we have example modules we distribute that don't extend or parent pom (so users don't have to pull down our whole code base to get an example project). This also means that the syntactic sugar "-Dtest=false" to turn off all testing no longer works. At the end of the day, I don't understand why not having tests is a build failure and not just a warning. -- 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: (MDEP-122) Analyze target does not work correctly when only using a constant defined in a different module
[
http://jira.codehaus.org/browse/MDEP-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125745
]
Benjamin Bentmann commented on MDEP-122:
Instead of {{}}, I suggest to use {{}}
to tell the plugin the actual meaning of the dependency. This allows the plugin
to correctly create the analysis right from the beginning instead of
post-processing the initial analysis. For example, this also allows to detect
the case of an used but undeclared dependency as sketched below:
{noformat}
project uses constant C from dep-b, hence dep-b should be a
declared dependency
+- dep-a:compile
+- dep-b:compile defines some constant C
{noformat}
> Analyze target does not work correctly when only using a constant defined in
> a different module
> ---
>
> Key: MDEP-122
> URL: http://jira.codehaus.org/browse/MDEP-122
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
>Affects Versions: 2.0-alpha-4
> Environment: Windows.
> Maven 2.0.6
> Java 1.5 compiler
>Reporter: Iker Almandoz
>Assignee: Brian Fox
>Priority: Minor
> Attachments: analyze.zip, maven_bug.zip
>
>
> I have 2 projects as seen in the attached files.
> My first project contains a single interface that defines a String constant.
> My second project, uses the String constant from my first project.
> When i try to use dependency:analyze to fail the build as seen below, i can't
> make the system work.
> If i add the dependency from project 2 to project 1, i get:
> [INFO] [dependency:analyze {execution: analyze}]
> [INFO] Used declared dependencies:
> [INFO]None
> [INFO] Used undeclared dependencies:
> [WARNING]None
> [INFO] Unused declared dependencies:
> [INFO]test:project1:jar: 1.0-SNAPSHOT:compile
> [WARNING] Potential problems discovered.
> But if i remove it, i get:
> If i remove the supposedly unused dependency, then I get a compile error:
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Compilation failure
> C:\ASSIA\development\maven_bug\project2\src\main\java\project2\NamesUser.java:[6
> ,24] package project1 does not exist
> Here is the build definition i have...
>
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
>
>
> analyze
> package
>
> analyze
>
>
> true
> false
>
>
>
>
>
>
--
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] Updated: (MINVOKER-21) Clean up IT test output when running mvn clean.
[ http://jira.codehaus.org/browse/MINVOKER-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MINVOKER-21: - Fix Version/s: (was: 1.2) > Clean up IT test output when running mvn clean. > --- > > Key: MINVOKER-21 > URL: http://jira.codehaus.org/browse/MINVOKER-21 > Project: Maven 2.x Invoker Plugin > Issue Type: New Feature >Affects Versions: 1.1 >Reporter: Paul Gier >Assignee: Olivier Lamy > > Not sure if there is an easy way to do this, but it would be nice if the > invoker plugin could be set up so that during a "mvn clean" the target > directories and the build.log created by the integration tests would be > cleaned up. -- 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: (MDEP-152) Analyze main and test dependencies separately
Analyze main and test dependencies separately -- Key: MDEP-152 URL: http://jira.codehaus.org/browse/MDEP-152 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: analyze Affects Versions: 2.0 Reporter: Benjamin Bentmann Assignee: Brian Fox The current design of the maven-dependency-analyzer is mixing apples and oranges. If a POM declares an artifact as a compile time dependency but actually only requires it for test execution, the analysis would be fine because the analyzer ignores scopes. Therefore, I suggest to split the analysis and its report into: - used declared main dependencies - used undeclared main dependencies - unused declared main dependencies - used declared test dependencies - used undeclared test dependencies - unused declared test dependencies Analysis of the main dependencies would only include "target/classes" and artifacts with scope "compile"/"system"/"provided" (similar but not equal to ignoreNonCompile=true). Analysis of the test dependencies would consider "target/test-classes" and all available artifacts. As a special case, the group "unused declared test dependencies" should be post-processed by removing all artifacts whose scope is not "test". Otherwise, many of the main artifacts would be reported here. Finally, a new parameter "excludeTest" should allow to skip the analysis of test dependencies. -- 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: (MINVOKER-24) parameter to use an alternate settings file
parameter to use an alternate settings file --- Key: MINVOKER-24 URL: http://jira.codehaus.org/browse/MINVOKER-24 Project: Maven 2.x Invoker Plugin Issue Type: New Feature Reporter: Olivier Lamy Assignee: John Casey the plugin should support a new parameter in order to use an alternate settings file. -- 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] Updated: (MINVOKER-24) parameter to use an alternate settings file
[ http://jira.codehaus.org/browse/MINVOKER-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MINVOKER-24: - Assignee: Olivier Lamy (was: John Casey) Fix Version/s: 1.2 > parameter to use an alternate settings file > --- > > Key: MINVOKER-24 > URL: http://jira.codehaus.org/browse/MINVOKER-24 > Project: Maven 2.x Invoker Plugin > Issue Type: New Feature >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 1.2 > > > the plugin should support a new parameter in order to use an alternate > settings file. -- 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] Closed: (MINVOKER-24) parameter to use an alternate settings file
[ http://jira.codehaus.org/browse/MINVOKER-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MINVOKER-24. Resolution: Fixed fixed in rev 632679. > parameter to use an alternate settings file > --- > > Key: MINVOKER-24 > URL: http://jira.codehaus.org/browse/MINVOKER-24 > Project: Maven 2.x Invoker Plugin > Issue Type: New Feature >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 1.2 > > > the plugin should support a new parameter in order to use an alternate > settings file. -- 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] Closed: (MNG-3410) Managed versions in plugins are not considered when using them
[ http://jira.codehaus.org/browse/MNG-3410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MNG-3410. --- Assignee: Carlos Sanchez Resolution: Fixed Fix Version/s: 2.1 2.1-alpha-1 2.0.9 > Managed versions in plugins are not considered when using them > -- > > Key: MNG-3410 > URL: http://jira.codehaus.org/browse/MNG-3410 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.8, 2.1-alpha-1, 2.1 >Reporter: Carlos Sanchez >Assignee: Carlos Sanchez > Fix For: 2.0.9, 2.1-alpha-1, 2.1 > > Attachments: MNG-3410.patch > > > If you build and install a plugin with managed versions that affect plugin > transitive dependencies, when it's used the dependency management is ignored > If the dependency management affects the plugin direct dependecies it works > properly because the information is merged. > eg. > Plugin A depends on jar B that depends on jar C[1.0] > A dependencyManagement explicitly forces C[2.0], you build and install using > C[2.0] in the classpath > If you use plugin A in your pom it will be used with C version 1.0 -- 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] Closed: (MSHADE-9) failure to shade/relocate plexus-archiver (interfaces not properly relocated)
[
http://jira.codehaus.org/browse/MSHADE-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MSHADE-9.
-
Assignee: Brett Porter
Resolution: Cannot Reproduce
Fix Version/s: (was: 1.0-beta-2)
1.0-beta-1
cannot reproduce against 1.0-beta-1
I went back to the old surefire that used archiver and tried this, getting this
from javap:
Compiled from "AsiExtraField.java"
public class
org.apache.maven.surefire.booter.shade.org.codehaus.plexus.archiver.zip.AsiExtraField
extends java.lang.Object implements
org.apache.maven.surefire.booter.shade.org.codehaus.plexus.archiver.zip.ZipExtraField,org.apache.maven.surefire.booter.shade.org.codehaus.plexus.archiver.UnixStat,java.lang.Cloneable{
> failure to shade/relocate plexus-archiver (interfaces not properly relocated)
> -
>
> Key: MSHADE-9
> URL: http://jira.codehaus.org/browse/MSHADE-9
> Project: Maven 2.x Shade Plugin
> Issue Type: Bug
>Affects Versions: 1.0-alpha-15
>Reporter: Dan Fabulich
>Assignee: Brett Porter
>Priority: Blocker
> Fix For: 1.0-beta-1
>
> Attachments: mshade9-repro.diff
>
>
> I tried using the shade plugin with surefire, to shade/relocate
> plexus-archiver. I'm trying to relocate its package to be
> org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver. It took
> several tries due to MSHADE-5, but even when it finally "worked", it failed
> to modify plexus-archiver correctly.
> org.codehaus.plexus.archiver.zip.AsiExtraField implements
> org.codehaus.plexus.archiver.zip.ZipExtraField. But when I try to run
> p-archiver after shading it, I get this exception:
> java.lang.ExceptionInInitializerError
> at
> org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ZipEntry.getCentralDirectoryExtra(ZipEntry.java:386)
> at
> org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ZipOutputStream.writeCentralFileHeader(ZipOutputStream.java:769)
> at
> org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ZipOutputStream.finish(ZipOutputStream.java:320)
> at
> org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ZipOutputStream.close(ZipOutputStream.java:542)
> at
> org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:378)
> at
> org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchive(AbstractZipArchiver.java:250)
> at
> org.apache.maven.surefire.booter.ForkConfiguration.createJar(ForkConfiguration.java:264)
> [snip]
> Caused by: java.lang.RuntimeException: class
> org.codehaus.plexus.archiver.zip.AsiExtraField doesn't implement ZipExtraField
> at
> org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ExtraFieldUtils.register(ExtraFieldUtils.java:63)
> at
> org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ExtraFieldUtils.(ExtraFieldUtils.java:43)
> ... 31 more
> My decompiler (DJ) shows that the interfaces were partially but not entirely
> shaded correctly:
> package org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip;
> import java.util.zip.CRC32;
> import java.util.zip.ZipException;
> import org.codehaus.plexus.archiver.UnixStat;
> import org.codehaus.plexus.archiver.zip.ZipExtraField;
> import org.codehaus.plexus.archiver.zip.ZipLong;
> import org.codehaus.plexus.archiver.zip.ZipShort;
> // Referenced classes of package
> org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip:
> //ZipExtraField, ZipShort, ZipLong
> public class AsiExtraField
> implements
> org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ZipExtraField,
> org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.UnixStat,
> Cloneable
> {
> [...]
> }
--
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] Updated: (MSHADE-8) Shade plugin will cheerfully relocate your own classes
[ http://jira.codehaus.org/browse/MSHADE-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MSHADE-8: -- Fix Version/s: (was: 1.0-beta-2) > Shade plugin will cheerfully relocate your own classes > -- > > Key: MSHADE-8 > URL: http://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. - 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
