[jira] (MJAR-168) Update to latest plexus-archiver
[ https://jira.codehaus.org/browse/MJAR-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise reopened MJAR-168: -- Assignee: Karl-Heinz Marbaise Updated to newest plexus-archiver version 2.4.4 > Update to latest plexus-archiver > > > Key: MJAR-168 > URL: https://jira.codehaus.org/browse/MJAR-168 > Project: Maven JAR Plugin > Issue Type: Improvement >Affects Versions: 2.4 > Environment: Any Unix system that has some ldap groups >Reporter: Osvaldo Doederlein >Assignee: Karl-Heinz Marbaise > Fix For: 2.5 > > > maven-jar-plugin regresses horribly with JDK 7 compared to JDK 6. The cause > is well known and already fixed in plexus-io, PLXCOMP-203, but the fixed > version of plexus-io has yet to be used by maven-jar-plugin. Here's some > benchmark from y project: > Standard build with maven 3.0.x or 3.1-alpha1: > [INFO] Total time: 3:03.048s > [INFO] Finished at: Tue Jul 09 15:22:02 EDT 2013 > [INFO] Final Memory: 40M/221M > After rebuilding maven-jar-plugin, changing its POM to use plexus-archiver > 2.4.1 (which in turn uses the latest plexus-io): > [INFO] Total time: 41.786s > [INFO] Finished at: Tue Jul 09 15:28:26 EDT 2013 > [INFO] Final Memory: 47M/403M > It seems like a trivial fix, all maven-jar unit tests pass. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAR-168) Update to latest plexus-archiver
[ https://jira.codehaus.org/browse/MJAR-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MJAR-168. Resolution: Fixed Fixed in [r1602806|http://svn.apache.org/r1602806] > Update to latest plexus-archiver > > > Key: MJAR-168 > URL: https://jira.codehaus.org/browse/MJAR-168 > Project: Maven JAR Plugin > Issue Type: Improvement >Affects Versions: 2.4 > Environment: Any Unix system that has some ldap groups >Reporter: Osvaldo Doederlein >Assignee: Karl-Heinz Marbaise > Fix For: 2.5 > > > maven-jar-plugin regresses horribly with JDK 7 compared to JDK 6. The cause > is well known and already fixed in plexus-io, PLXCOMP-203, but the fixed > version of plexus-io has yet to be used by maven-jar-plugin. Here's some > benchmark from y project: > Standard build with maven 3.0.x or 3.1-alpha1: > [INFO] Total time: 3:03.048s > [INFO] Finished at: Tue Jul 09 15:22:02 EDT 2013 > [INFO] Final Memory: 40M/221M > After rebuilding maven-jar-plugin, changing its POM to use plexus-archiver > 2.4.1 (which in turn uses the latest plexus-io): > [INFO] Total time: 41.786s > [INFO] Finished at: Tue Jul 09 15:28:26 EDT 2013 > [INFO] Final Memory: 47M/403M > It seems like a trivial fix, all maven-jar unit tests pass. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAR-176) Usage page should (only) describe default behavior
[
https://jira.codehaus.org/browse/MJAR-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise reassigned MJAR-176:
Assignee: Karl-Heinz Marbaise
> Usage page should (only) describe default behavior
> ---
>
> Key: MJAR-176
> URL: https://jira.codehaus.org/browse/MJAR-176
> Project: Maven JAR Plugin
> Issue Type: Improvement
>Reporter: Robert Scholte
>Assignee: Karl-Heinz Marbaise
> Fix For: 2.5
>
>
> If one is pretty new to Maven and just wants to create a jar (still the most
> used packaging type), he'll probably go to the docs of this plugin. This
> means that the usage page should make it immediately clear. Now it jumps fast
> to finetuning the configuration.
> Instead:
> - describe standard folder structure (start with only {{src/main/java}} and
> {{src/main/resources}})
> - describe minimum pom (in this case GAV + modelVersion, saying {{jar}} is
> the default packaging type)
> - describe the {{package}} goal.
> Configuration specifics should be moved to example pages.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAR-168) Update to latest plexus-archiver
[ https://jira.codehaus.org/browse/MJAR-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348103#comment-348103 ] Karl-Heinz Marbaise commented on MJAR-168: -- Update plexus-archiver to 2.4.4. > Update to latest plexus-archiver > > > Key: MJAR-168 > URL: https://jira.codehaus.org/browse/MJAR-168 > Project: Maven JAR Plugin > Issue Type: Improvement >Affects Versions: 2.4 > Environment: Any Unix system that has some ldap groups >Reporter: Osvaldo Doederlein > Fix For: 2.5 > > > maven-jar-plugin regresses horribly with JDK 7 compared to JDK 6. The cause > is well known and already fixed in plexus-io, PLXCOMP-203, but the fixed > version of plexus-io has yet to be used by maven-jar-plugin. Here's some > benchmark from y project: > Standard build with maven 3.0.x or 3.1-alpha1: > [INFO] Total time: 3:03.048s > [INFO] Finished at: Tue Jul 09 15:22:02 EDT 2013 > [INFO] Final Memory: 40M/221M > After rebuilding maven-jar-plugin, changing its POM to use plexus-archiver > 2.4.1 (which in turn uses the latest plexus-io): > [INFO] Total time: 41.786s > [INFO] Finished at: Tue Jul 09 15:28:26 EDT 2013 > [INFO] Final Memory: 47M/403M > It seems like a trivial fix, all maven-jar unit tests pass. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-180) Artifacts with same ID are ignored in packaging
[
https://jira.codehaus.org/browse/MEAR-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise updated MEAR-180:
-
Fix Version/s: 2.10
> Artifacts with same ID are ignored in packaging
> ---
>
> Key: MEAR-180
> URL: https://jira.codehaus.org/browse/MEAR-180
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Reto Hablützel
>Assignee: Karl-Heinz Marbaise
> Fix For: 2.10
>
> Attachments: ear-silent-ignore.zip
>
>
> The attached sample consists of an ear that references two other projects,
> both of which have the *same artifactId and the same versionId*, but *not the
> same groupId*.
> Both are to be packaged in the lib folder, but only the first will make it
> in, because the maven ear plugin identifies them only by their artifactId and
> version. This means that when it sees the second dependency, it thinks it was
> already in there.
> Note that I already brought this up on the mailing list:
> https://mail-archives.apache.org/mod_mbox/maven-users/201402.mbox/browser
> Follow these steps to recreate the issue based on the attached sample:
> {quote}
> Install 'utilities' project in 'collections':
> collections/utilities> mvn install
> Install 'utilities' project in 'email':
> email/utilities> mvn install
> Package 'ear' project:
> ear> mvn package
> Look at contents of ear and notice how only one jar is included:
> ear> unzip -v target/ear-1.0.0.ear
> Now use the debug flag to see why only one gets included:
> ear> mvn --debug clean package
> Partial output:
> \[INFO\] Copying artifact \[jar:ch.rethab.email:utilities:1.0.0\] to
> \[utilities-1.0.0.jar\]
> \[DEBUG\] Skipping artifact \[jar:ch.rethab.collections:utilities:1.0.0\],
> as it is already up to date at \[utilities-1.0.0.jar\]
> {quote}
> Note that this sample shows how dependent libraries are ignored, but I think
> it is also an issue if you have two ejbs with the same name and version -
> though that is probably far less likely.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5394) Document how to do logging in a plugin
[ https://jira.codehaus.org/browse/MNG-5394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348102#comment-348102 ] Herve Boutemy commented on MNG-5394: we just need to replace "long enough now" with a precise Maven version prerequisite: I don't remember precisely > Document how to do logging in a plugin > -- > > Key: MNG-5394 > URL: https://jira.codehaus.org/browse/MNG-5394 > Project: Maven 2 & 3 > Issue Type: Task > Components: Logging > Environment: n/a >Reporter: Anders Hammar > > We should document the different logging options in a Maven plugin that exist > and differences/benefits. So the main audience is not Maven users, but plugin > developers and I guess this doc should go in under the Plugin Developer > Center section. > There is currently a "Maven 3.1.x logging" page, but that one is for end > users and a different story than what this ticket is about. > A few things that the page should cover: > * Plexus logger & SLF4J > * Any compatibility problems using SLF4J with older Maven versions? > * A code example including an example pom depicting dependencies > * How to establish logging separated from Maven's (fork a JVM?) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAR-167) skipIfEmpty outputs incorrect logging nessage
[
https://jira.codehaus.org/browse/MJAR-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise closed MJAR-167.
Resolution: Fixed
Assignee: Karl-Heinz Marbaise
Fixed in [1602802|http://svn.apache.org/r1602802]
> skipIfEmpty outputs incorrect logging nessage
> -
>
> Key: MJAR-167
> URL: https://jira.codehaus.org/browse/MJAR-167
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Stephen Colebourne
>Assignee: Karl-Heinz Marbaise
>Priority: Trivial
> Fix For: 2.5
>
>
> The 'skipIfEmpty' flag added in MJAR-139 has the wrong debugging message
> (refers to test-jar, not jar):
> {code}
> [INFO] --- maven-jar-plugin:2.4:jar (jar) @ og-server ---
> [INFO] Skipping packaging of the test-jar
> [INFO]
> [INFO] --- maven-jar-plugin:2.4:test-jar (test-jar) @ og-server ---
> [INFO] Skipping packaging of the test-jar
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5594) Show current/total project number in reactor during build
[
https://jira.codehaus.org/browse/MNG-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348100#comment-348100
]
Claus Ibsen commented on MNG-5594:
--
Maybe it can show the number of already build modules, so for parallel builds
it can become more useful.
Total modules: 79 (built: 17, in progress: 4)
Also its actually great if there is a duration as well, as when you log at
outputs from CI servers you do know easily know how long time it has been since
the build started that this module is being built and tested.
Total modules: 79 (built: 17, in progress: 4)
Elapsed: 16m23s
What you need is just a time since the CI job started. As sometimes you know
that the build usually takes 37m, and so if the duration is at 16m, then there
is about 20m still.
> Show current/total project number in reactor during build
> -
>
> Key: MNG-5594
> URL: https://jira.codehaus.org/browse/MNG-5594
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: General
>Affects Versions: 3.2.x
>Reporter: Grzegorz Grzybek
>Priority: Minor
> Attachments: project-progress.diff
>
>
> While building long projects, containing hundreds of modules it would be nice
> to see how far did we get.
> For example, the build might look like this:
> {noformat}
> ...
> [INFO]
>
> [INFO] Building Maven Compat 3.2.2-SNAPSHOT (11/13)
> [INFO]
>
> [INFO]
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Maven Embedder 3.2.2-SNAPSHOT (12/13)
> [INFO]
>
> [INFO]
> ...
> {noformat}
> Please find attached a naive implementation here: [^project-progress.diff].
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5594) Show current/total project number in reactor during build
[
https://jira.codehaus.org/browse/MNG-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348099#comment-348099
]
Grzegorz Grzybek commented on MNG-5594:
---
Thanks for looking into this.
Sure - with parallel build it's useless, but it helps when I have ~20 minutes
build and I want to look at the console to see how far I got.
Maybe it'd be good to think about something similar to log4j/logback's
"pattern" for this header line? (using placeholders for project's name,
artifactId, total, current, etc.)
regards
Grzegorz
> Show current/total project number in reactor during build
> -
>
> Key: MNG-5594
> URL: https://jira.codehaus.org/browse/MNG-5594
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: General
>Affects Versions: 3.2.x
>Reporter: Grzegorz Grzybek
>Priority: Minor
> Attachments: project-progress.diff
>
>
> While building long projects, containing hundreds of modules it would be nice
> to see how far did we get.
> For example, the build might look like this:
> {noformat}
> ...
> [INFO]
>
> [INFO] Building Maven Compat 3.2.2-SNAPSHOT (11/13)
> [INFO]
>
> [INFO]
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Maven Embedder 3.2.2-SNAPSHOT (12/13)
> [INFO]
>
> [INFO]
> ...
> {noformat}
> Please find attached a naive implementation here: [^project-progress.diff].
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MEAR-180) Artifacts with same ID are ignored in packaging
[
https://jira.codehaus.org/browse/MEAR-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Reto Hablützel reopened MEAR-180:
-
Hi, the basic problem is that the maven ear plugin sees certain artifacts as
the same and thus does not include them in the ear although they are in fact
not the same. This happens because it identifies them only by their artifactId
and version, which is not enough to identify a maven artifact - the groupId
should be considered as well.
There are surely ways to work around this, such as the one pointed out by you,
but the general problem remains the same.
Please note that this issue has been discussed on the mailing list and has been
described as a flaw by other users as well.
> Artifacts with same ID are ignored in packaging
> ---
>
> Key: MEAR-180
> URL: https://jira.codehaus.org/browse/MEAR-180
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Reto Hablützel
>Assignee: Karl-Heinz Marbaise
> Attachments: ear-silent-ignore.zip
>
>
> The attached sample consists of an ear that references two other projects,
> both of which have the *same artifactId and the same versionId*, but *not the
> same groupId*.
> Both are to be packaged in the lib folder, but only the first will make it
> in, because the maven ear plugin identifies them only by their artifactId and
> version. This means that when it sees the second dependency, it thinks it was
> already in there.
> Note that I already brought this up on the mailing list:
> https://mail-archives.apache.org/mod_mbox/maven-users/201402.mbox/browser
> Follow these steps to recreate the issue based on the attached sample:
> {quote}
> Install 'utilities' project in 'collections':
> collections/utilities> mvn install
> Install 'utilities' project in 'email':
> email/utilities> mvn install
> Package 'ear' project:
> ear> mvn package
> Look at contents of ear and notice how only one jar is included:
> ear> unzip -v target/ear-1.0.0.ear
> Now use the debug flag to see why only one gets included:
> ear> mvn --debug clean package
> Partial output:
> \[INFO\] Copying artifact \[jar:ch.rethab.email:utilities:1.0.0\] to
> \[utilities-1.0.0.jar\]
> \[DEBUG\] Skipping artifact \[jar:ch.rethab.collections:utilities:1.0.0\],
> as it is already up to date at \[utilities-1.0.0.jar\]
> {quote}
> Note that this sample shows how dependent libraries are ignored, but I think
> it is also an issue if you have two ejbs with the same name and version -
> though that is probably far less likely.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MEAR-182) Skinny WAR's - Skip Class-Path Modification in Manifest
[ https://jira.codehaus.org/browse/MEAR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348095#comment-348095 ] Mario Däpp commented on MEAR-182: - Sounds good. This fix will be much appreciated. > Skinny WAR's - Skip Class-Path Modification in Manifest > --- > > Key: MEAR-182 > URL: https://jira.codehaus.org/browse/MEAR-182 > Project: Maven Ear Plugin > Issue Type: Improvement >Affects Versions: 2.9 >Reporter: Mario Däpp > Fix For: 2.10 > > Attachments: MEAR-182-patch.txt > > > From Java EE 5, a library directory may be specified in the application.xml > (element library-directory). The Maven EAR Plugin already supports this for > generating the application.xml (value of property defaultLibBundleDir). > The Java EE 5 specification mandates that all JAR files contained in the > library directory be made available to all modules within the EAR file (cf. > chapter EE.8.2.1 Bundled Libraries, section 2). > If one specifies both the skinnyWars (value = true) and defaultLibBundleDir > parameters, the libraries will be removed from the WAR and copied to the > defaultLibBundleDir. They will also be added to the Class-Path in the WAR > files manifest. This is unnecessary as per the Java EE 5 specification. Even > worse, it breaks my EAR on WebLogic (classloading issues). > I therefore propose the following improvement to the skinny WAR's > functionality: If the Java EE version is 5 or greater and the > defaultLibBundleDir has been specified, the Class-Path in the WAR's manifest > should remain unchanged. > I've created a corresponding patch and integration test. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-701) class AddDependencySetsTask doesn't re-unpack contents of unpacked SNAPSHOT artifacts
[ https://jira.codehaus.org/browse/MASSEMBLY-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348092#comment-348092 ] Valentin Kovalenko edited comment on MASSEMBLY-701 at 6/15/14 5:07 PM: --- _>>Why don't you organize your project based on the logical structure ..._ It's just a quick-made example of how to reproduce the bug. Location of parent module is not related to the described behavior so why care about it? Even if you'll refactor the location of the p-parent it will not change the described behavior. Originally in my actual project the module p2 (well, not p2 but its analogue) produces an attached artifact with configuration files and the module p1 includes these configuration files into a final assembled package. _>>Why are you creating a zip via antrun-plugin?_ Well, I didn't find an understandable way to create a zip-type attached artifact via assembly pligun if its content comes from the same project that should produce the artifact. Nonetheless project p2 produces an attached artifact _p2-0.0.0-SNAPSHOT-myClassifier.zip_ and if you'll try run _mvn install_ and check the local .m2 repo you'll see that the attached artifact is installed correctly. For me it seems that it doesn't matter how the attached artifact was produced. Am I wrong here? P.S. of course _mvn clean package_ solves the problem, but this is just a work around was (Author: male): _>>Why don't you organize your project based on the logical structure ..._ It's just a quick-made example of how to reproduce the bug. Location of parent module is not related to the described behavior so why care about it? Even if you'll refactor the location of the p-parent it will not change the described behavior. Originally in my actual project the module p2 (well, not p2 but its analogue) produces an attached artifact with configuration files and the module p1 includes these configuration files into a final assembled package. _>>Why are you creating a zip via antrun-plugin?_ Well, I didn't find an understandable way to create a zip-type attached artifact via assembly pligun if it's content comes from the same project that should produce the artifact. Nonetheless project p2 produces an attached artifact _p2-0.0.0-SNAPSHOT-myClassifier.zip_ and if you'll try run _mvn install_ and check the local .m2 repo you'll see that the attached artifact is installed correctly. For me it seems that it doesn't matter how the attached artifact was produced. Am I wrong here? P.S. of course _mvn clean package_ solves the problem, but this is just a work around > class AddDependencySetsTask doesn't re-unpack contents of unpacked SNAPSHOT > artifacts > - > > Key: MASSEMBLY-701 > URL: https://jira.codehaus.org/browse/MASSEMBLY-701 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: dependencySet >Affects Versions: 2.4 > Environment: Apache Maven 3.2.1, Oracle Java SE Runtime Environment > (build 1.8.0-b132) >Reporter: Valentin Kovalenko > Fix For: backlog > > Attachments: test-Maven.zip > > > Simple project [^test-Maven.zip] to reproduce the problem is attached. > *Test case scenario:* > 1) Upack _test-Maven.zip_ into _test-Maven_ directory. > 2) Run _mvn package_ from the _test-Maven_ directory. > 3) Check that content of the file > _test-Maven\p2\target\p2-0.0.0-SNAPSHOT-myClassifier.zip\content.txt_ is > "some content". > 4) Check that content of the file > _test-Maven\target\p1-0.0.0-SNAPSHOT-myClassifier.zip\myClassifier\content.txt_ > is "some content" (p2 assembly packs content of > _p2-0.0.0-SNAPSHOT-myClassifier.zip_ into > _p1-0.0.0-SNAPSHOT-myClassifier.zip_). > 5) Modify content of the file _test-Maven\p2\src\myClassifier\content.txt_ > (e.g. write "a new content"). > 6) Same as 2). Run _mvn package_ from the _test-Maven_ directory. > 7) Check that content of the file > _test-Maven\p2\target\p2-0.0.0-SNAPSHOT-myClassifier.zip\content.txt_ has > changed to "a new content". > 8) Check that content of the file > _test-Maven\target\p1-0.0.0-SNAPSHOT-myClassifier.zip\myClassifier\content.txt_ > is still "some content" and not "a new content" (+! bug+). > Assembly plugin unpacks content of _p2-0.0.0-SNAPSHOT-myClassifier.zip_ into > the directory > _test-Maven\target\assembly\work\test_p2_0.0.0-SNAPSHOT_myClassifier.zip_ and > never unpacks _p2-0.0.0-SNAPSHOT-myClassifier.zip_ again if working directory > exists. That is +assembly plugin ignores the fact that > _p2-0.0.0-SNAPSHOT-myClassifier.zip_ is a SNAPSHOT (the version of p2 is > 0.0.0-SNAPSHOT)+. > It seems like the corresponding code is in the line 238 (_if ( dir.exists() > )_) in the class > [org.apache.maven.plugin.assembly.archive.task
[jira] (MASSEMBLY-701) class AddDependencySetsTask doesn't re-unpack contents of unpacked SNAPSHOT artifacts
[ https://jira.codehaus.org/browse/MASSEMBLY-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348092#comment-348092 ] Valentin Kovalenko commented on MASSEMBLY-701: -- _>>Why don't you organize your project based on the logical structure ..._ It's just a quick-made example of how to reproduce the bug. Location of parent module is not related to the described behavior so why care about it? Even if you'll refactor the location of the p-parent it will not change the described behavior. Originally in my actual project the module p2 (well, not p2 but its analogue) produces an attached artifact with configuration files and the module p1 includes these configuration files into a final assembled package. _>>Why are you creating a zip via antrun-plugin?_ Well, I didn't find an understandable way to create a zip-type attached artifact via assembly pligun if it's content comes from the same project that should produce the artifact. Nonetheless project p2 produces an attached artifact _p2-0.0.0-SNAPSHOT-myClassifier.zip_ and if you'll try run _mvn install_ and check the local .m2 repo you'll see that the attached artifact is installed correctly. For me it seems that it doesn't matter how the attached artifact was produced. Am I wrong here? P.S. of course _mvn clean package_ solves the problem, but this is just a work around > class AddDependencySetsTask doesn't re-unpack contents of unpacked SNAPSHOT > artifacts > - > > Key: MASSEMBLY-701 > URL: https://jira.codehaus.org/browse/MASSEMBLY-701 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: dependencySet >Affects Versions: 2.4 > Environment: Apache Maven 3.2.1, Oracle Java SE Runtime Environment > (build 1.8.0-b132) >Reporter: Valentin Kovalenko > Fix For: backlog > > Attachments: test-Maven.zip > > > Simple project [^test-Maven.zip] to reproduce the problem is attached. > *Test case scenario:* > 1) Upack _test-Maven.zip_ into _test-Maven_ directory. > 2) Run _mvn package_ from the _test-Maven_ directory. > 3) Check that content of the file > _test-Maven\p2\target\p2-0.0.0-SNAPSHOT-myClassifier.zip\content.txt_ is > "some content". > 4) Check that content of the file > _test-Maven\target\p1-0.0.0-SNAPSHOT-myClassifier.zip\myClassifier\content.txt_ > is "some content" (p2 assembly packs content of > _p2-0.0.0-SNAPSHOT-myClassifier.zip_ into > _p1-0.0.0-SNAPSHOT-myClassifier.zip_). > 5) Modify content of the file _test-Maven\p2\src\myClassifier\content.txt_ > (e.g. write "a new content"). > 6) Same as 2). Run _mvn package_ from the _test-Maven_ directory. > 7) Check that content of the file > _test-Maven\p2\target\p2-0.0.0-SNAPSHOT-myClassifier.zip\content.txt_ has > changed to "a new content". > 8) Check that content of the file > _test-Maven\target\p1-0.0.0-SNAPSHOT-myClassifier.zip\myClassifier\content.txt_ > is still "some content" and not "a new content" (+! bug+). > Assembly plugin unpacks content of _p2-0.0.0-SNAPSHOT-myClassifier.zip_ into > the directory > _test-Maven\target\assembly\work\test_p2_0.0.0-SNAPSHOT_myClassifier.zip_ and > never unpacks _p2-0.0.0-SNAPSHOT-myClassifier.zip_ again if working directory > exists. That is +assembly plugin ignores the fact that > _p2-0.0.0-SNAPSHOT-myClassifier.zip_ is a SNAPSHOT (the version of p2 is > 0.0.0-SNAPSHOT)+. > It seems like the corresponding code is in the line 238 (_if ( dir.exists() > )_) in the class > [org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask|http://svn.apache.org/viewvc/maven/plugins/tags/maven-assembly-plugin-2.4/src/main/java/org/apache/maven/plugin/assembly/archive/task/AddDependencySetsTask.java?view=markup#l238]. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5394) Document how to do logging in a plugin
[ https://jira.codehaus.org/browse/MNG-5394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348090#comment-348090 ] Jason van Zyl commented on MNG-5394: I think we should just document using SLF4J using the static LoggerFactory and avoiding telling people to do anything else. SLF4J has been in there long enough now. > Document how to do logging in a plugin > -- > > Key: MNG-5394 > URL: https://jira.codehaus.org/browse/MNG-5394 > Project: Maven 2 & 3 > Issue Type: Task > Components: Logging > Environment: n/a >Reporter: Anders Hammar > > We should document the different logging options in a Maven plugin that exist > and differences/benefits. So the main audience is not Maven users, but plugin > developers and I guess this doc should go in under the Plugin Developer > Center section. > There is currently a "Maven 3.1.x logging" page, but that one is for end > users and a different story than what this ticket is about. > A few things that the page should cover: > * Plexus logger & SLF4J > * Any compatibility problems using SLF4J with older Maven versions? > * A code example including an example pom depicting dependencies > * How to establish logging separated from Maven's (fork a JVM?) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5507) Configurable download retry policy (with global override)
[ https://jira.codehaus.org/browse/MNG-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348091#comment-348091 ] Marcin Wisnicki commented on MNG-5507: -- But that other task was about doing it with command line parameters which as you pointed out already existed. > Configurable download retry policy (with global override) > - > > Key: MNG-5507 > URL: https://jira.codehaus.org/browse/MNG-5507 > Project: Maven 2 & 3 > Issue Type: Sub-task >Reporter: Marcin Wisnicki > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-4148) Apply profiles from settings.xml to POMs built from the repository
[
https://jira.codehaus.org/browse/MNG-4148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348089#comment-348089
]
Jason van Zyl commented on MNG-4148:
I think profiles are specifically build time, with the possible exception of
platform and JDK which is really more of an environment. If we are moving
toward a consumption-time POM we want to avoid the processing of profiles as
much as possible.
> Apply profiles from settings.xml to POMs built from the repository
> --
>
> Key: MNG-4148
> URL: https://jira.codehaus.org/browse/MNG-4148
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Artifacts and Repositories, POM, Profiles
>Affects Versions: 2.1.0
>Reporter: John Casey
>Assignee: John Casey
> Fix For: 2.2.2
>
> Attachments: test-mng3553.zip
>
>
> When we declare a profile in the settings.xml, it will never be applied to
> POMs loaded from the Maven repository. This means that overriding the central
> repository definition - for instance - cannot be done without using mirror
> definitions, since transitive dependencies (any dependency of a direct
> dependency) will skip the modified definition and use the original from the
> super-POM instead.
> I'm attaching a testing setup that was originally reported for MNG-3553,
> which exhibits this problem when dealing with scope == import. The
> instructions for using it are as follows:
> {noformat}
> I installed locally a nexus server (1.3.3 Open Source) and I'm using maven
> 2.1.0 (I reproduced the issue with 2.0.10).
> In the releases repository of nexus you upload all artifacts given in the
> toUpload directory :
> * parent 1.0.0 pom
> * dependencies 1.0.0 pom
> * module 1.0.0 pom and jar
> You'll find in the root of the archive my settings. It defines to use nexus
> for the central repository.
> You launch a build of the project and you'll have :
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Unnamed -
> org.apache.maven.it.mng3553:project:jar:1.0.0-SNAPSHOT
> [INFO]task-segment: [install]
> [INFO]
>
> [INFO] [resources:resources]
> [WARNING] Using platform encoding (Cp1252 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] skip non existing resourceDirectory
> E:\jtb\workspaces\tests\test-mng3553\project\src\main\resources
> Downloading:
> http://localhost:8081/nexus/content/groups/public//org/apache/maven/it/mng3553/module/1.0.0/module-1.0.0.pom
> 867b downloaded (module-1.0.0.pom)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/maven/it/mng3553/dependencies/1.0.0/dependencies-1.0.0.pom
> [WARNING] Unable to get resource
> 'org.apache.maven.it.mng3553:dependencies:pom:1.0.0'
> from repository central (http://repo1.maven.org/maven2): Authorization
> failed: Access denied to:
>
> http://repo1.maven.org/maven2/org/apache/maven/it/mng3553/dependencies/1.0.0/dependencies-1.0.0.pom
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> GroupId: org.apache.maven.it.mng3553
> ArtifactId: dependencies
> Version: 1.0.0
> Reason: Unable to download the artifact from any repository
> org.apache.maven.it.mng3553:dependencies:pom:1.0.0
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 1 second
> [INFO] Finished at: Thu Apr 30 15:19:47 CEST 2009
> [INFO] Final Memory: 6M/254M
> [INFO]
>
> You can see that the project downloads successfully the module-1.0.0 from
> nexus but
> it fails for depencencies which is an import. It tries to download it from
> the real central repository
> and not from the one I defined in my settings.
> The behavior is inconsistent...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-4148) Apply profiles from settings.xml to POMs built from the repository
[
https://jira.codehaus.org/browse/MNG-4148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-4148.
--
Resolution: Won't Fix
> Apply profiles from settings.xml to POMs built from the repository
> --
>
> Key: MNG-4148
> URL: https://jira.codehaus.org/browse/MNG-4148
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Artifacts and Repositories, POM, Profiles
>Affects Versions: 2.1.0
>Reporter: John Casey
>Assignee: John Casey
> Fix For: 2.2.2
>
> Attachments: test-mng3553.zip
>
>
> When we declare a profile in the settings.xml, it will never be applied to
> POMs loaded from the Maven repository. This means that overriding the central
> repository definition - for instance - cannot be done without using mirror
> definitions, since transitive dependencies (any dependency of a direct
> dependency) will skip the modified definition and use the original from the
> super-POM instead.
> I'm attaching a testing setup that was originally reported for MNG-3553,
> which exhibits this problem when dealing with scope == import. The
> instructions for using it are as follows:
> {noformat}
> I installed locally a nexus server (1.3.3 Open Source) and I'm using maven
> 2.1.0 (I reproduced the issue with 2.0.10).
> In the releases repository of nexus you upload all artifacts given in the
> toUpload directory :
> * parent 1.0.0 pom
> * dependencies 1.0.0 pom
> * module 1.0.0 pom and jar
> You'll find in the root of the archive my settings. It defines to use nexus
> for the central repository.
> You launch a build of the project and you'll have :
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Unnamed -
> org.apache.maven.it.mng3553:project:jar:1.0.0-SNAPSHOT
> [INFO]task-segment: [install]
> [INFO]
>
> [INFO] [resources:resources]
> [WARNING] Using platform encoding (Cp1252 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] skip non existing resourceDirectory
> E:\jtb\workspaces\tests\test-mng3553\project\src\main\resources
> Downloading:
> http://localhost:8081/nexus/content/groups/public//org/apache/maven/it/mng3553/module/1.0.0/module-1.0.0.pom
> 867b downloaded (module-1.0.0.pom)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/maven/it/mng3553/dependencies/1.0.0/dependencies-1.0.0.pom
> [WARNING] Unable to get resource
> 'org.apache.maven.it.mng3553:dependencies:pom:1.0.0'
> from repository central (http://repo1.maven.org/maven2): Authorization
> failed: Access denied to:
>
> http://repo1.maven.org/maven2/org/apache/maven/it/mng3553/dependencies/1.0.0/dependencies-1.0.0.pom
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> GroupId: org.apache.maven.it.mng3553
> ArtifactId: dependencies
> Version: 1.0.0
> Reason: Unable to download the artifact from any repository
> org.apache.maven.it.mng3553:dependencies:pom:1.0.0
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 1 second
> [INFO] Finished at: Thu Apr 30 15:19:47 CEST 2009
> [INFO] Final Memory: 6M/254M
> [INFO]
>
> You can see that the project downloads successfully the module-1.0.0 from
> nexus but
> it fails for depencencies which is an import. It tries to download it from
> the real central repository
> and not from the one I defined in my settings.
> The behavior is inconsistent...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5506) Master override of checksumPolicy
[
https://jira.codehaus.org/browse/MNG-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348088#comment-348088
]
Marcin Wisnicki commented on MNG-5506:
--
Is it possible to have maven strictly validate checksums if present but just
warn when they are absent (unless that's how {{-C,--strict-checksums}} works
already) ?
> Master override of checksumPolicy
> -
>
> Key: MNG-5506
> URL: https://jira.codehaus.org/browse/MNG-5506
> Project: Maven 2 & 3
> Issue Type: Sub-task
>Reporter: Marcin Wisnicki
>Assignee: Jason van Zyl
>
> There should be a property usable both from command line and pom to override
> checksumPolicy for all repositories.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5507) Configurable download retry policy (with global override)
[ https://jira.codehaus.org/browse/MNG-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348086#comment-348086 ] Jason van Zyl commented on MNG-5507: Ok, I'll close this and reopen that one. > Configurable download retry policy (with global override) > - > > Key: MNG-5507 > URL: https://jira.codehaus.org/browse/MNG-5507 > Project: Maven 2 & 3 > Issue Type: Sub-task >Reporter: Marcin Wisnicki > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-1353) Allow creating POJO config classes anywhere without requiring the plugin user to specify an implementation element
[ https://jira.codehaus.org/browse/MNG-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1353. -- Resolution: Won't Fix > Allow creating POJO config classes anywhere without requiring the plugin user > to specify an implementation element > -- > > Key: MNG-1353 > URL: https://jira.codehaus.org/browse/MNG-1353 > Project: Maven 2 & 3 > Issue Type: Task > Components: Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: Vincent Massol >Assignee: Jason van Zyl > Fix For: Issues to be reviewed for 3.x > > > This is really important for several reasons: > * I don't like to clutter my main plugin package with POJO classes. For the > Cargo m2 plugin I have 7-8 POJO classes and I'd like to move them to a > different package > * I need to reuse existing POJOs from another jar and it's just too stupid to > have to duplicate all the code or write wrapper classes with only > getter/setters. > I think the best solution would be to accept @implementation javadoc tags > that would map a parameter to an implementation. This would need to work not > only for Mojo classes but also for POJO classes being used for configuration. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5507) Configurable download retry policy (with global override)
[ https://jira.codehaus.org/browse/MNG-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-5507. -- Resolution: Duplicate > Configurable download retry policy (with global override) > - > > Key: MNG-5507 > URL: https://jira.codehaus.org/browse/MNG-5507 > Project: Maven 2 & 3 > Issue Type: Sub-task >Reporter: Marcin Wisnicki > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-1353) Allow creating POJO config classes anywhere without requiring the plugin user to specify an implementation element
[ https://jira.codehaus.org/browse/MNG-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348087#comment-348087 ] Jason van Zyl commented on MNG-1353: After 10 years, I don't think we're going to do this :-) > Allow creating POJO config classes anywhere without requiring the plugin user > to specify an implementation element > -- > > Key: MNG-1353 > URL: https://jira.codehaus.org/browse/MNG-1353 > Project: Maven 2 & 3 > Issue Type: Task > Components: Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: Vincent Massol >Assignee: Jason van Zyl > Fix For: Issues to be reviewed for 3.x > > > This is really important for several reasons: > * I don't like to clutter my main plugin package with POJO classes. For the > Cargo m2 plugin I have 7-8 POJO classes and I'd like to move them to a > different package > * I need to reuse existing POJOs from another jar and it's just too stupid to > have to duplicate all the code or write wrapper classes with only > getter/setters. > I think the best solution would be to accept @implementation javadoc tags > that would map a parameter to an implementation. This would need to work not > only for Mojo classes but also for POJO classes being used for configuration. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5506) Master override of checksumPolicy
[ https://jira.codehaus.org/browse/MNG-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348085#comment-348085 ] Jason van Zyl commented on MNG-5506: @Marcin, it probably can be now but historically there were many artifacts without checksums. No reason it can't be the default now. > Master override of checksumPolicy > - > > Key: MNG-5506 > URL: https://jira.codehaus.org/browse/MNG-5506 > Project: Maven 2 & 3 > Issue Type: Sub-task >Reporter: Marcin Wisnicki > > There should be a property usable both from command line and pom to override > checksumPolicy for all repositories. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5506) Master override of checksumPolicy
[ https://jira.codehaus.org/browse/MNG-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl reopened MNG-5506: Assignee: Jason van Zyl > Master override of checksumPolicy > - > > Key: MNG-5506 > URL: https://jira.codehaus.org/browse/MNG-5506 > Project: Maven 2 & 3 > Issue Type: Sub-task >Reporter: Marcin Wisnicki >Assignee: Jason van Zyl > > There should be a property usable both from command line and pom to override > checksumPolicy for all repositories. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5507) Configurable download retry policy (with global override)
[ https://jira.codehaus.org/browse/MNG-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcin Wisnicki reopened MNG-5507: -- Description provided. > Configurable download retry policy (with global override) > - > > Key: MNG-5507 > URL: https://jira.codehaus.org/browse/MNG-5507 > Project: Maven 2 & 3 > Issue Type: Sub-task >Reporter: Marcin Wisnicki > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5507) Configurable download retry policy (with global override)
[ https://jira.codehaus.org/browse/MNG-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348082#comment-348082 ] Marcin Wisnicki commented on MNG-5507: -- Sorry, I meant sibling task (MNG-5506). > Configurable download retry policy (with global override) > - > > Key: MNG-5507 > URL: https://jira.codehaus.org/browse/MNG-5507 > Project: Maven 2 & 3 > Issue Type: Sub-task >Reporter: Marcin Wisnicki > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5507) Configurable download retry policy (with global override)
[ https://jira.codehaus.org/browse/MNG-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348081#comment-348081 ] Marcin Wisnicki commented on MNG-5507: -- You provided it in parent task (command line parameters) - I just want a way to set the policy in global/user configuration file. > Configurable download retry policy (with global override) > - > > Key: MNG-5507 > URL: https://jira.codehaus.org/browse/MNG-5507 > Project: Maven 2 & 3 > Issue Type: Sub-task >Reporter: Marcin Wisnicki > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAR-138) jar:test-jar is skipped when maven.test.skip=true
[ https://jira.codehaus.org/browse/MJAR-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MJAR-138: - Fix Version/s: more-investigation > jar:test-jar is skipped when maven.test.skip=true > - > > Key: MJAR-138 > URL: https://jira.codehaus.org/browse/MJAR-138 > Project: Maven JAR Plugin > Issue Type: Improvement >Affects Versions: 2.3.1 > Environment: jar:test-jar >Reporter: Andrew Hughes > Fix For: more-investigation > > Attachments: MJAR-138-maven-jar-plugin.patch > > > Not sure if this is a bug or improvement... > Example: > * ./pom.xml > * ./moduleA/pom.xml > * ./moduleB/pom.xml > Situation: > * moduleA produces moduleA-1.2.3-test.jar with the jar:test-jar goal > * moduleB consumes moduleA-1.2.3-test.jar as a > ...test > Problem: > * When -Dmaven.test.skip=true the moduleA-1.2.3-test.jar is never built. > * Then when moduleB tries to build, it's moduleA-1.2.3-test.jar dependency is > unresolved. FAIL! Even with -Dmaven.test.skip=true this will fail. > You might argue that this is a bug with dependency resolution with > -Dmaven.test.skip=true - should a missing dependency @ test scope really fail > the build??? It probably should - which is why the bug is submitted here :) > I've no idea what could be done to fix this either? > --- > p.s. for anyone with this bug the only workaround I can suggest is running > another module... > ./moduleA-test/pom.xml > and have > ...moduleA-test...test -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAR-167) skipIfEmpty outputs incorrect logging nessage
[
https://jira.codehaus.org/browse/MJAR-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise updated MJAR-167:
-
Fix Version/s: 2.5
> skipIfEmpty outputs incorrect logging nessage
> -
>
> Key: MJAR-167
> URL: https://jira.codehaus.org/browse/MJAR-167
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Stephen Colebourne
>Priority: Trivial
> Fix For: 2.5
>
>
> The 'skipIfEmpty' flag added in MJAR-139 has the wrong debugging message
> (refers to test-jar, not jar):
> {code}
> [INFO] --- maven-jar-plugin:2.4:jar (jar) @ og-server ---
> [INFO] Skipping packaging of the test-jar
> [INFO]
> [INFO] --- maven-jar-plugin:2.4:test-jar (test-jar) @ og-server ---
> [INFO] Skipping packaging of the test-jar
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAR-172) Manifest entries are in wrong (visual) order
[ https://jira.codehaus.org/browse/MJAR-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348080#comment-348080 ] Karl-Heinz Marbaise commented on MJAR-172: -- Is this really a bug or more cosmetic nature? > Manifest entries are in wrong (visual) order > > > Key: MJAR-172 > URL: https://jira.codehaus.org/browse/MJAR-172 > Project: Maven JAR Plugin > Issue Type: Bug >Affects Versions: 2.4 > Environment: Windows 7, IBM JDK 1.6.0, Maven 3.0.4 >Reporter: Anders Hammar >Priority: Minor > > When enabling addDefaultImplementationEntries and/or > addDefaultSpecificationEntries, these added manifest entries are not listed > together, which makes it not so nice visually. This was not the case with > v2.3.x (and prior) of the plugin, where they were added as explained here: > http://maven.apache.org/shared/maven-archiver/examples/manifest.html -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAR-172) Manifest entries are in wrong (visual) order
[ https://jira.codehaus.org/browse/MJAR-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348080#comment-348080 ] Karl-Heinz Marbaise edited comment on MJAR-172 at 6/15/14 2:29 PM: --- Is this really a bug or more cosmetic nature? I would categorize this a improvement or wish but not as bug. was (Author: khmarbaise): Is this really a bug or more cosmetic nature? > Manifest entries are in wrong (visual) order > > > Key: MJAR-172 > URL: https://jira.codehaus.org/browse/MJAR-172 > Project: Maven JAR Plugin > Issue Type: Bug >Affects Versions: 2.4 > Environment: Windows 7, IBM JDK 1.6.0, Maven 3.0.4 >Reporter: Anders Hammar >Priority: Minor > > When enabling addDefaultImplementationEntries and/or > addDefaultSpecificationEntries, these added manifest entries are not listed > together, which makes it not so nice visually. This was not the case with > v2.3.x (and prior) of the plugin, where they were added as explained here: > http://maven.apache.org/shared/maven-archiver/examples/manifest.html -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5496) Fixing NOTICE and LICENSE files
[ https://jira.codehaus.org/browse/MNG-5496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-5496. -- Resolution: Fixed > Fixing NOTICE and LICENSE files > --- > > Key: MNG-5496 > URL: https://jira.codehaus.org/browse/MNG-5496 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.1.0 >Reporter: SebbASF >Priority: Blocker > > The NOTICE and LICENSE files are an essential part of any release. > They need to relate to the contents of the bundle in which they are located > and it is important that they don't contain anything superfluous [1] > Each distribution artifact potentially needs its own specific N&L files. > In particular, the source and binary artifacts will generally need different > versions, as the binary often bundles additional items, for example 3rd party > jars. > However the jar files which are created from the SCM source probably can use > the same license as the source archive. > However, the existing N&L files in 3.1.0 fall short on several counts: > The source and binary NOTICE files both start as follows: > > >= >== NOTICE file corresponding to the section 4 d of== >== the Apache License, Version 2.0, == >== in this case for the Apache Maven distribution.== >= > Apache Maven > Copyright 2001-2013 The Apache Software Foundation > This product includes software developed by > The Apache Software Foundation (http://www.apache.org/). > <<< > However, the file must start as follows: > > Apache Maven > Copyright 2001-2013 The Apache Software Foundation > This product includes software developed at > The Apache Software Foundation (http://www.apache.org/). > > Note particularly that the phrase is "developed at" not "developed by" > The source NOTICE file is the same as the binary NOTICE file, yet the binary > archive contains lots of additional jars. > It looks to me as though the above 5 lines is all that are needed for the > source archive. The existing source LICENSE.txt file looks OK. > However, the binary LICENSE file makes no mention at all of any licenses for > the additional products. It should point to the licenses for each of the > additional products that are included, for example: Aether, Sisu, Plexus etc. > These licenses need to be obtained and stored in a suitable directory which > is referenced in LICENSE.txt. > [1] http://www.apache.org/dev/licensing-howto.html -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAR-176) Usage page should (only) describe default behavior
[
https://jira.codehaus.org/browse/MJAR-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise updated MJAR-176:
-
Fix Version/s: 2.5
> Usage page should (only) describe default behavior
> ---
>
> Key: MJAR-176
> URL: https://jira.codehaus.org/browse/MJAR-176
> Project: Maven JAR Plugin
> Issue Type: Improvement
>Reporter: Robert Scholte
> Fix For: 2.5
>
>
> If one is pretty new to Maven and just wants to create a jar (still the most
> used packaging type), he'll probably go to the docs of this plugin. This
> means that the usage page should make it immediately clear. Now it jumps fast
> to finetuning the configuration.
> Instead:
> - describe standard folder structure (start with only {{src/main/java}} and
> {{src/main/resources}})
> - describe minimum pom (in this case GAV + modelVersion, saying {{jar}} is
> the default packaging type)
> - describe the {{package}} goal.
> Configuration specifics should be moved to example pages.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5473) Backwards compatibility issue in MavenProjectBuilder.build(...)
[ https://jira.codehaus.org/browse/MNG-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348079#comment-348079 ] Jason van Zyl commented on MNG-5473: Do you still need this. Over a major version change I'm not concerned about the builder methods. There were massive changes, I'm not really interested in making it compatible. > Backwards compatibility issue in MavenProjectBuilder.build(...) > --- > > Key: MNG-5473 > URL: https://jira.codehaus.org/browse/MNG-5473 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 3.0.4 > Environment: Mac OS 10.8.3 with Apple JDK 1.6.0_45 >Reporter: Anders Hammar > Attachments: compat-issue.zip > > > I'm running into a NPE when using the compat lib of Maven 3. Attached is a > test project with unit test code that works with Maven 2.2.1 deps but fails > with Maven 3.0.4 deps. > To switch between Maven 2 and Maven 3, the deps in the pom needs to be > altered (see comments). If built as-si it will use Maven 3.0.4 deps and fail. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAR-166) Ability to add additional class directories to create jar
[ https://jira.codehaus.org/browse/MJAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MJAR-166: - Fix Version/s: (was: 2.5) more-investigation > Ability to add additional class directories to create jar > - > > Key: MJAR-166 > URL: https://jira.codehaus.org/browse/MJAR-166 > Project: Maven JAR Plugin > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Viraj >Priority: Minor > Fix For: more-investigation > > Attachments: MNG-MJAR-166-maven-jar-plugin.patch > > > Current maven-jar-plugin create jar using target/classes and additional > resources directories. It will be useful if one can add additional classes > directories. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAR-174) NoClassDefFoundError while packaging using maven-jar-plugin:2.4 with Maven 3.1.1
[ https://jira.codehaus.org/browse/MJAR-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348078#comment-348078 ] Karl-Heinz Marbaise commented on MJAR-174: -- Can you please create a full working example project may be attach to the issue or create a github project. > NoClassDefFoundError while packaging using maven-jar-plugin:2.4 with Maven > 3.1.1 > > > Key: MJAR-174 > URL: https://jira.codehaus.org/browse/MJAR-174 > Project: Maven JAR Plugin > Issue Type: Bug > Components: sign >Affects Versions: 2.4 > Environment: Windows, Mac and Linux >Reporter: Maruthi Shanmugam > Attachments: Maven_Error.txt > > > Exception while building with Maven 3.1.1 and maven-jar-plugin:2.4 > Exception pasted for your reference : > WARNING] Error injecting: org.apache.maven.plugin.jar.JarMojo > java.lang.NoClassDefFoundError: > org/codehaus/plexus/components/io/resources/PlexusIoResourceCollection > at java.lang.Class.getDeclaredConstructors0(Native Method) > at java.lang.Class.privateGetDeclaredConstructors(Class.java:2493) > at java.lang.Class.getDeclaredConstructors(Class.java:1901) > at com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoi -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5487) Missing NOTICE and LICENSE files at top level of SCM trees
[ https://jira.codehaus.org/browse/MNG-5487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-5487. -- Resolution: Fixed > Missing NOTICE and LICENSE files at top level of SCM trees > -- > > Key: MNG-5487 > URL: https://jira.codehaus.org/browse/MNG-5487 > Project: Maven 2 & 3 > Issue Type: Bug >Reporter: SebbASF >Priority: Critical > > There should be a NOTICE and LICENSE file in an obvious place in every > published source release. Since the SVN / GIT repos are published, AIUI they > should have N & L files. > I would expect to find N & L files alongside the pom.xml files. > The only such files I could find were under apache-maven: > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=tree;f=apache-maven;h=b1f7f0b63f3617a55381ccaa2ee25b7050e218fc;hb=master > The NOTICE file there is also incorrect; the leading 5 lines should be > removed; the NOTICE file MUST start with something like: > === > Apache Maven > Copyright 2001-2013 The Apache Software Foundation > This product includes software developed at > The Apache Software Foundation (http://www.apache.org/). > > Note also that the correct phrase is "developed at" - *not* "developed by" - > the distinction is important. > See: > http://www.apache.org/legal/src-headers.html#notice-text -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5507) Configurable download retry policy (with global override)
[ https://jira.codehaus.org/browse/MNG-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-5507. -- Resolution: Incomplete > Configurable download retry policy (with global override) > - > > Key: MNG-5507 > URL: https://jira.codehaus.org/browse/MNG-5507 > Project: Maven 2 & 3 > Issue Type: Sub-task >Reporter: Marcin Wisnicki > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5507) Configurable download retry policy (with global override)
[ https://jira.codehaus.org/browse/MNG-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348077#comment-348077 ] Jason van Zyl commented on MNG-5507: Provide a decent description of the isse if you want us to look at it. > Configurable download retry policy (with global override) > - > > Key: MNG-5507 > URL: https://jira.codehaus.org/browse/MNG-5507 > Project: Maven 2 & 3 > Issue Type: Sub-task >Reporter: Marcin Wisnicki > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5510) Maven causing ClassCastException with container plugins when project is using other SLF4J implementation than slf4j-simple
[ https://jira.codehaus.org/browse/MNG-5510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-5510. -- Resolution: Won't Fix > Maven causing ClassCastException with container plugins when project is using > other SLF4J implementation than slf4j-simple > -- > > Key: MNG-5510 > URL: https://jira.codehaus.org/browse/MNG-5510 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Bootstrap & Build, Logging >Affects Versions: 3.1.0 >Reporter: Juan Pablo Santos Rodríguez > > On our project we're using directly logback to start up a custom mbean to be > able to change log levels dynamically, among other things. Most of these > operations are Logback-specific, they're not available via SLF4J API > For testing we use Jetty, so when we're doing an mvn jetty:run, the mbean > gets init'd and we get an Exception stating "ClassCastException: > org.slf4j.impl.SimpleLoggerFactory cannot be cast to > ch.qos.logback.classic.LoggerContext", due to slf4j-simple being on maven's > lib. This is very likely to happen with other container plugins (tomcat7 et > al) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5510) Maven causing ClassCastException with container plugins when project is using other SLF4J implementation than slf4j-simple
[ https://jira.codehaus.org/browse/MNG-5510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348076#comment-348076 ] Jason van Zyl commented on MNG-5510: If you have hardcoded requirements for specific SLF4J implementations then I would say that's not great, but to work around to have something that is specific for your use then fork the VM and there will be no conflict. > Maven causing ClassCastException with container plugins when project is using > other SLF4J implementation than slf4j-simple > -- > > Key: MNG-5510 > URL: https://jira.codehaus.org/browse/MNG-5510 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Bootstrap & Build, Logging >Affects Versions: 3.1.0 >Reporter: Juan Pablo Santos Rodríguez > > On our project we're using directly logback to start up a custom mbean to be > able to change log levels dynamically, among other things. Most of these > operations are Logback-specific, they're not available via SLF4J API > For testing we use Jetty, so when we're doing an mvn jetty:run, the mbean > gets init'd and we get an Exception stating "ClassCastException: > org.slf4j.impl.SimpleLoggerFactory cannot be cast to > ch.qos.logback.classic.LoggerContext", due to slf4j-simple being on maven's > lib. This is very likely to happen with other container plugins (tomcat7 et > al) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-700) Difference in property expansion between pom and assembly components
[
https://jira.codehaus.org/browse/MASSEMBLY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise closed MASSEMBLY-700.
-
Resolution: Not A Bug
Assignee: Karl-Heinz Marbaise
Hm. May be i misundestand a thing but i can't see a buggy behaviour here, cause
maven-assembly-plugin (component descriptor) uses the properties you have
defined in your pom. Hm..I will close the issue, cause this is no bug in
contrary it's exactly designed behaviour. I would suggest that you create a
feature request which will scream loud by using an option.
If you have different opinion don't hesitate to reopen the issue.
> Difference in property expansion between pom and assembly components
>
>
> Key: MASSEMBLY-700
> URL: https://jira.codehaus.org/browse/MASSEMBLY-700
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: component descriptor
>Affects Versions: 2.4
> Environment: Java 8 update 5
> Maven 3.2.1
> Linux (Fedora 20 x86_64)
>Reporter: Andreas Kohn
>Assignee: Karl-Heinz Marbaise
>
> My pom.xml contains a property {{java.version}} which points to the version
> of java to include in our assembly. In the assembly component for including
> java I refer to this property.
> {code:title=pom.xml dependency}
>
>
>
>
> com.oracle.java
> jdk
> ${java.version}
> linux-x64
> tar.gz
>
> provided
>
>
>
> 1.7.0_55
>
>
> {code}
> (the GAV point to a manually deployed JDK artifact)
> {code:title=jdk component}
>
> xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/component/1.1.2";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>
> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/component/1.1.2
> http://maven.apache.org/xsd/component-1.1.2.xsd";>
>
>
>
> releases
>
> com.oracle.java:jdk:tar.gz
>
> true
>
>
>
>
> jdk${java.version}/db/
>
> jdk${java.version}/src.zip
>
> jdk${java.version}/lib/missioncontrol/
>
> jdk${java.version}/lib/visualvm/
>
> jdk${java.version}/man/
>
> jdk${java.version}/jre/lib/desktop/
>
>
> provided
> false
>
>
>
> {code}
> The goal is to trim the size of this artifact to speed up automatic
> deployments.
> Unfortunately I noticed that the exclusions stopped working when the version
> of java i'm using for building and the version of java to be included differ:
> the maven-assembly-plugin seems to be expanding 'java.version' to the system
> property, not the pom property.
> I worked around this by using a different property name, but this
> inconsistency could potentially confuse people.
> Maybe the plugin could "scream loudly" when such a situation is detected, or
> use the same priorities when resolving properties as in pom expansion?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5526) parent with 'RELEASE' version not resolved when only maven-metadata-local.xml (with a SNAPSHOT pom) file available in the local nexus repo
[ https://jira.codehaus.org/browse/MNG-5526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348074#comment-348074 ] Jason van Zyl commented on MNG-5526: Coming with Maven 3.2.2 you will be able to use ranges in parent elements. Will this work for your requirements to get the latest parent with all your definitions? While these cannot be unbounded you can do something like [1.0,2.0) where you can continually release the parent and have it be used. > parent with 'RELEASE' version not resolved when only maven-metadata-local.xml > (with a SNAPSHOT pom) file available in the local nexus repo > -- > > Key: MNG-5526 > URL: https://jira.codehaus.org/browse/MNG-5526 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.3, 3.0.4, 3.0.5 >Reporter: Nico De Groote >Priority: Critical > Attachments: artifact_pom.xml, parent-pom.xml > > > We have a parent pom project containing all infrastructure + plugin version > to be used by all our projects. > We always point to the RELEASE of this parent pom for our projects. However > when there is only a maven-metadata-local.xml in our local nexus repo, we get > the following error. > Non-resolvable parent POM: Failed to resolve version for > be.company:parent:pom:RELEASE and 'parent.relativePath' points at wrong local > POM @ line 3, column 11 -> [Help 2] > org.apache.maven.model.resolution.UnresolvableModelException: Failed to > resolve version for be.company:parent:pom:RELEASE > at > org.apache.maven.project.ProjectModelResolver.resolveModel(ProjectModelResolver.java:159) > at > org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(DefaultModelBuilder.java:819) > at > org.apache.maven.model.building.DefaultModelBuilder.readParent(DefaultModelBuilder.java:670) > at > org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:308) > at > org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:232) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:386) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:355) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:319) > at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:632) > at > org.apache.maven.DefaultMaven.getProjectsForMavenReactor(DefaultMaven.java:581) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:233) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.sonatype.aether.resolution.ArtifactResolutionException: Failed > to resolve version for be.company:parent:pom:RELEASE > at > org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:541) > at > org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:220) > at > org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:197) > at > org.sonatype.aether.impl.internal.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:323) > at > org.apache.maven.project.ProjectModelResolver.resolveModel(ProjectModelResolver.java:155) > ... 22 more > Caused by: org.sonatype.aether.resolution.VersionResolutionException: Failed > to resolve version for be.company:parent:pom:RELEASE > at > org.apache.maven.repository.internal.DefaultVersionResolver.resolveVersion(DefaultVersionResolver.java:273) > at > org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:276) > ... 26 more > When we remove
[jira] (MNG-5544) Add removeMetadata method to org.apache.maven.artifact.Artifact interface
[ https://jira.codehaus.org/browse/MNG-5544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-5544. -- Resolution: Won't Fix > Add removeMetadata method to org.apache.maven.artifact.Artifact interface > - > > Key: MNG-5544 > URL: https://jira.codehaus.org/browse/MNG-5544 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Jack Jia > > Need to add removeMetadata method to org.apache.maven.artifact.Artifact > interface for removing metadata from Artifact. > Method Signature: > public abstract void removeMetadata(ArtifactMetadata paramArtifactMetadata); > Should use the getKey method of > org.apache.maven.artifact.metadata.ArtifactMetadata as key to remove metadata > in implementation > The jira issue http://jira.codehaus.org/browse/MDEPLOY-173 explains why this > method is needed. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5544) Add removeMetadata method to org.apache.maven.artifact.Artifact interface
[ https://jira.codehaus.org/browse/MNG-5544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348073#comment-348073 ] Jason van Zyl commented on MNG-5544: Release repositories should be immutable, we're not adding something to remove anything. To deploy a consumption-only POM we are likely to go down another route. We're going to talk about this coming this Wednesday if you're interested: https://plus.google.com/u/0/b/113247990055413254822/events/cvbjktccvtp8cj9pru9u7r511fs > Add removeMetadata method to org.apache.maven.artifact.Artifact interface > - > > Key: MNG-5544 > URL: https://jira.codehaus.org/browse/MNG-5544 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Jack Jia > > Need to add removeMetadata method to org.apache.maven.artifact.Artifact > interface for removing metadata from Artifact. > Method Signature: > public abstract void removeMetadata(ArtifactMetadata paramArtifactMetadata); > Should use the getKey method of > org.apache.maven.artifact.metadata.ArtifactMetadata as key to remove metadata > in implementation > The jira issue http://jira.codehaus.org/browse/MDEPLOY-173 explains why this > method is needed. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-701) class AddDependencySetsTask doesn't re-unpack contents of unpacked SNAPSHOT artifacts
[
https://jira.codehaus.org/browse/MASSEMBLY-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348072#comment-348072
]
Karl-Heinz Marbaise commented on MASSEMBLY-701:
---
Can you please describe what you like to achieve with this setup. You have
already described how to reproduce the behaviour. Based on your examples there
are coming many questions in my mind. Why don't you organize your project based
on the logical structure
{code}
- parent (pom.xml)
+-- mod-1 (pom.xml)
+-- mod-1 (pom.xml)
{code}
where each child (mod-1, mod-2) uses parent as the {{parent}} and not locating
the parent into a sub-folder which results in relativePath overrides instead of
the defaults. Why are you creating a zip via antrun-plugin?
> class AddDependencySetsTask doesn't re-unpack contents of unpacked SNAPSHOT
> artifacts
> -
>
> Key: MASSEMBLY-701
> URL: https://jira.codehaus.org/browse/MASSEMBLY-701
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.4
> Environment: Apache Maven 3.2.1, Oracle Java SE Runtime Environment
> (build 1.8.0-b132)
>Reporter: Valentin Kovalenko
> Fix For: backlog
>
> Attachments: test-Maven.zip
>
>
> Simple project [^test-Maven.zip] to reproduce the problem is attached.
> *Test case scenario:*
> 1) Upack _test-Maven.zip_ into _test-Maven_ directory.
> 2) Run _mvn package_ from the _test-Maven_ directory.
> 3) Check that content of the file
> _test-Maven\p2\target\p2-0.0.0-SNAPSHOT-myClassifier.zip\content.txt_ is
> "some content".
> 4) Check that content of the file
> _test-Maven\target\p1-0.0.0-SNAPSHOT-myClassifier.zip\myClassifier\content.txt_
> is "some content" (p2 assembly packs content of
> _p2-0.0.0-SNAPSHOT-myClassifier.zip_ into
> _p1-0.0.0-SNAPSHOT-myClassifier.zip_).
> 5) Modify content of the file _test-Maven\p2\src\myClassifier\content.txt_
> (e.g. write "a new content").
> 6) Same as 2). Run _mvn package_ from the _test-Maven_ directory.
> 7) Check that content of the file
> _test-Maven\p2\target\p2-0.0.0-SNAPSHOT-myClassifier.zip\content.txt_ has
> changed to "a new content".
> 8) Check that content of the file
> _test-Maven\target\p1-0.0.0-SNAPSHOT-myClassifier.zip\myClassifier\content.txt_
> is still "some content" and not "a new content" (+! bug+).
> Assembly plugin unpacks content of _p2-0.0.0-SNAPSHOT-myClassifier.zip_ into
> the directory
> _test-Maven\target\assembly\work\test_p2_0.0.0-SNAPSHOT_myClassifier.zip_ and
> never unpacks _p2-0.0.0-SNAPSHOT-myClassifier.zip_ again if working directory
> exists. That is +assembly plugin ignores the fact that
> _p2-0.0.0-SNAPSHOT-myClassifier.zip_ is a SNAPSHOT (the version of p2 is
> 0.0.0-SNAPSHOT)+.
> It seems like the corresponding code is in the line 238 (_if ( dir.exists()
> )_) in the class
> [org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask|http://svn.apache.org/viewvc/maven/plugins/tags/maven-assembly-plugin-2.4/src/main/java/org/apache/maven/plugin/assembly/archive/task/AddDependencySetsTask.java?view=markup#l238].
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-701) class AddDependencySetsTask doesn't re-unpack contents of unpacked SNAPSHOT artifacts
[ https://jira.codehaus.org/browse/MASSEMBLY-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MASSEMBLY-701: -- Fix Version/s: backlog > class AddDependencySetsTask doesn't re-unpack contents of unpacked SNAPSHOT > artifacts > - > > Key: MASSEMBLY-701 > URL: https://jira.codehaus.org/browse/MASSEMBLY-701 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: dependencySet >Affects Versions: 2.4 > Environment: Apache Maven 3.2.1, Oracle Java SE Runtime Environment > (build 1.8.0-b132) >Reporter: Valentin Kovalenko > Fix For: backlog > > Attachments: test-Maven.zip > > > Simple project [^test-Maven.zip] to reproduce the problem is attached. > *Test case scenario:* > 1) Upack _test-Maven.zip_ into _test-Maven_ directory. > 2) Run _mvn package_ from the _test-Maven_ directory. > 3) Check that content of the file > _test-Maven\p2\target\p2-0.0.0-SNAPSHOT-myClassifier.zip\content.txt_ is > "some content". > 4) Check that content of the file > _test-Maven\target\p1-0.0.0-SNAPSHOT-myClassifier.zip\myClassifier\content.txt_ > is "some content" (p2 assembly packs content of > _p2-0.0.0-SNAPSHOT-myClassifier.zip_ into > _p1-0.0.0-SNAPSHOT-myClassifier.zip_). > 5) Modify content of the file _test-Maven\p2\src\myClassifier\content.txt_ > (e.g. write "a new content"). > 6) Same as 2). Run _mvn package_ from the _test-Maven_ directory. > 7) Check that content of the file > _test-Maven\p2\target\p2-0.0.0-SNAPSHOT-myClassifier.zip\content.txt_ has > changed to "a new content". > 8) Check that content of the file > _test-Maven\target\p1-0.0.0-SNAPSHOT-myClassifier.zip\myClassifier\content.txt_ > is still "some content" and not "a new content" (+! bug+). > Assembly plugin unpacks content of _p2-0.0.0-SNAPSHOT-myClassifier.zip_ into > the directory > _test-Maven\target\assembly\work\test_p2_0.0.0-SNAPSHOT_myClassifier.zip_ and > never unpacks _p2-0.0.0-SNAPSHOT-myClassifier.zip_ again if working directory > exists. That is +assembly plugin ignores the fact that > _p2-0.0.0-SNAPSHOT-myClassifier.zip_ is a SNAPSHOT (the version of p2 is > 0.0.0-SNAPSHOT)+. > It seems like the corresponding code is in the line 238 (_if ( dir.exists() > )_) in the class > [org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask|http://svn.apache.org/viewvc/maven/plugins/tags/maven-assembly-plugin-2.4/src/main/java/org/apache/maven/plugin/assembly/archive/task/AddDependencySetsTask.java?view=markup#l238]. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5647) ${maven.build.timestamp} uses incorrect ISO datetime separator
[
https://jira.codehaus.org/browse/MNG-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-5647.
---
Resolution: Fixed
Fixed with cdb8ad6dd1ee5e24abede7ec22dce7a8197dbd1a. I'll have a look at the
integration tests and will add two to verify new default format and another
format.
> ${maven.build.timestamp} uses incorrect ISO datetime separator
> --
>
> Key: MNG-5647
> URL: https://jira.codehaus.org/browse/MNG-5647
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.2.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.2.2
>
>
> Separator must be {{T}} and not {{-}} if we predefine ISO 8601 datetime
> format. Additionally, {{Z}} should be added to denote UTC time zone.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5580) mvn 3.x - unable to resolve snapshot artifact via ArtifactResolver using override local repository
[ https://jira.codehaus.org/browse/MNG-5580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348070#comment-348070 ] Jason van Zyl commented on MNG-5580: Can you please make a test or an example problem so I can reproduce the problem. > mvn 3.x - unable to resolve snapshot artifact via ArtifactResolver using > override local repository > -- > > Key: MNG-5580 > URL: https://jira.codehaus.org/browse/MNG-5580 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0.5, 3.1.0, 3.1.1 >Reporter: Dan Tran > > I can use ArtifactResolver to download a given snapshot maven coordinate. > This works with private local repository ( ie I dont want to use the default > one) using mvn2 but fails with mvn3.x > This type of invocation also under maven-dependency-plugin > Similar invocation using technique at > https://github.com/ljnelson/maven-artifacts/blob/master/src/main/java/com/edugility/maven/Artifacts.java > also see the same result > The main motivation is for my plugin to download a huge artifact using a > given artifact under 'target' directory using maven 2/3.x without using aether > a demo is also at > https://svn.codehaus.org/mojo/trunk/sandbox/download-maven-plugin -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-193) Add new rule: BannedRepositories to ban specified repositories for whole maven session
[ https://jira.codehaus.org/browse/MENFORCER-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MENFORCER-193. - Resolution: Fixed Assignee: Karl-Heinz Marbaise Fixed in [r1602751|http://svn.apache.org/r1602751]. Thanks for the contribution Simon. > Add new rule: BannedRepositories to ban specified repositories for whole > maven session > -- > > Key: MENFORCER-193 > URL: https://jira.codehaus.org/browse/MENFORCER-193 > Project: Maven Enforcer Plugin > Issue Type: New Feature > Components: Standard Rules >Affects Versions: 2.0 >Reporter: Simon Wang >Assignee: Karl-Heinz Marbaise > Fix For: 1.4 > > > *Description* > There are use cases that need to ban specified repositories. > Ex. one enterprise migrate their repositories from old one to new one. > But some users still use old settings.xml or some projects' pom.xml still > have old repositories. > What this rule did: > 1. bannedRepositories: user could add banned repositories and support > wildcard "*" to simplify user's usage. > 2. allowedRepositories: that's simpler and useful for enterprise users. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-193) Add new rule: BannedRepositories to ban specified repositories for whole maven session
[ https://jira.codehaus.org/browse/MENFORCER-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MENFORCER-193: -- Fix Version/s: (was: 2.0) 1.4 > Add new rule: BannedRepositories to ban specified repositories for whole > maven session > -- > > Key: MENFORCER-193 > URL: https://jira.codehaus.org/browse/MENFORCER-193 > Project: Maven Enforcer Plugin > Issue Type: New Feature > Components: Standard Rules >Affects Versions: 2.0 >Reporter: Simon Wang > Fix For: 1.4 > > > *Description* > There are use cases that need to ban specified repositories. > Ex. one enterprise migrate their repositories from old one to new one. > But some users still use old settings.xml or some projects' pom.xml still > have old repositories. > What this rule did: > 1. bannedRepositories: user could add banned repositories and support > wildcard "*" to simplify user's usage. > 2. allowedRepositories: that's simpler and useful for enterprise users. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5649) Stop abusing IllegalArgumentException in case of null
[
https://jira.codehaus.org/browse/MNG-5649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348068#comment-348068
]
Michael Osipov commented on MNG-5649:
-
{noformat}
$ grep -nrF "throw new IllegalArgumentException" .
./maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java:168:
throw new IllegalArgumentException( "remote repository manager has not
been specified" );
./maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java:178:
throw new IllegalArgumentException( "version resolver has not been
specified" );
./maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java:189:
throw new IllegalArgumentException( "version range resolver has not
been specified" );
./maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java:199:
throw new IllegalArgumentException( "artifact resolver has not been
specified" );
./maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java:209:
throw new IllegalArgumentException( "repository event dispatcher has
not been specified" );
./maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java:219:
throw new IllegalArgumentException( "model builder has not been
specified" );
./maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java:130:
throw new IllegalArgumentException( "metadata resolver has not been
specified" );
./maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java:140:
throw new IllegalArgumentException( "sync context factory has not been
specified" );
./maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java:150:
throw new IllegalArgumentException( "repository event dispatcher has not
been specified" );
./maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionResolver.java:142:
t
hrow new IllegalArgumentException( "metadata resolver has not been specified" );
./maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionResolver.java:152:
t
hrow new IllegalArgumentException( "sync context factory has not been
specified" );
./maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionResolver.java:162:
t
hrow new IllegalArgumentException( "repository event dispatcher has not been
specified" );
./maven-aether-provider/src/main/java/org/apache/maven/repository/internal/RelocatedArtifact.java:47:
throw n
ew IllegalArgumentException( "no artifact specified" );
./maven-artifact/src/main/java/org/apache/maven/artifact/ArtifactUtils.java:55:
throw new IllegalArgumentExce
ption( "version: null" );
./maven-core/src/main/java/org/apache/maven/artifact/repository/LegacyLocalRepositoryManager.java:93:
throw n
ew IllegalArgumentException( "local repository delegate missing" );
./maven-core/src/main/java/org/apache/maven/artifact/repository/metadata/io/DefaultMetadataReader.java:50:
th
row new IllegalArgumentException( "input file missing" );
./maven-core/src/main/java/org/apache/maven/artifact/repository/metadata/io/DefaultMetadataReader.java:63:
th
row new IllegalArgumentException( "input reader missing" );
./maven-core/src/main/java/org/apache/maven/artifact/repository/metadata/io/DefaultMetadataReader.java:86:
th
row new IllegalArgumentException( "input stream missing" );
./maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java:312:
throw new IllegalAr
gumentException( "model missing" );
./maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java:329:
throw new IllegalAr
gumentException( "extension plugin missing" );
./maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java:345:
throw new IllegalAr
gumentException( "plugin missing" );
./maven-core/src/main/java/org/apache/maven/configuration/DefaultBeanConfigurationRequest.java:125:
throw new
IllegalArgumentException( "group id for plugin has not been specified" );
./maven-core/src/main/java/org/apache/maven/configuration/DefaultBeanConfigurationRequest.java:129:
throw new
IllegalArgumentException( "artifact id for plugin has not been specified" );
./maven-core/src/main/java/org/apache/maven/configuration/internal/DefaultBeanConfigurator.java:58:
throw new
IllegalArgumentException( "bean configuration request not specified" );
./maven-core/src/main/java/org/apache/maven/configurati
[jira] (MNG-5649) Stop abusing IllegalArgumentException in case of null
[
https://jira.codehaus.org/browse/MNG-5649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348068#comment-348068
]
Michael Osipov edited comment on MNG-5649 at 6/15/14 1:36 PM:
--
{noformat}
$ grep -nrF "throw new IllegalArgumentException" .
./maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java:168:
throw new IllegalArgumentException( "remote repository manager has not
been specified" );
./maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java:178:
throw new IllegalArgumentException( "version resolver has not been
specified" );
./maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java:189:
throw new IllegalArgumentException( "version range resolver has not
been specified" );
./maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java:199:
throw new IllegalArgumentException( "artifact resolver has not been
specified" );
./maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java:209:
throw new IllegalArgumentException( "repository event dispatcher has
not been specified" );
./maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java:219:
throw new IllegalArgumentException( "model builder has not been
specified" );
./maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java:130:
throw new IllegalArgumentException( "metadata resolver has not been
specified" );
./maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java:140:
throw new IllegalArgumentException( "sync context factory has not been
specified" );
./maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java:150:
throw new IllegalArgumentException( "repository event dispatcher has not
been specified" );
./maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionResolver.java:142:
t
hrow new IllegalArgumentException( "metadata resolver has not been specified" );
./maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionResolver.java:152:
t
hrow new IllegalArgumentException( "sync context factory has not been
specified" );
./maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionResolver.java:162:
t
hrow new IllegalArgumentException( "repository event dispatcher has not been
specified" );
./maven-aether-provider/src/main/java/org/apache/maven/repository/internal/RelocatedArtifact.java:47:
throw n
ew IllegalArgumentException( "no artifact specified" );
./maven-artifact/src/main/java/org/apache/maven/artifact/ArtifactUtils.java:55:
throw new IllegalArgumentExce
ption( "version: null" );
./maven-core/src/main/java/org/apache/maven/artifact/repository/LegacyLocalRepositoryManager.java:93:
throw n
ew IllegalArgumentException( "local repository delegate missing" );
./maven-core/src/main/java/org/apache/maven/artifact/repository/metadata/io/DefaultMetadataReader.java:50:
th
row new IllegalArgumentException( "input file missing" );
./maven-core/src/main/java/org/apache/maven/artifact/repository/metadata/io/DefaultMetadataReader.java:63:
th
row new IllegalArgumentException( "input reader missing" );
./maven-core/src/main/java/org/apache/maven/artifact/repository/metadata/io/DefaultMetadataReader.java:86:
th
row new IllegalArgumentException( "input stream missing" );
./maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java:312:
throw new IllegalAr
gumentException( "model missing" );
./maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java:329:
throw new IllegalAr
gumentException( "extension plugin missing" );
./maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java:345:
throw new IllegalAr
gumentException( "plugin missing" );
./maven-core/src/main/java/org/apache/maven/configuration/DefaultBeanConfigurationRequest.java:125:
throw new
IllegalArgumentException( "group id for plugin has not been specified" );
./maven-core/src/main/java/org/apache/maven/configuration/DefaultBeanConfigurationRequest.java:129:
throw new
IllegalArgumentException( "artifact id for plugin has not been specified" );
./maven-core/src/main/java/org/apache/maven/configuration/internal/DefaultBeanConfigurator.java:58:
throw new
IllegalArgumentException( "bean configuration request not specified" );
./mave
[jira] (MNG-5649) Stop abusing IllegalArgumentException in case of null
[
https://jira.codehaus.org/browse/MNG-5649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348067#comment-348067
]
Jason van Zyl commented on MNG-5649:
Where exactly? I'd like to start using Guava's Preconditions class for these
sorts of checks.
> Stop abusing IllegalArgumentException in case of null
> -
>
> Key: MNG-5649
> URL: https://jira.codehaus.org/browse/MNG-5649
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Michael Osipov
>
> In several spots of Maven Core, IAE is thrown where an argument is null. This
> should be turned into {{NullPointerException}} since JDK adheres to is and
> the
> [description|http://docs.oracle.com/javase/6/docs/api/java/lang/NullPointerException.html]
> of this exception indicates that and Effective Java does that too.
> I possible fix version could next minor: 3.3. Is no one is opposed it could
> even be 3.2.2.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5647) ${maven.build.timestamp} uses incorrect ISO datetime separator
[
https://jira.codehaus.org/browse/MNG-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348066#comment-348066
]
Michael Osipov commented on MNG-5647:
-
OK, great. I am already working on it and want to add other test cases where
local time != UTC time. I would align it to the output of {{mvn --version}}.
That would make anything predictable and processable by tools and libs like
JodaTime/JSR 310.
> ${maven.build.timestamp} uses incorrect ISO datetime separator
> --
>
> Key: MNG-5647
> URL: https://jira.codehaus.org/browse/MNG-5647
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.2.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.2.2
>
>
> Separator must be {{T}} and not {{-}} if we predefine ISO 8601 datetime
> format. Additionally, {{Z}} should be added to denote UTC time zone.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5649) Stop abusing IllegalArgumentException in case of null
Michael Osipov created MNG-5649:
---
Summary: Stop abusing IllegalArgumentException in case of null
Key: MNG-5649
URL: https://jira.codehaus.org/browse/MNG-5649
Project: Maven 2 & 3
Issue Type: Bug
Affects Versions: 3.2.1
Reporter: Michael Osipov
In several spots of Maven Core, IAE is thrown where an argument is null. This
should be turned into {{NullPointerException}} since JDK adheres to is and the
[description|http://docs.oracle.com/javase/6/docs/api/java/lang/NullPointerException.html]
of this exception indicates that and Effective Java does that too.
I possible fix version could next minor: 3.3. Is no one is opposed it could
even be 3.2.2.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5648) Regression of MNG-5176, DST in effect is ignored
[
https://jira.codehaus.org/browse/MNG-5648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348064#comment-348064
]
Michael Osipov edited comment on MNG-5648 at 6/15/14 12:18 PM:
---
Fixed with 5c78a8d2faa99398b2a8170fd3cf804ae0385e94.
was (Author: michael-o):
Fixed with f794bf05c14cce3467da8649fdb0209c7f4bf65c.
> Regression of MNG-5176, DST in effect is ignored
>
>
> Key: MNG-5648
> URL: https://jira.codehaus.org/browse/MNG-5648
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.2.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 3.2.2
>
>
> When TZ offset is calculated, DST is completely ignored cause
> {{TimeZone#getRawOffset}} does not take DST into account.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5647) ${maven.build.timestamp} uses incorrect ISO datetime separator
[
https://jira.codehaus.org/browse/MNG-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348065#comment-348065
]
Jason van Zyl commented on MNG-5647:
I left what our's current is but you can change the format by using the
maven.build.timestamp.format property if you want to make it compliant. It is
not consistent even at Eclipse so as long as the TZ used is UTC and the format
is configurable anyone should be able to make it do what they like.
That said our SNAPSHOT format is decoupled from maven.build.timestamp so I
don't see any harm in making it ISO compliant.
> ${maven.build.timestamp} uses incorrect ISO datetime separator
> --
>
> Key: MNG-5647
> URL: https://jira.codehaus.org/browse/MNG-5647
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.2.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.2.2
>
>
> Separator must be {{T}} and not {{-}} if we predefine ISO 8601 datetime
> format. Additionally, {{Z}} should be added to denote UTC time zone.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5648) Regression of MNG-5176, DST in effect is ignored
[
https://jira.codehaus.org/browse/MNG-5648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-5648.
---
Resolution: Fixed
Fixed with f794bf05c14cce3467da8649fdb0209c7f4bf65c.
> Regression of MNG-5176, DST in effect is ignored
>
>
> Key: MNG-5648
> URL: https://jira.codehaus.org/browse/MNG-5648
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.2.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 3.2.2
>
>
> When TZ offset is calculated, DST is completely ignored cause
> {{TimeZone#getRawOffset}} does not take DST into account.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5648) Regression of MNG-5176, DST in effect is ignored
Michael Osipov created MNG-5648:
---
Summary: Regression of MNG-5176, DST in effect is ignored
Key: MNG-5648
URL: https://jira.codehaus.org/browse/MNG-5648
Project: Maven 2 & 3
Issue Type: Bug
Components: Command Line
Affects Versions: 3.2.1
Reporter: Michael Osipov
When TZ offset is calculated, DST is completely ignored cause
{{TimeZone#getRawOffset}} does not take DST into account.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5648) Regression of MNG-5176, DST in effect is ignored
[
https://jira.codehaus.org/browse/MNG-5648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-5648:
---
Assignee: Michael Osipov
> Regression of MNG-5176, DST in effect is ignored
>
>
> Key: MNG-5648
> URL: https://jira.codehaus.org/browse/MNG-5648
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.2.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 3.2.2
>
>
> When TZ offset is calculated, DST is completely ignored cause
> {{TimeZone#getRawOffset}} does not take DST into account.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5648) Regression of MNG-5176, DST in effect is ignored
[
https://jira.codehaus.org/browse/MNG-5648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-5648:
Fix Version/s: 3.2.2
> Regression of MNG-5176, DST in effect is ignored
>
>
> Key: MNG-5648
> URL: https://jira.codehaus.org/browse/MNG-5648
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.2.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 3.2.2
>
>
> When TZ offset is calculated, DST is completely ignored cause
> {{TimeZone#getRawOffset}} does not take DST into account.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNGSITE-152) Maven websites don't follow ASF rules on License
[ https://jira.codehaus.org/browse/MNGSITE-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348063#comment-348063 ] Karl-Heinz Marbaise commented on MNGSITE-152: - The links work not cause as you mentioned cause 2.9.1 is not released yet. Just VOTE started. Thanks for the feedback. > Maven websites don't follow ASF rules on License > > > Key: MNGSITE-152 > URL: https://jira.codehaus.org/browse/MNGSITE-152 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: SebbASF >Assignee: Karl-Heinz Marbaise > Attachments: screenshot-license.png > > > ASF projects are supposed to provide a prominent link [0] to the ASF licenses > page [1] > AIUI, websites are not supposed to provide their own license pages. > [0] http://apache.org/foundation/marks/pmcs.html#navigation > [1] http://www.apache.org/licenses/ -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNGSITE-152) Maven websites don't follow ASF rules on License
[ https://jira.codehaus.org/browse/MNGSITE-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348062#comment-348062 ] SebbASF commented on MNGSITE-152: - Looks good to me. The License link is to the correct page, and it is placed just above the download link, which means it should be obvious to people wishing to use the software. The download page also has a clear link to the source archive, plus sig and hash. The links don't actually work, but I assume that is because 2.9.1 has yet to be released. If I change 2.9.1 to 2.9 then the links do work OK. > Maven websites don't follow ASF rules on License > > > Key: MNGSITE-152 > URL: https://jira.codehaus.org/browse/MNGSITE-152 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: SebbASF >Assignee: Karl-Heinz Marbaise > Attachments: screenshot-license.png > > > ASF projects are supposed to provide a prominent link [0] to the ASF licenses > page [1] > AIUI, websites are not supposed to provide their own license pages. > [0] http://apache.org/foundation/marks/pmcs.html#navigation > [1] http://www.apache.org/licenses/ -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5647) ${maven.build.timestamp} uses incorrect ISO datetime separator
[
https://jira.codehaus.org/browse/MNG-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-5647:
Fix Version/s: 3.2.2
> ${maven.build.timestamp} uses incorrect ISO datetime separator
> --
>
> Key: MNG-5647
> URL: https://jira.codehaus.org/browse/MNG-5647
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.2.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.2.2
>
>
> Separator must be {{T}} and not {{-}} if we predefine ISO 8601 datetime
> format. Additionally, {{Z}} should be added to denote UTC time zone.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5647) ${maven.build.timestamp} uses incorrect ISO datetime separator
[
https://jira.codehaus.org/browse/MNG-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-5647:
---
Assignee: Michael Osipov
> ${maven.build.timestamp} uses incorrect ISO datetime separator
> --
>
> Key: MNG-5647
> URL: https://jira.codehaus.org/browse/MNG-5647
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.2.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.2.2
>
>
> Separator must be {{T}} and not {{-}} if we predefine ISO 8601 datetime
> format. Additionally, {{Z}} should be added to denote UTC time zone.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5647) ${maven.build.timestamp} uses incorrect ISO datetime separator
Michael Osipov created MNG-5647:
---
Summary: ${maven.build.timestamp} uses incorrect ISO datetime
separator
Key: MNG-5647
URL: https://jira.codehaus.org/browse/MNG-5647
Project: Maven 2 & 3
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 3.2.1
Reporter: Michael Osipov
Priority: Minor
Separator must be {{T}} and not {{-}} if we predefine ISO 8601 datetime format.
Additionally, {{Z}} should be added to denote UTC time zone.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5647) ${maven.build.timestamp} uses incorrect ISO datetime separator
[
https://jira.codehaus.org/browse/MNG-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348061#comment-348061
]
Michael Osipov commented on MNG-5647:
-
Spins off the fixes Jason made.
> ${maven.build.timestamp} uses incorrect ISO datetime separator
> --
>
> Key: MNG-5647
> URL: https://jira.codehaus.org/browse/MNG-5647
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.2.1
>Reporter: Michael Osipov
>Priority: Minor
> Fix For: 3.2.2
>
>
> Separator must be {{T}} and not {{-}} if we predefine ISO 8601 datetime
> format. Additionally, {{Z}} should be added to denote UTC time zone.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNGSITE-152) Maven websites don't follow ASF rules on License
[ https://jira.codehaus.org/browse/MNGSITE-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348060#comment-348060 ] Karl-Heinz Marbaise commented on MNGSITE-152: - Hi, can you check this example which is created a few hours ago if it fits the needs? http://maven.apache.org/plugins-archives/maven-ear-plugin-LATEST/ > Maven websites don't follow ASF rules on License > > > Key: MNGSITE-152 > URL: https://jira.codehaus.org/browse/MNGSITE-152 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: SebbASF >Assignee: Karl-Heinz Marbaise > Attachments: screenshot-license.png > > > ASF projects are supposed to provide a prominent link [0] to the ASF licenses > page [1] > AIUI, websites are not supposed to provide their own license pages. > [0] http://apache.org/foundation/marks/pmcs.html#navigation > [1] http://www.apache.org/licenses/ -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-188) Project property cannot be resolved inside element
[
https://jira.codehaus.org/browse/MEAR-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348059#comment-348059
]
Karl-Heinz Marbaise commented on MEAR-188:
--
At the moment i'm not 100% sure what exactly the cause for that...but i'll
continue to investigate it. May be my assumption is wrong. May be it's exactly
the difference using PlexusConfiguration or not so may be i need to change
this...I have an other plugin which works with PlexusConfiguration that's why
didn't understand the issue at the moment.
> Project property cannot be resolved inside element
> --
>
> Key: MEAR-188
> URL: https://jira.codehaus.org/browse/MEAR-188
> Project: Maven Ear Plugin
> Issue Type: Test
>Affects Versions: 2.9
>Reporter: Maciej Kara?
>Priority: Minor
> Fix For: 2.10
>
> Attachments: test.zip
>
>
> I have created simple ear project with filters. I want to use different
> settings for each environment and those settings should be passed to
> generated *application.xml* file inside the *env-entries*. The generation of
> ear package is done as shown below:
> {code:xml}
>
> maven-ear-plugin
> 2.9
>
> true
> 6
>
>
> customProperty
> java.lang.String
>
> ${custom.property}
>
>
> ${custom.property}
>
>
> {code}
> To read maven project properties from external properties file I had to use
> another plugin:
> [properties-maven-plugin|http://mojo.codehaus.org/properties-maven-plugin/].
> It successfully reads properties from file and sets them as maven project
> properties, so I can insert them in pom.xml file using *${}*. It works for
> most of the pom.xml elements (i.e. **), unfortunately it is
> not successfully looked up when I place it inside *env-entry* element where I
> need it. Below is generated *application.xml*.
> {code:xml}
>
> http://java.sun.com/xml/ns/javaee";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/application_6.xsd"; version="6">
> default property
> test
>
> customProperty
> java.lang.String
> ${custom.property}
>
>
> {code}
> If I put project properties inside the block
> everything works fine, but that doesn't allow me to use filters for
> *application.xml*.
> I'm attaching maven project with all necessary configuration. I have also
> submitted an issue at
> [Stackoverflow|http://stackoverflow.com/questions/23734249/maven-ear-plugin-project-property-lookup-fails],
> because I didn't have account here.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MEAR-188) Project property cannot be resolved inside element
[
https://jira.codehaus.org/browse/MEAR-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348058#comment-348058
]
Maciej Kara? commented on MEAR-188:
---
Thanks for your message. Could you explain why it works for *applicationName*
parameter and not with *envEntry*? Someone on Stackoverflow said that it is due
to fact that envEntries are load through PlexusConfiguration thus the dynamic
project properties are not read.
> Project property cannot be resolved inside element
> --
>
> Key: MEAR-188
> URL: https://jira.codehaus.org/browse/MEAR-188
> Project: Maven Ear Plugin
> Issue Type: Test
>Affects Versions: 2.9
>Reporter: Maciej Kara?
>Priority: Minor
> Fix For: 2.10
>
> Attachments: test.zip
>
>
> I have created simple ear project with filters. I want to use different
> settings for each environment and those settings should be passed to
> generated *application.xml* file inside the *env-entries*. The generation of
> ear package is done as shown below:
> {code:xml}
>
> maven-ear-plugin
> 2.9
>
> true
> 6
>
>
> customProperty
> java.lang.String
>
> ${custom.property}
>
>
> ${custom.property}
>
>
> {code}
> To read maven project properties from external properties file I had to use
> another plugin:
> [properties-maven-plugin|http://mojo.codehaus.org/properties-maven-plugin/].
> It successfully reads properties from file and sets them as maven project
> properties, so I can insert them in pom.xml file using *${}*. It works for
> most of the pom.xml elements (i.e. **), unfortunately it is
> not successfully looked up when I place it inside *env-entry* element where I
> need it. Below is generated *application.xml*.
> {code:xml}
>
> http://java.sun.com/xml/ns/javaee";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/application_6.xsd"; version="6">
> default property
> test
>
> customProperty
> java.lang.String
> ${custom.property}
>
>
> {code}
> If I put project properties inside the block
> everything works fine, but that doesn't allow me to use filters for
> *application.xml*.
> I'm attaching maven project with all necessary configuration. I have also
> submitted an issue at
> [Stackoverflow|http://stackoverflow.com/questions/23734249/maven-ear-plugin-project-property-lookup-fails],
> because I didn't have account here.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5593) Plugin Errors are not handled
[ https://jira.codehaus.org/browse/MNG-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348056#comment-348056 ] Jason van Zyl commented on MNG-5593: Please add a self-contained example project please. > Plugin Errors are not handled > - > > Key: MNG-5593 > URL: https://jira.codehaus.org/browse/MNG-5593 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.2.1 >Reporter: Michael Schnupp >Priority: Critical > > The > [DefaultBuildPluginManager|https://maven.apache.org/ref/3.2.1/maven-core/xref/org/apache/maven/plugin/DefaultBuildPluginManager.html#L133] > executes the plugin mojo and catches all kind of exceptions. > However if the plugin throws some Error, it is not catched and maven > continues like everything went fine. > Shouldn't maven handle Errors and stop the build in that case? > (see also IZPACK-1050) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5599) Using -am and -amd does not include all necessary dependencies
[ https://jira.codehaus.org/browse/MNG-5599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348053#comment-348053 ] Jason van Zyl commented on MNG-5599: If you can create a pull request and take a look at http://takari.io/2014/06/02/contributing-to-maven-core.html I will take a look this week. > Using -am and -amd does not include all necessary dependencies > -- > > Key: MNG-5599 > URL: https://jira.codehaus.org/browse/MNG-5599 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.1 >Reporter: Christopher Mosher > Attachments: MNG-5599.patch, mvn_amd_bug.tar.gz > > > If I have a module APP1 that depends on two other modules LIB1 and LIB2, all > in multi-mode project, and I try to rebuild LIB1 with -am and -amd, then when > maven tries to build APP1 (due to -amd), it cannot find LIB2, and the build > fails with "The POM for LIB2 is missing". See attached project for use case > (test.sh). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5598) Environment variables must be written in UPPER CASE
[
https://jira.codehaus.org/browse/MNG-5598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348054#comment-348054
]
Jason van Zyl commented on MNG-5598:
Can you please make an example test project to demonstrate the problem.
> Environment variables must be written in UPPER CASE
> ---
>
> Key: MNG-5598
> URL: https://jira.codehaus.org/browse/MNG-5598
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 3.0.4
> Environment: Windows
>Reporter: Markus KARG
>
> On Windows, it is valid and common practice to define environment variables
> with mixed case names, e. g. SystemDrive, SystemRoot, ProgramData, etc.
> When writing such mixed case names in the pom.xml, these cannot be resolved
> but will be used as string literals. For example, the popular exec plugin
> from codehaus mojo project complains it cannot find the executable at
> LITERALLY ${env.MSDevDir}/Bin/MSDEV.exe, while actually that variable is
> defined in exactly that mixed case name, and points to the existing
> executable. Once MSDevDir is replaced in the (wrong!) UPPER CASE form of
> ${env.MSDEVDIR}, then the executable is found, which is weird!
> While the MavenPropertiesGuide
> (http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide) actually
> only shows examples using UPPER CASE environment variables, it does not
> clearly say that this is an enforced restriction. Hence, either this is a bug
> in the Maven software (i. e. it unintentionally expects UPPER CASE), or it is
> to be clearly said in the properties guide that UPPER CASE is a wanted
> constrained of Maven.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5594) Show current/total project number in reactor during build
[
https://jira.codehaus.org/browse/MNG-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348055#comment-348055
]
Jason van Zyl commented on MNG-5594:
If you are building in parallel mode I'm not sure how useful this is. In the
final output do you just want to see how many projects in total were built out
of all the available projects before failure?
> Show current/total project number in reactor during build
> -
>
> Key: MNG-5594
> URL: https://jira.codehaus.org/browse/MNG-5594
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: General
>Affects Versions: 3.2.x
>Reporter: Grzegorz Grzybek
>Priority: Minor
> Attachments: project-progress.diff
>
>
> While building long projects, containing hundreds of modules it would be nice
> to see how far did we get.
> For example, the build might look like this:
> {noformat}
> ...
> [INFO]
>
> [INFO] Building Maven Compat 3.2.2-SNAPSHOT (11/13)
> [INFO]
>
> [INFO]
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Maven Embedder 3.2.2-SNAPSHOT (12/13)
> [INFO]
>
> [INFO]
> ...
> {noformat}
> Please find attached a naive implementation here: [^project-progress.diff].
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5601) multimodule plugin configuration e.g. "build-tools" pattern broken
[ https://jira.codehaus.org/browse/MNG-5601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348052#comment-348052 ] Jason van Zyl commented on MNG-5601: Yup, this looks like a bug in how the graph is created. > multimodule plugin configuration e.g. "build-tools" pattern broken > -- > > Key: MNG-5601 > URL: https://jira.codehaus.org/browse/MNG-5601 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies, Plugins and Lifecycle >Affects Versions: 3.2.1 >Reporter: Matt Benson > Attachments: cyclic-ref-test.tar.gz > > > The recommendation at > https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html > breaks down in projects that use the pattern more than once, e.g. for > checkstyle/findbugs/PMD alike. I have boiled this down to a super-simple test > project that defines a build-tools module, and in separate profiles declares > each of these plugins with a dependency on that submodule. Activating any one > of these profiles and calling `mvn validate` works fine, but as soon as you > activate two or more of them the command fails with "The projects in the > reactor contain a cyclic reference". -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5604) make it possible to mark a maven module as deprected
[
https://jira.codehaus.org/browse/MNG-5604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348051#comment-348051
]
Jason van Zyl commented on MNG-5604:
I agree this can be done with the enforcer plugin.
> make it possible to mark a maven module as deprected
>
>
> Key: MNG-5604
> URL: https://jira.codehaus.org/browse/MNG-5604
> Project: Maven 2 & 3
> Issue Type: Wish
> Components: Artifacts and Repositories
>Affects Versions: 3.2.1
>Reporter: Klaus Claszen
>Priority: Minor
> Labels: build, pom.xml
>
> It would be great if it would be possible to mark a maven module as
> 'deprecated'. It would help to document that a module is outdated. The
> information could be used during build processes to show warnings and guide
> the user to a better alternative.
> Maybe it could be a pom enhancement linke this
> {code:xml}
>
> not maintained anymore
>
> foo
> bar
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5604) make it possible to mark a maven module as deprected
[
https://jira.codehaus.org/browse/MNG-5604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-5604.
--
Resolution: Won't Fix
> make it possible to mark a maven module as deprected
>
>
> Key: MNG-5604
> URL: https://jira.codehaus.org/browse/MNG-5604
> Project: Maven 2 & 3
> Issue Type: Wish
> Components: Artifacts and Repositories
>Affects Versions: 3.2.1
>Reporter: Klaus Claszen
>Priority: Minor
> Labels: build, pom.xml
>
> It would be great if it would be possible to mark a maven module as
> 'deprecated'. It would help to document that a module is outdated. The
> information could be used during build processes to show warnings and guide
> the user to a better alternative.
> Maybe it could be a pom enhancement linke this
> {code:xml}
>
> not maintained anymore
>
> foo
> bar
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5635) No info generated for nested classes in mojo config
[ https://jira.codehaus.org/browse/MNG-5635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348050#comment-348050 ] Axel Fontaine commented on MNG-5635: Maybe nested parameter elements like this: myparam com.company.MyClass false true ... mynestedparam java.lang.String[] false true ... ... > No info generated for nested classes in mojo config > --- > > Key: MNG-5635 > URL: https://jira.codehaus.org/browse/MNG-5635 > Project: Maven 2 & 3 > Issue Type: Bug > Components: IDEs, Plugin API, Plugins and Lifecycle >Affects Versions: 3.2.1 >Reporter: Axel Fontaine > > For more advanced plugins, it is nice to have nested objects in order to > group settings > (http://maven.apache.org/guides/plugin/guide-java-plugin-development.html#Other_Object_Classes) > Currently the metadata for these does not get generated nor included in > plugin.xml (even though it is present in the original class). > This in turn leads to IDEs not being able to offer completion, documentation, > validation, ... for these attributes, hindering reliability and > discoverability, two of Maven's primary strengths. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5634) Import scope is not respected in profiles
[
https://jira.codehaus.org/browse/MNG-5634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-5634:
---
Assignee: Jason van Zyl
> Import scope is not respected in profiles
> -
>
> Key: MNG-5634
> URL: https://jira.codehaus.org/browse/MNG-5634
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies, Inheritance and Interpolation
>Affects Versions: 3.0.5
>Reporter: Christian Koppen
>Assignee: Jason van Zyl
> Attachments: import-scope-in-profile.zip
>
>
> The {{import}} scope does not work as expected when used in a scenario with
> inheritance and profiles.
> Please have a look at the attached testcase to understand the problem.
> We have a project POM that declares a dependency. The scope of this
> dependency ({{runtime}}) is imported from a BOM POM ({{runtime-bom}}). The
> project POM has a parent POM which defines two profiles. In the first profile
> ({{direct}}), the scope of the dependency is set to {{provided}}. In the
> second profile ({{bom}}), another BOM POM ({{provided-pom}}) is imported that
> defines the scope of the dependency as {{provided}}.
> When maven is executed without defining profiles, the dependency is resolved
> in scope {{runtime}}. This is what I expect.
> When maven is executed with profile {{direct}}, the dependency is resolved in
> scope {{provided}}. This is what I expect.
> When maven is executed with profile {{bom}}, the dependency is resolved in
> scope {{runtime}}. I expect the scope to be {{provided}}.
> The
> [documentation|http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope]
> states that a dependency with scope {{import}} is *replaced* by the
> {{dependencyManagement}}-block of the imported POM. This is not true in this
> case.
> Output from the command line:
> {noformat}
> import-scope-in-profile\project>mvn -Pdirect dependency:tree
> [INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ project ---
> [INFO] org.apache.maven.issues:project:jar:1.0-SNAPSHOT
> [INFO] \- org.apache.maven.issues:dependency:jar:1.0-SNAPSHOT:provided
> import-scope-in-profile\project>mvn -Pbom dependency:tree
> [INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ project ---
> [INFO] org.apache.maven.issues:project:jar:1.0-SNAPSHOT
> [INFO] \- org.apache.maven.issues:dependency:jar:1.0-SNAPSHOT:runtime
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5635) No info generated for nested classes in mojo config
[ https://jira.codehaus.org/browse/MNG-5635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348049#comment-348049 ] Jason van Zyl commented on MNG-5635: I think here we can just introspect the class in the IDE which isn't terribly expensive. What would the plugin.xml look like in your opinion? Can you provide an example? > No info generated for nested classes in mojo config > --- > > Key: MNG-5635 > URL: https://jira.codehaus.org/browse/MNG-5635 > Project: Maven 2 & 3 > Issue Type: Bug > Components: IDEs, Plugin API, Plugins and Lifecycle >Affects Versions: 3.2.1 >Reporter: Axel Fontaine > > For more advanced plugins, it is nice to have nested objects in order to > group settings > (http://maven.apache.org/guides/plugin/guide-java-plugin-development.html#Other_Object_Classes) > Currently the metadata for these does not get generated nor included in > plugin.xml (even though it is present in the original class). > This in turn leads to IDEs not being able to offer completion, documentation, > validation, ... for these attributes, hindering reliability and > discoverability, two of Maven's primary strengths. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-153) Skinny Modules -- not just WARs
[ https://jira.codehaus.org/browse/MEAR-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MEAR-153: - Issue Type: New Feature (was: Improvement) > Skinny Modules -- not just WARs > --- > > Key: MEAR-153 > URL: https://jira.codehaus.org/browse/MEAR-153 > Project: Maven Ear Plugin > Issue Type: New Feature >Affects Versions: 2.7 >Reporter: Roland Asmann > Fix For: more-investigation > > Attachments: AbstractEarModule.java.patch, SarModule.java.patch > > > Currently it is only possible to have the plugin filter WARs to get them > 'skinny', however this could be very useful for other modules as well! > In my project I have both a WAR and a SAR that should share several > libraries. As standalone artifacts, they should both package it themselves, > but in the deployed EAR I get classloading-errors when they don't have the > libs shared in the EAR. > I traced a solution to the method 'EarModule.getLibDir()', which is only > implemented with a value in the 'WebModule'-subclass. > Since I am not familiar with all the module-types, I attached a solution that > ONLY handles the SarModule, but this can probably used in all other Modules > that contain libs as well. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-153) Skinny Modules -- not just WARs
[ https://jira.codehaus.org/browse/MEAR-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MEAR-153: - Fix Version/s: more-investigation > Skinny Modules -- not just WARs > --- > > Key: MEAR-153 > URL: https://jira.codehaus.org/browse/MEAR-153 > Project: Maven Ear Plugin > Issue Type: New Feature >Affects Versions: 2.7 >Reporter: Roland Asmann > Fix For: more-investigation > > Attachments: AbstractEarModule.java.patch, SarModule.java.patch > > > Currently it is only possible to have the plugin filter WARs to get them > 'skinny', however this could be very useful for other modules as well! > In my project I have both a WAR and a SAR that should share several > libraries. As standalone artifacts, they should both package it themselves, > but in the deployed EAR I get classloading-errors when they don't have the > libs shared in the EAR. > I traced a solution to the method 'EarModule.getLibDir()', which is only > implemented with a value in the 'WebModule'-subclass. > Since I am not familiar with all the module-types, I attached a solution that > ONLY handles the SarModule, but this can probably used in all other Modules > that contain libs as well. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-166) 'skinnyWar' doesn't work well with dependencies of type 'ejb'
[
https://jira.codehaus.org/browse/MEAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348048#comment-348048
]
Karl-Heinz Marbaise edited comment on MEAR-166 at 6/15/14 8:00 AM:
---
Created an [example
project|https://github.com/khmarbaise/mear/tree/master/MEAR-166] which shows
the wrong behaviour:
{code}
ear-module/target/ear-module-1.0
|-- META-INF
| `-- application.xml
|-- ejb-module-1.0.jar
|-- lib
| `-- commons-lang-2.5.jar
`-- war-module-1.0.war
{code}
unfortunately the war file contains the ejb jar file:
{code}
Archive: ear-module/target/ear-module-1.0/war-module-1.0.war
testing: META-INF/OK
testing: META-INF/maven/ OK
testing: META-INF/maven/org.apache.maven.its.ear.skinnywars/ OK
testing: META-INF/maven/org.apache.maven.its.ear.skinnywars/war-module/ OK
testing: WEB-INF/ OK
testing: WEB-INF/classes/ OK
testing: WEB-INF/lib/ OK
testing: META-INF/INDEX.LIST OK
testing: META-INF/MANIFEST.MF OK
testing:
META-INF/maven/org.apache.maven.its.ear.skinnywars/war-module/pom.properties
OK
testing:
META-INF/maven/org.apache.maven.its.ear.skinnywars/war-module/pom.xml OK
**testing: WEB-INF/lib/ejb-module-1.0.jar OK**
testing: WEB-INF/web.xml OK
{code}
So taking a deeper look into the code it is not supported at the moment. The
questions is: Does this make sense? Defining the dep on ejb within the war
module which itself will be put into EAR ? (I'm not sure about that kind of use
case. Has someone a good example for this? In my opinion using a ejb-client as
a dep in the war module would make more sense to me.
was (Author: khmarbaise):
Created an [example
project|https://github.com/khmarbaise/mear/tree/master/MEAR-166] which shows
the wrong behaviour:
{code}
ear-module/target/ear-module-1.0
|-- META-INF
| `-- application.xml
|-- ejb-module-1.0.jar
|-- lib
| `-- commons-lang-2.5.jar
`-- war-module-1.0.war
{code}
unfortunately the war file contains the ejb jar file:
{code}
Archive: ear-module/target/ear-module-1.0/war-module-1.0.war
testing: META-INF/OK
testing: META-INF/maven/ OK
testing: META-INF/maven/org.apache.maven.its.ear.skinnywars/ OK
testing: META-INF/maven/org.apache.maven.its.ear.skinnywars/war-module/ OK
testing: WEB-INF/ OK
testing: WEB-INF/classes/ OK
testing: WEB-INF/lib/ OK
testing: META-INF/INDEX.LIST OK
testing: META-INF/MANIFEST.MF OK
testing:
META-INF/maven/org.apache.maven.its.ear.skinnywars/war-module/pom.properties
OK
testing:
META-INF/maven/org.apache.maven.its.ear.skinnywars/war-module/pom.xml OK
**testing: WEB-INF/lib/ejb-module-1.0.jar OK**
testing: WEB-INF/web.xml OK
{code}
So taking a deeper look into the code it is not supported at the moment. The
questions is: Does this make sense? Defining the dep on ejb within the war
module which itself will be put into EAR ? (I'm not sure about that kind of use
case. Has someone a good example for this?
> 'skinnyWar' doesn't work well with dependencies of type 'ejb'
> -
>
> Key: MEAR-166
> URL: https://jira.codehaus.org/browse/MEAR-166
> Project: Maven Ear Plugin
> Issue Type: New Feature
>Affects Versions: 2.8, 2.9
> Environment: many different environments I've verified this on
>Reporter: Michal Michalski
>Priority: Minor
> Fix For: more-investigation
>
>
> It seems that 'skinnyWar' works OK with dependencies of type 'jar', but it
> does left 'ejb' dependencies in WEB-INF/lib. Finally, these dependencies
> exist both in EAR's lib dir and WEB-INF/lib within WAR, when using classic
> trick with both 'war'-type and 'pom'-type dependency to WAR, so all WAR's
> dependencies should go to EAR's lib.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MEAR-166) 'skinnyWar' doesn't work well with dependencies of type 'ejb'
[ https://jira.codehaus.org/browse/MEAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MEAR-166: - Fix Version/s: more-investigation > 'skinnyWar' doesn't work well with dependencies of type 'ejb' > - > > Key: MEAR-166 > URL: https://jira.codehaus.org/browse/MEAR-166 > Project: Maven Ear Plugin > Issue Type: New Feature >Affects Versions: 2.8, 2.9 > Environment: many different environments I've verified this on >Reporter: Michal Michalski >Priority: Minor > Fix For: more-investigation > > > It seems that 'skinnyWar' works OK with dependencies of type 'jar', but it > does left 'ejb' dependencies in WEB-INF/lib. Finally, these dependencies > exist both in EAR's lib dir and WEB-INF/lib within WAR, when using classic > trick with both 'war'-type and 'pom'-type dependency to WAR, so all WAR's > dependencies should go to EAR's lib. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-166) 'skinnyWar' doesn't work well with dependencies of type 'ejb'
[ https://jira.codehaus.org/browse/MEAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MEAR-166: - Issue Type: New Feature (was: Bug) > 'skinnyWar' doesn't work well with dependencies of type 'ejb' > - > > Key: MEAR-166 > URL: https://jira.codehaus.org/browse/MEAR-166 > Project: Maven Ear Plugin > Issue Type: New Feature >Affects Versions: 2.8, 2.9 > Environment: many different environments I've verified this on >Reporter: Michal Michalski >Priority: Minor > > It seems that 'skinnyWar' works OK with dependencies of type 'jar', but it > does left 'ejb' dependencies in WEB-INF/lib. Finally, these dependencies > exist both in EAR's lib dir and WEB-INF/lib within WAR, when using classic > trick with both 'war'-type and 'pom'-type dependency to WAR, so all WAR's > dependencies should go to EAR's lib. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-166) 'skinnyWar' doesn't work well with dependencies of type 'ejb'
[ https://jira.codehaus.org/browse/MEAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MEAR-166: - Priority: Minor (was: Major) > 'skinnyWar' doesn't work well with dependencies of type 'ejb' > - > > Key: MEAR-166 > URL: https://jira.codehaus.org/browse/MEAR-166 > Project: Maven Ear Plugin > Issue Type: Bug >Affects Versions: 2.8, 2.9 > Environment: many different environments I've verified this on >Reporter: Michal Michalski >Priority: Minor > > It seems that 'skinnyWar' works OK with dependencies of type 'jar', but it > does left 'ejb' dependencies in WEB-INF/lib. Finally, these dependencies > exist both in EAR's lib dir and WEB-INF/lib within WAR, when using classic > trick with both 'war'-type and 'pom'-type dependency to WAR, so all WAR's > dependencies should go to EAR's lib. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-166) 'skinnyWar' doesn't work well with dependencies of type 'ejb'
[
https://jira.codehaus.org/browse/MEAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348048#comment-348048
]
Karl-Heinz Marbaise edited comment on MEAR-166 at 6/15/14 7:56 AM:
---
Created an [example
project|https://github.com/khmarbaise/mear/tree/master/MEAR-166] which shows
the wrong behaviour:
{code}
ear-module/target/ear-module-1.0
|-- META-INF
| `-- application.xml
|-- ejb-module-1.0.jar
|-- lib
| `-- commons-lang-2.5.jar
`-- war-module-1.0.war
{code}
unfortunately the war file contains the ejb jar file:
{code}
Archive: ear-module/target/ear-module-1.0/war-module-1.0.war
testing: META-INF/OK
testing: META-INF/maven/ OK
testing: META-INF/maven/org.apache.maven.its.ear.skinnywars/ OK
testing: META-INF/maven/org.apache.maven.its.ear.skinnywars/war-module/ OK
testing: WEB-INF/ OK
testing: WEB-INF/classes/ OK
testing: WEB-INF/lib/ OK
testing: META-INF/INDEX.LIST OK
testing: META-INF/MANIFEST.MF OK
testing:
META-INF/maven/org.apache.maven.its.ear.skinnywars/war-module/pom.properties
OK
testing:
META-INF/maven/org.apache.maven.its.ear.skinnywars/war-module/pom.xml OK
**testing: WEB-INF/lib/ejb-module-1.0.jar OK**
testing: WEB-INF/web.xml OK
{code}
So taking a deeper look into the code it is not supported at the moment. The
questions is: Does this make sense? Defining the dep on ejb within the war
module which itself will be put into EAR ? (I'm not sure about that kind of use
case. Has someone a good example for this?
was (Author: khmarbaise):
Created an [example
project|https://github.com/khmarbaise/mear/tree/master/MEAR-166] which shows
the wrong behaviour:
{code}
ear-module/target/ear-module-1.0
|-- META-INF
| `-- application.xml
|-- ejb-module-1.0.jar
|-- lib
| `-- commons-lang-2.5.jar
`-- war-module-1.0.war
{code}
unfortunately the war file contains the ejb jar file:
{code}
Archive: ear-module/target/ear-module-1.0/war-module-1.0.war
testing: META-INF/OK
testing: META-INF/maven/ OK
testing: META-INF/maven/org.apache.maven.its.ear.skinnywars/ OK
testing: META-INF/maven/org.apache.maven.its.ear.skinnywars/war-module/ OK
testing: WEB-INF/ OK
testing: WEB-INF/classes/ OK
testing: WEB-INF/lib/ OK
testing: META-INF/INDEX.LIST OK
testing: META-INF/MANIFEST.MF OK
testing:
META-INF/maven/org.apache.maven.its.ear.skinnywars/war-module/pom.properties
OK
testing:
META-INF/maven/org.apache.maven.its.ear.skinnywars/war-module/pom.xml OK
**testing: WEB-INF/lib/ejb-module-1.0.jar OK**
testing: WEB-INF/web.xml OK
{code}
> 'skinnyWar' doesn't work well with dependencies of type 'ejb'
> -
>
> Key: MEAR-166
> URL: https://jira.codehaus.org/browse/MEAR-166
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.8, 2.9
> Environment: many different environments I've verified this on
>Reporter: Michal Michalski
>
> It seems that 'skinnyWar' works OK with dependencies of type 'jar', but it
> does left 'ejb' dependencies in WEB-INF/lib. Finally, these dependencies
> exist both in EAR's lib dir and WEB-INF/lib within WAR, when using classic
> trick with both 'war'-type and 'pom'-type dependency to WAR, so all WAR's
> dependencies should go to EAR's lib.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MEAR-166) 'skinnyWar' doesn't work well with dependencies of type 'ejb'
[ https://jira.codehaus.org/browse/MEAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MEAR-166: - Affects Version/s: 2.9 > 'skinnyWar' doesn't work well with dependencies of type 'ejb' > - > > Key: MEAR-166 > URL: https://jira.codehaus.org/browse/MEAR-166 > Project: Maven Ear Plugin > Issue Type: Bug >Affects Versions: 2.8, 2.9 > Environment: many different environments I've verified this on >Reporter: Michal Michalski > > It seems that 'skinnyWar' works OK with dependencies of type 'jar', but it > does left 'ejb' dependencies in WEB-INF/lib. Finally, these dependencies > exist both in EAR's lib dir and WEB-INF/lib within WAR, when using classic > trick with both 'war'-type and 'pom'-type dependency to WAR, so all WAR's > dependencies should go to EAR's lib. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-166) 'skinnyWar' doesn't work well with dependencies of type 'ejb'
[
https://jira.codehaus.org/browse/MEAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348048#comment-348048
]
Karl-Heinz Marbaise commented on MEAR-166:
--
Created an [example
project|https://github.com/khmarbaise/mear/tree/master/MEAR-166] which shows
the wrong behaviour:
{code}
ear-module/target/ear-module-1.0
|-- META-INF
| `-- application.xml
|-- ejb-module-1.0.jar
|-- lib
| `-- commons-lang-2.5.jar
`-- war-module-1.0.war
{code}
unfortunately the war file contains the ejb jar file:
{code}
Archive: ear-module/target/ear-module-1.0/war-module-1.0.war
testing: META-INF/OK
testing: META-INF/maven/ OK
testing: META-INF/maven/org.apache.maven.its.ear.skinnywars/ OK
testing: META-INF/maven/org.apache.maven.its.ear.skinnywars/war-module/ OK
testing: WEB-INF/ OK
testing: WEB-INF/classes/ OK
testing: WEB-INF/lib/ OK
testing: META-INF/INDEX.LIST OK
testing: META-INF/MANIFEST.MF OK
testing:
META-INF/maven/org.apache.maven.its.ear.skinnywars/war-module/pom.properties
OK
testing:
META-INF/maven/org.apache.maven.its.ear.skinnywars/war-module/pom.xml OK
**testing: WEB-INF/lib/ejb-module-1.0.jar OK**
testing: WEB-INF/web.xml OK
{code}
> 'skinnyWar' doesn't work well with dependencies of type 'ejb'
> -
>
> Key: MEAR-166
> URL: https://jira.codehaus.org/browse/MEAR-166
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.8
> Environment: many different environments I've verified this on
>Reporter: Michal Michalski
>
> It seems that 'skinnyWar' works OK with dependencies of type 'jar', but it
> does left 'ejb' dependencies in WEB-INF/lib. Finally, these dependencies
> exist both in EAR's lib dir and WEB-INF/lib within WAR, when using classic
> trick with both 'war'-type and 'pom'-type dependency to WAR, so all WAR's
> dependencies should go to EAR's lib.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MEAR-182) Skinny WAR's - Skip Class-Path Modification in Manifest
[ https://jira.codehaus.org/browse/MEAR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MEAR-182: - Fix Version/s: 2.10 > Skinny WAR's - Skip Class-Path Modification in Manifest > --- > > Key: MEAR-182 > URL: https://jira.codehaus.org/browse/MEAR-182 > Project: Maven Ear Plugin > Issue Type: Improvement >Affects Versions: 2.9 >Reporter: Mario Däpp > Fix For: 2.10 > > Attachments: MEAR-182-patch.txt > > > From Java EE 5, a library directory may be specified in the application.xml > (element library-directory). The Maven EAR Plugin already supports this for > generating the application.xml (value of property defaultLibBundleDir). > The Java EE 5 specification mandates that all JAR files contained in the > library directory be made available to all modules within the EAR file (cf. > chapter EE.8.2.1 Bundled Libraries, section 2). > If one specifies both the skinnyWars (value = true) and defaultLibBundleDir > parameters, the libraries will be removed from the WAR and copied to the > defaultLibBundleDir. They will also be added to the Class-Path in the WAR > files manifest. This is unnecessary as per the Java EE 5 specification. Even > worse, it breaks my EAR on WebLogic (classloading issues). > I therefore propose the following improvement to the skinny WAR's > functionality: If the Java EE version is 5 or greater and the > defaultLibBundleDir has been specified, the Class-Path in the WAR's manifest > should remain unchanged. > I've created a corresponding patch and integration test. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-170) EAR plugin will emit invalid application.xml (without needing user override)
[ https://jira.codehaus.org/browse/MEAR-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MEAR-170: - Fix Version/s: more-investigation > EAR plugin will emit invalid application.xml (without needing user override) > > > Key: MEAR-170 > URL: https://jira.codehaus.org/browse/MEAR-170 > Project: Maven Ear Plugin > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Darryl L. Miles > Fix For: more-investigation > > > The DTD/XSD for the application.xml indicates that it must contain both a > and at least one element. > Maven EAR plugin will emit by default, this bug ticket has no > concerns there. > But it is easy to configure it up with no valid . > The plugin should have a new user-configurable attribute to enforce > application.xml DTD/XSD rules. It should be in enforcing mode by default (so > the plugin will cause a build error if the configuration causes an invalid > application.xml to be emitted). > When this situation is detected the user should be informed in the Maven > error message that to override this check they can set > -DenforceWellFormedApplicationXml=false > The above information may not be correct for all EE versions of > application.xml so for each EE version the rule(s) should be checked. > But Maven by default should not be emitting invalid XML data, without the > user overriding this check manually. > There is also a use case to allow not emitting an application.xml at all when > there is no configuration (no set). However again this should not > be the default, if the user is using the EAR plugin they expect it to produce > a well formed EAR artifact (and provide assistance towards that goal, by > displaying appropriate error messages when they do something wrong). This > means the default should be to always need to create an application.xml. > Which then means they must configure the maven-ear-plugin correctly to > achieve that goal (and not get a build failure). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-188) Project property cannot be resolved inside element
[
https://jira.codehaus.org/browse/MEAR-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348047#comment-348047
]
Karl-Heinz Marbaise edited comment on MEAR-188 at 6/15/14 7:17 AM:
---
After taking a deeper look into that. This a bug of the properties-maven-plugin
cause if the properties are being defined within the pom it works with no
problem only if the were read by the properties-maven-plugin it does not work.
So it's not a bug for maven-ear-plugin. Created one for
[properties-maven-plugin|http://jira.codehaus.org/browse/MOJO-2033].
was (Author: khmarbaise):
After taking a deeper look into that this a bug of the properties-maven-plugin
cause if the properties are being defined within the pom it works with no
problem only if the were read by the properties-maven-plugin it does not work.
So it's not a bug for maven-ear-plugin. Create one for
[properties-maven-plugin|http://jira.codehaus.org/browse/MOJO-2033].
> Project property cannot be resolved inside element
> --
>
> Key: MEAR-188
> URL: https://jira.codehaus.org/browse/MEAR-188
> Project: Maven Ear Plugin
> Issue Type: Test
>Affects Versions: 2.9
>Reporter: Maciej Kara?
>Priority: Minor
> Fix For: 2.10
>
> Attachments: test.zip
>
>
> I have created simple ear project with filters. I want to use different
> settings for each environment and those settings should be passed to
> generated *application.xml* file inside the *env-entries*. The generation of
> ear package is done as shown below:
> {code:xml}
>
> maven-ear-plugin
> 2.9
>
> true
> 6
>
>
> customProperty
> java.lang.String
>
> ${custom.property}
>
>
> ${custom.property}
>
>
> {code}
> To read maven project properties from external properties file I had to use
> another plugin:
> [properties-maven-plugin|http://mojo.codehaus.org/properties-maven-plugin/].
> It successfully reads properties from file and sets them as maven project
> properties, so I can insert them in pom.xml file using *${}*. It works for
> most of the pom.xml elements (i.e. **), unfortunately it is
> not successfully looked up when I place it inside *env-entry* element where I
> need it. Below is generated *application.xml*.
> {code:xml}
>
> http://java.sun.com/xml/ns/javaee";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/application_6.xsd"; version="6">
> default property
> test
>
> customProperty
> java.lang.String
> ${custom.property}
>
>
> {code}
> If I put project properties inside the block
> everything works fine, but that doesn't allow me to use filters for
> *application.xml*.
> I'm attaching maven project with all necessary configuration. I have also
> submitted an issue at
> [Stackoverflow|http://stackoverflow.com/questions/23734249/maven-ear-plugin-project-property-lookup-fails],
> because I didn't have account here.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MEAR-188) Project property cannot be resolved inside element
[
https://jira.codehaus.org/browse/MEAR-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise updated MEAR-188:
-
Priority: Minor (was: Major)
> Project property cannot be resolved inside element
> --
>
> Key: MEAR-188
> URL: https://jira.codehaus.org/browse/MEAR-188
> Project: Maven Ear Plugin
> Issue Type: Test
>Affects Versions: 2.9
>Reporter: Maciej Kara?
>Priority: Minor
> Fix For: 2.10
>
> Attachments: test.zip
>
>
> I have created simple ear project with filters. I want to use different
> settings for each environment and those settings should be passed to
> generated *application.xml* file inside the *env-entries*. The generation of
> ear package is done as shown below:
> {code:xml}
>
> maven-ear-plugin
> 2.9
>
> true
> 6
>
>
> customProperty
> java.lang.String
>
> ${custom.property}
>
>
> ${custom.property}
>
>
> {code}
> To read maven project properties from external properties file I had to use
> another plugin:
> [properties-maven-plugin|http://mojo.codehaus.org/properties-maven-plugin/].
> It successfully reads properties from file and sets them as maven project
> properties, so I can insert them in pom.xml file using *${}*. It works for
> most of the pom.xml elements (i.e. **), unfortunately it is
> not successfully looked up when I place it inside *env-entry* element where I
> need it. Below is generated *application.xml*.
> {code:xml}
>
> http://java.sun.com/xml/ns/javaee";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/application_6.xsd"; version="6">
> default property
> test
>
> customProperty
> java.lang.String
> ${custom.property}
>
>
> {code}
> If I put project properties inside the block
> everything works fine, but that doesn't allow me to use filters for
> *application.xml*.
> I'm attaching maven project with all necessary configuration. I have also
> submitted an issue at
> [Stackoverflow|http://stackoverflow.com/questions/23734249/maven-ear-plugin-project-property-lookup-fails],
> because I didn't have account here.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MEAR-188) Project property cannot be resolved inside element
[
https://jira.codehaus.org/browse/MEAR-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise updated MEAR-188:
-
Issue Type: Test (was: Bug)
> Project property cannot be resolved inside element
> --
>
> Key: MEAR-188
> URL: https://jira.codehaus.org/browse/MEAR-188
> Project: Maven Ear Plugin
> Issue Type: Test
>Affects Versions: 2.9
>Reporter: Maciej Kara?
> Fix For: 2.10
>
> Attachments: test.zip
>
>
> I have created simple ear project with filters. I want to use different
> settings for each environment and those settings should be passed to
> generated *application.xml* file inside the *env-entries*. The generation of
> ear package is done as shown below:
> {code:xml}
>
> maven-ear-plugin
> 2.9
>
> true
> 6
>
>
> customProperty
> java.lang.String
>
> ${custom.property}
>
>
> ${custom.property}
>
>
> {code}
> To read maven project properties from external properties file I had to use
> another plugin:
> [properties-maven-plugin|http://mojo.codehaus.org/properties-maven-plugin/].
> It successfully reads properties from file and sets them as maven project
> properties, so I can insert them in pom.xml file using *${}*. It works for
> most of the pom.xml elements (i.e. **), unfortunately it is
> not successfully looked up when I place it inside *env-entry* element where I
> need it. Below is generated *application.xml*.
> {code:xml}
>
> http://java.sun.com/xml/ns/javaee";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/application_6.xsd"; version="6">
> default property
> test
>
> customProperty
> java.lang.String
> ${custom.property}
>
>
> {code}
> If I put project properties inside the block
> everything works fine, but that doesn't allow me to use filters for
> *application.xml*.
> I'm attaching maven project with all necessary configuration. I have also
> submitted an issue at
> [Stackoverflow|http://stackoverflow.com/questions/23734249/maven-ear-plugin-project-property-lookup-fails],
> because I didn't have account here.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MEAR-179) Timestamped jars (sometimes)
[ https://jira.codehaus.org/browse/MEAR-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348043#comment-348043 ] Karl-Heinz Marbaise edited comment on MEAR-179 at 6/15/14 7:15 AM: --- Are you working with Maven 2 or Maven 3 ? Have you tested with cleaning your local repository before running ? was (Author: khmarbaise): Are you working with Maven 2 or Maven 3 ? > Timestamped jars (sometimes) > > > Key: MEAR-179 > URL: https://jira.codehaus.org/browse/MEAR-179 > Project: Maven Ear Plugin > Issue Type: Bug >Affects Versions: 2.9 > Environment: Hudson 3.1 on Redhat Linux. >Reporter: Morten Knudsen > Fix For: more-investigation > > > I upgraded Maven ear plugin from 2.8 to 2.9. After that some *but not all* > SNAPSHOT dependencies are included with the timestamp in their names. > This was not the behaviour in 2.8. I have not found any pattern in which > dependencies that use snapshot and which that don't. > 2.8: > [INFO] Copying artifact > [jar:dk.autocom.invoice.pdf:invoice-pdf-core:2.40-20140121.141224-7] to > [lib/invoice-pdf-core-2.40-SNAPSHOT.jar] > 2.9 > [INFO] Copying artifact > [jar:dk.autocom.invoice.pdf:invoice-pdf-core:2.40-20140121.141224-7] to > [lib/invoice-pdf-core-2.40-20140121.141224-7.jar] > Is this the intended behaviour? -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-179) Timestamped jars (sometimes)
[ https://jira.codehaus.org/browse/MEAR-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MEAR-179: - Fix Version/s: more-investigation > Timestamped jars (sometimes) > > > Key: MEAR-179 > URL: https://jira.codehaus.org/browse/MEAR-179 > Project: Maven Ear Plugin > Issue Type: Bug >Affects Versions: 2.9 > Environment: Hudson 3.1 on Redhat Linux. >Reporter: Morten Knudsen > Fix For: more-investigation > > > I upgraded Maven ear plugin from 2.8 to 2.9. After that some *but not all* > SNAPSHOT dependencies are included with the timestamp in their names. > This was not the behaviour in 2.8. I have not found any pattern in which > dependencies that use snapshot and which that don't. > 2.8: > [INFO] Copying artifact > [jar:dk.autocom.invoice.pdf:invoice-pdf-core:2.40-20140121.141224-7] to > [lib/invoice-pdf-core-2.40-SNAPSHOT.jar] > 2.9 > [INFO] Copying artifact > [jar:dk.autocom.invoice.pdf:invoice-pdf-core:2.40-20140121.141224-7] to > [lib/invoice-pdf-core-2.40-20140121.141224-7.jar] > Is this the intended behaviour? -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-188) Project property cannot be resolved inside element
[
https://jira.codehaus.org/browse/MEAR-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348047#comment-348047
]
Karl-Heinz Marbaise edited comment on MEAR-188 at 6/15/14 7:11 AM:
---
After taking a deeper look into that this a bug of the properties-maven-plugin
cause if the properties are being defined within the pom it works with no
problem only if the were read by the properties-maven-plugin it does not work.
So it's not a bug for maven-ear-plugin. Create one for
[properties-maven-plugin|http://jira.codehaus.org/browse/MOJO-2033].
was (Author: khmarbaise):
This should be handled by maven-filtering component (shared). Currently can't
find a simple solution. Have to dive more into it.
> Project property cannot be resolved inside element
> --
>
> Key: MEAR-188
> URL: https://jira.codehaus.org/browse/MEAR-188
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Maciej Kara?
> Fix For: 2.10
>
> Attachments: test.zip
>
>
> I have created simple ear project with filters. I want to use different
> settings for each environment and those settings should be passed to
> generated *application.xml* file inside the *env-entries*. The generation of
> ear package is done as shown below:
> {code:xml}
>
> maven-ear-plugin
> 2.9
>
> true
> 6
>
>
> customProperty
> java.lang.String
>
> ${custom.property}
>
>
> ${custom.property}
>
>
> {code}
> To read maven project properties from external properties file I had to use
> another plugin:
> [properties-maven-plugin|http://mojo.codehaus.org/properties-maven-plugin/].
> It successfully reads properties from file and sets them as maven project
> properties, so I can insert them in pom.xml file using *${}*. It works for
> most of the pom.xml elements (i.e. **), unfortunately it is
> not successfully looked up when I place it inside *env-entry* element where I
> need it. Below is generated *application.xml*.
> {code:xml}
>
> http://java.sun.com/xml/ns/javaee";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/application_6.xsd"; version="6">
> default property
> test
>
> customProperty
> java.lang.String
> ${custom.property}
>
>
> {code}
> If I put project properties inside the block
> everything works fine, but that doesn't allow me to use filters for
> *application.xml*.
> I'm attaching maven project with all necessary configuration. I have also
> submitted an issue at
> [Stackoverflow|http://stackoverflow.com/questions/23734249/maven-ear-plugin-project-property-lookup-fails],
> because I didn't have account here.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MEAR-184) Application.xml generated in 2 locations
[
https://jira.codehaus.org/browse/MEAR-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise updated MEAR-184:
-
Fix Version/s: more-investigation
> Application.xml generated in 2 locations
>
>
> Key: MEAR-184
> URL: https://jira.codehaus.org/browse/MEAR-184
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Peter Gabriel
> Fix For: more-investigation
>
>
> If is use:
>
> ${basedir}/src/main/application/META-INF
> the application.xml is generated in this dir but it is also generated in
> target dir under '/target/META-INF/application.xml'
> This is the problem for IntelliJ IDEA, cause target dir is not empty. I think
> only one and only one should be created. (NOt in target dir)
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MEAR-188) Project property cannot be resolved inside element
[
https://jira.codehaus.org/browse/MEAR-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348047#comment-348047
]
Karl-Heinz Marbaise commented on MEAR-188:
--
This should be handled by maven-filtering component (shared). Currently can't
find a simple solution. Have to dive more into it.
> Project property cannot be resolved inside element
> --
>
> Key: MEAR-188
> URL: https://jira.codehaus.org/browse/MEAR-188
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Maciej Kara?
> Fix For: 2.10
>
> Attachments: test.zip
>
>
> I have created simple ear project with filters. I want to use different
> settings for each environment and those settings should be passed to
> generated *application.xml* file inside the *env-entries*. The generation of
> ear package is done as shown below:
> {code:xml}
>
> maven-ear-plugin
> 2.9
>
> true
> 6
>
>
> customProperty
> java.lang.String
>
> ${custom.property}
>
>
> ${custom.property}
>
>
> {code}
> To read maven project properties from external properties file I had to use
> another plugin:
> [properties-maven-plugin|http://mojo.codehaus.org/properties-maven-plugin/].
> It successfully reads properties from file and sets them as maven project
> properties, so I can insert them in pom.xml file using *${}*. It works for
> most of the pom.xml elements (i.e. **), unfortunately it is
> not successfully looked up when I place it inside *env-entry* element where I
> need it. Below is generated *application.xml*.
> {code:xml}
>
> http://java.sun.com/xml/ns/javaee";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/application_6.xsd"; version="6">
> default property
> test
>
> customProperty
> java.lang.String
> ${custom.property}
>
>
> {code}
> If I put project properties inside the block
> everything works fine, but that doesn't allow me to use filters for
> *application.xml*.
> I'm attaching maven project with all necessary configuration. I have also
> submitted an issue at
> [Stackoverflow|http://stackoverflow.com/questions/23734249/maven-ear-plugin-project-property-lookup-fails],
> because I didn't have account here.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
