[jira] Commented: (MASSEMBLY-264) Filtering in Assembly Generates Blank Files in the Archive
[ http://jira.codehaus.org/browse/MASSEMBLY-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147313#action_147313 ] Neill Alexander commented on MASSEMBLY-264: --- Hi Petar, I can't reproduce it either. I've retested with the original build, and it's all working fine with 2.2-beta-2. And it looks like it was working on my test project as well when I reported it. Apologies. I must have been suffering from brain freeze when I reported this. Neill > Filtering in Assembly Generates Blank Files in the Archive > -- > > Key: MASSEMBLY-264 > URL: http://jira.codehaus.org/browse/MASSEMBLY-264 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 >Reporter: Neill Alexander > Fix For: 2.2-beta-3 > > Attachments: maven-assembly-plugin-bug-test.tar.gz > > > When filers are filtered during assembly, the result is an empty file in the > archive (see output from unzip below): > $ unzip -l assembly-bug-1.0.0-SNAPSHOT-buggy.zip > Archive: assembly-bug-1.0.0-SNAPSHOT-buggy.zip > Length Date TimeName > > 0 15/01/08 13:05 assembly-bug-1.0.0-SNAPSHOT/ > 0 15/01/08 13:05 assembly-bug-1.0.0-SNAPSHOT/bin/ > 0 15/01/08 13:05 assembly-bug-1.0.0-SNAPSHOT/bin/test.ini > --- > 0 3 files > This appears to be a result of some recent changes to the > src/main/java/org/apache/maven/plugin/assembly/archive/task/AddFileSetsTask.java > file (changeset 591556) which deletes the files from the temporary > directory. The problem with this is that the archive object has a reference > to the filtered files in the temporary directory. When the call to > archive.createArchive( ) is made it can't find the filtered files, and > therefore they end up empty in the archive. > The attached archive contains a test maven project you can run which will > demonstrate this bug. Run 'mvn clean assembly:assembly' and check out the > contents of target/assembly-bug-1.0.0-SNAPSHOT-buggy.zip > The simply fix is simply to roll-back the 'finally' clause added as part of > 591556 to > src/main/java/org/apache/maven/plugin/assembly/archive/task/AddFileSetsTask.java. > Whether or not it is the best fix, I don't know (hence the absence of a > patch). -- 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: (MWAR-169) NPE during packaging.
[ http://jira.codehaus.org/browse/MWAR-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147323#action_147323 ] Jonathan Ramsey commented on MWAR-169: -- This problem occurs when you run any of the goals on version 2.1-alpha-2 of the maven-war-plugin after running any of the goals on version 2.1-alpha-1, without a clean of the project between. The change in version might occur without you knowing if you hadn't explictely set the version of maven-war-plugin in your pom.xml. Your first run of a war:goal occur prior to the release of 2.1-alpha-2, and your second run of a war:goal your first goal was run before 2.1-alpha-2 was released, and your second goal was run after 2.1-alpha-2 was released and you hadn't explictely set the version of maven-war-plugin in your pom.xml. The problem is caused because a dependenciesInfo variable was added to org.apache.maven.plugin.war.util.WebappStructure in r606628, but no defensive initialization of the variable was added to the readResolve() method. r606628 was released in maven-war-plugin version 2.1-alpha-2. http://svn.apache.org/viewvc/maven/plugins/tags/maven-war-plugin-2.1-alpha-2/src/main/java/org/apache/maven/plugin/war/util/WebappStructure.java?view=diff&r1=606627&r2=606628 When one of the war goals is executed, maven-war-plugin 2.1-alpha-1 uses XStream to serialize a WebappStructure object to target\war\work\webapp-cache.xml. Provided you haven't cleaned your project, when you next run one of the war goals the maven-war-plugin 2.1-alpha-2 deserializes the WebappStructure object from target\war\work\webapp-cache.xml. The dependenciesInfo variable is not initialized with a value because the webapp-cache.xml doesn't contain a element and the readResolve() method doesn't initialize the variable defensively. When the WebappStructure.getDependencies() method is invoked, dependenciesInfo is dereferenced which triggers a NullPointerException. Steps to reproduce: 1. mvn archetype:create -DarchetypeArtifactId=maven-archetype-webapp -DarchetypeVersion=1.0 -DgroupId=test -DartifactId=webapp 2. cd webapp 3. Add this to in pom.xml. org.apache.maven.plugins maven-war-plugin 2.1-alpha-1 4. mvn package 5. Change version from 2.1-alpha-1 to 2.1-alpha-2 6. mvn package You reproduce the error: [INFO] Scanning for projects... [INFO] [INFO] Building webapp Maven Webapp [INFO]task-segment: [package] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] No sources to compile [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] No sources to compile [INFO] [surefire:test] [INFO] No tests to run. [INFO] [war:war] [INFO] Packaging webapp [INFO] Assembling webapp[webapp] in [C:\WebTeam\projects\webapp\target\webapp] [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.plugin.war.util.WebappStructure.getDependencies(WebappStructure.java:109) at org.apache.maven.plugin.war.util.WebappStructure.analyseDependencies(WebappStructure.java:288) at org.apache.maven.plugin.war.packaging.DependenciesAnalysisPackagingTask.performPackaging(DependenciesAnalysisPackagingTask.java:46) at org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:439) at org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:375) at org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:181) at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:143) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) 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.mave
[jira] Issue Comment Edited: (MWAR-169) NPE during packaging.
[ http://jira.codehaus.org/browse/MWAR-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147323#action_147323 ] jonathan.ramsey edited comment on MWAR-169 at 9/8/08 8:26 AM: -- This problem occurs when you run any of the goals on version 2.1-alpha-2 of the maven-war-plugin after running any of the goals on version 2.1-alpha-1, without a clean of the project in between. The change in version might occur without you knowing if you hadn't explicitly set the version of maven-war-plugin in your pom.xml. The first war goal is executed prior to the release of 2.1-alpha-2, and the second war goal is executed after 2.1-alpha-2 was released. The problem is caused because a dependenciesInfo variable was added to org.apache.maven.plugin.war.util.WebappStructure in [r606628|http://svn.apache.org/viewvc/maven/plugins/tags/maven-war-plugin-2.1-alpha-2/src/main/java/org/apache/maven/plugin/war/util/WebappStructure.java?view=diff&r1=606627&r2=606628], but no defensive initialization of the variable was added to the readResolve() method. r606628 was released in maven-war-plugin version 2.1-alpha-2. When one of the war goals is executed, maven-war-plugin 2.1-alpha-1 uses XStream to serialize a WebappStructure object to target\war\work\webapp-cache.xml. Provided you haven't cleaned your project, when you next run one of the war goals the maven-war-plugin 2.1-alpha-2 deserializes the WebappStructure object from target\war\work\webapp-cache.xml. The dependenciesInfo variable is not initialized with a value because the webapp-cache.xml doesn't contain a element and the readResolve() method doesn't initialize the variable defensively. When the WebappStructure.getDependencies() method is invoked, dependenciesInfo is dereferenced which triggers a NullPointerException. Steps to reproduce: 1. mvn archetype:create -DarchetypeArtifactId=maven-archetype-webapp -DarchetypeVersion=1.0 -DgroupId=test -DartifactId=webapp 2. cd webapp 3. Add this to in pom.xml. org.apache.maven.plugins maven-war-plugin 2.1-alpha-1 4. mvn package 5. Change version from 2.1-alpha-1 to 2.1-alpha-2 6. mvn package You reproduce the error: [INFO] Scanning for projects... [INFO] [INFO] Building webapp Maven Webapp [INFO]task-segment: [package] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] No sources to compile [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] No sources to compile [INFO] [surefire:test] [INFO] No tests to run. [INFO] [war:war] [INFO] Packaging webapp [INFO] Assembling webapp[webapp] in [C:\WebTeam\projects\webapp\target\webapp] [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.plugin.war.util.WebappStructure.getDependencies(WebappStructure.java:109) at org.apache.maven.plugin.war.util.WebappStructure.analyseDependencies(WebappStructure.java:288) at org.apache.maven.plugin.war.packaging.DependenciesAnalysisPackagingTask.performPackaging(DependenciesAnalysisPackagingTask.java:46) at org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:439) at org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:375) at org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:181) at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:143) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) 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:12
[jira] Commented: (MSITE-30) site:deploy incompatibilities with m1.02
[ http://jira.codehaus.org/browse/MSITE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147326#action_147326 ] Paul Spencer commented on MSITE-30: --- Dennis, I object to this issue be downgraded from a BUG since the desired behavior worked in a prior version of the plugin. Although have installed unzip on my HP-UX box to get around the problem #1 of the issue, I continue to have an issues with the chmod command. Paul Spencer > site:deploy incompatibilities with m1.02 > > > Key: MSITE-30 > URL: http://jira.codehaus.org/browse/MSITE-30 > Project: Maven 2.x Site Plugin > Issue Type: Improvement > Components: site:deploy > Environment: All >Reporter: Paul Spencer > Fix For: 2.0-beta-8 > > > Deploying a site in m2 has changed since m1. > 1) m1 used the "tar" and "gunzip" command on the remote site, where m2 uses > the "unzip" command. This poses a problem for be since my remote site does > not support the "unzip" command, thus making the "priority" of this issue > major > 1.1) Their may be desire to deploy without the use of tools like tar and zip > on some site. The deploy would esentailly be a recersive copy > 2) No equivelent to m1 property maven.site.chmod.mode. I use this to allow > other member is the group update and delete permission > 3) No equivelent to m1 property maven.site.publish.clean > Their are other properties for the m1.02 not mentioned above, but I suspect > the they can be calculated from m2 files, i.e. pom.xml and settings.xml. > Paul Spencer -- 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-3745) help:effective-pom should be available through an API
help:effective-pom should be available through an API - Key: MNG-3745 URL: http://jira.codehaus.org/browse/MNG-3745 Project: Maven 2 Issue Type: Improvement Components: General Reporter: Jason Smith When building tools around Maven 2, you need to be able to read the effective POM. Currently, the only obvious way to do this is to run help:effective-pom as a process and capture the output, parsing out the XML portion. It would be useful to have an API version of effective-POM, which returned the effective POM of an artifact either as a String or a DOM Document. Take your pick. I'm not choosy. And if this already exists, it probably ought to be documented a little better. :-) Thanks. -- 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: (MNG-3743) pluginManagement not consulted when building from lifecycle forked via javdoc reports
[ http://jira.codehaus.org/browse/MNG-3743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3743. --- Resolution: Fixed executionProject was not being used to verify plugins in a forked lifecycle. This meant that when pluginManagement information was injected, it was added to a project instance that wasn't actually being used to execute the plugin, and the plugin never saw the injected configuration parameters. > pluginManagement not consulted when building from lifecycle forked via javdoc > reports > - > > Key: MNG-3743 > URL: http://jira.codehaus.org/browse/MNG-3743 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.1.0-M1 >Reporter: John Casey >Assignee: John Casey >Priority: Blocker > Fix For: 2.1.0-M1 > > > if you use java5 generics or java 1.4 assertions, and you have the compiler > plugin configured with source and target parameters inside a plugin entry in > the pluginManagement section of the POM, this configuration is not used when > building from a forked lifecycle spawned from a report. The classic example > here is the javadoc reports, which trigger the compilation of sources (for > some reason). -- 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: (SCM-406) scm tag does not work with Subversion 1.5.1
[
http://jira.codehaus.org/browse/SCM-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147352#action_147352
]
Grégory Joseph commented on SCM-406:
Has anyone had a chance to test with a 1.5.2 client ? (source released Aug
30th, no binary for osx yet, afaik)
> scm tag does not work with Subversion 1.5.1
> ---
>
> Key: SCM-406
> URL: http://jira.codehaus.org/browse/SCM-406
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 1.0
>Reporter: James William Dumay
> Fix For: 1.1.1
>
>
> scm:checkin does not work with Subversion 1.5.1
> On release:perform (which I assume calls scm:checkin) the following error
> occurs:
> {code}
> svn: File
> '/svn/private/atlassian/confluence/tags/confluence-project-2.10-m1/conf-acceptance-test/pom.xml'
> already exists
> {code}
> Using subversion 1.4.x is a good enough workaround.
--
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-3746) POM properties do not override default system properties during POM interpolation
POM properties do not override default system properties during POM
interpolation
-
Key: MNG-3746
URL: http://jira.codehaus.org/browse/MNG-3746
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 2.1.0-M1
Reporter: John Casey
Priority: Blocker
>From Paul Benedict, on the maven dev list:
{noformat}
My issue might be related to MNG-3535.
I defined this property:
1.6
And used it in my compiler plugin:
org.apache.maven.plugins
maven-compiler-plugin
${java.version}
${java.version}
I know this use to work before 2.0.10, but now it does not.
[INFO] Compilation failure
Failure executing javac, but could not parse the error:
javac: invalid target release: 1.6.0_06
Usage: javac
use -help for a list of possible options
The error here is that ${java.version} is not the value I specified,
but one that already exists.
Paul
{noformat}
I've replicated the problem in a separate test mock-up project.
--
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-3746) POM properties do not override default system properties during POM interpolation
[
http://jira.codehaus.org/browse/MNG-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MNG-3746:
Assignee: John Casey
Fix Version/s: 2.1.0-M1
> POM properties do not override default system properties during POM
> interpolation
> -
>
> Key: MNG-3746
> URL: http://jira.codehaus.org/browse/MNG-3746
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.1.0-M1
>Reporter: John Casey
>Assignee: John Casey
>Priority: Blocker
> Fix For: 2.1.0-M1
>
>
> From Paul Benedict, on the maven dev list:
> {noformat}
> My issue might be related to MNG-3535.
> I defined this property:
> 1.6
> And used it in my compiler plugin:
>
> org.apache.maven.plugins
> maven-compiler-plugin
>
> ${java.version}
> ${java.version}
>
>
> I know this use to work before 2.0.10, but now it does not.
> [INFO] Compilation failure
> Failure executing javac, but could not parse the error:
> javac: invalid target release: 1.6.0_06
> Usage: javac
> use -help for a list of possible options
> The error here is that ${java.version} is not the value I specified,
> but one that already exists.
> Paul
> {noformat}
> I've replicated the problem in a separate test mock-up project.
--
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] Work started: (MNG-3746) POM properties do not override default system properties during POM interpolation
[
http://jira.codehaus.org/browse/MNG-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on MNG-3746 started by John Casey.
> POM properties do not override default system properties during POM
> interpolation
> -
>
> Key: MNG-3746
> URL: http://jira.codehaus.org/browse/MNG-3746
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.1.0-M1
>Reporter: John Casey
>Assignee: John Casey
>Priority: Blocker
> Fix For: 2.1.0-M1
>
>
> From Paul Benedict, on the maven dev list:
> {noformat}
> My issue might be related to MNG-3535.
> I defined this property:
> 1.6
> And used it in my compiler plugin:
>
> org.apache.maven.plugins
> maven-compiler-plugin
>
> ${java.version}
> ${java.version}
>
>
> I know this use to work before 2.0.10, but now it does not.
> [INFO] Compilation failure
> Failure executing javac, but could not parse the error:
> javac: invalid target release: 1.6.0_06
> Usage: javac
> use -help for a list of possible options
> The error here is that ${java.version} is not the value I specified,
> but one that already exists.
> Paul
> {noformat}
> I've replicated the problem in a separate test mock-up project.
--
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: (SCM-406) scm tag does not work with Subversion 1.5.1
[
http://jira.codehaus.org/browse/SCM-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147355#action_147355
]
Grégory Joseph commented on SCM-406:
Good news, I guess: using the macports.org port of the subversion client 1.5.2,
this now seems to work.
> scm tag does not work with Subversion 1.5.1
> ---
>
> Key: SCM-406
> URL: http://jira.codehaus.org/browse/SCM-406
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 1.0
>Reporter: James William Dumay
> Fix For: 1.1.1
>
>
> scm:checkin does not work with Subversion 1.5.1
> On release:perform (which I assume calls scm:checkin) the following error
> occurs:
> {code}
> svn: File
> '/svn/private/atlassian/confluence/tags/confluence-project-2.10-m1/conf-acceptance-test/pom.xml'
> already exists
> {code}
> Using subversion 1.4.x is a good enough workaround.
--
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-30) site:deploy incompatibilities with m1.02
[ http://jira.codehaus.org/browse/MSITE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147356#action_147356 ] Dennis Lundberg commented on MSITE-30: -- Paul, When you say "a prior version", do you mean it used to work in M1? > site:deploy incompatibilities with m1.02 > > > Key: MSITE-30 > URL: http://jira.codehaus.org/browse/MSITE-30 > Project: Maven 2.x Site Plugin > Issue Type: Improvement > Components: site:deploy > Environment: All >Reporter: Paul Spencer > Fix For: 2.0-beta-8 > > > Deploying a site in m2 has changed since m1. > 1) m1 used the "tar" and "gunzip" command on the remote site, where m2 uses > the "unzip" command. This poses a problem for be since my remote site does > not support the "unzip" command, thus making the "priority" of this issue > major > 1.1) Their may be desire to deploy without the use of tools like tar and zip > on some site. The deploy would esentailly be a recersive copy > 2) No equivelent to m1 property maven.site.chmod.mode. I use this to allow > other member is the group update and delete permission > 3) No equivelent to m1 property maven.site.publish.clean > Their are other properties for the m1.02 not mentioned above, but I suspect > the they can be calculated from m2 files, i.e. pom.xml and settings.xml. > Paul Spencer -- 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] Issue Comment Edited: (SCM-406) scm tag does not work with Subversion 1.5.1
[
http://jira.codehaus.org/browse/SCM-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147355#action_147355
]
gjoseph edited comment on SCM-406 at 9/8/08 1:38 PM:
Good news, I guess: using the macports.org port of the subversion client 1.5.2,
this now seems to work.
edit: i spoke too fast: it seems to work for single module projects (which was
maybe the case with 1.5.1 too) but not with multi-module projects.
was (Author: gjoseph):
Good news, I guess: using the macports.org port of the subversion client
1.5.2, this now seems to work.
> scm tag does not work with Subversion 1.5.1
> ---
>
> Key: SCM-406
> URL: http://jira.codehaus.org/browse/SCM-406
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 1.0
>Reporter: James William Dumay
> Fix For: 1.1.1
>
>
> scm:checkin does not work with Subversion 1.5.1
> On release:perform (which I assume calls scm:checkin) the following error
> occurs:
> {code}
> svn: File
> '/svn/private/atlassian/confluence/tags/confluence-project-2.10-m1/conf-acceptance-test/pom.xml'
> already exists
> {code}
> Using subversion 1.4.x is a good enough workaround.
--
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: (MENFORCER-51) build failure in case of available updates
[ http://jira.codehaus.org/browse/MENFORCER-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147357#action_147357 ] Tomasz Pik commented on MENFORCER-51: - I agree that having it in enforcer is a better idea, then having it in versions plugin. Any chance that it can be included in roadmap for 1.0? > build failure in case of available updates > -- > > Key: MENFORCER-51 > URL: http://jira.codehaus.org/browse/MENFORCER-51 > Project: Maven 2.x Enforcer Plugin > Issue Type: Wish >Reporter: Tomasz Pik > > It would be useful to have a possibility to fail build if there's an update > of given dependency. > In some way it would 'solve' problem of 'how to depend of latest stable > version of my company parent pom' problem - build would just not pass > if there's an update. -- 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-3746) POM properties do not override default system properties during POM interpolation
[
http://jira.codehaus.org/browse/MNG-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147368#action_147368
]
Paul Benedict commented on MNG-3746:
I am not quite sure what the correct solution is. Obviously, properties like
java.version are really important, and if they can be overridden, that might
lead to some unpredictable expectations.
I'd rather Maven err if such properties like java.* exist. However, if it is
pre-existing behavior, maybe it's worth continuing but I must admit I feel
that my code was inappropriate to use that property namespace.
> POM properties do not override default system properties during POM
> interpolation
> -
>
> Key: MNG-3746
> URL: http://jira.codehaus.org/browse/MNG-3746
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.1.0-M1
>Reporter: John Casey
>Assignee: John Casey
>Priority: Blocker
> Fix For: 2.1.0-M1
>
>
> From Paul Benedict, on the maven dev list:
> {noformat}
> My issue might be related to MNG-3535.
> I defined this property:
> 1.6
> And used it in my compiler plugin:
>
> org.apache.maven.plugins
> maven-compiler-plugin
>
> ${java.version}
> ${java.version}
>
>
> I know this use to work before 2.0.10, but now it does not.
> [INFO] Compilation failure
> Failure executing javac, but could not parse the error:
> javac: invalid target release: 1.6.0_06
> Usage: javac
> use -help for a list of possible options
> The error here is that ${java.version} is not the value I specified,
> but one that already exists.
> Paul
> {noformat}
> I've replicated the problem in a separate test mock-up project.
--
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: (MNG-3746) POM properties do not override default system properties during POM interpolation
[
http://jira.codehaus.org/browse/MNG-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MNG-3746.
---
Resolution: Fixed
> POM properties do not override default system properties during POM
> interpolation
> -
>
> Key: MNG-3746
> URL: http://jira.codehaus.org/browse/MNG-3746
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.1.0-M1
>Reporter: John Casey
>Assignee: John Casey
>Priority: Blocker
> Fix For: 2.1.0-M1
>
>
> From Paul Benedict, on the maven dev list:
> {noformat}
> My issue might be related to MNG-3535.
> I defined this property:
> 1.6
> And used it in my compiler plugin:
>
> org.apache.maven.plugins
> maven-compiler-plugin
>
> ${java.version}
> ${java.version}
>
>
> I know this use to work before 2.0.10, but now it does not.
> [INFO] Compilation failure
> Failure executing javac, but could not parse the error:
> javac: invalid target release: 1.6.0_06
> Usage: javac
> use -help for a list of possible options
> The error here is that ${java.version} is not the value I specified,
> but one that already exists.
> Paul
> {noformat}
> I've replicated the problem in a separate test mock-up project.
--
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] Reopened: (MNG-3746) POM properties do not override default system properties during POM interpolation
[
http://jira.codehaus.org/browse/MNG-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey reopened MNG-3746:
-
Need to verify that -Djava.version=1.4 will override in POM.
> POM properties do not override default system properties during POM
> interpolation
> -
>
> Key: MNG-3746
> URL: http://jira.codehaus.org/browse/MNG-3746
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.1.0-M1
>Reporter: John Casey
>Assignee: John Casey
>Priority: Blocker
> Fix For: 2.1.0-M1
>
>
> From Paul Benedict, on the maven dev list:
> {noformat}
> My issue might be related to MNG-3535.
> I defined this property:
> 1.6
> And used it in my compiler plugin:
>
> org.apache.maven.plugins
> maven-compiler-plugin
>
> ${java.version}
> ${java.version}
>
>
> I know this use to work before 2.0.10, but now it does not.
> [INFO] Compilation failure
> Failure executing javac, but could not parse the error:
> javac: invalid target release: 1.6.0_06
> Usage: javac
> use -help for a list of possible options
> The error here is that ${java.version} is not the value I specified,
> but one that already exists.
> Paul
> {noformat}
> I've replicated the problem in a separate test mock-up project.
--
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: (MNG-3746) POM properties do not override default system properties during POM interpolation
[
http://jira.codehaus.org/browse/MNG-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MNG-3746.
---
Resolution: Fixed
fixed CLI overrides of POM properties, and added another integration test for
this case.
> POM properties do not override default system properties during POM
> interpolation
> -
>
> Key: MNG-3746
> URL: http://jira.codehaus.org/browse/MNG-3746
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.1.0-M1
>Reporter: John Casey
>Assignee: John Casey
>Priority: Blocker
> Fix For: 2.1.0-M1
>
>
> From Paul Benedict, on the maven dev list:
> {noformat}
> My issue might be related to MNG-3535.
> I defined this property:
> 1.6
> And used it in my compiler plugin:
>
> org.apache.maven.plugins
> maven-compiler-plugin
>
> ${java.version}
> ${java.version}
>
>
> I know this use to work before 2.0.10, but now it does not.
> [INFO] Compilation failure
> Failure executing javac, but could not parse the error:
> javac: invalid target release: 1.6.0_06
> Usage: javac
> use -help for a list of possible options
> The error here is that ${java.version} is not the value I specified,
> but one that already exists.
> Paul
> {noformat}
> I've replicated the problem in a separate test mock-up project.
--
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-30) site:deploy incompatibilities with m1.02
[ http://jira.codehaus.org/browse/MSITE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147374#action_147374 ] Paul Spencer commented on MSITE-30: --- Yes. Paul Spencer > site:deploy incompatibilities with m1.02 > > > Key: MSITE-30 > URL: http://jira.codehaus.org/browse/MSITE-30 > Project: Maven 2.x Site Plugin > Issue Type: Improvement > Components: site:deploy > Environment: All >Reporter: Paul Spencer > Fix For: 2.0-beta-8 > > > Deploying a site in m2 has changed since m1. > 1) m1 used the "tar" and "gunzip" command on the remote site, where m2 uses > the "unzip" command. This poses a problem for be since my remote site does > not support the "unzip" command, thus making the "priority" of this issue > major > 1.1) Their may be desire to deploy without the use of tools like tar and zip > on some site. The deploy would esentailly be a recersive copy > 2) No equivelent to m1 property maven.site.chmod.mode. I use this to allow > other member is the group update and delete permission > 3) No equivelent to m1 property maven.site.publish.clean > Their are other properties for the m1.02 not mentioned above, but I suspect > the they can be calculated from m2 files, i.e. pom.xml and settings.xml. > Paul Spencer -- 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-3747) relative build paths are not path-translated when using prefixed expressions (eg. project.build.directory) in plugin configurations
relative build paths are not path-translated when using prefixed expressions
(eg. project.build.directory) in plugin configurations
---
Key: MNG-3747
URL: http://jira.codehaus.org/browse/MNG-3747
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 2.1.0-M1
Reporter: John Casey
example:
{noformat}
bld
maven-antrun-plugin
test
test
run
{noformat}
When the antrun plugin executes, the expressions will be resolved with relative
paths, not absolute ones (as would be the case if they were run through the
pathTranslator).
This is a problem with the interpolation post-processor that handles path
translation, because it doesn't have any sensitivity to prefixed expressions.
In other words, it'll handle build.directory but not project.build.directory.
--
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-3747) relative build paths are not path-translated when using prefixed expressions (eg. project.build.directory) in plugin configurations
[
http://jira.codehaus.org/browse/MNG-3747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MNG-3747:
Assignee: John Casey
Fix Version/s: 2.1.0-M1
to be clear, the key points to this issue are the prefixed expression:
*project.build.directory* and the relative build/directory value: *bld*.
> relative build paths are not path-translated when using prefixed expressions
> (eg. project.build.directory) in plugin configurations
> ---
>
> Key: MNG-3747
> URL: http://jira.codehaus.org/browse/MNG-3747
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.1.0-M1
>Reporter: John Casey
>Assignee: John Casey
> Fix For: 2.1.0-M1
>
>
> example:
> {noformat}
>
> bld
>
>
> maven-antrun-plugin
>
>
> test
> test
>
> run
>
>
>
> antfile="${project.build.directory}/test-classes/test.build.xml" />
>
>
>
>
>
>
>
> {noformat}
> When the antrun plugin executes, the expressions will be resolved with
> relative paths, not absolute ones (as would be the case if they were run
> through the pathTranslator).
> This is a problem with the interpolation post-processor that handles path
> translation, because it doesn't have any sensitivity to prefixed expressions.
> In other words, it'll handle build.directory but not project.build.directory.
--
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-3747) relative build paths are not path-translated when using prefixed expressions (eg. project.build.directory) in plugin configurations
[
http://jira.codehaus.org/browse/MNG-3747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147384#action_147384
]
John Casey commented on MNG-3747:
-
One additional point critical to reproducing this problem is to use a String
configuration that *embeds* the expression, rather than having the expression
as the whole value or even starting with it...
> relative build paths are not path-translated when using prefixed expressions
> (eg. project.build.directory) in plugin configurations
> ---
>
> Key: MNG-3747
> URL: http://jira.codehaus.org/browse/MNG-3747
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.1.0-M1
>Reporter: John Casey
>Assignee: John Casey
> Fix For: 2.1.0-M1
>
>
> example:
> {noformat}
>
> bld
>
>
> maven-antrun-plugin
>
>
> test
> test
>
> run
>
>
>
> antfile="${project.build.directory}/test-classes/test.build.xml" />
>
>
>
>
>
>
>
> {noformat}
> When the antrun plugin executes, the expressions will be resolved with
> relative paths, not absolute ones (as would be the case if they were run
> through the pathTranslator).
> This is a problem with the interpolation post-processor that handles path
> translation, because it doesn't have any sensitivity to prefixed expressions.
> In other words, it'll handle build.directory but not project.build.directory.
--
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: (SCM-406) scm tag does not work with Subversion 1.5.1
[
http://jira.codehaus.org/browse/SCM-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147386#action_147386
]
James William Dumay commented on SCM-406:
-
I can still confirm this issue with the SVN 1.5.2 release.
> scm tag does not work with Subversion 1.5.1
> ---
>
> Key: SCM-406
> URL: http://jira.codehaus.org/browse/SCM-406
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 1.0
>Reporter: James William Dumay
> Fix For: 1.1.1
>
>
> scm:checkin does not work with Subversion 1.5.1
> On release:perform (which I assume calls scm:checkin) the following error
> occurs:
> {code}
> svn: File
> '/svn/private/atlassian/confluence/tags/confluence-project-2.10-m1/conf-acceptance-test/pom.xml'
> already exists
> {code}
> Using subversion 1.4.x is a good enough workaround.
--
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: (MNG-3747) relative build paths are not path-translated when using prefixed expressions (eg. project.build.directory) in plugin configurations
[
http://jira.codehaus.org/browse/MNG-3747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MNG-3747.
---
Resolution: Fixed
> relative build paths are not path-translated when using prefixed expressions
> (eg. project.build.directory) in plugin configurations
> ---
>
> Key: MNG-3747
> URL: http://jira.codehaus.org/browse/MNG-3747
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.1.0-M1
>Reporter: John Casey
>Assignee: John Casey
> Fix For: 2.1.0-M1
>
>
> example:
> {noformat}
>
> bld
>
>
> maven-antrun-plugin
>
>
> test
> test
>
> run
>
>
>
> antfile="${project.build.directory}/test-classes/test.build.xml" />
>
>
>
>
>
>
>
> {noformat}
> When the antrun plugin executes, the expressions will be resolved with
> relative paths, not absolute ones (as would be the case if they were run
> through the pathTranslator).
> This is a problem with the interpolation post-processor that handles path
> translation, because it doesn't have any sensitivity to prefixed expressions.
> In other words, it'll handle build.directory but not project.build.directory.
--
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: (MECLIPSE-486) ITs dont compare expected files if the IT is a multi-module project
ITs dont compare expected files if the IT is a multi-module project
---
Key: MECLIPSE-486
URL: http://jira.codehaus.org/browse/MECLIPSE-486
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: Core : Multi-projects
Affects Versions: 2.6
Reporter: Barrie Treloar
The comparison of directories is only done in testProject:
{code:title=AbstractEclipsePluginIT.testProject(String, Properties, String,
String)}
// line 250
compareDirectoryContent( basedir, projectOutputDir, "" );
compareDirectoryContent( basedir, projectOutputDir, ".settings/" );
compareDirectoryContent( basedir, projectOutputDir,
".externalToolBuilders/" );
compareDirectoryContent( basedir, projectOutputDir, "META-INF/" );
{code}
which only checks the top level basedir.
I'm changing the tests to locate all "expected" directories under basedir and
to compare all the files recursively under "expected" to the equivalent level
in the outputDir.
--
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: (MECLIPSE-185) mvn eclipse:eclipse report 'Build Successful' even when generation fails
[ http://jira.codehaus.org/browse/MECLIPSE-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147391#action_147391 ] Barrie Treloar commented on MECLIPSE-185: - This affects the IT tests too. I've noticed that project-34 (a multi-module project) is failing in the output log because it is missing some system dependencies. The root pom for project-34 appears to be copied from master-test. Even though it fails because of missing dependencies the plugin indicates successful generation. See MECLIPSE-486 > mvn eclipse:eclipse report 'Build Successful' even when generation fails > > > Key: MECLIPSE-185 > URL: http://jira.codehaus.org/browse/MECLIPSE-185 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Dependencies resolution and build path >Affects Versions: 2.2 >Reporter: Hans Dockter >Assignee: Brian Fox > > When I start mvn eclipse:eclipse and for example some dependencies can't be > downloaded. Then the plugin still reports at the end Build successful, > although no new .classpath file was generated. Now ypu have to always verify > the content of the output, to see if it was really successful. -- 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
