[jira] [Created] (ARCHETYPE-633) A required class was missing while executing org.apache.maven.plugins:maven-archetype-plugin:3.1.1:generate: org/apache/commons/lang/StringUtils
Stefano Fornari created ARCHETYPE-633: - Summary: A required class was missing while executing org.apache.maven.plugins:maven-archetype-plugin:3.1.1:generate: org/apache/commons/lang/StringUtils Key: ARCHETYPE-633 URL: https://issues.apache.org/jira/browse/ARCHETYPE-633 Project: Maven Archetype Issue Type: Bug Environment: any Reporter: Stefano Fornari This issue seems to be still there. As described in [this SO article|https://stackoverflow.com/questions/56993067/maven-archetype-plugin-fails-with-classnotfoundexception], the pom misses a dependency on commons-lang... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] Updated: (SUREFIRE-121) System properties set on the command line get clobbered
[ http://jira.codehaus.org/browse/SUREFIRE-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Fornari updated SUREFIRE-121: - Attachment: testargs.zip Adding a simple project to reproduce the issue > System properties set on the command line get clobbered > --- > > Key: SUREFIRE-121 > URL: http://jira.codehaus.org/browse/SUREFIRE-121 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.0 (2.2 plugin) > Environment: Linux, Maven 2.0.4, Sun JDK 1.5U5, bash 3.0 >Reporter: Brenton Leanhardt >Priority: Critical > Fix For: Future > > Attachments: testargs.zip > > > Some system properties get clobbered if you set them on the command line. For > example, > mvn clean test -Dtest=LoginTest -Dselenium.user=test32 > The 'test' system property will work, but the 'selenium.user' property will > be null at runtime. I have tried: > * hard coding the system property in the unit test, this worked fine. > * setting the system properties in the pom file, this worked fine also. > * tried an older version of the surefire plugin, this worked fine. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRESOURCES-59) filtering with @property@
filtering with @property@ - Key: MRESOURCES-59 URL: http://jira.codehaus.org/browse/MRESOURCES-59 Project: Maven 2.x Resources Plugin Issue Type: Bug Affects Versions: 2.2 Reporter: Stefano Fornari >From the source code, it looks like @property@ should be expanded as well. It >does not work with the tests I've done -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRESOURCES-60) delimiter configuration
delimiter configuration
---
Key: MRESOURCES-60
URL: http://jira.codehaus.org/browse/MRESOURCES-60
Project: Maven 2.x Resources Plugin
Issue Type: New Feature
Reporter: Stefano Fornari
It would be great to be able to configure the delimiters of the properties
expansion. Something like:
...
@{}
to expand @{property}
It would also solve the problem of replacing unwanted variables in templates
(where ${} expansion is already used).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRESOURCES-60) delimiter configuration
[
http://jira.codehaus.org/browse/MRESOURCES-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127364
]
Stefano Fornari commented on MRESOURCES-60:
---
I can develop it if you are interested.
> delimiter configuration
> ---
>
> Key: MRESOURCES-60
> URL: http://jira.codehaus.org/browse/MRESOURCES-60
> Project: Maven 2.x Resources Plugin
> Issue Type: New Feature
>Reporter: Stefano Fornari
>
> It would be great to be able to configure the delimiters of the properties
> expansion. Something like:
>
> ...
> @{}
>
> to expand @{property}
> It would also solve the problem of replacing unwanted variables in templates
> (where ${} expansion is already used).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPJAVACC-5) Multiple grammar issue
Multiple grammar issue -- Key: MPJAVACC-5 URL: http://jira.codehaus.org/browse/MPJAVACC-5 Project: maven-javacc-plugin Issue Type: Bug Reporter: Stefano Fornari Attachments: JavaCCMojo.java, multi-grammar-2.patch Hi All, I have multiple grammar files, each going into a different package. Therefore, I cannot specify either the output directory nor the package. I created the attached pom, but when maven generates the parser, all source codes go in the same generated-files directory. Looking at the code of the plug-in, it looks like it is a limitation in the plug-in (please forgive me if I am saying an heresy, it is the first time I see a mojo... :) ). Therefore, I would like to propose a little change: the grammar is searched for a package declaration, if it is found it is used like if it was specified as plugin property. I would aslo skeep processing ig the output directory does not exist. This helps in specifying the plug-in in a parent project even if any of the subprojects does not have javacc grammars. Please see the attached pacth and class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
