[jira] (MTOOLCHAINS-6) Cannot create custom toolchain type
[
https://jira.codehaus.org/browse/MTOOLCHAINS-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355878#comment-355878
]
Markus KARG commented on MTOOLCHAINS-6:
---
Thank you so much for your effort. This looks really promising. There are only
few notes on your draft:
* Please introduce hyperlinks to the mentioned IT source code, as not everybody
implementing a toolchain is aware of the source location of the mentioned
classes.
* It is unclear, why one must extend DefaultTypechain but cannot just implement
Typechain.
* There is a typo "epxected"
* For those not familiar with the concept of "extensions", it would be a big
help if in "Using the Custom Toolchain and its Plugin" you would give clear
advice, into WHICH pom.xml the particular XML snippets have to go: The
toolchain, the separate plugins, or the end user's project pom?
As I have to build my own toolchain in the next months, there will be a beta
test for your description soon. :-) Unfortunately I will not find the time to
test it before end of the year, but nevertheless, thank you so much for your
work!
Regards
-Markus
> Cannot create custom toolchain type
> ---
>
> Key: MTOOLCHAINS-6
> URL: https://jira.codehaus.org/browse/MTOOLCHAINS-6
> Project: Maven Toolchains Plugin
> Issue Type: Bug
>Affects Versions: 1.0
> Environment: Win 7 Pro SP1 64 Bit, mvn 3.0.4, JDK 1.7.0_45
>Reporter: Markus KARG
>Priority: Blocker
>
> The web site says that it is possible to use other toolchains besides .
> Actually the site links to a nonexistent TBD page. This is very ugly.
> Please tell the truth on the web page: It is simply impossible to use any
> other toolschain type besides !
> It would be really cool, if someone could simply write:
> {code:xml}
>
> installshield
>
> isx
> 10.0
> macrovision
>
>
> C:\Program Files (x86)\InstallShield
> X
>
>
> {code}
> ...and the plugin would in turn simply provide a property that one can read
> in the POM using {{$\{installshieldHome}}} -- without any need to write Java
> code, register custom types, provide more xml, whatever!
> This seems to be such an obvious need that I just cannot believe that it does
> not already work exactly that way in the 1.0 release of the toolchains
> plugin...! :-)
> I really beg for that! :-)
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-729) lineEnding ignored when file is not filtered
[
https://jira.codehaus.org/browse/MASSEMBLY-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed MASSEMBLY-729.
Resolution: Fixed
Assignee: Kristian Rosenvold
Fixed with a unit test in r1637652, thanks for the report !
> lineEnding ignored when file is not filtered
>
>
> Key: MASSEMBLY-729
> URL: https://jira.codehaus.org/browse/MASSEMBLY-729
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Tony Jewell
>Assignee: Kristian Rosenvold
> Fix For: 2.5.2
>
> Attachments:
> maven-assembly-plugin-2.5-lineEnding-ignored-when-not-filtering.zip
>
>
> lineEnding=unix is ignored when filtering is not enabled in FileSet.
> See attached sample project.
> unfiltered.properties - has original (DOS) line endings
> filtered.properties - has unix file endings - original had DOS line endings
> *NOTE* the pom.xml maven-assembly-plugin:2.5 with the following dependency
> overrides:
> {code}
>
> org.codehaus.plexus
> plexus-archiver
> 2.8.2
>
>
> org.codehaus.plexus
> plexus-io
> 2.3.3
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1110) Document the memory requirements to run unit- and integration tests for a release test
[
https://jira.codehaus.org/browse/SUREFIRE-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355884#comment-355884
]
Karl-Heinz Marbaise commented on SUREFIRE-1110:
---
Hi Tibor,
it might be a good idea to check if it's possible to put this into a profile
which is automatically activated by using the integration test profile
`run-its`? Otherwise it would be ok to put it into the README.txt.
> Document the memory requirements to run unit- and integration tests for a
> release test
> --
>
> Key: SUREFIRE-1110
> URL: https://jira.codehaus.org/browse/SUREFIRE-1110
> Project: Maven Surefire
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 2.18
>Reporter: Karl-Heinz Marbaise
>Priority: Minor
> Fix For: 2.19
>
>
> It should be documented how to run unit and integration tests for a release
> check during the vote.
> The following memory requirements are needed:
> {{export MAVEN_OPTS="-Xmx2048m -Xms1024m -XX:MaxPermSize=512m
> -Djava.awt.headless=true"}}.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-298) Continuous Integration support for Travis CI
[ https://jira.codehaus.org/browse/MPIR-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MPIR-298: - Fix Version/s: 2.8 > Continuous Integration support for Travis CI > > > Key: MPIR-298 > URL: https://jira.codehaus.org/browse/MPIR-298 > Project: Maven Project Info Reports Plugin > Issue Type: Improvement > Components: cim >Affects Versions: 2.7 >Reporter: Philippe Marschall > Fix For: 2.8 > > Attachments: travis-ci.patch > > > Recognizes [Travis CI|https://travis-ci.org/] as a CIM system. Travis CI is > popular with GitHub projects. The patch is modeled after MPIR-224 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-298) Continuous Integration support for Travis CI
[ https://jira.codehaus.org/browse/MPIR-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MPIR-298. Resolution: Fixed Assignee: Karl-Heinz Marbaise Patch applied in [r1637666|http://svn.apache.org/r1637666]. Thank you Philippe Marshall. > Continuous Integration support for Travis CI > > > Key: MPIR-298 > URL: https://jira.codehaus.org/browse/MPIR-298 > Project: Maven Project Info Reports Plugin > Issue Type: Improvement > Components: cim >Affects Versions: 2.7 >Reporter: Philippe Marschall >Assignee: Karl-Heinz Marbaise > Fix For: 2.8 > > Attachments: travis-ci.patch > > > Recognizes [Travis CI|https://travis-ci.org/] as a CIM system. Travis CI is > popular with GitHub projects. The patch is modeled after MPIR-224 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-726) Fix artifact inclusion/exclusion filtering
[ https://jira.codehaus.org/browse/MASSEMBLY-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MASSEMBLY-726. Resolution: Fixed Assignee: Kristian Rosenvold Fixed in r1637649 > Fix artifact inclusion/exclusion filtering > -- > > Key: MASSEMBLY-726 > URL: https://jira.codehaus.org/browse/MASSEMBLY-726 > Project: Maven Assembly Plugin > Issue Type: Bug >Reporter: Kristian Rosenvold >Assignee: Kristian Rosenvold > Fix For: 2.5.2 > > > Artifact filtering is implemented in several places and at different layers, > and is rich with inconsistencies. Some code tries to filter based on "source" > artifact while the (correct) approach is to implement on target filename; > avoid duplicate files being added to the archive under the same name. If the > user wants to add the same file under different names, we should not care. > The entire class AssemblyProxyArchiver should basically be removed (there is > a DryRunArchiver in plexus that can be used for dry runs). The other logic in > this class is faulty duplication control and/or workarounds that I suspect > have been added as symptomatic stopgaps for MASSEMBLY-725 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-725) Fix phase ordering
[ https://jira.codehaus.org/browse/MASSEMBLY-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MASSEMBLY-725. Resolution: Fixed Assignee: Kristian Rosenvold Fixed in r1637662 > Fix phase ordering > -- > > Key: MASSEMBLY-725 > URL: https://jira.codehaus.org/browse/MASSEMBLY-725 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Kristian Rosenvold >Assignee: Kristian Rosenvold > Fix For: 2.5.2 > > > The execution order of the phases is random based on maven version and > possibly java version. Documentation on site seems to indicate there is a > given precedence, which is wrong. > Fix precedence of phases; this will only affect resolution of "duplicate" > elements in the archive -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] [Commented] (MASFRES-12) Documentation links to non existent page
[ https://issues.apache.org/jira/browse/MASFRES-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14203919#comment-14203919 ] Alessandro Polverini commented on MASFRES-12: - Done, thanks. http://jira.codehaus.org/browse/MNGSITE-210 > Documentation links to non existent page > > > Key: MASFRES-12 > URL: https://issues.apache.org/jira/browse/MASFRES-12 > Project: Apache Maven Resource Bundles > Issue Type: Bug > Environment: Web browsing >Reporter: Alessandro Polverini > Labels: documentation > > In the page > https://maven.apache.org/guides/mini/guide-central-repository-upload.html > there is a link to the page with the guidelines to follow to upload packages > to the central maven repository, and it's not working: > https://docs.sonatype.org/display/Repository/Choosing+your+Coordinates -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] (MNGSITE-210) Documentation links to non existent page
Alessandro Polverini created MNGSITE-210: Summary: Documentation links to non existent page Key: MNGSITE-210 URL: https://jira.codehaus.org/browse/MNGSITE-210 Project: Maven Project Web Site Issue Type: Bug Environment: Web Reporter: Alessandro Polverini In the page https://maven.apache.org/guides/mini/guide-central-repository-upload.html there is a link to the page with the guidelines to follow to upload packages to the central maven repository, and it's not working: https://docs.sonatype.org/display/Repository/Choosing+your+Coordinates -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-601) http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html seems to have the components of a filter element in the wrong order
[ https://jira.codehaus.org/browse/MASSEMBLY-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MASSEMBLY-601. Resolution: Fixed Assignee: Kristian Rosenvold Someone seems to have fixed the docs, you are sane :) > http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html seems to > have the components of a filter element in the wrong order > --- > > Key: MASSEMBLY-601 > URL: https://jira.codehaus.org/browse/MASSEMBLY-601 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: filtering >Affects Versions: 2.3 >Reporter: Benson Margulies >Assignee: Kristian Rosenvold > Fix For: 2.5.2 > > > The page says: "or they may be fully qualified in the form > groupId:artifactId:type:version[:classifier]" > However, it seems by experiment that the order is: > groupId:artifactId:type:classifier:version > I'd just fix it but I was hoping that someone would tell me that I haven't > lost my mind. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MTOOLCHAINS-6) Cannot create custom toolchain type
[
https://jira.codehaus.org/browse/MTOOLCHAINS-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MTOOLCHAINS-6.
---
Resolution: Fixed
Fix Version/s: 1.1
Assignee: Herve Boutemy
thank you for your useful feedback: documentation updated
http://maven.apache.org/plugins-archives/maven-toolchains-plugin-LATEST/toolchains/custom.html
I consider this is now ok
> Cannot create custom toolchain type
> ---
>
> Key: MTOOLCHAINS-6
> URL: https://jira.codehaus.org/browse/MTOOLCHAINS-6
> Project: Maven Toolchains Plugin
> Issue Type: Bug
>Affects Versions: 1.0
> Environment: Win 7 Pro SP1 64 Bit, mvn 3.0.4, JDK 1.7.0_45
>Reporter: Markus KARG
>Assignee: Herve Boutemy
>Priority: Blocker
> Fix For: 1.1
>
>
> The web site says that it is possible to use other toolchains besides .
> Actually the site links to a nonexistent TBD page. This is very ugly.
> Please tell the truth on the web page: It is simply impossible to use any
> other toolschain type besides !
> It would be really cool, if someone could simply write:
> {code:xml}
>
> installshield
>
> isx
> 10.0
> macrovision
>
>
> C:\Program Files (x86)\InstallShield
> X
>
>
> {code}
> ...and the plugin would in turn simply provide a property that one can read
> in the POM using {{$\{installshieldHome}}} -- without any need to write Java
> code, register custom types, provide more xml, whatever!
> This seems to be such an obvious need that I just cannot believe that it does
> not already work exactly that way in the 1.0 release of the toolchains
> plugin...! :-)
> I really beg for that! :-)
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MTOOLCHAINS-1) Document how to create new toolchains
[ https://jira.codehaus.org/browse/MTOOLCHAINS-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MTOOLCHAINS-1. --- Resolution: Fixed Assignee: Herve Boutemy (was: Milos Kleint) done: see MTOOLCHAINS-6 and result in http://maven.apache.org/plugins-archives/maven-toolchains-plugin-LATEST/toolchains/custom.html > Document how to create new toolchains > - > > Key: MTOOLCHAINS-1 > URL: https://jira.codehaus.org/browse/MTOOLCHAINS-1 > Project: Maven Toolchains Plugin > Issue Type: Improvement >Affects Versions: 1.0 >Reporter: Stephen Connolly >Assignee: Herve Boutemy > Fix For: 1.1 > > > Document how you go about creating new toolchain implementations -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-353) Variable interpolation doesn't work with nested component descriptors
[
https://jira.codehaus.org/browse/MASSEMBLY-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed MASSEMBLY-353.
Resolution: Fixed
Fix Version/s: (was: 2.5.2)
2.2
This issue was fixed in 2.2
> Variable interpolation doesn't work with nested component descriptors
> -
>
> Key: MASSEMBLY-353
> URL: https://jira.codehaus.org/browse/MASSEMBLY-353
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: component descriptor
>Affects Versions: 2.1, 2.2-beta-2
>Reporter: Jonathan Anstey
>Priority: Minor
> Fix For: 2.2
>
>
> When I nest another component descriptor file like so
> {code:xml}
>
>
> src/main/descriptors/common-bin.xml
>
> {code}
> any variable refs such as ${pom.artifactId} or ${pom.version} do not get
> resolved in the nested descriptor.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-730) jar-with-dependencies : a file in a dependency is overridden by the same file in JDK / JRE
[
https://jira.codehaus.org/browse/MASSEMBLY-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355897#comment-355897
]
Kristian Rosenvold commented on MASSEMBLY-730:
--
Hmm. There's something interesting here. Running with jdk8 on my mac all works
as expected.
> jar-with-dependencies : a file in a dependency is overridden by the same file
> in JDK / JRE
> --
>
> Key: MASSEMBLY-730
> URL: https://jira.codehaus.org/browse/MASSEMBLY-730
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: predefined descriptors
>Affects Versions: 2.5, 2.5.1
> Environment: JDK 6
> Maven 3.0.4
> Linux / Windows
>Reporter: Guillaume Husta
> Fix For: 2.5.2
>
>
> Since version 2.5, when I try to make a "jar-with-dependencies" with the
> "single" goal, I get a strange mistake.
> A file in a dependency (a JDBC driver in my example) is overridden by a file
> with the same path / name included in a dependency from the JDK / JRE (in my
> example jre/lib/resources.jar).
> In my example, I just add the dependency
> _org.postgresql:postgresql:9.3-1102-jdbc4_ to my POM.
> Then I package to make a "jar-with-dependencies".
> I can find the file _META-INF/services/java.sql.Driver_ in this jar.
> But with the version 2.5 of plugin assembly, it contains
> * {{sun.jdbc.odbc.JdbcOdbcDriver}} (originated from JRE : resources.jar)
> and with version 2.4.1 of the plugin, it contains
> * {{org.postgresql.Driver}} (originated from postgresql-9.3-1102-jdbc4.jar),
> what I expect
> In the previous version (2.4.1) there was no problem.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-730) jar-with-dependencies : a file in a dependency is overridden by the same file in JDK / JRE
[
https://jira.codehaus.org/browse/MASSEMBLY-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355897#comment-355897
]
Kristian Rosenvold edited comment on MASSEMBLY-730 at 11/9/14 12:17 PM:
Hmm. There's something interesting here. Running with jdk8 on my mac all works
as expected. It also works fine on 1.7 on linux. But 1.6 certainly fails on my
linux box!
was (Author: krosenvold):
Hmm. There's something interesting here. Running with jdk8 on my mac all works
as expected.
> jar-with-dependencies : a file in a dependency is overridden by the same file
> in JDK / JRE
> --
>
> Key: MASSEMBLY-730
> URL: https://jira.codehaus.org/browse/MASSEMBLY-730
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: predefined descriptors
>Affects Versions: 2.5, 2.5.1
> Environment: JDK 6
> Maven 3.0.4
> Linux / Windows
>Reporter: Guillaume Husta
> Fix For: 2.5.2
>
>
> Since version 2.5, when I try to make a "jar-with-dependencies" with the
> "single" goal, I get a strange mistake.
> A file in a dependency (a JDBC driver in my example) is overridden by a file
> with the same path / name included in a dependency from the JDK / JRE (in my
> example jre/lib/resources.jar).
> In my example, I just add the dependency
> _org.postgresql:postgresql:9.3-1102-jdbc4_ to my POM.
> Then I package to make a "jar-with-dependencies".
> I can find the file _META-INF/services/java.sql.Driver_ in this jar.
> But with the version 2.5 of plugin assembly, it contains
> * {{sun.jdbc.odbc.JdbcOdbcDriver}} (originated from JRE : resources.jar)
> and with version 2.4.1 of the plugin, it contains
> * {{org.postgresql.Driver}} (originated from postgresql-9.3-1102-jdbc4.jar),
> what I expect
> In the previous version (2.4.1) there was no problem.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-730) jar-with-dependencies : a file in a dependency is overridden by the same file in JDK / JRE
[
https://jira.codehaus.org/browse/MASSEMBLY-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355897#comment-355897
]
Kristian Rosenvold edited comment on MASSEMBLY-730 at 11/9/14 12:19 PM:
Hmm. There's something interesting here. Running with jdk8 on my mac all works
as expected. It also works fine on 1.7 on linux. But 1.6 certainly fails on my
linux box. If I'm not mistaken there's set iteration order somewhere here :)
was (Author: krosenvold):
Hmm. There's something interesting here. Running with jdk8 on my mac all works
as expected. It also works fine on 1.7 on linux. But 1.6 certainly fails on my
linux box!
> jar-with-dependencies : a file in a dependency is overridden by the same file
> in JDK / JRE
> --
>
> Key: MASSEMBLY-730
> URL: https://jira.codehaus.org/browse/MASSEMBLY-730
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: predefined descriptors
>Affects Versions: 2.5, 2.5.1
> Environment: JDK 6
> Maven 3.0.4
> Linux / Windows
>Reporter: Guillaume Husta
> Fix For: 2.5.2
>
>
> Since version 2.5, when I try to make a "jar-with-dependencies" with the
> "single" goal, I get a strange mistake.
> A file in a dependency (a JDBC driver in my example) is overridden by a file
> with the same path / name included in a dependency from the JDK / JRE (in my
> example jre/lib/resources.jar).
> In my example, I just add the dependency
> _org.postgresql:postgresql:9.3-1102-jdbc4_ to my POM.
> Then I package to make a "jar-with-dependencies".
> I can find the file _META-INF/services/java.sql.Driver_ in this jar.
> But with the version 2.5 of plugin assembly, it contains
> * {{sun.jdbc.odbc.JdbcOdbcDriver}} (originated from JRE : resources.jar)
> and with version 2.4.1 of the plugin, it contains
> * {{org.postgresql.Driver}} (originated from postgresql-9.3-1102-jdbc4.jar),
> what I expect
> In the previous version (2.4.1) there was no problem.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1110) Document the memory requirements to run unit- and integration tests for a release test
[
https://jira.codehaus.org/browse/SUREFIRE-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355898#comment-355898
]
Andreas Gudian commented on SUREFIRE-1110:
--
I'd say we just add that note on the memory requirements for a full build to
the README.TXT file. We could also add a sentence or so about the possibility
to run the ITs without the embedded mode, which would require less memory, but
takes much longer.
I wouldn't add a new profile for the ITs either, as they are located in their
own module anyway and that profile wouldn't have any effect on the
memory-settings of the executing mvn run (again, we prefer running the tests in
embedded mode, i.e. allow Maven Verifier to reuse the surrounding maven
process, which would not be possible if we would fork a process for the test
execution).
> Document the memory requirements to run unit- and integration tests for a
> release test
> --
>
> Key: SUREFIRE-1110
> URL: https://jira.codehaus.org/browse/SUREFIRE-1110
> Project: Maven Surefire
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 2.18
>Reporter: Karl-Heinz Marbaise
>Priority: Minor
> Fix For: 2.19
>
>
> It should be documented how to run unit and integration tests for a release
> check during the vote.
> The following memory requirements are needed:
> {{export MAVEN_OPTS="-Xmx2048m -Xms1024m -XX:MaxPermSize=512m
> -Djava.awt.headless=true"}}.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-730) jar-with-dependencies : a file in a dependency is overridden by the same file in JDK / JRE
[
https://jira.codehaus.org/browse/MASSEMBLY-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355899#comment-355899
]
Kristian Rosenvold commented on MASSEMBLY-730:
--
Apple jdk 1.6.0.65 also works on mac os.
> jar-with-dependencies : a file in a dependency is overridden by the same file
> in JDK / JRE
> --
>
> Key: MASSEMBLY-730
> URL: https://jira.codehaus.org/browse/MASSEMBLY-730
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: predefined descriptors
>Affects Versions: 2.5, 2.5.1
> Environment: JDK 6
> Maven 3.0.4
> Linux / Windows
>Reporter: Guillaume Husta
> Fix For: 2.5.2
>
>
> Since version 2.5, when I try to make a "jar-with-dependencies" with the
> "single" goal, I get a strange mistake.
> A file in a dependency (a JDBC driver in my example) is overridden by a file
> with the same path / name included in a dependency from the JDK / JRE (in my
> example jre/lib/resources.jar).
> In my example, I just add the dependency
> _org.postgresql:postgresql:9.3-1102-jdbc4_ to my POM.
> Then I package to make a "jar-with-dependencies".
> I can find the file _META-INF/services/java.sql.Driver_ in this jar.
> But with the version 2.5 of plugin assembly, it contains
> * {{sun.jdbc.odbc.JdbcOdbcDriver}} (originated from JRE : resources.jar)
> and with version 2.4.1 of the plugin, it contains
> * {{org.postgresql.Driver}} (originated from postgresql-9.3-1102-jdbc4.jar),
> what I expect
> In the previous version (2.4.1) there was no problem.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1113) Build does not fail when successPercentage for @org.testng.annotations.Test() is not met
[
https://jira.codehaus.org/browse/SUREFIRE-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355900#comment-355900
]
Andreas Gudian commented on SUREFIRE-1113:
--
OK, great: the examples in SUREFIRE-654 and also the created integration test
use TestNG 5.7, and there it works. For TestNG 6.x, it's not working anymore.
What we do in Surefire is to implement {{org.testng.ITestListener}} to be
informed about started tests and the result of those tests. Fortunately, the
following method from that interface has a pretty clear documentation:
{code}
/**
* Invoked each time a method fails but has been annotated with
* successPercentage and this failure still keeps it within the
* success percentage requested.
*
* @param result ITestResult containing information about the
run test
* @see ITestResult#SUCCESS_PERCENTAGE_FAILURE
*/
public void onTestFailedButWithinSuccessPercentage(ITestResult result);
{code}
That method is called all four times for the test {{testShouldFailButDoesnt}}
in version 6.8.8 that you use in your pom. In TestNG 5.7, it is called only the
first two times, where the failure percentage is still under 70 percent. Given
the javadoc, I'd say that 5.7 did it right and 6.x introduced a bug here.
Could you please check back with the TestNG folks and file a bug there, if
necessary?
> Build does not fail when successPercentage for @org.testng.annotations.Test()
> is not met
>
>
> Key: SUREFIRE-1113
> URL: https://jira.codehaus.org/browse/SUREFIRE-1113
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, TestNG support
>Affects Versions: 2.18
> Environment: TestNG 6.8.8, maven-surefire-plugin 2.19-SNAPSHOT
> (53a40eef48ea)
> Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4;
> 2014-08-11T22:58:10+02:00)
> Maven home: C:\Program Files\apache-maven-3.2.3
> Java version: 1.7.0_67, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_67\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Benoit Lagae
>Assignee: Andreas Gudian
> Attachments: surefiretest.zip
>
>
> When a TestNG test with annotation methods invocationCount = x and
> successPercentage = y fails, this does not break the Maven build of the
> project. I have attached a minimal Maven project with only the pom and a
> single test class, which contains three dummy tests which should all fail:
> {code}
> @Test
> public void testFailsCorrectly() { fail("dummy"); }
> @Test(invocationCount = x)
> public void testCounterWorksAndTestFails() { fail("dummy"); }
> @Test(invocationCount = x, successPercentage = y)
> public void testShouldFailButDoesnt() { fail("dummy"); }
> {code}
> The first two comply, but the third one doesn't, as is implied in the name of
> the method. I created this project from scratch, i.e. not from an IDE: manual
> creation of folders, code and pom in Notepad++, ...
> I have attached both the project and the info I thought could be relevant
> from my test runs of the project ('diagnostics' folder). Below are the
> results of the individual method runs:
> {code}
>
>
>
>
>
> signature="testShouldFailButDoesnt()[pri:0,
> instance:blagae.StatisticsTest@575598a]" name="testShouldFailButDoesnt"/>
> signature="testShouldFailButDoesnt()[pri:0,
> instance:blagae.StatisticsTest@575598a]" name="testShouldFailButDoesnt"/>
>
>
> {code}
> If we comment out the other tests, and only make testShouldFailButDoesnt run,
> then the build succeeds while it shouldn't. See the results in
> surefiretest/diagnostics/only_faulty_test/console_output.txt
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-987) Provide user property for suiteXmlFile so that it can be passed from Maven Command line
[ https://jira.codehaus.org/browse/SUREFIRE-987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355901#comment-355901 ] Tibor Digana commented on SUREFIRE-987: --- I am assigning to fix version 2.19. Makes sense due to SUREFIRE-1109 is fixing same problem with other parameter in this plugin. In both cases the properties are yet unspecified in AbstractSurefireMojo and the Java fields have same modifier "protected". The fix would provide two system property keys namely surefire.suiteXmlFile and failsafe.suiteXmlFile. > Provide user property for suiteXmlFile so that it can be passed from Maven > Command line > --- > > Key: SUREFIRE-987 > URL: https://jira.codehaus.org/browse/SUREFIRE-987 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin >Affects Versions: 2.12 > Environment: Mac 10.8.2 >Reporter: Manmohan Veettil >Assignee: Tibor Digana >Priority: Critical > > Can we have a way to run all the tests in a package? I know we can run all > tests in a class using -Dit.test option. > OR > Can we define a user property for suiteXmlFile so that tests in a package can > be run using maven fail-safe plugin. > mvn clean install -DsuiteXmlFile=test1.xml > Thanks, > manmohanpv -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-987) Provide user property for suiteXmlFile so that it can be passed from Maven Command line
[ https://jira.codehaus.org/browse/SUREFIRE-987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-987: -- Fix Version/s: 2.19 > Provide user property for suiteXmlFile so that it can be passed from Maven > Command line > --- > > Key: SUREFIRE-987 > URL: https://jira.codehaus.org/browse/SUREFIRE-987 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin >Affects Versions: 2.12 > Environment: Mac 10.8.2 >Reporter: Manmohan Veettil >Assignee: Tibor Digana >Priority: Critical > Fix For: 2.19 > > > Can we have a way to run all the tests in a package? I know we can run all > tests in a class using -Dit.test option. > OR > Can we define a user property for suiteXmlFile so that tests in a package can > be run using maven fail-safe plugin. > mvn clean install -DsuiteXmlFile=test1.xml > Thanks, > manmohanpv -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (JXR-111) Upgrade to Maven 2.2.1 compatibility
[ https://jira.codehaus.org/browse/JXR-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated JXR-111: -- Summary: Upgrade to Maven 2.2.1 compatibility (was: Upgrade to Maven 2.2.1 compatiblity) > Upgrade to Maven 2.2.1 compatibility > > > Key: JXR-111 > URL: https://jira.codehaus.org/browse/JXR-111 > Project: Maven JXR > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Karl-Heinz Marbaise >Assignee: Karl-Heinz Marbaise >Priority: Minor > Fix For: 2.5 > > > Upgrade to Maven 2.2.1 compatiblity. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (JXR-111) Upgrade to Maven 2.2.1 compatibility
[ https://jira.codehaus.org/browse/JXR-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated JXR-111: -- Description: Upgrade to Maven 2.2.1 compatibility. (was: Upgrade to Maven 2.2.1 compatiblity.) > Upgrade to Maven 2.2.1 compatibility > > > Key: JXR-111 > URL: https://jira.codehaus.org/browse/JXR-111 > Project: Maven JXR > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Karl-Heinz Marbaise >Assignee: Karl-Heinz Marbaise >Priority: Minor > Fix For: 2.5 > > > Upgrade to Maven 2.2.1 compatibility. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPLUGIN-278) Upgrade to Maven 2.2.1 minimum requirement
Herve Boutemy created MPLUGIN-278: - Summary: Upgrade to Maven 2.2.1 minimum requirement Key: MPLUGIN-278 URL: https://jira.codehaus.org/browse/MPLUGIN-278 Project: Maven Plugin Tools Issue Type: Task Components: Plugin Plugin Affects Versions: 3.3 Reporter: Herve Boutemy Upgrade to Maven 2.2.1 minimum requirement -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPLUGIN-278) Upgrade to Maven 2.2.1 minimum requirement
[ https://jira.codehaus.org/browse/MPLUGIN-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MPLUGIN-278. - Resolution: Fixed Fix Version/s: 3.4 Assignee: Herve Boutemy done in [r1637736|http://svn.apache.org/r1637736] > Upgrade to Maven 2.2.1 minimum requirement > -- > > Key: MPLUGIN-278 > URL: https://jira.codehaus.org/browse/MPLUGIN-278 > Project: Maven Plugin Tools > Issue Type: Task > Components: Plugin Plugin >Affects Versions: 3.3 >Reporter: Herve Boutemy >Assignee: Herve Boutemy > Fix For: 3.4 > > > Upgrade to Maven 2.2.1 minimum requirement -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] [Created] (MPOM-63) define m-compiler-p target version to avoid plugin-tools report limitation
Hervé Boutemy created MPOM-63:
-
Summary: define m-compiler-p target version to avoid plugin-tools
report limitation
Key: MPOM-63
URL: https://issues.apache.org/jira/browse/MPOM-63
Project: Maven POMs
Issue Type: Wish
Components: asf, maven
Affects Versions: ASF-15, MAVEN-25, MAVEN-PLUGINS-26
Reporter: Hervé Boutemy
Assignee: Hervé Boutemy
Fix For: ASF-16, MAVEN-26, MAVEN-PLUGINS-27
we defined m-compiler-p configuration with default properties instead of
m-compiler-p configuration
{code:xml}1.4
1.4{code}
this causes plugin report to discover minimum JDK as "Default target for
maven-compiler-plugin version 3.1", which is not very useful
it's better to define m-compiler-p configuration to avoid this bug, even if
configured value is exactly the default value
{code:xml}
org.apache.maven.plugins
maven-compiler-plugin
${maven.compiler.source}
${maven.compiler.target}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MPOM-63) define m-compiler-p target version to avoid plugin-tools report limitation
[
https://issues.apache.org/jira/browse/MPOM-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14204129#comment-14204129
]
Hervé Boutemy commented on MPOM-63:
---
see http://jira.codehaus.org/browse/MPLUGIN-279 for plugin tools limitation fix
> define m-compiler-p target version to avoid plugin-tools report limitation
> --
>
> Key: MPOM-63
> URL: https://issues.apache.org/jira/browse/MPOM-63
> Project: Maven POMs
> Issue Type: Wish
> Components: asf, maven
>Affects Versions: MAVEN-PLUGINS-26, MAVEN-25, ASF-15
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
> Fix For: ASF-16, MAVEN-26, MAVEN-PLUGINS-27
>
>
> we defined m-compiler-p configuration with default properties instead of
> m-compiler-p configuration
> {code:xml}1.4
> 1.4{code}
> this causes plugin report to discover minimum JDK as "Default target for
> maven-compiler-plugin version 3.1", which is not very useful
> it's better to define m-compiler-p configuration to avoid this bug, even if
> configured value is exactly the default value
> {code:xml}
> org.apache.maven.plugins
> maven-compiler-plugin
>
> ${maven.compiler.source}
> ${maven.compiler.target}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] (MPLUGIN-279) improve jdk requirement when m-compiler-p not explicitely configured: use default properties
[
https://jira.codehaus.org/browse/MPLUGIN-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355903#comment-355903
]
Herve Boutemy commented on MPLUGIN-279:
---
see https://issues.apache.org/jira/browse/MPOM-63 for workaround in ASF and
Maven parent poms
> improve jdk requirement when m-compiler-p not explicitely configured: use
> default properties
>
>
> Key: MPLUGIN-279
> URL: https://jira.codehaus.org/browse/MPLUGIN-279
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Affects Versions: 3.3
>Reporter: Herve Boutemy
>
> When m-compiler-p has no explicit configuration, plugin-info report displays
> "Default target for maven-compiler-plugin version xxx"
> This message is misleading, since default target can be set with
> {{$\{maven.compiler.target}}} property
> The detection algorithm should look for this property
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPLUGIN-279) improve jdk requirement when m-compiler-p not explicitely configured: use default properties
Herve Boutemy created MPLUGIN-279:
-
Summary: improve jdk requirement when m-compiler-p not explicitely
configured: use default properties
Key: MPLUGIN-279
URL: https://jira.codehaus.org/browse/MPLUGIN-279
Project: Maven Plugin Tools
Issue Type: Improvement
Components: Plugin Plugin
Affects Versions: 3.3
Reporter: Herve Boutemy
When m-compiler-p has no explicit configuration, plugin-info report displays
"Default target for maven-compiler-plugin version xxx"
This message is misleading, since default target can be set with
{{$\{maven.compiler.target}}} property
The detection algorithm should look for this property
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] [Commented] (MPOM-63) define m-compiler-p target version to avoid plugin-tools report limitation
[
https://issues.apache.org/jira/browse/MPOM-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14204135#comment-14204135
]
Hudson commented on MPOM-63:
SUCCESS: Integrated in ASF Parent Pom #112 (See
[https://builds.apache.org/job/ASF%20Parent%20Pom/112/])
[MPOM-63] defined m-compiler-p target version to avoid plugin-tools report
limitation (hboutemy: http://svn.apache.org/viewvc/?view=rev&rev=1637748)
* /maven/pom/trunk/asf/pom.xml
> define m-compiler-p target version to avoid plugin-tools report limitation
> --
>
> Key: MPOM-63
> URL: https://issues.apache.org/jira/browse/MPOM-63
> Project: Maven POMs
> Issue Type: Wish
> Components: asf, maven
>Affects Versions: MAVEN-PLUGINS-26, MAVEN-25, ASF-15
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
> Fix For: ASF-16, MAVEN-26, MAVEN-PLUGINS-27
>
>
> we defined m-compiler-p configuration with default properties instead of
> m-compiler-p configuration
> {code:xml}1.4
> 1.4{code}
> this causes plugin report to discover minimum JDK as "Default target for
> maven-compiler-plugin version 3.1", which is not very useful
> it's better to define m-compiler-p configuration to avoid this bug, even if
> configured value is exactly the default value
> {code:xml}
> org.apache.maven.plugins
> maven-compiler-plugin
>
> ${maven.compiler.source}
> ${maven.compiler.target}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MPOM-63) define m-compiler-p target version to avoid plugin-tools report limitation
[
https://issues.apache.org/jira/browse/MPOM-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy closed MPOM-63.
-
Resolution: Fixed
> define m-compiler-p target version to avoid plugin-tools report limitation
> --
>
> Key: MPOM-63
> URL: https://issues.apache.org/jira/browse/MPOM-63
> Project: Maven POMs
> Issue Type: Wish
> Components: asf, maven
>Affects Versions: MAVEN-PLUGINS-26, MAVEN-25, ASF-15
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
> Fix For: ASF-16, MAVEN-26, MAVEN-PLUGINS-27
>
>
> we defined m-compiler-p configuration with default properties instead of
> m-compiler-p configuration
> {code:xml}1.4
> 1.4{code}
> this causes plugin report to discover minimum JDK as "Default target for
> maven-compiler-plugin version 3.1", which is not very useful
> it's better to define m-compiler-p configuration to avoid this bug, even if
> configured value is exactly the default value
> {code:xml}
> org.apache.maven.plugins
> maven-compiler-plugin
>
> ${maven.compiler.source}
> ${maven.compiler.target}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MPOM-63) define m-compiler-p target version to avoid plugin-tools report limitation
[
https://issues.apache.org/jira/browse/MPOM-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14204146#comment-14204146
]
Hudson commented on MPOM-63:
SUCCESS: Integrated in maven-parent #186 (See
[https://builds.apache.org/job/maven-parent/186/])
[MPOM-63] defined m-compiler-p target version to avoid plugin-tools report
limitation (hboutemy: http://svn.apache.org/viewvc/?view=rev&rev=1637749)
* /maven/pom/trunk/maven/pom.xml
> define m-compiler-p target version to avoid plugin-tools report limitation
> --
>
> Key: MPOM-63
> URL: https://issues.apache.org/jira/browse/MPOM-63
> Project: Maven POMs
> Issue Type: Wish
> Components: asf, maven
>Affects Versions: MAVEN-PLUGINS-26, MAVEN-25, ASF-15
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
> Fix For: ASF-16, MAVEN-26, MAVEN-PLUGINS-27
>
>
> we defined m-compiler-p configuration with default properties instead of
> m-compiler-p configuration
> {code:xml}1.4
> 1.4{code}
> this causes plugin report to discover minimum JDK as "Default target for
> maven-compiler-plugin version 3.1", which is not very useful
> it's better to define m-compiler-p configuration to avoid this bug, even if
> configured value is exactly the default value
> {code:xml}
> org.apache.maven.plugins
> maven-compiler-plugin
>
> ${maven.compiler.source}
> ${maven.compiler.target}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] (SUREFIRE-987) Provide user property for suiteXmlFile so that it can be passed from Maven Command line
[ https://jira.codehaus.org/browse/SUREFIRE-987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355905#comment-355905 ] Tibor Digana commented on SUREFIRE-987: --- Fixed in https://github.com/apache/maven-surefire/pull/67 > Provide user property for suiteXmlFile so that it can be passed from Maven > Command line > --- > > Key: SUREFIRE-987 > URL: https://jira.codehaus.org/browse/SUREFIRE-987 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin >Affects Versions: 2.12 > Environment: Mac 10.8.2 >Reporter: Manmohan Veettil >Assignee: Tibor Digana >Priority: Critical > Fix For: 2.19 > > > Can we have a way to run all the tests in a package? I know we can run all > tests in a class using -Dit.test option. > OR > Can we define a user property for suiteXmlFile so that tests in a package can > be run using maven fail-safe plugin. > mvn clean install -DsuiteXmlFile=test1.xml > Thanks, > manmohanpv -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1109) runOrder should have a user property
[ https://jira.codehaus.org/browse/SUREFIRE-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355904#comment-355904 ] Tibor Digana commented on SUREFIRE-1109: Fixed in https://github.com/apache/maven-surefire/pull/67 > runOrder should have a user property > > > Key: SUREFIRE-1109 > URL: https://jira.codehaus.org/browse/SUREFIRE-1109 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Reporter: Dima Spivak >Assignee: Tibor Digana >Priority: Minor > Fix For: 2.19 > > > Long time user, first time contributor here :). I'd like to add a user > property to specify runOrder from the command line, which seems to be a > pretty trivial change to [this > line|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L685]. > Is it best to submit a pull request or just put up a patch on this issue? > And is there anything else necessary to include besides the one-line change? > Cheers! -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-987) Provide user property for suiteXmlFile so that it can be passed from Maven Command line
[ https://jira.codehaus.org/browse/SUREFIRE-987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355901#comment-355901 ] Tibor Digana edited comment on SUREFIRE-987 at 11/9/14 4:45 PM: I am assigning to fix version 2.19. Makes sense due to SUREFIRE-1109 is fixing same problem with other parameter in this plugin. In both cases the properties are yet unspecified in AbstractSurefireMojo and the Java fields have same modifier "protected". The fix would provide two system property keys namely surefire.suiteXmlFiles and failsafe.suiteXmlFiles. was (Author: tibor17): I am assigning to fix version 2.19. Makes sense due to SUREFIRE-1109 is fixing same problem with other parameter in this plugin. In both cases the properties are yet unspecified in AbstractSurefireMojo and the Java fields have same modifier "protected". The fix would provide two system property keys namely surefire.suiteXmlFile and failsafe.suiteXmlFile. > Provide user property for suiteXmlFile so that it can be passed from Maven > Command line > --- > > Key: SUREFIRE-987 > URL: https://jira.codehaus.org/browse/SUREFIRE-987 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin >Affects Versions: 2.12 > Environment: Mac 10.8.2 >Reporter: Manmohan Veettil >Assignee: Tibor Digana >Priority: Critical > Fix For: 2.19 > > > Can we have a way to run all the tests in a package? I know we can run all > tests in a class using -Dit.test option. > OR > Can we define a user property for suiteXmlFile so that tests in a package can > be run using maven fail-safe plugin. > mvn clean install -DsuiteXmlFile=test1.xml > Thanks, > manmohanpv -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPLUGIN-279) improve jdk requirement when m-compiler-p not explicitely configured: use default properties
[
https://jira.codehaus.org/browse/MPLUGIN-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MPLUGIN-279.
-
Resolution: Fixed
Fix Version/s: 3.4
Assignee: Herve Boutemy
fixed in [r1637762|http://svn.apache.org/r1637762]
> improve jdk requirement when m-compiler-p not explicitely configured: use
> default properties
>
>
> Key: MPLUGIN-279
> URL: https://jira.codehaus.org/browse/MPLUGIN-279
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Affects Versions: 3.3
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
> Fix For: 3.4
>
>
> When m-compiler-p has no explicit configuration, plugin-info report displays
> "Default target for maven-compiler-plugin version xxx"
> This message is misleading, since default target can be set with
> {{$\{maven.compiler.target}}} property
> The detection algorithm should look for this property
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-730) jar-with-dependencies : a file in a dependency is overridden by the same file in JDK / JRE
[
https://jira.codehaus.org/browse/MASSEMBLY-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355907#comment-355907
]
Guillaume Husta commented on MASSEMBLY-730:
---
OK thanks for the information.
My test also failed with Oracle JDK 7 u71 x64 for Windows.
But it succeeded with Oracle JDK 8 u25 x64 for Windows.
It think the reason is that JDK 7 contains
*jre/lib/resources.jar!META-INF/services/java.sql.Driver*
but JDK 8 doesn't anymore !
> jar-with-dependencies : a file in a dependency is overridden by the same file
> in JDK / JRE
> --
>
> Key: MASSEMBLY-730
> URL: https://jira.codehaus.org/browse/MASSEMBLY-730
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: predefined descriptors
>Affects Versions: 2.5, 2.5.1
> Environment: JDK 6
> Maven 3.0.4
> Linux / Windows
>Reporter: Guillaume Husta
> Fix For: 2.5.2
>
>
> Since version 2.5, when I try to make a "jar-with-dependencies" with the
> "single" goal, I get a strange mistake.
> A file in a dependency (a JDBC driver in my example) is overridden by a file
> with the same path / name included in a dependency from the JDK / JRE (in my
> example jre/lib/resources.jar).
> In my example, I just add the dependency
> _org.postgresql:postgresql:9.3-1102-jdbc4_ to my POM.
> Then I package to make a "jar-with-dependencies".
> I can find the file _META-INF/services/java.sql.Driver_ in this jar.
> But with the version 2.5 of plugin assembly, it contains
> * {{sun.jdbc.odbc.JdbcOdbcDriver}} (originated from JRE : resources.jar)
> and with version 2.4.1 of the plugin, it contains
> * {{org.postgresql.Driver}} (originated from postgresql-9.3-1102-jdbc4.jar),
> what I expect
> In the previous version (2.4.1) there was no problem.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-343) add symbolic links managment (java7+ only supported)
[ https://jira.codehaus.org/browse/MASSEMBLY-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hitanjan Sarkar updated MASSEMBLY-343: -- Attachment: symlink-test.tar.gz Symlink test project. Contains a symlink generator (symlinks generated using ant-runer and bundled using assembly plugin) and a symlink consumer that unwraps the dependency using (dependency plugin). My objective is to pack a symlink (using assembly) and unpack it (using dependency-unpack) and see if links remain intact. With assembly-plugin v2.4, the links get resolved into a regular folder structure (dereferenced basically) at the end of the assembly. With v2.5, atleast the assembly-generated artifact should bundle symlinks. But instead the symlinks appear as empty directories. > add symbolic links managment (java7+ only supported) > > > Key: MASSEMBLY-343 > URL: https://jira.codehaus.org/browse/MASSEMBLY-343 > Project: Maven Assembly Plugin > Issue Type: Wish >Affects Versions: 2.2-beta-2 > Environment: linux, ubuntu >Reporter: Godet Gilles >Assignee: Kristian Rosenvold > Fix For: 2.5 > > Attachments: MASSEMBLY-343_maven-assembly-plugin_fixed.patch, > MASSEMBLY-343_maven-assembly-plugin.patch, symlink-test.tar.gz > > > i need to buid archives ( tar for example ) with symbolic links > the plugin build an archive with a file containing the destination of the > link, not the link itself > => the plugin need an option to know if deferencement of links is needed > this is just like -h option of tar > -h, --dereference > don't dump symlinks; dump the files they point to > actually, if you do an archive of /lib, for example, many file will be in > double with diff̮̩rent names. extract of archive will not be the > exactly the same as the source of the archive. => this is a test ! -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-343) add symbolic links managment (java7+ only supported)
[ https://jira.codehaus.org/browse/MASSEMBLY-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355910#comment-355910 ] Hitanjan Sarkar commented on MASSEMBLY-343: --- I 've tested this on OS X Yosemite, Ubuntu Desktop 14.04, and Suse Linux Enterprise Server. All versions of Java have been 7+ and Oracle JDK ( I hope any JDK>=7 should have worked). Java version "1.7.0_71" I have attached a 'symlink-test' project. > add symbolic links managment (java7+ only supported) > > > Key: MASSEMBLY-343 > URL: https://jira.codehaus.org/browse/MASSEMBLY-343 > Project: Maven Assembly Plugin > Issue Type: Wish >Affects Versions: 2.2-beta-2 > Environment: linux, ubuntu >Reporter: Godet Gilles >Assignee: Kristian Rosenvold > Fix For: 2.5 > > Attachments: MASSEMBLY-343_maven-assembly-plugin_fixed.patch, > MASSEMBLY-343_maven-assembly-plugin.patch, symlink-test.tar.gz > > > i need to buid archives ( tar for example ) with symbolic links > the plugin build an archive with a file containing the destination of the > link, not the link itself > => the plugin need an option to know if deferencement of links is needed > this is just like -h option of tar > -h, --dereference > don't dump symlinks; dump the files they point to > actually, if you do an archive of /lib, for example, many file will be in > double with diff̮̩rent names. extract of archive will not be the > exactly the same as the source of the archive. => this is a test ! -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-730) jar-with-dependencies : a file in a dependency is overridden by the same file in JDK / JRE
[
https://jira.codehaus.org/browse/MASSEMBLY-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355911#comment-355911
]
Kristian Rosenvold commented on MASSEMBLY-730:
--
The root cause of this issue is probably the escaping algorithm from PLXCOMP-107
> jar-with-dependencies : a file in a dependency is overridden by the same file
> in JDK / JRE
> --
>
> Key: MASSEMBLY-730
> URL: https://jira.codehaus.org/browse/MASSEMBLY-730
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: predefined descriptors
>Affects Versions: 2.5, 2.5.1
> Environment: JDK 6
> Maven 3.0.4
> Linux / Windows
>Reporter: Guillaume Husta
> Fix For: 2.5.2
>
>
> Since version 2.5, when I try to make a "jar-with-dependencies" with the
> "single" goal, I get a strange mistake.
> A file in a dependency (a JDBC driver in my example) is overridden by a file
> with the same path / name included in a dependency from the JDK / JRE (in my
> example jre/lib/resources.jar).
> In my example, I just add the dependency
> _org.postgresql:postgresql:9.3-1102-jdbc4_ to my POM.
> Then I package to make a "jar-with-dependencies".
> I can find the file _META-INF/services/java.sql.Driver_ in this jar.
> But with the version 2.5 of plugin assembly, it contains
> * {{sun.jdbc.odbc.JdbcOdbcDriver}} (originated from JRE : resources.jar)
> and with version 2.4.1 of the plugin, it contains
> * {{org.postgresql.Driver}} (originated from postgresql-9.3-1102-jdbc4.jar),
> what I expect
> In the previous version (2.4.1) there was no problem.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-343) add symbolic links managment (java7+ only supported)
[ https://jira.codehaus.org/browse/MASSEMBLY-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355912#comment-355912 ] Kristian Rosenvold commented on MASSEMBLY-343: -- @Hitanjan Sarkar Would you min dcreating a separat issue for this ? 2.5.2 is not too far off and I'll definitely take a look at this ! > add symbolic links managment (java7+ only supported) > > > Key: MASSEMBLY-343 > URL: https://jira.codehaus.org/browse/MASSEMBLY-343 > Project: Maven Assembly Plugin > Issue Type: Wish >Affects Versions: 2.2-beta-2 > Environment: linux, ubuntu >Reporter: Godet Gilles >Assignee: Kristian Rosenvold > Fix For: 2.5 > > Attachments: MASSEMBLY-343_maven-assembly-plugin_fixed.patch, > MASSEMBLY-343_maven-assembly-plugin.patch, symlink-test.tar.gz > > > i need to buid archives ( tar for example ) with symbolic links > the plugin build an archive with a file containing the destination of the > link, not the link itself > => the plugin need an option to know if deferencement of links is needed > this is just like -h option of tar > -h, --dereference > don't dump symlinks; dump the files they point to > actually, if you do an archive of /lib, for example, many file will be in > double with diff̮̩rent names. extract of archive will not be the > exactly the same as the source of the archive. => this is a test ! -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-343) add symbolic links managment (java7+ only supported)
[ https://jira.codehaus.org/browse/MASSEMBLY-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355914#comment-355914 ] Hitanjan Sarkar commented on MASSEMBLY-343: --- Sure Kristian, will do. Thanks !!! Any idea of the tentative date when 2.5.2 might be released ? Also, there is a corresponding outstanding issue on the dependency plugin, tracked here - http://jira.codehaus.org/browse/MDEP-68 Would you be the right person to ask about this too ? >From whatever little I seem to have gathered on this, since the plexus-io and >plexus-archiver plugins have this fix in, the dependency plugin would probably >need to be re-released with the updated plexus dependencies or something >similar ? > add symbolic links managment (java7+ only supported) > > > Key: MASSEMBLY-343 > URL: https://jira.codehaus.org/browse/MASSEMBLY-343 > Project: Maven Assembly Plugin > Issue Type: Wish >Affects Versions: 2.2-beta-2 > Environment: linux, ubuntu >Reporter: Godet Gilles >Assignee: Kristian Rosenvold > Fix For: 2.5 > > Attachments: MASSEMBLY-343_maven-assembly-plugin_fixed.patch, > MASSEMBLY-343_maven-assembly-plugin.patch, symlink-test.tar.gz > > > i need to buid archives ( tar for example ) with symbolic links > the plugin build an archive with a file containing the destination of the > link, not the link itself > => the plugin need an option to know if deferencement of links is needed > this is just like -h option of tar > -h, --dereference > don't dump symlinks; dump the files they point to > actually, if you do an archive of /lib, for example, many file will be in > double with diff̮̩rent names. extract of archive will not be the > exactly the same as the source of the archive. => this is a test ! -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-731) Assembly plugin bundles symlinks as emtpy folders
Hitanjan Sarkar created MASSEMBLY-731: - Summary: Assembly plugin bundles symlinks as emtpy folders Key: MASSEMBLY-731 URL: https://jira.codehaus.org/browse/MASSEMBLY-731 Project: Maven Assembly Plugin Issue Type: Bug Affects Versions: 2.5.1, 2.5 Environment: linux, ubuntu, OS X Reporter: Hitanjan Sarkar The Maven Assembly plugin (v2.5) should bundle symlinks correctly while assembling resources. (As per the resolved issue - https://jira.codehaus.org/browse/MASSEMBLY-343) With v2.4, it was dereferencing and resolving all such symlinks. With v2.5, it is bundling those symlinks as empty directories. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-343) add symbolic links managment (java7+ only supported)
[ https://jira.codehaus.org/browse/MASSEMBLY-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355915#comment-355915 ] Hitanjan Sarkar commented on MASSEMBLY-343: --- Created the issue here - https://jira.codehaus.org/browse/MASSEMBLY-731 > add symbolic links managment (java7+ only supported) > > > Key: MASSEMBLY-343 > URL: https://jira.codehaus.org/browse/MASSEMBLY-343 > Project: Maven Assembly Plugin > Issue Type: Wish >Affects Versions: 2.2-beta-2 > Environment: linux, ubuntu >Reporter: Godet Gilles >Assignee: Kristian Rosenvold > Fix For: 2.5 > > Attachments: MASSEMBLY-343_maven-assembly-plugin_fixed.patch, > MASSEMBLY-343_maven-assembly-plugin.patch, symlink-test.tar.gz > > > i need to buid archives ( tar for example ) with symbolic links > the plugin build an archive with a file containing the destination of the > link, not the link itself > => the plugin need an option to know if deferencement of links is needed > this is just like -h option of tar > -h, --dereference > don't dump symlinks; dump the files they point to > actually, if you do an archive of /lib, for example, many file will be in > double with diff̮̩rent names. extract of archive will not be the > exactly the same as the source of the archive. => this is a test ! -- This message was sent by Atlassian JIRA (v6.1.6#6162)
