[jira] Closed: (SUREFIRE-407) maven-invoker tests failed with surefire snapshot 2.4-20071210.231259-24
[ http://jira.codehaus.org/browse/SUREFIRE-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-407. - Resolution: Fixed This was due to a botched deploy (blame MSHADE-5 and MSHADE-6). The currently deployed snapshot works a lot better now. > maven-invoker tests failed with surefire snapshot 2.4-20071210.231259-24 > > > Key: SUREFIRE-407 > URL: http://jira.codehaus.org/browse/SUREFIRE-407 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.4 > Environment: cygwin/jdk1.4 >Reporter: Olivier Lamy > Attachments: stack.out > > > Just do > svn co https://svn.apache.org/repos/asf/maven/shared/trunk/maven-invoker && > cd maven-invoker && mvn test > The tests break. > fix the surefire plugin version in the it test-build-should-succeed and it > doesn't break. > Looks to be a class loading issue because the failure says compilation > failure. > The stack trace is attached. -- 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: (MRELEASE-303) Resolved SNAPSHOT versions are overwritten
Resolved SNAPSHOT versions are overwritten
--
Key: MRELEASE-303
URL: http://jira.codehaus.org/browse/MRELEASE-303
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-8
Reporter: Jean-Philippe Steck
When running release:prepare on a parent-child projet, I'm asked to resolved
the SNAPSHOT version but some of my answers are ignored.
Cause is :
In this method : CheckDependencySnapshotsPhase.resolveSnapshots
Lig 367 : releaseDescriptor.setResolvedSnapshotDependencies( resolvedSnapshots
);
This line overwrite the map of resolved snapshot of the releaseDescriptor :
The newly resolved informations should be added to the existing map.
It should be smthg like :
for (resolvedSnapshots ) {
if (! eleaseDescriptor.getResolvedSnapshotDependencies().contains(key))
releaseDescriptor.getResolvedSnapshotDependencies().put(resolvedSnapshots.key,
resolvedSnapshots .value)
}
--
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: (MRELEASE-304) Wrong version in development pom.xml
Wrong version in development pom.xml
Key: MRELEASE-304
URL: http://jira.codehaus.org/browse/MRELEASE-304
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-8
Reporter: Jean-Philippe Steck
In class : RewritePomsForDevelopmentPhase
Method :
---
protected Map getOriginalVersionMap( ReleaseDescriptor releaseDescriptor, List
reactorProjects )
{
return releaseDescriptor.getReleaseVersions();
}
Should be :
protected Map getOriginalVersionMap( ReleaseDescriptor releaseDescriptor,
List reactorProjects )
{
return releaseDescriptor.getOriginalVersions( reactorProjects );
}
--
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: (SUREFIRE-328) java.lang.NoClassDefFoundError: org/apache/maven/surefire/util/NestedRuntimeException
[ http://jira.codehaus.org/browse/SUREFIRE-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116470 ] Gerald Reinhart commented on SUREFIRE-328: -- Downloading: http://snapshots.repository.codehaus.org//org/apache/maven/surefire/surefire-booter/2.4-SNAPSHOT/surefire-booter-2.4-20071211.0 83739-25.pom [INFO] Surefire report directory: C:\Dev\projects\\target\surefire-reports java.lang.NoClassDefFoundError: org/apache/maven/surefire/util/NestedRuntimeException Exception in thread "main" [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Seems that the SNAPSHOT built today is not working very well... (I do not change anything: the build fail because of the new version of the SNAPSHOT) I'm using the 2.4-snapshot release because I use TestNG 5.5. Regards, Gerald > java.lang.NoClassDefFoundError: > org/apache/maven/surefire/util/NestedRuntimeException > - > > Key: SUREFIRE-328 > URL: http://jira.codehaus.org/browse/SUREFIRE-328 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.4 > Environment: Windows XP > Maven 2.0.6 >Reporter: Wim Deblauwe > Fix For: 2.4 > > > I just updated my surefire 2.4-SNAPSHOT plugin, but now I cannot build > anymore. I get a NoClassDefFoundError: > org/apache/maven/surefire/util/NestedRuntimeException. This is the console > output with the -e option: > >mvn -e clean test > [INFO] [surefire:test] > [INFO] Surefire report directory: C:\personal\vigilog\target\surefire-reports > java.lang.NoClassDefFoundError: > org/apache/maven/surefire/util/NestedRuntimeException > Exception in thread "main" > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] There are test failures. > [INFO] > > [INFO] Trace > org.apache.maven.BuildFailureException: There are test failures. > at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals > (DefaultLifecycleExecutor.java:560) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal > (DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments > (DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke (Method.java:597) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode > (Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoFailureException: There are test > failures. > at org.apache.maven.plugin.surefire.SurefirePlugin.execute > (SurefirePlugin.java:413) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java > :539) > ... 16 more > [INFO] > > [INFO] Total time: 6 seconds > [INFO] Finished at: Mon May 14 10:45:43 CEST 2007 > [INFO] Final Memory: 8M/25M > [INFO] > > I'm using the snapshot release because I use TestNG 5.5. Any solution to make > my build work again would be highly appriciated. > regards, > Wim -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrat
[jira] Commented: (MSHADE-7) Shade should generate code, not replace the jar
[ http://jira.codehaus.org/browse/MSHADE-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116471 ] Mauro Talevi commented on MSHADE-7: --- Dan, have you tried configuring a shaded attached artifact - as in src/test/projects/shaded-attached-project? That will create a new jar instead of replacing the original artifact. > Shade should generate code, not replace the jar > --- > > Key: MSHADE-7 > URL: http://jira.codehaus.org/browse/MSHADE-7 > Project: Maven 2.x Shade Plugin > Issue Type: Improvement >Reporter: Dan Fabulich > > I frequently get errors replacing the output jar. (That's MSHADE-5.) It > seems to me that it would be better if shade operated during the > generate-sources phase, dropping the generated dependencies into a > target/generated-sources directory. > That way I could write my code directly against the shaded classes (rather > than requiring shade do do the extra work of shading me as well). > That would have the benefit of not needing to replace the artifact at package > time, knocking out MSHADE-5, and making MSHADE-6 irrelevant as well. -- 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: (MAVENUPLOAD-1846) please upload YUIcompressor to central
please upload YUIcompressor to central -- Key: MAVENUPLOAD-1846 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1846 Project: maven-upload-requests Issue Type: Wish Reporter: nicolas de loof Yahoo UI Javascript compressor -- 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: (MJAR-49) Jarsigner fails on windows due to spaces in pathnames
[ http://jira.codehaus.org/browse/MJAR-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116473 ] Stanilslav Spiridonov commented on MJAR-49: --- Yes it works for me (with 2.2-20071210.234803-5) > Jarsigner fails on windows due to spaces in pathnames > - > > Key: MJAR-49 > URL: http://jira.codehaus.org/browse/MJAR-49 > Project: Maven 2.x Jar Plugin > Issue Type: Bug > Components: sign >Affects Versions: 2.1 > Environment: Windows XP >Reporter: Jon Tayler >Assignee: Olivier Lamy > Fix For: 2.2 > > Attachments: pathproblem.txt > > > This is a problem uncovered while running the latest (1.0-20060307.100605-1) > version of the webstart plugin, which uses the jar plugin to sign jars. > During the signing stage maven fails with > [debug] jarsigner executable=[C:\Program > Files\Java\jdk1.5.0_06\jre\..\bin\jarsigner.exe] > [debug] Signing JAR in-place (overwritting original JAR). > [warn] 'C:\Program' is not recognized as an internal or external command, > [warn] operable program or batch file. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Result of "C:\Program Files\Java\jdk1.5.0_06\jre\..\bin\jarsigner.exe" > -verbose -keystore "C:\Documents and Settings\jdt\.keystore" -storepass > ** -keypass ** > E:\jdt\data\workspace\tabview\tabview-webstart\target\jnlp\commons-logging-1.0.3.jar > roe execution is: '1'. > [INFO] > > (full trace is attached). > It looks as though the plexus utils classes are tokenizing the path to the > jarsigner executable wrongly due to it containing spaces. -- 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: (MRM-625) LDAP authentication leaks connections
LDAP authentication leaks connections - Key: MRM-625 URL: http://jira.codehaus.org/browse/MRM-625 Project: Archiva Issue Type: Bug Components: Users/Security Affects Versions: 1.0-beta-4 Environment: Archiva 1.0-beta-4, OpenLdap Reporter: Emilio Jose Mena Cebrian Priority: Minor I've configured redback to authenticate from a LDAP with cached used manager and I've detected it's leaking connections. Connections from web interface seem to be returned to LdapContext pool , but connection from repository servlet are leaked. The LdapCtx Configuration is : org.codehaus.plexus.redback.common.ldap.connection.LdapConnectionFactory configurable org.codehaus.plexus.redback.common.ldap.connection.ConfigurableLdapConnectionFactory localhost 389 com.sun.jndi.ldap.LdapCtxFactory *** com.sun.jndi.ldap.connect.pool true com.sun.jndi.ldap.connect.pool.maxsize 20 com.sun.jndi.ldap.connect.pool.prefsize 10 com.sun.jndi.ldap.connect.pool.timeout 3 NOTE: sensible configuration tags are correctly configured, but i'm erased them (marked with *) -- 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: (MAVENUPLOAD-1847) Please add Basher to the automatic synch process
Please add Basher to the automatic synch process Key: MAVENUPLOAD-1847 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1847 Project: maven-upload-requests Issue Type: Wish Reporter: johan lindquist Attachments: net.sourceforge.basher.sh Please find attached the script necessary to add the Basher project to the list of automatically synchronized repositories. I assume that the mavensync user is alredy setup to access the Sourceforge server? Thanks in advance and regards, Johan -- 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: (CONTINUUM-1601) Email address with '+' is not accepted in mail notifier
Email address with '+' is not accepted in mail notifier --- Key: CONTINUUM-1601 URL: http://jira.codehaus.org/browse/CONTINUUM-1601 Project: Continuum Issue Type: Bug Components: Web - UI Affects Versions: 1.1 Reporter: Marcin Zajaczkowski Priority: Minor It's unable to add email address including '+' (like [EMAIL PROTECTED]) for mail notifier (via " Add/Edit Mail Notifier" form). Displayed error "Address is invalid". The same email address can be added in other places like email address for user, so maybe it only problem with validation at WebUI level (not system wide restriction). -- 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: (CONTINUUM-1602) UTF-8 characters imported from POM aren't properly stored/displayed
UTF-8 characters imported from POM aren't properly stored/displayed
---
Key: CONTINUUM-1602
URL: http://jira.codehaus.org/browse/CONTINUUM-1602
Project: Continuum
Issue Type: Bug
Affects Versions: 1.1
Environment: Linux (Fedora 8), locale UTF-8, Tomcat and Jetty, Firefox
2.0.0.10
Reporter: Marcin Zajaczkowski
Priority: Minor
Attachments: pom.xml
UTF-8 characters in imported POM file (tested with adding Maven2 project)
aren't properly stored (or at least displayed).
How to reproduce:
1. Import attached POM.
2. Check developers for added project
3. There is '?' in developer name ("F?falski") instead of proper UTF-8 encoded
Polish character 'ą' ("Fąfalski").
Note:
Character encoding for Continuum pages is setting by default to ISO-8859-1
(which could be changed to UTF-8), but already in page source there is '?'
character (so maybe it's wrongly stored in a database? - here using default
Derby).
--
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: (MNG-3316) Barfs at attribues named .*encoding
Barfs at attribues named .*encoding
---
Key: MNG-3316
URL: http://jira.codehaus.org/browse/MNG-3316
Project: Maven 2
Issue Type: Bug
Components: POM::Encoding
Affects Versions: 2.0.8
Reporter: David J. M. Karlsen
Priority: Blocker
Attachments: examplepom.xml
With 2.0.8 a regression snuck in:
Please see attached pom for details.
In several of my project I use xdoclet-maven-plugin. In xdoclet-maven-plugin's
configuration element there is an element, with an attribute
xmlencoding="${variable}" (installed into my repository - NOT talking about
building them).
If maven tries to read these pom's (from my repo) it barfs with an error
message:
"
Project ID: some.group.id:myproject-war
Reason: Failed to build model from file
'c:\data\.m2\repository\some\group\id\myproject-war\1.3-SNAPSHOT\myproject-war-1.3-SNAPSHOT.pom'.
Error: '${ENCODING.DEFAULT}' for project some.group.id:myproject-war .
"
This did NOT happen before 2.0.8 - so it must be a regression.
What really puzzles me is why maven tries to parse these tags in the first
place (as they are configurations for elements which should be of no value for
this maven execution) - but I guess it was introduced when fixing MNG-2932,
MNG-2025 and/or MNG-2254 without knowing any details.
As 2.0.8 fails the entire build (which works on 2.0.7) I'm rating this as
Blocker.
--
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: (MNG-3316) Barfs at attribues named .*encoding
[
http://jira.codehaus.org/browse/MNG-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116497
]
David J. M. Karlsen commented on MNG-3316:
--
It should also be noted that if I remote the element containing the xmlencoding
attribute the build will succeed.
> Barfs at attribues named .*encoding
> ---
>
> Key: MNG-3316
> URL: http://jira.codehaus.org/browse/MNG-3316
> Project: Maven 2
> Issue Type: Bug
> Components: POM::Encoding
>Affects Versions: 2.0.8
>Reporter: David J. M. Karlsen
>Priority: Blocker
> Attachments: examplepom.xml
>
>
> With 2.0.8 a regression snuck in:
> Please see attached pom for details.
> In several of my project I use xdoclet-maven-plugin. In
> xdoclet-maven-plugin's configuration element there is an element, with an
> attribute xmlencoding="${variable}" (installed into my repository - NOT
> talking about building them).
> If maven tries to read these pom's (from my repo) it barfs with an error
> message:
> "
> Project ID: some.group.id:myproject-war
> Reason: Failed to build model from file
> 'c:\data\.m2\repository\some\group\id\myproject-war\1.3-SNAPSHOT\myproject-war-1.3-SNAPSHOT.pom'.
> Error: '${ENCODING.DEFAULT}' for project some.group.id:myproject-war .
> "
> This did NOT happen before 2.0.8 - so it must be a regression.
> What really puzzles me is why maven tries to parse these tags in the first
> place (as they are configurations for elements which should be of no value
> for this maven execution) - but I guess it was introduced when fixing
> MNG-2932, MNG-2025 and/or MNG-2254 without knowing any details.
> As 2.0.8 fails the entire build (which works on 2.0.7) I'm rating this as
> Blocker.
--
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] Closed: (MJAR-49) Jarsigner fails on windows due to spaces in pathnames
[ http://jira.codehaus.org/browse/MJAR-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MJAR-49. Resolution: Fixed Closed it due to positive feeback from user. Thanks for your tests. > Jarsigner fails on windows due to spaces in pathnames > - > > Key: MJAR-49 > URL: http://jira.codehaus.org/browse/MJAR-49 > Project: Maven 2.x Jar Plugin > Issue Type: Bug > Components: sign >Affects Versions: 2.1 > Environment: Windows XP >Reporter: Jon Tayler >Assignee: Olivier Lamy > Fix For: 2.2 > > Attachments: pathproblem.txt > > > This is a problem uncovered while running the latest (1.0-20060307.100605-1) > version of the webstart plugin, which uses the jar plugin to sign jars. > During the signing stage maven fails with > [debug] jarsigner executable=[C:\Program > Files\Java\jdk1.5.0_06\jre\..\bin\jarsigner.exe] > [debug] Signing JAR in-place (overwritting original JAR). > [warn] 'C:\Program' is not recognized as an internal or external command, > [warn] operable program or batch file. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Result of "C:\Program Files\Java\jdk1.5.0_06\jre\..\bin\jarsigner.exe" > -verbose -keystore "C:\Documents and Settings\jdt\.keystore" -storepass > ** -keypass ** > E:\jdt\data\workspace\tabview\tabview-webstart\target\jnlp\commons-logging-1.0.3.jar > roe execution is: '1'. > [INFO] > > (full trace is attached). > It looks as though the plexus utils classes are tokenizing the path to the > jarsigner executable wrongly due to it containing spaces. -- 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: (MRELEASE-305) release:prepare forgets a slash when changing the urls
release:prepare forgets a slash when changing the urls Key: MRELEASE-305 URL: http://jira.codehaus.org/browse/MRELEASE-305 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-7 Environment: Maven 2.0.8, JDK 1.6.0_01 Reporter: Boris Maras Attachments: TestRelease.zip In certain circumstances, the goal release:prepare incorrectly modifies the pom.xml that is commited in the tag. This goal is supposed to change the URLs in the part of the pom.xml files, to reflect the commited tag. For example, if you release a 1.2 version, it should replace scm:svn:svn://ntmestest01/TESTSVN14/testrelease/trunk/child/ with scm:svn:svn://ntmestest01/TESTSVN14/testrelease/tags/TestRelease-1.2/child In the attached test-case, you will see that the URL for the "child" module is changed to scm:svn:svn://ntmestest01/TESTSVN14/testrelease/tags/TestRelease-1.2child : a slash is missing between the tag name, and the module name. To reproduce, you need to commit that files on a scm, and run "mvn release:prepare". It will tag a version with this wrong URL for the child module. It seems to occur only with modules (the URLs in the master-pom are correct). It seems to occur ONLY if the master-pom scm url ends with a slash. So a workaround is simply to remove the last slash of the urls in the master-pom (they can be left in the child pom). This way, the generated poms are correct. I suppose there is a little bug in the string manipulation -- 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] Updated: (MRELEASE-305) release:prepare forgets a slash when changing the urls
[ http://jira.codehaus.org/browse/MRELEASE-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Maras updated MRELEASE-305: - Attachment: generated child pom.xml.jpg There should be a slash bewteen the tag name "TestRelease-1.2" and the module name "child" > release:prepare forgets a slash when changing the urls > > > Key: MRELEASE-305 > URL: http://jira.codehaus.org/browse/MRELEASE-305 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-7 > Environment: Maven 2.0.8, JDK 1.6.0_01 >Reporter: Boris Maras > Attachments: generated child pom.xml.jpg, TestRelease.zip > > > In certain circumstances, the goal release:prepare incorrectly modifies the > pom.xml that is commited in the tag. > This goal is supposed to change the URLs in the part of the pom.xml > files, to reflect the commited tag. > For example, if you release a 1.2 version, it should replace > scm:svn:svn://ntmestest01/TESTSVN14/testrelease/trunk/child/ with > scm:svn:svn://ntmestest01/TESTSVN14/testrelease/tags/TestRelease-1.2/child > In the attached test-case, you will see that the URL for the "child" module > is changed to > scm:svn:svn://ntmestest01/TESTSVN14/testrelease/tags/TestRelease-1.2child : a > slash is missing between the tag name, and the module name. > To reproduce, you need to commit that files on a scm, and run "mvn > release:prepare". It will tag a version with this wrong URL for the child > module. > It seems to occur only with modules (the URLs in the master-pom are correct). > It seems to occur ONLY if the master-pom scm url ends with a slash. > So a workaround is simply to remove the last slash of the urls in the > master-pom (they can be left in the child pom). This way, the generated poms > are correct. > I suppose there is a little bug in the string manipulation -- 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: (MNG-3317) i want to use filter option one of my txt file has multiple option like qa,prod,dev/
i want to use filter option one of my txt file has multiple option like qa,prod,dev/ Key: MNG-3317 URL: http://jira.codehaus.org/browse/MNG-3317 Project: Maven 2 Issue Type: Task Components: Dependencies Affects Versions: 2.0.8 Reporter: parlepoint hi guys, i have properties file having multiple option for qa,prd,dev. i would like to filtered with my option of qa /prd or dev. did anybody know how to apply filter in properties file. -- 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: (MSITE-277) site:deploy possibility to choose directory tree when using sub-modules
[
http://jira.codehaus.org/browse/MSITE-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116510
]
Benjamin Bentmann commented on MSITE-277:
-
I experienced this change, too, but it was not caused by
maven-site-plugin:2.0-beta-6 but actually by Maven itself after I updated to
2.0.8. The change is caused by the fix for MNG-3134 where they brought the URL
inheritance for the site in line with the other URL inheritance for SCM. In
other words, the directory layout of the site resembles the layout of the
source repository.
Isabelle, you need not wait for an option to get the old layout back. All that
happened is that Maven changed the default handling when inheriting
${project.distributionManagement.site.url}. You can put a
element in every of your sub POMs to specify the
desired location and overwrite the otherwise inherited URL.
Nevertheless, I would appreciate some kind of option like a new POM element,
too. Could imagine something like this:
{code:xml}
...
default|flat|nested
{code}
This would allow for a central configuration of the site layout and spare one
from copy&paste'ing in the sub POMs.
> site:deploy possibility to choose directory tree when using sub-modules
> ---
>
> Key: MSITE-277
> URL: http://jira.codehaus.org/browse/MSITE-277
> Project: Maven 2.x Site Plugin
> Issue Type: Improvement
> Components: site:deploy
>Affects Versions: 2.0-beta-6
>Reporter: Guimiot Isabelle
>Priority: Minor
>
> I use Eclipse and my modules (root and submodules) are all at the same level
> in the directory tree :
> [eclipse_workspace]/root
> [eclipse_workspace]/sub1
> [eclipse_workspace]/sub2
> Until the 2.0-beta-5 of the maven site plugin, when I deployed my site, I
> obtained this tree :
> [publish]/root
> [publish]/root/sub1
> [publish]/root/sub2
> I installed the beta-6 version, and the default behaviour has changed, I now
> have every module at the same level :
> [publish]/root
> [publish]/sub1
> [publish]/sub2
> So I just wondered if it was possible to have an option to choose whether we
> prefer to publish the submodules inside the root directory, or at the same
> level... ?
> thx
> Isabelle
--
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: (WAGONSSH-59) build error while building for a corporate
build error while building for a corporate -- Key: WAGONSSH-59 URL: http://jira.codehaus.org/browse/WAGONSSH-59 Project: wagon-ssh Issue Type: Bug Reporter: deepak chavan [INFO] [ERROR] BUILD ERROR [INFO] --- constituent[0]: file:/maven-2.0.6/lib/maven-core-2.0.6-uber.jar constituent[1]: file:/root/.m2/repository/org/apache/maven/wagon/wagon-ssh-common/1.0-beta-2/wagon-ssh-common-1.0-beta-2.jar --- java.lang.NullPointerException at org.apache.maven.usability.MojoExecutionExceptionDiagnoser.diagnose(MojoExecutionExceptionDiagnoser.java:64) at org.apache.maven.usability.diagnostics.ErrorDiagnostics.diagnose(ErrorDiagnostics.java:84) at org.apache.maven.DefaultMaven.logDiagnostics(DefaultMaven.java:711) at org.apache.maven.DefaultMaven.logError(DefaultMaven.java:656) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:131) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- 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: (MSHADE-7) Shade should generate code, not replace the jar
[ http://jira.codehaus.org/browse/MSHADE-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116518 ] Dan Fabulich commented on MSHADE-7: --- MSHADE-7 is a very different feature from shadedArtifactAttached. MSHADE-7 suggests that the generated classes just get dumped in with the regular classes, so I can just write my code directly against the shaded packages. In that case, there would be no separate shaded artifact; the main artifact would be the only artifact, and no need to replace. shadedArtifactAttached appends a new artifact with -shaded classifier, which isn't as helpful because the non-shaded artifact is usually trash. > Shade should generate code, not replace the jar > --- > > Key: MSHADE-7 > URL: http://jira.codehaus.org/browse/MSHADE-7 > Project: Maven 2.x Shade Plugin > Issue Type: Improvement >Reporter: Dan Fabulich > > I frequently get errors replacing the output jar. (That's MSHADE-5.) It > seems to me that it would be better if shade operated during the > generate-sources phase, dropping the generated dependencies into a > target/generated-sources directory. > That way I could write my code directly against the shaded classes (rather > than requiring shade do do the extra work of shading me as well). > That would have the benefit of not needing to replace the artifact at package > time, knocking out MSHADE-5, and making MSHADE-6 irrelevant as well. -- 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: (MSITE-271) Page title reads Introduction to $project.name
[
http://jira.codehaus.org/browse/MSITE-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116521
]
Benjamin Bentmann commented on MSITE-271:
-
>From the source of
>http://maven.apache.org/plugins/maven-site-plugin/index.html, i.e. the site of
>the maven-site-plugin, i.e. the site that should be the most wonderful among
>all plugins ;-)
{code:xml}
Maven Site plugin - Introduction to $project.name
...
{code}
The bad string "Introduction to $project.name" likely originates from
maven-site-plugin/src/site/apt/index.apt. I guess the APT title should just be
"Introduction" like used by many other plugins (the title is already prefixed
with the plugin name so why append again?).
As for the version: The generated pages only contain "Last published: ..." but
having the version number would be interesting, too. The funny thing is that
maven/plugins/trunk/src/site/site.xml already contains the required element, but it does not seem to make into the final site
(inheritance bug?).
> Page title reads Introduction to $project.name
> --
>
> Key: MSITE-271
> URL: http://jira.codehaus.org/browse/MSITE-271
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Reporter: Tim Pizey
>
> Number one for google search maven site plugin gives:
> Page title reads Introduction to $project.name
> Also still has no version in strap line.
> Maven is about versioning.
--
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: (MSITE-279) Inheritance of elements from site descriptor quite broken
Inheritance of elements from site descriptor quite broken - Key: MSITE-279 URL: http://jira.codehaus.org/browse/MSITE-279 Project: Maven 2.x Site Plugin Issue Type: Bug Components: inheritance Affects Versions: 2.0-beta-6 Environment: Maven 2.0.8, JDK 1.5.0_12, WinXP Reporter: Benjamin Bentmann Priority: Critical Attachments: project.zip After updating to 2.0-beta-6, I never get proper site output for multi module projects. I attached a simple dummy project that shall help to reproduce the problem. When I perform a reactor build of the site (i.e. "project-parent> mvn site"), the pages of the sub module project-module-1 properly inherit most of the decorator elements, except for the custom "overview" menu. That is, the site of the sub module contains the menu configured for the parent project despite the sub module specifying its own menu.- In contrast, when I only build the site of the sub module (i.e. "project-module-1> mvn site"), many decoration elements are not inherited from the parent's site.xml like , , , . However, now the sub module's site properly outputs its own menu items (i.e. "Module-Item" instead of "Parent-Item" for the attached projects). This issues might be a duplicate/relative of MSITE-256 but as I cannot safely judge from its description, I opened a new issue. -- 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] Closed: (MSHADE-5) Whenever I do a deploy and run the shade plugin, it's unable to replace the original jar
[ http://jira.codehaus.org/browse/MSHADE-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed MSHADE-5. - Resolution: Fixed Fix Version/s: 1.0-alpha-14 Fixed again in revisions 603267 603291 603295 > Whenever I do a deploy and run the shade plugin, it's unable to replace the > original jar > > > Key: MSHADE-5 > URL: http://jira.codehaus.org/browse/MSHADE-5 > Project: Maven 2.x Shade Plugin > Issue Type: Bug > Environment: Windows XP SP2, Java 1.5.0_12 >Reporter: Dan Fabulich >Priority: Blocker > Fix For: 1.0-alpha-14 > > > I tried to wire up the shade plugin in surefire trunk. About 50% of the time > I run the shade plugin I get a "[WARNING] Could not replace original artifact > with shaded artifact!" IMO that should halt the build, because it goes on to > use the stripped POM without using the shaded jar; hilarity ensues. -- 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] Updated: (MSITE-271) Page title reads Introduction to $project.name
[ http://jira.codehaus.org/browse/MSITE-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MSITE-271: Attachment: site-index.patch Proposed patch for the index.apt together with some further tweaks attached. > Page title reads Introduction to $project.name > -- > > Key: MSITE-271 > URL: http://jira.codehaus.org/browse/MSITE-271 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Tim Pizey > Attachments: site-index.patch > > > Number one for google search maven site plugin gives: > Page title reads Introduction to $project.name > Also still has no version in strap line. > Maven is about versioning. -- 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: (MGPG-11) upgrade to last plexus-utils (1.4.8) to work on platform without /bin/bash
upgrade to last plexus-utils (1.4.8) to work on platform without /bin/bash --- Key: MGPG-11 URL: http://jira.codehaus.org/browse/MGPG-11 Project: Maven 2.x GPG Plugin Issue Type: Bug Affects Versions: 1.0-alpha-4 Environment: freeBsd Reporter: Olivier Lamy Priority: Blocker The plugin need to upgrade p-u version in order to work on platform without /bin/bash (freeBsd) -- 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] Closed: (MGPG-11) upgrade to last plexus-utils (1.4.8) to work on platform without /bin/bash
[ http://jira.codehaus.org/browse/MGPG-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MGPG-11. Resolution: Fixed Fix Version/s: 1.0.beta-1 fix in rev 603370. > upgrade to last plexus-utils (1.4.8) to work on platform without /bin/bash > --- > > Key: MGPG-11 > URL: http://jira.codehaus.org/browse/MGPG-11 > Project: Maven 2.x GPG Plugin > Issue Type: Bug >Affects Versions: 1.0-alpha-4 > Environment: freeBsd >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Blocker > Fix For: 1.0.beta-1 > > > The plugin need to upgrade p-u version in order to work on platform without > /bin/bash (freeBsd) -- 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: (MAVENUPLOAD-1792) 4.1 Release of Dozer
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116549 ] Craig commented on MAVENUPLOAD-1792: What is the status of this update? Dozer 4.1 fixes a number of issues, some of which I have encountered. What can I do to help move this along? Thanks! > 4.1 Release of Dozer > > > Key: MAVENUPLOAD-1792 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1792 > Project: maven-upload-requests > Issue Type: Task >Reporter: Franz Garsombke >Assignee: Carlos Sanchez > Attachments: dozer-4.1-bundle.jar > > > I have attached the bundle to this Jira Request. > The source can be found at: > http://sourceforge.net/project/showfiles.php?group_id=133517 -- 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] Updated: (MNG-1914) Wrong url in error message when using a mirror
[ http://jira.codehaus.org/browse/MNG-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak updated MNG-1914: - Summary: Wrong url in error message when using a mirror (was: Wrong error message when using a mirror) > Wrong url in error message when using a mirror > -- > > Key: MNG-1914 > URL: http://jira.codehaus.org/browse/MNG-1914 > Project: Maven 2 > Issue Type: Bug > Components: Errors >Affects Versions: 2.0.1 >Reporter: Vincent Massol > Fix For: 2.1 > > > I had the following in my settings.xml: > > [...] > > > cargo m2 release repository > http://cargo.codehaus.org/dist2 > central > > > > > staging-repo > > > central > staging repo > http://test.maven.codehaus.org/maven2 > > true > > > true > > > > > > central > staging repo > http://test.maven.codehaus.org/maven2 > > true > > > true > > > > > > > staging-repo > > [...] > > When building any project I was getting the following console trace: > [...] > Downloading: > http://cargo.codehaus.org/dist2/org/apache/maven/plugins/maven-plugin-parent/2.0/maven-plugin-parent-2.0.pom > [WARNING] Unable to get resource from repository central > (http://test.maven.codehaus.org/maven2) > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > > GroupId: org.apache.maven.plugins > ArtifactId: maven-plugin-parent > Version: 2.0 > > Reason: Unable to download the artifact from any repository > > org.apache.maven.plugins:maven-plugin-parent:pom:2.0 > > from the specified remote repositories: > central (http://test.maven.codehaus.org/maven2) > As you can see it says that it cannot get the pom from the > test.maven.codehaus.org repository whereas it's actually looking in > cargo.codehaus.org... The message needs to be fixed. -- 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: (MAVENUPLOAD-1848) Add SwiXML 1.4.149
Add SwiXML 1.4.149 -- Key: MAVENUPLOAD-1848 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1848 Project: maven-upload-requests Issue Type: Task Reporter: Steve Taylor The file in "Bundle URL" isn't a maven bundle per se, but the jar file can be found in the /build directory of the project and the pom is in the root directory. The jar just needs to be renamed according to convention. -- 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: (MAVENUPLOAD-1848) Add SwiXML 1.4.149
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116556 ] Steve Taylor commented on MAVENUPLOAD-1848: --- Version should be 1.5.149. > Add SwiXML 1.4.149 > -- > > Key: MAVENUPLOAD-1848 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1848 > Project: maven-upload-requests > Issue Type: Task >Reporter: Steve Taylor > > The file in "Bundle URL" isn't a maven bundle per se, but the jar file can be > found in the /build directory of the project and the pom is in the root > directory. The jar just needs to be renamed according to convention. -- 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: (MAVENUPLOAD-1849) Add SwiXML 1.6.151
Add SwiXML 1.6.151 -- Key: MAVENUPLOAD-1849 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1849 Project: maven-upload-requests Issue Type: Task Reporter: Steve Taylor The file in "Bundle URL" isn't a maven bundle per se, but the jar file can be found in the /build directory of the project and the pom is in the root directory. The jar just needs to be renamed according to convention. -- 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: (MASSEMBLY-256) Regression: pom properties are no longer expanded in descriptor.
Regression: pom properties are no longer expanded in descriptor.
Key: MASSEMBLY-256
URL: http://jira.codehaus.org/browse/MASSEMBLY-256
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-2
Environment: maven 2.0.8
windows xp sp2
Reporter: Mark Reynolds
Attachments: assembly-issue.zip
Attached is a minimal project which demonstrates this issue.
The pom contains a property:
...
file/path
The descriptor uses this property in specifying the output directory for a
fileSet:
...
src/main/files
${fileLocation}
In versions 2.1, 2.2-beta-1, and 2.2-SNAPSHOT of the assembly plugin, this
property is expanded so the resulting archive has files in file/path/
In the latest 2.2-beta-2-SNAPSHOT, the resulting archive has files in
${fileLocation}/...
--
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: (MAVENUPLOAD-1850) Please upload DWR 2.0.2 to maven repo
Please upload DWR 2.0.2 to maven repo - Key: MAVENUPLOAD-1850 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1850 Project: maven-upload-requests Issue Type: Bug Reporter: Brendan Grainger Attachments: dwr-2.0.2-bundle.jar Hi, Please upload dwr 2.0.2 to the central repository. DWR2 has been uploaded previously. I've attached the bundle and it is also available on the project page at java.net. Please let me know if there are any issues. Also, I see you want people to set up automatic syncing of releases. I'll try to get that set up for our next release. I don't suppose you know of people syncing from java.net? No worries if not, I think I can do it via sourceforge. Regards Brendan Grainger -- 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-8) maven-resources-plugin ignores configuration/resources property
[
http://jira.codehaus.org/browse/MRESOURCES-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116564
]
Samuel Le Berrigaud commented on MRESOURCES-8:
--
Any activity on this issue:
I just ran into this today. Needed to copy/process some resources before the
integration phase but impossible to set the resource directory. As suggested
there should either:
* be the possibility to specify resources to include
* or a separate mojo that would copy any resource to any directory.
Our work around for the moment, using ANT, not really nice...
> maven-resources-plugin ignores configuration/resources property
> ---
>
> Key: MRESOURCES-8
> URL: http://jira.codehaus.org/browse/MRESOURCES-8
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Reporter: Leszek Gawron
>Assignee: Brett Porter
> Attachments: example.zip, MRESOURCES-8-workaround.patch, pom.xml
>
>
> I am evaluating maven + eclipse combo. In a trivial POM filtered resources
> exist only in target/classes. If one executes Project -> Clean under eclipse
> this information is lost. If filtered resources would appear as source folder
> they would survive cleaning and not got overriden by unfiltered ones.
> I have been trying to implement a scenario which would allow filtered
> resources to appear as "static" source folder under eclipse.
> The POM explains it best:
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> com.mobilebox.squash.client
> squash-client
> jar
> 1.0-SNAPSHOT
> Maven Quick Start Archetype
> http://maven.apache.org
>
>
>
> maven-resources-plugin
>
>
> prefilter-resources
> generate-resources
>
> resources
>
>
>
> target/generated-resources
>
>
>
> src/main/resource-templates
> true
>
>
>
>
>
>
>
>
> ${ffile}
>
>
>
> src/main/resources
>
>
> target/generated-resources
>
>
>
>
>
> junit
> junit
> 3.8.1
> test
>
>
>
> filter.properties
>
>
> thing is this part:
>
>
> src/main/properties
> true
>
>
> is completely ignored. Instead for both maven-resource-plugin executions (the
> one in generate-resources phase and the default one) this config is used:
>
>
> src/main/resources
>
>
> target/generated-resources
>
>
> which of course breaks the whole idea.
> Is this a bug or a design decision. In latter case is there any equivalent
> approach I might take?
--
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
