[jira] (MRELEASE-794) Maven release plugin with git - Create release branch only for a particular sub-module

2012-09-10 Thread Gayathri Muralidharan (JIRA)
Gayathri Muralidharan created MRELEASE-794:
--

 Summary: Maven release plugin with git - Create release branch 
only for a particular sub-module
 Key: MRELEASE-794
 URL: https://jira.codehaus.org/browse/MRELEASE-794
 Project: Maven 2.x Release Plugin
  Issue Type: New Feature
  Components: scm
Affects Versions: 2.3.2
 Environment: git
Reporter: Gayathri Muralidharan
Priority: Minor


I am trying to use maven release plugin for creating a branch from trunk.

Ex. repository.git/ 
child1/ 
child2/

The plugin creates a new branch that contains my entire repository. How can i 
restrict it to create a branch that contains only child1 ?

Currently the pom.xml connection, developer connection and url are as follows :

scm
  connectionscm:git:ssh://githost/repository.git/connection
 developerConnectionscm:git:ssh://githost/repository.git/developerConnection
  urlscm:git:ssh://githost/repository.git/url
  tagHEAD/tag
/scm

In svn we used to achieve this by using the absolute path to child1 in 
developerConnection.

Posted the issue here :

http://stackoverflow.com/questions/12280992/maven-release-plugin-with-git-developer-connection


Thanks,
Gayathri

--
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-5323) Add ability to interrupt a build with SUCCESS status from maven plugins.

2012-09-10 Thread Gregor B. Rosenauer (JIRA)

[ 
https://jira.codehaus.org/browse/MNG-5323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308079#comment-308079
 ] 

Gregor B. Rosenauer commented on MNG-5323:
--

I thought maven would already do that if you don't supply the clean option..? 
Shouldn't this be handled by the Plexus container itself, instead of 
controlling the build process from the plugin? Seems like the tail wagging the 
dog to me...

 Add ability to interrupt a build with SUCCESS status from maven plugins.
 

 Key: MNG-5323
 URL: https://jira.codehaus.org/browse/MNG-5323
 Project: Maven 2  3
  Issue Type: Improvement
  Components: General, Plugin API
Affects Versions: 3.0.5
 Environment: any
Reporter: Stanislav Tyurikov
Priority: Critical
 Attachments: build_succeed_exception.patch


 Add ability to successfully finish a build from maven plugin. It can help to 
 create maven plugins for build optimization. Currently we can interrupt a 
 build only to fail it (by throwing an exception from the execute method of a 
 mojo).
 This functionality can be easily implemented by adding BuildSuccessException 
 to the maven core and modifying LifecycleModuleBuilder and 
 DefaultBuildPluginManager to process this exception and finish the build as 
 succeed. Any custom maven plugin can throw BuildSuccessException to indicate 
 the build is OK and no further steps are needed to be executed.

--
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-5345) command line option to get status of last build

2012-09-10 Thread Gregor B. Rosenauer (JIRA)
Gregor B. Rosenauer created MNG-5345:


 Summary: command line option to get status of last build
 Key: MNG-5345
 URL: https://jira.codehaus.org/browse/MNG-5345
 Project: Maven 2  3
  Issue Type: Improvement
  Components: Command Line, Reactor and workspace
Affects Versions: 3.0.4
 Environment: Linux 3.2.0-30-generic #48-Ubuntu SMP Fri Aug 24 16:52:48 
UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Gregor B. Rosenauer
Priority: Minor


I would find it very useful to be able to quickly get the status of my last 
build (without having to dig out the log or look at the date of generated 
artifacts).

Something like mvn status that immediately gives me a quick glance at the 
project's health in my local workspace, as I don't want to and cannot rely on a 
CI server for this.

--
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-5323) Add ability to interrupt a build with SUCCESS status from maven plugins.

2012-09-10 Thread Stanislav Tyurikov (JIRA)

[ 
https://jira.codehaus.org/browse/MNG-5323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308082#comment-308082
 ] 

Stanislav Tyurikov commented on MNG-5323:
-

Gregor, thank you for reply.

 I thought maven would already do that if you don't supply the clean 
 option..?
If you have A.java and B.java on the first build, then you delete A.java and 
run the second build without clean, A.class and B.class will be exist in 
result jar. A.class wouldn't be deleted because of no clean was performed. 
This is wrong. Only B.class must exist.

 Shouldn't this be handled by the Plexus container itself, instead of 
 controlling the build process from the plugin? 
May be... but isn't it looks as complete API to have ways to finish build with 
different results? I can interrupt a build from a my plugin to mark it as 
failed, why can't I do this to say build is ok?


 Add ability to interrupt a build with SUCCESS status from maven plugins.
 

 Key: MNG-5323
 URL: https://jira.codehaus.org/browse/MNG-5323
 Project: Maven 2  3
  Issue Type: Improvement
  Components: General, Plugin API
Affects Versions: 3.0.5
 Environment: any
Reporter: Stanislav Tyurikov
Priority: Critical
 Attachments: build_succeed_exception.patch


 Add ability to successfully finish a build from maven plugin. It can help to 
 create maven plugins for build optimization. Currently we can interrupt a 
 build only to fail it (by throwing an exception from the execute method of a 
 mojo).
 This functionality can be easily implemented by adding BuildSuccessException 
 to the maven core and modifying LifecycleModuleBuilder and 
 DefaultBuildPluginManager to process this exception and finish the build as 
 succeed. Any custom maven plugin can throw BuildSuccessException to indicate 
 the build is OK and no further steps are needed to be executed.

--
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] (MECLIPSE-731) eclipse:clean not deleting ./settings folder that it creates

2012-09-10 Thread Olivier Lamy (JIRA)

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

Olivier Lamy closed MECLIPSE-731.
-

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

fixed r1382816

 eclipse:clean not deleting ./settings folder that it creates
 

 Key: MECLIPSE-731
 URL: https://jira.codehaus.org/browse/MECLIPSE-731
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Bug
Affects Versions: 2.9
 Environment: Maven 3.0.3 maven-eclipse-plugin 2.9
Reporter: Glen Mazza
Assignee: Olivier Lamy
 Fix For: 2.10


 Hi, I use mvn eclipse:eclipse to create Eclipse projects that I subsequently 
 import into my IDE.  I then make code changes, and run mvn eclipse:clean 
 prior to uploading my changes to GitHub.
 Problem is that eclipse:clean is not deleting the ./settings folder, giving 
 me this list of files that I have to manually delete before I can do a simple 
 git add . prior to committing:
 gmazza@ubuntu:/media/work1/jersey-samples-on-cxf$ git status
 # On branch master
 # Untracked files:
 #   (use git add file... to include in what will be committed)
 #
 # entity-provider/.settings/
 # exceptions/.settings/
 # helloworld-webapp/.settings/
 # helloworld/.settings/
 # https-server-glassfish/.settings/
 # jacksonjsonprovider/.settings/
 # json-from-jaxb/.settings/
 # jsonp/.settings/
 # simple-console/.settings/
 # simple-servlet/.settings/
 The Linux command I otherwise have to run to delete all these settings 
 folders: find . -name '.settings' -type d | xargs rm -rf {} \; is quite 
 complex and outside the capabilities of many/most Linux users (like me, I got 
 the above command from Olivier Lamy).
 mvn eclipse:help says it's already supposed to delete the .settings folder:
 Maven Eclipse Plugin 2.9
   The Eclipse Plugin is used to generate Eclipse IDE files (.project, 
 .classpath
   and the .settings folder) from a POM.
 This plugin has 13 goals:
 ... 
 eclipse:clean
   Deletes the .project, .classpath, .wtpmodules files and .settings folder 
 used
   by Eclipse.
 ...
 Apparently the deletion of the .settings folder was made to please the people 
 who posted http://jira.codehaus.org/browse/MECLIPSE-71 -- I would say theirs 
 is minority use case (~10-15%?) though of just wanting mvn eclipse:clean to 
 delete just some but not all of the artifacts that mvn eclipse:eclipse 
 created; therefore some plugin configuration setting like 
 keepSettingsFoldertrue/keepSettingsFolder should be created with a 
 default value of false to not require this explicit configuration for the 
 most common use-case; however if backwards compatibility is a concern the 
 default value for this setting can be set to true.  Regardless, eclipse:help 
 should be updated to inform people to put in this setting to exclude/include 
 deletion of the .settings folder.  Thanks!

--
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] (MEAR-155) Building multiple EARs containing different modules with classifiers doesn't work with skinnyWars set to true

2012-09-10 Thread Roland Asmann (JIRA)

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

Roland Asmann updated MEAR-155:
---

Attachment: MEAR-155.zip

A simple project that shows the problem.

When the parameter 'skinnyWars' in the EAR-project is set to 'false'. the 
generated EAR is correct.

 Building multiple EARs containing different modules with classifiers doesn't 
 work with skinnyWars set to true
 -

 Key: MEAR-155
 URL: https://jira.codehaus.org/browse/MEAR-155
 Project: Maven 2.x Ear Plugin
  Issue Type: Bug
Reporter: Roland Asmann
 Attachments: MEAR-155.zip


 I have a multi-module project with following structure:
 root
  |- content
  |- WAR
  \- EAR
 In which all modules (except root) generate 2 artifacts: a 'normal' artifact 
 (no classifier), that gets deployed on the server and a 'dev' artifact 
 (classifier=dev), that is used for local development.
 This has worked fine until the skinnyWar was set to true:
 The EAR-plugin now extracts the normal WAR into a temp-dir and repackages it. 
 Then it creates the EAR -- this version is alright.
 When it wants to package the 'dev'-version, it extract the WAR into the SAME 
 directory as the previous WAR, repackages it and creates the EAR.
 The problem here, is that the 'dev'-EAR now contains a 'dev'-WAR that has 
 mixed libraries inside -- both the 'normal' and 'dev' content-JAR!
 Wouldn't it be better to either delete the temp-dir after creating the first 
 EAR or unpacking the module into a different temp-dir (eg including the 
 classifier in the name)?

--
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-375) dependency:tree fails with NPE if executed twice

2012-09-10 Thread Taciano Tres (JIRA)
Taciano Tres created MDEP-375:
-

 Summary: dependency:tree fails with NPE if executed twice
 Key: MDEP-375
 URL: https://jira.codehaus.org/browse/MDEP-375
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
  Components: tree
Affects Versions: 2.5.1, 2.5
 Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 16:16:01-0300)
Java version: 1.7.0_05
Java home: /usr/lib/jvm/jdk1.7.0_05/jre
Default locale: pt_BR, platform encoding: UTF-8
OS name: linux version: 2.6.32-41-generic arch: amd64 Family: unix
Reporter: Taciano Tres


Plugin fails to generate the dependency tree when executed twice, the second 
one for Cobertura life cycle:
{quote}
$ mvn --batch-mode --update-snapshots --errors clean install 
dependency:analyze-only cobertura:cobertura
(...)
[INFO] [dependency:tree {execution: gerar-dependency-tree}]
[INFO] Wrote dependency tree to: 
/target/classes/META-INF/bom/dependency-tree.txt
(...)
[INFO] Preparing cobertura:cobertura
(...)
[INFO] [dependency:tree {execution: gerar-dependency-tree}]
[INFO] 
[ERROR] FATAL ERROR
[INFO] 
[INFO] null
[INFO] 
[INFO] Trace
java.lang.NullPointerException
at 
org.apache.maven.shared.dependency.tree.DefaultDependencyTreeBuilder.buildDependencyTree(DefaultDependencyTreeBuilder.java:139)
at 
org.apache.maven.shared.dependency.graph.internal.Maven2DependencyGraphBuilder.buildDependencyGraph(Maven2DependencyGraphBuilder.java:55)
at 
org.apache.maven.shared.dependency.graph.internal.DefaultDependencyGraphBuilder.buildDependencyGraph(DefaultDependencyGraphBuilder.java:63)
at 
org.apache.maven.plugin.dependency.TreeMojo.execute(TreeMojo.java:202)
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.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1205)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1038)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:643)
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:348)
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:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
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] 
[INFO] Total time: 11 seconds
[INFO] Finished at: Mon Sep 10 11:02:34 BRT 2012
[INFO] Final Memory: 69M/379M
[INFO] 
{quote}

The plugin is defined in {{pom.xml}} as:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
version2.5/version
executions
execution
idgerar-dependency-tree/id
phaseinitialize/phase
goals
goaltree/goal

[jira] (MDEP-366) NPE when running site

2012-09-10 Thread Peter Janes (JIRA)

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

Peter Janes updated MDEP-366:
-

Attachment: mdep-366-it.patch

Here's an IT that triggers the bug (for some reason the project variable is 
null in AnalyzeReportMojo.java).

 NPE when running site
 -

 Key: MDEP-366
 URL: https://jira.codehaus.org/browse/MDEP-366
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
Affects Versions: 2.5
Reporter: Paul Nyheim
Priority: Blocker
 Attachments: mdep-366-it.patch


 I have configured the {{analyze-report}} report in my reporting section of 
 pom.xml
 {code:xml}
 reporting
   plugins
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-dependency-plugin/artifactId
 version2.5/version
 reportSets
 reportSet
 reports
 reportanalyze-report/report
 /reports
 /reportSet
 /reportSets
 /plugin
   /plugins
 /reporting
 {code}
 And when I try to run {{mvn site}}, I get this NPE:
 {noformat}
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on project 
 : Execution default-site of goal 
 org.apache.maven.plugins:maven-site-plugin:3.1:site failed. 
 NullPointerException - [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on 
 project : Execution default-site of goal 
 org.apache.maven.plugins:maven-site-plugin:3.1:site failed.
   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: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.PluginExecutionException: Execution 
 default-site of goal org.apache.maven.plugins:maven-site-plugin:3.1:site 
 failed.
   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.NullPointerException
   at 
 org.apache.maven.plugin.dependency.AnalyzeReportMojo.executeReport(AnalyzeReportMojo.java:100)
   at 
 org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:135)
   at 
 org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:228)
   at 
 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
   at 
 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
   at 
 org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
   at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
   at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
   ... 20 more
 {noformat}

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

[jira] (MDEP-366) NPE when running site

2012-09-10 Thread Peter Janes (JIRA)

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

Peter Janes updated MDEP-366:
-

Attachment: mdep-366.patch

Looks like the project variable was set as a Parameter in 
AnalyzeReportMojo.java instead of a Component (as in the others) when the 
plugin was migrated to annotations.  This should fix it, and updates the IT 
with a basic verify script.

 NPE when running site
 -

 Key: MDEP-366
 URL: https://jira.codehaus.org/browse/MDEP-366
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
Affects Versions: 2.5
Reporter: Paul Nyheim
Priority: Blocker
 Attachments: mdep-366-it.patch, mdep-366.patch


 I have configured the {{analyze-report}} report in my reporting section of 
 pom.xml
 {code:xml}
 reporting
   plugins
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-dependency-plugin/artifactId
 version2.5/version
 reportSets
 reportSet
 reports
 reportanalyze-report/report
 /reports
 /reportSet
 /reportSets
 /plugin
   /plugins
 /reporting
 {code}
 And when I try to run {{mvn site}}, I get this NPE:
 {noformat}
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on project 
 : Execution default-site of goal 
 org.apache.maven.plugins:maven-site-plugin:3.1:site failed. 
 NullPointerException - [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on 
 project : Execution default-site of goal 
 org.apache.maven.plugins:maven-site-plugin:3.1:site failed.
   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: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.PluginExecutionException: Execution 
 default-site of goal org.apache.maven.plugins:maven-site-plugin:3.1:site 
 failed.
   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.NullPointerException
   at 
 org.apache.maven.plugin.dependency.AnalyzeReportMojo.executeReport(AnalyzeReportMojo.java:100)
   at 
 org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:135)
   at 
 org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:228)
   at 
 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
   at 
 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
   at 
 org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
   at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
   at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
   ... 20 more
 {noformat}

--

[jira] (MECLIPSE-731) eclipse:clean not deleting ./settings folder that it creates

2012-09-10 Thread Dan Tran (JIRA)

[ 
https://jira.codehaus.org/browse/MECLIPSE-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308110#comment-308110
 ] 

Dan Tran commented on MECLIPSE-731:
---

now we need a release :-)

 eclipse:clean not deleting ./settings folder that it creates
 

 Key: MECLIPSE-731
 URL: https://jira.codehaus.org/browse/MECLIPSE-731
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Bug
Affects Versions: 2.9
 Environment: Maven 3.0.3 maven-eclipse-plugin 2.9
Reporter: Glen Mazza
Assignee: Olivier Lamy
 Fix For: 2.10


 Hi, I use mvn eclipse:eclipse to create Eclipse projects that I subsequently 
 import into my IDE.  I then make code changes, and run mvn eclipse:clean 
 prior to uploading my changes to GitHub.
 Problem is that eclipse:clean is not deleting the ./settings folder, giving 
 me this list of files that I have to manually delete before I can do a simple 
 git add . prior to committing:
 gmazza@ubuntu:/media/work1/jersey-samples-on-cxf$ git status
 # On branch master
 # Untracked files:
 #   (use git add file... to include in what will be committed)
 #
 # entity-provider/.settings/
 # exceptions/.settings/
 # helloworld-webapp/.settings/
 # helloworld/.settings/
 # https-server-glassfish/.settings/
 # jacksonjsonprovider/.settings/
 # json-from-jaxb/.settings/
 # jsonp/.settings/
 # simple-console/.settings/
 # simple-servlet/.settings/
 The Linux command I otherwise have to run to delete all these settings 
 folders: find . -name '.settings' -type d | xargs rm -rf {} \; is quite 
 complex and outside the capabilities of many/most Linux users (like me, I got 
 the above command from Olivier Lamy).
 mvn eclipse:help says it's already supposed to delete the .settings folder:
 Maven Eclipse Plugin 2.9
   The Eclipse Plugin is used to generate Eclipse IDE files (.project, 
 .classpath
   and the .settings folder) from a POM.
 This plugin has 13 goals:
 ... 
 eclipse:clean
   Deletes the .project, .classpath, .wtpmodules files and .settings folder 
 used
   by Eclipse.
 ...
 Apparently the deletion of the .settings folder was made to please the people 
 who posted http://jira.codehaus.org/browse/MECLIPSE-71 -- I would say theirs 
 is minority use case (~10-15%?) though of just wanting mvn eclipse:clean to 
 delete just some but not all of the artifacts that mvn eclipse:eclipse 
 created; therefore some plugin configuration setting like 
 keepSettingsFoldertrue/keepSettingsFolder should be created with a 
 default value of false to not require this explicit configuration for the 
 most common use-case; however if backwards compatibility is a concern the 
 default value for this setting can be set to true.  Regardless, eclipse:help 
 should be updated to inform people to put in this setting to exclude/include 
 deletion of the .settings folder.  Thanks!

--
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] (MWAR-259) need to update dependency of maven-archiver to 2.5

2012-09-10 Thread Ludwig Magnusson (JIRA)

[ 
https://jira.codehaus.org/browse/MWAR-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308117#comment-308117
 ] 

Ludwig Magnusson commented on MWAR-259:
---

Isn't this solved?

 need to update dependency of maven-archiver to 2.5
 --

 Key: MWAR-259
 URL: https://jira.codehaus.org/browse/MWAR-259
 Project: Maven 2.x WAR Plugin
  Issue Type: Bug
Affects Versions: 2.1.1
Reporter: Peter B.

 due to: http://jira.codehaus.org/browse/MSHARED-131
 there is a need up update dependencies to maven-archiver-2.5
 otherwise incorrect META-INF/MANIFEST.MF files are generated

--
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] (DOXIA-478) snippet macro fails if online: add a parameter to skip network error.

2012-09-10 Thread Olivier Lamy (JIRA)
Olivier Lamy created DOXIA-478:
--

 Summary: snippet macro fails if online: add a parameter to skip 
network error.
 Key: DOXIA-478
 URL: https://jira.codehaus.org/browse/DOXIA-478
 Project: Maven Doxia
  Issue Type: Bug
  Components: Core
Affects Versions: 1.3
Reporter: Olivier Lamy




--
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] (DOXIA-478) snippet macro fails if online: add a parameter to skip network error.

2012-09-10 Thread Olivier Lamy (JIRA)

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

Olivier Lamy closed DOXIA-478.
--

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

fixed r1382987.

 snippet macro fails if online: add a parameter to skip network error.
 -

 Key: DOXIA-478
 URL: https://jira.codehaus.org/browse/DOXIA-478
 Project: Maven Doxia
  Issue Type: Bug
  Components: Core
Affects Versions: 1.3
Reporter: Olivier Lamy
Assignee: Olivier Lamy
 Fix For: 1.4




--
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] (DOXIATOOLS-40) Eclipse Doxia Edit update site nolonger available

2012-09-10 Thread Dan Tran (JIRA)
Dan Tran created DOXIATOOLS-40:
--

 Summary: Eclipse Doxia Edit update site nolonger available
 Key: DOXIATOOLS-40
 URL: https://jira.codehaus.org/browse/DOXIATOOLS-40
 Project: Maven Doxia Tools
  Issue Type: Bug
  Components: Doxia Eclipse Editor
Reporter: Dan Tran
Priority: Blocker


The eclipse update site link at 
http://maven.apache.org/doxia/doxia-ide/eclipse/ to pickup update site is 
nolonger available

--
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] (DOXIATOOLS-40) Eclipse Doxia Edit update site nolonger available

2012-09-10 Thread Dan Tran (JIRA)

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

Dan Tran updated DOXIATOOLS-40:
---

Issue Type: Task  (was: Bug)

 Eclipse Doxia Edit update site nolonger available
 -

 Key: DOXIATOOLS-40
 URL: https://jira.codehaus.org/browse/DOXIATOOLS-40
 Project: Maven Doxia Tools
  Issue Type: Task
  Components: Doxia Eclipse Editor
Reporter: Dan Tran
Priority: Blocker

 The eclipse update site link at 
 http://maven.apache.org/doxia/doxia-ide/eclipse/ to pickup update site is 
 nolonger available

--
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] (MCHANGES-285) SAXException parsing JIRA XML from JIRA 5.1

2012-09-10 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg closed MCHANGES-285.


   Resolution: Fixed
Fix Version/s: 2.8

 SAXException parsing JIRA XML from JIRA 5.1 
 

 Key: MCHANGES-285
 URL: https://jira.codehaus.org/browse/MCHANGES-285
 Project: Maven 2.x Changes Plugin
  Issue Type: Bug
  Components: jira
Affects Versions: 2.7.1
 Environment: osx rhel sun java 1.6.0_30
Reporter: Micah Whitacre
Assignee: Dennis Lundberg
 Fix For: 2.8

 Attachments: patch-2.7.x.txt, patch.txt


 When trying to generate a changes report from a JIRA instance running 5.1[1] 
 I get the following exception 
 [INFO] Generating JIRA Report report--- maven-changes-plugin:2.7.1
 Jul 16, 2012 5:32:53 PM org.apache.commons.httpclient.HttpMethodBase 
 getResponseBody
 WARNING: Going to buffer response body of large or unknown size. Using 
 getResponseBodyAsStream instead is recommended.
 [INFO] Downloading from JIRA at: 
 http://bugs.cloud.cerner.corp/secure/IssueNavigator.jspa?view=rsspid=10670component=kepler-clientcomponent=kepler-parentstatus=Verifiedstatus=Closedresolution=1resolution=12tempMax=100reset=truedecorator=none
 [WARNING] 
 org.apache.maven.plugin.MojoExecutionException: Failed to parse JIRA XML.
   at org.apache.maven.plugin.jira.JiraXML.parse(JiraXML.java:132)
   at org.apache.maven.plugin.jira.JiraXML.parseXML(JiraXML.java:108)
   at 
 org.apache.maven.plugin.jira.AbstractJiraDownloader.getIssueList(AbstractJiraDownloader.java:755)
   at 
 org.apache.maven.plugin.jira.JiraMojo.executeReport(JiraMojo.java:347)
   at 
 org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
   at 
 org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:219)
   at 
 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:317)
   at 
 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:134)
   at 
 org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
   at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
   at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
   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.xml.sax.SAXParseException: The entity name must immediately 
 follow the '' in the entity reference.
   at 
 org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown 
 Source)
   at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source)
   at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
   at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
   at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
   at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown Source)
   at org.apache.xerces.impl.XMLScanner.scanAttributeValue(Unknown Source)
   at 
 

[jira] (MCHANGES-267) Add ability to skip JIRA report creation

2012-09-10 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg closed MCHANGES-267.


   Resolution: Fixed
Fix Version/s: 2.8
 Assignee: Dennis Lundberg

Patch applied in 
[r1382996|http://svn.apache.org/viewvc?view=revisionrevision=1382996] with 
some modifications. The plugin has moved to using annotations for mojo 
parameters, so I adjusted the patch accordingly.

Thank you for the patch!

 Add ability to skip JIRA report creation
 

 Key: MCHANGES-267
 URL: https://jira.codehaus.org/browse/MCHANGES-267
 Project: Maven 2.x Changes Plugin
  Issue Type: Improvement
  Components: jira
Affects Versions: 2.6
Reporter: Joshua Hyde
Assignee: Dennis Lundberg
Priority: Minor
 Fix For: 2.8

 Attachments: skip-jira.patch, skip-jira-username.patch


 We use the JIRA report in a reactor build, using Maven's reporting plugin 
 inheritance to have child projects generate their own reports. However, some 
 of the projects - such as the reactor build POMs themselves - have no real 
 relevant JIRA components to be used in the report (they're just build 
 aggregates). Right now, we just short-circuit the report in those cases by 
 providing it a phony component ID, but it'd be nice if we could just skip it 
 altogether, since our current approach still generates a JIRA report, but 
 with an error message.
 I've attached a patch with the proposed changes.

--
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] (MCHANGES-279) ability to skip for Jira is offlince

2012-09-10 Thread Dennis Lundberg (JIRA)

[ 
https://jira.codehaus.org/browse/MCHANGES-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308128#comment-308128
 ] 

Dennis Lundberg commented on MCHANGES-279:
--

Does the solution in MCHANGES-267 solve this issue as well?

 ability to skip for Jira is offlince
 

 Key: MCHANGES-279
 URL: https://jira.codehaus.org/browse/MCHANGES-279
 Project: Maven 2.x Changes Plugin
  Issue Type: Improvement
  Components: jira
Affects Versions: 2.6
 Environment: {code}
 $ mvn -v
 Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
 Maven home: /usr/share/maven
 Java version: 1.6.0_29, vendor: Apple Inc.
 Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
 Default locale: en_US, platform encoding: MacRoman
 OS name: mac os x, version: 10.6.8, arch: x86_64, family: mac
 {code}
Reporter: cosmo
 Attachments: 
 MCHANGES-279_skip_network_operations_during_--offline_mode_.patch


 maven-changes-plugin is great and compiles a nice Jira report.
 We need an ability to skip the Jira report compilation. Jira instance may not 
 always be available when on different network or completely disconnected from 
 Jira.
 {code:xml}
 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-changes-plugin/artifactId
   version2.6/version
   configuration
   skiptrueskip
 ...
   /configuration
 /plugin 
 {code}
 Skip flag above can then be parameterized.
 I'm not sure if the plugin can be sensitive to --offline flag instead of 
 skip flag.
 When Jira is unavailable, current behavior just times out during the build. 
 But build takes forever to complete waiting for times outs and retries.

--
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] (MWAR-259) need to update dependency of maven-archiver to 2.5

2012-09-10 Thread Olivier Lamy (JIRA)

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

Olivier Lamy closed MWAR-259.
-

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

already solved.
version is 2.5 in trunk.

 need to update dependency of maven-archiver to 2.5
 --

 Key: MWAR-259
 URL: https://jira.codehaus.org/browse/MWAR-259
 Project: Maven 2.x WAR Plugin
  Issue Type: Bug
Affects Versions: 2.1.1
Reporter: Peter B.
Assignee: Olivier Lamy
 Fix For: 2.3


 due to: http://jira.codehaus.org/browse/MSHARED-131
 there is a need up update dependencies to maven-archiver-2.5
 otherwise incorrect META-INF/MANIFEST.MF files are generated

--
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-5336) Descriptor Reference for settings.xml is incorrect

2012-09-10 Thread Olivier Lamy (JIRA)

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

Olivier Lamy updated MNG-5336:
--

Fix Version/s: 3.0.5

fixed in modello.
We only need a release.
Perso even if I have karma for modello git I don't have karma to deploy modello 
artifacts to codehaus repo. 
The fun of infrastructure with non unified authz ...

 Descriptor Reference for settings.xml is incorrect
 --

 Key: MNG-5336
 URL: https://jira.codehaus.org/browse/MNG-5336
 Project: Maven 2  3
  Issue Type: Bug
  Components: Settings
Affects Versions: 3.0.4
Reporter: Jan Hänsli
 Fix For: 3.0.5


 The example settings.xml found here 
 (http://maven.apache.org/ref/3.0.4/maven-settings/settings.html) is not valid!
 65: properties
 66:   keyvalue/key
 67: properties/
 bad line 67:  properties/
 correct line 67:  /properties
 Steps to reproduce:
 - Copy  Paste the document into your IDE or XML editor.
 - Start the xml validator and try to validate the document against 
 http://maven.apache.org/xsd/settings-1.1.0.xsd

--
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] (MRAR-29) Make ra.xml optional - 1.6 spec

2012-09-10 Thread Olivier Lamy (JIRA)

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

Olivier Lamy reassigned MRAR-29:


Assignee: Olivier Lamy

 Make ra.xml optional - 1.6 spec
 ---

 Key: MRAR-29
 URL: https://jira.codehaus.org/browse/MRAR-29
 Project: Maven 2.x Rar Plugin
  Issue Type: New Feature
Affects Versions: 2.3
Reporter: Kresimir Kovac
Assignee: Olivier Lamy
 Attachments: maven-rar-plugin.patch


 According to Java EE Connector Architecture Specification 1.6 Deployment 
 Descriptor is not Optional.
 Most of the Resource Adapter can be configured using only annotations.
 maven-rar-plugin should not enforce mandatory ra.xml deployment descriptor 
 any more or it should 
 include new parameter 'jca-version' and behave accordingly.

--
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] (MRAR-32) Pass MavenSession to createArchive

2012-09-10 Thread Olivier Lamy (JIRA)

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

Olivier Lamy reassigned MRAR-32:


Assignee: Olivier Lamy

 Pass MavenSession to createArchive
 --

 Key: MRAR-32
 URL: https://jira.codehaus.org/browse/MRAR-32
 Project: Maven 2.x Rar Plugin
  Issue Type: Improvement
Affects Versions: 2.2
Reporter: Philippe Marschall
Assignee: Olivier Lamy
Priority: Minor
 Attachments: maven-rar-plugin-maven-session.patch


 The {{RarMojo}} uses the deprecated {{createArchive}} method without passing 
 the {{MavenSession}}. Attached is a simple one line patch to fix it. As far 
 as I can tell the difference is that the Maven version will end up in the 
 manifest.

--
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] (MRAR-32) Pass MavenSession to createArchive

2012-09-10 Thread Olivier Lamy (JIRA)

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

Olivier Lamy closed MRAR-32.


   Resolution: Fixed
Fix Version/s: 2.3

 Pass MavenSession to createArchive
 --

 Key: MRAR-32
 URL: https://jira.codehaus.org/browse/MRAR-32
 Project: Maven 2.x Rar Plugin
  Issue Type: Improvement
Affects Versions: 2.2
Reporter: Philippe Marschall
Assignee: Olivier Lamy
Priority: Minor
 Fix For: 2.3

 Attachments: maven-rar-plugin-maven-session.patch


 The {{RarMojo}} uses the deprecated {{createArchive}} method without passing 
 the {{MavenSession}}. Attached is a simple one line patch to fix it. As far 
 as I can tell the difference is that the Maven version will end up in the 
 manifest.

--
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] (MRAR-29) Make ra.xml optional - 1.6 spec

2012-09-10 Thread Olivier Lamy (JIRA)

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

Olivier Lamy closed MRAR-29.


   Resolution: Fixed
Fix Version/s: 2.3

 Make ra.xml optional - 1.6 spec
 ---

 Key: MRAR-29
 URL: https://jira.codehaus.org/browse/MRAR-29
 Project: Maven 2.x Rar Plugin
  Issue Type: New Feature
Affects Versions: 2.3
Reporter: Kresimir Kovac
Assignee: Olivier Lamy
 Fix For: 2.3

 Attachments: maven-rar-plugin.patch


 According to Java EE Connector Architecture Specification 1.6 Deployment 
 Descriptor is not Optional.
 Most of the Resource Adapter can be configured using only annotations.
 maven-rar-plugin should not enforce mandatory ra.xml deployment descriptor 
 any more or it should 
 include new parameter 'jca-version' and behave accordingly.

--
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] (MWAR-286) Please make test-jar also run for war packages

2012-09-10 Thread Robert Scholte (JIRA)

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

Robert Scholte moved MJAR-160 to MWAR-286:
--

Affects Version/s: (was: 2.4)
   2.2
  Key: MWAR-286  (was: MJAR-160)
  Project: Maven 2.x WAR Plugin  (was: Maven 2.x JAR Plugin)

 Please make test-jar also run for war packages
 

 Key: MWAR-286
 URL: https://jira.codehaus.org/browse/MWAR-286
 Project: Maven 2.x WAR Plugin
  Issue Type: Wish
Affects Versions: 2.2
Reporter: Marco rietveld
Priority: Minor

 If you configure the jar plugin to also run the test-jar goal, it will only 
 run that if the package type in the pom of the project is jar. 
 However, in the case of wars it's would also be handy to be able to make the 
 test-jars (by simply changing the configuration in one mother pom). 
 We realize that this is an edge-case. However, we (drools/jbpm) work with a 
 project that has _lots_ or submodules including a couple war submodules. 
 Being able to simply have all war submodules generate test-jars without 
 having to modify each individual war submodule's pom.xml would be nice. 
 Thanks!

--
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] (MWAR-286) Please make test-jar also run for war packages

2012-09-10 Thread Robert Scholte (JIRA)

[ 
https://jira.codehaus.org/browse/MWAR-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308142#comment-308142
 ] 

Robert Scholte commented on MWAR-286:
-

An equivalent of 
[attachClasses|http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#attachClasses]?

 Please make test-jar also run for war packages
 

 Key: MWAR-286
 URL: https://jira.codehaus.org/browse/MWAR-286
 Project: Maven 2.x WAR Plugin
  Issue Type: Wish
Affects Versions: 2.2
Reporter: Marco rietveld
Priority: Minor

 If you configure the jar plugin to also run the test-jar goal, it will only 
 run that if the package type in the pom of the project is jar. 
 However, in the case of wars it's would also be handy to be able to make the 
 test-jars (by simply changing the configuration in one mother pom). 
 We realize that this is an edge-case. However, we (drools/jbpm) work with a 
 project that has _lots_ or submodules including a couple war submodules. 
 Being able to simply have all war submodules generate test-jars without 
 having to modify each individual war submodule's pom.xml would be nice. 
 Thanks!

--
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] (MINVOKER-138) Add groovy-xml dependency by default

2012-09-10 Thread Robert Scholte (JIRA)
Robert Scholte created MINVOKER-138:
---

 Summary: Add groovy-xml dependency by default
 Key: MINVOKER-138
 URL: https://jira.codehaus.org/browse/MINVOKER-138
 Project: Maven 2.x Invoker Plugin
  Issue Type: Improvement
Affects Versions: 1.7
Reporter: Robert Scholte
Priority: Minor


With the upgrade to groovy-2+ we've lost the XmlSlurper and other xml related 
classes. By adding the groovy-xml dependency by default we shouldn't notice the 
difference between maven-invoker-plugin 1.6 and 1.8

--
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] (MINVOKER-138) Add groovy-xml dependency by default

2012-09-10 Thread Olivier Lamy (JIRA)

[ 
https://jira.codehaus.org/browse/MINVOKER-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308155#comment-308155
 ] 

Olivier Lamy commented on MINVOKER-138:
---

artifactIdgroovy-all/artifactId ?

 Add groovy-xml dependency by default
 

 Key: MINVOKER-138
 URL: https://jira.codehaus.org/browse/MINVOKER-138
 Project: Maven 2.x Invoker Plugin
  Issue Type: Improvement
Affects Versions: 1.7
Reporter: Robert Scholte
Priority: Minor

 With the upgrade to groovy-2+ we've lost the XmlSlurper and other xml related 
 classes. By adding the groovy-xml dependency by default we shouldn't notice 
 the difference between maven-invoker-plugin 1.6 and 1.8

--
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] (MINVOKER-138) Add groovy-all dependency instead of groovy by default

2012-09-10 Thread Robert Scholte (JIRA)

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

Robert Scholte updated MINVOKER-138:


Description: With the upgrade to groovy-2+ we've lost the XmlSlurper and 
other xml related classes. By adding the groovy-all dependency by default we 
also get the classes of groovy-xml so we shouldn't notice the difference 
between maven-invoker-plugin 1.6 and 1.8  (was: With the upgrade to groovy-2+ 
we've lost the XmlSlurper and other xml related classes. By adding the 
groovy-xml dependency by default we shouldn't notice the difference between 
maven-invoker-plugin 1.6 and 1.8)
Summary: Add groovy-all dependency instead of groovy by default  (was: 
Add groovy-xml dependency by default)

 Add groovy-all dependency instead of groovy by default
 --

 Key: MINVOKER-138
 URL: https://jira.codehaus.org/browse/MINVOKER-138
 Project: Maven 2.x Invoker Plugin
  Issue Type: Improvement
Affects Versions: 1.7
Reporter: Robert Scholte
Priority: Minor

 With the upgrade to groovy-2+ we've lost the XmlSlurper and other xml related 
 classes. By adding the groovy-all dependency by default we also get the 
 classes of groovy-xml so we shouldn't notice the difference between 
 maven-invoker-plugin 1.6 and 1.8

--
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] (MINVOKER-138) Add groovy-all dependency instead of groovy by default

2012-09-10 Thread Robert Scholte (JIRA)

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

Robert Scholte closed MINVOKER-138.
---

   Resolution: Fixed
Fix Version/s: 1.8

Fixed in [r1383109|http://svn.apache.org/viewvc?rev=1383109view=rev]

 Add groovy-all dependency instead of groovy by default
 --

 Key: MINVOKER-138
 URL: https://jira.codehaus.org/browse/MINVOKER-138
 Project: Maven 2.x Invoker Plugin
  Issue Type: Improvement
Affects Versions: 1.7
Reporter: Robert Scholte
Priority: Minor
 Fix For: 1.8


 With the upgrade to groovy-2+ we've lost the XmlSlurper and other xml related 
 classes. By adding the groovy-all dependency by default we also get the 
 classes of groovy-xml so we shouldn't notice the difference between 
 maven-invoker-plugin 1.6 and 1.8

--
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] (MPLUGIN-203) upgrade core Maven plugins to use java 5 annotations

2012-09-10 Thread Herve Boutemy (JIRA)

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

Herve Boutemy closed MPLUGIN-203.
-

Resolution: Fixed

 upgrade core Maven plugins to use java 5 annotations
 

 Key: MPLUGIN-203
 URL: https://jira.codehaus.org/browse/MPLUGIN-203
 Project: Maven 2.x Plugin Tools
  Issue Type: Task
Reporter: Herve Boutemy



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