[jira] (ARCHETYPE-441) A convenient way to specify post-archetype-generation goals
[ https://jira.codehaus.org/browse/ARCHETYPE-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362345#comment-362345 ] Alessandro Dionisi commented on ARCHETYPE-441: -- Hey, I have the same need. Did you find a way to specify plugin goals into the archetype? > A convenient way to specify post-archetype-generation goals > --- > > Key: ARCHETYPE-441 > URL: https://jira.codehaus.org/browse/ARCHETYPE-441 > Project: Maven Archetype > Issue Type: Wish >Reporter: Vyacheslav Artyukhov > > Now archetype writes in log "No post-archetype-generation goals to invoke." > I guess there is a way to configure post-archetype-generation goals but I > cannt find it. > So, my issue is to invoke java classes to modify newly created project after > archetype generation is finished. Can I do this using > post-archetype-generation goals? -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1126) Discrepancy between test exclusion docs and plugin behavior
[ https://jira.codehaus.org/browse/SUREFIRE-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362359#comment-362359 ] Tibor Digana commented on SUREFIRE-1126: It is in progress https://github.com/apache/maven-surefire/pull/83 I am fixing two issues actually SUREFIRE-745 and SUREFIRE-1126. The point here is to unify the parser and use the same mechanism in junit4, junit47, and TestNG providers. Nowadays the main functionality works, tests passed, but I need to update DirectoryScanner and DependenciesScanner due to %regex[] pattern. As a result, the patterns will be [!][class_pattern][#method_pattern] or the same with comma separated values. class_pattern can be for instance pkg/XTest.java, **/XTest, **/?Test, %regex[.*XTest.*], etc. method_pattern can be for instance m?thod, test*, etc. ** denotes long path name or package * denotes zero or more characters ? denotes single character > Discrepancy between test exclusion docs and plugin behavior > --- > > Key: SUREFIRE-1126 > URL: https://jira.codehaus.org/browse/SUREFIRE-1126 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.18 >Reporter: Dima Spivak >Assignee: Tibor Digana > > According to [Surefire > documentation|http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#test], > tests can be excluded on the command line by prefixing with an exclamation > mark. Is this expected behavior that's currently broken, or did someone jump > the gun with the docs? -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1126) Discrepancy between test exclusion docs and plugin behavior
[ https://jira.codehaus.org/browse/SUREFIRE-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362359#comment-362359 ] Tibor Digana edited comment on SUREFIRE-1126 at 2/2/15 6:07 AM: It is in progress https://github.com/apache/maven-surefire/pull/83 I am fixing two issues actually SUREFIRE-745 and SUREFIRE-1126. The point here is to unify the parser and use the same mechanism in junit4, junit47, and TestNG providers. Nowadays the main functionality works, tests passed, but I need to update DirectoryScanner and DependenciesScanner due to %regex[] pattern. As a result, the patterns will be [!][class_pattern][[##method_pattern]] or the same with comma separated values. class_pattern can be for instance pkg/XTest.java, **/XTest, **/?Test, %regex[.*XTest.*], etc. method_pattern can be for instance m?thod, test*, etc. "**" denotes long path name or package "*" denotes zero or more characters "?" denotes single character was (Author: tibor17): It is in progress https://github.com/apache/maven-surefire/pull/83 I am fixing two issues actually SUREFIRE-745 and SUREFIRE-1126. The point here is to unify the parser and use the same mechanism in junit4, junit47, and TestNG providers. Nowadays the main functionality works, tests passed, but I need to update DirectoryScanner and DependenciesScanner due to %regex[] pattern. As a result, the patterns will be [!][class_pattern][[##method_pattern]] or the same with comma separated values. class_pattern can be for instance pkg/XTest.java, **/XTest, **/?Test, %regex[.*XTest.*], etc. method_pattern can be for instance m?thod, test*, etc. "**" denotes long path name or package * denotes zero or more characters "?" denotes single character > Discrepancy between test exclusion docs and plugin behavior > --- > > Key: SUREFIRE-1126 > URL: https://jira.codehaus.org/browse/SUREFIRE-1126 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.18 >Reporter: Dima Spivak >Assignee: Tibor Digana > > According to [Surefire > documentation|http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#test], > tests can be excluded on the command line by prefixing with an exclamation > mark. Is this expected behavior that's currently broken, or did someone jump > the gun with the docs? -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1126) Discrepancy between test exclusion docs and plugin behavior
[ https://jira.codehaus.org/browse/SUREFIRE-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362359#comment-362359 ] Tibor Digana edited comment on SUREFIRE-1126 at 2/2/15 6:06 AM: It is in progress https://github.com/apache/maven-surefire/pull/83 I am fixing two issues actually SUREFIRE-745 and SUREFIRE-1126. The point here is to unify the parser and use the same mechanism in junit4, junit47, and TestNG providers. Nowadays the main functionality works, tests passed, but I need to update DirectoryScanner and DependenciesScanner due to %regex[] pattern. As a result, the patterns will be [!][class_pattern][[##method_pattern]] or the same with comma separated values. class_pattern can be for instance pkg/XTest.java, **/XTest, **/?Test, %regex[.*XTest.*], etc. method_pattern can be for instance m?thod, test*, etc. ** denotes long path name or package * denotes zero or more characters ? denotes single character was (Author: tibor17): It is in progress https://github.com/apache/maven-surefire/pull/83 I am fixing two issues actually SUREFIRE-745 and SUREFIRE-1126. The point here is to unify the parser and use the same mechanism in junit4, junit47, and TestNG providers. Nowadays the main functionality works, tests passed, but I need to update DirectoryScanner and DependenciesScanner due to %regex[] pattern. As a result, the patterns will be [!][class_pattern][[#method_pattern]] or the same with comma separated values. class_pattern can be for instance pkg/XTest.java, **/XTest, **/?Test, %regex[.*XTest.*], etc. method_pattern can be for instance m?thod, test*, etc. ** denotes long path name or package * denotes zero or more characters ? denotes single character > Discrepancy between test exclusion docs and plugin behavior > --- > > Key: SUREFIRE-1126 > URL: https://jira.codehaus.org/browse/SUREFIRE-1126 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.18 >Reporter: Dima Spivak >Assignee: Tibor Digana > > According to [Surefire > documentation|http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#test], > tests can be excluded on the command line by prefixing with an exclamation > mark. Is this expected behavior that's currently broken, or did someone jump > the gun with the docs? -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1126) Discrepancy between test exclusion docs and plugin behavior
[ https://jira.codehaus.org/browse/SUREFIRE-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362359#comment-362359 ] Tibor Digana edited comment on SUREFIRE-1126 at 2/2/15 6:06 AM: It is in progress https://github.com/apache/maven-surefire/pull/83 I am fixing two issues actually SUREFIRE-745 and SUREFIRE-1126. The point here is to unify the parser and use the same mechanism in junit4, junit47, and TestNG providers. Nowadays the main functionality works, tests passed, but I need to update DirectoryScanner and DependenciesScanner due to %regex[] pattern. As a result, the patterns will be [!][class_pattern][[#method_pattern]] or the same with comma separated values. class_pattern can be for instance pkg/XTest.java, **/XTest, **/?Test, %regex[.*XTest.*], etc. method_pattern can be for instance m?thod, test*, etc. ** denotes long path name or package * denotes zero or more characters ? denotes single character was (Author: tibor17): It is in progress https://github.com/apache/maven-surefire/pull/83 I am fixing two issues actually SUREFIRE-745 and SUREFIRE-1126. The point here is to unify the parser and use the same mechanism in junit4, junit47, and TestNG providers. Nowadays the main functionality works, tests passed, but I need to update DirectoryScanner and DependenciesScanner due to %regex[] pattern. As a result, the patterns will be [!][class_pattern][#method_pattern] or the same with comma separated values. class_pattern can be for instance pkg/XTest.java, **/XTest, **/?Test, %regex[.*XTest.*], etc. method_pattern can be for instance m?thod, test*, etc. ** denotes long path name or package * denotes zero or more characters ? denotes single character > Discrepancy between test exclusion docs and plugin behavior > --- > > Key: SUREFIRE-1126 > URL: https://jira.codehaus.org/browse/SUREFIRE-1126 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.18 >Reporter: Dima Spivak >Assignee: Tibor Digana > > According to [Surefire > documentation|http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#test], > tests can be excluded on the command line by prefixing with an exclamation > mark. Is this expected behavior that's currently broken, or did someone jump > the gun with the docs? -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1126) Discrepancy between test exclusion docs and plugin behavior
[ https://jira.codehaus.org/browse/SUREFIRE-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362359#comment-362359 ] Tibor Digana edited comment on SUREFIRE-1126 at 2/2/15 6:07 AM: It is in progress https://github.com/apache/maven-surefire/pull/83 I am fixing two issues actually SUREFIRE-745 and SUREFIRE-1126. The point here is to unify the parser and use the same mechanism in junit4, junit47, and TestNG providers. Nowadays the main functionality works, tests passed, but I need to update DirectoryScanner and DependenciesScanner due to %regex[] pattern. As a result, the patterns will be [!][class_pattern][[##method_pattern]] or the same with comma separated values. class_pattern can be for instance pkg/XTest.java, **/XTest, **/?Test, %regex[.*XTest.*], etc. method_pattern can be for instance m?thod, test*, etc. "**" denotes long path name or package * denotes zero or more characters "?" denotes single character was (Author: tibor17): It is in progress https://github.com/apache/maven-surefire/pull/83 I am fixing two issues actually SUREFIRE-745 and SUREFIRE-1126. The point here is to unify the parser and use the same mechanism in junit4, junit47, and TestNG providers. Nowadays the main functionality works, tests passed, but I need to update DirectoryScanner and DependenciesScanner due to %regex[] pattern. As a result, the patterns will be [!][class_pattern][[##method_pattern]] or the same with comma separated values. class_pattern can be for instance pkg/XTest.java, **/XTest, **/?Test, %regex[.*XTest.*], etc. method_pattern can be for instance m?thod, test*, etc. ** denotes long path name or package * denotes zero or more characters ? denotes single character > Discrepancy between test exclusion docs and plugin behavior > --- > > Key: SUREFIRE-1126 > URL: https://jira.codehaus.org/browse/SUREFIRE-1126 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.18 >Reporter: Dima Spivak >Assignee: Tibor Digana > > According to [Surefire > documentation|http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#test], > tests can be excluded on the command line by prefixing with an exclamation > mark. Is this expected behavior that's currently broken, or did someone jump > the gun with the docs? -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHADE-181) Allow including dependencies of scope:provided
[
https://jira.codehaus.org/browse/MSHADE-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies reassigned MSHADE-181:
---
Assignee: (was: Benson Margulies)
> Allow including dependencies of scope:provided
> ---
>
> Key: MSHADE-181
> URL: https://jira.codehaus.org/browse/MSHADE-181
> Project: Maven Shade Plugin
> Issue Type: Wish
>Affects Versions: 2.3
>Reporter: Matthias Stevens
>
> I have a project for which I'd like to create a shaded jar.
> It has a bunch of dependencies in scope:provided, because they really are, in
> the normal use-case of this artifact; it's meant to be deployed as a plugin
> in another app, so, for example, {{myapp-api}} really is "provided".
> The project's assembly depends on these deps to be scope:provided (so they're
> not included in the assembly)
> If a webapp project is made and depends on this project, the scope:provided
> also helps avoiding duplicated dependencies in some cases.
> .. but yes, this project now also needs a standalone/executable jar; some of
> the "provided" dependencies are needed at runtime for this. As far as I can
> tell, the shade plugin currently does not propose any solution for this.
> Is there any way this could be considered for the plugin ? Or am I looking at
> it the wrong way ? I suppose I could split my project and have 2 modules, one
> simply being the standalone/shaded version of the other, but it seems
> overkill, since they're really the same source.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5416) Forked execution message should specify the forked goal
[
https://jira.codehaus.org/browse/MNG-5416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies reassigned MNG-5416:
-
Assignee: (was: Benson Margulies)
> Forked execution message should specify the forked goal
> ---
>
> Key: MNG-5416
> URL: https://jira.codehaus.org/browse/MNG-5416
> Project: Maven
> Issue Type: Bug
> Components: Reactor and workspace
>Affects Versions: 3.0.4
>Reporter: Benson Margulies
>Priority: Minor
>
> {noformat}
> [INFO]
>
> [INFO] Forking License Test :: global-db - something to depend on 1
> [INFO]
>
> {noformat}
> One of the struggles in debugging a build can be forked executions.
> If the forked execution implicitly depends on some goal of some plugin that
> is bound to a phase after the forked goal, the build fails. This would be
> easier to debug if this message included the goal.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MANTRUN-186) seems ignoring classpath
[
https://jira.codehaus.org/browse/MANTRUN-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies updated MANTRUN-186:
-
Assignee: (was: Benson Margulies)
Summary: seems ignoring classpath (was: CLONE -
seems ignoring classpath)
> seems ignoring classpath
> ---
>
> Key: MANTRUN-186
> URL: https://jira.codehaus.org/browse/MANTRUN-186
> Project: Maven Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.5, 1.6, 1.7
> Environment: Fedora
>Reporter: Mansour Al Akeel
> Fix For: 1.7
>
>
> I'm trying to run xdoclet in ant build file called from antrun plugin. The
> build file is very simple:
> {code:xml}
>
>
>
>
>
>
>name="commons-collections/commons-collections/3.1/commons-collections-3.1.jar"/>
>name="commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar"/>
>name="jboss/jboss-j2ee/4.0.2/jboss-j2ee-4.0.2.jar"/>
>
>name="xdoclet/xdoclet/1.2.3/xdoclet-1.2.3.jar"/>
>name="xdoclet/xdoclet-ejb-module/1.2.3/xdoclet-ejb-module-1.2.3.jar"/>
>
>
>
>
>
>
>
>
>
>classpathref="xdoclet.classpath" name="ejbdoclet"/>
>
>
>
>dir="${basedir}/src/main/java"/>
>
>
>
>
> {code}
> When executed directly from command (ant
> -Dmaven.repository=/home/javor/.m2/repository) it works fine. But fails when
> embedded in antrun:
> {code:xml}
>
> maven-antrun-plugin
> 1.2-SNAPSHOT
>
>
> generate-sources
>
> run
>
>
>
>antfile="build.xml">
>value="${settings.localRepository}"/>
>
>
>
>
>
>
> {code}
> Maven output:
> {noformat}
> ...
> [INFO] [antrun:run {execution: default}]
> [INFO] Executing tasks
>
> run:
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error executing ant tasks
>
> Embedded error: The following error occurred while executing this line:
> /home/javor/workspace/testcase/build.xml:26: Can't create a remoteinterface
> element under ejbdoclet. Make sure the jar file containing the corresponding
> subtask class is on the classpath specified in the that defined {2}.
> ...
> {noformat}
> Could you show me any workaround or put a bit of light on that problem?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-885) When the base pom is a subdirectory, tagging fails in GIT
[ https://jira.codehaus.org/browse/MRELEASE-885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies reassigned MRELEASE-885: - Assignee: (was: Benson Margulies) > When the base pom is a subdirectory, tagging fails in GIT > - > > Key: MRELEASE-885 > URL: https://jira.codehaus.org/browse/MRELEASE-885 > Project: Maven Release Plugin > Issue Type: Bug > Components: Git, scm >Affects Versions: 2.3.2, 2.5 > Environment: linux (fedora 20) >Reporter: Bradley Baetz > Fix For: 2.5.1 > > > (NOTE, this is not the same as MRELEASE-875. I think) > Given a GIT checkout with a project structure of: > project/ > dir1/pom.xml > dir2/pom.xml > Given an config of: > scm:git:ssh://g...@github.com:bbaetz/maven-release-bug.git > the maven-release plugin correctly commits the pom file, but fails to tag. > The problem is that its stripping off one level of the URL, and doing: > [INFO] Executing: /bin/sh -c cd /home/bbaetz/src/subdir-project && git push > ssh://g...@github.com:bbaetz refs/tags/project-1.0.0 > which is wrong for git > To reproduce, fork https://github.com/bbaetz/maven-release-bug/, change the > scm settings to your own, and run: > mvn -X -B -f build/pom.xml -DdevelopmentVersion=1.0.1-SNAPSHOT > -DreleaseVersion=1.0.0 -Dresume=false release:prepare release:perform > I've tried various combinations of maven-release-plugin and maven-scm-plugin > versions, with no luck -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (ARCHETYPE-471) Make a final Maven 2.2.1 release
Benson Margulies created ARCHETYPE-471: -- Summary: Make a final Maven 2.2.1 release Key: ARCHETYPE-471 URL: https://jira.codehaus.org/browse/ARCHETYPE-471 Project: Maven Archetype Issue Type: Task Reporter: Benson Margulies -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHADE-181) Allow including dependencies of scope:provided
[
https://jira.codehaus.org/browse/MSHADE-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies updated MSHADE-181:
Summary: Allow including dependencies of scope:provided (was: CLONE -
Allow including dependencies of scope:provided)
> Allow including dependencies of scope:provided
> ---
>
> Key: MSHADE-181
> URL: https://jira.codehaus.org/browse/MSHADE-181
> Project: Maven Shade Plugin
> Issue Type: Wish
>Affects Versions: 2.3
>Reporter: Matthias Stevens
>Assignee: Benson Margulies
>
> I have a project for which I'd like to create a shaded jar.
> It has a bunch of dependencies in scope:provided, because they really are, in
> the normal use-case of this artifact; it's meant to be deployed as a plugin
> in another app, so, for example, {{myapp-api}} really is "provided".
> The project's assembly depends on these deps to be scope:provided (so they're
> not included in the assembly)
> If a webapp project is made and depends on this project, the scope:provided
> also helps avoiding duplicated dependencies in some cases.
> .. but yes, this project now also needs a standalone/executable jar; some of
> the "provided" dependencies are needed at runtime for this. As far as I can
> tell, the shade plugin currently does not propose any solution for this.
> Is there any way this could be considered for the plugin ? Or am I looking at
> it the wrong way ? I suppose I could split my project and have 2 modules, one
> simply being the standalone/shaded version of the other, but it seems
> overkill, since they're really the same source.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1034) dependencesToScan versus classifiers: what's the scoop?
[ https://jira.codehaus.org/browse/SUREFIRE-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies reassigned SUREFIRE-1034: -- Assignee: (was: Benson Margulies) > dependencesToScan versus classifiers: what's the scoop? > --- > > Key: SUREFIRE-1034 > URL: https://jira.codehaus.org/browse/SUREFIRE-1034 > Project: Maven Surefire > Issue Type: Bug >Reporter: Benson Margulies > Fix For: 3.0 > > > # The doc could really use an example of dependenciesToScan > # The doc should tell me the syntax for using classifiers > # if classifiers don't work, please make them work. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MWAR-284) overlay parameter documentation is missing
[ https://jira.codehaus.org/browse/MWAR-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies reassigned MWAR-284: - Assignee: (was: Benson Margulies) > overlay parameter documentation is missing > -- > > Key: MWAR-284 > URL: https://jira.codehaus.org/browse/MWAR-284 > Project: Maven WAR Plugin > Issue Type: Improvement > Components: overlay >Affects Versions: 2.2 >Reporter: Benson Margulies > > The doc for the overlays element is incomplete. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (ARCHETYPE-471) Make a final Maven 2.2.1 release
[ https://jira.codehaus.org/browse/ARCHETYPE-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated ARCHETYPE-471: --- Description: Release current state with prereqs amped up to 2.2.1. Fix Version/s: 2.3 > Make a final Maven 2.2.1 release > > > Key: ARCHETYPE-471 > URL: https://jira.codehaus.org/browse/ARCHETYPE-471 > Project: Maven Archetype > Issue Type: Task >Reporter: Benson Margulies > Fix For: 2.3 > > > Release current state with prereqs amped up to 2.2.1. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (ARCHETYPE-471) Make a final Maven 2.2.1 release
[ https://jira.codehaus.org/browse/ARCHETYPE-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies reassigned ARCHETYPE-471: -- Assignee: Benson Margulies > Make a final Maven 2.2.1 release > > > Key: ARCHETYPE-471 > URL: https://jira.codehaus.org/browse/ARCHETYPE-471 > Project: Maven Archetype > Issue Type: Task >Reporter: Benson Margulies >Assignee: Benson Margulies > Fix For: 2.3 > > > Release current state with prereqs amped up to 2.2.1. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-240) Generated sources directory should not be added to compiler's source roots
[
https://jira.codehaus.org/browse/MCOMPILER-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362373#comment-362373
]
Dave Roberge commented on MCOMPILER-240:
+1 - we are using dagger on one of our projects (which uses annotation
processors) and using version 3.2 causes this issue
> Generated sources directory should not be added to compiler's source roots
> --
>
> Key: MCOMPILER-240
> URL: https://jira.codehaus.org/browse/MCOMPILER-240
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.2
> Environment: Apache Maven 3.2.5
> (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00)
> Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
> Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
>Reporter: Tibor Varga
> Attachments: code-generation-test-case.tar.bz2,
> Generated_sources_directory_added_to_source_roots_after_compilation.patch
>
>
> I am using annotation processors with Maven and I keep getting errors when
> compiling with generated sources already present from a previous run.
> I have modified one of the test cases submitted for
> [MCOMPILER-157|http://jira.codehaus.org/browse/MCOMPILER-157] to induce the
> error by generating a source file _as source file_ rather than as a resource.
> Untar the test case and run {{mvn clean test -q && mvn test -q}} to verify.
> What I found is that {{AbstractCompilerMojo}} in version 3.2 of the compiler
> plugin adds the generated sources directory to the compiler's source root
> list, and that has two undesirable effects:
> # Sources generated in the previous run will be stale the next time around
> and cause recompilation.
> # The compiler will consider the previously generated source files to be
> initial inputs.
> The first one is mostly harmless but the second one is deadly, as it breaks
> the processing environment of the annotation processors.
> From the {{javax.annotation.Filer}} documentation in JDK 8:
> bq. "During each run of an annotation processing tool, a file with a given
> pathname may be created only once. Any subsequent attempt to create the same
> file during a run will throw a FilerException [...] The initial inputs to the
> tool are considered to be created by the zeroth round; therefore, attempting
> to create a source or class file corresponding to one of those inputs will
> result in a FilerException."
> Thus by adding the generated sources directory to the compiler's source
> roots, the compiler plugin causes annotation processors to inadvertently
> break their contract with the compiler.
> I get the expected behavior when lines 511-540 in {{AbstractCompilerMojo}}
> are moved after the compiler invocation, say to line 806. See the attached
> patch.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-169) Suppressions property is incorrectly set if suppressions file is on classpath
[
https://jira.codehaus.org/browse/MCHECKSTYLE-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362374#comment-362374
]
Dmitry Katsubo commented on MCHECKSTYLE-169:
Before v2.12 (that included this patch) it was possible to set
{{}} to some location, that does not necessarily exist in
particular project. This is handy e.g. during multi-module build, when some of
the projects have that file, and some ? don't. Now the location should exist.
How to make this setting optional (e.g. if suppressions file exists then it is
used, otherwise the build does not fail)?
> Suppressions property is incorrectly set if suppressions file is on classpath
> -
>
> Key: MCHECKSTYLE-169
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-169
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Sergei Ivanov
>Assignee: Dennis Lundberg
> Fix For: 2.12
>
> Attachments: MCHECKSTYLE-169-bugfix.patch, MCHECKSTYLE-169-it.patch
>
>
> If checkstyle plugin loads suppressions file from its classpath, and the
> checkstyle configuration contains suppression filter with a property
> placeholder, that property is not expanded because an incorrect path is used.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (ARCHETYPE-473) Add Apache Velocity Tools 2.0
Christian Schlichtherle created ARCHETYPE-473: - Summary: Add Apache Velocity Tools 2.0 Key: ARCHETYPE-473 URL: https://jira.codehaus.org/browse/ARCHETYPE-473 Project: Maven Archetype Issue Type: New Feature Components: Generator Affects Versions: 2.2 Reporter: Christian Schlichtherle This would allow to use fancy tools like $date et al. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (ARCHETYPE-472) Upgrade Apache Velocity Engine to 1.7
Christian Schlichtherle created ARCHETYPE-472: - Summary: Upgrade Apache Velocity Engine to 1.7 Key: ARCHETYPE-472 URL: https://jira.codehaus.org/browse/ARCHETYPE-472 Project: Maven Archetype Issue Type: Improvement Components: Generator Affects Versions: 2.2 Reporter: Christian Schlichtherle The Maven Archetype Plugin version 2.2 is depending on the Apache Velocity Engine 1.5, which is old. It should get updated to version 1.7 in order to support new features like #evaluate() et al. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (ARCHETYPE-474) .gitignore file is not copied to archetype JAR
Christian Schlichtherle created ARCHETYPE-474:
-
Summary: .gitignore file is not copied to archetype JAR
Key: ARCHETYPE-474
URL: https://jira.codehaus.org/browse/ARCHETYPE-474
Project: Maven Archetype
Issue Type: Bug
Components: Creator
Affects Versions: 2.2
Reporter: Christian Schlichtherle
In the file {{src/main/resources/META-INF/maven/archetype-metadata.xml}}, I
have something like this:
{code}
...
.*ignore
...
{code}
In the directory {{src/main/resources/archetype-resources}}, there are two
files {{.gitignore}} and {{.hgignore}}. Now when I create the archetype from
the resources, only the {{.hgignore}} file gets copied into the archetype, but
not the {{.gitignore}} file.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SCM-788) new goal to manipulate scm ignore metadata (e.g. .gitignore)
[
https://jira.codehaus.org/browse/SCM-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362384#comment-362384
]
jieryn commented on SCM-788:
{code:title=pom.xml}
maven-scm-plugin
ignore
.classpath
.idea
.project
.settings
target
*.iml
checkin
automatic scm:ignore for common junk
{code}
> new goal to manipulate scm ignore metadata (e.g. .gitignore)
>
>
> Key: SCM-788
> URL: https://jira.codehaus.org/browse/SCM-788
> Project: Maven SCM
> Issue Type: Improvement
>Reporter: jieryn
>Priority: Minor
>
> Please allow the plugin to manipulate and update standard SCM ignore
> metadata: .cvsignore, svn:ignore, .gitignore
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SCM-788) new goal to manipulate scm ignore metadata (e.g. .gitignore)
[
https://jira.codehaus.org/browse/SCM-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362385#comment-362385
]
jieryn commented on SCM-788:
Perhaps the scm:ignore goal should also accept {{rootModuleOnly=true|false}} as
well, because some SCMs can be applied to the entire SCM checkout.
> new goal to manipulate scm ignore metadata (e.g. .gitignore)
>
>
> Key: SCM-788
> URL: https://jira.codehaus.org/browse/SCM-788
> Project: Maven SCM
> Issue Type: Improvement
>Reporter: jieryn
>Priority: Minor
>
> Please allow the plugin to manipulate and update standard SCM ignore
> metadata: .cvsignore, svn:ignore, .gitignore
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1140) Support anchoring all test case names
Sean Griffin created SUREFIRE-1140: -- Summary: Support anchoring all test case names Key: SUREFIRE-1140 URL: https://jira.codehaus.org/browse/SUREFIRE-1140 Project: Maven Surefire Issue Type: New Feature Components: Maven Surefire Report Plugin Affects Versions: 2.18 Reporter: Sean Griffin Priority: Minor Attachments: anchor_test_case_names.patch The report includes anchors to test suite names but not test case names inside the suite. We would like the ability to externally link to individual test cases in the report. The anchor should be present whether the test case passes or fails. Patch with tests is included. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5760) All `-rf` to automatically resume from the last failure point
Phil Webb created MNG-5760:
--
Summary: All `-rf` to automatically resume from the last failure
point
Key: MNG-5760
URL: https://jira.codehaus.org/browse/MNG-5760
Project: Maven
Issue Type: Improvement
Components: Command Line
Affects Versions: 3.2.5
Reporter: Phil Webb
Priority: Trivial
Currently when a multi-module build fails the {{mvn}} command line prints the
following error:
{noformat}
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn -rf :some-module-name
{noformat}
Since I almost always want to use this flag with the next build it would be
very useful if you could type {{mvn -rf}} and have the project name
inferred from the last failure rather than needing to copy/paste from the
terminal.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (JXR-68) ignores classes with same name in other packages
[ https://jira.codehaus.org/browse/JXR-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte reopened JXR-68: --- The jxr-report of the [maven-compiler-plugin|http://maven.apache.org/plugins/maven-compiler-plugin/xref/index.html] shows this issue as well. Both packages contain the same classes (for backwards compatibility they weren't moved), but only the classes of the first package are shown. > ignores classes with same name in other packages > > > Key: JXR-68 > URL: https://jira.codehaus.org/browse/JXR-68 > Project: Maven JXR > Issue Type: Bug > Components: maven2 jxr plugin >Affects Versions: 2.1 >Reporter: Paul Sundling > > say you the following classes > package1/MyClass > package2/MyClass > While both will show up in javadocs plugin, only one will show up in JXR > report. > Let me know if you need a test case. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (ARCHETYPE-471) Make a final Maven 2.2.1 release
[ https://jira.codehaus.org/browse/ARCHETYPE-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362405#comment-362405 ] Benson Margulies commented on ARCHETYPE-471: commit 1656583: ARCHETYPE-471: update maven baseline to 2.2.1. all tests pass with versions bumped to 2.2.1. > Make a final Maven 2.2.1 release > > > Key: ARCHETYPE-471 > URL: https://jira.codehaus.org/browse/ARCHETYPE-471 > Project: Maven Archetype > Issue Type: Task >Reporter: Benson Margulies >Assignee: Benson Margulies > Fix For: 2.3 > > > Release current state with prereqs amped up to 2.2.1. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (ARCHETYPE-475) Each template file should have its own Velocity context
Christian Schlichtherle created ARCHETYPE-475:
-
Summary: Each template file should have its own Velocity context
Key: ARCHETYPE-475
URL: https://jira.codehaus.org/browse/ARCHETYPE-475
Project: Maven Archetype
Issue Type: Improvement
Components: Generator
Affects Versions: 2.2
Reporter: Christian Schlichtherle
Priority: Minor
Right now, when generating a project from an archetype, all template files are
merged with the same Velocity context. This has the side effect that changes to
the Velocity context in one template file are reflected in all subsequent
template files. Consider the following example:
{code}
#set ($foo = "bar")
{code}
This is a change to the Velocity context. Once it has been done, it's visible
in all template files which get subsequently merged with the global Velocity
context. This is bad because it's unexpected and uncontrollable because users
have no control over the order of processing.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (ARCHETYPE-435) Bad link to old docs in usage page
[ https://jira.codehaus.org/browse/ARCHETYPE-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed ARCHETYPE-435. -- Resolution: Fixed Assignee: Benson Margulies > Bad link to old docs in usage page > -- > > Key: ARCHETYPE-435 > URL: https://jira.codehaus.org/browse/ARCHETYPE-435 > Project: Maven Archetype > Issue Type: Bug > Components: Documentation >Affects Versions: 2.2 > Environment: online docs >Reporter: Anders Hammar >Assignee: Benson Margulies >Priority: Critical > Fix For: 2.3 > > > At the bottom of the usage page there is a link to the old docs, which > renders a Page Not Found. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (ARCHETYPE-475) Each template file should have its own Velocity context
[
https://jira.codehaus.org/browse/ARCHETYPE-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362407#comment-362407
]
Benson Margulies commented on ARCHETYPE-475:
How about a patch?
> Each template file should have its own Velocity context
> ---
>
> Key: ARCHETYPE-475
> URL: https://jira.codehaus.org/browse/ARCHETYPE-475
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Generator
>Affects Versions: 2.2
>Reporter: Christian Schlichtherle
>Priority: Minor
>
> Right now, when generating a project from an archetype, all template files
> are merged with the same Velocity context. This has the side effect that
> changes to the Velocity context in one template file are reflected in all
> subsequent template files. Consider the following example:
> {code}
> #set ($foo = "bar")
> {code}
> This is a change to the Velocity context. Once it has been done, it's visible
> in all template files which get subsequently merged with the global Velocity
> context. This is bad because it's unexpected and uncontrollable because users
> have no control over the order of processing.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (ARCHETYPE-464) Upgrade Plugin Required Maven Version to 2.2.1
[ https://jira.codehaus.org/browse/ARCHETYPE-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed ARCHETYPE-464. -- Resolution: Duplicate Fix Version/s: 2.3 > Upgrade Plugin Required Maven Version to 2.2.1 > -- > > Key: ARCHETYPE-464 > URL: https://jira.codehaus.org/browse/ARCHETYPE-464 > Project: Maven Archetype > Issue Type: Wish > Components: Plugin >Affects Versions: 2.2 >Reporter: Herve Boutemy >Assignee: Benson Margulies > Fix For: 2.3 > > > 2.2.1 is the unified minimum Maven version we're targetting > see > https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/dist-tool-prerequisites.html > for report -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (ARCHETYPE-469) Maven Failed to read artifact descriptor for org.codehaus.mojo:jaxb2-maven-plugin:jar:1.6 in pom.xml?
[ https://jira.codehaus.org/browse/ARCHETYPE-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed ARCHETYPE-469. -- Resolution: Not A Bug Assignee: Benson Margulies Please use the mailing list for support requests. > Maven Failed to read artifact descriptor for > org.codehaus.mojo:jaxb2-maven-plugin:jar:1.6 in pom.xml? > - > > Key: ARCHETYPE-469 > URL: https://jira.codehaus.org/browse/ARCHETYPE-469 > Project: Maven Archetype > Issue Type: Task > Components: Archetypes, Plugin >Reporter: Siva Prasad >Assignee: Benson Margulies > Attachments: consolelogEclipse.txt, errormaven.png, pom.xml > > > I have done a check out from svn as in Eclipse(luna) as "Checkout Maven > Project as SCM".After doing that i am getting g error in pom.xml.How to > resolve the error.?Below is the error...Please verifiy the attached file.How > to resole this error and what it means.? > Thank you... -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (ARCHETYPE-464) Upgrade Plugin Required Maven Version to 2.2.1
[ https://jira.codehaus.org/browse/ARCHETYPE-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies reassigned ARCHETYPE-464: -- Assignee: Benson Margulies > Upgrade Plugin Required Maven Version to 2.2.1 > -- > > Key: ARCHETYPE-464 > URL: https://jira.codehaus.org/browse/ARCHETYPE-464 > Project: Maven Archetype > Issue Type: Wish > Components: Plugin >Affects Versions: 2.2 >Reporter: Herve Boutemy >Assignee: Benson Margulies > Fix For: 2.3 > > > 2.2.1 is the unified minimum Maven version we're targetting > see > https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/dist-tool-prerequisites.html > for report -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (ARCHETYPE-464) Upgrade Plugin Required Maven Version to 2.2.1
[ https://jira.codehaus.org/browse/ARCHETYPE-464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362409#comment-362409 ] Benson Margulies commented on ARCHETYPE-464: I made the code changes marked with 471. > Upgrade Plugin Required Maven Version to 2.2.1 > -- > > Key: ARCHETYPE-464 > URL: https://jira.codehaus.org/browse/ARCHETYPE-464 > Project: Maven Archetype > Issue Type: Wish > Components: Plugin >Affects Versions: 2.2 >Reporter: Herve Boutemy >Assignee: Benson Margulies > Fix For: 2.3 > > > 2.2.1 is the unified minimum Maven version we're targetting > see > https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/dist-tool-prerequisites.html > for report -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (ARCHETYPE-475) Each template file should have its own Velocity context
[
https://jira.codehaus.org/browse/ARCHETYPE-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362410#comment-362410
]
Christian Schlichtherle commented on ARCHETYPE-475:
---
Sorry, it seems I won't have some time to spend on this within a reasonable
time frame.
> Each template file should have its own Velocity context
> ---
>
> Key: ARCHETYPE-475
> URL: https://jira.codehaus.org/browse/ARCHETYPE-475
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Generator
>Affects Versions: 2.2
>Reporter: Christian Schlichtherle
>Priority: Minor
>
> Right now, when generating a project from an archetype, all template files
> are merged with the same Velocity context. This has the side effect that
> changes to the Velocity context in one template file are reflected in all
> subsequent template files. Consider the following example:
> {code}
> #set ($foo = "bar")
> {code}
> This is a change to the Velocity context. Once it has been done, it's visible
> in all template files which get subsequently merged with the global Velocity
> context. This is bad because it's unexpected and uncontrollable because users
> have no control over the order of processing.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (ARCHETYPE-182) Adding 'role-hint' for the default Selector/Configurer/Queryer implementations
[ https://jira.codehaus.org/browse/ARCHETYPE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed ARCHETYPE-182. -- Resolution: Fixed Fix Version/s: 2.3 Assignee: Benson Margulies Commit 1656610. > Adding 'role-hint' for the default Selector/Configurer/Queryer implementations > -- > > Key: ARCHETYPE-182 > URL: https://jira.codehaus.org/browse/ARCHETYPE-182 > Project: Maven Archetype > Issue Type: Improvement > Components: Creator, Generator >Affects Versions: 2.0-alpha-3 >Reporter: Gert Vanthienen >Assignee: Benson Margulies > Fix For: 2.3 > > Attachments: archetype-default-role-hint.patch > > > With the current version of the Maven archetype plugin, it is not possible to > add a custom Selector/Configurer/Queryer implementation. > If I understand plexus correctly, adding a role-hint 'default' to the default > implementations would allow you to add an implementation with another > role-hint in your own pom.xml files as an extension to the > maven-archetype-plugin plugin. > This patch configures the role-hint attribute so it's generated in the > components.xml file -- This message was sent by Atlassian JIRA (v6.1.6#6162)
