[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-tabpanelfocusedCommentId=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-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-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-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)
[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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-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-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] (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-tabpanelfocusedCommentId=362374#comment-362374
]
Dmitry Katsubo commented on MCHECKSTYLE-169:
Before v2.12 (that included this patch) it was possible to set
{{suppressionsLocation}} 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] (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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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 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 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] (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] (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) taskdef/ 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: taskdef/ seems ignoring classpath (was: CLONE - taskdef/
seems ignoring classpath)
taskdef/ 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}
project name=testcase default=run
property name=maven.repository value=set repository location
here!/
property name=destdir value=target/generated-sources/
path id=xdoclet.classpath
fileset dir=${maven.repository}
include
name=commons-collections/commons-collections/3.1/commons-collections-3.1.jar/
include
name=commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar/
include
name=jboss/jboss-j2ee/4.0.2/jboss-j2ee-4.0.2.jar/
include name=xjavadoc/xjavadoc/1.1/xjavadoc-1.1.jar/
include
name=xdoclet/xdoclet/1.2.3/xdoclet-1.2.3.jar/
include
name=xdoclet/xdoclet-ejb-module/1.2.3/xdoclet-ejb-module-1.2.3.jar/
/fileset
/path
target name=run
!-- print classplath --
property refid=xdoclet.classpath name=cp/
echo message=xdoclet.classpath: ${cp}/
!-- define ejbdoclet task --
taskdef classname=xdoclet.modules.ejb.EjbDocletTask
classpathref=xdoclet.classpath name=ejbdoclet/
!-- run ejbdoclet --
ejbdoclet destdir=${destdir}
fileset includes=**/*Bean.java
dir=${basedir}/src/main/java/
remoteinterface/
/ejbdoclet
/target
/project
{code}
When executed directly from command (ant
-Dmaven.repository=/home/javor/.m2/repository) it works fine. But fails when
embedded in antrun:
{code:xml}
plugin
artifactIdmaven-antrun-plugin/artifactId
version1.2-SNAPSHOT/version
executions
execution
phasegenerate-sources/phase
goals
goalrun/goal
/goals
configuration
tasks
ant inheritRefs=true inheritall=true
antfile=build.xml
property name=maven.repository
value=${settings.localRepository}/
/ant
/tasks
/configuration
/execution
/executions
/plugin
{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 taskdef 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] (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-tabpanelfocusedCommentId=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] (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 scm config of: developerConnectionscm:git:ssh://g...@github.com:bbaetz/maven-release-bug.git/developerConnection 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] (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}
...
fileSets
fileSet filtered=false packaged=false
directory/
includes
include.*ignore/include
/includes
/fileSet
/fileSets
...
{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] (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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] (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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] (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-tabpanelfocusedCommentId=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] (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-tabpanelfocusedCommentId=362384#comment-362384
]
jieryn commented on SCM-788:
{code:title=pom.xml}
plugin
artifactIdmaven-scm-plugin/artifactId
executions
execution
goals
goalignore/goal
/goals
configuration
patterns
pattern.classpath/pattern
pattern.idea/pattern
pattern.project/pattern
pattern.settings/pattern
patterntarget/pattern
pattern*.iml/pattern
/patterns
/configuration
/execution
execution
goals
goalcheckin/goal
/goals
configuration
messageautomatic scm:ignore for common junk/message
/configuration
/execution
/executions
/plugin
{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] (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 goals -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 goals -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] (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] (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)
