[jira] [Commented] (MSHADE-202) When promoteTransitiveDependencies=true, some are stripped from the dependency-reduced-pom
[
https://issues.apache.org/jira/browse/MSHADE-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999084#comment-16999084
]
Elliotte Rusty Harold commented on MSHADE-202:
--
Is this still an issue?
> When promoteTransitiveDependencies=true, some are stripped from
> the dependency-reduced-pom
> ---
>
> Key: MSHADE-202
> URL: https://issues.apache.org/jira/browse/MSHADE-202
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.4.1
> Environment: Windows 7
> java 1.8
>Reporter: Andrey Stepaonv
>Priority: Major
>
> I have 2 modules. First module uses this dependencies:
>
> ch.imvs
> sdes4j
> 1.1.3
>
>
> commons-codec
> commons-codec
>
>
>
>
> commons-codec
> commons-codec
> 1.10
>
> and second module uses first module and maven-shade plugin with execution:
>
> shade-for-obfuscate
> package
>
> shade
>
>
>
>
> ${project.groupId}:firstModule
>
>
> true
>
> ${basedir}/target/dependency-reduced-pom.xml
>
>
> As a result i have reduced pom with dependencies:
>
> ch.imvs
> sdes4j
> 1.1.3
> compile
>
>
> commons-codec
> commons-codec
> 1.10
> compile
>
> But i had to get dependency with
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-149) XmlAppendingTransformer not adequate for aop-ajc.xml files
[ https://issues.apache.org/jira/browse/MSHADE-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999087#comment-16999087 ] Elliotte Rusty Harold commented on MSHADE-149: -- I don;t know anything about AOP. Does this make sense? > XmlAppendingTransformer not adequate for aop-ajc.xml files > -- > > Key: MSHADE-149 > URL: https://issues.apache.org/jira/browse/MSHADE-149 > Project: Maven Shade Plugin > Issue Type: Improvement >Reporter: Pascal Pochet >Priority: Trivial > Attachments: AopAjcXmlResourceTransformer.java > > > When merging aop-ajc.xml files (== merging several AspectJ jars...), > XmlAppendingTransformer generates: > > > ...aspects of jar 1 > > > ...aspects of jar 2 > >... > > ...aspects of jar N > > > instead of > > > ...aspects of jar 1 > ...aspects of jar 2 > ...aspects of jar N > > > Solution: > add the attached transformer to the list of existing ones. > and in pom.xml: > implementation="org.apache.maven.plugins.shade.resource.AopAjcXmlResourceTransformer"> > META-INF/aop-ajc.xml > > NB > A more general solution would be to add a parameter to > XmlAppendingTransformer to specify the XML level to merge... (maybe as a > XPath expression ?) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSHADE-196) Must not attempt to unzip unfamiliar dependency type
[ https://issues.apache.org/jira/browse/MSHADE-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999086#comment-16999086 ] Elliotte Rusty Harold commented on MSHADE-196: -- seems right > Must not attempt to unzip unfamiliar dependency type > > > Key: MSHADE-196 > URL: https://issues.apache.org/jira/browse/MSHADE-196 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Markus Karg >Priority: Major > Labels: dll > > When adding dependencies to rather unconventional package types, like "dll" > or "pdf", we noticed that the share plugin by default tries to unzip them. > This is weird, as obviously this attempt will fail in almost any case. A user > is forced to add explicit exceptions, which is tedious, error prone, and > breaks CoC. > The solution is rather obvious: The shade plugin must only unzip those > package types which it is familiar with. This namely is e. g. JAR, ZIP, BZIP, > GZIP etc. but certainly not anything unknown. > The result of this change will be a simplification of the pom.xml, and shade > plugin's behaviour will be more like a user expects it to work: Don't touch > unkown stuff! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MSHADE-95) test-scoped artifact excluded, even if it is also a transitive dep
[
https://issues.apache.org/jira/browse/MSHADE-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MSHADE-95.
---
> test-scoped artifact excluded, even if it is also a transitive dep
> --
>
> Key: MSHADE-95
> URL: https://issues.apache.org/jira/browse/MSHADE-95
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 1.3.2, 1.4
> Environment: (cygwin)
> Apache Maven 3.0.1 (r1038046; 2010-11-23 05:58:32-0500)
> Java version: 1.6.0_23
> Java home: C:\Program Files\Java\jdk1.6.0_23\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7" version: "6.1" arch: "amd64" Family: "windows"
>Reporter: Alan D. Salewski
>Priority: Major
> Labels: moreinfo
> Attachments: MSHADE-95-IT.patch
>
>
> A test-scoped artifact is excluded from the final jar, even if that artifact
> is also a transitive dependency of some other (non-test-scoped) dep.
> {noformat}
> MY_POM
> |
> |
> +-- dep A (scope: test)
> |
> |
> +-- dep B (scope: compile)
> |
> |
> +-- dep A (scope: compile)
> {noformat}
> In the above scenario, I would expect '{{dep A}}' to be included in the final
> jar, even though it's in the '{{test}}' scope in my POM. The rationale is
> that it is required for '{{dep B}}' to run; its absence will result in a
> {{java.lang.ClassNotFoundException}} at runtime.
> Behavior observed with maven-shade-plugin versions 1.3.2 and 1.4; other
> versions not tested.
> I'll put together a test case later tonight when I have more time and attach
> it here.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MSHADE-95) test-scoped artifact excluded, even if it is also a transitive dep
[
https://issues.apache.org/jira/browse/MSHADE-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MSHADE-95.
-
Resolution: Won't Fix
Since this issue is scheduled for autoclosing due to inactivity anyway, I'm
going to be opinionated and say Maven should not support non-test scoped
dependencies on test scoped dependencies. The correct solution here is to fix
the scopes in the POM.
Bundling test scoped dependencies would cause far more problems for correctly
scoped products than it would cure for incorrectly scoped projects.
> test-scoped artifact excluded, even if it is also a transitive dep
> --
>
> Key: MSHADE-95
> URL: https://issues.apache.org/jira/browse/MSHADE-95
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 1.3.2, 1.4
> Environment: (cygwin)
> Apache Maven 3.0.1 (r1038046; 2010-11-23 05:58:32-0500)
> Java version: 1.6.0_23
> Java home: C:\Program Files\Java\jdk1.6.0_23\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7" version: "6.1" arch: "amd64" Family: "windows"
>Reporter: Alan D. Salewski
>Priority: Major
> Labels: moreinfo
> Attachments: MSHADE-95-IT.patch
>
>
> A test-scoped artifact is excluded from the final jar, even if that artifact
> is also a transitive dependency of some other (non-test-scoped) dep.
> {noformat}
> MY_POM
> |
> |
> +-- dep A (scope: test)
> |
> |
> +-- dep B (scope: compile)
> |
> |
> +-- dep A (scope: compile)
> {noformat}
> In the above scenario, I would expect '{{dep A}}' to be included in the final
> jar, even though it's in the '{{test}}' scope in my POM. The rationale is
> that it is required for '{{dep B}}' to run; its absence will result in a
> {{java.lang.ClassNotFoundException}} at runtime.
> Behavior observed with maven-shade-plugin versions 1.3.2 and 1.4; other
> versions not tested.
> I'll put together a test case later tonight when I have more time and attach
> it here.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSHADE-233) IncludeResourceTransformer should (be configurable to) error if file doesn't exist.
[ https://issues.apache.org/jira/browse/MSHADE-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MSHADE-233: - Description: Just spent a long time debugging why the shaded jar was missing a resource, and it turns out I just typoed the file. It would be much better if this wasn't a silent failure. At least a warning should be logged, if not a full error. was: Just spent a long time debugging why the shaded jar mas missing a resource, and it turns out I just typoed the file. It would be much better if this wasn't a silent failure. At least a warning should be logged, if not a full error. > IncludeResourceTransformer should (be configurable to) error if file doesn't > exist. > --- > > Key: MSHADE-233 > URL: https://issues.apache.org/jira/browse/MSHADE-233 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 2.4.3 >Reporter: James Howe >Priority: Major > > Just spent a long time debugging why the shaded jar was missing a resource, > and it turns out I just typoed the file. > It would be much better if this wasn't a silent failure. > At least a warning should be logged, if not a full error. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MENFORCER-252) DependencyConvergence rule doesn't account dependencyManagement section correctly
[
https://issues.apache.org/jira/browse/MENFORCER-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999140#comment-16999140
]
Elliotte Rusty Harold commented on MENFORCER-252:
-
sounds like a bug, and if it's still happening--is it?--it should be fixed
unconditionally. There shouldn't be a configuration option for this.
> DependencyConvergence rule doesn't account dependencyManagement section
> correctly
> -
>
> Key: MENFORCER-252
> URL: https://issues.apache.org/jira/browse/MENFORCER-252
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 1.4.1
>Reporter: Dmitry Spikhalskiy
>Priority: Major
> Labels: dependency-tree
>
> DependencyConvergence doesn't catch dependencyManagement section of
> dependency correctly.
> Specific example:
> We have module that depends on async-http-client:
> {code:xml}
>
> org.asynchttpclient
> async-http-client
> 2.0.3
>
> {code}
> From dependencyConvergence rule we get
> {noformat}
> [WARNING] Rule 0: org.apache.maven.plugins.enforcer.DependencyConvergence
> failed with message:
> Failed while enforcing releasability the error(s) are [
> Dependency convergence error for io.netty:netty-handler:4.0.36.Final paths to
> dependency are:
> +-our_artifact
> +-org.asynchttpclient:async-http-client:2.0.3
> +-io.netty:netty-codec-http:4.0.36.Final
> +-io.netty:netty-handler:4.0.36.Final
> and
> +-our_artifact
> +-org.asynchttpclient:async-http-client:2.0.3
> +-com.typesafe.netty:netty-reactive-streams:1.0.4
> +-io.netty:netty-handler:4.0.34.Final
> {noformat}
> While, actually, dependencyManagement section of async-http-client specifies
> and enforce netty-handler:4.0.36.Final and it's dependency tree doesn't
> contain netty-handler:4.0.34.Final
> So... if it's not a bug, it should be a way to ignore such cases of
> explicitly resolved conflicts in external artifact maybe.
> Current fix for this is
> {code:xml}
>
> org.asynchttpclient
> async-http-client
>
>
> io.netty
> netty-handler
>
>
>
>
> io.netty
> netty-handler
> 4.0.36.Final
>
> {code}
> But it's stupid, because netty-handler already contains only
> netty-handler:4.0.36.Final
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MPLUGIN-302) Dependencies Annotation
[
https://issues.apache.org/jira/browse/MPLUGIN-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999143#comment-16999143
]
Elliotte Rusty Harold commented on MPLUGIN-302:
---
scheduled for autoclose. Does anyone want to work on this, or should we resolve
that we're not going to do this?
> Dependencies Annotation
> ---
>
> Key: MPLUGIN-302
> URL: https://issues.apache.org/jira/browse/MPLUGIN-302
> Project: Maven Plugin Tools
> Issue Type: New Feature
> Components: API
>Reporter: Robert Scholte
>Priority: Major
> Attachments: dependencies-annotation.patch
>
>
> The goal of this Annotation is to remove all dependencies from the plugin
> configuration and to have custom scopes so they become part of the dependency
> resolution when Maven is creating a buildplan.
> {code:xml}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
> group-Taglet
> artifact-Taglet
> version-Taglet
>
>
>
> {code}
> This will become
> {code:xml}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
>
>
> group-Taglet
> artifact-Taglet
> version-Taglet
> taglet
>
>
>
> {code}
> Going further: there can be project dependencies which are not part of the
> classpath. One concrete example is the multirelease jar, where the newer
> implementation classes can be added to base jar. Current solution is to have
> a separate (distribution) Maven module which assembles the final jar, but
> with the solution above it is possible to embed them already when creating
> the base jar.
> This project would have the following dependencies:
> {code:xml}
>
>
> GROUPID
>ARTIFACTID-7
>release:7
>
>
> GROUPID
>ARTIFACTID-8
>release:8
>
>
> {code}
> In the maven-jar-plugin one would have something like:
> {code}
> @Dependecies( label="release" )
> Map releaseArtifacts;
> // somewhere in the code
> foreach( Map.Entry releaseEntry : releaseArtifacts.entrySet() )
> {
> // copy content of release.value() to META-INF/versions/release.key()
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-170) Outstanding questions about MSHADE-124
[
https://issues.apache.org/jira/browse/MSHADE-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999068#comment-16999068
]
Elliotte Rusty Harold commented on MSHADE-170:
--
at the very least the docs are still an open issue.
> Outstanding questions about MSHADE-124
> --
>
> Key: MSHADE-170
> URL: https://issues.apache.org/jira/browse/MSHADE-170
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Gili
>Priority: Major
> Fix For: backlog
>
>
> MSHADE-124 is marked as fixed but as Anthony Whitford points out:
> # If this is fixed, why does the documentation still warn about this?
> http://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#dependencyReducedPomLocation
> # Shouldn't the default location be under project.build.directory instead of
> basedir? Then {{mvn clean}} would be more effective, and the {{Maven
> Release}} plugin wouldn't give an error saying, "Cannot prepare the release
> because you have local modifications."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSHADE-170) Outstanding questions about MSHADE-124
[
https://issues.apache.org/jira/browse/MSHADE-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MSHADE-170:
-
Priority: Minor (was: Major)
> Outstanding questions about MSHADE-124
> --
>
> Key: MSHADE-170
> URL: https://issues.apache.org/jira/browse/MSHADE-170
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Gili
>Priority: Minor
> Fix For: backlog
>
>
> MSHADE-124 is marked as fixed but as Anthony Whitford points out:
> # If this is fixed, why does the documentation still warn about this?
> http://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#dependencyReducedPomLocation
> # Shouldn't the default location be under project.build.directory instead of
> basedir? Then {{mvn clean}} would be more effective, and the {{Maven
> Release}} plugin wouldn't give an error saying, "Cannot prepare the release
> because you have local modifications."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MSHADE-220) Shade test-scoped dependencies of test jars
[ https://issues.apache.org/jira/browse/MSHADE-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MSHADE-220. > Shade test-scoped dependencies of test jars > --- > > Key: MSHADE-220 > URL: https://issues.apache.org/jira/browse/MSHADE-220 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 2.4.3 >Reporter: Joel Friedly >Priority: Major > > I have a trivial smoketest project that creates a shaded executable jar so > that I can just copy my smoketest jar to any host and run it. My smoketest > project doesn't actually contain the test cases though, it just depends on > the test jar produced by our main integration testing submodule. Shade will > shade in the compile-scoped dependencies of this test jar, but not the > test-scoped dependencies of this test jar. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MSHADE-220) Shade test-scoped dependencies of test jars
[ https://issues.apache.org/jira/browse/MSHADE-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MSHADE-220. -- Resolution: Won't Fix Per last comment, this is WAI > Shade test-scoped dependencies of test jars > --- > > Key: MSHADE-220 > URL: https://issues.apache.org/jira/browse/MSHADE-220 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 2.4.3 >Reporter: Joel Friedly >Priority: Major > > I have a trivial smoketest project that creates a shaded executable jar so > that I can just copy my smoketest jar to any host and run it. My smoketest > project doesn't actually contain the test cases though, it just depends on > the test jar produced by our main integration testing submodule. Shade will > shade in the compile-scoped dependencies of this test jar, but not the > test-scoped dependencies of this test jar. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MSHADE-230) Cannot specify custom manifest file in a shaded jar.
[ https://issues.apache.org/jira/browse/MSHADE-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MSHADE-230: - Priority: Minor (was: Major) > Cannot specify custom manifest file in a shaded jar. > > > Key: MSHADE-230 > URL: https://issues.apache.org/jira/browse/MSHADE-230 > Project: Maven Shade Plugin > Issue Type: New Feature >Affects Versions: 2.4.3 >Reporter: BlakeTNC >Priority: Minor > > When a project uses the maven-jar-plugin, it's easy to include a custom (hand > written) manifest file in the jar, but I can't find a way to do the same > thing with maven shade. How can I use my own manifest file while using the > "maven-shade-plugin"? > Basic details: > My custom manifest file is located in > "src/main/resources/META-INF/MANIFEST.MF". Shade is not including my file, > instead it is being replaced in the final jar with a default manifest file. > The reason I need a custom manifest file is to specify some JavaBeans classes > in my manifest, for a swing component library. Multiple JavaBeans classes > should be specified in the manifest file in the following format, as > described here: > http://www.ewebprogrammer.com/java-beans/module3/javabeans-manifest-file.jsp > (Note that the order of these lines is important, as well as the empty lines > between them. The ManifestResourceTransformer could add the lines, but they > get added out of order and without the empty lines.) > Name: SomeBean1.class > Java-Bean: True > Name: SomeBean2.class > Java-Bean: True > Name: SomeBean3.class > Java-Bean: True > The POM file for this project is long, so I won't paste the whole thing here. > However, the current full POM for this project can be seen on github at this > link: > https://github.com/LGoodDatePicker/LGoodDatePicker/blob/master/Project/pom.xml > See the list of (unsuccessful) solutions I have tried (and additional > details), which are located here. > http://stackoverflow.com/questions/38243222/how-can-i-specify-a-custom-manifest-mf-file-while-using-the-maven-shade-plugin > Thank you. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MWAR-220) dependencyManagement && overlay + transitive dependency = multiple versions of same dependency in WEB-INF/lib
[ https://issues.apache.org/jira/browse/MWAR-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999108#comment-16999108 ] Elliotte Rusty Harold commented on MWAR-220: probably still an issue > dependencyManagement && overlay + transitive dependency = multiple versions > of same dependency in WEB-INF/lib > - > > Key: MWAR-220 > URL: https://issues.apache.org/jira/browse/MWAR-220 > Project: Maven WAR Plugin > Issue Type: Bug > Components: overlay > Environment: Reproduced this on: 2.0.11, 2.1.0, 2.2.1, 3.0-alpha-7 >Reporter: jieryn >Priority: Major > Attachments: pom.xml > > > With dependencyManagement section defined I get multiple versions of spring > libraries in target/cas-*/WEB-INF/lib after mvn package. If I remove the > dependencyManagement section then only one version of the spring libraries > are found. > There seems to be a problem with m-war-p and overlays and > dependencyManagement not using the maven GAV resolver in a proper way.. I > attached a simple pom which exhibits the problem, just run mvn package to > verify. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MGPG-54) Add check for use of weak private keys before signing
[
https://issues.apache.org/jira/browse/MGPG-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MGPG-54.
---
Resolution: Won't Fix
Since there's no activity here and this issue is scheduled for autoclosure
anyway, I'm going to make an opinionated call that we shouldn't fix this. The
GPG plugin should support what GPG supports, no more, no less.
If anyone disagrees, feel free to reopen.
> Add check for use of weak private keys before signing
> -
>
> Key: MGPG-54
> URL: https://issues.apache.org/jira/browse/MGPG-54
> Project: Maven GPG Plugin
> Issue Type: New Feature
>Reporter: Christopher Tubbs
>Priority: Minor
>
> I just filed MPOM-118, and was thinking that signatures on releases are also
> weakened by the use of weaker private keys.
> It may be possible for the plugin to validate the key to be used prior to
> signing, and to fail if the key is weaker than 4096-bit RSA (the current
> recommended minimum).
> You can see a similar check in this bash scriptlet:
> {code}
> # get default key, if it exists
> KEY=$(gpgconf --list-options gpg | awk -F: '$1 == "default-key" {print $10}'
> | cut -c2-)
> # get first secret key if default isn't set
> [[ -n $KEY ]] || KEY=$(gpg --with-colons --list-secret-key | grep ^sec | head
> -1 | cut -f5 -d:)
> # get bits from first RSA signing (sub)key
> BITS=$(gpg --with-colons --list-secret-key $KEY | grep
> -E'^(sec|ssb)(:[^:]*){2}:1(:[^:]*){7}:[^:]*s' | head -1 | cut -f3 -d:)
> # verify bits are at least 4096
> (( $BITS >= 4096 )) || exit 1
> {code}
> {{--with-colons}} provides backwards-compatible machine-parseable output
> predictably. Specifying the $KEY is optional. Unfortunately, the "usage"
> codes (field 12) to find the signing key/subkey (code "s") aren't displayed
> if you don't specify $KEY on the command line. So, we need to figure out the
> one the gpg command will select, and ask about it explicitly.
> GPG's selection method is to use the default key specified in the gpg
> configuration first. If that isn't set, it just uses the first secret key it
> finds. There's no better way to figure out which key this is other than to
> parse the config file. {{gpgconf}} command can help with that.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MGPG-45) ascDirectory has no effect unless artifacts are not in target
[
https://issues.apache.org/jira/browse/MGPG-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999149#comment-16999149
]
Elliotte Rusty Harold commented on MGPG-45:
---
seems worth investigating
> ascDirectory has no effect unless artifacts are not in target
> -
>
> Key: MGPG-45
> URL: https://issues.apache.org/jira/browse/MGPG-45
> Project: Maven GPG Plugin
> Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Sebb
>Priority: Major
>
> Not sure if this is a documentation or code bug or both.
> The doc for gpg:sign / ascDirectory says:
> {code}
> The directory where to store signature files.
> Default: ${project.build.directory}/gpg
> {code}
> However changing this has no effect unless the artifacts are moved elsewhere
> than target (by changing assembly:outputDirectory).
> If outputDirectory is set to target/tarballs then the sig files are actually
> stored in target/gpg/target/tarballs for the default setting, rather than in
> the expected directory of target/gpg
> If ascDirectory is set to ASC then the sigs are stored in
> ASC/target/tarballs/ rather than ASC.
> If ascDirectory is set to "." then the sigs are stored in
> target/tarballs/ rather than the home directory.
> There does not seem to be any use-case for this behaviour, and if there is,
> it's not documented correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5966) Add bash completion to delivery
[ https://issues.apache.org/jira/browse/MNG-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999083#comment-16999083 ] Elliotte Rusty Harold commented on MNG-5966: seems useful > Add bash completion to delivery > --- > > Key: MNG-5966 > URL: https://issues.apache.org/jira/browse/MNG-5966 > Project: Maven > Issue Type: Improvement > Components: Command Line >Affects Versions: needing-scrub-3.4.0-fallout >Reporter: Karl Heinz Marbaise >Priority: Minor > > I would like to suggest to add a bash completion to our maven delivery. > I would like to suggest to use the following one: > https://github.com/juven/maven-bash-completion (which is already under Apache > License)... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSHADE-231) Multiple shade artifacts + reduced pom from the same artifact
[ https://issues.apache.org/jira/browse/MSHADE-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999103#comment-16999103 ] Elliotte Rusty Harold commented on MSHADE-231: -- What do you mean by "attach" in this context? > Multiple shade artifacts + reduced pom from the same artifact > - > > Key: MSHADE-231 > URL: https://issues.apache.org/jira/browse/MSHADE-231 > Project: Maven Shade Plugin > Issue Type: Improvement >Reporter: Romain Manni-Bucau >Priority: Major > > Hi guys, > in tomee we create several flavors of tomee-embedded from tomee-embedded > module. > We basically deploy: > - tomee-embedded normal jar > - tomee-embedded "uber" shade > - tomee-embedded "jaxws" shade > - tomee-embedded "jaxrs" shade > We would add few more flavors if we can solve this issue: we can't get > reduced pom and attach it to let our users depend on the reduced pom. > Best would be to: > 1- have the reduced pom created in target/ > 2- attach it to deploy it with another artifact (to avoid pom conflicts) > is that something mvn-shade could do? > Here is the pom: > https://github.com/apache/tomee/blob/master/tomee/tomee-embedded/pom.xml#L55 > Side note: the obvious fix it to define 1 pom by shade but it would make the > maintenance harder for us and create inconsistencies long term. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MSHADE-230) Cannot specify custom manifest file in a shaded jar.
[ https://issues.apache.org/jira/browse/MSHADE-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MSHADE-230: - Issue Type: New Feature (was: Bug) > Cannot specify custom manifest file in a shaded jar. > > > Key: MSHADE-230 > URL: https://issues.apache.org/jira/browse/MSHADE-230 > Project: Maven Shade Plugin > Issue Type: New Feature >Affects Versions: 2.4.3 >Reporter: BlakeTNC >Priority: Major > > When a project uses the maven-jar-plugin, it's easy to include a custom (hand > written) manifest file in the jar, but I can't find a way to do the same > thing with maven shade. How can I use my own manifest file while using the > "maven-shade-plugin"? > Basic details: > My custom manifest file is located in > "src/main/resources/META-INF/MANIFEST.MF". Shade is not including my file, > instead it is being replaced in the final jar with a default manifest file. > The reason I need a custom manifest file is to specify some JavaBeans classes > in my manifest, for a swing component library. Multiple JavaBeans classes > should be specified in the manifest file in the following format, as > described here: > http://www.ewebprogrammer.com/java-beans/module3/javabeans-manifest-file.jsp > (Note that the order of these lines is important, as well as the empty lines > between them. The ManifestResourceTransformer could add the lines, but they > get added out of order and without the empty lines.) > Name: SomeBean1.class > Java-Bean: True > Name: SomeBean2.class > Java-Bean: True > Name: SomeBean3.class > Java-Bean: True > The POM file for this project is long, so I won't paste the whole thing here. > However, the current full POM for this project can be seen on github at this > link: > https://github.com/LGoodDatePicker/LGoodDatePicker/blob/master/Project/pom.xml > See the list of (unsuccessful) solutions I have tried (and additional > details), which are located here. > http://stackoverflow.com/questions/38243222/how-can-i-specify-a-custom-manifest-mf-file-while-using-the-maven-shade-plugin > Thank you. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MGPG-43) Allow signing of arbitrary artifacts
[ https://issues.apache.org/jira/browse/MGPG-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MGPG-43. --- Resolution: Won't Fix Since there's no activity here and this issue is scheduled for autoclosure anyway, I'm going to make an opinionated call that this is out of scope for the GPG plugin. Signing arbitrary files should be done with gpg itself, not a Maven plugin. If anyone wants to pick it up again, feel free to reopen. > Allow signing of arbitrary artifacts > > > Key: MGPG-43 > URL: https://issues.apache.org/jira/browse/MGPG-43 > Project: Maven GPG Plugin > Issue Type: New Feature >Reporter: Sebb >Priority: Major > Attachments: MGPG-43.patch, MGPG43-2.patch, MGPG43-3.patch, > MGPG43.patch > > > At present, the plugin relies on being run after the "package" phase, > presumably so it knows which files to sign. > This is fine if all the artifacts are intended for distribution via Maven > repos, but there are other distribution mechanisms where signed artifacts are > needed. For example, ASF releases to their mirror system. > It would be useful if there was a separate goal for signing files using > standard includes/excludes. > Ideally this would also be integrated with the assembly plugin somehow so it > could obtain the list of files from the plugin. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MGPG-43) Allow signing of arbitrary artifacts
[ https://issues.apache.org/jira/browse/MGPG-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MGPG-43. - > Allow signing of arbitrary artifacts > > > Key: MGPG-43 > URL: https://issues.apache.org/jira/browse/MGPG-43 > Project: Maven GPG Plugin > Issue Type: New Feature >Reporter: Sebb >Priority: Major > Attachments: MGPG-43.patch, MGPG43-2.patch, MGPG43-3.patch, > MGPG43.patch > > > At present, the plugin relies on being run after the "package" phase, > presumably so it knows which files to sign. > This is fine if all the artifacts are intended for distribution via Maven > repos, but there are other distribution mechanisms where signed artifacts are > needed. For example, ASF releases to their mirror system. > It would be useful if there was a separate goal for signing files using > standard includes/excludes. > Ideally this would also be integrated with the assembly plugin somehow so it > could obtain the list of files from the plugin. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNGSITE-271) CLONE - Better documentation related to repository order
[ https://issues.apache.org/jira/browse/MNGSITE-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MNGSITE-271: -- Priority: Minor (was: Major) > CLONE - Better documentation related to repository order > > > Key: MNGSITE-271 > URL: https://issues.apache.org/jira/browse/MNGSITE-271 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: Jakub Bochenski >Priority: Minor > > I was not able to find clear documentation describing the order of > repositories used during a build. For example, the documentation should > answer the following questions. > 1. Which repositories are used first, the ones defined in settings.xml or in > the pom.xml or super pom? > 2. The order of repositories defined in the settings.xml profiles seems to be > the reverse of what one would expect when viewed in the effective-pom, why is > this? > 3. If a repository ID in settings.xml matches one defined in pom.xml which > one takes priority? > Some additional information is available in the JBoss build forum. > http://community.jboss.org/thread/160185 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MRELEASE-721) Release plugin should not operate on current SVN trunk/branch to create the tag
[ https://issues.apache.org/jira/browse/MRELEASE-721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MRELEASE-721: --- Summary: Release plugin should not operate on current SVN trunk/branch to create the tag (was: Release plugin should not operate on current SVN tunk/branch to create the tag) > Release plugin should not operate on current SVN trunk/branch to create the > tag > --- > > Key: MRELEASE-721 > URL: https://issues.apache.org/jira/browse/MRELEASE-721 > Project: Maven Release Plugin > Issue Type: Bug >Reporter: Sebb >Priority: Major > > AIUI, the release plugin currently updates the trunk (or branch) working copy > in order to create the RC tag. > This is inherently unsafe, as the trunk loses its SNAPSHOT status for a short > while. > Also, if the RC fails, trunk has to be reset in order to start again. > A better method would be to check out trunk into a new working copy, update > that, and create the tag from the new WC. > This has the added benefit of creating a clean working copy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MRELEASE-721) Release plugin should not operate on current SVN trunk/branch to create the tag
[ https://issues.apache.org/jira/browse/MRELEASE-721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MRELEASE-721: --- Issue Type: Improvement (was: Bug) > Release plugin should not operate on current SVN trunk/branch to create the > tag > --- > > Key: MRELEASE-721 > URL: https://issues.apache.org/jira/browse/MRELEASE-721 > Project: Maven Release Plugin > Issue Type: Improvement >Reporter: Sebb >Priority: Major > > AIUI, the release plugin currently updates the trunk (or branch) working copy > in order to create the RC tag. > This is inherently unsafe, as the trunk loses its SNAPSHOT status for a short > while. > Also, if the RC fails, trunk has to be reset in order to start again. > A better method would be to check out trunk into a new working copy, update > that, and create the tag from the new WC. > This has the added benefit of creating a clean working copy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ARCHETYPE-369) scripting support
[ https://issues.apache.org/jira/browse/ARCHETYPE-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved ARCHETYPE-369. - Resolution: Won't Fix > scripting support > - > > Key: ARCHETYPE-369 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-369 > Project: Maven Archetype > Issue Type: New Feature > Components: Generator >Affects Versions: 2.0 >Reporter: Lucien Weller >Priority: Major > > I tried to implement a scripting support for maven-archetype. See git pull > request (https://github.com/apache/maven-archetype/pull/1) for further > details. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SUREFIRE-1169) JUnit / Arquillian lifecycle friendly test execution with forkCount > 1 and reuseForks = true
[
https://issues.apache.org/jira/browse/SUREFIRE-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed SUREFIRE-1169.
---
> JUnit / Arquillian lifecycle friendly test execution with forkCount > 1 and
> reuseForks = true
> -
>
> Key: SUREFIRE-1169
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1169
> Project: Maven Surefire
> Issue Type: Improvement
> Components: process forking
>Affects Versions: 2.18.1
>Reporter: Falko Modler
>Assignee: Tibor Digana
>Priority: Major
> Attachments: SUREFIRE-1169_forksExecuteTestsOneByOne.patch,
> SUREFIRE-1169_forksExecuteTestsOneByOne_FIXED.patch
>
>
> The current approach to "stream" each test class name to a fork via
> {{TestProvidingInputStream}} yields a good "load balancing" accross the forks
> but it *triggers the entire test lifecycle for each test*.
> With {{forkCount = 1}}, all tests are executed in one set but with
> {{forkCount = n}} (n > 1) each test is a separate "set" (so to say).
> This is very problematic in case you or a test framwork you are using relies
> on a certain lifecycle.
> [Arquillian|http://arquillian.org/] for example ties various "events" to
> JUnit's lifecycle methods, like {{AfterSuite}} to
> {{RunListener.testRunFinished(...)}} which triggers the shutdown of the
> managed server etc.
> When using multiple forks, {{RunListener.testRunFinished(...)}} is called for
> *every* single test class, triggering {{AfterSuite}} for every single test,
> although the fork will receive further tests after that which should "reuse"
> the server.
> This is just an example. In fact the whole JUnit / Arquillian lifecycle is
> inconsistent when using multiple forks.
> From a user perspective I wouldn't expect this behaviour:
> As {{forkCount = 1}} (and {{reusableForks = true}}) triggers
> {{RunListener.testRunFinished(...)}} *once*, {{forkCount = n}} (and
> {{reusableForks = true}}) should trigger that method *n* times, not *x* times.
> To be fair, the
> [documentation|https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html]
> *does* contain a pointer to that problem by saying:
> {quote}
> When using reuseForks=true and a forkCount value larger than one, test
> classes are handed over to the forked process one-by-one.
> {quote}
> But the consequences remain very unclear.
> *(Possible) Solution:*
> I took a stab at this and implemented an "eager test distribution" to the
> forks in {{ForkStart.java}} and disabled streaming. Please see attached patch
> (to be applied against project root, 2.18.1).
> Patch Details:
> - New config property: {{ForkConfiguration.forksExecuteTestsOneByOne}}, set
> via Mojo (default is true for backward compatibility, name is debatable)
> - When {{forksExecuteTestsOneByOne}} ist set to false, the {{messageQueue}}
> in {{ForkStarter.runSuitesForkOnceMultiple(...)}} is *not* wrapped in fork
> specific {{TestProvidingInputStream}} instances to be consumed bit by bit
> later on.
> Instead, the queue is consumed directly and each test class name is assigned
> to the respective fork by creating a copy of the {{providerProperties}} which
> is filled individually for each fork.
> E.g. for three forks and eight tests:
> -- fork 1 executes test 1, 4 and 7
> -- fork 2 executes test 2, 5 and 8
> -- fork 3 executes test 3 and 6
> - To have a clean {{providerProperties}} template I had to move
> {{DefaultScanResult.writeTo(...)}} to the respective private methods.
> Otherwise the properties would have contained *all* tests already.
> - I refactored some methods in {{ForkStarter}} to enhance readability and to
> reduce code duplication.
> - The patch does *not* contain a test for the new behaviour but all existing
> tests passed.
> {{forksExecuteTestsOneByOne = false}} now leads to a consistent lifecycle.
> This solution has one downside: One or more forks could be overloaded while
> other forks could "underloaded" because you cannot say how long each test
> will take. runOrder=balanced could help here but has yet to be implemented
> for forks.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MLINKCHECK-23) Linkcheck reports 302 Found on link that is redirected to itself.
[ https://issues.apache.org/jira/browse/MLINKCHECK-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000156#comment-17000156 ] Elliotte Rusty Harold commented on MLINKCHECK-23: - does this plugin follow redirects? > Linkcheck reports 302 Found on link that is redirected to itself. > - > > Key: MLINKCHECK-23 > URL: https://issues.apache.org/jira/browse/MLINKCHECK-23 > Project: Maven Linkcheck Plugin > Issue Type: Bug >Affects Versions: 1.2 > Environment: OS: Linux Mint, IntelliJ IDEA, checkstyle >Reporter: Andrei Selkin >Priority: Minor > > We use maven-linkcheck-plugin v. 1.2 to check links on checkstyle's website: > http://checkstyle.sourceforge.net/ with the following config: > > org.apache.maven.plugins > maven-linkcheck-plugin > 1.2 > > GET > 3000 > false > true > > dependencies.html > cobertura/** > dsm/** > xref/** > xref-test/** > pmd.html > findbugs.html > surefire-report.html > > taglist.html > > > > > http://iweb.dl.sourceforge.net/project/checkstyle/checkstyle/*-SNAPSHOT/checkstyle-*-SNAPSHOT-all.jar > reports/google-style/guava > reports/javadoc/openjdk8 > https://travis-ci.org/ > > https://travis-ci.org/checkstyle/checkstyle > > https://coveralls.io/r/checkstyle/checkstyle > http://search.maven.org/* > http://junit.org > > http://sonar-plugins.codehaus.org/maven-report > > **/com/puppycrawl/** > > > http://docs.oracle.com/javase/7/docs/api/org/xml/sax/helpers.DefaultHandler.html?* > > > 401 > > > > maven-linkcheck-plugin v. 1.2 reports 302 Found: > http://kclee.com/clemens/java/javancss/ > But according to redirect tracers the link is redirected directly to > http://kclee.com/clemens/java/javancss/ > Checkstyle's pom.xml: > https://github.com/checkstyle/checkstyle/blob/master/pom.xml > Redirect tracers: > http://www.wheregoes.com/retracer.php > http://www.internetofficer.com/seo-tool/redirect-check/ > http://redirectdetective.com/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MASSEMBLY-774) too many open files
[ https://issues.apache.org/jira/browse/MASSEMBLY-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000254#comment-17000254 ] Elliotte Rusty Harold commented on MASSEMBLY-774: - Is this fixed at head? > too many open files > --- > > Key: MASSEMBLY-774 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-774 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 2.5.5 >Reporter: Dan Armbrust >Assignee: Kristian Rosenvold >Priority: Major > > I ran across this - > http://mail-archives.apache.org/mod_mbox/maven-dev/201501.mbox/%3ca2ee0d04-04e3-4c99-8842-673463862...@takari.io%3E > - and since I'm making huge zip files, I thought I would give it a try. > I configured as: > > org.apache.maven.plugins > maven-assembly-plugin > 2.5.5 > > > org.codehaus.plexus > plexus-archiver > 3.0.1 > > > org.codehaus.plexus > plexus-io > 2.6 > > > > But this lead to a failure: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single (zip) on project > ... sememe/seg.3182.sememe.map (Too many open files) -> [Help 1] > I certainly could raise my ulimit: > darmbrust@overkill:/mnt/STORAGE/Work/Apelon/Workspaces/ISAAC-Core-2/va-solor-goods$ > ulimit -a > ... > open files (-n) 1024 > But it seems it would be better if the zip process limited itself to a > reasonable number of open files. I don't know the algorithm... but it seems > that double or triple the processor count would be more than enough. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MDEP-289) Incorrect warning with javax.xml
[ https://issues.apache.org/jira/browse/MDEP-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MDEP-289: --- Priority: Minor (was: Major) > Incorrect warning with javax.xml > > > Key: MDEP-289 > URL: https://issues.apache.org/jira/browse/MDEP-289 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: analyze >Affects Versions: 2.1 > Environment: OS : Windows XP > Maven 2.2.1 > Java 1.5 >Reporter: zaccret >Priority: Minor > Attachments: sandbox.zip > > > When you use some javax.xml classes in a project and that you have transitive > dependencies containing these classes, you will get a warning if you analyze > your dependencies (Used undeclared dependencies found), even if the classes > you use are contained in your JDK. > I attach a project using javax.xml.parsers.DocumentBuilder which is included > in Java Class Library (rt.jar) but also in a transitive dependency (xml-apis). > I think we should not get a warning because the Java Class Library should be > the first library found in the classpath, doesn't it ? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MDEP-310) We should be able to customize the filtering token when writing build-classpath goal's output in a file
[ https://issues.apache.org/jira/browse/MDEP-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MDEP-310. -- > We should be able to customize the filtering token when writing > build-classpath goal's output in a file > --- > > Key: MDEP-310 > URL: https://issues.apache.org/jira/browse/MDEP-310 > Project: Maven Dependency Plugin > Issue Type: Improvement > Components: build-classpath >Affects Versions: 2.2 > Environment: Not specific >Reporter: Mike Andrzejewski >Priority: Minor > Attachments: filteringToken.patch > > > The attached patch proposes to introduce an additional parameter > "filteringToken" which allows to customize the filtering token when writing > build-classpath goal's output in a file. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MDEP-310) We should be able to customize the filtering token when writing build-classpath goal's output in a file
[ https://issues.apache.org/jira/browse/MDEP-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MDEP-310. Resolution: Won't Fix don't seem t be any resources to address this > We should be able to customize the filtering token when writing > build-classpath goal's output in a file > --- > > Key: MDEP-310 > URL: https://issues.apache.org/jira/browse/MDEP-310 > Project: Maven Dependency Plugin > Issue Type: Improvement > Components: build-classpath >Affects Versions: 2.2 > Environment: Not specific >Reporter: Mike Andrzejewski >Priority: Minor > Attachments: filteringToken.patch > > > The attached patch proposes to introduce an additional parameter > "filteringToken" which allows to customize the filtering token when writing > build-classpath goal's output in a file. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MDEP-294) copy-dependencies goal doesn't properly respect classifier when creating base version of snapshots
[ https://issues.apache.org/jira/browse/MDEP-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MDEP-294: --- Priority: Minor (was: Major) > copy-dependencies goal doesn't properly respect classifier when creating base > version of snapshots > -- > > Key: MDEP-294 > URL: https://issues.apache.org/jira/browse/MDEP-294 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: copy-dependencies >Affects Versions: 2.1 >Reporter: Tim Downey >Priority: Minor > Attachments: CopyDependenciesMojo.java, > CopyDependenciesMojo.java.diff, TestCopyDependenciesMojo.java, > TestCopyDependenciesMojo2.diff > > > CopyDependenciesMojo ignores any classifier on the artifact being copied when > creating the base version of a snapshot. It works correctly for the non-base > (timestamped) version. This leads to a mismatch in the copied dependencies > where the timestamped version correctly keeps the classifier, but the base > -SNAPSHOT version has the classifier completely dropped. > The fix is simple, although a bit ugly. In the installBaseSnapshot method, a > check must be made for the presence of a classifier on the artifact being > copied before using the ArtifactFactory to create a copy of the base version. > Ideally, the ArtifactFactory would expose a single method that takes all > parameters, but unfortunately it does not. This requires a separate 'if' > check for the presence of a classifier. > Another potential issue is that the method > ArtifactFactory#createArtifactWithClassifier has no parameter for scope. I > don't think that causes any issue in this case, but is another reason why > there should be a single method createArtifact that takes all combinations of > parameters including classifier. > I've attached a patch that will fix the issue, but not a test case since it > looks like the maven-plugin-testing-tools-harness would need to be updated as > well. It doesn't appear to expose any artifacts that both have a classifier > and are snapshots from the ArtifactStubFactory. If deemed important, I can > produce a patch for that as well along with a test. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARCHETYPE-506) archetype:generate if pom.xml packaging value is pom,Chinese XML comments will change to ???
[
https://issues.apache.org/jira/browse/ARCHETYPE-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000148#comment-17000148
]
Elliotte Rusty Harold commented on ARCHETYPE-506:
-
sounds like an encoding issue somewhere. Anyone have a reproducible test case
handy?
> archetype:generate if pom.xml packaging value is pom,Chinese XML comments
> will change to ???
> --
>
> Key: ARCHETYPE-506
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-506
> Project: Maven Archetype
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: feilong
>Priority: Minor
>
> {{archetype:generate}} if pom.xml {{packaging}} value is pom,Chinese XML
> comments will change to {{???}}
> here is
> {code:xml}
>
>
> true
> org.apache.maven.plugins
> maven-surefire-plugin
> ${v.maven-surefire-plugin}
>
>
> true
>
>
> {code}
> if {{pom}}
> when i call mvn {{archetype:generate}}
> result is
> {code:xml}
>
>
> true
> org.apache.maven.plugins
> maven-surefire-plugin
> ${v.maven-surefire-plugin}
>
>
> true
>
>
> {code}
> but when {{war}}, result is ok
> And in
> http://maven.apache.org/archetype/maven-archetype-plugin/generate-mojo.html,
> I can't find any {{encode}} or {{charset}} param to set
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MLINKCHECK-25) Support the ability to set HTTP headers on requests generated by maven-linkchecker-plugin
[ https://issues.apache.org/jira/browse/MLINKCHECK-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MLINKCHECK-25. --- this is not a general pupose HTTP clioent and we don't have resources to make it one > Support the ability to set HTTP headers on requests generated by > maven-linkchecker-plugin > - > > Key: MLINKCHECK-25 > URL: https://issues.apache.org/jira/browse/MLINKCHECK-25 > Project: Maven Linkcheck Plugin > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: Richard Friend >Priority: Major > > We use the maven-linkcheck-plugin in order to verify that our developer > documentation does not contain any broken links. > When verifying links to external sites we need the ability to set HEADERs on > the HTTP requests generated by linkchecker. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SCM-833) getLastChangedRevision() returns null whereas as getRevision() get correct versions
[
https://issues.apache.org/jira/browse/SCM-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated SCM-833:
--
Priority: Minor (was: Major)
> getLastChangedRevision() returns null whereas as getRevision() get correct
> versions
> ---
>
> Key: SCM-833
> URL: https://issues.apache.org/jira/browse/SCM-833
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-api, maven-scm-provider-jgit
>Affects Versions: 1.9.4, 1.9.5
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> Currently there is a method like this in the code (buildnumber-maven-plugin):
> AbstractScmMojo.java:
> {code:java}
> protected String getScmRevision()
> throws ScmException
> {
> ScmRepository repository = getScmRepository();
> InfoScmResult scmResult = info( repository, new ScmFileSet(
> scmDirectory ) );
> if ( scmResult == null || scmResult.getInfoItems().isEmpty() )
> {
> return ( !StringUtils.isEmpty( revisionOnScmFailure ) ) ?
> revisionOnScmFailure : null;
> }
> checkResult( scmResult );
> InfoItem info = scmResult.getInfoItems().get( 0 );
>
> List infoItems = scmResult.getInfoItems();
>
> for (InfoItem infoItem : infoItems) {
> getLog().info("Item: " +infoItem.getRevision() + " lcr: " +
> infoItem.getLastChangedRevision() );
> }
> getLog().info("useLastCommittedRevision: " +
> useLastCommittedRevision);
> if ( useLastCommittedRevision )
> {
> return info.getLastChangedRevision();
> }
> return info.getRevision();
> }
> {code}
> The problem is simply that {{getLastChangedRevision()}} returns null whereas
> {{getRevision()}} returns the requested value?...
> So ATM I'm not sure if this is really a bug in SCM or a misusage in
> buildnumber-maven-plugin ?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MLINKCHECK-25) Support the ability to set HTTP headers on requests generated by maven-linkchecker-plugin
[ https://issues.apache.org/jira/browse/MLINKCHECK-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MLINKCHECK-25. - Resolution: Won't Fix > Support the ability to set HTTP headers on requests generated by > maven-linkchecker-plugin > - > > Key: MLINKCHECK-25 > URL: https://issues.apache.org/jira/browse/MLINKCHECK-25 > Project: Maven Linkcheck Plugin > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: Richard Friend >Priority: Major > > We use the maven-linkcheck-plugin in order to verify that our developer > documentation does not contain any broken links. > When verifying links to external sites we need the ability to set HEADERs on > the HTTP requests generated by linkchecker. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCHANGES-150) [regression] Incorrect parsing of the element
[
https://issues.apache.org/jira/browse/MCHANGES-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000216#comment-17000216
]
Elliotte Rusty Harold commented on MCHANGES-150:
sounds like this might be more important than just this one case
> [regression] Incorrect parsing of the element
> --
>
> Key: MCHANGES-150
> URL: https://issues.apache.org/jira/browse/MCHANGES-150
> Project: Maven Changes Plugin
> Issue Type: Bug
> Components: changes.xml, modello
>Affects Versions: 2.1
>Reporter: Paul Benedict
>Priority: Major
> Attachments: MNG-4045-debug.txt, MNG-4045.zip, changes.xml
>
>
> I was locking down my Maven Changes Plugin version with the following config:
> {code}
>
>
> org.apache.maven.plugins
> maven-changes-plugin
> 2.1
>
>
>
> changes-report
>
>
>
>
>
> {code}
> And then I created the site and noticed the report was empty. The report
> markup was there, of course, but it generated like my changes.xml was blank.
> I could run changes:changes-report just fine. However, when I then removed
> the tag and tried site:site again, the report output was present as
> expected.
> Here's an interesting line from the debug output when is specified:
> {quote}[DEBUG] The following artifacts were filtered out for plugin:
> org.apache.maven.plugins:maven-changes-plugin:2.1 because they're already in
> the core of Maven:{quote}
> My theory is that because my plugin version has an exact match on the
> version, my specified plugin configuration is tossed. That certainly seems
> like a bug to me.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MDEP-505) Apply stripClassifier to folder naming, also add stripType
[
https://issues.apache.org/jira/browse/MDEP-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MDEP-505.
--
> Apply stripClassifier to folder naming, also add stripType
> --
>
> Key: MDEP-505
> URL: https://issues.apache.org/jira/browse/MDEP-505
> Project: Maven Dependency Plugin
> Issue Type: Improvement
> Components: unpack-dependencies
>Affects Versions: 2.10
> Environment: Eclipse Mars
> Java 1.8u60 x64
> Windows 7 Pro
>Reporter: Jesse Shaffer
>Priority: Major
>
> First off, I'm new to this, so what I'm trying to accomplish may be doable
> another way. Basically, I am trying to unpack dependencies into directories
> based solely on the artifactId, but so far have been stymied.
> {code:xml}
>
> unpack-modules
> generate-resources
>
> unpack-dependencies
>
>
> modules.source
> META-INF/**
> true
> true
> true
> true
> true
>
> ${project.build.directory}/${project.artifactId}-${project.version}/modules
>
>
> {code}
> Based on the above configuration, the modules get extracted into
> /modules/{artifactId}-{classifier}-{type}. However, what I'm wanting is for
> my modules to be extracted into /modules/{artifactId}.
> Part of this feels more like a bug, seeing as MDEP-295 was requested but not
> implemented for directories. In any case, I would also need to have the type
> stripped out also.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MDEP-507) dependency:resolve-plugins and dependency:go-offline doesn't respect plugin dependencies from pom.xml
[
https://issues.apache.org/jira/browse/MDEP-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MDEP-507:
---
Priority: Minor (was: Major)
> dependency:resolve-plugins and dependency:go-offline doesn't respect plugin
> dependencies from pom.xml
> -
>
> Key: MDEP-507
> URL: https://issues.apache.org/jira/browse/MDEP-507
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: go-offline, resolve-plugins
>Affects Versions: 2.8
> Environment: linux, java version "1.8.0_60", maven 3.3.3
>Reporter: Marek Hudik
>Priority: Minor
>
> When I override plugin dependecies in {{pom.xml}} then
> dependency:resolve-plugins and dependency:go-offline displays wrong
> dependencies.
> This example shows selenium version {{2.21.0}} instead of {{2.47.1}}. The
> only way to check what is used is to delete local maven repo, execute the
> target and see what dependencies were downloaded.
> {{pom.xml}}
> {noformat}
>
> org.codehaus.mojo
> selenium-maven-plugin
> 2.3
>
>
> org.seleniumhq.selenium
> selenium-server
> 2.47.1
>
>
> org.seleniumhq.selenium
>
> selenium-remote-driver
> 2.47.1
>
>
> org.seleniumhq.selenium
> selenium-api
> 2.47.1
>
>
> {noformat}
> {{mvn dependency:resolve-plugins}}
> {noformat}
> [INFO] Plugin Resolved: selenium-maven-plugin-2.3.jar
> [INFO] Plugin Dependency Resolved: gmaven-mojo-1.3.jar
> [INFO] Plugin Dependency Resolved: gmaven-mojo-support-1.3.jar
> [INFO] Plugin Dependency Resolved: groovy-all-1.7.5.jar
> [INFO] Plugin Dependency Resolved: selenium-server-2.21.0.jar
> [INFO] Plugin Dependency Resolved: selenium-remote-driver-2.21.0.jar
> [INFO] Plugin Dependency Resolved: selenium-api-2.21.0.jar
> [INFO] Plugin Dependency Resolved: selenium-remote-control-2.0rc2.jar
> [INFO] Plugin Dependency Resolved: bcprov-jdk15-140.jar
> [INFO] Plugin Dependency Resolved: guava-10.0.1.jar
> [INFO] Plugin Dependency Resolved: commons-exec-1.1.jar
> [INFO] Plugin Dependency Resolved: commons-logging-1.1.1.jar
> [INFO] Plugin Dependency Resolved: selenium-java-client-driver-1.0.2.jar
> [INFO] Plugin Dependency Resolved: servlet-api-2.4.jar
> [INFO] Plugin Dependency Resolved: commons-lang-2.4.jar
> [INFO] Plugin Dependency Resolved: commons-codec-1.5.jar
> [INFO] Plugin Dependency Resolved: log4j-1.2.14.jar
> {noformat}
> {{mvn dependency:go-offline}}
> {noformat}
> [INFO] Plugin Resolved: selenium-maven-plugin-2.3.jar
> [INFO] Plugin Dependency Resolved: gmaven-mojo-1.3.jar
> [INFO] Plugin Dependency Resolved: gmaven-mojo-support-1.3.jar
> [INFO] Plugin Dependency Resolved: groovy-all-1.7.5.jar
> [INFO] Plugin Dependency Resolved: selenium-server-2.21.0.jar
> [INFO] Plugin Dependency Resolved: selenium-remote-driver-2.21.0.jar
> [INFO] Plugin Dependency Resolved: selenium-api-2.21.0.jar
> [INFO] Plugin Dependency Resolved: selenium-remote-control-2.0rc2.jar
> [INFO] Plugin Dependency Resolved: bcprov-jdk15-140.jar
> [INFO] Plugin Dependency Resolved: guava-10.0.1.jar
> [INFO] Plugin Dependency Resolved: commons-exec-1.1.jar
> [INFO] Plugin Dependency Resolved: commons-logging-1.1.1.jar
> [INFO] Plugin Dependency Resolved: selenium-java-client-driver-1.0.2.jar
> [INFO] Plugin Dependency Resolved: servlet-api-2.4.jar
> [INFO] Plugin Dependency Resolved: commons-lang-2.4.jar
> [INFO] Plugin Dependency Resolved: commons-codec-1.5.jar
> [INFO] Plugin Dependency Resolved: log4j-1.2.14.jar
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MDEP-505) Apply stripClassifier to folder naming, also add stripType
[
https://issues.apache.org/jira/browse/MDEP-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MDEP-505.
Resolution: Won't Fix
> Apply stripClassifier to folder naming, also add stripType
> --
>
> Key: MDEP-505
> URL: https://issues.apache.org/jira/browse/MDEP-505
> Project: Maven Dependency Plugin
> Issue Type: Improvement
> Components: unpack-dependencies
>Affects Versions: 2.10
> Environment: Eclipse Mars
> Java 1.8u60 x64
> Windows 7 Pro
>Reporter: Jesse Shaffer
>Priority: Major
>
> First off, I'm new to this, so what I'm trying to accomplish may be doable
> another way. Basically, I am trying to unpack dependencies into directories
> based solely on the artifactId, but so far have been stymied.
> {code:xml}
>
> unpack-modules
> generate-resources
>
> unpack-dependencies
>
>
> modules.source
> META-INF/**
> true
> true
> true
> true
> true
>
> ${project.build.directory}/${project.artifactId}-${project.version}/modules
>
>
> {code}
> Based on the above configuration, the modules get extracted into
> /modules/{artifactId}-{classifier}-{type}. However, what I'm wanting is for
> my modules to be extracted into /modules/{artifactId}.
> Part of this feels more like a bug, seeing as MDEP-295 was requested but not
> implemented for directories. In any case, I would also need to have the type
> stripped out also.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MDEP-503) Add parameter "assignProperty" to dependency:list
[
https://issues.apache.org/jira/browse/MDEP-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MDEP-503.
--
> Add parameter "assignProperty" to dependency:list
> -
>
> Key: MDEP-503
> URL: https://issues.apache.org/jira/browse/MDEP-503
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Components: tree
>Reporter: Leo Breuss
>Priority: Major
>
> Add to dependency:list a new parameter assignProperty, that will assign the
> results of the list goal to the specified property.
> Example:{code}
> assignProperty=my-found-artifacts
> {code}
> The resulting artifacts are assigned as a list to the property
> {{my-found-artifacts}}.
> Useful to avoid generating temporary files on disk.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MDEP-503) Add parameter "assignProperty" to dependency:list
[
https://issues.apache.org/jira/browse/MDEP-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MDEP-503.
Resolution: Won't Fix
resources are limited and existing approach works well enough
> Add parameter "assignProperty" to dependency:list
> -
>
> Key: MDEP-503
> URL: https://issues.apache.org/jira/browse/MDEP-503
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Components: tree
>Reporter: Leo Breuss
>Priority: Major
>
> Add to dependency:list a new parameter assignProperty, that will assign the
> results of the list goal to the specified property.
> Example:{code}
> assignProperty=my-found-artifacts
> {code}
> The resulting artifacts are assigned as a list to the property
> {{my-found-artifacts}}.
> Useful to avoid generating temporary files on disk.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MINVOKER-125) Global variable about the target folder into the groovy scripts.
[
https://issues.apache.org/jira/browse/MINVOKER-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MINVOKER-125:
---
Issue Type: New Feature (was: Improvement)
> Global variable about the target folder into the groovy scripts.
>
>
> Key: MINVOKER-125
> URL: https://issues.apache.org/jira/browse/MINVOKER-125
> Project: Maven Invoker Plugin
> Issue Type: New Feature
>Affects Versions: 1.5
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> Often (may be everytime) groovy scripts (post-build) which are doing work in
> relationship with integration-tests must access the *target* folder to check
> results etc. But currently i have to hard code the folder "target" by
> contrast in the pom.xml there already exists a good replacement for that
> $\{project.build.directory} so it would be very helpful to have an context
> information like "target" which represents the target folder.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (DOXIASITETOOLS-156) fail if deprecated ${reports}, ${parentProject} or ${modules} is found
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated DOXIASITETOOLS-156:
-
Priority: Minor (was: Major)
> fail if deprecated ${reports}, ${parentProject} or ${modules} is found
> --
>
> Key: DOXIASITETOOLS-156
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-156
> Project: Maven Doxia Sitetools
> Issue Type: Task
> Components: Integration Tools
>Affects Versions: 1.7
>Reporter: Herve Boutemy
>Priority: Minor
>
> we say for long that this feature is deprecated: doing a clear failure with a
> notice is easy to do and will help users update their site.xml
> we could have done a warning in DOXIASITETOOLS-163...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SUREFIRE-1169) JUnit / Arquillian lifecycle friendly test execution with forkCount > 1 and reuseForks = true
[
https://issues.apache.org/jira/browse/SUREFIRE-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved SUREFIRE-1169.
-
Resolution: Won't Fix
can't imagine this is going to happen unless someone dedicates a lot of work to
it, and the current setup at least works.
> JUnit / Arquillian lifecycle friendly test execution with forkCount > 1 and
> reuseForks = true
> -
>
> Key: SUREFIRE-1169
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1169
> Project: Maven Surefire
> Issue Type: Improvement
> Components: process forking
>Affects Versions: 2.18.1
>Reporter: Falko Modler
>Assignee: Tibor Digana
>Priority: Major
> Attachments: SUREFIRE-1169_forksExecuteTestsOneByOne.patch,
> SUREFIRE-1169_forksExecuteTestsOneByOne_FIXED.patch
>
>
> The current approach to "stream" each test class name to a fork via
> {{TestProvidingInputStream}} yields a good "load balancing" accross the forks
> but it *triggers the entire test lifecycle for each test*.
> With {{forkCount = 1}}, all tests are executed in one set but with
> {{forkCount = n}} (n > 1) each test is a separate "set" (so to say).
> This is very problematic in case you or a test framwork you are using relies
> on a certain lifecycle.
> [Arquillian|http://arquillian.org/] for example ties various "events" to
> JUnit's lifecycle methods, like {{AfterSuite}} to
> {{RunListener.testRunFinished(...)}} which triggers the shutdown of the
> managed server etc.
> When using multiple forks, {{RunListener.testRunFinished(...)}} is called for
> *every* single test class, triggering {{AfterSuite}} for every single test,
> although the fork will receive further tests after that which should "reuse"
> the server.
> This is just an example. In fact the whole JUnit / Arquillian lifecycle is
> inconsistent when using multiple forks.
> From a user perspective I wouldn't expect this behaviour:
> As {{forkCount = 1}} (and {{reusableForks = true}}) triggers
> {{RunListener.testRunFinished(...)}} *once*, {{forkCount = n}} (and
> {{reusableForks = true}}) should trigger that method *n* times, not *x* times.
> To be fair, the
> [documentation|https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html]
> *does* contain a pointer to that problem by saying:
> {quote}
> When using reuseForks=true and a forkCount value larger than one, test
> classes are handed over to the forked process one-by-one.
> {quote}
> But the consequences remain very unclear.
> *(Possible) Solution:*
> I took a stab at this and implemented an "eager test distribution" to the
> forks in {{ForkStart.java}} and disabled streaming. Please see attached patch
> (to be applied against project root, 2.18.1).
> Patch Details:
> - New config property: {{ForkConfiguration.forksExecuteTestsOneByOne}}, set
> via Mojo (default is true for backward compatibility, name is debatable)
> - When {{forksExecuteTestsOneByOne}} ist set to false, the {{messageQueue}}
> in {{ForkStarter.runSuitesForkOnceMultiple(...)}} is *not* wrapped in fork
> specific {{TestProvidingInputStream}} instances to be consumed bit by bit
> later on.
> Instead, the queue is consumed directly and each test class name is assigned
> to the respective fork by creating a copy of the {{providerProperties}} which
> is filled individually for each fork.
> E.g. for three forks and eight tests:
> -- fork 1 executes test 1, 4 and 7
> -- fork 2 executes test 2, 5 and 8
> -- fork 3 executes test 3 and 6
> - To have a clean {{providerProperties}} template I had to move
> {{DefaultScanResult.writeTo(...)}} to the respective private methods.
> Otherwise the properties would have contained *all* tests already.
> - I refactored some methods in {{ForkStarter}} to enhance readability and to
> reduce code duplication.
> - The patch does *not* contain a test for the new behaviour but all existing
> tests passed.
> {{forksExecuteTestsOneByOne = false}} now leads to a consistent lifecycle.
> This solution has one downside: One or more forks could be overloaded while
> other forks could "underloaded" because you cannot say how long each test
> will take. runOrder=balanced could help here but has yet to be implemented
> for forks.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MASSEMBLY-778) Treat missing file as an error
[
https://issues.apache.org/jira/browse/MASSEMBLY-778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MASSEMBLY-778.
---
> Treat missing file as an error
> --
>
> Key: MASSEMBLY-778
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-778
> Project: Maven Assembly Plugin
> Issue Type: New Feature
>Reporter: Kenneth Glidden
>Priority: Major
>
> If a file specified for inclusion in the descriptor...
> e.g.
> {noformat}
>
> false
> lib
>
> bt${artifact.artifactId}-${artifact.version}${dashClassifier?}.${artifact.extension}
> true
> true
>
> com.basistech:common-api
> com.basistech:common-lib
>
>
> {noformat}
> ... is missing, maven simply reports a warning:
> {noformat}
> [INFO] --- maven-assembly-plugin:2.5.5:single (assemble-distribution) @
> rbl-distribution ---
> [INFO] Reading assembly descriptor: src/main/assembly/all.xml
> [WARNING] The following patterns were never triggered in this artifact
> inclusion filter:
> o 'com.basistech:common-api'
> o 'com.basistech:common-lib'
> {noformat}
> I want an option to tell the plugin to treat this as an error so that it is
> obvious that the assembly is missing files I need.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MASSEMBLY-778) Treat missing file as an error
[
https://issues.apache.org/jira/browse/MASSEMBLY-778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MASSEMBLY-778.
-
Resolution: Won't Fix
> Treat missing file as an error
> --
>
> Key: MASSEMBLY-778
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-778
> Project: Maven Assembly Plugin
> Issue Type: New Feature
>Reporter: Kenneth Glidden
>Priority: Major
>
> If a file specified for inclusion in the descriptor...
> e.g.
> {noformat}
>
> false
> lib
>
> bt${artifact.artifactId}-${artifact.version}${dashClassifier?}.${artifact.extension}
> true
> true
>
> com.basistech:common-api
> com.basistech:common-lib
>
>
> {noformat}
> ... is missing, maven simply reports a warning:
> {noformat}
> [INFO] --- maven-assembly-plugin:2.5.5:single (assemble-distribution) @
> rbl-distribution ---
> [INFO] Reading assembly descriptor: src/main/assembly/all.xml
> [WARNING] The following patterns were never triggered in this artifact
> inclusion filter:
> o 'com.basistech:common-api'
> o 'com.basistech:common-lib'
> {noformat}
> I want an option to tell the plugin to treat this as an error so that it is
> obvious that the assembly is missing files I need.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Reopened] (MASSEMBLY-778) Treat missing file as an error
[
https://issues.apache.org/jira/browse/MASSEMBLY-778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold reopened MASSEMBLY-778:
-
> Treat missing file as an error
> --
>
> Key: MASSEMBLY-778
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-778
> Project: Maven Assembly Plugin
> Issue Type: New Feature
>Reporter: Kenneth Glidden
>Priority: Major
>
> If a file specified for inclusion in the descriptor...
> e.g.
> {noformat}
>
> false
> lib
>
> bt${artifact.artifactId}-${artifact.version}${dashClassifier?}.${artifact.extension}
> true
> true
>
> com.basistech:common-api
> com.basistech:common-lib
>
>
> {noformat}
> ... is missing, maven simply reports a warning:
> {noformat}
> [INFO] --- maven-assembly-plugin:2.5.5:single (assemble-distribution) @
> rbl-distribution ---
> [INFO] Reading assembly descriptor: src/main/assembly/all.xml
> [WARNING] The following patterns were never triggered in this artifact
> inclusion filter:
> o 'com.basistech:common-api'
> o 'com.basistech:common-lib'
> {noformat}
> I want an option to tell the plugin to treat this as an error so that it is
> obvious that the assembly is missing files I need.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MASSEMBLY-778) Treat missing file as an error
[
https://issues.apache.org/jira/browse/MASSEMBLY-778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MASSEMBLY-778.
-
Resolution: Fixed
We have too many config options already.
> Treat missing file as an error
> --
>
> Key: MASSEMBLY-778
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-778
> Project: Maven Assembly Plugin
> Issue Type: New Feature
>Reporter: Kenneth Glidden
>Priority: Major
>
> If a file specified for inclusion in the descriptor...
> e.g.
> {noformat}
>
> false
> lib
>
> bt${artifact.artifactId}-${artifact.version}${dashClassifier?}.${artifact.extension}
> true
> true
>
> com.basistech:common-api
> com.basistech:common-lib
>
>
> {noformat}
> ... is missing, maven simply reports a warning:
> {noformat}
> [INFO] --- maven-assembly-plugin:2.5.5:single (assemble-distribution) @
> rbl-distribution ---
> [INFO] Reading assembly descriptor: src/main/assembly/all.xml
> [WARNING] The following patterns were never triggered in this artifact
> inclusion filter:
> o 'com.basistech:common-api'
> o 'com.basistech:common-lib'
> {noformat}
> I want an option to tell the plugin to treat this as an error so that it is
> obvious that the assembly is missing files I need.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MSHARED-433) DependencyConvergence doesn't acknowledge exclusion wildcards (MNG-2315)
[ https://issues.apache.org/jira/browse/MSHARED-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MSHARED-433. - > DependencyConvergence doesn't acknowledge exclusion wildcards (MNG-2315) > > > Key: MSHARED-433 > URL: https://issues.apache.org/jira/browse/MSHARED-433 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-dependency-tree >Affects Versions: maven-dependency-tree-2.2 >Reporter: Karl Heinz Marbaise >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MDEP-523) Unused dependency not detected when present in test classes
[ https://issues.apache.org/jira/browse/MDEP-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MDEP-523: --- Priority: Minor (was: Major) > Unused dependency not detected when present in test classes > --- > > Key: MDEP-523 > URL: https://issues.apache.org/jira/browse/MDEP-523 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: analyze >Affects Versions: 2.10 >Reporter: Victor >Priority: Minor > > Hi, > I realised that analyze-only was returning unexpected resuls. > Basically, I have one simple maven project as defined here: > https://gist.github.com/victornoel/713a3b17999f353030bed949b79970d8 > The java test file is in the src/test/java/test/test/Test.java > If I run mvn verify on that, the dependency plugin does not complain about > the fact that the commons-lang3 dependency is not used in compile scope as I > would expect it to. > If I comment the use of the dependency in the Test.java file, then > maven-dependency-plugin complains about the non-use of the dependency. > Am I mistaken on the expected behaviour of analyze? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MDEP-519) Dependency tree with description of each artefacts
[ https://issues.apache.org/jira/browse/MDEP-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MDEP-519. Resolution: Won't Fix Since there's no activity here and this issue is scheduled for autoclosure anyway, I'm going to make an opinionated call that we shouldn't fix this. Our output is too verbose already. > Dependency tree with description of each artefacts > -- > > Key: MDEP-519 > URL: https://issues.apache.org/jira/browse/MDEP-519 > Project: Maven Dependency Plugin > Issue Type: Improvement > Components: tree >Affects Versions: 2.10 >Reporter: Eric Reboisson >Priority: Major > Labels: newbie > > Hello, > I would like to generate a maven dependency tree with a description of each > artefacts. > For instance, in my dependencies, due to transitive dependency antlr is in my > libs, but (even if I know what is this librairies) I would like to generate a > kind of documentation. > If I take the example of antlr artefact I would like something like this : | > | | +- antlr:antlr:jar:2.7.7:compile "A framework for constructing > recognizers, compilers, and translators from grammatical descriptions > containing Java, C#, C++, or Python actions." > > The description is coming from > central.maven.org/maven2/antlr/antlr/2.7.7/antlr-2.7.7.pom -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MDEP-485) unpack-dependencies should be able to use subdirectories per classifier
[
https://issues.apache.org/jira/browse/MDEP-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MDEP-485:
---
Issue Type: New Feature (was: Improvement)
> unpack-dependencies should be able to use subdirectories per classifier
> ---
>
> Key: MDEP-485
> URL: https://issues.apache.org/jira/browse/MDEP-485
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Components: unpack-dependencies
>Affects Versions: 2.10
>Reporter: Dirk Rudolph
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> When using classifiers to build environment specific artefacts, aggregating
> them to for example a single deployment unit (in my case its an rpm file,
> using the rpm plugin) would be easier when there would be a configuration
> option to unpack all dependencies to a subdirectory per classifier.
> {code}
>
> true
>
> {code}
> In this case we could easily unpack all dependencies build for development
> environment to a single place. Adding a new artefact would require adding a
> dependency and *not* changing the plugin configuration for the build of the
> deployment unit.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MCHANGES-365) Add Link to Action
[
https://issues.apache.org/jira/browse/MCHANGES-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MCHANGES-365:
---
Priority: Minor (was: Major)
> Add Link to Action
> --
>
> Key: MCHANGES-365
> URL: https://issues.apache.org/jira/browse/MCHANGES-365
> Project: Maven Changes Plugin
> Issue Type: New Feature
> Components: announcement
>Affects Versions: 2.11
>Reporter: dur
>Priority: Minor
> Labels: close-pending
>
> Add property link to class Action to support links in an announcment.
> Property should copied in
> {code}
> /**
> * Create an Action from an issue.
> *
> * @param issue The issue to extract the information from
> * @return An Action
> */
> public Action createAction( Issue issue )
> {
> Action action = new Action();
> // @todo We need to add something like
> issue.getPresentationIdentifier() to be able to support other IMSes
> // beside JIRA
> action.setIssue( issue.getKey() );
> // Try to map the IMS-specific issue type to one that is used in a
> changes.xml file
> IssueType type;
> if ( getIssueTypeMap().containsKey( issue.getType() ) )
> {
> type = getIssueTypeMap().get( issue.getType() );
> action.setType( type.modelRepresentation() );
> }
> else
> {
> action.setType( UNKNOWN_ISSUE_TYPE );
> }
> action.setDev( issue.getAssignee() );
> // Set dueTo to the empty String instead of null to make Velocity
> happy
> action.setDueTo( "" );
> // action.setDueTo( issue.getReporter() );
> action.setAction( issue.getSummary() );
> return action;
> }
> {code}
> For example with following line:
> {code}
> action.setLink(issue.getLink());
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MLINKCHECK-23) Linkcheck reports 302 Found on link that is redirected to itself.
[ https://issues.apache.org/jira/browse/MLINKCHECK-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MLINKCHECK-23: Priority: Minor (was: Major) > Linkcheck reports 302 Found on link that is redirected to itself. > - > > Key: MLINKCHECK-23 > URL: https://issues.apache.org/jira/browse/MLINKCHECK-23 > Project: Maven Linkcheck Plugin > Issue Type: Bug >Affects Versions: 1.2 > Environment: OS: Linux Mint, IntelliJ IDEA, checkstyle >Reporter: Andrei Selkin >Priority: Minor > > We use maven-linkcheck-plugin v. 1.2 to check links on checkstyle's website: > http://checkstyle.sourceforge.net/ with the following config: > > org.apache.maven.plugins > maven-linkcheck-plugin > 1.2 > > GET > 3000 > false > true > > dependencies.html > cobertura/** > dsm/** > xref/** > xref-test/** > pmd.html > findbugs.html > surefire-report.html > > taglist.html > > > > > http://iweb.dl.sourceforge.net/project/checkstyle/checkstyle/*-SNAPSHOT/checkstyle-*-SNAPSHOT-all.jar > reports/google-style/guava > reports/javadoc/openjdk8 > https://travis-ci.org/ > > https://travis-ci.org/checkstyle/checkstyle > > https://coveralls.io/r/checkstyle/checkstyle > http://search.maven.org/* > http://junit.org > > http://sonar-plugins.codehaus.org/maven-report > > **/com/puppycrawl/** > > > http://docs.oracle.com/javase/7/docs/api/org/xml/sax/helpers.DefaultHandler.html?* > > > 401 > > > > maven-linkcheck-plugin v. 1.2 reports 302 Found: > http://kclee.com/clemens/java/javancss/ > But according to redirect tracers the link is redirected directly to > http://kclee.com/clemens/java/javancss/ > Checkstyle's pom.xml: > https://github.com/checkstyle/checkstyle/blob/master/pom.xml > Redirect tracers: > http://www.wheregoes.com/retracer.php > http://www.internetofficer.com/seo-tool/redirect-check/ > http://redirectdetective.com/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-5926) Allow for comment elements inside POM
[ https://issues.apache.org/jira/browse/MNG-5926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MNG-5926: --- Issue Type: New Feature (was: Improvement) > Allow for comment elements inside POM > - > > Key: MNG-5926 > URL: https://issues.apache.org/jira/browse/MNG-5926 > Project: Maven > Issue Type: New Feature > Components: POM >Reporter: James Green >Priority: Trivial > Fix For: Issues to be reviewed for 4.x > > > I have spent hours tracking down why something exists as it does within a > company POM. On multiple occasions. > All because there is no obvious documentation for things like dependencies. > Yes, we could use XML comments but these will not show in the results of any > documentation tools. > What I am asking for is a element to be permitted within a > , , and probably a few other areas but those are real > immediate areas of need. > This was discussed briefly on the -users mailing list many months ago and was > generally met with approval. I can't remember adding it here though... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MLINKCHECK-25) Support the ability to set HTTP headers on requests generated by maven-linkchecker-plugin
[ https://issues.apache.org/jira/browse/MLINKCHECK-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000152#comment-17000152 ] Elliotte Rusty Harold edited comment on MLINKCHECK-25 at 12/19/19 3:58 PM: --- this is not a general pupose HTTP clioent and we don't have resources to make it one. Links can be checked without custom headers given a properly configured website. That's all this does. was (Author: elharo): this is not a general pupose HTTP clioent and we don't have resources to make it one > Support the ability to set HTTP headers on requests generated by > maven-linkchecker-plugin > - > > Key: MLINKCHECK-25 > URL: https://issues.apache.org/jira/browse/MLINKCHECK-25 > Project: Maven Linkcheck Plugin > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: Richard Friend >Priority: Major > > We use the maven-linkcheck-plugin in order to verify that our developer > documentation does not contain any broken links. > When verifying links to external sites we need the ability to set HEADERs on > the HTTP requests generated by linkchecker. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MRELEASE-206) Pass MAVEN_OPTS to the forked release build
[ https://issues.apache.org/jira/browse/MRELEASE-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MRELEASE-206: --- Summary: Pass MAVEN_OPTS to the forked release build (was: its not possible to pass MAVEN_OPTS to the forked release build) > Pass MAVEN_OPTS to the forked release build > --- > > Key: MRELEASE-206 > URL: https://issues.apache.org/jira/browse/MRELEASE-206 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.0-beta-3, 2.0-beta-4 >Reporter: Brian E Fox >Priority: Major > Labels: contributers-welcome > > I need to increase my jvm size for my build. The forked release doesn't get > the maven_opts. I tried the -Darguments: > mvn release:prepare -DdryRun=true -Darguments=-Xmx1024m > gets me this: >[INFO] Invalid task 'mx1024m': you must specify a valid lifecycle phase, > or > a goal in the format plugin:goal or > pluginGroupId:pluginArtifactId:pluginVersion > :goal -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MRELEASE-915) Forked execution of perform leaks source roots
[ https://issues.apache.org/jira/browse/MRELEASE-915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MRELEASE-915: --- Priority: Minor (was: Major) > Forked execution of perform leaks source roots > -- > > Key: MRELEASE-915 > URL: https://issues.apache.org/jira/browse/MRELEASE-915 > Project: Maven Release Plugin > Issue Type: Bug > Components: perform >Affects Versions: 2.5.1 >Reporter: Benson Margulies >Priority: Minor > > https://github.com/bimargulies/release-root-leakage is a test case for the > following: > If you add a source root in generate-sources in a pom, that source root will > show up in the 'validate' phase in the forked execution for release:perform. > This causes checkstyle to see things that it should not, if nothing else bad. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SUREFIRE-1237) Running suites forked
[ https://issues.apache.org/jira/browse/SUREFIRE-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed SUREFIRE-1237. --- > Running suites forked > - > > Key: SUREFIRE-1237 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1237 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Surefire Plugin >Affects Versions: 2.19.1 >Reporter: Koen Serneels >Priority: Major > > I have a Maven module in which I grouped test classes based on their package > into different TestNG suite files. The different suite's are listed in the > plugin config using . The tests identified by the suites are > ran sequentially ootb by surefire. With the current version it is already > possible to run the tests within the suites in parallel using multiple > threads (within a single JVM). > However, in my situation I need them to run forked in different JMVs. So what > I want is a JVM fork per suite XML file and not multiple threads. While > there are also fork options, they don't seem to work in combination with > suite XML files (but rather with methods and or test classes). > So, what I'm after is an option that creates a pool of forked JVM's which > takes care of running the available suite XML files. For ex. > "suites 8". Each fork will then execute it's > test (as identified by the suite XML file) in sequence. So for example, in > the config given above, there will be 8 forked JVM's. When I have 10 suite > XML files, each JVM will start working on the tests identified by its > assigned suite XML. So, JVM1 will run all tests (sequentially) identified by > suite XML1. In parallel, JVM2-8 will do the same thing for their assigned > suite XML. From the moment a forked JVM is done processing its suite XML file > it will start on the next one until they are all processed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MINSTALL-119) installAtEnd not installing when used together with tycho
[ https://issues.apache.org/jira/browse/MINSTALL-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MINSTALL-119: --- Priority: Minor (was: Major) > installAtEnd not installing when used together with tycho > - > > Key: MINSTALL-119 > URL: https://issues.apache.org/jira/browse/MINSTALL-119 > Project: Maven Install Plugin > Issue Type: Bug > Components: install:install >Affects Versions: 2.5.2 >Reporter: Ralf Sieger >Priority: Minor > > We use the installAtEnd flag in our maven/tycho build to install all the > plugins only if everything works together. > This works if only the plugins are build. > If we use this flag in a greater container where features and products are > build, too. We see entries like: > [INFO] Installing -SNAPSHOT at end > But the corresponding entry at the end of the build is missing: > [INFO] Installing ... to ... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SUREFIRE-1237) Running suites forked
[ https://issues.apache.org/jira/browse/SUREFIRE-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved SUREFIRE-1237. - Resolution: Won't Fix > Running suites forked > - > > Key: SUREFIRE-1237 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1237 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Surefire Plugin >Affects Versions: 2.19.1 >Reporter: Koen Serneels >Priority: Major > > I have a Maven module in which I grouped test classes based on their package > into different TestNG suite files. The different suite's are listed in the > plugin config using . The tests identified by the suites are > ran sequentially ootb by surefire. With the current version it is already > possible to run the tests within the suites in parallel using multiple > threads (within a single JVM). > However, in my situation I need them to run forked in different JMVs. So what > I want is a JVM fork per suite XML file and not multiple threads. While > there are also fork options, they don't seem to work in combination with > suite XML files (but rather with methods and or test classes). > So, what I'm after is an option that creates a pool of forked JVM's which > takes care of running the available suite XML files. For ex. > "suites 8". Each fork will then execute it's > test (as identified by the suite XML file) in sequence. So for example, in > the config given above, there will be 8 forked JVM's. When I have 10 suite > XML files, each JVM will start working on the tests identified by its > assigned suite XML. So, JVM1 will run all tests (sequentially) identified by > suite XML1. In parallel, JVM2-8 will do the same thing for their assigned > suite XML. From the moment a forked JVM is done processing its suite XML file > it will start on the next one until they are all processed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MNG-5986) XML validators flag errors on poms that declare plugin configurations using the 'combine.self' attribute because the maven-4.0.0 XSD does not declare this attribute.
[
https://issues.apache.org/jira/browse/MNG-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold reassigned MNG-5986:
--
Assignee: Elliotte Rusty Harold
> XML validators flag errors on poms that declare plugin configurations using
> the 'combine.self' attribute because the maven-4.0.0 XSD does not declare
> this attribute.
> -
>
> Key: MNG-5986
> URL: https://issues.apache.org/jira/browse/MNG-5986
> Project: Maven
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.3.3
> Environment: All
>Reporter: Ben Tels
>Assignee: Elliotte Rusty Harold
>Priority: Minor
>
> Maven recognizes an attribute 'combine.self' on the 'configuration' element
> within plugin declarations within a POM ('configuration' elements within and
> outside 'execution' elements). However, an XML validator flags use of this
> attribute as an error. Which is correct, because published XSD
> http://maven.apache.org/xsd/maven-4.0.0.xsd does not declare 'combine.self'
> as an attribute of 'configuration'.
> Current declaration of the configuration element:
>
>
> 4.0.0
> The configuration of the
> reporting plugin.
>
>
>
> processContents="skip"/>
>
>
>
> Simple fix:
>
>
> 0.0.0+
>
>
>
> processContents="skip"/>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHARED-431) # (Hash-Sign) should trigger quoting in BourneShell.java
[ https://issues.apache.org/jira/browse/MSHARED-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000168#comment-17000168 ] Elliotte Rusty Harold commented on MSHARED-431: --- should be easy > # (Hash-Sign) should trigger quoting in BourneShell.java > > > Key: MSHARED-431 > URL: https://issues.apache.org/jira/browse/MSHARED-431 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-shared-utils >Affects Versions: maven-shared-utils-0.8 > Environment: Unix (Linux) >Reporter: Fritz Elfert >Priority: Major > > When trying to use the latest maven-jarsign-plugin using a keystore-password > which started with a hash (#), signing failed. After enabling debug output > with -X, I got a strange debug message: > [DEBUG] Option lacks argument > Since signtool is invoked using /bin/sh -c ..., of course, any # must be > quoted, because otherwise it acts as a comment-start and thus effectively > cuts-off the rest of the cmdline. > After single-quoting the password in the pom.xml, the jar signing was ok. > => > Adding '#' to BASH_QUOTING_TRIGGER_CHARS in > org.apache.maven.shared.utils.cli.shell.BourneShell.java should fix the > problem. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MCHANGES-227) Add document properties to the velocity context
[ https://issues.apache.org/jira/browse/MCHANGES-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MCHANGES-227: --- Priority: Minor (was: Major) > Add document properties to the velocity context > --- > > Key: MCHANGES-227 > URL: https://issues.apache.org/jira/browse/MCHANGES-227 > Project: Maven Changes Plugin > Issue Type: New Feature > Components: announcement >Affects Versions: 2.4 >Reporter: Sebb >Priority: Minor > > The plugin currently makes almost all of the changes.xml content available to > custom templates. > However the document properties are not currently made available as far as I > can tell. > It would sometimes be useful to be able to pass in variable content from > changes.xml, rather than from announceParameters in the POM. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MNG-2316) Add info to the poms for dependencies that implement an API or provide other dependencies
[
https://issues.apache.org/jira/browse/MNG-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MNG-2316.
--
> Add info to the poms for dependencies that implement an API or provide other
> dependencies
> -
>
> Key: MNG-2316
> URL: https://issues.apache.org/jira/browse/MNG-2316
> Project: Maven
> Issue Type: New Feature
> Components: Dependencies
>Affects Versions: 2.0.4
>Reporter: Carlos Sanchez Gonzalez
>Priority: Critical
> Fix For: Issues to be reviewed for 4.x
>
>
> e.g.
> geronimo implementation of javamail could say
> {code:xml}
>
> javax.mail
> mail
> ...
>
> {code}
> spring.jar pom could say
> {code:xml}
>
> org.springframework
> spring-webmvc
> ...
>
>
> org.springframework
> spring-context
> ...
>
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MNG-2316) Add info to the poms for dependencies that implement an API or provide other dependencies
[
https://issues.apache.org/jira/browse/MNG-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MNG-2316.
Resolution: Won't Do
> Add info to the poms for dependencies that implement an API or provide other
> dependencies
> -
>
> Key: MNG-2316
> URL: https://issues.apache.org/jira/browse/MNG-2316
> Project: Maven
> Issue Type: New Feature
> Components: Dependencies
>Affects Versions: 2.0.4
>Reporter: Carlos Sanchez Gonzalez
>Priority: Critical
> Fix For: Issues to be reviewed for 4.x
>
>
> e.g.
> geronimo implementation of javamail could say
> {code:xml}
>
> javax.mail
> mail
> ...
>
> {code}
> spring.jar pom could say
> {code:xml}
>
> org.springframework
> spring-webmvc
> ...
>
>
> org.springframework
> spring-context
> ...
>
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SUREFIRE-530) Allow runtime ordering of tests to be specified
[ https://issues.apache.org/jira/browse/SUREFIRE-530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved SUREFIRE-530. Resolution: Abandoned doesn't look likely to happen > Allow runtime ordering of tests to be specified > --- > > Key: SUREFIRE-530 > URL: https://issues.apache.org/jira/browse/SUREFIRE-530 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Affects Versions: 2.4.3 > Environment: testNG, Junit >Reporter: Nick Pellow >Priority: Major > Fix For: 3.0 > > > Allow other plugins to specify tests to get run, and preserve the ordering of > tests. > Currently, a plugin may set the "test" parameter with a comma separated list > of tests to run. > However, the order is not preserved. > For plugins such as the maven-clover2-plugin, (possibly the > maven-reactor-plugin?) that optimize the build/test run, ordering of a tests > is a very nice way to ensure the build fails as fast as possible. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SUREFIRE-530) Allow runtime ordering of tests to be specified
[ https://issues.apache.org/jira/browse/SUREFIRE-530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed SUREFIRE-530. -- > Allow runtime ordering of tests to be specified > --- > > Key: SUREFIRE-530 > URL: https://issues.apache.org/jira/browse/SUREFIRE-530 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Affects Versions: 2.4.3 > Environment: testNG, Junit >Reporter: Nick Pellow >Priority: Major > Fix For: 3.0 > > > Allow other plugins to specify tests to get run, and preserve the ordering of > tests. > Currently, a plugin may set the "test" parameter with a comma separated list > of tests to run. > However, the order is not preserved. > For plugins such as the maven-clover2-plugin, (possibly the > maven-reactor-plugin?) that optimize the build/test run, ordering of a tests > is a very nice way to ensure the build fails as fast as possible. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCHANGES-357) Cannot include Unresolved issues
[ https://issues.apache.org/jira/browse/MCHANGES-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000256#comment-17000256 ] Elliotte Rusty Harold commented on MCHANGES-357: Patch does not include tests > Cannot include Unresolved issues > > > Key: MCHANGES-357 > URL: https://issues.apache.org/jira/browse/MCHANGES-357 > Project: Maven Changes Plugin > Issue Type: Bug > Components: jira >Affects Versions: 2.11 > Environment: Jira 5.2.11 >Reporter: Franck Malartic >Priority: Major > Attachments: RestJiraDownloader.java.patch > > > Using the jira-report goal, it is impossible to get Unresolved issues. > Unresolved is not managed by Jira server like other resolution statuses. The > REST API does not return the Unresolved status thus the plugin throws the > following exception: > org.apache.maven.plugin.MojoFailureException: Could not find resolution > Unresolved. > at > org.apache.maven.plugin.jira.RestJiraDownloader.resolveOneItem(RestJiraDownloader.java:265) > at > org.apache.maven.plugin.jira.RestJiraDownloader.resolveList(RestJiraDownloader.java:246) > at > org.apache.maven.plugin.jira.RestJiraDownloader.resolveIds(RestJiraDownloader.java:212) > at > org.apache.maven.plugin.jira.RestJiraDownloader.doExecute(RestJiraDownloader.java:131) > at > org.apache.maven.plugin.jira.AdaptiveJiraDownloader.doExecute(AdaptiveJiraDownloader.java:47) > at > org.apache.maven.plugin.jira.JiraMojo.executeReport(JiraMojo.java:372) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:255) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:210) > at > org.apache.maven.plugin.changes.AbstractChangesReport.execute(AbstractChangesReport.java:207) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76) > at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:157) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > at org.codehaus.classworlds.Launcher.main(Launcher.java:46) > Note that you won't have the same error with the > https://issues.apache.org/jira/ server, because the Unresolved status is > "redefined" (id 9) > https://issues.apache.org/jira/rest/api/2/resolution/ > This is explicitly not recommended in Jira documentation: > https://confluence.atlassian.com/display/JIRA/Defining+Resolution+Field+Values > The redefinition of Unresolved shall lead to incorrect Jira status report. > JQL with id="Unresolved" is correct: > https://issues.apache.org/jira/browse/MCHANGES-240?jql=project%20%3D%20MCHANGES%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC > but with id=9 it is not (result is empty): > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MCHANGES%20AND%20resolution%20%3D%209%20ORDER%20BY%20priority%20DESC > And in that case, setting configuration resolutionIds to Unresolved will lead > to the second sample query. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5818) Disallow plugins from programmatically adding dependencies to projects
[ https://issues.apache.org/jira/browse/MNG-5818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000261#comment-17000261 ] Elliotte Rusty Harold commented on MNG-5818: This loos done? > Disallow plugins from programmatically adding dependencies to projects > -- > > Key: MNG-5818 > URL: https://issues.apache.org/jira/browse/MNG-5818 > Project: Maven > Issue Type: Task >Reporter: Jason van Zyl >Assignee: Jason van Zyl >Priority: Major > > MavenProject.setDependencyArtifacts(deps) is publicly available to plugins > that can alter the classpath non-declaratively. For compatibility reasons in > MNG-4363 we restored this capability for the cobertura-maven-plugin but it > needs to be removed. It causes some nasty logic in the core, but it being > non-delclarative and magical is the real problem. > We need to deprecate MavenProject.setDependencyArtifacts(deps), and replace > the logic for constructing the artifacts in a better. Preferably passing in > the artifacts in the constructor of MavenProject. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MDEP-519) Dependency tree with description of each artefacts
[ https://issues.apache.org/jira/browse/MDEP-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MDEP-519. -- > Dependency tree with description of each artefacts > -- > > Key: MDEP-519 > URL: https://issues.apache.org/jira/browse/MDEP-519 > Project: Maven Dependency Plugin > Issue Type: Improvement > Components: tree >Affects Versions: 2.10 >Reporter: Eric Reboisson >Priority: Major > Labels: newbie > > Hello, > I would like to generate a maven dependency tree with a description of each > artefacts. > For instance, in my dependencies, due to transitive dependency antlr is in my > libs, but (even if I know what is this librairies) I would like to generate a > kind of documentation. > If I take the example of antlr artefact I would like something like this : | > | | +- antlr:antlr:jar:2.7.7:compile "A framework for constructing > recognizers, compilers, and translators from grammatical descriptions > containing Java, C#, C++, or Python actions." > > The description is coming from > central.maven.org/maven2/antlr/antlr/2.7.7/antlr-2.7.7.pom -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MDEP-515) Unpack does not work on Linux
[
https://issues.apache.org/jira/browse/MDEP-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MDEP-515.
Resolution: Invalid
> Unpack does not work on Linux
> -
>
> Key: MDEP-515
> URL: https://issues.apache.org/jira/browse/MDEP-515
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: unpack
>Affects Versions: 2.8, 2.10
>Reporter: Karl Heinz Marbaise
>Priority: Major
>
> I had the following plugin configuration for maven-dependency-plugin:
> {code:xml}
>
> org.apache.maven.plugins
> maven-dependency-plugin
>
>
> unpack-content
> generate-sources
>
> unpack
>
>
>
>
> groupId
> artifactId
> ${project.version}
> war
> true
>
> ${project.build.directory}/../src/main/webapp
> WEB-INF/*.xml
>
>
>
>
>
>
> {code}
> Linux Debug output:
> {code}
> [DEBUG] -- end configuration --
> [INFO] Configured Artifact: groupId:artifactId:1.2.3-SNAPSHOT:war
> [INFO] Unpacking /home/jenkins/workspace/BUILD/module/webgui.war to
> /home/jenkins/workspace/BUILD/other-module/target/../src/main/webapp with
> includes "WEB-INF/*.xml" and excludes ""
> [DEBUG] Found unArchiver by type:
> org.codehaus.plexus.archiver.zip.ZipUnArchiver$__plexus2@37a65ac9
> [DEBUG] Expanding: /home/jenkins/workspace/BUILD/module/webgui.war into null
> [DEBUG] expand complete
> {code}
> Windows Debug output:
> {code}
> [DEBUG] -- end configuration --
> [INFO] Configured Artifact: groupId:artifactId:1.2.3-SNAPSHOT:war
> [INFO] Unpacking C:\ws\BUILD\module\webgui.war to
> C:\ws\BUILD\other-module\target\..\src\main\webapp with includes
> "WEB-INF/*.xml" and excludes ""
> [DEBUG] Found unArchiver by type:
> org.codehaus.plexus.archiver.zip.ZipUnArchiver$__plexus2@7d6c3feb
> [DEBUG] Expanding: C:\ws\BUILD\module\webgui.war into
> C:\ws\BUILD\other-module\target\..\src\main\webapp
> [DEBUG] expand complete
> [INFO]
> {code}
> Apart from the configuration which should be done differently, for example
> using different phase like {{prepare-package}} and of course differerent
> {{outputDirectory}} like {{$\{project.build.outputDirectory\}}} it should
> work which is not the case.
> The problem seemed to be related based on the markersDirectory which is used
> by maven-dependency-plugin which looks like it is not created during the
> running of maven-dependency-plugin which seemed to be related to the early
> life cycle phase.
> I have changed the binding to a later life cycle phase which means the
> {{target/classes}} folder will be created by previous phases.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MDEP-510) copy-dependencies + copyPom + useRepositoryLayout skips existing artifacts
[ https://issues.apache.org/jira/browse/MDEP-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MDEP-510: --- Priority: Minor (was: Major) > copy-dependencies + copyPom + useRepositoryLayout skips existing artifacts > -- > > Key: MDEP-510 > URL: https://issues.apache.org/jira/browse/MDEP-510 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: copy-dependencies >Affects Versions: 2.10 > Environment: Debian Jessie >Reporter: Alexander Knaust >Priority: Minor > > copy-dependencies using copyPom with useRepositoryLayout will skip copying > poms to artifact directories that already exist. This doesn't seem to happen > without useRepositoryLayout > Here is a link to a bash script demonstrating the bug. It clones apache > commons-math, and then copies its dependencies with useRepositoryLayout. It > then goes back and does it with copyPom=true, but the pom files do not get > copied. > +This can be overcome by setting -DoverWriteReleases=true+ > https://gist.github.com/olemma/2a344a5748befcb7acce -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MDEP-515) Unpack does not work on Linux
[
https://issues.apache.org/jira/browse/MDEP-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MDEP-515.
--
> Unpack does not work on Linux
> -
>
> Key: MDEP-515
> URL: https://issues.apache.org/jira/browse/MDEP-515
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: unpack
>Affects Versions: 2.8, 2.10
>Reporter: Karl Heinz Marbaise
>Priority: Major
>
> I had the following plugin configuration for maven-dependency-plugin:
> {code:xml}
>
> org.apache.maven.plugins
> maven-dependency-plugin
>
>
> unpack-content
> generate-sources
>
> unpack
>
>
>
>
> groupId
> artifactId
> ${project.version}
> war
> true
>
> ${project.build.directory}/../src/main/webapp
> WEB-INF/*.xml
>
>
>
>
>
>
> {code}
> Linux Debug output:
> {code}
> [DEBUG] -- end configuration --
> [INFO] Configured Artifact: groupId:artifactId:1.2.3-SNAPSHOT:war
> [INFO] Unpacking /home/jenkins/workspace/BUILD/module/webgui.war to
> /home/jenkins/workspace/BUILD/other-module/target/../src/main/webapp with
> includes "WEB-INF/*.xml" and excludes ""
> [DEBUG] Found unArchiver by type:
> org.codehaus.plexus.archiver.zip.ZipUnArchiver$__plexus2@37a65ac9
> [DEBUG] Expanding: /home/jenkins/workspace/BUILD/module/webgui.war into null
> [DEBUG] expand complete
> {code}
> Windows Debug output:
> {code}
> [DEBUG] -- end configuration --
> [INFO] Configured Artifact: groupId:artifactId:1.2.3-SNAPSHOT:war
> [INFO] Unpacking C:\ws\BUILD\module\webgui.war to
> C:\ws\BUILD\other-module\target\..\src\main\webapp with includes
> "WEB-INF/*.xml" and excludes ""
> [DEBUG] Found unArchiver by type:
> org.codehaus.plexus.archiver.zip.ZipUnArchiver$__plexus2@7d6c3feb
> [DEBUG] Expanding: C:\ws\BUILD\module\webgui.war into
> C:\ws\BUILD\other-module\target\..\src\main\webapp
> [DEBUG] expand complete
> [INFO]
> {code}
> Apart from the configuration which should be done differently, for example
> using different phase like {{prepare-package}} and of course differerent
> {{outputDirectory}} like {{$\{project.build.outputDirectory\}}} it should
> work which is not the case.
> The problem seemed to be related based on the markersDirectory which is used
> by maven-dependency-plugin which looks like it is not created during the
> running of maven-dependency-plugin which seemed to be related to the early
> life cycle phase.
> I have changed the binding to a later life cycle phase which means the
> {{target/classes}} folder will be created by previous phases.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MDEP-431) new options to control output from dependency:analyze(-only)
[ https://issues.apache.org/jira/browse/MDEP-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MDEP-431: --- Priority: Minor (was: Major) > new options to control output from dependency:analyze(-only) > > > Key: MDEP-431 > URL: https://issues.apache.org/jira/browse/MDEP-431 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: analyze >Affects Versions: 2.8 >Reporter: Robert Platt >Priority: Minor > Attachments: mdep.patch > > > Including dependency:analyze-only with failOnWarning into a build can be very > effective at catching dependency issues. However, it is pretty much > all-or-nothing at the moment. In the case of complex or legacy projects it > can be difficult to incorporate the plugin into the build. > This is a patch (see attached mdep.path) to version 2.8 to provide more > control over dependency analysis output, introducing three new configuration > options. In all cases, the default options provide the current plugin > behavior: > 1. warnUnusedDeclared (default true). Unused declared dependencies generate > a warning if this is true, otherwise it is just info. > 2. ignoreManagedUndeclared (default false). If true, then used undeclared > dependencies which are dependency managed are not reported in the warnings. > The reasoning behind this option is that used undeclared dependencies are > less likely to break a build in subtle ways if they are dependency managed, > since the version will not change without developer intervention. Turning > this option on focuses the analysis on compiling against unmanaged transitive > dependencies. > 3. preferManagedVersionOutput (default false). If true, when outputting XML, > versions are left unspecified for managed dependencies. This can be handy > when you aren't using ignoreManagedUndeclared but want to use managed > versions when fixing undeclared dependencies. > Finally, the wording for the output of unused declared dependencies has been > changed to 'Potentially unused declared dependencies found' because, as > documented, their are limitations to this detection process with the default > analyzer. This wording makes it clearer to developers without that working > knowledge. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MDEP-431) new options to control output from dependency:analyze(-only)
[ https://issues.apache.org/jira/browse/MDEP-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MDEP-431: --- Issue Type: New Feature (was: Improvement) > new options to control output from dependency:analyze(-only) > > > Key: MDEP-431 > URL: https://issues.apache.org/jira/browse/MDEP-431 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: analyze >Affects Versions: 2.8 >Reporter: Robert Platt >Priority: Major > Attachments: mdep.patch > > > Including dependency:analyze-only with failOnWarning into a build can be very > effective at catching dependency issues. However, it is pretty much > all-or-nothing at the moment. In the case of complex or legacy projects it > can be difficult to incorporate the plugin into the build. > This is a patch (see attached mdep.path) to version 2.8 to provide more > control over dependency analysis output, introducing three new configuration > options. In all cases, the default options provide the current plugin > behavior: > 1. warnUnusedDeclared (default true). Unused declared dependencies generate > a warning if this is true, otherwise it is just info. > 2. ignoreManagedUndeclared (default false). If true, then used undeclared > dependencies which are dependency managed are not reported in the warnings. > The reasoning behind this option is that used undeclared dependencies are > less likely to break a build in subtle ways if they are dependency managed, > since the version will not change without developer intervention. Turning > this option on focuses the analysis on compiling against unmanaged transitive > dependencies. > 3. preferManagedVersionOutput (default false). If true, when outputting XML, > versions are left unspecified for managed dependencies. This can be handy > when you aren't using ignoreManagedUndeclared but want to use managed > versions when fixing undeclared dependencies. > Finally, the wording for the output of unused declared dependencies has been > changed to 'Potentially unused declared dependencies found' because, as > documented, their are limitations to this detection process with the default > analyzer. This wording makes it clearer to developers without that working > knowledge. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MSCMPUB-27) Make it possible to publish only subfolders in a targeting site repository
[
https://issues.apache.org/jira/browse/MSCMPUB-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MSCMPUB-27:
-
Issue Type: New Feature (was: Improvement)
> Make it possible to publish only subfolders in a targeting site repository
> --
>
> Key: MSCMPUB-27
> URL: https://issues.apache.org/jira/browse/MSCMPUB-27
> Project: Maven SCM Publish Plugin
> Issue Type: New Feature
>Reporter: Karl Heinz Marbaise
>Priority: Major
>
> Scenario: Having a single git repo which contains the site for a multi
> component project where each component site should be published at a
> different time point.
> {code}
> /
> .. index.html...
> +--- M1
> +--- M2
> +
> {code}
> I can configure to ignore paths like {{M1,M2}} but I can't configure to use a
> target path while the content is being copied into the target site git repos
> to say that only the current content will be copied into {{M1}} and this is
> the only part which is handle with updates/changes/deletes.
> The root path can be handled by using the {{ignorePathsToDelete}}
> configuration but in the sub modules like M1 and M2 it is not possible to
> configure scm-publish in a way to handle only a sub folder.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MRELEASE-962) A way for other plugins to hook into the release and add files to SCM
[ https://issues.apache.org/jira/browse/MRELEASE-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MRELEASE-962. Resolution: Won't Fix generated files don't belong in repos > A way for other plugins to hook into the release and add files to SCM > - > > Key: MRELEASE-962 > URL: https://issues.apache.org/jira/browse/MRELEASE-962 > Project: Maven Release Plugin > Issue Type: Wish > Components: prepare >Reporter: Kasper Sørensen >Priority: Major > > Hi Maven Release community, > I am working on a plugin for driving dotnet (.NET core) builds via Maven [1]. > One particularly annoying thing with such projects is that project versions > have to be sync'ed manually, while I would like it to be something that is > governed by Maven so that if the pom.xml file specifies a version, then that > is propagated also to the project.json files of a dotnet build/release. My > plugin now has a goal for doing this (dotnet:update-versions) but I cannot > hook that into the release process so that the outcome of this step (the > changed project.json files) are added to the commits made by the release > plugin. I have looked around in your source code and cannot find any way of > doing it, and I also see that the release plugin explicitly only adds pom.xml > files to the commit. Having a way to add other files would be great. > [1] https://github.com/kaspersorensen/dotnet-maven-plugin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MRELEASE-962) A way for other plugins to hook into the release and add files to SCM
[ https://issues.apache.org/jira/browse/MRELEASE-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MRELEASE-962. -- > A way for other plugins to hook into the release and add files to SCM > - > > Key: MRELEASE-962 > URL: https://issues.apache.org/jira/browse/MRELEASE-962 > Project: Maven Release Plugin > Issue Type: Wish > Components: prepare >Reporter: Kasper Sørensen >Priority: Major > > Hi Maven Release community, > I am working on a plugin for driving dotnet (.NET core) builds via Maven [1]. > One particularly annoying thing with such projects is that project versions > have to be sync'ed manually, while I would like it to be something that is > governed by Maven so that if the pom.xml file specifies a version, then that > is propagated also to the project.json files of a dotnet build/release. My > plugin now has a goal for doing this (dotnet:update-versions) but I cannot > hook that into the release process so that the outcome of this step (the > changed project.json files) are added to the commits made by the release > plugin. I have looked around in your source code and cannot find any way of > doing it, and I also see that the release plugin explicitly only adds pom.xml > files to the commit. Having a way to add other files would be great. > [1] https://github.com/kaspersorensen/dotnet-maven-plugin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MSHARED-514) if filter file does not exist it should optionally ignore it, not just throw an exception
[
https://issues.apache.org/jira/browse/MSHARED-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MSHARED-514.
-
> if filter file does not exist it should optionally ignore it, not just throw
> an exception
> -
>
> Key: MSHARED-514
> URL: https://issues.apache.org/jira/browse/MSHARED-514
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-filtering
>Affects Versions: maven-filtering-3.1.0
>Reporter: richard stevenson
>Assignee: Olivier Lamy
>Priority: Minor
> Attachments: maven-filter.patch
>
>
> If you have a list of filter files
>
> a.properties
> b.properties
> ${prop.name}.properties
>
> It would be nice to tell the resources plugin to optioanlly ignore a file if
> it does not exist. Currently get the following stack trace:
> org.apache.maven.lifecycle.LifecycleExecutionException: Error loading
> property f
> ile 'D:\projects\.../src/main/filters/a.filter.properties'
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> ultLifecycleExecutor.java:719)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
> fecycle(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
> ltLifecycleExecutor.java:535)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
> dleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
> ts(DefaultLifecycleExecutor.java:348)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
> fecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:6
> 0)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error loading
> propert
> y file 'D:\projects\.../src/main/filters/a.filter.properties'
> at
> org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo
> .java:269)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
> nManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> ultLifecycleExecutor.java:694)
> ... 17 more
> Caused by: org.apache.maven.shared.filtering.MavenFilteringException: Error
> load
> ing property file 'D:\projects\.../src/main/filters/a.properties'
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.loadProperti
> es(DefaultMavenFileFilter.java:274)
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.getDefaultFi
> lterWrappers(DefaultMavenFileFilter.java:199)
> at
> org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filt
> erResources(DefaultMavenResourcesFiltering.java:162)
> at
> org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo
> .java:265)
> ... 19 more
> Caused by: java.io.FileNotFoundException:
> D:\projects\.../src/main/filters/a.fil
> ter.properties
> at
> org.apache.maven.shared.filtering.PropertyUtils.loadPropertyFile(Prop
> ertyUtils.java:65)
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.loadProperti
> es(DefaultMavenFileFilter.java:269)
> ... 22 more
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MSHARED-514) if filter file does not exist it should optionally ignore it, not just throw an exception
[
https://issues.apache.org/jira/browse/MSHARED-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MSHARED-514.
---
Resolution: Fixed
Since there's no activity here and this issue is scheduled for autoclosure
anyway, I'm going to make an opinionated call that we shouldn't fix this. The
current behavior is reasonable, and we have too many options to document and
support already.
> if filter file does not exist it should optionally ignore it, not just throw
> an exception
> -
>
> Key: MSHARED-514
> URL: https://issues.apache.org/jira/browse/MSHARED-514
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-filtering
>Affects Versions: maven-filtering-3.1.0
>Reporter: richard stevenson
>Assignee: Olivier Lamy
>Priority: Minor
> Attachments: maven-filter.patch
>
>
> If you have a list of filter files
>
> a.properties
> b.properties
> ${prop.name}.properties
>
> It would be nice to tell the resources plugin to optioanlly ignore a file if
> it does not exist. Currently get the following stack trace:
> org.apache.maven.lifecycle.LifecycleExecutionException: Error loading
> property f
> ile 'D:\projects\.../src/main/filters/a.filter.properties'
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> ultLifecycleExecutor.java:719)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
> fecycle(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
> ltLifecycleExecutor.java:535)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
> dleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
> ts(DefaultLifecycleExecutor.java:348)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
> fecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:6
> 0)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error loading
> propert
> y file 'D:\projects\.../src/main/filters/a.filter.properties'
> at
> org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo
> .java:269)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
> nManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> ultLifecycleExecutor.java:694)
> ... 17 more
> Caused by: org.apache.maven.shared.filtering.MavenFilteringException: Error
> load
> ing property file 'D:\projects\.../src/main/filters/a.properties'
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.loadProperti
> es(DefaultMavenFileFilter.java:274)
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.getDefaultFi
> lterWrappers(DefaultMavenFileFilter.java:199)
> at
> org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filt
> erResources(DefaultMavenResourcesFiltering.java:162)
> at
> org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo
> .java:265)
> ... 19 more
> Caused by: java.io.FileNotFoundException:
> D:\projects\.../src/main/filters/a.fil
> ter.properties
> at
> org.apache.maven.shared.filtering.PropertyUtils.loadPropertyFile(Prop
> ertyUtils.java:65)
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.loadProperti
> es(DefaultMavenFileFilter.java:269)
> ... 22 more
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MDEP-488) Build-classpath for maven repository layout
[
https://issues.apache.org/jira/browse/MDEP-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MDEP-488:
---
Issue Type: Bug (was: Improvement)
> Build-classpath for maven repository layout
> ---
>
> Key: MDEP-488
> URL: https://issues.apache.org/jira/browse/MDEP-488
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: build-classpath
>Affects Versions: 2.10
>Reporter: Gaël Lalire
>Priority: Major
> Attachments: classpathPatch.diff
>
>
> Build-classpath cannot create a classpath for a maven repository layout in
> multimodules projects.
> Indeed project.artifacts returns artifacts whose file may be from the local
> repository or from your project target directories.
> For last one the replace mechanism failed.
> We could execute the build-classpath with invoker plugin as a workaround but
> it is not clean.
> I propose to make it possible with following configuration {code}
>
> ${project.build.directory}/unix-classpath.txt
> :
> /
> repository
> true
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MDEP-488) Build-classpath for maven repository layout
[
https://issues.apache.org/jira/browse/MDEP-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MDEP-488:
---
Priority: Minor (was: Major)
> Build-classpath for maven repository layout
> ---
>
> Key: MDEP-488
> URL: https://issues.apache.org/jira/browse/MDEP-488
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: build-classpath
>Affects Versions: 2.10
>Reporter: Gaël Lalire
>Priority: Minor
> Attachments: classpathPatch.diff
>
>
> Build-classpath cannot create a classpath for a maven repository layout in
> multimodules projects.
> Indeed project.artifacts returns artifacts whose file may be from the local
> repository or from your project target directories.
> For last one the replace mechanism failed.
> We could execute the build-classpath with invoker plugin as a workaround but
> it is not clean.
> I propose to make it possible with following configuration {code}
>
> ${project.build.directory}/unix-classpath.txt
> :
> /
> repository
> true
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARCHETYPE-511) DefaultArchetypeManager.getRemoteCatalog() swallows exceptions
[ https://issues.apache.org/jira/browse/ARCHETYPE-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated ARCHETYPE-511: Issue Type: Bug (was: Improvement) > DefaultArchetypeManager.getRemoteCatalog() swallows exceptions > -- > > Key: ARCHETYPE-511 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-511 > Project: Maven Archetype > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Konrad Windszus >Priority: Major > > In case a remote catalog cannot be retrieved for some reason, just an empty > catalog is being returned. Instead a proper exception (probably > ArchetypeDataSourceException) should be thrown to ease tracing the error in > the configuration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MSHARED-581) Filtered resource copyFiles fails on pre-existing symlink
[
https://issues.apache.org/jira/browse/MSHARED-581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MSHARED-581.
---
Resolution: Won't Fix
symlinks are painful at best, even more so in Java. I strongly recommend not
using symlinks in your build. Atm we have no resources to contribute to this.
> Filtered resource copyFiles fails on pre-existing symlink
> -
>
> Key: MSHARED-581
> URL: https://issues.apache.org/jira/browse/MSHARED-581
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-shared-utils
>Affects Versions: maven-shared-utils-3.0.0, maven-filtering-3.1.1
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: /usr/local/Cellar/maven/3.3.9/libexec
> Java version: 1.8.0_77, vendor: Oracle Corporation
> Java home: /Users/steven/.jabba/jdk/1.8.77/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.11.6", arch: "x86_64", family: "mac"
>Reporter: Steven Schlansker
>Priority: Major
>
> I have a file shared between multiple projects via symlink:
> {code}
> -rw-r--r-- 1 steven staff 149 Mar 30 16:56
> client/src/test/resources/simplelogger.properties
> lrwxr-xr-x 1 steven staff 64 Oct 16 2014
> integration-tests/jersey-client/src/test/resources/simplelogger.properties ->
> ../../../../../client/src/test/resources/simplelogger.properties
> lrwxr-xr-x 1 steven staff 64 Oct 16 2014
> integration-tests/resteasy-client/src/test/resources/simplelogger.properties
> -> ../../../../../client/src/test/resources/simplelogger.properties
> {code}
> This works fine from a clean build, but on an incremental build, it fails:
> {code}
> Caused by: org.apache.maven.plugin.MojoExecutionException:
> /Users/steven/ot-code/service-discovery/integration-tests/jersey-client/target/test-classes/simplelogger.properties
> at
> org.apache.maven.plugins.resources.ResourcesMojo.execute(ResourcesMojo.java:348)
> at
> org.apache.maven.plugins.resources.TestResourcesMojo.execute(TestResourcesMojo.java:75)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> ... 20 more
> Caused by: org.apache.maven.shared.filtering.MavenFilteringException:
> /Users/steven/ot-code/service-discovery/integration-tests/jersey-client/target/test-classes/simplelogger.properties
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:128)
> at
> org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources(DefaultMavenResourcesFiltering.java:232)
> at
> org.apache.maven.plugins.resources.ResourcesMojo.execute(ResourcesMojo.java:342)
> ... 23 more
> Caused by: java.nio.file.FileAlreadyExistsException:
> /Users/steven/ot-code/service-discovery/integration-tests/jersey-client/target/test-classes/simplelogger.properties
> at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:88)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at
> sun.nio.fs.UnixFileSystemProvider.createSymbolicLink(UnixFileSystemProvider.java:457)
> at java.nio.file.Files.createSymbolicLink(Files.java:1043)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.maven.shared.utils.io.Java7Support.createSymbolicLink(Java7Support.java:176)
> at
> org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:821)
> at
> org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:1939)
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:121)
> ... 25 more
> {code}
> Perhaps {{FileUtils.copyFile}} should not attempt to copy over an existing
> symlink? It should leave it be if the target is the same, otherwise unlink
> it first.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SUREFIRE-1288) systemProperties should not be deprecated
[ https://issues.apache.org/jira/browse/SUREFIRE-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved SUREFIRE-1288. - Resolution: Won't Fix > systemProperties should not be deprecated > -- > > Key: SUREFIRE-1288 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1288 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.19.1 >Reporter: Michal Domagala >Priority: Major > Fix For: Backlog > > > Current property precedence is: (higher number=more important) > 1. systemProperties > 2. systemPropertiesFile > 3. systemPropertyVariables > systemPropertyVariables is not replacement for systemProperties because > meaning is different. > For me systemProperties are more useful, because I can define default values > in pom.xml and optionally override them in runtime by configuration file. > systemPropertyVariables are not useful because can be overriden only by > command line arguments. Commandline is not friendly if several properties > must be modified -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARCHETYPE-506) archetype:generate if pom.xml packaging value is pom,Chinese XML comments will change to ???
[
https://issues.apache.org/jira/browse/ARCHETYPE-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated ARCHETYPE-506:
Priority: Minor (was: Major)
> archetype:generate if pom.xml packaging value is pom,Chinese XML comments
> will change to ???
> --
>
> Key: ARCHETYPE-506
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-506
> Project: Maven Archetype
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: feilong
>Priority: Minor
>
> {{archetype:generate}} if pom.xml {{packaging}} value is pom,Chinese XML
> comments will change to {{???}}
> here is
> {code:xml}
>
>
> true
> org.apache.maven.plugins
> maven-surefire-plugin
> ${v.maven-surefire-plugin}
>
>
> true
>
>
> {code}
> if {{pom}}
> when i call mvn {{archetype:generate}}
> result is
> {code:xml}
>
>
> true
> org.apache.maven.plugins
> maven-surefire-plugin
> ${v.maven-surefire-plugin}
>
>
> true
>
>
> {code}
> but when {{war}}, result is ok
> And in
> http://maven.apache.org/archetype/maven-archetype-plugin/generate-mojo.html,
> I can't find any {{encode}} or {{charset}} param to set
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MCHANGES-374) Allow OAuth authentication in Jira
[ https://issues.apache.org/jira/browse/MCHANGES-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000147#comment-17000147 ] Elliotte Rusty Harold commented on MCHANGES-374: makes sense > Allow OAuth authentication in Jira > -- > > Key: MCHANGES-374 > URL: https://issues.apache.org/jira/browse/MCHANGES-374 > Project: Maven Changes Plugin > Issue Type: New Feature > Components: jira >Reporter: Angel Cervera Claudio >Priority: Major > > The only way to access to Jira is using User/Password. > Usually, because security issues, is not an option in big companies so it is > necessary to use other authentication systems, like tokens or OAuth. > Jira implements OAuth, so this would be the best option to avoid hard coded > passwords. > Documentation: > https://developer.atlassian.com/jiradev/jira-apis/jira-rest-apis/jira-rest-api-tutorials/jira-rest-api-example-oauth-authentication -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SUREFIRE-1288) systemProperties should not be deprecated
[ https://issues.apache.org/jira/browse/SUREFIRE-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed SUREFIRE-1288. --- > systemProperties should not be deprecated > -- > > Key: SUREFIRE-1288 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1288 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.19.1 >Reporter: Michal Domagala >Priority: Major > Fix For: Backlog > > > Current property precedence is: (higher number=more important) > 1. systemProperties > 2. systemPropertiesFile > 3. systemPropertyVariables > systemPropertyVariables is not replacement for systemProperties because > meaning is different. > For me systemProperties are more useful, because I can define default values > in pom.xml and optionally override them in runtime by configuration file. > systemPropertyVariables are not useful because can be overriden only by > command line arguments. Commandline is not friendly if several properties > must be modified -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MSHARED-581) Filtered resource copyFiles fails on pre-existing symlink
[
https://issues.apache.org/jira/browse/MSHARED-581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MSHARED-581.
-
> Filtered resource copyFiles fails on pre-existing symlink
> -
>
> Key: MSHARED-581
> URL: https://issues.apache.org/jira/browse/MSHARED-581
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-shared-utils
>Affects Versions: maven-shared-utils-3.0.0, maven-filtering-3.1.1
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: /usr/local/Cellar/maven/3.3.9/libexec
> Java version: 1.8.0_77, vendor: Oracle Corporation
> Java home: /Users/steven/.jabba/jdk/1.8.77/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.11.6", arch: "x86_64", family: "mac"
>Reporter: Steven Schlansker
>Priority: Major
>
> I have a file shared between multiple projects via symlink:
> {code}
> -rw-r--r-- 1 steven staff 149 Mar 30 16:56
> client/src/test/resources/simplelogger.properties
> lrwxr-xr-x 1 steven staff 64 Oct 16 2014
> integration-tests/jersey-client/src/test/resources/simplelogger.properties ->
> ../../../../../client/src/test/resources/simplelogger.properties
> lrwxr-xr-x 1 steven staff 64 Oct 16 2014
> integration-tests/resteasy-client/src/test/resources/simplelogger.properties
> -> ../../../../../client/src/test/resources/simplelogger.properties
> {code}
> This works fine from a clean build, but on an incremental build, it fails:
> {code}
> Caused by: org.apache.maven.plugin.MojoExecutionException:
> /Users/steven/ot-code/service-discovery/integration-tests/jersey-client/target/test-classes/simplelogger.properties
> at
> org.apache.maven.plugins.resources.ResourcesMojo.execute(ResourcesMojo.java:348)
> at
> org.apache.maven.plugins.resources.TestResourcesMojo.execute(TestResourcesMojo.java:75)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> ... 20 more
> Caused by: org.apache.maven.shared.filtering.MavenFilteringException:
> /Users/steven/ot-code/service-discovery/integration-tests/jersey-client/target/test-classes/simplelogger.properties
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:128)
> at
> org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources(DefaultMavenResourcesFiltering.java:232)
> at
> org.apache.maven.plugins.resources.ResourcesMojo.execute(ResourcesMojo.java:342)
> ... 23 more
> Caused by: java.nio.file.FileAlreadyExistsException:
> /Users/steven/ot-code/service-discovery/integration-tests/jersey-client/target/test-classes/simplelogger.properties
> at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:88)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at
> sun.nio.fs.UnixFileSystemProvider.createSymbolicLink(UnixFileSystemProvider.java:457)
> at java.nio.file.Files.createSymbolicLink(Files.java:1043)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.maven.shared.utils.io.Java7Support.createSymbolicLink(Java7Support.java:176)
> at
> org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:821)
> at
> org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:1939)
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:121)
> ... 25 more
> {code}
> Perhaps {{FileUtils.copyFile}} should not attempt to copy over an existing
> symlink? It should leave it be if the target is the same, otherwise unlink
> it first.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-683) Xref link generation regression with Maven 3
[ https://issues.apache.org/jira/browse/SUREFIRE-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000210#comment-17000210 ] Elliotte Rusty Harold commented on SUREFIRE-683: anyone still working on this? > Xref link generation regression with Maven 3 > > > Key: SUREFIRE-683 > URL: https://issues.apache.org/jira/browse/SUREFIRE-683 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Report Plugin >Affects Versions: 2.7.1 > Environment: Apache Maven 3.0.1 (r1038046; 2010-11-23 11:58:32+0100) > Java version: 1.6.0_20 > Java home: /usr/lib/jvm/java-6-openjdk/jre > Default locale: en_GB, platform encoding: UTF-8 > OS name: "linux" version: "2.6.32-27-generic" arch: "i386" Family: "unix" >Reporter: Marc Rohlfs >Priority: Minor > Attachments: SUREFIRE-683_sample.zip > > > When the site reports are created with Maven 3, the this plugin doesn't > generate the links to the Source Xref pages, when the JXR Plugin hasn't been > executed before. > The plugin looks for the xrefLocation directory and if it doesn't exist, it > checks if the JXR plugin is configured for the project (see > http://maven.apache.org/plugins/maven-surefire-report-plugin/xref/org/apache/maven/plugins/surefire/report/SurefireReportMojo.html#203). > To properly generate the Xref links when the report is created with Maven 3, > the plugin should also check the reportPlugins paramerter of the Site plugin > configuration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MCHANGES-216) Alow arbitrary xdoc markup inside action
[ https://issues.apache.org/jira/browse/MCHANGES-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MCHANGES-216. Resolution: Won't Fix > Alow arbitrary xdoc markup inside action > > > Key: MCHANGES-216 > URL: https://issues.apache.org/jira/browse/MCHANGES-216 > Project: Maven Changes Plugin > Issue Type: New Feature > Components: changes.xml >Affects Versions: 2.3 >Reporter: Lukas Theussl >Priority: Major > > In maven 1, the element could contain arbitrary xdoc markup. This > will require a new xsd. See MCHANGES-190. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MCHANGES-216) Alow arbitrary xdoc markup inside action
[ https://issues.apache.org/jira/browse/MCHANGES-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MCHANGES-216. -- > Alow arbitrary xdoc markup inside action > > > Key: MCHANGES-216 > URL: https://issues.apache.org/jira/browse/MCHANGES-216 > Project: Maven Changes Plugin > Issue Type: New Feature > Components: changes.xml >Affects Versions: 2.3 >Reporter: Lukas Theussl >Priority: Major > > In maven 1, the element could contain arbitrary xdoc markup. This > will require a new xsd. See MCHANGES-190. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MCHANGES-85) Create an abstraction layer for issue tracking systems
[ https://issues.apache.org/jira/browse/MCHANGES-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MCHANGES-85. --- Resolution: Won't Do Since there's no activity here and this issue is scheduled for autoclosure anyway, I'm going to make an opinionated call that this isn't important enough for anyone to spend time on. > Create an abstraction layer for issue tracking systems > -- > > Key: MCHANGES-85 > URL: https://issues.apache.org/jira/browse/MCHANGES-85 > Project: Maven Changes Plugin > Issue Type: New Feature > Components: other issue-trackers >Affects Versions: 2.0-beta-2 >Reporter: Dennis Lundberg >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MCHANGES-85) Create an abstraction layer for issue tracking systems
[ https://issues.apache.org/jira/browse/MCHANGES-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MCHANGES-85. - > Create an abstraction layer for issue tracking systems > -- > > Key: MCHANGES-85 > URL: https://issues.apache.org/jira/browse/MCHANGES-85 > Project: Maven Changes Plugin > Issue Type: New Feature > Components: other issue-trackers >Affects Versions: 2.0-beta-2 >Reporter: Dennis Lundberg >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (DOXIA-238) define a Sink Object Model in terms of a XSD
[
https://issues.apache.org/jira/browse/DOXIA-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved DOXIA-238.
-
Resolution: Won't Do
Since there's no activity here and this issue is scheduled for autoclosure
anyway, I'm going to make an opinionated call that this isn't important enough
for anyone to spend time on.
> define a Sink Object Model in terms of a XSD
>
>
> Key: DOXIA-238
> URL: https://issues.apache.org/jira/browse/DOXIA-238
> Project: Maven Doxia
> Issue Type: Wish
> Components: Sink API
>Reporter: Lukas Theussl
>Priority: Major
>
> From DOXIA-236:
> A thought with regard to event order/nesting: What about defining a Sink
> Object Model in terms of a XSD? This tree structure should not be expressed
> by a programmatic API but merely serves as a reference for parser validation.
> I.e. a CanonicalSink would output the XML document
> {code:xml}
>
>
>
> foo
>
>
>
> {code}
> for the event sequence head(), title(), text("foo"), _title(), _head(). This
> tree could then be passed through a validating XML parser (conveniently
> wrapped in a ValidatingSink, superceding the WellformednessCheckingSink) to
> check that the parser obeys the ordering/nesting rules defined by the XSD. Of
> course, the XSD would also serve the purpose of documenting the intended
> usage of the Sink API to implementors.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (DOXIA-238) define a Sink Object Model in terms of a XSD
[
https://issues.apache.org/jira/browse/DOXIA-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed DOXIA-238.
---
> define a Sink Object Model in terms of a XSD
>
>
> Key: DOXIA-238
> URL: https://issues.apache.org/jira/browse/DOXIA-238
> Project: Maven Doxia
> Issue Type: Wish
> Components: Sink API
>Reporter: Lukas Theussl
>Priority: Major
>
> From DOXIA-236:
> A thought with regard to event order/nesting: What about defining a Sink
> Object Model in terms of a XSD? This tree structure should not be expressed
> by a programmatic API but merely serves as a reference for parser validation.
> I.e. a CanonicalSink would output the XML document
> {code:xml}
>
>
>
> foo
>
>
>
> {code}
> for the event sequence head(), title(), text("foo"), _title(), _head(). This
> tree could then be passed through a validating XML parser (conveniently
> wrapped in a ValidatingSink, superceding the WellformednessCheckingSink) to
> check that the parser obeys the ordering/nesting rules defined by the XSD. Of
> course, the XSD would also serve the purpose of documenting the intended
> usage of the Sink API to implementors.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MDEP-234) Make the list and tree mojos support listing transitive dependencies for war artifact types
[
https://issues.apache.org/jira/browse/MDEP-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MDEP-234:
---
Description:
For example, check out
http://svn.xwiki.org/svnroot/xwiki/enterprise/trunk/web/
(note: you'll need to specify the xwiki remote repo in your settings.xml as
mentioned here:
http://dev.xwiki.org/xwiki/bin/view/Community/Building#HInstallingMaven )
When you run "mvn dependency:tree" (or dependency:list) you get:
{noformat}
[INFO] [dependency:tree {execution: default-cli}]
[INFO] com.xpn.xwiki.products:xwiki-enterprise-web:war:2.1-SNAPSHOT
[INFO] +- com.xpn.xwiki.platform:xwiki-web-standard:war:2.1-SNAPSHOT:compile
[INFO] +-
com.xpn.xwiki.platform.plugins:xwiki-plugin-watchlist:jar:1.20-SNAPSHOT:compile
[INFO] +-
com.xpn.xwiki.platform.plugins:xwiki-plugin-jodatime:jar:1.4-SNAPSHOT:compile
...
{noformat}
As you can see the com.xpn.xwiki.platform:xwiki-web-standard:war dependency
doesn't contain any transitive deps but it has several of them
(see http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/standard/pom.xml )
This is probably because the general artifact resolver stops at WAR packaging
types. While this is probably fine when executing a maven project, it isn't
when listing all project dependencies.
Thanks
was:
For example, check out
http://svn.xwiki.org/svnroot/xwiki/enterprise/trunk/web/
(note: you'll need to specify the xwiki remote repo in your settings.xml as
mentioned here:
http://dev.xwiki.org/xwiki/bin/view/Community/Building#HInstallingMaven )
When you runt "mvn dependency:tree" (or dependency:list) you get:
{noformat}
[INFO] [dependency:tree {execution: default-cli}]
[INFO] com.xpn.xwiki.products:xwiki-enterprise-web:war:2.1-SNAPSHOT
[INFO] +- com.xpn.xwiki.platform:xwiki-web-standard:war:2.1-SNAPSHOT:compile
[INFO] +-
com.xpn.xwiki.platform.plugins:xwiki-plugin-watchlist:jar:1.20-SNAPSHOT:compile
[INFO] +-
com.xpn.xwiki.platform.plugins:xwiki-plugin-jodatime:jar:1.4-SNAPSHOT:compile
...
{noformat}
As you can see the com.xpn.xwiki.platform:xwiki-web-standard:war dependency
doesn't contain any transitive deps but it has several of them
(see http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/standard/pom.xml )
This is probably because the general artifact resolver stops at WAR packaging
types. While this is probably fine when executing a maven project, it isn't
when listing all project dependencies.
Thanks
> Make the list and tree mojos support listing transitive dependencies for war
> artifact types
> ---
>
> Key: MDEP-234
> URL: https://issues.apache.org/jira/browse/MDEP-234
> Project: Maven Dependency Plugin
> Issue Type: Improvement
> Components: tree
>Affects Versions: 2.1
>Reporter: Vincent Massol
>Priority: Major
> Attachments: overlay-example-project.zip
>
>
> For example, check out
> http://svn.xwiki.org/svnroot/xwiki/enterprise/trunk/web/
> (note: you'll need to specify the xwiki remote repo in your settings.xml as
> mentioned here:
> http://dev.xwiki.org/xwiki/bin/view/Community/Building#HInstallingMaven )
> When you run "mvn dependency:tree" (or dependency:list) you get:
> {noformat}
> [INFO] [dependency:tree {execution: default-cli}]
> [INFO] com.xpn.xwiki.products:xwiki-enterprise-web:war:2.1-SNAPSHOT
> [INFO] +- com.xpn.xwiki.platform:xwiki-web-standard:war:2.1-SNAPSHOT:compile
> [INFO] +-
> com.xpn.xwiki.platform.plugins:xwiki-plugin-watchlist:jar:1.20-SNAPSHOT:compile
> [INFO] +-
> com.xpn.xwiki.platform.plugins:xwiki-plugin-jodatime:jar:1.4-SNAPSHOT:compile
> ...
> {noformat}
> As you can see the com.xpn.xwiki.platform:xwiki-web-standard:war dependency
> doesn't contain any transitive deps but it has several of them
> (see http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/standard/pom.xml )
> This is probably because the general artifact resolver stops at WAR packaging
> types. While this is probably fine when executing a maven project, it isn't
> when listing all project dependencies.
> Thanks
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MDEP-442) Failed to access file due to locked access when using more than one Maven worker thread
[
https://issues.apache.org/jira/browse/MDEP-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MDEP-442:
---
Priority: Major (was: Critical)
> Failed to access file due to locked access when using more than one Maven
> worker thread
> ---
>
> Key: MDEP-442
> URL: https://issues.apache.org/jira/browse/MDEP-442
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: copy
>Affects Versions: 2.8
> Environment: MVN 3.0.4, JDK 1.7, Win 7 Pro SP1 64 Bit
>Reporter: Markus Karg
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: maven-thread-test-update.zip, maven-thread-test.zip
>
>
> My multi-module POM contains of ten modules. Each of those modules does the
> same: Invoke the 'copy' goal of the dependency plugin. The idea is to have
> ten copies of the identical source, which then end up in ten different
> targets by getting furthere processed.
> As long as I do not use more than one Maven worker thread, everything works
> well always. But when using -T 5 to have five worker threads, rather often
> the reactor fails because the source file (!) is locked:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:2.8:copy (copy) on project
> MYARTIFACT: Unable to resolve artifact. Could not transfer artifact
> mygroup:myartifact:dll:4.36.1-20140415.143537-37 from/to nexus
> (http://nexus/nexus/content/groups/public):
> C:\Users\jenkins.QUIPSY\.m2\repository\mygroup\myartifact\4.36.1-SNAPSHOT\myartifact-4.36.1-20140415.143537-37.dll
> (The process cannot access the file, because it is in use by another process)
> {noformat}
> So it seems that the 'copy' task actually is locking the source file, which
> is not multi-threading-compatible. Hence, either that is a bug and should get
> fixed, or it is on purpose, then this goal has to be marked as
> non-multithreading-able.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
