[jira] (MENFORCER-117) Custom Packaging with executions fails with NullPointerException in RequirePluginVersions.java:702

[Barrie Treloar (JIRA)]

[ 
https://jira.codehaus.org/browse/MENFORCER-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302687#comment-302687
 ] 

Barrie Treloar commented on MENFORCER-117:
--

Investigation shows:
Line 708 (was 702 prior to the start of hacking)
{noformat}
plugin.setArtifactId( tokens[1] );
{noformat}

Dumping out what tokens is and some surrounding variables:

{noformat}
[ERROR] entry =clean=org.apache.maven.plugins:maven-clean-plugin:2.4.1:clean
[ERROR] value =org.apache.maven.plugins:maven-clean-plugin:2.4.1:clean
[ERROR] tokens =[org.apache.maven.plugins, maven-clean-plugin, 2.4.1, clean]
[ERROR] entry =install=org.apache.maven.plugins:maven-install-plugin:install
[ERROR] value =org.apache.maven.plugins:maven-install-plugin:install
[ERROR] tokens =[org.apache.maven.plugins, maven-install-plugin, install]
[ERROR] entry =generate-sources=
{noformat}

Likewise for the other test project being added
{noformat}
[ERROR] entry =integration-test=
[ERROR] value =
[ERROR] tokens =[]
{noformat}

So RequirePluginVersions needs to handle empty lifecycles.

> Custom Packaging with executions fails with NullPointerException in 
> RequirePluginVersions.java:702
> --
>
> Key: MENFORCER-117
> URL: https://jira.codehaus.org/browse/MENFORCER-117
> Project: Maven 2.x Enforcer Plugin
>  Issue Type: Bug
>  Components: Plugin
>Affects Versions: 1.0.1
> Environment: Windows XP
>Reporter: Barrie Treloar
>Assignee: Barrie Treloar
>Priority: Critical
> Attachments: pom.xml
>
>
> The pde-maven-plugin causes enforcer to NPE.
> I've attached an IT pom.xml.
> I haven't had time to investigate this any further than to get the IT to fail 
> the same as my real build.
> {noformat}
>   zip
>   
> 
>   
> org.codehaus.mojo
> pde-maven-plugin
> 1.0-alpha-1
> true
> 
>
>  example.product
>
> 
> 
> 
>   
> clean-pde
> clean
> 
>   clean
> 
>   
> 
>   
> ...
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MENFORCER-117) Custom Packaging with executions fails with NullPointerException in RequirePluginVersions.java:702

[Barrie Treloar (JIRA)]

[ 
https://jira.codehaus.org/browse/MENFORCER-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302686#comment-302686
 ] 

Barrie Treloar commented on MENFORCER-117:
--

Exception raised:
{noformat}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-enforcer-plugin:1.2-SNAPSHOT:enforce (test) on 
project pluginWithExtensions: Execution test of goal 
org.apache.maven.plugins:maven-enforcer-plugin:1.2-SNAPSHOT:enforce failed: 1 
-> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
org.apache.maven.plugins:maven-enforcer-plugin:1.2-SNAPSHOT:enforce (test) on 
project pluginWithExtensions: Execution test of goal 
org.apache.maven.plugins:maven-enforcer-plugin:1.2-SNAPSHOT:enforce failed: 1
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution test of 
goal org.apache.maven.plugins:maven-enforcer-plugin:1.2-SNAPSHOT:enforce 
failed: 1
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: java.lang.ArrayIndexOutOfBoundsException: 1
at 
org.apache.maven.plugins.enforcer.RequirePluginVersions.getAllPlugins(RequirePluginVersions.java:708)
at 
org.apache.maven.plugins.enforcer.RequirePluginVersions.getBoundPlugins(RequirePluginVersions.java:570)
at 
org.apache.maven.plugins.enforcer.RequirePluginVersions.execute(RequirePluginVersions.java:201)
at 
org.apache.maven.plugins.enforcer.EnforceMojo.execute(EnforceMojo.java:190)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)

{noformat}


> Custom Packaging with executions fails with NullPointerException in 
> RequirePluginVersions.java:702
> --
>
> Key: MENFORCER-117
> URL: https://jira.codehaus.org/browse/MENFORCER-117
> Project: Maven 2.x Enforcer Plugin
>  Issue Type: Bug
>  Components: Plugin
>Affects Versions: 1.0.1
> Environment: Windows XP
>Reporter: Barrie Treloar
>Assignee: Barrie Treloar
>Priority: Critical
> Attachments: pom.xml
>
>
> The pde-maven-plugin causes enforcer to NPE.
> I've attached an IT pom.xml.
> I haven't had time to investigate this any further than to get the IT to fail 
> the same as my real build.
> {noformat}
>   zip
>   
> 
>   
> org.codehaus.mojo
> pde-maven-plugin
> 1.0-alpha-1
> true
> 
>
>  example.product
>
> 
> 
> 
>   
> clean-pde
> clean
> 
>   clean
> 
>   
> 
>   
> ...
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministra

[jira] (MENFORCER-117) Custom Packaging with executions fails with NullPointerException in RequirePluginVersions.java:702

[Barrie Treloar (JIRA)]

 [ 
https://jira.codehaus.org/browse/MENFORCER-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Barrie Treloar reassigned MENFORCER-117:


Assignee: Barrie Treloar

> Custom Packaging with executions fails with NullPointerException in 
> RequirePluginVersions.java:702
> --
>
> Key: MENFORCER-117
> URL: https://jira.codehaus.org/browse/MENFORCER-117
> Project: Maven 2.x Enforcer Plugin
>  Issue Type: Bug
>  Components: Plugin
>Affects Versions: 1.0.1
> Environment: Windows XP
>Reporter: Barrie Treloar
>Assignee: Barrie Treloar
>Priority: Critical
> Attachments: pom.xml
>
>
> The pde-maven-plugin causes enforcer to NPE.
> I've attached an IT pom.xml.
> I haven't had time to investigate this any further than to get the IT to fail 
> the same as my real build.
> {noformat}
>   zip
>   
> 
>   
> org.codehaus.mojo
> pde-maven-plugin
> 1.0-alpha-1
> true
> 
>
>  example.product
>
> 
> 
> 
>   
> clean-pde
> clean
> 
>   clean
> 
>   
> 
>   
> ...
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MSKINS-50) Breadcrumb links do not all work on layout sample pages

[Dennis Lundberg (JIRA)]

 [ 
https://jira.codehaus.org/browse/MSKINS-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MSKINS-50:
--

  Component/s: Fluido Skin
Affects Version/s: fluido-1.2.1

> Breadcrumb links do not all work on layout sample pages
> ---
>
> Key: MSKINS-50
> URL: https://jira.codehaus.org/browse/MSKINS-50
> Project: Maven Skins
>  Issue Type: Bug
>  Components: Fluido Skin
>Affects Versions: fluido-1.2.1
> Environment: 
> http://maven.apache.org/skins/maven-fluido-skin/topbar/index.html
> http://maven.apache.org/skins/maven-fluido-skin/sidebar/index.html
>Reporter: SebbASF
>
> The breadcrumb navigation contains:
> Apache / Maven / skins / maven-fluido-skin / Apache Maven Fluido Skin IT, 
> sidebar layout
> However, only the 1st two links (i.e. Apache / Maven ) actually work.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MRESOURCES-132) Copying of files with permissions broken

[Martin Todorov (JIRA)]

[ 
https://jira.codehaus.org/browse/MRESOURCES-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302648#comment-302648
 ] 

Martin Todorov commented on MRESOURCES-132:
---

Well, you are right and I believe the fix was rather simple.
I believe that preserving the permissions is quite important and should be 
corrected in the resources plugin.

> Copying of files with permissions broken
> 
>
> Key: MRESOURCES-132
> URL: https://jira.codehaus.org/browse/MRESOURCES-132
> Project: Maven 2.x Resources Plugin
>  Issue Type: Bug
>  Components: copy
>Affects Versions: 2.4.3
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 22:16:01+0300)
> Java version: 1.6.0_19
> Java home: /java/jdk1.6.0_19/jre
> Default locale: en_US, platform encoding: ISO-8859-1
> OS name: "linux" version: "2.6.28.5" arch: "i386" Family: "unix"
>Reporter: Martin Todorov
>
> Files with permissions are not copied with the permissions as illustrated 
> below:
> {noformat}
> root@carlspring:/java/opensource/build-force/zipper-plugin# ls -al `find . 
> -name *perm*`
> -rwxr--r-- 1 root root   8 2010-12-09 20:48 
> ./src/test/resources/zip/file.with.permission.sh*
> -rw-r--r-- 1 root root   8 2010-12-09 22:56 
> ./target/test-classes/zip/file.with.permission.sh
> {noformat}
> Notice the 'x' permission missing from the copied file.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MRESOURCES-132) Copying of files with permissions broken

[Martin Todorov (JIRA)]

[ 
https://jira.codehaus.org/browse/MRESOURCES-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302646#comment-302646
 ] 

Martin Todorov commented on MRESOURCES-132:
---

Olivier... That was some two years ago. I don't remember what my use case was 
back then, but I think it could now be replaced by the assembly plugin. I have 
however fixed it in my zipper plugin. I will send you a link tomorrow.

> Copying of files with permissions broken
> 
>
> Key: MRESOURCES-132
> URL: https://jira.codehaus.org/browse/MRESOURCES-132
> Project: Maven 2.x Resources Plugin
>  Issue Type: Bug
>  Components: copy
>Affects Versions: 2.4.3
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 22:16:01+0300)
> Java version: 1.6.0_19
> Java home: /java/jdk1.6.0_19/jre
> Default locale: en_US, platform encoding: ISO-8859-1
> OS name: "linux" version: "2.6.28.5" arch: "i386" Family: "unix"
>Reporter: Martin Todorov
>
> Files with permissions are not copied with the permissions as illustrated 
> below:
> {noformat}
> root@carlspring:/java/opensource/build-force/zipper-plugin# ls -al `find . 
> -name *perm*`
> -rwxr--r-- 1 root root   8 2010-12-09 20:48 
> ./src/test/resources/zip/file.with.permission.sh*
> -rw-r--r-- 1 root root   8 2010-12-09 22:56 
> ./target/test-classes/zip/file.with.permission.sh
> {noformat}
> Notice the 'x' permission missing from the copied file.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MRESOURCES-132) Copying of files with permissions broken

[Gili (JIRA)]

[ 
https://jira.codehaus.org/browse/MRESOURCES-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302647#comment-302647
 ] 

Gili commented on MRESOURCES-132:
-

Shouldn't correctness always come before performance? Losing permissions along 
the way is tantamount to losing data (well, meta-data actually, but still 
important).

> Copying of files with permissions broken
> 
>
> Key: MRESOURCES-132
> URL: https://jira.codehaus.org/browse/MRESOURCES-132
> Project: Maven 2.x Resources Plugin
>  Issue Type: Bug
>  Components: copy
>Affects Versions: 2.4.3
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 22:16:01+0300)
> Java version: 1.6.0_19
> Java home: /java/jdk1.6.0_19/jre
> Default locale: en_US, platform encoding: ISO-8859-1
> OS name: "linux" version: "2.6.28.5" arch: "i386" Family: "unix"
>Reporter: Martin Todorov
>
> Files with permissions are not copied with the permissions as illustrated 
> below:
> {noformat}
> root@carlspring:/java/opensource/build-force/zipper-plugin# ls -al `find . 
> -name *perm*`
> -rwxr--r-- 1 root root   8 2010-12-09 20:48 
> ./src/test/resources/zip/file.with.permission.sh*
> -rw-r--r-- 1 root root   8 2010-12-09 22:56 
> ./target/test-classes/zip/file.with.permission.sh
> {noformat}
> Notice the 'x' permission missing from the copied file.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MRESOURCES-132) Copying of files with permissions broken

[Olivier Lamy (JIRA)]

[ 
https://jira.codehaus.org/browse/MRESOURCES-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302645#comment-302645
 ] 

Olivier Lamy commented on MRESOURCES-132:
-

the main issue is performance.
Because we will have to check permissions for all so a lot of io.
Can you use assembly plugin for your use case ?

> Copying of files with permissions broken
> 
>
> Key: MRESOURCES-132
> URL: https://jira.codehaus.org/browse/MRESOURCES-132
> Project: Maven 2.x Resources Plugin
>  Issue Type: Bug
>  Components: copy
>Affects Versions: 2.4.3
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 22:16:01+0300)
> Java version: 1.6.0_19
> Java home: /java/jdk1.6.0_19/jre
> Default locale: en_US, platform encoding: ISO-8859-1
> OS name: "linux" version: "2.6.28.5" arch: "i386" Family: "unix"
>Reporter: Martin Todorov
>
> Files with permissions are not copied with the permissions as illustrated 
> below:
> {noformat}
> root@carlspring:/java/opensource/build-force/zipper-plugin# ls -al `find . 
> -name *perm*`
> -rwxr--r-- 1 root root   8 2010-12-09 20:48 
> ./src/test/resources/zip/file.with.permission.sh*
> -rw-r--r-- 1 root root   8 2010-12-09 22:56 
> ./target/test-classes/zip/file.with.permission.sh
> {noformat}
> Notice the 'x' permission missing from the copied file.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MRESOURCES-111) escapeWindowsPath doesn't work when applying properties

[Olivier Lamy (JIRA)]

 [ 
https://jira.codehaus.org/browse/MRESOURCES-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy closed MRESOURCES-111.
---

   Resolution: Fixed
Fix Version/s: 2.6
 Assignee: Olivier Lamy

> escapeWindowsPath doesn't work when applying properties
> ---
>
> Key: MRESOURCES-111
> URL: https://jira.codehaus.org/browse/MRESOURCES-111
> Project: Maven 2.x Resources Plugin
>  Issue Type: Bug
>Affects Versions: 2.4.1
>Reporter: Jochen Wiedmann
>Assignee: Olivier Lamy
> Fix For: 2.6
>
> Attachments: mydemo.zip
>
>
> The attached project contains a property file 
> "src/test/main/hibernate.properties". I'd like to inject the projects build 
> path into that file. More precisely, I have a property "jdbc.url" in my 
> pom.xml, which looks like this:
> 
> jdbc:derby:${project.build.directory}/derby-db;create=true
> In hibernate.properties, I have
> hibernate.connection.url=${jdbc.url}
> Which resolves to
> 
> hibernate.connection.url=jdbc:derby:C:\workspace\mydemo\target/derby-db;create=true
> which is invalid, because the backslashes aren't escaped.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MRESOURCES-148) Turn Off '@' Escape Filtering

[Olivier Lamy (JIRA)]

 [ 
https://jira.codehaus.org/browse/MRESOURCES-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy closed MRESOURCES-148.
---

   Resolution: Fixed
Fix Version/s: 2.6
 Assignee: Olivier Lamy

> Turn Off '@' Escape Filtering
> -
>
> Key: MRESOURCES-148
> URL: https://jira.codehaus.org/browse/MRESOURCES-148
> Project: Maven 2.x Resources Plugin
>  Issue Type: Improvement
>Reporter: Lou Springer
>Assignee: Olivier Lamy
> Fix For: 2.6
>
> Attachments: test-resouce-escape.tar.gz
>
>
> I'm trying to filter a groovy script with @Grab annotations like so:
> {code}
> @Grab(group='com.neosgeo.neosphere.ops', module='host-ops', 
> version='${project.version}')
> {code}
> ${project.version} won't filter. If you use
> {code}
> @Grab(
>   group='com.neosgeo.neosphere.ops', module='host-ops', 
> version='${project.version}')
> {code}
> it does. 
> Note that 
> {code}
> \@Grab(group='com.neosgeo.neosphere.ops', module='host-ops', 
> version='${project.version}')
> {code}
> with 
> {code}
> \
> {code}
> is useless. 
>  
> There doesn't appear to be anyway to escape the single @ so it isn't 
> interpreted as a filter token, or to turn off '@' as a token entirely. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MRESOURCES-91) File last modified property is changed when copied as resource

[Olivier Lamy (JIRA)]

 [ 
https://jira.codehaus.org/browse/MRESOURCES-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy updated MRESOURCES-91:
---

Fix Version/s: (was: 2.6)
   2.7

> File last modified property is changed when copied as resource
> --
>
> Key: MRESOURCES-91
> URL: https://jira.codehaus.org/browse/MRESOURCES-91
> Project: Maven 2.x Resources Plugin
>  Issue Type: Bug
>  Components: copy
>Affects Versions: 2.3
> Environment: Ubuntu 9.04 x64
> Sun JDK 1.6.0_12
> Maven 2.1.0
>Reporter: Noam Y. Tenne
> Fix For: 2.7
>
>
> This occurs when no filter is being used.
> When a resource is copied to the target directory, the file's last modified 
> property is changed to the time of copy.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MRESOURCES-141) Filtering doesn't work when there is an odd number of @ in the resource

[Olivier Lamy (JIRA)]

 [ 
https://jira.codehaus.org/browse/MRESOURCES-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy closed MRESOURCES-141.
---

   Resolution: Fixed
Fix Version/s: 2.6

should be fixed with MRESOURCES-166 

> Filtering doesn't work when there is an odd number of @ in the resource
> ---
>
> Key: MRESOURCES-141
> URL: https://jira.codehaus.org/browse/MRESOURCES-141
> Project: Maven 2.x Resources Plugin
>  Issue Type: Bug
>  Components: filtering
>Affects Versions: 2.4.3, 2.5
>Reporter: Roland Asmann
>Assignee: Olivier Lamy
> Fix For: 2.6
>
> Attachments: eclipse_resources_test_project.zip, 
> IT-MRESOURCES-141.patch, resources-bug.zip
>
>
> When filtering a resource that contains an odd number of @, all variables 
> after the last @ are not replaced by the defined values.
> Attached a project that shows this behavior -- workaround is to uncomment the 
> configuration for the resources-plugin in the POM.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MRESOURCES-83) Improved diagnostics on failures

[Olivier Lamy (JIRA)]

[ 
https://jira.codehaus.org/browse/MRESOURCES-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302642#comment-302642
 ] 

Olivier Lamy commented on MRESOURCES-83:


please provide a log because it's difficult to know from where the issue come.

> Improved diagnostics on failures
> 
>
> Key: MRESOURCES-83
> URL: https://jira.codehaus.org/browse/MRESOURCES-83
> Project: Maven 2.x Resources Plugin
>  Issue Type: Improvement
>Affects Versions: 2.3
> Environment: Maven 2.0.9, AIX, IBM JVM 1.5.x
>Reporter: Dave Meibusch
> Fix For: backlog
>
>
> Background: 
> The JVM and class libraries are not forgiving if you attempt to filter a 
> resource with an incorrect encoding.
> For example, if a file contains an invalid UTF-8 character 
> sun.io.ByteToCharUTF8 throws a MalformedInputException.
> The resource plugin in this scenario reports (in trace with mvn -X) "Error 
> copying resource", but with no indication which file or even which set of 
> resources in the project caused the error.
> With very large number of resources (in my case, several thousand files), it 
> is challenging to find the corrupted/incorrectly encoded file.
> Suggested improvement is more contextual information in the debug output.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MRESOURCES-83) Improved diagnostics on failures

[Olivier Lamy (JIRA)]

 [ 
https://jira.codehaus.org/browse/MRESOURCES-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy updated MRESOURCES-83:
---

Fix Version/s: (was: 2.6)
   backlog

> Improved diagnostics on failures
> 
>
> Key: MRESOURCES-83
> URL: https://jira.codehaus.org/browse/MRESOURCES-83
> Project: Maven 2.x Resources Plugin
>  Issue Type: Improvement
>Affects Versions: 2.3
> Environment: Maven 2.0.9, AIX, IBM JVM 1.5.x
>Reporter: Dave Meibusch
> Fix For: backlog
>
>
> Background: 
> The JVM and class libraries are not forgiving if you attempt to filter a 
> resource with an incorrect encoding.
> For example, if a file contains an invalid UTF-8 character 
> sun.io.ByteToCharUTF8 throws a MalformedInputException.
> The resource plugin in this scenario reports (in trace with mvn -X) "Error 
> copying resource", but with no indication which file or even which set of 
> resources in the project caused the error.
> With very large number of resources (in my case, several thousand files), it 
> is challenging to find the corrupted/incorrectly encoded file.
> Suggested improvement is more contextual information in the debug output.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MRESOURCES-70) Filter does not process nested ${} variables

[Olivier Lamy (JIRA)]

 [ 
https://jira.codehaus.org/browse/MRESOURCES-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy updated MRESOURCES-70:
---

Fix Version/s: (was: 2.6)
   backlog

> Filter does not process nested ${} variables
> 
>
> Key: MRESOURCES-70
> URL: https://jira.codehaus.org/browse/MRESOURCES-70
> Project: Maven 2.x Resources Plugin
>  Issue Type: New Feature
>  Components: delimiters
>Affects Versions: 2.2
>Reporter: Matt Steele
> Fix For: backlog
>
> Attachments: MRESOURCES-70.zip
>
>
> When I try filtering this under src/main/resources:
> jms.username=${${env}.jms.username}
> with this filtering strategy:
>   
>   
>   src/main/resources
>   true
>   
>   
> Setting the property (from command line, , etc.) fails to properly 
> filter the nested element:
> jms.username=${${env}.jms.username} 
> For example, I'd like the filter to convert to this (using a property of 
> -Denv=dev):
> jms.username=${dev.jms.username} 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MRESOURCES-22) Being able to filter resources based on solely the filter files ?

[Olivier Lamy (JIRA)]

 [ 
https://jira.codehaus.org/browse/MRESOURCES-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy closed MRESOURCES-22.
--

   Resolution: Won't Fix
Fix Version/s: (was: 2.6)
 Assignee: Olivier Lamy

Changing order will break backward comp.


> Being able to filter resources based on solely the filter files ?
> -
>
> Key: MRESOURCES-22
> URL: https://jira.codehaus.org/browse/MRESOURCES-22
> Project: Maven 2.x Resources Plugin
>  Issue Type: Improvement
>Reporter: Grégory Joseph
>Assignee: Olivier Lamy
>
> I'd like to be able to switch the interpolation of pom and system properties, 
> so that the filtering uses only the properties in 
> Specifically, I think it comes down to enable/disabling lines 198-202 in 
> ResourcesMojo
> // System properties
> filterProperties.putAll( System.getProperties() );
> 
> // Project properties
> filterProperties.putAll( project.getProperties() );
> 
> Alternatively, being able to specify the token delimiters to use could also 
> make my day. (lines 255/258 still in ResourcesMojo)
> WDYT?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MRESOURCES-108) filter delimiter config that includes ${filter:*} will be changed to ${*} as of 2.4.1, causes NPE in 2.4

[Olivier Lamy (JIRA)]

 [ 
https://jira.codehaus.org/browse/MRESOURCES-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy updated MRESOURCES-108:


Fix Version/s: (was: 2.6)
   backlog

> filter delimiter config that includes ${filter:*} will be changed to ${*} as 
> of 2.4.1, causes NPE in 2.4
> 
>
> Key: MRESOURCES-108
> URL: https://jira.codehaus.org/browse/MRESOURCES-108
> Project: Maven 2.x Resources Plugin
>  Issue Type: Bug
>  Components: delimiters
>Affects Versions: 2.4, 2.4.1
>Reporter: John Casey
> Fix For: backlog
>
>
> This is the continuation of the problem expressed in MRESOURCES-105, for the 
> more general case. It has something to do with the way the 
> PluginParameterExpressionEvaluator and plexus itself resolves list-style 
> plugin parameters.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SCM-659) gitexe SCM: Configurability of SCM info method

[Robert Scholte (JIRA)]

 [ 
https://jira.codehaus.org/browse/SCM-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte updated SCM-659:
---

Priority: Minor  (was: Major)

> gitexe SCM: Configurability of SCM info method 
> ---
>
> Key: SCM-659
> URL: https://jira.codehaus.org/browse/SCM-659
> Project: Maven SCM
>  Issue Type: Improvement
>  Components: maven-scm-provider-git
>Affects Versions: 1.6
>Reporter: Paul Hicks
>Priority: Minor
>
> I need to use the output of "git describe" with the buildnumber plugin. The 
> newest versions of gitexe scm are using "git rev-parse --verify HEAD" which 
> is a sensible choice, but won't work for me. Is there a way to configure how 
> the info method works? I can't find a definition of the API.
> I'd be happy to develop this and submit a patch. I just need to know how 
> individual methods in the SCM plugin are configured. I'm not having any luck 
> with http://maven.apache.org/scm/maven-scm-api/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MSKINS-28) Make it possible to center "powered by" logos in sidebar

[Robert Scholte (JIRA)]

[ 
https://jira.codehaus.org/browse/MSKINS-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302629#comment-302629
 ] 

Robert Scholte edited comment on MSKINS-28 at 7/3/12 2:51 PM:
--

Fixed in [r1356876|http://svn.apache.org/viewvc?rev=1356876&view=rev]
I don't see the issue with the large logo's.
I can imagine that logo's next to eachother might look odd, it just depends on 
the sizes. But having them under eachother seems like a safe solution.

Thanks for the patch!

  was (Author: rfscholte):
Fixed in [r1356876|http://svn.apache.org/viewvc?rev=1356876&view=rev]
I don't see the issue with the large logo's.
I can imagine that logo's next to eachother might look odd, it just depends on 
the sizes. But having them under eachother seems like a save solution.

Thanks for the patch!
  
> Make it possible to center "powered by" logos in sidebar
> 
>
> Key: MSKINS-28
> URL: https://jira.codehaus.org/browse/MSKINS-28
> Project: Maven Skins
>  Issue Type: Wish
>  Components: Fluido Skin
>Affects Versions: fluido-1.1
>Reporter: Andreas Sewe
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: fluido-1.2.2
>
> Attachments: maven-theme.patch, mskins-28-it.patch
>
>
> Left alignment may look OK for badge-like logos like 
> ,
>  but is quite ugly for other types of logo.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MSOURCES-53) defaultManifestFile should not be readonly

[Olivier Lamy (JIRA)]

 [ 
https://jira.codehaus.org/browse/MSOURCES-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy closed MSOURCES-53.


   Resolution: Fixed
Fix Version/s: 2.2
 Assignee: Olivier Lamy

> defaultManifestFile should not be readonly
> --
>
> Key: MSOURCES-53
> URL: https://jira.codehaus.org/browse/MSOURCES-53
> Project: Maven 2.x Source Plugin
>  Issue Type: Improvement
>Affects Versions: 2.1.1
>Reporter: Philippe Marschall
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 2.2
>
> Attachments: maven-source-plugin.patch
>
>
> The location of the default manifest file is hardcoded to 
> {code}${project.build.outputDirectory}/META-INF/MANIFEST.MF{code} with no 
> possibility to change it (@readonly). We have a case where we need to have a 
> different manifest in the source jar than in the binary jar. Currently we can 
> not do this with the Maven Source Plugin because we can't make it use a 
> different manifest.
> The reason we need to have a different manifest in the source jar than the 
> binary jar is that we generate manifests for OSGi bundles. The source jar 
> needs to be a so called source bundle which means having different manifest 
> headers. Unfortunately the logic for generating those headers is a bit 
> complicated so it can't be done with a MavenArchiveConfiguration but has to 
> be done with a custom plugin.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MSKINS-28) Make it possible to center "powered by" logos in sidebar

[Robert Scholte (JIRA)]

 [ 
https://jira.codehaus.org/browse/MSKINS-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte closed MSKINS-28.


   Resolution: Fixed
Fix Version/s: (was: fluido-1.2)
   fluido-1.2.2
 Assignee: Robert Scholte  (was: Simone Tripodi)

Fixed in [r1356876|http://svn.apache.org/viewvc?rev=1356876&view=rev]
I don't see the issue with the large logo's.
I can imagine that logo's next to eachother might look odd, it just depends on 
the sizes. But having them under eachother seems like a save solution.

Thanks for the patch!

> Make it possible to center "powered by" logos in sidebar
> 
>
> Key: MSKINS-28
> URL: https://jira.codehaus.org/browse/MSKINS-28
> Project: Maven Skins
>  Issue Type: Wish
>  Components: Fluido Skin
>Affects Versions: fluido-1.1
>Reporter: Andreas Sewe
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: fluido-1.2.2
>
> Attachments: maven-theme.patch, mskins-28-it.patch
>
>
> Left alignment may look OK for badge-like logos like 
> ,
>  but is quite ugly for other types of logo.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SUREFIRE-876) surefire-junit47 does not work in an OSGi classloader environment

[Olivier Lamy (JIRA)]

 [ 
https://jira.codehaus.org/browse/SUREFIRE-876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy closed SUREFIRE-876.
-

   Resolution: Fixed
Fix Version/s: 2.13

applied.
Thanks!

> surefire-junit47 does not work in an OSGi classloader environment
> -
>
> Key: SUREFIRE-876
> URL: https://jira.codehaus.org/browse/SUREFIRE-876
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: classloading, Junit 4.7+ (parallel) support
>Affects Versions: 2.10
>Reporter: Jan Sievers
>Assignee: Olivier Lamy
> Fix For: 2.13
>
>
> while trying to port JUnitCoreProvider to tycho, I noticed that it fails with 
> an NPE when run inside an OSGi environment.
> The root cause is really JUnit bug
> https://github.com/KentBeck/junit/issues/364
> JUnit uses Class.forName() to load the test class which assumes the JUnit 
> classloader can always load test classes, which is not true in an OSGi 
> classloader environment.
> While this should be fixed in JUnit, it's easy to work around this issue in 
> surefire.
> It's not necessary to use the offending 
> org.junit.runner.Description.getTestClass() in 
> JUnitCoreRunListener.fillTestCountMap(). We can use String getClassName() 
> instead to circumvent classloading issues as we only need the class name 
> anyway.
> I will attach a patch.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SUREFIRE-876) surefire-junit47 does not work in an OSGi classloader environment

[Olivier Lamy (JIRA)]

 [ 
https://jira.codehaus.org/browse/SUREFIRE-876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy reassigned SUREFIRE-876:
-

Assignee: Olivier Lamy

> surefire-junit47 does not work in an OSGi classloader environment
> -
>
> Key: SUREFIRE-876
> URL: https://jira.codehaus.org/browse/SUREFIRE-876
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: classloading, Junit 4.7+ (parallel) support
>Affects Versions: 2.10
>Reporter: Jan Sievers
>Assignee: Olivier Lamy
>
> while trying to port JUnitCoreProvider to tycho, I noticed that it fails with 
> an NPE when run inside an OSGi environment.
> The root cause is really JUnit bug
> https://github.com/KentBeck/junit/issues/364
> JUnit uses Class.forName() to load the test class which assumes the JUnit 
> classloader can always load test classes, which is not true in an OSGi 
> classloader environment.
> While this should be fixed in JUnit, it's easy to work around this issue in 
> surefire.
> It's not necessary to use the offending 
> org.junit.runner.Description.getTestClass() in 
> JUnitCoreRunListener.fillTestCountMap(). We can use String getClassName() 
> instead to circumvent classloading issues as we only need the class name 
> anyway.
> I will attach a patch.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MASSEMBLY-295) Repository assembly contains local metadata

[Martin Ellis (JIRA)]

 [ 
https://jira.codehaus.org/browse/MASSEMBLY-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Martin Ellis updated MASSEMBLY-295:
---

Attachment: massembly-295-assembly-plugin.diff
massembly-295-repo-builder.diff

Patches for maven-repository-builder and maven-assembly-plugin attached.

I've tested by building the assembly plugin with -Prun-its.

Does anything else use maven-repository-builder? Any reason not to just remove 
the local metadata generation?

> Repository assembly contains local metadata
> ---
>
> Key: MASSEMBLY-295
> URL: https://jira.codehaus.org/browse/MASSEMBLY-295
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Wendy Smoak
> Attachments: massembly-295-assembly-plugin.diff, 
> massembly-295-repo-builder.diff
>
>
> When using the assembly plugin to construct a remote repository as described 
> on 
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/using-repositories.html,
>  the repository contains "local" metadata files such as 
> maven-metadata-central.xml.
> The remote repository format should only contain maven-metadata.xml files.
> Need to re-test with 2.2-beta-2 to confirm.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (WAGON-364) FTP connection reset

[Dmytro (JIRA)]

 [ 
https://jira.codehaus.org/browse/WAGON-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro closed WAGON-364.


Resolution: Not A Bug

> FTP connection reset
> 
>
> Key: WAGON-364
> URL: https://jira.codehaus.org/browse/WAGON-364
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-ftp
>Affects Versions: 2.1
> Environment: Win 7, 64 bit. JDK 1.7.0_01. Maven 3.0.3.
>Reporter: Dmytro
>
> Hi.
> Deployment to the FTP repository fails - connection reset error.
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on 
> project xxx: Failed to retrieve remote metadata xxx/maven-metadata.xml: Could 
> not transfer metadata xxx/maven-metadata.xml from/to xxx (ftp://xxx): Error 
> transferring file via FTP: Connection reset -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) 
> on project xxx: Failed to retrieve remote metadata xxx/maven-metadata.xml: 
> Could not transfer metadata xxx/maven-metadata.xml from/to xxx (ftp://xxx): 
> Error transferring file via FTP
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:601)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to retrieve 
> remote metadata xxx/maven-metadata.xml: Could not transfer metadata 
> xxx/maven-metadata.xml from/to xxx (ftp://xxx): Error transferring file via 
> FTP
>   at 
> org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:193)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
>   ... 19 more
> Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException: 
> Failed to retrieve remote metadata xxx/maven-metadata.xml: Could not transfer 
> metadata xxx/maven-metadata.xml from/to xxx (ftp://xxx): Error transferring 
> file via FTP
>   at 
> org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:141)
>   at 
> org.apache.maven.plugin.deploy.AbstractDeployMojo.deploy(AbstractDeployMojo.java:167)
>   at 
> org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:157)
>   ... 21 more
> Caused by: org.sonatype.aether.deployment.DeploymentException: Failed to 
> retrieve remote metadata xxx/maven-metadata.xml: Could not transfer metadata 
> xxx/maven-metadata.xml from/to xxx (ftp://xxx): Error transferring file via 
> FTP
>   at 
> org.sonatype.aether.impl.internal.DefaultDeployer.upload(DefaultDeployer.java:407)
>   at 
> org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:260)
>   at 
> org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:215)
>   at 
> org.sonatype.aether.impl.internal.DefaultRepositorySystem.deploy(DefaultRepositorySystem.java:480)
>   at 
> org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:137)
>   ... 23 mor

[jira] (WAGON-364) FTP connection reset

[Dmytro (JIRA)]

[ 
https://jira.codehaus.org/browse/WAGON-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302620#comment-302620
 ] 

Dmytro commented on WAGON-364:
--

Christoph,

Thank you very much for your advice.
It helped.
Moreover, the firewall can be turned on, the command from the "stackoverflow" 
article is enough.

Thanks again.

> FTP connection reset
> 
>
> Key: WAGON-364
> URL: https://jira.codehaus.org/browse/WAGON-364
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-ftp
>Affects Versions: 2.1
> Environment: Win 7, 64 bit. JDK 1.7.0_01. Maven 3.0.3.
>Reporter: Dmytro
>
> Hi.
> Deployment to the FTP repository fails - connection reset error.
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on 
> project xxx: Failed to retrieve remote metadata xxx/maven-metadata.xml: Could 
> not transfer metadata xxx/maven-metadata.xml from/to xxx (ftp://xxx): Error 
> transferring file via FTP: Connection reset -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) 
> on project xxx: Failed to retrieve remote metadata xxx/maven-metadata.xml: 
> Could not transfer metadata xxx/maven-metadata.xml from/to xxx (ftp://xxx): 
> Error transferring file via FTP
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:601)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to retrieve 
> remote metadata xxx/maven-metadata.xml: Could not transfer metadata 
> xxx/maven-metadata.xml from/to xxx (ftp://xxx): Error transferring file via 
> FTP
>   at 
> org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:193)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
>   ... 19 more
> Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException: 
> Failed to retrieve remote metadata xxx/maven-metadata.xml: Could not transfer 
> metadata xxx/maven-metadata.xml from/to xxx (ftp://xxx): Error transferring 
> file via FTP
>   at 
> org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:141)
>   at 
> org.apache.maven.plugin.deploy.AbstractDeployMojo.deploy(AbstractDeployMojo.java:167)
>   at 
> org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:157)
>   ... 21 more
> Caused by: org.sonatype.aether.deployment.DeploymentException: Failed to 
> retrieve remote metadata xxx/maven-metadata.xml: Could not transfer metadata 
> xxx/maven-metadata.xml from/to xxx (ftp://xxx): Error transferring file via 
> FTP
>   at 
> org.sonatype.aether.impl.internal.DefaultDeployer.upload(DefaultDeployer.java:407)
>   at 
> org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:260)
>   at 
> org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:215)
>   at 
> org.sonatype.aeth

[jira] (MASSEMBLY-295) Repository assembly contains local metadata

[Martin Ellis (JIRA)]

[ 
https://jira.codehaus.org/browse/MASSEMBLY-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302618#comment-302618
 ] 

Martin Ellis commented on MASSEMBLY-295:


Not adding local metadata would have the benefit of fixing the NPE in 
MASSEMBLY-556. :)

> Repository assembly contains local metadata
> ---
>
> Key: MASSEMBLY-295
> URL: https://jira.codehaus.org/browse/MASSEMBLY-295
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Wendy Smoak
>
> When using the assembly plugin to construct a remote repository as described 
> on 
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/using-repositories.html,
>  the repository contains "local" metadata files such as 
> maven-metadata-central.xml.
> The remote repository format should only contain maven-metadata.xml files.
> Need to re-test with 2.2-beta-2 to confirm.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MSITE-643) use maven-plugin-tools' java 5 annotations

[Olivier Lamy (JIRA)]

 [ 
https://jira.codehaus.org/browse/MSITE-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy closed MSITE-643.
--

   Resolution: Fixed
Fix Version/s: 3.2

applied.
Thanks!

> use maven-plugin-tools' java 5 annotations
> --
>
> Key: MSITE-643
> URL: https://jira.codehaus.org/browse/MSITE-643
> Project: Maven 2.x and 3.x Site Plugin
>  Issue Type: Task
>Affects Versions: 3.1
>Reporter: Herve Boutemy
>Assignee: Olivier Lamy
> Fix For: 3.2
>
> Attachments: MSITE-643_2.diff, MSITE-643.diff
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MSITE-643) use maven-plugin-tools' java 5 annotations

[Olivier Lamy (JIRA)]

 [ 
https://jira.codehaus.org/browse/MSITE-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy reassigned MSITE-643:
--

Assignee: Olivier Lamy

> use maven-plugin-tools' java 5 annotations
> --
>
> Key: MSITE-643
> URL: https://jira.codehaus.org/browse/MSITE-643
> Project: Maven 2.x and 3.x Site Plugin
>  Issue Type: Task
>Affects Versions: 3.1
>Reporter: Herve Boutemy
>Assignee: Olivier Lamy
> Attachments: MSITE-643_2.diff, MSITE-643.diff
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MRELEASE-494) Should fail during release:prepare if scm:url doesn't match working copy

[Martin Todorov (JIRA)]

[ 
https://jira.codehaus.org/browse/MRELEASE-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302608#comment-302608
 ] 

Martin Todorov commented on MRELEASE-494:
-

Older versions of the plugin (ca. 2.1.x?) had a bug where the scm:url was 
getting messed up and when rolling back this would mess things up and keep an 
incorrect scm url.
Another case where this can happen is when developers have created a branch off 
a tag (manually) and have forgotten to change the scm url-s. This would be an 
excellent thing to check for!


> Should fail during release:prepare if scm:url doesn't match working copy
> 
>
> Key: MRELEASE-494
> URL: https://jira.codehaus.org/browse/MRELEASE-494
> Project: Maven 2.x Release Plugin
>  Issue Type: Bug
>  Components: prepare
>Affects Versions: 2.0-beta-9
> Environment: Subversion SCM; working in a branch
>Reporter: David M. Lee
>
> The release plugin should check scm:url against the output of {{svn info}}.  
> If they don't match, it should fail with an error.
> We had a situation where the pom file in a branch was screwed up during a 
> merge, such that scm:url was incorrect.  In our case, it pointed to the trunk 
> instead of the branch.
> This caused release:prepare to silently do the wrong thing.  It would still 
> do the normal edit/commit in the working copy of the branch, but then it 
> would do the copy using the scm:url.  In our case, this meant that the tag 
> was copied from the trunk instead of the branch.
> In fact, release:perform also completed successfully; our only indication 
> that there was a problem was the version number of the released artifacts.
> We cannot set remotetagging=false due to the Subversion bug trying to copy 
> with svn > 1.5.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MRELEASE-459) releaseProfiles has no effect without passing profiles in the command line

[Martin Todorov (JIRA)]

[ 
https://jira.codehaus.org/browse/MRELEASE-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302591#comment-302591
 ] 

Martin Todorov edited comment on MRELEASE-459 at 7/3/12 7:32 AM:
-

This works fine under version 2.2.2 of the plugin. I am actively using it. I 
think it can be closed.

  was (Author: carlspring):
This works fine under version 2.2.2 of the plugin. I am actively using it.
  
> releaseProfiles has no effect without passing profiles in the command line 
> ---
>
> Key: MRELEASE-459
> URL: https://jira.codehaus.org/browse/MRELEASE-459
> Project: Maven 2.x Release Plugin
>  Issue Type: Bug
>  Components: perform
>Affects Versions: 2.0-beta-8, 2.0-beta-9
>Reporter: Andreas Christoforides
>  Labels: contributers-welcome, help-requested, 
> missing-integration-tests
> Attachments: MRELEASE-459.1.patch, patch.txt
>
>
> The releaseProfiles parameter on the perform goal is not taken into 
> consideration when no other profiles are passed in the command line. In other 
> words, the current code only uses the value of the parameter if you have 
> additional profiles passed in. 
> Example:
> mvn release:perform -P someProfile (uses releaseProfiles value)
> mvn release:perform (does NOT use releaseProfiles value)
> The plugin should use the parameter even if no other profiles are passed. It 
> should actually encourage release profiles configured in your POM as opposed 
> to arbitrary profiles passed in the command line.
> I have included a patch that uses the releaseProfiles parameter regardless of 
> any profiles passed in the command line.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MRELEASE-459) releaseProfiles has no effect without passing profiles in the command line

[Martin Todorov (JIRA)]

[ 
https://jira.codehaus.org/browse/MRELEASE-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302591#comment-302591
 ] 

Martin Todorov commented on MRELEASE-459:
-

This works fine under version 2.2.2 of the plugin. I am actively using it.

> releaseProfiles has no effect without passing profiles in the command line 
> ---
>
> Key: MRELEASE-459
> URL: https://jira.codehaus.org/browse/MRELEASE-459
> Project: Maven 2.x Release Plugin
>  Issue Type: Bug
>  Components: perform
>Affects Versions: 2.0-beta-8, 2.0-beta-9
>Reporter: Andreas Christoforides
>  Labels: contributers-welcome, help-requested, 
> missing-integration-tests
> Attachments: MRELEASE-459.1.patch, patch.txt
>
>
> The releaseProfiles parameter on the perform goal is not taken into 
> consideration when no other profiles are passed in the command line. In other 
> words, the current code only uses the value of the parameter if you have 
> additional profiles passed in. 
> Example:
> mvn release:perform -P someProfile (uses releaseProfiles value)
> mvn release:perform (does NOT use releaseProfiles value)
> The plugin should use the parameter even if no other profiles are passed. It 
> should actually encourage release profiles configured in your POM as opposed 
> to arbitrary profiles passed in the command line.
> I have included a patch that uses the releaseProfiles parameter regardless of 
> any profiles passed in the command line.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MRELEASE-685) prompt for license information while release:perform

[Martin Todorov (JIRA)]

[ 
https://jira.codehaus.org/browse/MRELEASE-685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302590#comment-302590
 ] 

Martin Todorov commented on MRELEASE-685:
-

The thing is... if people care enough to actually add the enforcer plugin and 
explicitly add a rule (which currently doesn't exist) for checking if the 
project has a , then they would most-likely already have defined it, 
as they would be diligent enough.

Something I've been thinking of for a while is that the release plugin needs to 
have the option of defining  just like the enforcer plugin. Then it 
would be possible to write your own custom checks and attach them to the 
release:prepare goal for example.

> prompt for license information while release:perform
> 
>
> Key: MRELEASE-685
> URL: https://jira.codehaus.org/browse/MRELEASE-685
> Project: Maven 2.x Release Plugin
>  Issue Type: New Feature
>  Components: prepare
>Reporter: Mark Struberg
>
> Currently not many projects make use of the  tags available in 
> pom-4.0, but this information might be used for many things.
> I imagine something like an automated 'license verification check' e.g. with 
> the maven-dependency-plugin
> $> mvn dependency:licenses
> which lists all the dependencies with their licenses.
> Apache RAT could also make use of this information IF the  coverage 
> would be good enough!
> To increase the amount of pom files with a valid  section, we could 
> prompt for it in the release:prepare step and create the respective  
> section for the user.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (WAGON-364) FTP connection reset

[JIRA]

[ 
https://jira.codehaus.org/browse/WAGON-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302567#comment-302567
 ] 

Christoph Küpker commented on WAGON-364:


This is a bug caused by the Windows Firewall. Had the same issue while 
deploying. Worked only from my home machine. Disable the windows firewall to 
check if this helps.

Also see this stackoverflow post which sent me in the right direction: 
http://stackoverflow.com/questions/8333797/ftpclient-uploading-file-socketexception-connection-reset

> FTP connection reset
> 
>
> Key: WAGON-364
> URL: https://jira.codehaus.org/browse/WAGON-364
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-ftp
>Affects Versions: 2.1
> Environment: Win 7, 64 bit. JDK 1.7.0_01. Maven 3.0.3.
>Reporter: Dmytro
>
> Hi.
> Deployment to the FTP repository fails - connection reset error.
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on 
> project xxx: Failed to retrieve remote metadata xxx/maven-metadata.xml: Could 
> not transfer metadata xxx/maven-metadata.xml from/to xxx (ftp://xxx): Error 
> transferring file via FTP: Connection reset -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) 
> on project xxx: Failed to retrieve remote metadata xxx/maven-metadata.xml: 
> Could not transfer metadata xxx/maven-metadata.xml from/to xxx (ftp://xxx): 
> Error transferring file via FTP
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:601)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to retrieve 
> remote metadata xxx/maven-metadata.xml: Could not transfer metadata 
> xxx/maven-metadata.xml from/to xxx (ftp://xxx): Error transferring file via 
> FTP
>   at 
> org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:193)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
>   ... 19 more
> Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException: 
> Failed to retrieve remote metadata xxx/maven-metadata.xml: Could not transfer 
> metadata xxx/maven-metadata.xml from/to xxx (ftp://xxx): Error transferring 
> file via FTP
>   at 
> org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:141)
>   at 
> org.apache.maven.plugin.deploy.AbstractDeployMojo.deploy(AbstractDeployMojo.java:167)
>   at 
> org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:157)
>   ... 21 more
> Caused by: org.sonatype.aether.deployment.DeploymentException: Failed to 
> retrieve remote metadata xxx/maven-metadata.xml: Could not transfer metadata 
> xxx/maven-metadata.xml from/to xxx (ftp://xxx): Error transferring file via 
> FTP
>   at 
> org.sonatype.aether.impl.internal.DefaultDeployer.upload(DefaultDeployer.java:407)
>   at 
> org.sonatype.aether

[jira] (MANTTASKS-201) artifact:mvn generates "org.apache.tools.ant.ExitException: Permission (java.lang.RuntimePermission exitVM) was not granted" when fork=false

[Thomas Pasch (JIRA)]

[ 
https://jira.codehaus.org/browse/MANTTASKS-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302554#comment-302554
 ] 

Thomas Pasch commented on MANTTASKS-201:


This is really great. Ant sets a security police on 'exitVM' just in order to 
throw an Exception and ... exit! It strongly feels like ant bug. 

On the other site, perhaps somebody could force a introduction of an command 
line option that forces mvn *not* to call exit at all...

> artifact:mvn generates "org.apache.tools.ant.ExitException: Permission 
> (java.lang.RuntimePermission exitVM) was not granted" when fork=false
> 
>
> Key: MANTTASKS-201
> URL: https://jira.codehaus.org/browse/MANTTASKS-201
> Project: Maven 2.x Ant Tasks
>  Issue Type: Bug
>  Components: mvn task
>Affects Versions: 2.1.1
>Reporter: Matt McHenry
>Priority: Minor
>
> Using this simple ant target:
> {code:xml}  
> 
> 
>   
> 
>   {code}
> I get the correct behaviour:
> {noformat}
> $ M2_HOME=`cygpath -w "$M2_HOME"` ant -Dmvn.goal=-version mvn.invoke
> Searching for build.xml ...
> Buildfile: c:\Users\mmchenry\svn\cli\trunk\runtime\maven\build.xml
> mvn.setversion:
> mvn.invoke:
> [artifact:mvn] Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400)
> [artifact:mvn] Java version: 1.6.0_17
> [artifact:mvn] Java home: c:\Program Files\Java\jdk1.6.0_17\jre
> [artifact:mvn] Default locale: en_US, platform encoding: Cp1252
> [artifact:mvn] OS name: "windows 7" version: "6.1" arch: "amd64" Family: 
> "windows"
> BUILD SUCCESSFUL
> Total time: 0 seconds{noformat}
> But if I set fork="false", then I get:
> {noformat}
> [artifact:mvn] Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400)
> [artifact:mvn] Java version: 1.6.0_17
> [artifact:mvn] Java home: c:\Program Files\Java\jdk1.6.0_17\jre
> [artifact:mvn] Default locale: en_US, platform encoding: Cp1252
> [artifact:mvn] OS name: "windows 7" version: "6.1" arch: "amd64" Family: 
> "windows"
> [artifact:mvn] org.apache.tools.ant.ExitException: Permission 
> (java.lang.RuntimePermission exitVM) was not granted.
> [artifact:mvn]  at 
> org.apache.tools.ant.types.Permissions$MySM.checkExit(Permissions.java:196)
> [artifact:mvn]  at java.lang.Runtime.exit(Runtime.java:88)
> [artifact:mvn]  at java.lang.System.exit(System.java:904)
> [artifact:mvn]  at org.codehaus.classworlds.Launcher.main(Launcher.java:376)
> [artifact:mvn]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [artifact:mvn]  at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> [artifact:mvn]  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> [artifact:mvn]  at java.lang.reflect.Method.invoke(Method.java:597)
> [artifact:mvn]  at 
> org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:217)
> [artifact:mvn]  at 
> org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:152)
> [artifact:mvn]  at org.apache.tools.ant.taskdefs.Java.run(Java.java:764)
> [artifact:mvn]  at 
> org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:218)
> [artifact:mvn]  at 
> org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:132)
> [artifact:mvn]  at org.apache.tools.ant.taskdefs.Java.execute(Java.java:105)
> [artifact:mvn]  at org.apache.maven.artifact.ant.Mvn.execute(Mvn.java:81)
> [artifact:mvn]  at 
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
> [artifact:mvn]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [artifact:mvn]  at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> [artifact:mvn]  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> [artifact:mvn]  at java.lang.reflect.Method.invoke(Method.java:597)
> [artifact:mvn]  at 
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> [artifact:mvn]  at org.apache.tools.ant.Task.perform(Task.java:348)
> [artifact:mvn]  at org.apache.tools.ant.Target.execute(Target.java:357)
> [artifact:mvn]  at org.apache.tools.ant.Target.performTasks(Target.java:385)
> [artifact:mvn]  at 
> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337)
> [artifact:mvn]  at 
> org.apache.tools.ant.Project.executeTarget(Project.java:1306)
> [artifact:mvn]  at 
> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
> [artifact:mvn]  at 
> org.apache.tools.ant.Project.executeTargets(Project.java:1189)
> [artifact:mvn]  at org.apache.tools.ant.Main.runBuild(Main.java:758)
> [artifact:mvn]  at org.apache.tools.ant.Main.startAnt(Main.java:217)
> [artifact:mvn]  at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257

[jira] (MANTTASKS-201) artifact:mvn generates "org.apache.tools.ant.ExitException: Permission (java.lang.RuntimePermission exitVM) was not granted" when fork=false

[Thomas Pasch (JIRA)]

[ 
https://jira.codehaus.org/browse/MANTTASKS-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302554#comment-302554
 ] 

Thomas Pasch edited comment on MANTTASKS-201 at 7/3/12 3:45 AM:


This is really great. Ant sets a security police on 'exitVM' just in order to 
throw an Exception and ... exit! It strongly feels like an ant bug. 

On the other site, perhaps somebody could force a introduction of an command 
line option that forces mvn *not* to call exit at all...

  was (Author: aannoo):
This is really great. Ant sets a security police on 'exitVM' just in order 
to throw an Exception and ... exit! It strongly feels like ant bug. 

On the other site, perhaps somebody could force a introduction of an command 
line option that forces mvn *not* to call exit at all...
  
> artifact:mvn generates "org.apache.tools.ant.ExitException: Permission 
> (java.lang.RuntimePermission exitVM) was not granted" when fork=false
> 
>
> Key: MANTTASKS-201
> URL: https://jira.codehaus.org/browse/MANTTASKS-201
> Project: Maven 2.x Ant Tasks
>  Issue Type: Bug
>  Components: mvn task
>Affects Versions: 2.1.1
>Reporter: Matt McHenry
>Priority: Minor
>
> Using this simple ant target:
> {code:xml}  
> 
> 
>   
> 
>   {code}
> I get the correct behaviour:
> {noformat}
> $ M2_HOME=`cygpath -w "$M2_HOME"` ant -Dmvn.goal=-version mvn.invoke
> Searching for build.xml ...
> Buildfile: c:\Users\mmchenry\svn\cli\trunk\runtime\maven\build.xml
> mvn.setversion:
> mvn.invoke:
> [artifact:mvn] Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400)
> [artifact:mvn] Java version: 1.6.0_17
> [artifact:mvn] Java home: c:\Program Files\Java\jdk1.6.0_17\jre
> [artifact:mvn] Default locale: en_US, platform encoding: Cp1252
> [artifact:mvn] OS name: "windows 7" version: "6.1" arch: "amd64" Family: 
> "windows"
> BUILD SUCCESSFUL
> Total time: 0 seconds{noformat}
> But if I set fork="false", then I get:
> {noformat}
> [artifact:mvn] Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400)
> [artifact:mvn] Java version: 1.6.0_17
> [artifact:mvn] Java home: c:\Program Files\Java\jdk1.6.0_17\jre
> [artifact:mvn] Default locale: en_US, platform encoding: Cp1252
> [artifact:mvn] OS name: "windows 7" version: "6.1" arch: "amd64" Family: 
> "windows"
> [artifact:mvn] org.apache.tools.ant.ExitException: Permission 
> (java.lang.RuntimePermission exitVM) was not granted.
> [artifact:mvn]  at 
> org.apache.tools.ant.types.Permissions$MySM.checkExit(Permissions.java:196)
> [artifact:mvn]  at java.lang.Runtime.exit(Runtime.java:88)
> [artifact:mvn]  at java.lang.System.exit(System.java:904)
> [artifact:mvn]  at org.codehaus.classworlds.Launcher.main(Launcher.java:376)
> [artifact:mvn]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [artifact:mvn]  at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> [artifact:mvn]  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> [artifact:mvn]  at java.lang.reflect.Method.invoke(Method.java:597)
> [artifact:mvn]  at 
> org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:217)
> [artifact:mvn]  at 
> org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:152)
> [artifact:mvn]  at org.apache.tools.ant.taskdefs.Java.run(Java.java:764)
> [artifact:mvn]  at 
> org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:218)
> [artifact:mvn]  at 
> org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:132)
> [artifact:mvn]  at org.apache.tools.ant.taskdefs.Java.execute(Java.java:105)
> [artifact:mvn]  at org.apache.maven.artifact.ant.Mvn.execute(Mvn.java:81)
> [artifact:mvn]  at 
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
> [artifact:mvn]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [artifact:mvn]  at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> [artifact:mvn]  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> [artifact:mvn]  at java.lang.reflect.Method.invoke(Method.java:597)
> [artifact:mvn]  at 
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> [artifact:mvn]  at org.apache.tools.ant.Task.perform(Task.java:348)
> [artifact:mvn]  at org.apache.tools.ant.Target.execute(Target.java:357)
> [artifact:mvn]  at org.apache.tools.ant.Target.performTasks(Target.java:385)
> [artifact:mvn]  at 
> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337)
> [artifact:mvn]  at 
> org.apache.tools.ant.Project.executeTarget(Project.java:1306)
> [artifact:mvn]  at 
> org.apache

[jira] (MSKINS-28) Make it possible to center "powered by" logos in sidebar

[Andreas Sewe (JIRA)]

[ 
https://jira.codehaus.org/browse/MSKINS-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302549#comment-302549
 ] 

Andreas Sewe commented on MSKINS-28:


I just build a 1.3-SNAPSHOT. There are still two problems present, both due to 
the {{img.poweredBy}} being inline rather than block-level content:

* If the images are small, several may end up next to each other.
* If an image is larger than the sidebar, however, its edges are cut off.

You can experiment with this by explicitly setting the {{logo}}'s {{width}} in 
your {{site.xml}}.

If you move to block-level content, you avoid the first issue as non-floating 
blocks cannot sit side-by-side and the second issue because the contained block 
pushes the boundaries of its container (the sidebar).

> Make it possible to center "powered by" logos in sidebar
> 
>
> Key: MSKINS-28
> URL: https://jira.codehaus.org/browse/MSKINS-28
> Project: Maven Skins
>  Issue Type: Wish
>  Components: Fluido Skin
>Affects Versions: fluido-1.1
>Reporter: Andreas Sewe
>Assignee: Simone Tripodi
>Priority: Minor
> Fix For: fluido-1.2
>
> Attachments: maven-theme.patch, mskins-28-it.patch
>
>
> Left alignment may look OK for badge-like logos like 
> ,
>  but is quite ugly for other types of logo.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira