[jira] (MEAR-73) Property to disable transitive dependencies resolving
[
https://jira.codehaus.org/browse/MEAR-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=336035#comment-336035
]
Max Schaefer commented on MEAR-73:
--
This would really be an appreciated feature because it would save me to
configure all my transitive dependency excludes in pom.xml i.e. would increase
readability: less configuration and
maintainability: no need to check for new transitive dependencies on update of
a module
> Property to disable transitive dependencies resolving
> -
>
> Key: MEAR-73
> URL: https://jira.codehaus.org/browse/MEAR-73
> Project: Maven Ear Plugin
> Issue Type: Improvement
>Reporter: Thomas Hart
>Assignee: Stéphane Nicoll
> Attachments: ear.jpg, patch2.txt, patch.txt
>
>
> We have ears with a lot of modules. So the transitive dependencies are very
> huge and to exclude all these with {{true}} is no
> option. Also to mark these dependencies with optional is no way. It is
> possible to create a new property for that?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-673) Add support for "delimiters" and "useDefaultDelimiters" like the maven-resources-plugin 2.4 has
Iain Coulter created MASSEMBLY-673:
--
Summary: Add support for "delimiters" and "useDefaultDelimiters"
like the maven-resources-plugin 2.4 has
Key: MASSEMBLY-673
URL: https://jira.codehaus.org/browse/MASSEMBLY-673
Project: Maven Assembly Plugin
Issue Type: Improvement
Components: filtering
Affects Versions: 2.4
Reporter: Iain Coulter
The maven-resources-plugin 2.4 added "delimiters" and "useDefaultDelimiters"
which allows the default delimiter strings to be disabled and allows custom
delimiters to be used.
In a project which is packaging ant files or other files which use a lot of
${*} type variables specifying a custom delimiter and disabling the defaults
would be more more usefull than the other option at present "escapeString"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-674) escapeString using \ does not work correctly
Iain Coulter created MASSEMBLY-674:
--
Summary: escapeString using \ does not work correctly
Key: MASSEMBLY-674
URL: https://jira.codehaus.org/browse/MASSEMBLY-674
Project: Maven Assembly Plugin
Issue Type: Bug
Components: filtering
Reporter: Iain Coulter
Attachments: escapeStringBug.zip
Using \ does not correctly when dealing with
case where previous text is also a \.
attached pom,test and assembly.xml show what happens. The follwoing scenario is
currently fail: (varible=Hello)
C:\path\\${variable} converted to C:\path\\Hello
I would of expected: C:\path\${variable}
The following does work but is not exactly as required as it means you get get
two \'s
C:\path\\\${variable} converted to C:\path\\${variable}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-177) Jars from previous execution are copied into ear
[
https://jira.codehaus.org/browse/MEAR-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel updated MEAR-177:
---
Attachment: mear-177.zip
> Jars from previous execution are copied into ear
>
>
> Key: MEAR-177
> URL: https://jira.codehaus.org/browse/MEAR-177
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Pavel
> Attachments: mear-177.zip
>
>
> If several executions for ear plugn configured and each contain own jarModule
> than every next execution will contain jar from previous.
> For example following project (see attachment):
> {code}
> root/
> - ear
> - jar1
> - jar2
> {code}
> Ear contain two executions
> {code}
>
> jar1
> package
>
> jar1
>
>
> example
> jar1
>
>
>
> ear
>
>
> jar2
> package
>
> jar2
>
>
> example
> jar2
>
>
>
> ear
>
> {code}
> But resulting ear-0.0.1-SNAPSHOT-jar2.ear contain both jar1.jar and jar2.jar
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-177) Jars from previous execution are copied into ear
Pavel created MEAR-177:
--
Summary: Jars from previous execution are copied into ear
Key: MEAR-177
URL: https://jira.codehaus.org/browse/MEAR-177
Project: Maven Ear Plugin
Issue Type: Bug
Affects Versions: 2.8
Reporter: Pavel
Attachments: mear-177.zip
If several executions for ear plugn configured and each contain own jarModule
than every next execution will contain jar from previous.
For example following project (see attachment):
{code}
root/
- ear
- jar1
- jar2
{code}
Ear contain two executions
{code}
jar1
package
jar1
example
jar1
ear
jar2
package
jar2
example
jar2
ear
{code}
But resulting ear-0.0.1-SNAPSHOT-jar2.ear contain both jar1.jar and jar2.jar
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-177) Jars from previous execution are copied into ear
[
https://jira.codehaus.org/browse/MEAR-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=336047#comment-336047
]
Jörg Schaible commented on MEAR-177:
This is exactly how it has to work. It is your fault if you use the same work
directory for every execution.
> Jars from previous execution are copied into ear
>
>
> Key: MEAR-177
> URL: https://jira.codehaus.org/browse/MEAR-177
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Pavel
> Attachments: mear-177.zip
>
>
> If several executions for ear plugn configured and each contain own jarModule
> than every next execution will contain jar from previous.
> For example following project (see attachment):
> {code}
> root/
> - ear
> - jar1
> - jar2
> {code}
> Ear contain two executions
> {code}
>
> jar1
> package
>
> jar1
>
>
> example
> jar1
>
>
>
> ear
>
>
> jar2
> package
>
> jar2
>
>
> example
> jar2
>
>
>
> ear
>
> {code}
> But resulting ear-0.0.1-SNAPSHOT-jar2.ear contain both jar1.jar and jar2.jar
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-177) Jars from previous execution are copied into ear
[
https://jira.codehaus.org/browse/MEAR-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=336049#comment-336049
]
Pavel commented on MEAR-177:
Thanks, using custom working directories works.
But with custom directories application.xml generation does not work, because
it generates into default output directory and can't find it during package.
Using custom application.xml solves this.
> Jars from previous execution are copied into ear
>
>
> Key: MEAR-177
> URL: https://jira.codehaus.org/browse/MEAR-177
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Pavel
> Attachments: mear-177.zip
>
>
> If several executions for ear plugn configured and each contain own jarModule
> than every next execution will contain jar from previous.
> For example following project (see attachment):
> {code}
> root/
> - ear
> - jar1
> - jar2
> {code}
> Ear contain two executions
> {code}
>
> jar1
> package
>
> jar1
>
>
> example
> jar1
>
>
>
> ear
>
>
> jar2
> package
>
> jar2
>
>
> example
> jar2
>
>
>
> ear
>
> {code}
> But resulting ear-0.0.1-SNAPSHOT-jar2.ear contain both jar1.jar and jar2.jar
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-432) dependency:unpack documents 'artifact', but does not support pomless execution
Benson Margulies created MDEP-432: - Summary: dependency:unpack documents 'artifact', but does not support pomless execution Key: MDEP-432 URL: https://jira.codehaus.org/browse/MDEP-432 Project: Maven Dependency Plugin Issue Type: Bug Components: unpack Affects Versions: 2.8 Reporter: Benson Margulies http://maven.apache.org/plugins/maven-dependency-plugin/unpack-mojo.html#artifact implies the use from command-line, but this goal refuses to run without a POM. Either the parameter should be documented as deprecated, or command-line execution should work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEJB-62) "This version of the EJB Plugin uses Maven Archiver 2.4" hardcoded in Javadoc
Anders Hammar created MEJB-62: - Summary: "This version of the EJB Plugin uses Maven Archiver 2.4" hardcoded in Javadoc Key: MEJB-62 URL: https://jira.codehaus.org/browse/MEJB-62 Project: Maven EJB Plugin Issue Type: Task Affects Versions: 2.3 Environment: n/a Reporter: Anders Hammar Priority: Trivial In the Javadoc a comment about which version of Maven Archiver is used is hardcoded. It states v2.4 but in fact v2.4.1 is used, which proves the point that this is a bad idea. This Javadoc comment should be removed! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-673) Add support for "delimiters" and "useDefaultDelimiters" like the maven-resources-plugin 2.4 has
[
https://jira.codehaus.org/browse/MASSEMBLY-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iain Coulter updated MASSEMBLY-673:
---
Attachment: MASSEMBLY-673-patch.txt
Patch against latest code on trunk to fix these, plus two test cases to test
new feature
> Add support for "delimiters" and "useDefaultDelimiters" like the
> maven-resources-plugin 2.4 has
> ---
>
> Key: MASSEMBLY-673
> URL: https://jira.codehaus.org/browse/MASSEMBLY-673
> Project: Maven Assembly Plugin
> Issue Type: Improvement
> Components: filtering
>Affects Versions: 2.4
>Reporter: Iain Coulter
> Attachments: MASSEMBLY-673-patch.txt
>
>
> The maven-resources-plugin 2.4 added "delimiters" and "useDefaultDelimiters"
> which allows the default delimiter strings to be disabled and allows custom
> delimiters to be used.
> In a project which is packaging ant files or other files which use a lot of
> ${*} type variables specifying a custom delimiter and disabling the defaults
> would be more more usefull than the other option at present "escapeString"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-575) Test run as JUnit3 test when extends TestCase - TestNG annotations are ignored
[
https://jira.codehaus.org/browse/SUREFIRE-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=336066#comment-336066
]
David Forsman commented on SUREFIRE-575:
Any work planned on this one - it's been four years?
Even nastier - if @BeforeClass cats exception Surefire will silently "ignore"
the complete test class.
We ran into this during in our project. Maven test in our CI have silently
ignored whole classes.
I regard this as critical since it is so silent and have big impact - tests not
run.
public class JunitTest {
@org.junit.BeforeClass
public static void beforeClass() {
// Silently swallowed by surefire testng!
throw new NullPointerException();
}
@org.junit.Test
public void junitMe() {
// never reach here?!
throw new NullPointerException("Never get here!!");
}
}
> Test run as JUnit3 test when extends TestCase - TestNG annotations are ignored
> --
>
> Key: SUREFIRE-575
> URL: https://jira.codehaus.org/browse/SUREFIRE-575
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 2.4.3
> Environment: Sun JDK 1.6.0_16, Maven 2.2.1
>Reporter: Przemyslaw Wojnowski
> Attachments: DaoTest.java, pom.xml
>
>
> TestNG test is run as JUnit3 test when it inherits from JUnit's TestCase
> class.
> When inheritance is removed, then test is run as TestNG test.
> In both cases in Eclipse it is run as TestNG test (BeforeClass and AfterClass
> are called).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-575) Test run as JUnit3 test when extends TestCase - TestNG annotations are ignored
[
https://jira.codehaus.org/browse/SUREFIRE-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=336066#comment-336066
]
David Forsman edited comment on SUREFIRE-575 at 11/20/13 11:31 AM:
---
Any work planned on this one - it's been four years?
Even nastier - if @BeforeClass cats exception Surefire will silently "ignore"
the complete test class.
We ran into this during in our project. Maven test in our CI have silently
ignored whole classes.
I regard this as critical since it is so silent and have big impact - tests not
run.
public class JunitTest {
// Silently swallowed by surefire testng!
@org.junit.BeforeClass
public static void beforeClass() {
throw new NullPointerException();
}
// never reach here?!
@org.junit.Test
public void junitMe() {
throw new NullPointerException("Never get here!!");
}
}
was (Author: achoice):
Any work planned on this one - it's been four years?
Even nastier - if @BeforeClass cats exception Surefire will silently "ignore"
the complete test class.
We ran into this during in our project. Maven test in our CI have silently
ignored whole classes.
I regard this as critical since it is so silent and have big impact - tests not
run.
public class JunitTest {
@org.junit.BeforeClass
public static void beforeClass() {
// Silently swallowed by surefire testng!
throw new NullPointerException();
}
@org.junit.Test
public void junitMe() {
// never reach here?!
throw new NullPointerException("Never get here!!");
}
}
> Test run as JUnit3 test when extends TestCase - TestNG annotations are ignored
> --
>
> Key: SUREFIRE-575
> URL: https://jira.codehaus.org/browse/SUREFIRE-575
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 2.4.3
> Environment: Sun JDK 1.6.0_16, Maven 2.2.1
>Reporter: Przemyslaw Wojnowski
> Attachments: DaoTest.java, pom.xml
>
>
> TestNG test is run as JUnit3 test when it inherits from JUnit's TestCase
> class.
> When inheritance is removed, then test is run as TestNG test.
> In both cases in Eclipse it is run as TestNG test (BeforeClass and AfterClass
> are called).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-575) Test run as JUnit3 test when extends TestCase - TestNG annotations are ignored
[
https://jira.codehaus.org/browse/SUREFIRE-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=336066#comment-336066
]
David Forsman edited comment on SUREFIRE-575 at 11/20/13 11:32 AM:
---
Any work planned on this one - it's been four years?
Even nastier - if @BeforeClass cats exception Surefire will silently "ignore"
the complete test class.
We ran into this during in our project where we have both TestNG and JUnit.
Maven test in our CI have silently ignored whole classes.
I regard this as critical since it is so silent and have big impact - tests not
run.
public class JunitTest {
// Silently swallowed by surefire testng!
@org.junit.BeforeClass
public static void beforeClass() {
throw new NullPointerException();
}
// never reach here?!
@org.junit.Test
public void junitMe() {
throw new NullPointerException("Never get here!!");
}
}
was (Author: achoice):
Any work planned on this one - it's been four years?
Even nastier - if @BeforeClass cats exception Surefire will silently "ignore"
the complete test class.
We ran into this during in our project. Maven test in our CI have silently
ignored whole classes.
I regard this as critical since it is so silent and have big impact - tests not
run.
public class JunitTest {
// Silently swallowed by surefire testng!
@org.junit.BeforeClass
public static void beforeClass() {
throw new NullPointerException();
}
// never reach here?!
@org.junit.Test
public void junitMe() {
throw new NullPointerException("Never get here!!");
}
}
> Test run as JUnit3 test when extends TestCase - TestNG annotations are ignored
> --
>
> Key: SUREFIRE-575
> URL: https://jira.codehaus.org/browse/SUREFIRE-575
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 2.4.3
> Environment: Sun JDK 1.6.0_16, Maven 2.2.1
>Reporter: Przemyslaw Wojnowski
> Attachments: DaoTest.java, pom.xml
>
>
> TestNG test is run as JUnit3 test when it inherits from JUnit's TestCase
> class.
> When inheritance is removed, then test is run as TestNG test.
> In both cases in Eclipse it is run as TestNG test (BeforeClass and AfterClass
> are called).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-673) Add support for "delimiters" and "useDefaultDelimiters" like the maven-resources-plugin 2.4 has
[
https://jira.codehaus.org/browse/MASSEMBLY-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iain Coulter updated MASSEMBLY-673:
---
Attachment: MASSEMBLY-673.zip
Sample test files and pom to demonstrate new options
> Add support for "delimiters" and "useDefaultDelimiters" like the
> maven-resources-plugin 2.4 has
> ---
>
> Key: MASSEMBLY-673
> URL: https://jira.codehaus.org/browse/MASSEMBLY-673
> Project: Maven Assembly Plugin
> Issue Type: Improvement
> Components: filtering
>Affects Versions: 2.4
>Reporter: Iain Coulter
> Attachments: MASSEMBLY-673-patch.txt, MASSEMBLY-673.zip
>
>
> The maven-resources-plugin 2.4 added "delimiters" and "useDefaultDelimiters"
> which allows the default delimiter strings to be disabled and allows custom
> delimiters to be used.
> In a project which is packaging ant files or other files which use a lot of
> ${*} type variables specifying a custom delimiter and disabling the defaults
> would be more more usefull than the other option at present "escapeString"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-575) Test run as JUnit3 test when extends TestCase - TestNG annotations are ignored
[ https://jira.codehaus.org/browse/SUREFIRE-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=336070#comment-336070 ] Kristian Rosenvold commented on SUREFIRE-575: - I doubt this issue will be fixed unless someone submits a patch. As for the exception in @BeforeClass, please file a separate issue. On a side note, I am quite certain we have a test case for the exception in beforeClass that is for the junit 4.7 provider. So I assume this problem applies to the old junit 4 provider. This makes it no less serious, but you can probably work around by switching to the 4.7 provider. > Test run as JUnit3 test when extends TestCase - TestNG annotations are ignored > -- > > Key: SUREFIRE-575 > URL: https://jira.codehaus.org/browse/SUREFIRE-575 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.4.3 > Environment: Sun JDK 1.6.0_16, Maven 2.2.1 >Reporter: Przemyslaw Wojnowski > Attachments: DaoTest.java, pom.xml > > > TestNG test is run as JUnit3 test when it inherits from JUnit's TestCase > class. > When inheritance is removed, then test is run as TestNG test. > In both cases in Eclipse it is run as TestNG test (BeforeClass and AfterClass > are called). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-1378) Make dependencies of test-jars transitive
[ https://jira.codehaus.org/browse/MNG-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=336071#comment-336071 ] Hugo Garza commented on MNG-1378: - I was able to solve this by moving my test dependencies into the parent POM that both projects share, but this isn't possible in every case. I guess the only thing I can do for now is to cast my vote for hopefully getting this feature implemented. I just learned about test-jar and was excited that it would just work but then I got my ClassNotFoundException and realized it was because of my missing transitive test dependencies. > Make dependencies of test-jars transitive > - > > Key: MNG-1378 > URL: https://jira.codehaus.org/browse/MNG-1378 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0 >Reporter: Mark Hobson > Fix For: Issues to be reviewed for 3.x > > Attachments: mng1378.tar.gz > > > test-jar transitive dependencies are calculated as per compile scope rather > than test scope. > The situation is demonstrated nicely in it0077: > * module sub1 has a test-scoped dependency of commons-lang > * module sub2 has a test-scoped dependency of sub1 test-jar > sub2 tests should inherit the commons-lang transitive dependency. For > example: > Index: > maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java > === > --- > maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java > (revision > 328307) > +++ > maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java > (working > copy) > @@ -1,6 +1,7 @@ > package org.apache.maven.it0077; > import junit.framework.TestCase; > +import org.apache.commons.lang.BooleanUtils; > public class PersonTwoTest > extends PersonTest > Results in: > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Compilation failure > c:\maven-components\maven-core-it\it0077\sub2\src\test\java\org\apache\maven\it0077\PersonTwoTest.java:[4,31] > package org.apache.commons.lang does not exist -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-177) Jars from previous execution are copied into ear
[
https://jira.codehaus.org/browse/MEAR-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MEAR-177.
---
Resolution: Not A Bug
Assignee: Robert Scholte
> Jars from previous execution are copied into ear
>
>
> Key: MEAR-177
> URL: https://jira.codehaus.org/browse/MEAR-177
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Pavel
>Assignee: Robert Scholte
> Attachments: mear-177.zip
>
>
> If several executions for ear plugn configured and each contain own jarModule
> than every next execution will contain jar from previous.
> For example following project (see attachment):
> {code}
> root/
> - ear
> - jar1
> - jar2
> {code}
> Ear contain two executions
> {code}
>
> jar1
> package
>
> jar1
>
>
> example
> jar1
>
>
>
> ear
>
>
> jar2
> package
>
> jar2
>
>
> example
> jar2
>
>
>
> ear
>
> {code}
> But resulting ear-0.0.1-SNAPSHOT-jar2.ear contain both jar1.jar and jar2.jar
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-158) Allow shading of test jar
[ https://jira.codehaus.org/browse/MSHADE-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=336072#comment-336072 ] David Pilato commented on MSHADE-158: - Hey Olivier, I tried your branch but it was not working as I was expecting. So I did a patch on top of your branch here: https://github.com/olamy/maven-plugins/pull/1 With this, I get the shaded test jar as I was expecting. I did test this test jar on another project and everything went fine. Let me know if I can help more. Thanks for looking into this! > Allow shading of test jar > - > > Key: MSHADE-158 > URL: https://jira.codehaus.org/browse/MSHADE-158 > Project: Maven Shade Plugin > Issue Type: Improvement >Reporter: David Pilato > > Heya, > I'm creating a project which builds two artifacts: > * project.jar > * project-tests.jar > I'm using shade plugin to shade dependencies with package relocation. For > example, org.apache goes to com.company.apache package. > So my project.jar contains relocated classes (com.company.apache). > But my project-tests.jar still have links to original packages (and > dependencies). > Could it be possible to have an option that shade tests jar as well? > Thanks! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-158) Allow shading of test jar
[ https://jira.codehaus.org/browse/MSHADE-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MSHADE-158. --- Resolution: Fixed Fix Version/s: 2.2 Assignee: Olivier Lamy fixed http://svn.apache.org/r1543990 Thanks! > Allow shading of test jar > - > > Key: MSHADE-158 > URL: https://jira.codehaus.org/browse/MSHADE-158 > Project: Maven Shade Plugin > Issue Type: Improvement >Reporter: David Pilato >Assignee: Olivier Lamy > Fix For: 2.2 > > > Heya, > I'm creating a project which builds two artifacts: > * project.jar > * project-tests.jar > I'm using shade plugin to shade dependencies with package relocation. For > example, org.apache goes to com.company.apache package. > So my project.jar contains relocated classes (com.company.apache). > But my project-tests.jar still have links to original packages (and > dependencies). > Could it be possible to have an option that shade tests jar as well? > Thanks! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
