[jira] (MNG-3556) XML entity not supported in Maven 2

2012-03-28 Thread Brett Porter (JIRA) 

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

Brett Porter commented on MNG-3556:
---

Matt: combination of lack of parser support at the time in conjunction with the 
decision not to use it. My only thought at this stage some years later might be 
tool support. Regardless, it would be far better to focus on shipping support 
for more concise formats or ways to compose the model of other external 
fragments in a generic fashion rather than relying on XML tooling specifically.

> XML entity not supported in Maven 2
> ---
>
> Key: MNG-3556
> URL: https://jira.codehaus.org/browse/MNG-3556
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: General
>Reporter: Dan Fabulich
> Attachments: pom.xml
>
>
> The attached XML file defines and uses an XML entity called "&blah;".  It 
> validates in FF and in other XML parsers, but when I attempt to load it up in 
> Maven, I get the fellowing exception:
> {code}
> [INFO] Scanning for projects...
> [INFO] 
> 
> [ERROR] FATAL ERROR
> [INFO] 
> 
> [INFO] Error building POM (may not be this project's POM).
> Project ID: unknown
> POM Location: C:\blah\pom.xml
> Reason: Parse error reading POM. Reason: could not resolve entity named 
> 'blah' (position: START_TAG seen ...\r\n  &blah;... @11:15)  
> for project unknown at C:\blah\pom.xml
> [INFO] 
> 
> [INFO] Trace
> org.apache.maven.reactor.MavenExecutionException: Parse error reading POM. 
> Reason: could not resolve entity named 'blah' (position: START_TAG seen 
> ...\r\n  &blah;... @11:15)  for project unknown at 
> C:\blah\pom.xml
> at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:376)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:289)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.project.InvalidProjectModelException: Parse error 
> reading POM. Reason: could not resolve entity named 'blah' (position: 
> START_TAG seen ...\r\n  &blah;... @11:15)  for project 
> unknown at C:\blah\pom.xml
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1416)
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1377)
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:474)
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:197)
> at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:548)
> at 
> org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:458)
> at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:362)
> ... 11 more
> Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: could 
> not resolve entity named 'blah' (position: START_TAG seen ...\r\n  
> &blah;... @11:15)
> at 
> org.codehaus.plexus.util.xml.pull.MXParser.nextImpl(MXParser.java:1282)
> at org.codehaus.plexus.util.xml.pull.MXParser.next(MXParser.java:1093)
> at 
> org.codehaus.plexus.util.xml.pull.MXParser.nextText(MXParser.java:1058)
> at 
> org.apache.maven.model.io.xpp3.MavenXpp3Reader.parseModel(MavenXpp3Reader.java:2050)
> at 
> org.apache.maven.model.io.xpp3.MavenXpp3Reader.read(MavenXpp3Reader.java:4422)
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1412)
> ... 17 more
> [INFO] 
> 
> [INFO] Total time: < 1 second
> [INFO] Finished at: Mon Apr 28 14:43:06 PDT 2008
> [INFO] Final Memory: 1M/4M
> [INFO] 
> 
>

[jira] (MNG-3556) XML entity not supported in Maven 2

2012-03-28 Thread Matt DeBoer (JIRA) 

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

Matt DeBoer commented on MNG-3556:
--

It has been mentioned that the reason for not supporting XML entities is that 
it provides capability to create a non-self-contained pom.
That argument doesn't apply to internal XML entities. Is there some reason 
support for these was thrown out along with external entities?


> XML entity not supported in Maven 2
> ---
>
> Key: MNG-3556
> URL: https://jira.codehaus.org/browse/MNG-3556
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: General
>Reporter: Dan Fabulich
> Attachments: pom.xml
>
>
> The attached XML file defines and uses an XML entity called "&blah;".  It 
> validates in FF and in other XML parsers, but when I attempt to load it up in 
> Maven, I get the fellowing exception:
> {code}
> [INFO] Scanning for projects...
> [INFO] 
> 
> [ERROR] FATAL ERROR
> [INFO] 
> 
> [INFO] Error building POM (may not be this project's POM).
> Project ID: unknown
> POM Location: C:\blah\pom.xml
> Reason: Parse error reading POM. Reason: could not resolve entity named 
> 'blah' (position: START_TAG seen ...\r\n  &blah;... @11:15)  
> for project unknown at C:\blah\pom.xml
> [INFO] 
> 
> [INFO] Trace
> org.apache.maven.reactor.MavenExecutionException: Parse error reading POM. 
> Reason: could not resolve entity named 'blah' (position: START_TAG seen 
> ...\r\n  &blah;... @11:15)  for project unknown at 
> C:\blah\pom.xml
> at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:376)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:289)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.project.InvalidProjectModelException: Parse error 
> reading POM. Reason: could not resolve entity named 'blah' (position: 
> START_TAG seen ...\r\n  &blah;... @11:15)  for project 
> unknown at C:\blah\pom.xml
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1416)
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1377)
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:474)
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:197)
> at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:548)
> at 
> org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:458)
> at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:362)
> ... 11 more
> Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: could 
> not resolve entity named 'blah' (position: START_TAG seen ...\r\n  
> &blah;... @11:15)
> at 
> org.codehaus.plexus.util.xml.pull.MXParser.nextImpl(MXParser.java:1282)
> at org.codehaus.plexus.util.xml.pull.MXParser.next(MXParser.java:1093)
> at 
> org.codehaus.plexus.util.xml.pull.MXParser.nextText(MXParser.java:1058)
> at 
> org.apache.maven.model.io.xpp3.MavenXpp3Reader.parseModel(MavenXpp3Reader.java:2050)
> at 
> org.apache.maven.model.io.xpp3.MavenXpp3Reader.read(MavenXpp3Reader.java:4422)
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1412)
> ... 17 more
> [INFO] 
> 
> [INFO] Total time: < 1 second
> [INFO] Finished at: Mon Apr 28 14:43:06 PDT 2008
> [INFO] Final Memory: 1M/4M
> [INFO] 
> 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your

[jira] (MRELEASE-727) release plugin uses wrong checkout directory

2012-03-28 Thread JIRA 

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

L. Compère commented on MRELEASE-727:
-

Hi all!

I'm using maven 2.2.1 with maven-release-plugin in version 2.2.2 and am getting 
the problem initially mentioned "When performing a release build on a multi 
module project, the plugin uses a wrong checkout directory and therefore is 
unable to perform the release".

Is there a maven-release-plugin version I can use which fixes the problem?

I can't seem to find version 2.2.3.

thanks!

> release plugin uses wrong checkout directory
> 
>
> Key: MRELEASE-727
> URL: https://jira.codehaus.org/browse/MRELEASE-727
> Project: Maven 2.x Release Plugin
>  Issue Type: Bug
>  Components: perform
>Affects Versions: 2.2, 2.2.2
> Environment: mvn 3.0.3
>Reporter: Dominik Bartholdi
>Assignee: Olivier Lamy
>Priority: Blocker
> Fix For: 2.3
>
> Attachments: flat-project-layout.patch, release_failed.txt, 
> testproject.zip
>
>
> When performing a release build on a multi module project, the plugin uses a 
> wrong checkout directory and therefore is unable to perform the release.
> I tested this with both version 2.2 and 2.2.2
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-release-plugin:2.2.2:perform (default-cli) on 
> project test_multi_parent: Error executing Maven. Working directory 
> "/Users/domi/work/ws/sts_0/test_multi_parent/target/checkout/test_multi_parent/test_multi_parent"
>  does not exist! -> [Help 1]
> We use flat project structure (where parent and modul project are in the same 
> directory)
> The SVN Repo looks like this:
> .../svnrepos/KUQ/trunk/test_multi_parent
> .../svnrepos/KUQ/trunk/test_multi_module1
> I'll attache a minimal test project to reproduce it and a file containing the 
> whole log output for release:prepare and release:perform
> To reproduce the problem:
> - adjust the SVN paths in the pom.xml
> - checkin to SVN
> - release:prepare
> - release:perform -Dgoals=install

--
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-396) release:branch goal does not honor autoVersionSubmodules=true configuration property

2012-03-28 Thread Robert Scholte (JIRA) 

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

Robert Scholte updated MRELEASE-396:


Description: 
In my pom, I have:
{code:xml}
  
maven-release-plugin

  true
  false

  
{code}
Yet, when I run:

{{mvn release:branch -DbranchName=JBossON_2_1_2_SP -DupdateBranchVersions=true 
-DupdateWorkingCopyVersions=false}}

I am still prompted for branch versions for all sub-modules in my reactor, i.e.:
{noformat}
What is the branch version for "JON"? (org.jboss.on:jboss-on-parent) 
2.1.2.GA-SNAPSHOT: : 2.1.2.SP1-SNAPSHOT
What is the branch version for "JON Parent"? (org.jboss.on:jon-parent) 
2.1.2.GA-SNAPSHOT: : 2.1.2.SP1-SNAPSHOT
What is the branch version for "JON Tomcat Plugin"? 
(org.jboss.on:rhq-tomcat-plugin) 2.1.2.GA-SNAPSHOT: : 2.1.2.SP1-SNAPSHOT
What is the branch version for "JON JBossAS 3.2.x/4.x Plugin"? 
(org.jboss.on:rhq-jbossas-plugin) 2.1.2.GA-SNAPSHOT: : 2.1.2.SP1-SNAPSHOT
What is the branch version for "JON Hibernate Plugin"? 
(org.jboss.on:rhq-hibernate-plugin) 2.1.2.GA-SNAPSHOT: : 2.1.2.SP1-SNAPSHOT
etc...
{noformat}
I also tried specifying autoVersionSubmodules=true via the command line to no 
avail, i.e.:

{{mvn release:branch -DbranchName=JBossON_2_1_2_SP -DupdateBranchVersions=true 
-DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true}}


  was:
In my pom, I have:

  
maven-release-plugin

  true
  false

  

Yet, when I run:

mvn release:branch -DbranchName=JBossON_2_1_2_SP -DupdateBranchVersions=true 
-DupdateWorkingCopyVersions=false

I am still prompted for branch versions for all sub-modules in my reactor, i.e.:

What is the branch version for "JON"? (org.jboss.on:jboss-on-parent) 
2.1.2.GA-SNAPSHOT: : 2.1.2.SP1-SNAPSHOT
What is the branch version for "JON Parent"? (org.jboss.on:jon-parent) 
2.1.2.GA-SNAPSHOT: : 2.1.2.SP1-SNAPSHOT
What is the branch version for "JON Tomcat Plugin"? 
(org.jboss.on:rhq-tomcat-plugin) 2.1.2.GA-SNAPSHOT: : 2.1.2.SP1-SNAPSHOT
What is the branch version for "JON JBossAS 3.2.x/4.x Plugin"? 
(org.jboss.on:rhq-jbossas-plugin) 2.1.2.GA-SNAPSHOT: : 2.1.2.SP1-SNAPSHOT
What is the branch version for "JON Hibernate Plugin"? 
(org.jboss.on:rhq-hibernate-plugin) 2.1.2.GA-SNAPSHOT: : 2.1.2.SP1-SNAPSHOT
etc...

I also tried specifying autoVersionSubmodules=true via the command line to no 
avail, i.e.:

mvn release:branch -DbranchName=JBossON_2_1_2_SP -DupdateBranchVersions=true 
-DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true



> release:branch goal does not honor autoVersionSubmodules=true configuration 
> property
> 
>
> Key: MRELEASE-396
> URL: https://jira.codehaus.org/browse/MRELEASE-396
> Project: Maven 2.x Release Plugin
>  Issue Type: Bug
>  Components: branch
>Affects Versions: 2.0-beta-8
> Environment: multi-module build
>Reporter: Ian Springer
>
> In my pom, I have:
> {code:xml}
>   
> maven-release-plugin
> 
>   true
>   false
> 
>   
> {code}
> Yet, when I run:
> {{mvn release:branch -DbranchName=JBossON_2_1_2_SP 
> -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false}}
> I am still prompted for branch versions for all sub-modules in my reactor, 
> i.e.:
> {noformat}
> What is the branch version for "JON"? (org.jboss.on:jboss-on-parent) 
> 2.1.2.GA-SNAPSHOT: : 2.1.2.SP1-SNAPSHOT
> What is the branch version for "JON Parent"? (org.jboss.on:jon-parent) 
> 2.1.2.GA-SNAPSHOT: : 2.1.2.SP1-SNAPSHOT
> What is the branch version for "JON Tomcat Plugin"? 
> (org.jboss.on:rhq-tomcat-plugin) 2.1.2.GA-SNAPSHOT: : 2.1.2.SP1-SNAPSHOT
> What is the branch version for "JON JBossAS 3.2.x/4.x Plugin"? 
> (org.jboss.on:rhq-jbossas-plugin) 2.1.2.GA-SNAPSHOT: : 2.1.2.SP1-SNAPSHOT
> What is the branch version for "JON Hibernate Plugin"? 
> (org.jboss.on:rhq-hibernate-plugin) 2.1.2.GA-SNAPSHOT: : 2.1.2.SP1-SNAPSHOT
> etc...
> {noformat}
> I also tried specifying autoVersionSubmodules=true via the command line to no 
> avail, i.e.:
> {{mvn release:branch -DbranchName=JBossON_2_1_2_SP 
> -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false 
> -DautoVersionSubmodules=true}}

--
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-653) Filter reactor projects that are concerned by a submodule branch operation

2012-03-28 Thread Robert Scholte (JIRA) 

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

Robert Scholte updated MRELEASE-653:


Description: 
We have the requirement to create a separate branch of one submodule when 
releasing the entire project. We solved this with the follwoing config in 
pom.xml of concerned submodule:
{code:xml}

  branchSubModule
  

  
org.apache.maven.plugins
maven-release-plugin
false

  
explorer-branch
false
package

  branch


  re${project.version}-submodule
  ${project.version}
  true
  ${project.version}-00-SNAPSHOT

  

  

  

{code}
We launch the release build of parent project with:

{{mvn release:prepare release:perform -DreleaseProfiles=branchSubModule}}

Beside issue adressed by MRELEASE-619, we also face the problem that all 
submodules are affected when our special submodule gets branched.

We solved this issue by filtering reactor projects with the current working 
path.

  was:
We have the requirement to create a separate branch of one submodule when 
releasing the entire project. We solved this with the follwoing config in 
pom.xml of concerned submodule:


  branchSubModule
  

  
org.apache.maven.plugins
maven-release-plugin
false

  
explorer-branch
false
package

  branch


  re${project.version}-submodule
  ${project.version}
  true
  ${project.version}-00-SNAPSHOT

  

  

  


We launch the release build of parent project with:

mvn release:prepare release:perform -DreleaseProfiles=branchSubModule

Beside issue adressed by MRELEASE-619, we also face the problem that all 
submodules are affected when our special submodule gets branched.

We solved this issue by filtering reactor projects with the current working 
path.


> Filter reactor projects that are concerned by a submodule branch operation
> --
>
> Key: MRELEASE-653
> URL: https://jira.codehaus.org/browse/MRELEASE-653
> Project: Maven 2.x Release Plugin
>  Issue Type: Bug
>  Components: branch
>Affects Versions: 2.1
>Reporter: Lucien Weller
> Attachments: filter-modules.patch
>
>
> We have the requirement to create a separate branch of one submodule when 
> releasing the entire project. We solved this with the follwoing config in 
> pom.xml of concerned submodule:
> {code:xml}
> 
>   branchSubModule
>   
> 
>   
> org.apache.maven.plugins
> maven-release-plugin
> false
> 
>   
> explorer-branch
> false
> package
> 
>   branch
> 
> 
>   re${project.version}-submodule
>   ${project.version}
>   true
>   ${project.version}-00-SNAPSHOT
> 
>   
> 
>   
> 
>   
> 
> {code}
> We launch the release build of parent project with:
> {{mvn release:prepare release:perform -DreleaseProfiles=branchSubModule}}
> Beside issue adressed by MRELEASE-619, we also face the problem that all 
> submodules are affected when our special submodule gets branched.
> We solved this issue by filtering reactor projects with the current working 
> path.

--
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-617) Maven release plugin branch goal failing with authentication error

2012-03-28 Thread Robert Scholte (JIRA) 

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

Robert Scholte updated MRELEASE-617:


Description: 
When I try to run branch on any application I get the following error:

{{mvn release:branch -DbranchName=TEST -Dusername=ricardo}}
{noformat}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-release-plugin:2.0:branch (default-cli) on 
project throttle-spring-annotations: Unable to branch SCM
[ERROR] Provider message:
[ERROR] The svn branch command failed.
[ERROR] Command output:
[ERROR] svn: OPTIONS of 
'http://nmsvn.bskyb.com:1080/repositories/loyalty/throttle-spring-annotations': 
authorization failed: Could not authenticate to server: rejected Basic challenge
{noformat}
I can execute subversion commits out of maven from the command line without 
requiring my password so not sure why this is failing.

  was:
When I try to run branch on any application I get the following error:

> mvn release:branch -DbranchName=TEST -Dusername=ricardo

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-release-plugin:2.0:branch (default-cli) on 
project throttle-spring-annotations: Unable to branch SCM
[ERROR] Provider message:
[ERROR] The svn branch command failed.
[ERROR] Command output:
[ERROR] svn: OPTIONS of 
'http://nmsvn.bskyb.com:1080/repositories/loyalty/throttle-spring-annotations': 
authorization failed: Could not authenticate to server: rejected Basic challenge

I can execute subversion commits out of maven from the command line without 
requiring my password so not sure why this is failing.


> Maven release plugin branch goal failing with authentication error
> --
>
> Key: MRELEASE-617
> URL: https://jira.codehaus.org/browse/MRELEASE-617
> Project: Maven 2.x Release Plugin
>  Issue Type: Bug
>  Components: branch
>Affects Versions: 2.1
> Environment: Fedora Core 13, subversion-1.6.13-1.fc13, maven 3.0, 
> Java JDK 1.6.0_20
>Reporter: Ricardo Gladwell
>
> When I try to run branch on any application I get the following error:
> {{mvn release:branch -DbranchName=TEST -Dusername=ricardo}}
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-release-plugin:2.0:branch (default-cli) on 
> project throttle-spring-annotations: Unable to branch SCM
> [ERROR] Provider message:
> [ERROR] The svn branch command failed.
> [ERROR] Command output:
> [ERROR] svn: OPTIONS of 
> 'http://nmsvn.bskyb.com:1080/repositories/loyalty/throttle-spring-annotations':
>  authorization failed: Could not authenticate to server: rejected Basic 
> challenge
> {noformat}
> I can execute subversion commits out of maven from the command line without 
> requiring my password so not sure why this is failing.

--
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-650) Perforce Client Where command prefixes a hyphen when returning source location on *nix

2012-03-28 Thread Robert Scholte (JIRA) 

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

Robert Scholte updated MRELEASE-650:


Description: 
Performing the following command on a *nix box:

{{mvn -X --batch-mode -DupdateBranchVersions=true 
-DuseArtifactIdforBranchTag=true -DbranchName=GARY release:clean 
release:branch}}

Returns:
{noformat}
DEBUG] Executing: /bin/sh -c p4 where /[censored]/Branch/pom.xml
 [DEBUG] -//depot/se/multi-module-test/pom.xml 
//com.xxx.multi.module_parent_HEAD_Branch-3936/pom.xml 
/[censored]/Branch/pom.xml
 [DEBUG] Actual POM location: -//depot/se/multi-module-test
 [INFO] The SCM location in your pom.xml (//depot/se/multi-module-test) is not 
equal to the depot location (-//depot/se/multi-module-test). This happens 
frequently with branches. Ignoring the SCM location.
 [DEBUG] Sending changelist:
 Change: new
 
 Description:
  [maven-release-plugin] prepare branch GARY
 
 Files:
  -//depot/se/multi-module-test/pom.xml
  -//depot/se/multi-module-test/versionless-module/pom.xml
  -//depot/se/multi-module-test/versioned-module/pom.xml
 
 [ERROR] CommandLineException Exit code: 1 - Error in change specification.
 Can't include file(s) not already opened.
 Open new files with p4 add, p4 edit, etc.
 
 Command line was:p4 -d /[censored]/Branch submit -i
 org.codehaus.plexus.util.cli.CommandLineException: Exit code: 1 - Error in 
change specification.
 Can't include file(s) not already opened.
 Open new files with p4 add, p4 edit, etc.
 
 Command line was:p4 -d /[censored]/Branch submit -i
  at 
org.apache.maven.scm.provider.perforce.command.checkin.PerforceCheckInCommand.executeCheckInCommand(PerforceCheckInCommand.java:88)
  at 
org.apache.maven.scm.command.checkin.AbstractCheckInCommand.executeCommand(AbstractCheckInCommand.java:53)
  at 
org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:59)
  at 
org.apache.maven.scm.provider.perforce.PerforceScmProvider.checkin(PerforceScmProvider.java:186)
  at 
org.apache.maven.scm.provider.AbstractScmProvider.checkIn(AbstractScmProvider.java:356)
  at 
org.apache.maven.shared.release.phase.AbstractScmCommitPhase.checkin(AbstractScmCommitPhase.java:159)
  at 
org.apache.maven.shared.release.phase.AbstractScmCommitPhase.performCheckins(AbstractScmCommitPhase.java:148)
  at 
org.apache.maven.shared.release.phase.ScmCommitPreparationPhase.runLogic(ScmCommitPreparationPhase.java:75)
  at 
org.apache.maven.shared.release.phase.AbstractScmCommitPhase.execute(AbstractScmCommitPhase.java:79)
  at 
org.apache.maven.shared.release.DefaultReleaseManager.branch(DefaultReleaseManager.java:389)
  at 
org.apache.maven.shared.release.DefaultReleaseManager.branch(DefaultReleaseManager.java:360)
  at 
org.apache.maven.plugins.release.BranchReleaseMojo.execute(BranchReleaseMojo.java:235)
  at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
  at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
  at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
  at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
  at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  at java.lang.reflect.Method.invoke(Method.java:597)
  at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
  at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
  at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
  at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
{noformat}
Attached a fix, based on 1.4 version of the maven-scm-provider-perforce artifact

  was:
Performing the following command on a *nix box:

mvn -X --batch-mode -DupdateBranchVersions=true 
-DuseArtifactIdforBranchTag=true -DbranchName=GARY release:clean release:branch

Returns:

DEBUG] Executing: /bin/sh -c p4 where /[censored]/Branch/pom.xml
 [DEBUG] -//depot/se/multi-module-test/pom.xml 
//com.xxx.multi.module_parent_HEAD_Branch-3936/pom.xml 
/[censored]/Branch/pom.xml
 [DEBUG] Actual POM location: -//de

[jira] (MRELEASE-484) release:rollback fails after branch with NPE and complaint about missing scm URL

2012-03-28 Thread Robert Scholte (JIRA) 

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

Robert Scholte updated MRELEASE-484:


Component/s: rollback
Description: 
After a problem with release:branch (possibly the 'remoteTagging' problem) an 
attempt to run rollback got me the following. The SCM urls are indeed in the 
POM.

{noformat}
[INFO] Trace
java.lang.NullPointerException: The scm url cannot be null.
at 
org.apache.maven.scm.manager.AbstractScmManager.makeScmRepository(AbstractScmManager.java:181)
at 
org.apache.maven.shared.release.scm.DefaultScmRepositoryConfigurator.getConfiguredRepository(DefaultScmRepositoryConfigurator.java:62)
at 
org.apache.maven.shared.release.phase.RestoreBackupPomsPhase.restorePomBackup(RestoreBackupPomsPhase.java:100)
at 
org.apache.maven.shared.release.phase.RestoreBackupPomsPhase.execute(RestoreBackupPomsPhase.java:69)
at 
org.apache.maven.shared.release.DefaultReleaseManager.rollback(DefaultReleaseManager.java:250)
at 
org.apache.maven.shared.release.DefaultReleaseManager.rollback(DefaultReleaseManager.java:227)
at 
org.apache.maven.plugins.release.RollbackReleaseMojo.execute(RollbackReleaseMojo.java:54)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO] 
{noformat}

  was:
After a problem with release:branch (possibly the 'remoteTagging' problem) an 
attempt to run rollback got me the following. The SCM urls are indeed in the 
POM.


[INFO] Trace
java.lang.NullPointerException: The scm url cannot be null.
at 
org.apache.maven.scm.manager.AbstractScmManager.makeScmRepository(AbstractScmManager.java:181)
at 
org.apache.maven.shared.release.scm.DefaultScmRepositoryConfigurator.getConfiguredRepository(DefaultScmRepositoryConfigurator.java:62)
at 
org.apache.maven.shared.release.phase.RestoreBackupPomsPhase.restorePomBackup(RestoreBackupPomsPhase.java:100)
at 
org.apache.maven.shared.release.phase.RestoreBackupPomsPhase.execute(RestoreBackupPomsPhase.java:69)
at 
org.apache.maven.shared.release.DefaultReleaseManager.rollback(DefaultReleaseManager.java:250)
at 
org.apache.maven.shared.release.DefaultReleaseManager.rollback(DefaultReleaseManager.java:227)
at 
org.apache.maven.plugins.release.RollbackReleaseMojo.execute(RollbackReleaseMojo.java:54)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
at org.apache.maven.DefaultMaven.execute(DefaultMave

[jira] (SUREFIRE-855) Allow failsafe to use actual jar file instead of target/classes

2012-03-28 Thread Benson Margulies (JIRA) 
Benson Margulies created SUREFIRE-855:
-

 Summary: Allow failsafe to use actual jar file instead of 
target/classes
 Key: SUREFIRE-855
 URL: https://jira.codehaus.org/browse/SUREFIRE-855
 Project: Maven Surefire
  Issue Type: Improvement
  Components: Maven Failsafe Plugin
Affects Versions: 2.12
Reporter: Benson Margulies


I've got some code that calls Class.getPackage() to see the manifest. I want to 
test it. A seemingly logical scheme here would be to have failsafe put the 
actual packaged jar into the classpath instead of the unpacked directory -- or 
some way to get the manifest copied across.

--
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] (MNG-5162) Maven stuck on downloading dependencies when using java 7.

2012-03-28 Thread gopi (JIRA) 

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

gopi edited comment on MNG-5162 at 3/28/12 3:30 PM:


Today i have upgraded maven 2.2.1 to 3.0.4 on Linux 64 bit system and when i 
invoke "mvn clean install" command build is keep throwing below exceptions 
since 8 hours and build still going.   (Note: everything works fine on Window 
system for the same project with maven 3.0.4)

-bash-3.2$ mvn --version
Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
Maven home: /usr/local/maven/apache-maven-3.0.4
Java version: 1.6.0_29, vendor: Sun Microsystems Inc.
Java home: /usr/java/jdk1.6.0_29/jre
Default locale: en_US, platform encoding: ANSI_X3.4-1968
OS name: "linux", version: "2.6.18-194.3.1.el5", arch: "amd64", family: "unix"



Please suggest, if i miss any steps.

28-Mar-2012 09:41:36  Downloaded: 
http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/maven-metadata.xml
 (588 B at 0.7 KB/sec) 
28-Mar-2012 09:42:06  [WARNING] Failed to write resolution tracking file 
/home/gopigadu/.m2/repository/org/apache/maven/plugins/maven-jar-plugin/resolver-status.properties
 
28-Mar-2012 09:42:06  java.io.IOException: No locks available 


28-Mar-2012 09:43:06  [WARNING] Failed to write resolution tracking file 
/home/gopigadu/.m2/repository/org/apache/maven/plugins/maven-jar-plugin/2.4/_maven.repositories
 
28-Mar-2012 09:43:06  java.io.IOException: No locks available 



  was (Author: gkrsihan):
Today i have upgraded maven 2.2.1 to 3.0.4 on Linux 64 bit system and when 
i invoke "mvn clean install" command build is keep throwing below exceptions 
since 8 hours and build still going.   (Note: everything works fine on Window 
system for the same project with maven 3.0.4)

Here is my environment variables:
JAVA_HOME=/usr/java/jdk1.6.0_29
M2_HOME=/usr/local/maven/apache-maven-3.0.4

Please suggest, if i miss any steps.

28-Mar-2012 09:41:36  Downloaded: 
http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/maven-metadata.xml
 (588 B at 0.7 KB/sec) 
28-Mar-2012 09:42:06  [WARNING] Failed to write resolution tracking file 
/home/gopigadu/.m2/repository/org/apache/maven/plugins/maven-jar-plugin/resolver-status.properties
 
28-Mar-2012 09:42:06  java.io.IOException: No locks available 


28-Mar-2012 09:43:06  [WARNING] Failed to write resolution tracking file 
/home/gopigadu/.m2/repository/org/apache/maven/plugins/maven-jar-plugin/2.4/_maven.repositories
 
28-Mar-2012 09:43:06  java.io.IOException: No locks available 


  
> Maven stuck on downloading dependencies when using java 7.
> --
>
> Key: MNG-5162
> URL: https://jira.codehaus.org/browse/MNG-5162
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 3.0.1, 3.0.3
> Environment: Windows 7 Professional x64
>Reporter: Lukas Stampf
> Attachments: dump.tdump, edb.zip, java6.jpg, java7.jpg
>
>
> When JAVA_HOME is set to the Java 7 JDK and I run "mvn clean install" on my 
> project the following happens:
> Maven downloads the dependencies to my local repository, as usual, but on 
> some dependencies he stops while downloading and never continues. He is just 
> stuck. I then must use CTRL+C and start from the beginning with my build, but 
> it doesnt help because he gets stuck at the same dependencies again. In my 
> local repository, where the failed dependency belongs is just a tmp file 
> like: org.apache.servicemix.bundles.serp-1.13.1_4.jar.tmp90088a9d7e9e4642
> When I set JAVA_HOME to java 6 Update 27 everything works fine.
> The problem does not seem to be related to JAR size because, I saw it fail on 
> 19kb dependencies as well.
> I have the impression it happens mostly to JARs with "long" names.
> Attached you will find a subproject of the project I am working on. it 
> contains the org.apache.servicemix.bundles.serp-1.13.1_4 dependency, which is 
> one of almost all servicemix bundles that is failing for me, when i use java7.

--
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] (MNG-5162) Maven stuck on downloading dependencies when using java 7.

2012-03-28 Thread gopi (JIRA) 

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

gopi commented on MNG-5162:
---

Today i have upgraded maven 2.2.1 to 3.0.4 on Linux 64 bit system and when i 
invoke "mvn clean install" command build is keep throwing below exceptions 
since 8 hours and build still going.   (Note: everything works fine on Window 
system for the same project with maven 3.0.4)

Here is my environment variables:
JAVA_HOME=/usr/java/jdk1.6.0_29
M2_HOME=/usr/local/maven/apache-maven-3.0.4

Please suggest, if i miss any steps.

28-Mar-2012 09:41:36  Downloaded: 
http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/maven-metadata.xml
 (588 B at 0.7 KB/sec) 
28-Mar-2012 09:42:06  [WARNING] Failed to write resolution tracking file 
/home/gopigadu/.m2/repository/org/apache/maven/plugins/maven-jar-plugin/resolver-status.properties
 
28-Mar-2012 09:42:06  java.io.IOException: No locks available 


28-Mar-2012 09:43:06  [WARNING] Failed to write resolution tracking file 
/home/gopigadu/.m2/repository/org/apache/maven/plugins/maven-jar-plugin/2.4/_maven.repositories
 
28-Mar-2012 09:43:06  java.io.IOException: No locks available 



> Maven stuck on downloading dependencies when using java 7.
> --
>
> Key: MNG-5162
> URL: https://jira.codehaus.org/browse/MNG-5162
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 3.0.1, 3.0.3
> Environment: Windows 7 Professional x64
>Reporter: Lukas Stampf
> Attachments: dump.tdump, edb.zip, java6.jpg, java7.jpg
>
>
> When JAVA_HOME is set to the Java 7 JDK and I run "mvn clean install" on my 
> project the following happens:
> Maven downloads the dependencies to my local repository, as usual, but on 
> some dependencies he stops while downloading and never continues. He is just 
> stuck. I then must use CTRL+C and start from the beginning with my build, but 
> it doesnt help because he gets stuck at the same dependencies again. In my 
> local repository, where the failed dependency belongs is just a tmp file 
> like: org.apache.servicemix.bundles.serp-1.13.1_4.jar.tmp90088a9d7e9e4642
> When I set JAVA_HOME to java 6 Update 27 everything works fine.
> The problem does not seem to be related to JAR size because, I saw it fail on 
> 19kb dependencies as well.
> I have the impression it happens mostly to JARs with "long" names.
> Attached you will find a subproject of the project I am working on. it 
> contains the org.apache.servicemix.bundles.serp-1.13.1_4 dependency, which is 
> one of almost all servicemix bundles that is failing for me, when i use java7.

--
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-128) SCM properties being replaced during release:perform

2012-03-28 Thread Robert Scholte (JIRA) 

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

Robert Scholte closed MRELEASE-128.
---

Resolution: Fixed

> SCM properties being replaced during release:perform
> 
>
> Key: MRELEASE-128
> URL: https://jira.codehaus.org/browse/MRELEASE-128
> Project: Maven 2.x Release Plugin
>  Issue Type: Bug
>  Components: prepare
> Environment: Windows XP client, Linux repo, CVS, Maven 2.0.4
>Reporter: Craig Dickson
>Assignee: Robert Scholte
>Priority: Critical
>  Labels: properties
> Fix For: 2.3
>
> Attachments: after-release-perform-pom.xml, 
> after-release-prepre-pom.xml, MNG-128-maven-release-manager.patch, 
> MRELEASE-128_cvs_hack_RewritePomsForDevelopmentPhase.java.patch, 
> original-pom.xml
>
>
> The  section of a pom in CVS for a pom archetype project looks like this 
> prior to executing release:prepare :
> 
>   ${base.cvs.url}:commons-maven/uber-pom
>   
> ${base.cvs.url}:commons-maven/uber-pom
>   ${base.viewcvs.url}/commons-maven/uber-pom
> 
> Then after executing release:prepare, the pom in CVS looks like this (new 
>  tag is only difference):
> 
>   ${base.cvs.url}:commons-maven/uber-pom
>   
> ${base.cvs.url}:commons-maven/uber-pom
>   ${base.viewcvs.url}/commons-maven/uber-pom
>   R-1_7
> 
> Then after executing release:perform, the pom looks like this in CVS:
> 
>   
> scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom
>   
> scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom
>   
> http://behrcvs.masco-coatings.com/cgi-bin/viewcvs.cgi/commons-maven/uber-pom
> 
> Notice that the properties that were there for the base URLs for CVS and 
> ViewCVS have been replaced with literal values. 
> No other properties in the POM are being replaced

--
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] (MDEP-287) Make maven-dependency-plugin @threadSafe

2012-03-28 Thread Tomasz Borek (JIRA) 

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

Tomasz Borek commented on MDEP-287:
---

Brian, how it looks? :-) Is Falko's comment right? Do you need some help with 
this issue?

I registered here solely for Maven dependency plug-in threadsafety so am eager 
about this. ;-)

> Make maven-dependency-plugin @threadSafe
> 
>
> Key: MDEP-287
> URL: https://jira.codehaus.org/browse/MDEP-287
> Project: Maven 2.x Dependency Plugin
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Andreas Sewe
>Assignee: Brian Fox
>
> The plugin is not yet marked as @threadSafe.

--
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

2012-03-28 Thread Andreas Sewe (JIRA) 

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

Andreas Sewe updated MSKINS-28:
---

Attachment: maven-theme.patch

Added a patch to accompany the integration test. (CSS tested on Firefox 11 
only.)

> 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

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

2012-03-28 Thread Simone Tripodi (JIRA) 

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

Simone Tripodi commented on MSKINS-28:
--

GREAT, thanks a lot! I'll review the patch ASAP!
best,
-Simo

> 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: 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] (MSKINS-28) Make it possible to center "powered by" logos in sidebar

2012-03-28 Thread Andreas Sewe (JIRA) 

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

Andreas Sewe updated MSKINS-28:
---

Attachment: mskins-28-it.patch

Integration test using 5 different-sized "powered by" logos.

> 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: 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] (MPDF-55) Nested items in site.xml are ignored

2012-03-28 Thread Lukas Theussl (JIRA) 

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

Lukas Theussl commented on MPDF-55:
---

Can you attach a simple demonstration project? pdf.xml and site.xml should 
indeed be equally supported.

> Nested items in site.xml are ignored
> 
>
> Key: MPDF-55
> URL: https://jira.codehaus.org/browse/MPDF-55
> Project: Maven 2.x PDF Plugin
>  Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Jonas Grote
>Assignee: Lukas Theussl
>
> MPDF-9 is closed, but does not seem to be implemented correctly: Nested items 
> in site.xml are being ignored.
> If items are nested in pdf.xml, they are being included into the pdf, though.
> Best regards

--
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] (MPDF-55) Nested items in site.xml are ignored

2012-03-28 Thread Jonas Grote (JIRA) 

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

Jonas Grote edited comment on MPDF-55 at 3/28/12 2:37 AM:
--

I was aware of MPDF-10, yet I believe it is a different issue.

MPDF-10 as well as 
http://maven.apache.org/plugins/maven-pdf-plugin/limitations.html mention the 
fact that menu sub-items start a new chapter.

This issue was not intended to be about pdf.xml. It aims at usage of the pdf 
plugin if there is only a site.xml. Menu sub-items are not appearing in the 
created pdf *at all*, even if they are listed in the site.xml.

I believe there should be a rather simple way to fix this, since this works for 
sub-items in pdf.xml.

Thanks for your time and consideration.

  was (Author: jfgrote):
I was aware of MFDF-10, yet I believe it is a different issue.

MFDF-10 as well as 
http://maven.apache.org/plugins/maven-pdf-plugin/limitations.html mention the 
fact that menu sub-items start a new chapter.

This issue was not intended to be about pdf.xml. It aims at usage of the pdf 
plugin if there is only a site.xml. Menu sub-items are not appearing in the 
created pdf *at all*, even if they are listed in the site.xml.

I believe there should be a rather simple way to fix this, since this works for 
sub-items in pdf.xml.

Thanks for your time and consideration.
  
> Nested items in site.xml are ignored
> 
>
> Key: MPDF-55
> URL: https://jira.codehaus.org/browse/MPDF-55
> Project: Maven 2.x PDF Plugin
>  Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Jonas Grote
>Assignee: Lukas Theussl
>
> MPDF-9 is closed, but does not seem to be implemented correctly: Nested items 
> in site.xml are being ignored.
> If items are nested in pdf.xml, they are being included into the pdf, though.
> Best regards

--
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] (MPDF-55) Nested items in site.xml are ignored

2012-03-28 Thread Jonas Grote (JIRA) 

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

Jonas Grote reopened MPDF-55:
-


I was aware of MFDF-10, yet I believe it is a different issue.

MFDF-10 as well as 
http://maven.apache.org/plugins/maven-pdf-plugin/limitations.html mention the 
fact that menu sub-items start a new chapter.

This issue was not intended to be about pdf.xml. It aims at usage of the pdf 
plugin if there is only a site.xml. Menu sub-items are not appearing in the 
created pdf *at all*, even if they are listed in the site.xml.

I believe there should be a rather simple way to fix this, since this works for 
sub-items in pdf.xml.

Thanks for your time and consideration.

> Nested items in site.xml are ignored
> 
>
> Key: MPDF-55
> URL: https://jira.codehaus.org/browse/MPDF-55
> Project: Maven 2.x PDF Plugin
>  Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Jonas Grote
>Assignee: Lukas Theussl
>
> MPDF-9 is closed, but does not seem to be implemented correctly: Nested items 
> in site.xml are being ignored.
> If items are nested in pdf.xml, they are being included into the pdf, though.
> Best regards

--
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

2012-03-28 Thread Simone Tripodi (JIRA) 

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

Simone Tripodi commented on MSKINS-28:
--

Thankjs for the feedbacks Andreas - can you provide please a patch with a 
testcase? It will be much more than appreciated!
Many thanks in advance, all the best!

> 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
>
>
> 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] (MSKINS-28) Make it possible to center "powered by" logos in sidebar

2012-03-28 Thread Andreas Sewe (JIRA) 

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

Andreas Sewe reopened MSKINS-28:



See my previous comment on problems with multiple "powered by" logos.

> 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
>
>
> 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] (MSKINS-28) Make it possible to center "powered by" logos in sidebar

2012-03-28 Thread Andreas Sewe (JIRA) 

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

Andreas Sewe commented on MSKINS-28:


Unfortunately, as I just discovered, the fix doesn't quite work as soon as you 
have *multiple* "powered by" logos.

Compare the left sidebars of the following two sites, for example: 
http://www.alia4j.org/alia4j/ (fluido 1.1) and http://stage.alia4j.org/alia4j/ 
(fluido 1.2). When viewing the latter in a browser whose viewport is wide 
enough (1920px works; alternatively adjust the logos' width using Firebug or 
some such), the two logos (AOSD Europe, CASED) are shown side by side, which 
can be quite ugly, depending on the logos' sizes and aspect ratios.

IMHO, turning the images into block-level elements and centering those would be 
a better solution than centering them as inline-level elements with 
{{text-align}}:

{quote}
img.poweredBy {
display: block;
margin-left: auto;
margin-right: auto;
}
{quote}

> 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
>
>
> 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