[jira] [Commented] (MNG-7045) Drop CDI API from Maven
[ https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17243488#comment-17243488 ] Mark Struberg commented on MNG-7045: +1 I was opposed to even the atinject and slf4j apis back then. Maven should imo be fully self-contained without any classpath conflicts. > Drop CDI API from Maven > --- > > Key: MNG-7045 > URL: https://issues.apache.org/jira/browse/MNG-7045 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Romain Manni-Bucau >Priority: Major > > This is an old leak which triggered a lot of regressions and still triggers > bugs in mojos. > Since there is on real justification in maven itself (@Typed is not since > there are alternative and cdi is not used in any piece of maven), let's drop > it. > If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSHADE-342) Many integration tests fail when run in isolation
[
https://issues.apache.org/jira/browse/MSHADE-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006435#comment-17006435
]
Mark Struberg commented on MSHADE-342:
--
I've documented the proper usage over at MASSEMBLY-919. You just have to add
that other setup IT as well. e.g.
{noformat}
mvn verify -Dinvoker.test=it-project-parent,projects/bugs/massembly-919
-Prun-its
{noformat}
> Many integration tests fail when run in isolation
> -
>
> Key: MSHADE-342
> URL: https://issues.apache.org/jira/browse/MSHADE-342
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
>
> Maven invoker plugin supports running ITs in isolation, but many ITs fail
> when run in isolation.
> One example (there are many others):
> {code:bash}
> mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
> {code}
> They fail because of a missing {{target/it/setup-parent/pom.xml}}.
> The failure is logged in {{target/it/setup-parent/build.log}}.
> The reason is that there is a missing parent dependency, which is apparently
> required for _any_ IT in this project.
> When you run all the ITs together, it works by accident because the missing
> directory is created by some other test in the beginning of the IT test run,
> and then all subsequent tests work as well.
> h3. Potential solution
> A fix is to identify the broken ITs by running all of them in isolation and
> add the following to all of the broken ones:
> {code:xml}
>
> org.apache.maven.plugins.shade.its
> shade-parent
> 1.0
> ../setup-parent
>
> {code}
> It should be documented somewhere (maybe it is but I overlooked it?) that,
> when writing an IT, this _must_ be the parent.
> The acceptance criteria for the fix should be:
> # {{mvn -Run-its clean verify -Dinvoker.test=}} must run the IT in
> isolation.
> # Optional, but nice if it works: after running the IT (or all ITs) once, it
> must be possible to debug the Maven project by doing {{cd target/it/;
> mvnDebug install}}.
> (+) It satisfies both acceptance criteria.
> (-) Every individual IT's {{pom.xml}} needs to be updated with a parent
> dependency it has no business with.
> (-) It excludes writing an IT for a root project (that has no parent).
> Maybe we can find a solution that doesn't involve updating all IT projects.
> I'll need to investigate a bit more, first I'll need to figure out where the
> {{setup-parent}} project comes from.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MASSEMBLY-775) Emit WARNING instead of ERROR
[
https://issues.apache.org/jira/browse/MASSEMBLY-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17003278#comment-17003278
]
Mark Struberg commented on MASSEMBLY-775:
-
proposed change up for review
[https://github.com/apache/maven-assembly-plugin/pull/14]
Gonna commit it in the next 2 days if no one is yelling ;)
> Emit WARNING instead of ERROR
> -
>
> Key: MASSEMBLY-775
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-775
> Project: Maven Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 2.5.5
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I have currently a build which creates several tar/tar.gz/zip archives etc.
> {code}
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor-inner-tar.xml
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor.xml
> [INFO] Building tar: C:\...\xyz-X.y.z-SNAPSHOT-dist.tar
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> {code}
> In my opinion the message could be a WARNING instead of an error ? WDYT ?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MASSEMBLY-775) Emit WARNING instead of ERROR
[
https://issues.apache.org/jira/browse/MASSEMBLY-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17002950#comment-17002950
]
Mark Struberg edited comment on MASSEMBLY-775 at 12/24/19 5:52 PM:
---
Yea, the problem is not really the WARN or ERROR. It's more that nobody can
really use a portable absolute path under Windows right now ;)
was (Author: struberg):
Yea, the problem is not really the WARN or ERROR. It's more that nobody can
really use an absolute path under Windows right now ;)
> Emit WARNING instead of ERROR
> -
>
> Key: MASSEMBLY-775
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-775
> Project: Maven Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 2.5.5
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> I have currently a build which creates several tar/tar.gz/zip archives etc.
> {code}
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor-inner-tar.xml
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor.xml
> [INFO] Building tar: C:\...\xyz-X.y.z-SNAPSHOT-dist.tar
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> {code}
> In my opinion the message could be a WARNING instead of an error ? WDYT ?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MASSEMBLY-775) Emit WARNING instead of ERROR
[
https://issues.apache.org/jira/browse/MASSEMBLY-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17002950#comment-17002950
]
Mark Struberg commented on MASSEMBLY-775:
-
Yea, the problem is not really the WARN or ERROR. It's more that nobody can
really use an absolute path under Windows right now ;)
> Emit WARNING instead of ERROR
> -
>
> Key: MASSEMBLY-775
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-775
> Project: Maven Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 2.5.5
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> I have currently a build which creates several tar/tar.gz/zip archives etc.
> {code}
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor-inner-tar.xml
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor.xml
> [INFO] Building tar: C:\...\xyz-X.y.z-SNAPSHOT-dist.tar
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> {code}
> In my opinion the message could be a WARNING instead of an error ? WDYT ?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MASSEMBLY-775) Emit WARNING instead of ERROR
[
https://issues.apache.org/jira/browse/MASSEMBLY-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17002881#comment-17002881
]
Mark Struberg commented on MASSEMBLY-775:
-
There are actual that a {{/}} is interpreted as absolute directory in linux,
but not on windows. And this is due to us using {{File#isAbsolute()}} in
{{org.apache.maven.plugins.assembly.archive.task.AddFileSetsTask#getFileSetDirectory}}.
[https://github.com/apache/maven-assembly-plugin/blob/master/src/main/java/org/apache/maven/plugins/assembly/archive/task/AddFileSetsTask.java#L189]
If it is not File#absolute then we pretend to be a subdirectory of the current
project. But only on Windows! This really really sounds wrong.
Right now those builds are NOT reproducible on a different OS!
So we might really go for checking for paths beginning with a {{"/"}}
ourselves. Yes, this would be kind of slightly backward incompatible, but it
would be far superior in terms of compatibility.
I think we could live with the diffferent behaviour if we bump to a new minor
version, e.g. 3.3.0.
> Emit WARNING instead of ERROR
> -
>
> Key: MASSEMBLY-775
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-775
> Project: Maven Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 2.5.5
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> I have currently a build which creates several tar/tar.gz/zip archives etc.
> {code}
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor-inner-tar.xml
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor.xml
> [INFO] Building tar: C:\...\xyz-X.y.z-SNAPSHOT-dist.tar
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> {code}
> In my opinion the message could be a WARNING instead of an error ? WDYT ?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MASSEMBLY-775) Emit WARNING instead of ERROR
[
https://issues.apache.org/jira/browse/MASSEMBLY-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17002759#comment-17002759
]
Mark Struberg commented on MASSEMBLY-775:
-
It looks like the IT for MASSEMBLY-665 doesn't really test what the ticket
describes. It also has no verify. We need to improve this.
> Emit WARNING instead of ERROR
> -
>
> Key: MASSEMBLY-775
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-775
> Project: Maven Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 2.5.5
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> I have currently a build which creates several tar/tar.gz/zip archives etc.
> {code}
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor-inner-tar.xml
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor.xml
> [INFO] Building tar: C:\...\xyz-X.y.z-SNAPSHOT-dist.tar
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> {code}
> In my opinion the message could be a WARNING instead of an error ? WDYT ?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MASSEMBLY-775) Emit WARNING instead of ERROR
[
https://issues.apache.org/jira/browse/MASSEMBLY-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17002164#comment-17002164
]
Mark Struberg edited comment on MASSEMBLY-775 at 12/23/19 8:45 AM:
---
MASSEMBLY-665 is the original ticket that introduced all those warnings.
was (Author: struberg):
the original ticket that introduced all those warnings.
> Emit WARNING instead of ERROR
> -
>
> Key: MASSEMBLY-775
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-775
> Project: Maven Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 2.5.5
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> I have currently a build which creates several tar/tar.gz/zip archives etc.
> {code}
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor-inner-tar.xml
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor.xml
> [INFO] Building tar: C:\...\xyz-X.y.z-SNAPSHOT-dist.tar
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> {code}
> In my opinion the message could be a WARNING instead of an error ? WDYT ?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MASSEMBLY-775) Emit WARNING instead of ERROR
[
https://issues.apache.org/jira/browse/MASSEMBLY-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17002162#comment-17002162
]
Mark Struberg edited comment on MASSEMBLY-775 at 12/23/19 8:45 AM:
---
ticket MASSEMBLY-746 applied the warnForPlatformSpecifics not only for for
AddFileSetsTasks but also for FileItemAssemblyPhase
was (Author: struberg):
this ticket applied the warnForPlatformSpecifics not only for for
AddFileSetsTasks but also for FileItemAssemblyPhase
> Emit WARNING instead of ERROR
> -
>
> Key: MASSEMBLY-775
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-775
> Project: Maven Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 2.5.5
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> I have currently a build which creates several tar/tar.gz/zip archives etc.
> {code}
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor-inner-tar.xml
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor.xml
> [INFO] Building tar: C:\...\xyz-X.y.z-SNAPSHOT-dist.tar
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> {code}
> In my opinion the message could be a WARNING instead of an error ? WDYT ?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MASSEMBLY-775) Emit WARNING instead of ERROR
[
https://issues.apache.org/jira/browse/MASSEMBLY-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17002164#comment-17002164
]
Mark Struberg commented on MASSEMBLY-775:
-
the original ticket that introduced all those warnings.
> Emit WARNING instead of ERROR
> -
>
> Key: MASSEMBLY-775
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-775
> Project: Maven Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 2.5.5
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> I have currently a build which creates several tar/tar.gz/zip archives etc.
> {code}
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor-inner-tar.xml
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor.xml
> [INFO] Building tar: C:\...\xyz-X.y.z-SNAPSHOT-dist.tar
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> {code}
> In my opinion the message could be a WARNING instead of an error ? WDYT ?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MASSEMBLY-775) Emit WARNING instead of ERROR
[
https://issues.apache.org/jira/browse/MASSEMBLY-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17002162#comment-17002162
]
Mark Struberg commented on MASSEMBLY-775:
-
this ticket applied the warnForPlatformSpecifics not only for for
AddFileSetsTasks but also for FileItemAssemblyPhase
> Emit WARNING instead of ERROR
> -
>
> Key: MASSEMBLY-775
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-775
> Project: Maven Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 2.5.5
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> I have currently a build which creates several tar/tar.gz/zip archives etc.
> {code}
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor-inner-tar.xml
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor.xml
> [INFO] Building tar: C:\...\xyz-X.y.z-SNAPSHOT-dist.tar
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> {code}
> In my opinion the message could be a WARNING instead of an error ? WDYT ?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MSHADE-286) Artifacts to be included for shading are not consistently checked for existence
[
https://issues.apache.org/jira/browse/MSHADE-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg reassigned MSHADE-286:
Assignee: Mark Struberg
> Artifacts to be included for shading are not consistently checked for
> existence
> ---
>
> Key: MSHADE-286
> URL: https://issues.apache.org/jira/browse/MSHADE-286
> Project: Maven Shade Plugin
> Issue Type: Improvement
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Assignee: Mark Struberg
>Priority: Minor
>
> While looking at {{ShadeMojo.execute}}, I noticed that the artifacts to be
> included for shading are not consistently checked for existence.
> For example, on line 404, the main artifact file is _not_ checked for
> existence:
> {code:java}
> artifacts.add( project.getArtifact().getFile() );{code}
> But immediately below, the sources artifact file _is_ checked for existence:
> {code:java}
> if ( createSourcesJar )
> {
> File file = shadedSourcesArtifactFile();
> if ( file.isFile() )
> {
> sourceArtifacts.add( file );
> }
> }
> {code}
> Maybe there is a reason for this, but it seems inconsistent - it seems like a
> good idea to always check for existence before adding a file. I suppose the
> impact of this is very low - it's merely an optimization to omit non-existent
> files.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MASSEMBLY-919) Transitive dependency of a test dependency is included
[
https://issues.apache.org/jira/browse/MASSEMBLY-919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17000165#comment-17000165
]
Mark Struberg commented on MASSEMBLY-919:
-
I was not able to reproduce your problem.
I've now created an integration test over here:
[https://github.com/struberg/maven-assembly-plugin/tree/MASSEMBLY-919]
Can you please check if this represents your scenario? You can run the single
IT with the following command:
{noformat}
mvn verify -Dinvoker.test=it-project-parent,projects/bugs/massembly-919
-Prun-its{noformat}
> Transitive dependency of a test dependency is included
> --
>
> Key: MASSEMBLY-919
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-919
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet, filtering
>Affects Versions: 3.1.1
>Reporter: Zsombor Gegesy
>Assignee: Mark Struberg
>Priority: Blocker
> Labels: patch-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I have a simple module, with one compile 'module-a' dependency, and with one
> test dependency ('module-b'), which has a couple of 'compile' dependencies
> (module-b-1, module-b-2, etc)
> In my assembly.xml I have:
> {code:java}
>
>
> true
> tools
> false
>
> runtime
> true
>
>
> {code}
> I would assume, that in this case, only 'module-a.jar' ends in the tool
> folder, however, the plugin adds module-b-1, module-b-2, etc too - which is
> not expected, as they are dependencies of 'module-b', which has test scope
> only.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MASSEMBLY-919) Transitive dependency of a test dependency is included
[
https://issues.apache.org/jira/browse/MASSEMBLY-919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg reassigned MASSEMBLY-919:
---
Assignee: Mark Struberg
> Transitive dependency of a test dependency is included
> --
>
> Key: MASSEMBLY-919
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-919
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet, filtering
>Affects Versions: 3.1.1
>Reporter: Zsombor Gegesy
>Assignee: Mark Struberg
>Priority: Blocker
> Labels: patch-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I have a simple module, with one compile 'module-a' dependency, and with one
> test dependency ('module-b'), which has a couple of 'compile' dependencies
> (module-b-1, module-b-2, etc)
> In my assembly.xml I have:
> {code:java}
>
>
> true
> tools
> false
>
> runtime
> true
>
>
> {code}
> I would assume, that in this case, only 'module-a.jar' ends in the tool
> folder, however, the plugin adds module-b-1, module-b-2, etc too - which is
> not expected, as they are dependencies of 'module-b', which has test scope
> only.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MSHADE-337) Relocation cannot process class file version 58 JARs
[
https://issues.apache.org/jira/browse/MSHADE-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved MSHADE-337.
--
Fix Version/s: 3.2.2
Resolution: Fixed
> Relocation cannot process class file version 58 JARs
>
>
> Key: MSHADE-337
> URL: https://issues.apache.org/jira/browse/MSHADE-337
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Jordan Zimmerman
>Assignee: Karl Heinz Marbaise
>Priority: Major
> Fix For: 3.2.2
>
> Attachments: shade-bug.zip
>
>
> I was playing around with Java 14 and was making a shaded JAR. The shade
> plugin seems to work fine but if I add a relocation it throws:
> {noformat}
> java.lang.IllegalArgumentException: Unsupported class file major version 58
> {noformat}
> Steps to Reproduce:
> * Unzip the enclosed attachment
> * Make sure Java 14 is installed and JAVA_HOME points at it
> * Run {{mvn package}}
> Stacktrace:
> {noformat}
> Caused by: java.lang.IllegalArgumentException: Unsupported class file major
> version 58
> at org.objectweb.asm.ClassReader. (ClassReader.java:184)
> at org.objectweb.asm.ClassReader. (ClassReader.java:166)
> at org.objectweb.asm.ClassReader. (ClassReader.java:152)
> at org.objectweb.asm.ClassReader. (ClassReader.java:273)
> at org.apache.maven.plugins.shade.DefaultShader.addRemappedClass
> (DefaultShader.java:438)
> at org.apache.maven.plugins.shade.DefaultShader.shadeSingleJar
> (DefaultShader.java:240)
> at org.apache.maven.plugins.shade.DefaultShader.shadeJars
> (DefaultShader.java:196)
> at org.apache.maven.plugins.shade.DefaultShader.shade
> (DefaultShader.java:106)
> at org.apache.maven.plugins.shade.mojo.ShadeMojo.execute
> (ShadeMojo.java:442)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> {noformat}
> Notes:
> * I tried to make the example as minimal as possible
> * The relocation patterns don't see to matter. The issue is in the relocator
> code opening a JAR dependency I guess
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-337) Relocation cannot process class file version 58 JARs
[
https://issues.apache.org/jira/browse/MSHADE-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998610#comment-16998610
]
Mark Struberg commented on MSHADE-337:
--
asmVersion already got updated to 7.2 in commit
70d643bebd6b5ce176ad134e984aa0d73ffc.
And yes [~michael-o], we will have this every 6 months :(.
> Relocation cannot process class file version 58 JARs
>
>
> Key: MSHADE-337
> URL: https://issues.apache.org/jira/browse/MSHADE-337
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Jordan Zimmerman
>Assignee: Karl Heinz Marbaise
>Priority: Major
> Attachments: shade-bug.zip
>
>
> I was playing around with Java 14 and was making a shaded JAR. The shade
> plugin seems to work fine but if I add a relocation it throws:
> {noformat}
> java.lang.IllegalArgumentException: Unsupported class file major version 58
> {noformat}
> Steps to Reproduce:
> * Unzip the enclosed attachment
> * Make sure Java 14 is installed and JAVA_HOME points at it
> * Run {{mvn package}}
> Stacktrace:
> {noformat}
> Caused by: java.lang.IllegalArgumentException: Unsupported class file major
> version 58
> at org.objectweb.asm.ClassReader. (ClassReader.java:184)
> at org.objectweb.asm.ClassReader. (ClassReader.java:166)
> at org.objectweb.asm.ClassReader. (ClassReader.java:152)
> at org.objectweb.asm.ClassReader. (ClassReader.java:273)
> at org.apache.maven.plugins.shade.DefaultShader.addRemappedClass
> (DefaultShader.java:438)
> at org.apache.maven.plugins.shade.DefaultShader.shadeSingleJar
> (DefaultShader.java:240)
> at org.apache.maven.plugins.shade.DefaultShader.shadeJars
> (DefaultShader.java:196)
> at org.apache.maven.plugins.shade.DefaultShader.shade
> (DefaultShader.java:106)
> at org.apache.maven.plugins.shade.mojo.ShadeMojo.execute
> (ShadeMojo.java:442)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> {noformat}
> Notes:
> * I tried to make the example as minimal as possible
> * The relocation patterns don't see to matter. The issue is in the relocator
> code opening a JAR dependency I guess
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MSHADE-285) It should be possible to shade test sources as a JAR
[
https://issues.apache.org/jira/browse/MSHADE-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved MSHADE-285.
--
Fix Version/s: 3.2.2
Resolution: Fixed
Thanks again Peter, excellent stuff!
> It should be possible to shade test sources as a JAR
>
>
> Key: MSHADE-285
> URL: https://issues.apache.org/jira/browse/MSHADE-285
> Project: Maven Shade Plugin
> Issue Type: Improvement
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 3.2.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The configuration option {{createSourcesJar}} allows to shade sources JAR,
> but there is no such option for test sources.
> I see two solutions:
> # Extend the semantics of {{createSourcesJar}} such that, when combined with
> {{shadeTestJar}}, is also creates the _test_ sources JAR.
> # Introduce a new configuration option {{createTestSourcesJar}}, similar to
> {{createSourcesJar}}.
> The former is very intuitive, but it lacks the flexibility to create a JAR,
> sources JAR, test JAR, but _no_ test sources JAR. The latter allows more
> flexibility.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MSHADE-285) It should be possible to shade test sources as a JAR
[
https://issues.apache.org/jira/browse/MSHADE-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg reassigned MSHADE-285:
Assignee: Mark Struberg
> It should be possible to shade test sources as a JAR
>
>
> Key: MSHADE-285
> URL: https://issues.apache.org/jira/browse/MSHADE-285
> Project: Maven Shade Plugin
> Issue Type: Improvement
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Assignee: Mark Struberg
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The configuration option {{createSourcesJar}} allows to shade sources JAR,
> but there is no such option for test sources.
> I see two solutions:
> # Extend the semantics of {{createSourcesJar}} such that, when combined with
> {{shadeTestJar}}, is also creates the _test_ sources JAR.
> # Introduce a new configuration option {{createTestSourcesJar}}, similar to
> {{createSourcesJar}}.
> The former is very intuitive, but it lacks the flexibility to create a JAR,
> sources JAR, test JAR, but _no_ test sources JAR. The latter allows more
> flexibility.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MSHADE-284) Shaded test JARs are always empty
[
https://issues.apache.org/jira/browse/MSHADE-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved MSHADE-284.
--
Fix Version/s: 3.2.2
Resolution: Fixed
PR applied, thanks a lot, Peter!
> Shaded test JARs are always empty
> -
>
> Key: MSHADE-284
> URL: https://issues.apache.org/jira/browse/MSHADE-284
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 3.2.2
>
> Attachments: shadeTestJar.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Shading test JARs using the {{shadeTestJar}} configuration option yields an
> empty test JAR. This has been noticed by others, see for example Steve K's
> answer [on
> StackOverflow|https://stackoverflow.com/questions/5149130/how-can-i-configure-the-maven-shade-plugin-to-include-test-code-in-my-jar/49617516#49617516],
> but people have reverted to other hacks and workarounds to overcome this
> (e.g. use a different plugin).
> Scenario:
> # Create modules {{api}}, {{impl}} and a module {{uber}} which has as sole
> purpose to make an uber JAR for the combination of the first two modules.
> {{uber}} itself has no sources.
> # Both modules have both {{jar}} and {{test-jar}} artifacts.
> # Configure the {{maven-shade-plugin}} in the {{uber}} module with the
> configuration option {{shadeTestJar}} set to {{true}}.
> Expected:
> # Content of {{uber.jar}} is the aggregate content of {{api.jar}} and
> {{impl.jar}}.
> # Content of {{uber-tests.jar}} is the aggregate content of
> {{api-tests.jar}} and {{impl-tests.jar}}.
> Actual:
> # Content of {{uber.jar}} is as expected.
> # {{uber-tests.jar}} is empty.
> Root cause:
> * The implementation of the {{shadeTestJar}} feature in {{ShaderMojo}} is
> buggy and incomplete.
> * The call to {{processArtifactSelectors}} on line 425 doesn't pass the
> {{testArtifacts}}, so they are never correctly filled in.
> * The implementation of {{processArtifactSelectors}} doesn't deal with test
> JARs at all and has to be extended to support them.
> * The "if" statement on line 452 incorrectly treats a test JAR as sources.
> This whole feature looks like it was done in a hurry as a sloppy copy-paste
> job, and in 5 years nobody took the time to report or fix it. Amazing.
> Anyway, you can find my proposed fix in attachment: [^shadeTestJar.patch]. I
> have tested it manually on my project and it works.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MSHADE-284) Shaded test JARs are always empty
[
https://issues.apache.org/jira/browse/MSHADE-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg reassigned MSHADE-284:
Assignee: Mark Struberg
> Shaded test JARs are always empty
> -
>
> Key: MSHADE-284
> URL: https://issues.apache.org/jira/browse/MSHADE-284
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Assignee: Mark Struberg
>Priority: Major
> Attachments: shadeTestJar.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Shading test JARs using the {{shadeTestJar}} configuration option yields an
> empty test JAR. This has been noticed by others, see for example Steve K's
> answer [on
> StackOverflow|https://stackoverflow.com/questions/5149130/how-can-i-configure-the-maven-shade-plugin-to-include-test-code-in-my-jar/49617516#49617516],
> but people have reverted to other hacks and workarounds to overcome this
> (e.g. use a different plugin).
> Scenario:
> # Create modules {{api}}, {{impl}} and a module {{uber}} which has as sole
> purpose to make an uber JAR for the combination of the first two modules.
> {{uber}} itself has no sources.
> # Both modules have both {{jar}} and {{test-jar}} artifacts.
> # Configure the {{maven-shade-plugin}} in the {{uber}} module with the
> configuration option {{shadeTestJar}} set to {{true}}.
> Expected:
> # Content of {{uber.jar}} is the aggregate content of {{api.jar}} and
> {{impl.jar}}.
> # Content of {{uber-tests.jar}} is the aggregate content of
> {{api-tests.jar}} and {{impl-tests.jar}}.
> Actual:
> # Content of {{uber.jar}} is as expected.
> # {{uber-tests.jar}} is empty.
> Root cause:
> * The implementation of the {{shadeTestJar}} feature in {{ShaderMojo}} is
> buggy and incomplete.
> * The call to {{processArtifactSelectors}} on line 425 doesn't pass the
> {{testArtifacts}}, so they are never correctly filled in.
> * The implementation of {{processArtifactSelectors}} doesn't deal with test
> JARs at all and has to be extended to support them.
> * The "if" statement on line 452 incorrectly treats a test JAR as sources.
> This whole feature looks like it was done in a hurry as a sloppy copy-paste
> job, and in 5 years nobody took the time to report or fix it. Amazing.
> Anyway, you can find my proposed fix in attachment: [^shadeTestJar.patch]. I
> have tested it manually on my project and it works.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-284) Shaded test JARs are always empty
[
https://issues.apache.org/jira/browse/MSHADE-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16997413#comment-16997413
]
Mark Struberg commented on MSHADE-284:
--
I'll gonna look into it tonight or in the next 2 days.
> Shaded test JARs are always empty
> -
>
> Key: MSHADE-284
> URL: https://issues.apache.org/jira/browse/MSHADE-284
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Assignee: Mark Struberg
>Priority: Major
> Attachments: shadeTestJar.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Shading test JARs using the {{shadeTestJar}} configuration option yields an
> empty test JAR. This has been noticed by others, see for example Steve K's
> answer [on
> StackOverflow|https://stackoverflow.com/questions/5149130/how-can-i-configure-the-maven-shade-plugin-to-include-test-code-in-my-jar/49617516#49617516],
> but people have reverted to other hacks and workarounds to overcome this
> (e.g. use a different plugin).
> Scenario:
> # Create modules {{api}}, {{impl}} and a module {{uber}} which has as sole
> purpose to make an uber JAR for the combination of the first two modules.
> {{uber}} itself has no sources.
> # Both modules have both {{jar}} and {{test-jar}} artifacts.
> # Configure the {{maven-shade-plugin}} in the {{uber}} module with the
> configuration option {{shadeTestJar}} set to {{true}}.
> Expected:
> # Content of {{uber.jar}} is the aggregate content of {{api.jar}} and
> {{impl.jar}}.
> # Content of {{uber-tests.jar}} is the aggregate content of
> {{api-tests.jar}} and {{impl-tests.jar}}.
> Actual:
> # Content of {{uber.jar}} is as expected.
> # {{uber-tests.jar}} is empty.
> Root cause:
> * The implementation of the {{shadeTestJar}} feature in {{ShaderMojo}} is
> buggy and incomplete.
> * The call to {{processArtifactSelectors}} on line 425 doesn't pass the
> {{testArtifacts}}, so they are never correctly filled in.
> * The implementation of {{processArtifactSelectors}} doesn't deal with test
> JARs at all and has to be extended to support them.
> * The "if" statement on line 452 incorrectly treats a test JAR as sources.
> This whole feature looks like it was done in a hurry as a sloppy copy-paste
> job, and in 5 years nobody took the time to report or fix it. Amazing.
> Anyway, you can find my proposed fix in attachment: [^shadeTestJar.patch]. I
> have tested it manually on my project and it works.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1457) trimStackTrace should be disabled by default
[
https://issues.apache.org/jira/browse/SUREFIRE-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16493318#comment-16493318
]
Mark Struberg edited comment on SUREFIRE-1457 at 5/29/18 9:56 AM:
--
+1 to disable it and go back to the original behaviour (which means to print
all the stack trace as it was in maven 1, 2 and earlier in maven 3 days).
was (Author: struberg):
+1 to disable it and go back to the original behaviour.
> trimStackTrace should be disabled by default
>
>
> Key: SUREFIRE-1457
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1457
> Project: Maven Surefire
> Issue Type: Improvement
>Affects Versions: 2.21.2
>Reporter: Réda Housni Alaoui
>Assignee: Tibor Digana
>Priority: Critical
>
> We are using Jenkins at work.
> Each time we had test failures, stack trace were incomplete and therefore
> totally useless.
> I just discovered {{trimStackTrace}} option.
> IMO, the fact that this option is currently enabled by default is a total non
> sense.
> Now we have to change the pom.xml of every projects of the company to have a
> correct default.
> IMO, and I think I am not the only one here, trimStackTrace should be
> disabled by default.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1457) trimStackTrace should be disabled by default
[
https://issues.apache.org/jira/browse/SUREFIRE-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16493318#comment-16493318
]
Mark Struberg commented on SUREFIRE-1457:
-
+1 to disable it and go back to the original behaviour.
> trimStackTrace should be disabled by default
>
>
> Key: SUREFIRE-1457
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1457
> Project: Maven Surefire
> Issue Type: Improvement
>Affects Versions: 2.21.2
>Reporter: Réda Housni Alaoui
>Assignee: Tibor Digana
>Priority: Critical
>
> We are using Jenkins at work.
> Each time we had test failures, stack trace were incomplete and therefore
> totally useless.
> I just discovered {{trimStackTrace}} option.
> IMO, the fact that this option is currently enabled by default is a total non
> sense.
> Now we have to change the pom.xml of every projects of the company to have a
> correct default.
> IMO, and I think I am not the only one here, trimStackTrace should be
> disabled by default.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MJAVADOC-494) javadoc:aggregate ignores repositories declared in sub-modules
[
https://issues.apache.org/jira/browse/MJAVADOC-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16191844#comment-16191844
]
Mark Struberg edited comment on MJAVADOC-494 at 10/4/17 7:10 PM:
-
verified with maven-3.3.9
Only happens during a full build of
$> mvn clean install javadoc:aggregate.
$> mvn clean install javadoc:javadoc works fine.
$> mvn javadoc:aggregate after a previous full build also works fine
was (Author: struberg):
verified with maven-3.3.9
Only happens with javadoc:aggregate. javadoc:javadoc works fine.
> javadoc:aggregate ignores repositories declared in sub-modules
> --
>
> Key: MJAVADOC-494
> URL: https://issues.apache.org/jira/browse/MJAVADOC-494
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.0.0-M1
> Environment: Maven Javadoc plugin 3.0.0-M1
> Apache Maven 3.5.0
> Java version 1.8.0_144
>Reporter: Martin Desruisseaux
> Labels: regression
>
> Given a multi-modules project with:
> * A {{… URL A …}} element in the root {{pom.xml}}.
> * Another {{… URL B …}} element in the {{pom.xml}}
> of a module, for downloading a JAR file used only by that specific module (we
> do that in order to depend only on Maven central for all modules except one).
> Then:
> * {{mvn install}} works: it download all JAR files as expected.
> * {{mvn javadoc:javadoc}} also work with both Maven Javadoc plugin 2.10.4 and
> 3.0.0-M1.
> * {{mvn javadoc:aggregate}} with Maven Javadoc plugin 2.10.4 works.
> * {{mvn javadoc:aggregate}} with Maven Javadoc plugin 3.0.0-M1 fails.
> Maven Javadoc plugin 3.0.0-M1 execution produces the following logs
> (simplified for brevity):
> {noformat}
> Downloading: URL A/.../MyArtifact.jar
> Downloading: https://repo.maven.apache.org/maven2/.../MyArtifact.jar
> {noformat}
> No download attempt from URL B is reported, despite the {{}}
> declaration in a sub-module. Note that the JAR is present in my
> {{.m2/repository}} directory but is apparently ignored.
> Downgrading Maven Javadoc plugin to 2.10.4 with everything else identical
> allows successful aggregated Javadoc generation.
> *Note:* another user apparently has [the same issue on stack
> overflow|https://stackoverflow.com/questions/46034250/maven-javadocaggregate-artifacts-could-not-be-resolved].
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MJAVADOC-494) javadoc:aggregate ignores repositories declared in sub-modules
[
https://issues.apache.org/jira/browse/MJAVADOC-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16191844#comment-16191844
]
Mark Struberg edited comment on MJAVADOC-494 at 10/4/17 7:09 PM:
-
verified with maven-3.3.9
Only happens with javadoc:aggregate. javadoc:javadoc works fine.
was (Author: struberg):
verified with maven-3.3.9 and maven-javadoc-plugin-2.9.1
Seems to be a longer outstanding issue.
Only happens with javadoc:aggregate. javadoc:javadoc works fine.
> javadoc:aggregate ignores repositories declared in sub-modules
> --
>
> Key: MJAVADOC-494
> URL: https://issues.apache.org/jira/browse/MJAVADOC-494
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.0.0-M1
> Environment: Maven Javadoc plugin 3.0.0-M1
> Apache Maven 3.5.0
> Java version 1.8.0_144
>Reporter: Martin Desruisseaux
> Labels: regression
>
> Given a multi-modules project with:
> * A {{… URL A …}} element in the root {{pom.xml}}.
> * Another {{… URL B …}} element in the {{pom.xml}}
> of a module, for downloading a JAR file used only by that specific module (we
> do that in order to depend only on Maven central for all modules except one).
> Then:
> * {{mvn install}} works: it download all JAR files as expected.
> * {{mvn javadoc:javadoc}} also work with both Maven Javadoc plugin 2.10.4 and
> 3.0.0-M1.
> * {{mvn javadoc:aggregate}} with Maven Javadoc plugin 2.10.4 works.
> * {{mvn javadoc:aggregate}} with Maven Javadoc plugin 3.0.0-M1 fails.
> Maven Javadoc plugin 3.0.0-M1 execution produces the following logs
> (simplified for brevity):
> {noformat}
> Downloading: URL A/.../MyArtifact.jar
> Downloading: https://repo.maven.apache.org/maven2/.../MyArtifact.jar
> {noformat}
> No download attempt from URL B is reported, despite the {{}}
> declaration in a sub-module. Note that the JAR is present in my
> {{.m2/repository}} directory but is apparently ignored.
> Downgrading Maven Javadoc plugin to 2.10.4 with everything else identical
> allows successful aggregated Javadoc generation.
> *Note:* another user apparently has [the same issue on stack
> overflow|https://stackoverflow.com/questions/46034250/maven-javadocaggregate-artifacts-could-not-be-resolved].
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MJAVADOC-494) javadoc:aggregate ignores repositories declared in sub-modules
[
https://issues.apache.org/jira/browse/MJAVADOC-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16191844#comment-16191844
]
Mark Struberg commented on MJAVADOC-494:
verified with maven-3.3.9 and maven-javadoc-plugin-2.9.1
Seems to be a longer outstanding issue.
Only happens with javadoc:aggregate. javadoc:javadoc works fine.
> javadoc:aggregate ignores repositories declared in sub-modules
> --
>
> Key: MJAVADOC-494
> URL: https://issues.apache.org/jira/browse/MJAVADOC-494
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.0.0-M1
> Environment: Maven Javadoc plugin 3.0.0-M1
> Apache Maven 3.5.0
> Java version 1.8.0_144
>Reporter: Martin Desruisseaux
> Labels: regression
>
> Given a multi-modules project with:
> * A {{… URL A …}} element in the root {{pom.xml}}.
> * Another {{… URL B …}} element in the {{pom.xml}}
> of a module, for downloading a JAR file used only by that specific module (we
> do that in order to depend only on Maven central for all modules except one).
> Then:
> * {{mvn install}} works: it download all JAR files as expected.
> * {{mvn javadoc:javadoc}} also work with both Maven Javadoc plugin 2.10.4 and
> 3.0.0-M1.
> * {{mvn javadoc:aggregate}} with Maven Javadoc plugin 2.10.4 works.
> * {{mvn javadoc:aggregate}} with Maven Javadoc plugin 3.0.0-M1 fails.
> Maven Javadoc plugin 3.0.0-M1 execution produces the following logs
> (simplified for brevity):
> {noformat}
> Downloading: URL A/.../MyArtifact.jar
> Downloading: https://repo.maven.apache.org/maven2/.../MyArtifact.jar
> {noformat}
> No download attempt from URL B is reported, despite the {{}}
> declaration in a sub-module. Note that the JAR is present in my
> {{.m2/repository}} directory but is apparently ignored.
> Downgrading Maven Javadoc plugin to 2.10.4 with everything else identical
> allows successful aggregated Javadoc generation.
> *Note:* another user apparently has [the same issue on stack
> overflow|https://stackoverflow.com/questions/46034250/maven-javadocaggregate-artifacts-could-not-be-resolved].
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6082) Introduction of model version 4.1.0
[ https://issues.apache.org/jira/browse/MNG-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15746401#comment-15746401 ] Mark Struberg commented on MNG-6082: Well, I didn't want to offend anyone. It seems that a lot of work have been put into it. But nonetheless I was not able to find any answer to what this ticket is about without looking at all the linked tickets. I think it's good to have as a summary ticket, but it should at least have a description. I've looked through the list of tickets and I could not find a ticket which requires us to bump the pom model version. There are quite a few underspecified areas (optional in dependencyManagement, etc) where I agree that it should get nailed better. But still nothing which requires a version bump imo. Can you point me to any new pom tag or attribute (and the corresponding ticket)? If there is none, then there is also no need to bump the version. Re the dependencyManagement clarifications: we might need at least a compatibility flag in the maven CLI to allow older projects to still build with their 'broken' poms. Just an idea... > Introduction of model version 4.1.0 > --- > > Key: MNG-6082 > URL: https://issues.apache.org/jira/browse/MNG-6082 > Project: Maven > Issue Type: New Feature >Reporter: Christian Schulte >Priority: Critical > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MNG-6082) Introduction of model version 4.1.0
[ https://issues.apache.org/jira/browse/MNG-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15746028#comment-15746028 ] Mark Struberg edited comment on MNG-6082 at 12/13/16 7:53 PM: -- *edit because it was too hard worded* just a general observation. Such a jira entry is extremely hard to read for any non-involved if it doesn't contain a summary about WHAT is supposed to get changed in 4.1.0! This is as bad as a "TODO fixme" without any notion about what's wrong... was (Author: struberg): just a general observation. Such a jira entry is imo totally bollocks and worth nothing if it doesn't contain a summary about WHAT is supposed to get changed in 4.1.0! This is as bad as a "TODO fixme" without any notion about what's wrong... > Introduction of model version 4.1.0 > --- > > Key: MNG-6082 > URL: https://issues.apache.org/jira/browse/MNG-6082 > Project: Maven > Issue Type: New Feature >Reporter: Christian Schulte >Priority: Critical > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-6082) Introduction of model version 4.1.0
[ https://issues.apache.org/jira/browse/MNG-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15746028#comment-15746028 ] Mark Struberg commented on MNG-6082: just a general observation. Such a jira entry is imo totally bollocks and worth nothing if it doesn't contain a summary about WHAT is supposed to get changed in 4.1.0! This is as bad as a "TODO fixme" without any notion about what's wrong... > Introduction of model version 4.1.0 > --- > > Key: MNG-6082 > URL: https://issues.apache.org/jira/browse/MNG-6082 > Project: Maven > Issue Type: New Feature >Reporter: Christian Schulte >Priority: Critical > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5649) Stop abusing IllegalArgumentException in case of null and use Guava's Preconditions
[
https://issues.apache.org/jira/browse/MNG-5649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14954676#comment-14954676
]
Mark Struberg commented on MNG-5649:
-1 for using Guava all over. I've used in in the past and it turned out to
introduce way more backward incompatibility headache than commons. And
IllegalArgumentException is btw much more explicit than a NullPointerException.
> Stop abusing IllegalArgumentException in case of null and use Guava's
> Preconditions
> ---
>
> Key: MNG-5649
> URL: https://issues.apache.org/jira/browse/MNG-5649
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 3.3.7
>
>
> In several spots of Maven Core, IAE is thrown where an argument is null. This
> should be turned into {{NullPointerException}} since JDK adheres to is and
> the
> [description|http://docs.oracle.com/javase/6/docs/api/java/lang/NullPointerException.html]
> of this exception indicates that and Effective Java does that too.
> I possible fix version could next minor: 3.3. Is no one is opposed it could
> even be 3.2.2.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] (MRELEASE-767) releasing flat multi-module projects using git
[ https://jira.codehaus.org/browse/MRELEASE-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg closed MRELEASE-767. -- Resolution: Fixed Fix Version/s: 2.5 indeed, thanks for testing it! > releasing flat multi-module projects using git > -- > > Key: MRELEASE-767 > URL: https://jira.codehaus.org/browse/MRELEASE-767 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.3.1 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800) > Maven home: /usr/share/maven > Java version: 1.6.0_31, vendor: Apple Inc. > Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home > Default locale: en_US, platform encoding: MacRoman > OS name: "mac os x", version: "10.7.4", arch: "x86_64", family: "mac" >Reporter: Jeremy Norris >Assignee: Mark Struberg > Fix For: 2.5 > > > When releasing a project as follows: > ./parent/pom.xml > ./module-a/pom.xml > ./module-b/pom.xml > From the parent directory, with an scm config in the parent pom.xml (only) as > follows: > > scm:git:ssh://github.com/repox.git > > scm:git:ssh://github.com/repox.git > master > https://github.com/view/repox.git > > In org/apache/maven/shared/release/util/ReleaseUtils.java:182 it does this > indiscriminately: > url = realignScmUrl( parentLevels, url ); > This will trim the repo url from 'ssh://github.com/repox.git' -> > 'ssh://github.com', which will cause a failure when pushing the tag. > This type of realignment is not appropriate when using a git scm type. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-740) Maven Release Plugin releases SNAPSHOT instead of STABLE version
[ https://jira.codehaus.org/browse/SCM-740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg closed SCM-740. - Resolution: Fixed Fix Version/s: 1.10 Assignee: Mark Struberg patch applied with small cleanup. Thanks for the patch, Jan! > Maven Release Plugin releases SNAPSHOT instead of STABLE version > > > Key: SCM-740 > URL: https://jira.codehaus.org/browse/SCM-740 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git > Environment: Everywhere with maven-scm-provider-gitexe of version 1.9 > (and maybe older) >Reporter: Jan Novotný >Assignee: Mark Struberg > Fix For: 1.10 > > Attachments: Wrong_base_directory_used1.patch > > > If you have following project structure: > - superproject [Git repository root] > - projectA [release target] > - projectB [release target] > in other words you release subproject of a larger Git repository separately, > you probably run at the same issue as we did. No recipe from above mentioned > sources solves your problems and during release:prepare phase still no commit > of stable pom.xml occurs. There is another bug in GitStatusConsumer class > that checks output of the git status --porcelain command and verifies > existency of the mentioned files on local filesystem. Regretfully it uses > working directory instead of git repository root as the base folder and thus > it constructs invalid path to the file where project folder directory is > duplicated. > Problem is better described here: > http://blog.novoj.net/2014/01/24/maven-release-plugin-releases-snapshot-instead-of-stable-version -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-207) file handle leak - leading to failed builds
[ https://jira.codehaus.org/browse/MCHECKSTYLE-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342256#comment-342256 ] Mark Struberg commented on MCHECKSTYLE-207: --- Any update on this, Dennis? Would like to include this for the next release. > file handle leak - leading to failed builds > --- > > Key: MCHECKSTYLE-207 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-207 > Project: Maven Checkstyle Plugin > Issue Type: Bug > Environment: Linux >Reporter: James Nord > Attachments: MCHECKSTYLE-207_PATCH_V1 (1).txt > > > The plugin sets the classpath to load as a URLClassloader populated with all > the URLs to the projects dependencies (jars) and output folders. > However the URLClassloader is never closed (only available in JDK1.7+) and > for a large multi-module project with a large number of dependencies this > leak can seriously add up (which if gc doesn't kick in at the right moment) > will lead to random failures due to java.io.IOException: error=24, Too many > open files. > see > http://svn.apache.org/viewvc/maven/plugins/tags/maven-checkstyle-plugin-2.11/src/main/java/org/apache/maven/plugin/checkstyle/DefaultCheckstyleExecutor.java?revision=1540890&view=markup > Line 162 where the URLClassloader is created - but never cleaned up. > The fix is relatively trivial if it is only to be fixed for 1.7+ JVMs (and > use reflection if need to be compatable with < 1.7). > Otherwise a custom classloader will be needed. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-89) java.lang.RuntimeException: Unable to get class information for XXXException
[ https://jira.codehaus.org/browse/MCHECKSTYLE-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg closed MCHECKSTYLE-89. Resolution: Not A Bug This is not a bug of the maven-checkstyle-plugin but might be a problem of checkstyle itself. You should be able to work around this by adding the dependency which contains the missing class to your > java.lang.RuntimeException: Unable to get class information for XXXException > > > Key: MCHECKSTYLE-89 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-89 > Project: Maven Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: Windows >Reporter: jreeman >Assignee: Mark Struberg > > When I execute mvn checkstyle:chekstyle I have the violations > java.lang.RuntimeException: Unable to get class information for > "ServletException". > The declaration of the ServletException in the javadoc comment is the reasons > of that violations. > In my pom, I tried to change javax.servlet scope to compile but the problem > remains. > I don't remember exactly in which case, but sometimes I have the same > violation for local exceptions. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-89) java.lang.RuntimeException: Unable to get class information for XXXException
[ https://jira.codehaus.org/browse/MCHECKSTYLE-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reassigned MCHECKSTYLE-89: Assignee: Mark Struberg > java.lang.RuntimeException: Unable to get class information for XXXException > > > Key: MCHECKSTYLE-89 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-89 > Project: Maven Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: Windows >Reporter: jreeman >Assignee: Mark Struberg > > When I execute mvn checkstyle:chekstyle I have the violations > java.lang.RuntimeException: Unable to get class information for > "ServletException". > The declaration of the ServletException in the javadoc comment is the reasons > of that violations. > In my pom, I tried to change javax.servlet scope to compile but the problem > remains. > I don't remember exactly in which case, but sometimes I have the same > violation for local exceptions. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-166) Drop @requiresDependencyResolution test
[
https://jira.codehaus.org/browse/MCHECKSTYLE-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg closed MCHECKSTYLE-166.
-
Resolution: Won't Fix
Assignee: Mark Struberg
The maven-checkstyle-plugin supports loading the checkstyle rule from a
dependency (see documentation about multi-module builds and creating a custom
build-tools.jar). For this to work we need to resolve the list of dependencies
first.
Please note that the dependency resolution itself does not cost much these days
anymore.
> Drop @requiresDependencyResolution test
> ---
>
> Key: MCHECKSTYLE-166
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-166
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.8
> Environment: N/A
>Reporter: Ernst de Haan
>Assignee: Mark Struberg
>Priority: Minor
>
> Currently, the
> [{{CheckstyleViolationCheckMojo}}|http://svn.apache.org/viewvc/maven/plugins/tags/maven-checkstyle-plugin-2.8/src/main/java/org/apache/maven/plugin/checkstyle/CheckstyleViolationCheckMojo.java?revision=1188083&view=markup]
> class declares:{code}@requiresDependencyResolution test{code}However, that
> should not be necessary. Checkstyle works on source files, not on bytecode.
> If this declaration would be removed, then this Checkstyle plugin should
> still work perfectly fine (I would expect without any further code changes).
> The advantage would be that in our Continuous Integration pipeline I can skip
> the _compile_ stage and immediately trigger the _checkstyle_ stage. That
> would save us multiple minutes on the feedback roundtrip.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-111) More information on issue: "Got an exception - java.lang.RuntimeException: Unable to get class information for [exception]"
[
https://jira.codehaus.org/browse/MCHECKSTYLE-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg closed MCHECKSTYLE-111.
-
Resolution: Not A Bug
Fix Version/s: 2.12
Assignee: Mark Struberg
Closing, as this is not a problem of the maven-checkstyle-plugin itself.
This happened to me as well when working with annotation processors, etc. In
this case simply add the framework dependency in question to the
worked for me.
> More information on issue: "Got an exception - java.lang.RuntimeException:
> Unable to get class information for [exception]"
> ---
>
> Key: MCHECKSTYLE-111
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-111
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Windows Vista Business (x64), Windows XP (x86), Windows
> 2003 Server (x86)
> Apache Maven 2.1.0 (r755702; 2009-03-18 20:10:27+0100) and Maven 2.0.10
> Java version: 1.6.0_13
>Reporter: Michael Grossniklaus
>Assignee: Mark Struberg
>Priority: Blocker
> Fix For: 2.12
>
> Attachments: maven-checkstyle-plugin.zip, output.txt
>
>
> This bug report provides more insight on the situations in which the
> maven-checkstyle-plugin is unable to get the class information for exceptions
> that are declared by the project. This report is, therefore, a refinement of
> prior bug reports such as MPCHECKSTYLE-1, MPCHECKSTYLE-20, or MCHECKSTYLE-54.
> We believe, however, that through a more in-depth study of the problem we can
> provide a narrower definition of the problem that, hopefully, will result in
> it resolution.
> Our experiments have shown that the maven-checkstyle-plugin fails for classes
> or interfaces that contain method signatures with a "throws" clause pointing
> to exception defined by both the project and elsewhere. This is demonstrated
> by the interface "ch.ethz.globis.demo.Demo" contained in the attached demo
> project.
> {{
> public interface Demo {
>void foo() throws DemoException, IOException, FileNotFoundException;
>void foofoo() throws DemoException;
>void bar() throws IOException, FileNotFoundException,
> IllegalArgumentException;
> }
> }}
> If the command "mvn checkstyle:check" is executed in the project, it will
> fail with one checkstyle violation. If, however, the method "foo()" is
> commented (or removed), everything works fine. Note that method "foofoo()"
> which *only* declares "ch.ethz.globis.demo.DemoException" is unproblematic as
> well as method "bar()" which declares a set of exceptions that are declared
> outside the project. Hence, the conclusion is that it is the combination of
> *both* project and outside-project exceptions that make the
> maven-checkstyle-plugin fail. Note that we have run maven on clean
> installation (where the local repository has been removed first) to produce a
> reproducible error.
> The attached zip file contains both the demo project that can be used to
> reproduce the error as well as the output of the "mvn checkstyle:check"
> command under "target". We also provide the file "output.txt" that documents
> the console output of the command. If further documentation is required, do
> not hesitate to contact me. We hope that by providing this information we can
> contribute to the resolution of said issue, once and for all.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-211) allow inline configuration for checkstyle plugin
[
https://jira.codehaus.org/browse/MCHECKSTYLE-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg closed MCHECKSTYLE-211.
-
Resolution: Fixed
Fix Version/s: 2.12
fixed in a similar way than suggested by Romain.
> allow inline configuration for checkstyle plugin
>
>
> Key: MCHECKSTYLE-211
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-211
> Project: Maven Checkstyle Plugin
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>Assignee: Mark Struberg
> Fix For: 2.12
>
> Attachments: CHECKSTYLE-inlineCDATA.patch,
> CHECKSTYLE-inlineCDATA.patch, CHECKSTYLE-inline.patch
>
>
> Make possible to not rely on an external module or file:
> {code}
>
> org.apache.maven.plugins
> maven-checkstyle-plugin
> @pom.version@
>
>
> check
> process-resources
>
> check
>
>
>
>
>
> Checker
>
>
> TreeWalker
>
>
> EmptyBlock
>
>
>
>
>
>
>
> {code}
> or (better) this one:
> {code}
>
> true
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-211) allow inline configuration for checkstyle plugin
[
https://jira.codehaus.org/browse/MCHECKSTYLE-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342205#comment-342205
]
Mark Struberg commented on MCHECKSTYLE-211:
---
Working on a way to implement this without the CDATA section.
> allow inline configuration for checkstyle plugin
>
>
> Key: MCHECKSTYLE-211
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-211
> Project: Maven Checkstyle Plugin
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>Assignee: Mark Struberg
> Attachments: CHECKSTYLE-inlineCDATA.patch,
> CHECKSTYLE-inlineCDATA.patch, CHECKSTYLE-inline.patch
>
>
> Make possible to not rely on an external module or file:
> {code}
>
> org.apache.maven.plugins
> maven-checkstyle-plugin
> @pom.version@
>
>
> check
> process-resources
>
> check
>
>
>
>
>
> Checker
>
>
> TreeWalker
>
>
> EmptyBlock
>
>
>
>
>
>
>
> {code}
> or (better) this one:
> {code}
>
> true
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-211) allow inline configuration for checkstyle plugin
[
https://jira.codehaus.org/browse/MCHECKSTYLE-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg reassigned MCHECKSTYLE-211:
-
Assignee: Mark Struberg
> allow inline configuration for checkstyle plugin
>
>
> Key: MCHECKSTYLE-211
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-211
> Project: Maven Checkstyle Plugin
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>Assignee: Mark Struberg
> Attachments: CHECKSTYLE-inlineCDATA.patch,
> CHECKSTYLE-inlineCDATA.patch, CHECKSTYLE-inline.patch
>
>
> Make possible to not rely on an external module or file:
> {code}
>
> org.apache.maven.plugins
> maven-checkstyle-plugin
> @pom.version@
>
>
> check
> process-resources
>
> check
>
>
>
>
>
> Checker
>
>
> TreeWalker
>
>
> EmptyBlock
>
>
>
>
>
>
>
> {code}
> or (better) this one:
> {code}
>
> true
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-211) allow inline configuration for checkstyle plugin
[
https://jira.codehaus.org/browse/MCHECKSTYLE-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341742#comment-341742
]
Mark Struberg commented on MCHECKSTYLE-211:
---
great idea. That way one can enable the checkstyle rules directly in the master
pom.
Will review and apply.
> allow inline configuration for checkstyle plugin
>
>
> Key: MCHECKSTYLE-211
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-211
> Project: Maven Checkstyle Plugin
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
> Attachments: CHECKSTYLE-inlineCDATA.patch,
> CHECKSTYLE-inlineCDATA.patch, CHECKSTYLE-inline.patch
>
>
> Make possible to not rely on an external module or file:
> {code}
>
> org.apache.maven.plugins
> maven-checkstyle-plugin
> @pom.version@
>
>
> check
> process-resources
>
> check
>
>
>
>
>
> Checker
>
>
> TreeWalker
>
>
> EmptyBlock
>
>
>
>
>
>
>
> {code}
> or (better) this one:
> {code}
>
> true
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SCM-714) mvn release:prepare fails if the command line is too long on windows
[ https://jira.codehaus.org/browse/SCM-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=323287#comment-323287 ] Mark Struberg commented on SCM-714: --- Hi Felix! Please note that scm:add != git-add and scm:checkin != git-commit maven-scm is intended to work the same way on every SCM. Thus we 'mimic' svn and cvs like operations. In the maven-release-manager we already do some special things for GIT. We'd need to There is of course an option to move the 'splitting' of git-add to an own function internally and utilize this from the other operations which need it. > mvn release:prepare fails if the command line is too long on windows > > > Key: SCM-714 > URL: https://jira.codehaus.org/browse/SCM-714 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.8.1 >Reporter: Felix Simmendinger >Priority: Blocker > > The issue from SCM-697 does not solve the issue as the gitprovider is not > using the add command but the checkin command during a release. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-538) mvn reactor:make-scm-changes fails for git provider with local git index
[
https://jira.codehaus.org/browse/SCM-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg closed SCM-538.
-
Resolution: Not A Bug
we still got no answer whether the url really was "file:.." or if the two dots
were just a placeholder for the real URL. Thus I'm closing this now as illegal.
> mvn reactor:make-scm-changes fails for git provider with local git index
>
>
> Key: SCM-538
> URL: https://jira.codehaus.org/browse/SCM-538
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-git
>Affects Versions: 1.3
> Environment: windows cygwin
>Reporter: Shankar Narayan
>Assignee: Mark Struberg
>
> I have the following scm connection setup
> {code:xml}
>
> scm:git:file:..
> scm:git:file:..
> scm:git:file:..
>
> {code}
> Regular {{mvn scm:*}} commands work fine.
> The maven reactor plugin seems to have a problem when I issue the following
> command:
> {{mvn -X reactor:make-scm-changes}}
> It complains about invalid scm url. The stack trace seems to point to the
> scm-provider.
> {noformat}
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Couldn't configure
> SCM repository: The scm url is invalid.
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.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:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.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: Couldn't configure
> SCM repository: The scm url is invalid.
> at
> org.apache.maven.plugin.reactor.MakeScmChanges.execute(MakeScmChanges.java:88)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> ... 17 more
> Caused by: org.apache.maven.scm.repository.ScmRepositoryException: The scm
> url is invalid.
> at
> org.apache.maven.scm.provider.git.AbstractGitScmProvider.makeProviderScmRepository(AbstractGitScmProvider.java:93)
> at
> org.apache.maven.scm.manager.AbstractScmManager.makeScmRepository(AbstractScmManager.java:192)
> at
> org.apache.maven.plugin.reactor.MakeScmChanges.execute(MakeScmChanges.java:83)
> ... 19 more
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-831) sometimes the version suggestion for the SCM tag doesnt work in release:prepare
[
https://jira.codehaus.org/browse/MRELEASE-831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322043#comment-322043
]
Mark Struberg commented on MRELEASE-831:
nope, the release version is 1.1.8 as with all other modules.
> sometimes the version suggestion for the SCM tag doesnt work in
> release:prepare
> ---
>
> Key: MRELEASE-831
> URL: https://jira.codehaus.org/browse/MRELEASE-831
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.4
>Reporter: Mark Struberg
>Priority: Minor
>
> {noformat}
> What is the release version for "Documentation"?
> (org.apache.openwebbeans:openwebbeans-doc) 1.1.8: :
> What is the release version for "OWB Arquillian Parent"?
> (org.apache.openwebbeans.arquillian:owb-arquillian-parent) 1.1.8: :
> What is the release version for "OpenWebBeans-Standalone Arquillian
> connector"? (org.apache.openwebbeans.arquillian:owb-arquillian-standalone)
> 1.1.8: :
> What is SCM release tag or label for "Apache OpenWebBeans"?
> (org.apache.openwebbeans:openwebbeans) openwebbeans-j: : openwebbeans-1.1.8
> What is the new development version for "Apache OpenWebBeans"?
> (org.apache.openwebbeans:openwebbeans) 1.1-SNAPSHOT: :
> What is the new development version for "SPI definition"?
> (org.apache.openwebbeans:openwebbeans-spi) 1.1.9-SNAPSHOT: :
> What is the new development version for "OpenWebBeans Core"?
> (org.apache.openwebbeans:openwebbeans-impl) 1.1.9-SNAPSHOT: :
> {noformat}
> See the 'openwebbeans-j' suggestion. I overwrote it manually to
> {{openwebbeans-1.1.8}} and also got a broken 'next' version. but only for the
> main module.
> All was fine again after a {{mvn release:rollback}} and doing
> {{release:prepare}} again
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-831) sometimes the version suggestion for the SCM tag doesnt work in release:prepare
Mark Struberg created MRELEASE-831: -- Summary: sometimes the version suggestion for the SCM tag doesnt work in release:prepare Key: MRELEASE-831 URL: https://jira.codehaus.org/browse/MRELEASE-831 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.4 Reporter: Mark Struberg What is the release version for "Documentation"? (org.apache.openwebbeans:openwebbeans-doc) 1.1.8: : What is the release version for "OWB Arquillian Parent"? (org.apache.openwebbeans.arquillian:owb-arquillian-parent) 1.1.8: : What is the release version for "OpenWebBeans-Standalone Arquillian connector"? (org.apache.openwebbeans.arquillian:owb-arquillian-standalone) 1.1.8: : What is SCM release tag or label for "Apache OpenWebBeans"? (org.apache.openwebbeans:openwebbeans) openwebbeans-j: : openwebbeans-1.1.8 What is the new development version for "Apache OpenWebBeans"? (org.apache.openwebbeans:openwebbeans) 1.1-SNAPSHOT: : What is the new development version for "SPI definition"? (org.apache.openwebbeans:openwebbeans-spi) 1.1.9-SNAPSHOT: : What is the new development version for "OpenWebBeans Core"? (org.apache.openwebbeans:openwebbeans-impl) 1.1.9-SNAPSHOT: : See the 'openwebbeans-j' suggestion. I overwrote it manually to openwebbeans-1.1.8 and also got a broken 'next' version. but only for the main module. All was fine again after a mvn release:rollback and doing release:prepare again -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-777) release plugin shouldn't git clone if the SCM is git
[ https://jira.codehaus.org/browse/MRELEASE-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317646#comment-317646 ] Mark Struberg commented on MRELEASE-777: yes, looks you don't do a localCheckout at all somehow. You should get a file:// URL. > release plugin shouldn't git clone if the SCM is git > > > Key: MRELEASE-777 > URL: https://jira.codehaus.org/browse/MRELEASE-777 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Environment: Linux x86_64, maven 2.2.1 >Reporter: Joel Orlina >Assignee: Mark Struberg > > See here for original issue: > https://issues.sonatype.org/browse/MVNCENTRAL-202 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-777) release plugin shouldn't git clone if the SCM is git
[ https://jira.codehaus.org/browse/MRELEASE-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317644#comment-317644 ] Mark Struberg commented on MRELEASE-777: being a GIT user/contributor since 2006 I can tell you that GIT is smart enough to _not_ copy files over. Instead GIT automatically does only reference the local origin repo without copying any files. So this really is the best option, because this is the only one which is really portable. please check the -l option man git-clone We explicitely don't use git-clone -s as we cannot guarantee that a user doesn't do any weirdo stuff in the cloned repo which would break upstream... Also consider that the maven-release-manager simply does a 'scm checkout' on all SCMs. Thus in order to remain portable we just provided the local file:// URL which is known to work with all distributed SCMs without having to do some special hacks. A local git-clone of a 4GB git repo takes way sub-second... I really see no reason to further improve this. PS: being busy with a big refactoring in Apache OpenWebBeans atm, hope to be back working on the incremental and SCM stuff in about 2 weeks. > release plugin shouldn't git clone if the SCM is git > > > Key: MRELEASE-777 > URL: https://jira.codehaus.org/browse/MRELEASE-777 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Environment: Linux x86_64, maven 2.2.1 >Reporter: Joel Orlina >Assignee: Mark Struberg > > See here for original issue: > https://issues.sonatype.org/browse/MVNCENTRAL-202 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-777) release plugin shouldn't git clone if the SCM is git
[ https://jira.codehaus.org/browse/MRELEASE-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317639#comment-317639 ] Mark Struberg commented on MRELEASE-777: hi Fred! If you use GIT, then please use the following config options truefalse release plugin shouldn't git clone if the SCM is git > > > Key: MRELEASE-777 > URL: https://jira.codehaus.org/browse/MRELEASE-777 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Environment: Linux x86_64, maven 2.2.1 >Reporter: Joel Orlina >Assignee: Mark Struberg > > See here for original issue: > https://issues.sonatype.org/browse/MVNCENTRAL-202 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-236) Refactor utility classes of shared components into an own utility package
[ https://jira.codehaus.org/browse/MSHARED-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg closed MSHARED-236. - Resolution: Fixed Fix Version/s: maven-shared-utils-0.1 Almost all important p-u classes are now either moved from other modules,IP clean imported by their original authors or got rewritten. > Refactor utility classes of shared components into an own utility package > - > > Key: MSHARED-236 > URL: https://jira.codehaus.org/browse/MSHARED-236 > Project: Maven Shared Components > Issue Type: Bug >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: maven-shared-utils-0.1 > > Attachments: MSHARED-236-krosenvold-original-work.patch > > > DirectoryScanner in maven-verifier is one example. > We should introcude a new shared-utils module which doesn't contain any > external dependencies if possible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-252) drop XmlReader and only use XmlStreamReader
[ https://jira.codehaus.org/browse/MSHARED-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg closed MSHARED-252. - Resolution: Fixed Fix Version/s: maven-shared-utils-0.1 > drop XmlReader and only use XmlStreamReader > --- > > Key: MSHARED-252 > URL: https://jira.codehaus.org/browse/MSHARED-252 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-shared-utils >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: maven-shared-utils-0.1 > > > XmlReader is a left-over from a refactoring. Oringinally there have been a > XmlWriter too. But due to build conflicts with the class XMLWriter (on > windows boxes) it got renamed to XmlStreamWriter and XmlReader got duplicated. > Thus we should now get rid of XmlReader and only use XmlStreamReader instead > to be more consistent -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-238) [DirectoryScanner] introduce a way to abort scanning if a certain criteria is met
[ https://jira.codehaus.org/browse/MSHARED-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg closed MSHARED-238. - Resolution: Fixed Fix Version/s: maven-shared-utils-0.1 > [DirectoryScanner] introduce a way to abort scanning if a certain criteria is > met > - > > Key: MSHARED-238 > URL: https://jira.codehaus.org/browse/MSHARED-238 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-shared-utils >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: maven-shared-utils-0.1 > > > The DirectoryScanner in plexus always scans the full directory tree. > If you e.g. only want to scan if any file is newer than a given date, then > you can immediately abort this processing. > By introducing a ScanConductor which might get used, we allow much more fine > grained control over the scanning. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-238) [DirectoryScanner] introduce a way to abort scanning if a certain criteria is met
[ https://jira.codehaus.org/browse/MSHARED-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated MSHARED-238: -- Component/s: maven-shared-utils > [DirectoryScanner] introduce a way to abort scanning if a certain criteria is > met > - > > Key: MSHARED-238 > URL: https://jira.codehaus.org/browse/MSHARED-238 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-shared-utils >Reporter: Mark Struberg >Assignee: Mark Struberg > > The DirectoryScanner in plexus always scans the full directory tree. > If you e.g. only want to scan if any file is newer than a given date, then > you can immediately abort this processing. > By introducing a ScanConductor which might get used, we allow much more fine > grained control over the scanning. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-252) drop XmlReader and only use XmlStreamReader
Mark Struberg created MSHARED-252: - Summary: drop XmlReader and only use XmlStreamReader Key: MSHARED-252 URL: https://jira.codehaus.org/browse/MSHARED-252 Project: Maven Shared Components Issue Type: Bug Components: maven-shared-utils Reporter: Mark Struberg XmlReader is a left-over from a refactoring. Oringinally there have been a XmlWriter too. But due to build conflicts with the class XMLWriter (on windows boxes) it got renamed to XmlStreamWriter and XmlReader got duplicated. Thus we should now get rid of XmlReader and only use XmlStreamReader instead to be more consistent -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-252) drop XmlReader and only use XmlStreamReader
[ https://jira.codehaus.org/browse/MSHARED-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reassigned MSHARED-252: - Assignee: Mark Struberg > drop XmlReader and only use XmlStreamReader > --- > > Key: MSHARED-252 > URL: https://jira.codehaus.org/browse/MSHARED-252 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-shared-utils >Reporter: Mark Struberg >Assignee: Mark Struberg > > XmlReader is a left-over from a refactoring. Oringinally there have been a > XmlWriter too. But due to build conflicts with the class XMLWriter (on > windows boxes) it got renamed to XmlStreamWriter and XmlReader got duplicated. > Thus we should now get rid of XmlReader and only use XmlStreamReader instead > to be more consistent -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-777) release plugin shouldn't git clone if the SCM is git
[ https://jira.codehaus.org/browse/MRELEASE-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg closed MRELEASE-777. -- Resolution: Not A Bug There are config options for this exact scenario true false section of the maven-release-plugin. Here is the explanation why: http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html > release plugin shouldn't git clone if the SCM is git > > > Key: MRELEASE-777 > URL: https://jira.codehaus.org/browse/MRELEASE-777 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Environment: Linux x86_64, maven 2.2.1 >Reporter: Joel Orlina >Assignee: Mark Struberg > > See here for original issue: > https://issues.sonatype.org/browse/MVNCENTRAL-202 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-179) Warnings
[
https://jira.codehaus.org/browse/MCOMPILER-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=309531#comment-309531
]
Mark Struberg commented on MCOMPILER-179:
-
temporarily set plexus-compiler back to 1.9.1
All IT are passing now.
> Warnings
> -
>
> Key: MCOMPILER-179
> URL: https://jira.codehaus.org/browse/MCOMPILER-179
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.4, 2.5, 2.5.1
> Environment: Windows7, 64-bit
> VMs, 1.6.0_32 and 1.7.0_04 both 64-bit
>Reporter: Sascha Vogt
>Assignee: Kristian Rosenvold
> Fix For: 2.6
>
>
> If one error occurs, all warnings are shown as error as well. Up to {{2.3.2}}
> this was not the case. Sample output {{2.4}} and higher:
> {noformat}
> [INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR] bad path element "": no such file or directory
> C:\dev-tmp\sample\src\main\java\de\maybebuggy\sample\Main.java:[19,18]
> [unchecked] unchecked call to add(E) as a member of the raw type
> java.util.List
> [ERROR]
> C:\dev-tmp\sample\src\main\java\de\maybebuggy\sample\Main.java:[20,18]
> [unchecked] unchecked call to add(E) as a member of the raw type
> java.util.List
> [ERROR]
> C:\dev-tmp\sample\src\main\java\de\maybebuggy\sample\Main.java:[24,15]
> [unchecked] unchecked conversion
> found : java.util.List
> required: java.util.List
> [ERROR]
> C:\dev-tmp\sample\src\main\java\de\maybebuggy\sample\Main.java:[29,29]
> getList() in de.maybebuggy.sample.Main cannot be applied to (int)
> [INFO] 4 errors
> {noformat}
> Sample output {{2.3.2}}:
> {noformat}
> [INFO] -
> [WARNING] COMPILATION WARNING :
> [INFO] -
> [WARNING]
> \dev-tmp\sample\src\main\java\de\maybebuggy\sample\Main.java:[19,18]
> [unchecked] unchecked call to add(E) as a member of the raw type
> java.util.List
> [WARNING]
> \dev-tmp\sample\src\main\java\de\maybebuggy\sample\Main.java:[20,18]
> [unchecked] unchecked call to add(E) as a member of the raw type
> java.util.List
> [WARNING]
> \dev-tmp\sample\src\main\java\de\maybebuggy\sample\Main.java:[24,15]
> [unchecked] unchecked conversion
> found : java.util.List
> required: java.util.List
> [INFO] 3 warnings
> [INFO] -
> [INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> \dev-tmp\sample\src\main\java\de\maybebuggy\sample\Main.java:[29,29]
> getList() in de.maybebuggy.sample.Main cannot be applied to (int)
> [INFO] 1 error
> [INFO] -
> {noformat}
> With the current behavior it is extremely hard to spot the error if there are
> multiple warnings in a project.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-244) Add EMPTY_xxxx_ARRAY from commons-lang to our CollectionsUtils
[ https://jira.codehaus.org/browse/MSHARED-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=309491#comment-309491 ] Mark Struberg commented on MSHARED-244: --- yes, commons is really good in those regards. But that doesn't help you if we use a method from a newer commons release and some plugin adds in an old jar which doesnt have this method. I think we still do client-Classloader-first in maven. So I expect a few "Class X cannot be cast to Class X". We would need to check, but I have a bad gut feeling. > Add EMPTY__ARRAY from commons-lang to our CollectionsUtils > -- > > Key: MSHARED-244 > URL: https://jira.codehaus.org/browse/MSHARED-244 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-shared-utils >Reporter: Mark Struberg >Assignee: Mark Struberg > > There are a lot of Classes which need constants for empty arrays like > String[0]. > We shall add such constants to our CollectionUtils. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-244) Add EMPTY_xxxx_ARRAY from commons-lang to our CollectionsUtils
[ https://jira.codehaus.org/browse/MSHARED-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=309477#comment-309477 ] Mark Struberg commented on MSHARED-244: --- The reason is pretty simple: binary compatibility! There are quite some different versions of various commons-*, logger APIs etc around. Not all of those versions are binary compatible. In some plugins and all of maven-core we do not know which other dependencies end up in the chain. Imagine what would happen if a commons-lang.jar is available in both a custom plugin dependency and in maven core. We could end up with those funny "Class X cannot be cast to Class X" errors. > Add EMPTY__ARRAY from commons-lang to our CollectionsUtils > -- > > Key: MSHARED-244 > URL: https://jira.codehaus.org/browse/MSHARED-244 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-shared-utils >Reporter: Mark Struberg >Assignee: Mark Struberg > > There are a lot of Classes which need constants for empty arrays like > String[0]. > We shall add such constants to our CollectionUtils. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-245) add IncrementalBuildHelper
[ https://jira.codehaus.org/browse/MSHARED-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=309441#comment-309441 ] Mark Struberg commented on MSHARED-245: --- initial version committed in r1388456. Tests are still missing. > add IncrementalBuildHelper > -- > > Key: MSHARED-245 > URL: https://jira.codehaus.org/browse/MSHARED-245 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-shared-incremental >Reporter: Mark Struberg > > add a module and utility class to make incremental builds easier. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-245) add IncrementalBuildHelper
Mark Struberg created MSHARED-245: - Summary: add IncrementalBuildHelper Key: MSHARED-245 URL: https://jira.codehaus.org/browse/MSHARED-245 Project: Maven Shared Components Issue Type: New Feature Components: maven-shared-incremental Reporter: Mark Struberg add a module and utility class to make incremental builds easier. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-244) Add EMPTY_xxxx_ARRAY from commons-lang to our CollectionsUtils
[ https://jira.codehaus.org/browse/MSHARED-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg closed MSHARED-244. - Resolution: Fixed fixed in r1388452 by adding an ArrayUtils class with the constants taken from commons-lang. > Add EMPTY__ARRAY from commons-lang to our CollectionsUtils > -- > > Key: MSHARED-244 > URL: https://jira.codehaus.org/browse/MSHARED-244 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-shared-utils >Reporter: Mark Struberg >Assignee: Mark Struberg > > There are a lot of Classes which need constants for empty arrays like > String[0]. > We shall add such constants to our CollectionUtils. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-244) Add EMPTY_xxxx_ARRAY from commons-lang to our CollectionsUtils
[ https://jira.codehaus.org/browse/MSHARED-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reassigned MSHARED-244: - Assignee: Mark Struberg > Add EMPTY__ARRAY from commons-lang to our CollectionsUtils > -- > > Key: MSHARED-244 > URL: https://jira.codehaus.org/browse/MSHARED-244 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-shared-utils >Reporter: Mark Struberg >Assignee: Mark Struberg > > There are a lot of Classes which need constants for empty arrays like > String[0]. > We shall add such constants to our CollectionUtils. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-244) Add EMPTY_xxxx_ARRAY from commons-lang to our CollectionsUtils
Mark Struberg created MSHARED-244: - Summary: Add EMPTY__ARRAY from commons-lang to our CollectionsUtils Key: MSHARED-244 URL: https://jira.codehaus.org/browse/MSHARED-244 Project: Maven Shared Components Issue Type: New Feature Components: maven-shared-utils Reporter: Mark Struberg There are a lot of Classes which need constants for empty arrays like String[0]. We shall add such constants to our CollectionUtils. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-243) add a way to calculate diffs of a directory at 2 different times
[ https://jira.codehaus.org/browse/MSHARED-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg closed MSHARED-243. - Resolution: Fixed Implemented in DirectoryScanner#diffIncludedFiles( String[] oldFiles ); This method returns a ScanResult which currently contains the lists of added and removed files. > add a way to calculate diffs of a directory at 2 different times > > > Key: MSHARED-243 > URL: https://jira.codehaus.org/browse/MSHARED-243 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-shared-utils >Reporter: Mark Struberg >Assignee: Mark Struberg > > For implementing the incremental build it should be possible to detect which > files got created by a certain mojo execution. > An example would be the maven-compiler-plugin which currently doesn't remove > class files for Java sources which got deleted. > The idea is to introduce a helper which can capture a snapshot of a certain > directory (e.g. target/classes), then you do the mojo work (javac invocation > with all source files) and take a capture of that very directory again. > The tool will allow you to take a 'diff' and store the names of all the added > files to a file in target/... > The next time you invoke a build you can delete all those created classes by > this very mojo-execution and so you do not have any left-overs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-243) add a way to calculate diffs of a directory at 2 different times
[ https://jira.codehaus.org/browse/MSHARED-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reassigned MSHARED-243: - Assignee: Mark Struberg > add a way to calculate diffs of a directory at 2 different times > > > Key: MSHARED-243 > URL: https://jira.codehaus.org/browse/MSHARED-243 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-shared-utils >Reporter: Mark Struberg >Assignee: Mark Struberg > > For implementing the incremental build it should be possible to detect which > files got created by a certain mojo execution. > An example would be the maven-compiler-plugin which currently doesn't remove > class files for Java sources which got deleted. > The idea is to introduce a helper which can capture a snapshot of a certain > directory (e.g. target/classes), then you do the mojo work (javac invocation > with all source files) and take a capture of that very directory again. > The tool will allow you to take a 'diff' and store the names of all the added > files to a file in target/... > The next time you invoke a build you can delete all those created classes by > this very mojo-execution and so you do not have any left-overs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-863) NPE in ConcurrentReporterManager
[ https://jira.codehaus.org/browse/SUREFIRE-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308764#comment-308764 ] Mark Struberg commented on SUREFIRE-863: Yes, I can try this. Just gimme a few days please - and remind me again :) > NPE in ConcurrentReporterManager > > > Key: SUREFIRE-863 > URL: https://jira.codehaus.org/browse/SUREFIRE-863 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.12 >Reporter: Mark Struberg > Fix For: 2.13 > > Attachments: SUREFIRE-863.patch > > > I have a wird NPE in surefire with one of my projects: > Caused by: java.lang.NullPointerException > at > java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768) > at > org.apache.maven.surefire.junitcore.ConcurrentReporterManager.getTestSet(ConcurrentReporterManager.java:157) > at > org.apache.maven.surefire.junitcore.ConcurrentReporterManager.getOrCreateTestMethod(ConcurrentReporterManager.java:127) > at > org.apache.maven.surefire.junitcore.ConcurrentReporterManager.testError(ConcurrentReporterManager.java:83) > at > org.apache.maven.surefire.common.junit4.JUnit4RunListener.testFailure(JUnit4RunListener.java:110) > at > org.junit.runner.notification.RunNotifier$4.notifyListener(RunNotifier.java:100) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-243) add a way to calculate diffs of a directory at 2 different times
Mark Struberg created MSHARED-243: - Summary: add a way to calculate diffs of a directory at 2 different times Key: MSHARED-243 URL: https://jira.codehaus.org/browse/MSHARED-243 Project: Maven Shared Components Issue Type: New Feature Components: maven-shared-utils Reporter: Mark Struberg For implementing the incremental build it should be possible to detect which files got created by a certain mojo execution. An example would be the maven-compiler-plugin which currently doesn't remove class files for Java sources which got deleted. The idea is to introduce a helper which can capture a snapshot of a certain directory (e.g. target/classes), then you do the mojo work (javac invocation with all source files) and take a capture of that very directory again. The tool will allow you to take a 'diff' and store the names of all the added files to a file in target/... The next time you invoke a build you can delete all those created classes by this very mojo-execution and so you do not have any left-overs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-133) Facing OutOfMemory as IsolatedClassloader (plexus-compiler jar) is not closed after JavacCompiler is done with compilation.
[ https://jira.codehaus.org/browse/MCOMPILER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308503#comment-308503 ] Mark Struberg commented on MCOMPILER-133: - agree, setting to wont-fix > Facing OutOfMemory as IsolatedClassloader (plexus-compiler jar) is not closed > after JavacCompiler is done with compilation. > --- > > Key: MCOMPILER-133 > URL: https://jira.codehaus.org/browse/MCOMPILER-133 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug > Environment: Windows 2003 Server >Reporter: kaniska >Priority: Blocker > Attachments: IsolatedClassLoader_Issue.docx > > > In Eclipse environment for a maven-based project, Auto-build fires > Maven-build which in turn executes CompilerMojo, finally creating an > IsolatedClassloader for each compile call ! > IsolatedClassLoader.addURL(URL) line: 42... > JavacCompiler.compile(CompilerConfiguration) line: 141 > CompilerMojo(AbstractCompilerMojo).execute() line: 493... > DefaultBuildPluginManager.executeMojo(MavenSession, MojoExecution) line: > 105... > MavenImpl.execute(MavenExecutionRequest, IProgressMonitor) ... > MavenBuilder.build(int, Map, IProgressMonitor) line: 153 > AutoBuildJob.run(IProgressMonitor) line: 238 > So every single change in maven-v4 project creates a new IsolatedClassloader > which is fine. > But the problem is JavacCompiler is not closing the loader which holds huge > number of jars (url points to maven-repo) in its url classpath. > It should use ClassLoaderutil.releaseLoader(..) to unload the jars. > GC does not reclaim the isolatedclassloader instances (not sure why). > As a result, IsolatedClassloader instances consume retains the heap. > Eventually maven-application goes OutOfMemory ! > Attached is the heapdump analysis of isolatedclassloader that holds the > memory. > This is kind of blocking us from building largescale maven app which requires > good number of jars in development time for compiling the app source at > development time. > Please note that we face this issue at development time whenever developer > making changes in source code as explained in the code-flow above. > Please let us know if more information is required. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-133) Facing OutOfMemory as IsolatedClassloader (plexus-compiler jar) is not closed after JavacCompiler is done with compilation.
[ https://jira.codehaus.org/browse/MCOMPILER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg closed MCOMPILER-133. --- Resolution: Won't Fix > Facing OutOfMemory as IsolatedClassloader (plexus-compiler jar) is not closed > after JavacCompiler is done with compilation. > --- > > Key: MCOMPILER-133 > URL: https://jira.codehaus.org/browse/MCOMPILER-133 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug > Environment: Windows 2003 Server >Reporter: kaniska >Priority: Blocker > Attachments: IsolatedClassLoader_Issue.docx > > > In Eclipse environment for a maven-based project, Auto-build fires > Maven-build which in turn executes CompilerMojo, finally creating an > IsolatedClassloader for each compile call ! > IsolatedClassLoader.addURL(URL) line: 42... > JavacCompiler.compile(CompilerConfiguration) line: 141 > CompilerMojo(AbstractCompilerMojo).execute() line: 493... > DefaultBuildPluginManager.executeMojo(MavenSession, MojoExecution) line: > 105... > MavenImpl.execute(MavenExecutionRequest, IProgressMonitor) ... > MavenBuilder.build(int, Map, IProgressMonitor) line: 153 > AutoBuildJob.run(IProgressMonitor) line: 238 > So every single change in maven-v4 project creates a new IsolatedClassloader > which is fine. > But the problem is JavacCompiler is not closing the loader which holds huge > number of jars (url points to maven-repo) in its url classpath. > It should use ClassLoaderutil.releaseLoader(..) to unload the jars. > GC does not reclaim the isolatedclassloader instances (not sure why). > As a result, IsolatedClassloader instances consume retains the heap. > Eventually maven-application goes OutOfMemory ! > Attached is the heapdump analysis of isolatedclassloader that holds the > memory. > This is kind of blocking us from building largescale maven app which requires > good number of jars in development time for compiling the app source at > development time. > Please note that we face this issue at development time whenever developer > making changes in source code as explained in the code-flow above. > Please let us know if more information is required. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-242) [shared-utils] improve shared utils featuers and introduce generics where possible
Mark Struberg created MSHARED-242: - Summary: [shared-utils] improve shared utils featuers and introduce generics where possible Key: MSHARED-242 URL: https://jira.codehaus.org/browse/MSHARED-242 Project: Maven Shared Components Issue Type: Bug Reporter: Mark Struberg Lots of the shared-utils stuff is still java-1.3 style. Should get some 1.5++ polishing and new features. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-239) replace plexus-utils with maven-shared-utils
[
https://jira.codehaus.org/browse/MSHARED-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=307523#comment-307523
]
Mark Struberg commented on MSHARED-239:
---
If you find a utility which is yet missing, then ping back and we add them to
MSHARED-236.
> replace plexus-utils with maven-shared-utils
>
>
> Key: MSHARED-239
> URL: https://jira.codehaus.org/browse/MSHARED-239
> Project: Maven Shared Components
> Issue Type: Task
>Reporter: Mark Struberg
>
> This task actually concerns quite a few components:
> # maven-core
> # maven-shared
> # wagon
> # maven-scm
> ...
> Please note that we do not yet have a Xpp3 replacement, so we cannot remove
> plexus-utils in the modules which need xppe.
> To determine if an upgrade is needed you can use the following quick shell
> command
> {code}
> find . -name "*.java" -exec grep -H "import org.codehaus.plexus.util" {} \; |
> grep -v xpp3 |less
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-239) replace plexus-utils with maven-shared-utils
Mark Struberg created MSHARED-239:
-
Summary: replace plexus-utils with maven-shared-utils
Key: MSHARED-239
URL: https://jira.codehaus.org/browse/MSHARED-239
Project: Maven Shared Components
Issue Type: Task
Reporter: Mark Struberg
This task actually concerns quite a few components:
# maven-core
# maven-shared
# wagon
# maven-scm
...
Please note that we do not yet have a Xpp3 replacement, so we cannot remove
plexus-utils in the modules which need xppe.
To determine if an upgrade is needed you can use the following quick shell
command
{code}
find . -name "*.java" -exec grep -H "import org.codehaus.plexus.util" {} \; |
grep -v xpp3 |less
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-236) Refactor utility classes of shared components into an own utility package
[ https://jira.codehaus.org/browse/MSHARED-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated MSHARED-236: -- Attachment: MSHARED-236-krosenvold-original-work.patch Christian, as you are the original author, with nothing changed otherwise - can you please import those classes into maven-shared-utils and update the license header to our ASF standard one? txs! A maven-shared-utils/src/main/java/org/apache/maven/shared/utils/cli/CommandLineCallable.java A maven-shared-utils/src/main/java/org/apache/maven/shared/utils/cli/AbstractStreamHandler.java A maven-shared-utils/src/main/java/org/apache/maven/shared/utils/cli/ShutdownHookUtils.java > Refactor utility classes of shared components into an own utility package > - > > Key: MSHARED-236 > URL: https://jira.codehaus.org/browse/MSHARED-236 > Project: Maven Shared Components > Issue Type: Bug >Reporter: Mark Struberg >Assignee: Mark Struberg > Attachments: MSHARED-236-krosenvold-original-work.patch > > > DirectoryScanner in maven-verifier is one example. > We should introcude a new shared-utils module which doesn't contain any > external dependencies if possible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-238) [DirectoryScanner] introduce a way to abort scanning if a certain criteria is met
[ https://jira.codehaus.org/browse/MSHARED-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=307392#comment-307392 ] Mark Struberg commented on MSHARED-238: --- Initial commit done in r1378655 > [DirectoryScanner] introduce a way to abort scanning if a certain criteria is > met > - > > Key: MSHARED-238 > URL: https://jira.codehaus.org/browse/MSHARED-238 > Project: Maven Shared Components > Issue Type: Improvement >Reporter: Mark Struberg >Assignee: Mark Struberg > > The DirectoryScanner in plexus always scans the full directory tree. > If you e.g. only want to scan if any file is newer than a given date, then > you can immediately abort this processing. > By introducing a ScanConductor which might get used, we allow much more fine > grained control over the scanning. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-238) [DirectoryScanner] introduce a way to abort scanning if a certain criteria is met
[ https://jira.codehaus.org/browse/MSHARED-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reassigned MSHARED-238: - Assignee: Mark Struberg > [DirectoryScanner] introduce a way to abort scanning if a certain criteria is > met > - > > Key: MSHARED-238 > URL: https://jira.codehaus.org/browse/MSHARED-238 > Project: Maven Shared Components > Issue Type: Improvement >Reporter: Mark Struberg >Assignee: Mark Struberg > > The DirectoryScanner in plexus always scans the full directory tree. > If you e.g. only want to scan if any file is newer than a given date, then > you can immediately abort this processing. > By introducing a ScanConductor which might get used, we allow much more fine > grained control over the scanning. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-238) [DirectoryScanner] introduce a way to abort scanning if a certain criteria is met
Mark Struberg created MSHARED-238: - Summary: [DirectoryScanner] introduce a way to abort scanning if a certain criteria is met Key: MSHARED-238 URL: https://jira.codehaus.org/browse/MSHARED-238 Project: Maven Shared Components Issue Type: Improvement Reporter: Mark Struberg The DirectoryScanner in plexus always scans the full directory tree. If you e.g. only want to scan if any file is newer than a given date, then you can immediately abort this processing. By introducing a ScanConductor which might get used, we allow much more fine grained control over the scanning. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-237) upgrade ApacheLicense 1.1 to 2.0 for some leftovers
[
https://jira.codehaus.org/browse/MSHARED-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg closed MSHARED-237.
-
Resolution: Fixed
Checked the prevenience and updated the license headers. All the files were
forks of Ant files which got upgraded to ALv2 in ant a long time ago
> upgrade ApacheLicense 1.1 to 2.0 for some leftovers
>
>
> Key: MSHARED-237
> URL: https://jira.codehaus.org/browse/MSHARED-237
> Project: Maven Shared Components
> Issue Type: Task
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>
> A few of our sources in our SVN repo which are explicitely noted as
> {quote}
> * Copyright (c) 2000-2003 The Apache Software Foundation. All rights
> * reserved.
> {quote}
> do still have the old 1.1 license header. Those classes are all forked out of
> ant which moved to ALv2.0 a long time ago. I'll update these headers
> accordingly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-237) upgrade ApacheLicense 1.1 to 2.0 for some leftovers
[
https://jira.codehaus.org/browse/MSHARED-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg reassigned MSHARED-237:
-
Assignee: Mark Struberg
> upgrade ApacheLicense 1.1 to 2.0 for some leftovers
>
>
> Key: MSHARED-237
> URL: https://jira.codehaus.org/browse/MSHARED-237
> Project: Maven Shared Components
> Issue Type: Task
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>
> A few of our sources in our SVN repo which are explicitely noted as
> {quote}
> * Copyright (c) 2000-2003 The Apache Software Foundation. All rights
> * reserved.
> {quote}
> do still have the old 1.1 license header. Those classes are all forked out of
> ant which moved to ALv2.0 a long time ago. I'll update these headers
> accordingly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-237) upgrade ApacheLicense 1.1 to 2.0 for some leftovers
Mark Struberg created MSHARED-237:
-
Summary: upgrade ApacheLicense 1.1 to 2.0 for some leftovers
Key: MSHARED-237
URL: https://jira.codehaus.org/browse/MSHARED-237
Project: Maven Shared Components
Issue Type: Task
Reporter: Mark Struberg
A few of our sources in our SVN repo which are explicitely noted as
{quote}
* Copyright (c) 2000-2003 The Apache Software Foundation. All rights
* reserved.
{quote}
do still have the old 1.1 license header. Those classes are all forked out of
ant which moved to ALv2.0 a long time ago. I'll update these headers
accordingly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-236) Refactor utility classes of shared components into an own utility package
[ https://jira.codehaus.org/browse/MSHARED-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reassigned MSHARED-236: - Assignee: Mark Struberg > Refactor utility classes of shared components into an own utility package > - > > Key: MSHARED-236 > URL: https://jira.codehaus.org/browse/MSHARED-236 > Project: Maven Shared Components > Issue Type: Bug >Reporter: Mark Struberg >Assignee: Mark Struberg > > DirectoryScanner in maven-verifier is one example. > We should introcude a new shared-utils module which doesn't contain any > external dependencies if possible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-236) Refactor utility classes of shared components into an own utility package
Mark Struberg created MSHARED-236: - Summary: Refactor utility classes of shared components into an own utility package Key: MSHARED-236 URL: https://jira.codehaus.org/browse/MSHARED-236 Project: Maven Shared Components Issue Type: Bug Reporter: Mark Struberg DirectoryScanner in maven-verifier is one example. We should introcude a new shared-utils module which doesn't contain any external dependencies if possible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-21) compiler smarts
[ https://jira.codehaus.org/browse/MCOMPILER-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated MCOMPILER-21: --- Attachment: MCOMPILER-21-v2.patch first version of an ugly hack to also get class inter-dependencies properly recompiled > compiler smarts > --- > > Key: MCOMPILER-21 > URL: https://jira.codehaus.org/browse/MCOMPILER-21 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Reporter: Brett Porter >Assignee: Mark Struberg > Fix For: backlog > > Attachments: MCOMPILER-21.patch, MCOMPILER-21-v2.patch > > > there are probably other ways we can make the compiler stale check smarter. > List them out here if you think of them. > 1) if a snapshot was resolved to a newer version, rebuild everything. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-21) compiler smarts
[
https://jira.codehaus.org/browse/MCOMPILER-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=307127#comment-307127
]
Mark Struberg commented on MCOMPILER-21:
gosh, it's even more broken. We also have problems detecting compile
dependencies inside the same module!
Compile a project with 2 classes:
{code}
public class BeanA {
getI() {return 42;}
}
public class BeanA2 {
getI() { return new BeanA().getI(); }
}
{code}
Now go on and change BeanA#getI() to BeanA#getI_broken(). Since BeanA2 still
uses the now non-existing getI() we should get a compile error. But 'mvn
compile' only detects that BeanA needs a compile and doesn't recompile BeanB.
The whole plexus StaleSourceScanner doesn't work as expected and should get
dropped imo. Detecting cross dependencies would only be possible by a full code
analysis and could require multi-pass scans. It's much more simple to just
recompile the whole plugin in that case once we detect a 'newer' file.
Once we hit a java file which is newer than it' corresponding class file then
we need to recompile all classes.
> compiler smarts
> ---
>
> Key: MCOMPILER-21
> URL: https://jira.codehaus.org/browse/MCOMPILER-21
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Reporter: Brett Porter
>Assignee: Mark Struberg
> Fix For: backlog
>
> Attachments: MCOMPILER-21.patch
>
>
> there are probably other ways we can make the compiler stale check smarter.
> List them out here if you think of them.
> 1) if a snapshot was resolved to a newer version, rebuild everything.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-21) compiler smarts
[ https://jira.codehaus.org/browse/MCOMPILER-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=307117#comment-307117 ] Mark Struberg commented on MCOMPILER-21: PS: the code above currently only builds with skipping the tests. I'll need to move all the tests to the invoker-plugin first. The old plugin-test-harness doesn't work with sisu... > compiler smarts > --- > > Key: MCOMPILER-21 > URL: https://jira.codehaus.org/browse/MCOMPILER-21 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Reporter: Brett Porter >Assignee: Mark Struberg > Fix For: backlog > > Attachments: MCOMPILER-21.patch > > > there are probably other ways we can make the compiler stale check smarter. > List them out here if you think of them. > 1) if a snapshot was resolved to a newer version, rebuild everything. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-21) compiler smarts
[ https://jira.codehaus.org/browse/MCOMPILER-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated MCOMPILER-21: --- Attachment: MCOMPILER-21.patch started with some ugly hacks for now. Doing proper incremental build support actually contains of 2 steps. The first one mainly kicks in if someone invokes a phase < package. In this case the Artifact of the other module is a directory. In this case we check whether the depending module is a path and if so, we check whether it contains newer files. -> recompile all. The second trick will be on the reactor level. We might check the md5 of the dependencies and compare them with the md5 previously used. -> invoke clean if something changed. > compiler smarts > --- > > Key: MCOMPILER-21 > URL: https://jira.codehaus.org/browse/MCOMPILER-21 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Reporter: Brett Porter >Assignee: Mark Struberg > Fix For: backlog > > Attachments: MCOMPILER-21.patch > > > there are probably other ways we can make the compiler stale check smarter. > List them out here if you think of them. > 1) if a snapshot was resolved to a newer version, rebuild everything. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-21) compiler smarts
[ https://jira.codehaus.org/browse/MCOMPILER-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated MCOMPILER-21: --- Priority: Major (was: Minor) > compiler smarts > --- > > Key: MCOMPILER-21 > URL: https://jira.codehaus.org/browse/MCOMPILER-21 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Reporter: Brett Porter >Assignee: Mark Struberg > Fix For: backlog > > > there are probably other ways we can make the compiler stale check smarter. > List them out here if you think of them. > 1) if a snapshot was resolved to a newer version, rebuild everything. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-21) compiler smarts
[ https://jira.codehaus.org/browse/MCOMPILER-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reassigned MCOMPILER-21: -- Assignee: Mark Struberg > compiler smarts > --- > > Key: MCOMPILER-21 > URL: https://jira.codehaus.org/browse/MCOMPILER-21 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Reporter: Brett Porter >Assignee: Mark Struberg >Priority: Minor > Fix For: backlog > > > there are probably other ways we can make the compiler stale check smarter. > List them out here if you think of them. > 1) if a snapshot was resolved to a newer version, rebuild everything. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-727) release plugin uses wrong checkout directory
[ https://jira.codehaus.org/browse/MRELEASE-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=300032#comment-300032 ] Mark Struberg commented on MRELEASE-727: yes, please create a new one. Do you folks really still use CVS? :) CVS is dead since 2006 ^^ > release plugin uses wrong checkout directory > > > Key: MRELEASE-727 > URL: https://jira.codehaus.org/browse/MRELEASE-727 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: perform >Affects Versions: 2.2, 2.2.2 > Environment: mvn 3.0.3 >Reporter: Dominik Bartholdi >Assignee: Olivier Lamy >Priority: Blocker > Fix For: 2.3 > > Attachments: flat-project-layout.patch, MRELEASE-727.patch, > release_failed.txt, testproject.zip > > > When performing a release build on a multi module project, the plugin uses a > wrong checkout directory and therefore is unable to perform the release. > I tested this with both version 2.2 and 2.2.2 > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-release-plugin:2.2.2:perform (default-cli) on > project test_multi_parent: Error executing Maven. Working directory > "/Users/domi/work/ws/sts_0/test_multi_parent/target/checkout/test_multi_parent/test_multi_parent" > does not exist! -> [Help 1] > We use flat project structure (where parent and modul project are in the same > directory) > The SVN Repo looks like this: > .../svnrepos/KUQ/trunk/test_multi_parent > .../svnrepos/KUQ/trunk/test_multi_module1 > I'll attache a minimal test project to reproduce it and a file containing the > whole log output for release:prepare and release:perform > To reproduce the problem: > - adjust the SVN paths in the pom.xml > - checkin to SVN > - release:prepare > - release:perform -Dgoals=install -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-674) ScmFile.path should always be relative and never start with any file-separator
[ https://jira.codehaus.org/browse/SCM-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=299103#comment-299103 ] Mark Struberg commented on SCM-674: --- Be careful with this one. There might be tons of side effects waiting for you. Most of the SCMs do NOT take a relative file:// url but only absolute ones. Thus you would really make an absolute file out of it most times. > ScmFile.path should always be relative and never start with any > file-separator > --- > > Key: SCM-674 > URL: https://jira.codehaus.org/browse/SCM-674 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-api >Affects Versions: 1.7 >Reporter: Robert Scholte >Priority: Minor > > With these restrictions we have better control over the ScmFiles, so projects > using SCM don't have to write their own workarounds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-426) There is no way to specify a branch/tag/revision when performing a release
[ https://jira.codehaus.org/browse/MRELEASE-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298480#comment-298480 ] Mark Struberg commented on MRELEASE-426: Well, I only used CVS from mid 90s to early 2004 or so, but I think there was a way to checkout a branch. It was not very handy but still it used to work. Can you please shed more light on why it is not possible to just create a branch in CVS. I bet it would be easier to switch to SVN or GIT nowadays. Given that CVS has horrible security leaks and is practically unmaintained since 5 years, isn't? > There is no way to specify a branch/tag/revision when performing a release > -- > > Key: MRELEASE-426 > URL: https://jira.codehaus.org/browse/MRELEASE-426 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: perform >Affects Versions: 2.0-beta-8 > Environment: Maven2, CVSNT >Reporter: Eric > > When using the release-plugin with CVS, there does not seem to be any way to > specify a version & versionType to base the release on. > The scm plugin allows to specify scmVersion, scmVersionType to pass this > information to the plugin, but when calling the release:perform goal, there > is no way to send this information to the scm plugin to checkout the files > from the appropriate branch/tag. > Accordingly, it seems that with CVS, the only way to build a release is from > the latest sources in the HEAD; not extremely practical. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-719) No error when release:prepare with an already existing scm tag
[ https://jira.codehaus.org/browse/MRELEASE-719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298046#comment-298046 ] Mark Struberg commented on MRELEASE-719: I'm not worried about the additional work needed. But I'm really worried that we pack all this information in our maven-release-manager. There is already way too much hardcoded stuff which is specific for single SCMs in there. I'd rather move all this information into the scm-api instead. > No error when release:prepare with an already existing scm tag > -- > > Key: MRELEASE-719 > URL: https://jira.codehaus.org/browse/MRELEASE-719 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.2.1 >Reporter: Tony Chemit >Assignee: Olivier Lamy > Fix For: 2.4 > > > When releasing the mojo-parent (codehaus), I had to do the release twice but > I forgot to remove the scm tag. > The release:prepare did not complain about it (should have). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-705) Project directory appended twice
[
https://jira.codehaus.org/browse/MRELEASE-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297972#comment-297972
]
Mark Struberg commented on MRELEASE-705:
This could be a duplicate of MRELEASE-727 , wdyt?
> Project directory appended twice
>
>
> Key: MRELEASE-705
> URL: https://jira.codehaus.org/browse/MRELEASE-705
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 2.2, 2.2.1
> Environment: accurev scm provider
>Reporter: Vadim Tsing
>Priority: Blocker
> Attachments: output.txt
>
>
> During perform, the fix for MRELEASE-457 changes the checkout directory by
> appending the checkout path, later the release manager appends it again in
> {{determineWorkingDirectory()}}. As a result maven cannot find the checked
> out project.
> Please see attached log file with {{-X}} output, specifically line 1541 that
> shows the correct project path, however, when it comes to running the deploy
> command, it appends project path again as indicated by line 1553.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-747) Support Jazz SCM
[ https://jira.codehaus.org/browse/MRELEASE-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297933#comment-297933 ] Mark Struberg commented on MRELEASE-747: ouch ^^ good catch, you are digging pretty deep ;) I assume this is coming from the original code which was mainly made for CVS back then. We need to check the history... > Support Jazz SCM > > > Key: MRELEASE-747 > URL: https://jira.codehaus.org/browse/MRELEASE-747 > Project: Maven 2.x Release Plugin > Issue Type: New Feature > Components: scm >Affects Versions: 2.2.2 > Environment: N/A >Reporter: Chris Graham >Assignee: Olivier Lamy > Fix For: 2.3 > > Attachments: maven-release-2.2.2-patch-jazz.patch > > > The Jazz SCM plugin requires SCM translation of the URL's in the POM. > This patch addresses that. > Note. This issue will ultimately depend on mavn-scm 1.7 being released, as > that version will include the maven-scm-providers-jazz module. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-747) Support Jazz SCM
[ https://jira.codehaus.org/browse/MRELEASE-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297927#comment-297927 ] Mark Struberg commented on MRELEASE-747: Hi! When hacking the similar stuff for GitScmTranslator and Hg I found out that the JazzScmTranslator still has the HEAD logic from CVS in it. Jazz folks, are you sure that Jazz also has such a special HEAD thingy? The HEAD in CVS is similar to the SVN trunk! It just denotes that you are on the CVS main route. I guess this is a copy & paste leftover... > Support Jazz SCM > > > Key: MRELEASE-747 > URL: https://jira.codehaus.org/browse/MRELEASE-747 > Project: Maven 2.x Release Plugin > Issue Type: New Feature > Components: scm >Affects Versions: 2.2.2 > Environment: N/A >Reporter: Chris Graham >Assignee: Olivier Lamy > Fix For: 2.3 > > Attachments: maven-release-2.2.2-patch-jazz.patch > > > The Jazz SCM plugin requires SCM translation of the URL's in the POM. > This patch addresses that. > Note. This issue will ultimately depend on mavn-scm 1.7 being released, as > that version will include the maven-scm-providers-jazz module. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-719) No error when release:prepare with an already existing scm tag
[ https://jira.codehaus.org/browse/MRELEASE-719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297924#comment-297924 ] Mark Struberg commented on MRELEASE-719: > Well, you don't 'remove' anything from a scm. You just create a new version.. That depends on the SCM. This statement is only true for SVN. CVS ditched it sometimes even in it's attic (the first delete is fine, the 2nd destroyed the attic). And in GIT if you push a removal of a tag, then it's gone... Of course it's still in the downstream repos if they pulled it, but it's a history rewrite which is often not allowed. It is perfectly fine though if pushChanges=false for Hg and GIT! Needs a bit more brainwork I fear. > No error when release:prepare with an already existing scm tag > -- > > Key: MRELEASE-719 > URL: https://jira.codehaus.org/browse/MRELEASE-719 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.2.1 >Reporter: Tony Chemit >Assignee: Olivier Lamy > Fix For: 2.4 > > > When releasing the mojo-parent (codehaus), I had to do the release twice but > I forgot to remove the scm tag. > The release:prepare did not complain about it (should have). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-719) No error when release:prepare with an already existing scm tag
[ https://jira.codehaus.org/browse/MRELEASE-719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297920#comment-297920 ] Mark Struberg commented on MRELEASE-719: right, we have 2 options a.) having release:prepare fail _early_ if the tag already exists. And have release:rollback only WARN that the tag must get removed manually b.) have release:rollback remove the tag as well if it exists _and_ we have proper privileges. I'm always a bit reluctant fraidy-cat when doing a remove operation on an SCM ... I think having release:prepare fail _early_ if the tag already exists is a good idea in any case. > No error when release:prepare with an already existing scm tag > -- > > Key: MRELEASE-719 > URL: https://jira.codehaus.org/browse/MRELEASE-719 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.2.1 >Reporter: Tony Chemit >Assignee: Olivier Lamy > Fix For: 2.4 > > > When releasing the mojo-parent (codehaus), I had to do the release twice but > I forgot to remove the scm tag. > The release:prepare did not complain about it (should have). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-723) DCVS tagging commands should store the tag-name (or hash) in the the //project/scm/tag element.
[ https://jira.codehaus.org/browse/MRELEASE-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg closed MRELEASE-723. -- Resolution: Fixed Fix Version/s: (was: 2.4) 2.3 fixed in r1333660. I've now used the explicit GitScmTranslator and HgScmTranslator. The generic fix would have been a way to big change. Tested with SVN and GIT. > DCVS tagging commands should store the tag-name (or hash) in the the > //project/scm/tag element. > --- > > Key: MRELEASE-723 > URL: https://jira.codehaus.org/browse/MRELEASE-723 > Project: Maven 2.x Release Plugin > Issue Type: New Feature > Components: Git, Mercurial, Subversion > Environment: Apache Maven 3.0.4-RC3 (r1210461; 2011-12-05 > 14:58:54+0100) > Maven home: /usr/local/Cellar/maven/current/libexec > Java version: 1.6.0_29, vendor: Apple Inc. > Java home: > /Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home > Default locale: de_DE, platform encoding: MacRoman > OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac" >Reporter: Mirko Friedenhagen >Assignee: Mark Struberg > Fix For: 2.3 > > Attachments: add-tag-to-release-poms-1329108.patch, > add-tag-to-release-poms.patch, MRELEASE-723-idea.patch, testpr-git.zip, > testprj-svn-repo.zip > > > With SVN the developerConnection and connection are > updated to the "real" release URL, that is when I invoke release:prepare with > a URL like: > https://SVNSERVER/svn/REPO/myproject/branches/release it will be > replaced by https://SVNSERVER/svn/REPO/myproject/tags/myproject-1.0 > which is fine because now you know which revision to checkout for > building the release. > With git there is no such possibility to realize this with rewriting > the URL AFAIK. So I would have expected however, that maybe the > //project/scm/tag > element would be updated to reflect the fact, that the pom is the one > of release, either to the "symbolic name" myproject-1.0 or to the hash > of the tag. > See http://markmail.org/thread/m77cvhqqq56krzzd as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-723) DCVS tagging commands should store the tag-name (or hash) in the the //project/scm/tag element.
[ https://jira.codehaus.org/browse/MRELEASE-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated MRELEASE-723: --- Attachment: testpr-git.zip and here comes the git repo > DCVS tagging commands should store the tag-name (or hash) in the the > //project/scm/tag element. > --- > > Key: MRELEASE-723 > URL: https://jira.codehaus.org/browse/MRELEASE-723 > Project: Maven 2.x Release Plugin > Issue Type: New Feature > Components: Git, Mercurial, Subversion > Environment: Apache Maven 3.0.4-RC3 (r1210461; 2011-12-05 > 14:58:54+0100) > Maven home: /usr/local/Cellar/maven/current/libexec > Java version: 1.6.0_29, vendor: Apple Inc. > Java home: > /Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home > Default locale: de_DE, platform encoding: MacRoman > OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac" >Reporter: Mirko Friedenhagen >Assignee: Mark Struberg > Fix For: 2.4 > > Attachments: add-tag-to-release-poms-1329108.patch, > add-tag-to-release-poms.patch, MRELEASE-723-idea.patch, testpr-git.zip, > testprj-svn-repo.zip > > > With SVN the developerConnection and connection are > updated to the "real" release URL, that is when I invoke release:prepare with > a URL like: > https://SVNSERVER/svn/REPO/myproject/branches/release it will be > replaced by https://SVNSERVER/svn/REPO/myproject/tags/myproject-1.0 > which is fine because now you know which revision to checkout for > building the release. > With git there is no such possibility to realize this with rewriting > the URL AFAIK. So I would have expected however, that maybe the > //project/scm/tag > element would be updated to reflect the fact, that the pom is the one > of release, either to the "symbolic name" myproject-1.0 or to the hash > of the tag. > See http://markmail.org/thread/m77cvhqqq56krzzd as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-723) DCVS tagging commands should store the tag-name (or hash) in the the //project/scm/tag element.
[ https://jira.codehaus.org/browse/MRELEASE-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated MRELEASE-723: --- Attachment: testprj-svn-repo.zip This is a small sample svn repo which I use. Of course you need to adopt the scm:svn: URL in the poms. > DCVS tagging commands should store the tag-name (or hash) in the the > //project/scm/tag element. > --- > > Key: MRELEASE-723 > URL: https://jira.codehaus.org/browse/MRELEASE-723 > Project: Maven 2.x Release Plugin > Issue Type: New Feature > Components: Git, Mercurial, Subversion > Environment: Apache Maven 3.0.4-RC3 (r1210461; 2011-12-05 > 14:58:54+0100) > Maven home: /usr/local/Cellar/maven/current/libexec > Java version: 1.6.0_29, vendor: Apple Inc. > Java home: > /Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home > Default locale: de_DE, platform encoding: MacRoman > OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac" >Reporter: Mirko Friedenhagen >Assignee: Mark Struberg > Fix For: 2.4 > > Attachments: add-tag-to-release-poms-1329108.patch, > add-tag-to-release-poms.patch, MRELEASE-723-idea.patch, testprj-svn-repo.zip > > > With SVN the developerConnection and connection are > updated to the "real" release URL, that is when I invoke release:prepare with > a URL like: > https://SVNSERVER/svn/REPO/myproject/branches/release it will be > replaced by https://SVNSERVER/svn/REPO/myproject/tags/myproject-1.0 > which is fine because now you know which revision to checkout for > building the release. > With git there is no such possibility to realize this with rewriting > the URL AFAIK. So I would have expected however, that maybe the > //project/scm/tag > element would be updated to reflect the fact, that the pom is the one > of release, either to the "symbolic name" myproject-1.0 or to the hash > of the tag. > See http://markmail.org/thread/m77cvhqqq56krzzd as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-723) DCVS tagging commands should store the tag-name (or hash) in the the //project/scm/tag element.
[ https://jira.codehaus.org/browse/MRELEASE-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297757#comment-297757 ] Mark Struberg commented on MRELEASE-723: > it looks to me that the String translateTagUrl hmm, don't think so. In GIT (like in CVS) the SCM URL doesn't change at all for a new TAG or BRANCH. The only thing we need to do is to set the in the SCM info. As far as I've understood this is what the resolveTag method is for, isn't? PS: I'l take care, but I'm really happy for your feedback folks! This one is pretty fundamental and I don't like to trash the release manager (again) ;) Otoh I don't hesitate to make important changes if there is a good reason. This one feels like one. > DCVS tagging commands should store the tag-name (or hash) in the the > //project/scm/tag element. > --- > > Key: MRELEASE-723 > URL: https://jira.codehaus.org/browse/MRELEASE-723 > Project: Maven 2.x Release Plugin > Issue Type: New Feature > Components: Git, Mercurial, Subversion > Environment: Apache Maven 3.0.4-RC3 (r1210461; 2011-12-05 > 14:58:54+0100) > Maven home: /usr/local/Cellar/maven/current/libexec > Java version: 1.6.0_29, vendor: Apple Inc. > Java home: > /Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home > Default locale: de_DE, platform encoding: MacRoman > OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac" >Reporter: Mirko Friedenhagen >Assignee: Mark Struberg > Fix For: 2.4 > > Attachments: add-tag-to-release-poms-1329108.patch, > add-tag-to-release-poms.patch, MRELEASE-723-idea.patch > > > With SVN the developerConnection and connection are > updated to the "real" release URL, that is when I invoke release:prepare with > a URL like: > https://SVNSERVER/svn/REPO/myproject/branches/release it will be > replaced by https://SVNSERVER/svn/REPO/myproject/tags/myproject-1.0 > which is fine because now you know which revision to checkout for > building the release. > With git there is no such possibility to realize this with rewriting > the URL AFAIK. So I would have expected however, that maybe the > //project/scm/tag > element would be updated to reflect the fact, that the pom is the one > of release, either to the "symbolic name" myproject-1.0 or to the hash > of the tag. > See http://markmail.org/thread/m77cvhqqq56krzzd as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
