date:20130131


[ 
https://jira.codehaus.org/browse/SUREFIRE-957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318354#comment-318354
 ] 

Andreas Gudian commented on SUREFIRE-957:
-

Could you try the latest 2.14 snapshot? The issue _should_ have been resolved 
with SUREFIRE-943.

 XML report with Junit 4.7 or 4.11 does not include method names
 ---

 Key: SUREFIRE-957
 URL: https://jira.codehaus.org/browse/SUREFIRE-957
 Project: Maven Surefire
  Issue Type: Bug
  Components: Junit 4.x support, xml generation
Affects Versions: 2.13
Reporter: Benson Margulies

 The XML files that result from Junit have a series of testcase/ elements. 
 Each names the class, each is a result of a method in the class, but the 
 method name is not anywhere in the XML.

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

[jira] (SUREFIRE-952) Incompatibility with future release 4.12 of junit (Categories)

[
https://jira.codehaus.org/browse/SUREFIRE-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318356#comment-318356
]

Andreas Gudian commented on SUREFIRE-952:
-

Could you attach a small sample project that demonstrates a) the new Junit
features and b) the described behavior? I changed some coded around that in
2.13 and would like to have a closer look :). Thanks!

Incompatibility with future release 4.12 of junit (Categories)
--

Key: SUREFIRE-952
URL: https://jira.codehaus.org/browse/SUREFIRE-952
Project: Maven Surefire
Issue Type: Bug
Components: Junit 4.x support
Affects Versions: 2.12.2, 2.12.4
Reporter: Henning Gross
Priority: Blocker

Junit is introducing some interesting new features on Categories in 4.12.
@Category will become @Inherited and @ExcludeCategory/@IncludeCategory will
accept a class-array instead of just a single class. As we need these
urgently we are currently testing with the current snapshot of junit
(https://oss.sonatype.org/content/repositories/snapshots/junit/junit/4.12-SNAPSHOT/).
Unfortuneately the version seems to be incompatible.
All tests are executed always. Regardless of the settings in groups or
excludedgroups. Using 4.11 works fine. I do not know why this happens and
therefore cannot provide a patch but I would love to see it fixed. If someone
points me at the cause I will happily find a solution.

--
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-695) tagNameFormat with @{project.version} tags the SNAPSHOT version

2013-01-31 Thread Carlo de Wolf (JIRA)


[ 
https://jira.codehaus.org/browse/MRELEASE-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318358#comment-318358
 ] 

Carlo de Wolf commented on MRELEASE-695:


The variable is already resolved before {{InputVariablesPhase#execute}} gets a 
chance. So essentially the code that inserts {{releaseVersion}} and does an 
extra interpolate is moot.

 tagNameFormat with @{project.version} tags the SNAPSHOT version
 ---

 Key: MRELEASE-695
 URL: https://jira.codehaus.org/browse/MRELEASE-695
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
  Components: prepare
Affects Versions: 2.2
Reporter: Fabrizio Giudici

 The much awaited (by me) MRELEASE-159 seems not to work. I tried a release 
 with the following pom:
 {code:xml}
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-release-plugin/artifactId
 configuration
 localCheckouttrue/localCheckout
 preparationGoalsclean install verify/preparationGoals
 goalsclean install javadoc:javadoc assembly:assembly 
 deploy/goals
 arguments-P${release.profiles} 
 -DaltDeploymentRepository=${altDeploymentRepository}/arguments
 tagNameFormat@{project.version}/tagNameFormat
 /configuration
 /plugin
 {code}
 but I got the tag {{1.0-ALPHA-2-SNAPSHOT}} in place of {{1.0-ALPHA-2}}.

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

[jira] (SUREFIRE-952) Incompatibility with future release 4.12 of junit (Categories)

[
https://jira.codehaus.org/browse/SUREFIRE-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318366#comment-318366
]

Henning Gross commented on SUREFIRE-952:

As I already stated this issue has the wrong title. I got the wrong idea of the
cause of the problem before I found it. I will attach a sample project with
profiles for the issue and also the new junit-feature as requested.

Incompatibility with future release 4.12 of junit (Categories)
--

[jira] (SUREFIRE-952) Incompatibility with future release 4.12 of junit (Categories)

[
https://jira.codehaus.org/browse/SUREFIRE-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318366#comment-318366
]

Henning Gross edited comment on SUREFIRE-952 at 1/31/13 6:32 AM:
-

As I already stated this issue has the wrong title. I got the wrong idea of the
cause of the problem before I found it. I will try to create and attach a
sample project with profiles for the issue and also the new junit-feature as
requested.

was (Author: gaffa):
As I already stated this issue has the wrong title. I got the wrong idea of
the cause of the problem before I found it. I will attach a sample project with
profiles for the issue and also the new junit-feature as requested.

Incompatibility with future release 4.12 of junit (Categories)
--

[jira] (SUREFIRE-952) Incompatibility with future release 4.12 of junit (Categories)

[
https://jira.codehaus.org/browse/SUREFIRE-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318370#comment-318370
]

Henning Gross commented on SUREFIRE-952:

First the feature. Pretty easy. You just run mvn test on the project I
attached. You will see that with 4.12-SNAPSHOT (you need to provide that under
our groupId/artifactId to reproduce the bug. Just install the latest SS from
https://oss.sonatype.org/content/repositories/snapshots/ to your repo with
foo.platform:junit:4.12_24t_1) the test is ran. Its not annotated but inherits
its Category from the abstract test. That is because @Category now is
@inherited.

The bug(s?) is/are not easy to reproduce/nail down. I dont seem to be able to
reproduce the issue we have in our productive project with modules not having a
junit-dep failing to testng or junit4.7 is required in classpath but maybe
you will find it. The reason why I cant do that can be oberserved when you run
mvn -Psf2.3 (which uses surefire 2.3 instead of 2.12.2). It results in a NPE
with the following Stacktrace:

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-test of goal org.apache.maven.plugins:mav
en-surefire-plugin:2.3:test 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.surefire.SurefirePlugin.constructSurefireBooter(SurefirePlugin.java:594)
at
org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:391)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)

Also I noticed that you do not use the Categories-Runner of Junit but instead
copy the behaviour. If that is only because of the fact that excludecategory
and includecategory did not accept more than one group before: this feature
will be introduced in 4.12, too.

Incompatibility with future release 4.12 of junit (Categories)
--

--
This message is automatically generated by JIRA.
If you

[jira] (SUREFIRE-952) Incompatibility with future release 4.12 of junit (Categories)

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

Henning Gross updated SUREFIRE-952:
---

Attachment: surefire-952.zip

Incompatibility with future release 4.12 of junit (Categories)
--

[jira] (MASSEMBLY-643) descriptorSourceDirectory: parameter isn't used

2013-01-31 Thread Arnaud Heritier (JIRA)

Arnaud Heritier created MASSEMBLY-643:
-

 Summary: descriptorSourceDirectory: parameter isn't used
 Key: MASSEMBLY-643
 URL: https://jira.codehaus.org/browse/MASSEMBLY-643
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.4
Reporter: Arnaud Heritier


I configure the plugin with something like this :
{code}
  plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-assembly-plugin/artifactId
configuration
  descriptors

descriptorplf-standalone-enterprise-tomcat-distribution-content.xml/descriptor
  /descriptors
descriptorSourceDirectorysrc/main/assemblies/descriptorSourceDirectory
/configuration
  /plugin
{code}
But it doesn't find the descriptor (using its filename or its ID)
{code}
[DEBUG] Configuring mojo 
'org.apache.maven.plugins:maven-assembly-plugin:2.4:single' with basic 
configurator --

[DEBUG]   (s) descriptorSourceDirectory = 
/Users/arnaud/Code/eXo/platform-distributions/plf-enterprise-tomcat-standalone/src/main/assemblies
[DEBUG]   (s) descriptors = 
[plf-standalone-enterprise-tomcat-distribution-content.xml]

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-assembly-plugin:2.4:single 
(plf-standalone-tomcat-distribution-content) on project 
plf-enterprise-tomcat-standalone: Error reading assemblies: Error locating 
assembly descriptor: plf-standalone-enterprise-tomcat-distribution-content.xml
[ERROR] 
[ERROR] [1] [INFO] Searching for file location: 
/Users/arnaud/Code/eXo/platform-distributions/plf-enterprise-tomcat-standalone/plf-standalone-enterprise-tomcat-distribution-content.xml
[ERROR] 
[ERROR] [2] [INFO] File: 
/Users/arnaud/Code/eXo/platform-distributions/plf-enterprise-tomcat-standalone/plf-standalone-enterprise-tomcat-distribution-content.xml
 does not exist.
[ERROR] 
[ERROR] [3] [INFO] File: 
/Users/arnaud/Code/eXo/platform-distributions/plf-enterprise-tomcat-standalone/plf-standalone-enterprise-tomcat-distribution-content.xml
 does not exist.
{code}
I simplified the config (I'll need to create an it) in my case i was using a 
2nd assembly coming from the classpath


--
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] (MCHECKSTYLE-186) FileTabCharacter check not working

2013-01-31 Thread Dipti Desai (JIRA)

Dipti Desai created MCHECKSTYLE-186:
---

 Summary: FileTabCharacter check not working
 Key: MCHECKSTYLE-186
 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-186
 Project: Maven 2.x Checkstyle Plugin
  Issue Type: Bug
Reporter: Dipti Desai
Priority: Minor


The FileTabCharacter check doesnt seem to work. Below is my config:

module name=Checker
..
..
!-- No TAB characters in the source code --
module name=FileTabCharacter
property name=eachLine value=true /
property name=fileExtensions value=java,xml /
/module
..
..
module name=TreeWalker
..
..
/module
/module

I have my xml files - pom.xml and checkstyle config xml containing tabs but 
none of them are flagged as violations.

Some additional info - my plugin config looks like this:

plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-checkstyle-plugin/artifactId
version2.9.1/version
executions
execution
phaseverify/phase
goals
goalcheck/goal
/goals
/execution
/executions
configuration

configLocationcheckstyle/kepler-checkstyle-config.xml/configLocation

suppressionsLocation${project.parent.basedir}${file.separator}checkstyle/kepler-checkstyle-suppressions.xml/suppressionsLocation
/configuration
/plugin

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

[jira] (MASSEMBLY-643) descriptorSourceDirectory: parameter isn't used

2013-01-31 Thread Arnaud Heritier (JIRA)


[ 
https://jira.codehaus.org/browse/MASSEMBLY-643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318374#comment-318374
 ] 

Arnaud Heritier commented on MASSEMBLY-643:
---

A workaround is to use this config
{code}
  descriptors

descriptorsrc/main/assemblies/plf-standalone-enterprise-tomcat-distribution-content.xml/descriptor
  /descriptors
{code}

 descriptorSourceDirectory: parameter isn't used
 ---

 Key: MASSEMBLY-643
 URL: https://jira.codehaus.org/browse/MASSEMBLY-643
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.4
Reporter: Arnaud Heritier

 I configure the plugin with something like this :
 {code}
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-assembly-plugin/artifactId
 configuration
   descriptors
 
 descriptorplf-standalone-enterprise-tomcat-distribution-content.xml/descriptor
   /descriptors
 descriptorSourceDirectorysrc/main/assemblies/descriptorSourceDirectory
 /configuration
   /plugin
 {code}
 But it doesn't find the descriptor (using its filename or its ID)
 {code}
 [DEBUG] Configuring mojo 
 'org.apache.maven.plugins:maven-assembly-plugin:2.4:single' with basic 
 configurator --
 
 [DEBUG]   (s) descriptorSourceDirectory = 
 /Users/arnaud/Code/eXo/platform-distributions/plf-enterprise-tomcat-standalone/src/main/assemblies
 [DEBUG]   (s) descriptors = 
 [plf-standalone-enterprise-tomcat-distribution-content.xml]
 
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-assembly-plugin:2.4:single 
 (plf-standalone-tomcat-distribution-content) on project 
 plf-enterprise-tomcat-standalone: Error reading assemblies: Error locating 
 assembly descriptor: plf-standalone-enterprise-tomcat-distribution-content.xml
 [ERROR] 
 [ERROR] [1] [INFO] Searching for file location: 
 /Users/arnaud/Code/eXo/platform-distributions/plf-enterprise-tomcat-standalone/plf-standalone-enterprise-tomcat-distribution-content.xml
 [ERROR] 
 [ERROR] [2] [INFO] File: 
 /Users/arnaud/Code/eXo/platform-distributions/plf-enterprise-tomcat-standalone/plf-standalone-enterprise-tomcat-distribution-content.xml
  does not exist.
 [ERROR] 
 [ERROR] [3] [INFO] File: 
 /Users/arnaud/Code/eXo/platform-distributions/plf-enterprise-tomcat-standalone/plf-standalone-enterprise-tomcat-distribution-content.xml
  does not exist.
 {code}
 I simplified the config (I'll need to create an it) in my case i was using a 
 2nd assembly coming from the classpath

--
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] (MINSTALL-94) Optional: limit install to packaging x and or make install plugin not fail if no artifacts were created for some modules.

Henning Gross created MINSTALL-94:
-

 Summary: Optional: limit install to packaging x and or make 
install plugin not fail if no artifacts were created for some modules.
 Key: MINSTALL-94
 URL: https://jira.codehaus.org/browse/MINSTALL-94
 Project: Maven 2.x Install Plugin
  Issue Type: Improvement
Reporter: Henning Gross


Background: I am working in a huge project with a lot of modules having a lot 
of javascript-optimization and stuff happening in lifecycle-steps after 
compile. This results in bad performance on jenkins. I would like to run

mvn compile install:install as I only need the jars/libs to be installed and 
not the wars (and more important I do not need them to be built).

Please introduce Parameters like

doNotInstallwar/doNotInstall
or
failIfNoArtifactfalse...


--
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] (MINSTALL-94) Optional: limit install to packaging x and or make install plugin not fail if no artifacts were created for some modules.


[ 
https://jira.codehaus.org/browse/MINSTALL-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318376#comment-318376
 ] 

Henning Gross commented on MINSTALL-94:
---

We might submit a Patch if theres a fair chance of getting it merged in soon.

 Optional: limit install to packaging x and or make install plugin not fail if 
 no artifacts were created for some modules.
 -

 Key: MINSTALL-94
 URL: https://jira.codehaus.org/browse/MINSTALL-94
 Project: Maven 2.x Install Plugin
  Issue Type: Improvement
Reporter: Henning Gross

 Background: I am working in a huge project with a lot of modules having a lot 
 of javascript-optimization and stuff happening in lifecycle-steps after 
 compile. This results in bad performance on jenkins. I would like to run
 mvn compile install:install as I only need the jars/libs to be installed and 
 not the wars (and more important I do not need them to be built).
 Please introduce Parameters like
 doNotInstallwar/doNotInstall
 or
 failIfNoArtifactfalse...

--
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] (ARCHETYPE-402) plugin does not seem to consult settings.xml for authentication to repository specified for archetypeCatalog

2013-01-31 Thread Greg Thomas (JIRA)


[ 
https://jira.codehaus.org/browse/ARCHETYPE-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318379#comment-318379
 ] 

Greg Thomas commented on ARCHETYPE-402:
---

Have a look at FAQ#2 at 
http://maven.apache.org/archetype/maven-archetype-plugin/faq.html

 plugin does not seem to consult settings.xml for authentication to repository 
 specified for archetypeCatalog
 

 Key: ARCHETYPE-402
 URL: https://jira.codehaus.org/browse/ARCHETYPE-402
 Project: Maven Archetype
  Issue Type: Improvement
  Components: Archetypes
Affects Versions: 2.2
Reporter: Tamsin Slinn

 We use artifactory internally with authentication, and have manually 
 published an archetype-catalog.xml file.
 If I run  archetype:generate -DarchetypeCatalog=https://my.internal.address, 
 I get an access denied error.
 If I run archetype:generate 
 -DarchetypeCatalog=https://username:password@my.internal.address the it works 
 fine and I can use my published archetypes.
 I have the username and password for the server configured in my settings.xml 
 file, and it works fine to use published artifacts. It would be nice if it 
 worked for this archetype catalog too, so I do not have to put username and 
 password on the command line.

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

[jira] (ARCHETYPE-426) Improved handling of authenticated repositories when generating a project from an archetype

2013-01-31 Thread Greg Thomas (JIRA)


[ 
https://jira.codehaus.org/browse/ARCHETYPE-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318380#comment-318380
 ] 

Greg Thomas commented on ARCHETYPE-426:
---

I've just noticed ARCHETYPE-358 which I think is related to this issue, but I 
don't understand enough to work out if this issue is a duplicate of that one or 
not.

 Improved handling of authenticated repositories when generating a project 
 from an archetype
 ---

 Key: ARCHETYPE-426
 URL: https://jira.codehaus.org/browse/ARCHETYPE-426
 Project: Maven Archetype
  Issue Type: Improvement
  Components: Plugin
Reporter: Greg Thomas
Priority: Minor

 Currently, if you wish to generate a project from an archetype that is held 
 in an authenticated repository, you have to ensure that the server holding 
 the artefact has an id in the format id[archetypeArtifactId]-repo/id 
 (reference: 
 http://maven.apache.org/archetype/maven-archetype-plugin/faq.html).
 This means that if you have half-a-dozen different archetypes in your 
 authenticated repository, you have to have half-a-dozen servers defined in 
 your settings.xml that differ only in their id.
 Instead, it would make more sense if it was possible to supply the server id 
 as an optional parameter, e.g. -DServerId=banana (with associated entry in 
 the archetype-catalog). This could default to [archetypeArtifactId]-repo if 
 not supplied for backward compatibility. 
 That way, the settings.xml file will not fill up with duplicate server 
 entries, all of which need modifying each and every time the password is 
 changed.

--
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] (MINSTALL-94) Optional: limit install to packaging x and or make install plugin not fail if no artifacts were created for some modules.


[ 
https://jira.codehaus.org/browse/MINSTALL-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318376#comment-318376
 ] 

Henning Gross edited comment on MINSTALL-94 at 1/31/13 9:24 AM:


I attached a patch. It works like a charm and we would really benefit from this.

  was (Author: gaffa):
We might submit a Patch if theres a fair chance of getting it merged in 
soon.
  
 Optional: limit install to packaging x and or make install plugin not fail if 
 no artifacts were created for some modules.
 -

 Key: MINSTALL-94
 URL: https://jira.codehaus.org/browse/MINSTALL-94
 Project: Maven 2.x Install Plugin
  Issue Type: Improvement
Reporter: Henning Gross
 Attachments: MINSTALL-94.patch


 Background: I am working in a huge project with a lot of modules having a lot 
 of javascript-optimization and stuff happening in lifecycle-steps after 
 compile. This results in bad performance on jenkins. I would like to run
 mvn compile install:install as I only need the jars/libs to be installed and 
 not the wars (and more important I do not need them to be built).
 Please introduce Parameters like
 doNotInstallwar/doNotInstall
 or
 failIfNoArtifactfalse...

--
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] (ARCHETYPE-426) Improved handling of authenticated repositories when generating a project from an archetype

2013-01-31 Thread Anders Hammar (JIRA)


[ 
https://jira.codehaus.org/browse/ARCHETYPE-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318382#comment-318382
 ] 

Anders Hammar commented on ARCHETYPE-426:
-

@Greg: No, it's not related.

 Improved handling of authenticated repositories when generating a project 
 from an archetype
 ---

 Key: ARCHETYPE-426
 URL: https://jira.codehaus.org/browse/ARCHETYPE-426
 Project: Maven Archetype
  Issue Type: Improvement
  Components: Plugin
Reporter: Greg Thomas
Priority: Minor

 Currently, if you wish to generate a project from an archetype that is held 
 in an authenticated repository, you have to ensure that the server holding 
 the artefact has an id in the format id[archetypeArtifactId]-repo/id 
 (reference: 
 http://maven.apache.org/archetype/maven-archetype-plugin/faq.html).
 This means that if you have half-a-dozen different archetypes in your 
 authenticated repository, you have to have half-a-dozen servers defined in 
 your settings.xml that differ only in their id.
 Instead, it would make more sense if it was possible to supply the server id 
 as an optional parameter, e.g. -DServerId=banana (with associated entry in 
 the archetype-catalog). This could default to [archetypeArtifactId]-repo if 
 not supplied for backward compatibility. 
 That way, the settings.xml file will not fill up with duplicate server 
 entries, all of which need modifying each and every time the password is 
 changed.

--
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] (MINSTALL-94) Optional: limit install to packaging x and or make install plugin not fail if no artifacts were created for some modules.


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

Henning Gross updated MINSTALL-94:
--

Attachment: MINSTALL-94.patch

 Optional: limit install to packaging x and or make install plugin not fail if 
 no artifacts were created for some modules.
 -

 Key: MINSTALL-94
 URL: https://jira.codehaus.org/browse/MINSTALL-94
 Project: Maven 2.x Install Plugin
  Issue Type: Improvement
Reporter: Henning Gross
 Attachments: MINSTALL-94.patch


 Background: I am working in a huge project with a lot of modules having a lot 
 of javascript-optimization and stuff happening in lifecycle-steps after 
 compile. This results in bad performance on jenkins. I would like to run
 mvn compile install:install as I only need the jars/libs to be installed and 
 not the wars (and more important I do not need them to be built).
 Please introduce Parameters like
 doNotInstallwar/doNotInstall
 or
 failIfNoArtifactfalse...

--
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] (MINSTALL-94) Optional: limit install to packaging x and or make install plugin not fail if no artifacts were created for some modules.

[
https://jira.codehaus.org/browse/MINSTALL-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318376#comment-318376
]

Henning Gross edited comment on MINSTALL-94 at 1/31/13 9:36 AM:

I attached a patch. It is really drop-dead-simple, works like a charm and we
would really benefit from this. Is there any hope to get it into the next
release? Do you already have an idea when you will release? We already use a
junit 4.12-SNAPSHOT in our build and I do not want to make that a regular habit
:D

was (Author: gaffa):
I attached a patch. It works like a charm and we would really benefit from
this.

Optional: limit install to packaging x and or make install plugin not fail if
no artifacts were created for some modules.
-

Key: MINSTALL-94
URL: https://jira.codehaus.org/browse/MINSTALL-94
Project: Maven 2.x Install Plugin
Issue Type: Improvement
Reporter: Henning Gross
Attachments: MINSTALL-94.patch

Background: I am working in a huge project with a lot of modules having a lot
of javascript-optimization and stuff happening in lifecycle-steps after
compile. This results in bad performance on jenkins. I would like to run
mvn compile install:install as I only need the jars/libs to be installed and
not the wars (and more important I do not need them to be built).
Please introduce Parameters like
doNotInstallwar/doNotInstall
or
failIfNoArtifactfalse...

[jira] (ARCHETYPE-416) Reproduced bug ARCHETYPE-262 with Maven Archetype 2.2 version

2013-01-31 Thread Anders Hammar (JIRA)


[ 
https://jira.codehaus.org/browse/ARCHETYPE-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318385#comment-318385
 ] 

Anders Hammar commented on ARCHETYPE-416:
-

Please provide a test project reproducing the issue.

 Reproduced bug ARCHETYPE-262 with Maven Archetype 2.2 version
 -

 Key: ARCHETYPE-416
 URL: https://jira.codehaus.org/browse/ARCHETYPE-416
 Project: Maven Archetype
  Issue Type: Bug
Affects Versions: 2.2
 Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 
 21:16:01+0200)
 Java version: 1.6.0_25
 Default locale: es_ES, platform encoding: Cp1252
 OS name: windows 7 version: 6.1 arch: x86 Family: windows
Reporter: Javier Valdes

 I have the same problem found in Reproduced bug ARCHETYPE-262 with Maven 
 Archetype 2.2 version
 When I have an empty property (e.g. jdbc.password/jdbc.password), it's 
 removed from the resulting pom.xml. 

--
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] (ARCHETYPE-403) Error reading archetype catalog http://repo1.maven.org/maven2 on archetype:generate

2013-01-31 Thread Anders Hammar (JIRA)


[ 
https://jira.codehaus.org/browse/ARCHETYPE-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318386#comment-318386
 ] 

Anders Hammar commented on ARCHETYPE-403:
-

What could be the problem here is the version RELEASE in 
org.apache.maven.archetypes:maven-archetype-quickstart:RELEASE.
Does it work if you execute:
mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes 
-DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.1
?

  Error reading archetype catalog http://repo1.maven.org/maven2 on 
 archetype:generate
 

 Key: ARCHETYPE-403
 URL: https://jira.codehaus.org/browse/ARCHETYPE-403
 Project: Maven Archetype
  Issue Type: Bug
  Components: Archetypes, Generator
Affects Versions: 2.1, 2.2
Reporter: Jens Rapp

 hello,
 we use maven behind a cascade of two maven proxies. (only second one is in 
 our hands, the other one connects to internet) 
 When we call mvn archetype:generate this happens:
 {quote}
 hal# /opt/maven-2.1.0/bin/mvn archetype:generate
 [INFO] Scanning for projects...
 [INFO] Searching repository for plugin with prefix: 'archetype'.
 [INFO] 
 
 [INFO] Building Maven Default Project
 [INFO]task-segment: [archetype:generate] (aggregator-style)
 [INFO] 
 
 [INFO] Preparing archetype:generate
 [INFO] No goals needed for project - skipping
 [INFO] [archetype:generate]
 [INFO] Generating project in Interactive mode
 [WARNING] Error reading archetype catalog http://repo1.maven.org/maven2
 org.apache.maven.wagon.TransferFailedException: Error transferring file: 
 repo1.maven.org
 at 
 org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:143)
 at 
 org.apache.maven.wagon.StreamWagon.getInputStream(StreamWagon.java:116)
 at org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:88)
 at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61)
 at 
 org.apache.maven.archetype.source.RemoteCatalogArchetypeDataSource.downloadCatalog(RemoteCatalogArchetypeDataSource.java:119)
 at 
 org.apache.maven.archetype.source.RemoteCatalogArchetypeDataSource.getArchetypeCatalog(RemoteCatalogArchetypeDataSource.java:87)
 at 
 org.apache.maven.archetype.DefaultArchetypeManager.getRemoteCatalog(DefaultArchetypeManager.java:216)
 at 
 org.apache.maven.archetype.DefaultArchetypeManager.getRemoteCatalog(DefaultArchetypeManager.java:205)
 at 
 org.apache.maven.archetype.ui.generation.DefaultArchetypeSelector.getArchetypesByCatalog(DefaultArchetypeSelector.java:200)
 at 
 org.apache.maven.archetype.ui.generation.DefaultArchetypeSelector.selectArchetype(DefaultArchetypeSelector.java:71)
 at 
 org.apache.maven.archetype.mojos.CreateProjectFromArchetypeMojo.execute(CreateProjectFromArchetypeMojo.java:197)
 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)
 Caused by: java.net.UnknownHostException: repo1.maven.org
 at

[jira] (MSITE-672) Interpolation of site deploy URL not done in child

2013-01-31 Thread jieryn (JIRA)


[ 
https://jira.codehaus.org/browse/MSITE-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318387#comment-318387
 ] 

jieryn commented on MSITE-672:
--

BUMP!

This doesn't work even with non-interpolated versions. maven-site-plugin seems 
to want to do its own thing no matter what, and none of these appear to be 
reliable or smart.

 Interpolation of site deploy URL not done in child
 --

 Key: MSITE-672
 URL: https://jira.codehaus.org/browse/MSITE-672
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Bug
  Components: site:deploy
Affects Versions: 3.0
 Environment: Debian Linux OpenJDK 7 mvn 3.0.4 
Reporter: Fred Cooke

 I have my parent distribution site config filled out like so:
 {{urlscp://private-site/home/private/site/releases/$\{project.groupId}/$\{project.artifactId}/$\{project.version}//url}}
 When the child tries to release:perform or {{site:deploy}} it tries to upload 
 with the parent arifactId, groupId and version instead of the current project 
 values. These should be interpolated like any other variables in the POM to 
 prevent needless duplication in all children.

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

[jira] (MSITE-672) Interpolation of site deploy URL not done in child

2013-01-31 Thread jieryn (JIRA)


[ 
https://jira.codehaus.org/browse/MSITE-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318388#comment-318388
 ] 

jieryn commented on MSITE-672:
--

i'm using distributionManagement.site.url=davs:https://blah .. when my top 
level parent sets this also, and i try to set it to something different, all 
combos of { m-site-p 2.3, 3.1, 3.2 } with all combos of { mvn304 and mvn310 } 
will try to construct a relative url... this is breaking my site! how can i 
prevent inheritance of this? even setting a different 
distributionManagement.site.id doesn't prevent maven trying to relativize 
everything. and worst, distributionManagement doesn't accept 
inheritedfalse/inherited


 Interpolation of site deploy URL not done in child
 --

 Key: MSITE-672
 URL: https://jira.codehaus.org/browse/MSITE-672
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Bug
  Components: site:deploy
Affects Versions: 3.0
 Environment: Debian Linux OpenJDK 7 mvn 3.0.4 
Reporter: Fred Cooke

 I have my parent distribution site config filled out like so:
 {{urlscp://private-site/home/private/site/releases/$\{project.groupId}/$\{project.artifactId}/$\{project.version}//url}}
 When the child tries to release:perform or {{site:deploy}} it tries to upload 
 with the parent arifactId, groupId and version instead of the current project 
 values. These should be interpolated like any other variables in the POM to 
 prevent needless duplication in all children.

--
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] (MINSTALL-94) Optional: limit install to packaging x and or make install plugin not fail if no artifacts were created for some modules.


[ 
https://jira.codehaus.org/browse/MINSTALL-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318391#comment-318391
 ] 

Robert Scholte commented on MINSTALL-94:


Assuming you're using a Artifact Repository Manager,  you should use {{verify}} 
instead of {{install}} and let Jenkins deploy the artifacts when the job has 
ended succesfully.
And what's wrong with the 
[skip|http://maven.apache.org/plugins/maven-install-plugin/install-mojo.html#skip]-parameter?


 Optional: limit install to packaging x and or make install plugin not fail if 
 no artifacts were created for some modules.
 -

 Key: MINSTALL-94
 URL: https://jira.codehaus.org/browse/MINSTALL-94
 Project: Maven 2.x Install Plugin
  Issue Type: Improvement
Reporter: Henning Gross
 Attachments: MINSTALL-94.patch


 Background: I am working in a huge project with a lot of modules having a lot 
 of javascript-optimization and stuff happening in lifecycle-steps after 
 compile. This results in bad performance on jenkins. I would like to run
 mvn compile install:install as I only need the jars/libs to be installed and 
 not the wars (and more important I do not need them to be built).
 Please introduce Parameters like
 doNotInstallwar/doNotInstall
 or
 failIfNoArtifactfalse...

--
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] (MCHECKSTYLE-186) FileTabCharacter check not working


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

Robert Scholte updated MCHECKSTYLE-186:
---

Description: 
The FileTabCharacter check doesnt seem to work. Below is my config:

{code:xml}
module name=Checker
..
..
!-- No TAB characters in the source code --
module name=FileTabCharacter
property name=eachLine value=true /
property name=fileExtensions value=java,xml /
/module
..
..
module name=TreeWalker
..
..
/module
/module
{code}

I have my xml files - pom.xml and checkstyle config xml containing tabs but 
none of them are flagged as violations.

Some additional info - my plugin config looks like this:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-checkstyle-plugin/artifactId
version2.9.1/version
executions
execution
phaseverify/phase
goals
goalcheck/goal
/goals
/execution
/executions
configuration

configLocationcheckstyle/kepler-checkstyle-config.xml/configLocation

suppressionsLocation${project.parent.basedir}${file.separator}checkstyle/kepler-checkstyle-suppressions.xml/suppressionsLocation
/configuration
/plugin
{code}

  was:
The FileTabCharacter check doesnt seem to work. Below is my config:

module name=Checker
..
..
!-- No TAB characters in the source code --
module name=FileTabCharacter
property name=eachLine value=true /
property name=fileExtensions value=java,xml /
/module
..
..
module name=TreeWalker
..
..
/module
/module

I have my xml files - pom.xml and checkstyle config xml containing tabs but 
none of them are flagged as violations.

Some additional info - my plugin config looks like this:

plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-checkstyle-plugin/artifactId
version2.9.1/version
executions
execution
phaseverify/phase
goals
goalcheck/goal
/goals
/execution
/executions
configuration

configLocationcheckstyle/kepler-checkstyle-config.xml/configLocation

suppressionsLocation${project.parent.basedir}${file.separator}checkstyle/kepler-checkstyle-suppressions.xml/suppressionsLocation
/configuration
/plugin


 FileTabCharacter check not working
 --

 Key: MCHECKSTYLE-186
 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-186
 Project: Maven 2.x Checkstyle Plugin
  Issue Type: Bug
Reporter: Dipti Desai
Priority: Minor

 The FileTabCharacter check doesnt seem to work. Below is my config:
 {code:xml}
 module name=Checker
 ..
 ..
 !-- No TAB characters in the source code --
 module name=FileTabCharacter
 property name=eachLine value=true /
 property name=fileExtensions value=java,xml /
 /module
 ..
 ..
 module name=TreeWalker
 ..
 ..
 /module
 /module
 {code}
 I have my xml files - pom.xml and checkstyle config xml containing tabs but 
 none of them are flagged as violations.
 Some additional info - my plugin config looks like this:
 {code:xml}
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-checkstyle-plugin/artifactId
 version2.9.1/version
 executions
 execution
 phaseverify/phase
 goals
 goalcheck/goal
 /goals
 /execution
 /executions
 configuration
 
 configLocationcheckstyle/kepler-checkstyle-config.xml/configLocation
 
 suppressionsLocation${project.parent.basedir}${file.separator}checkstyle/kepler-checkstyle-suppressions.xml/suppressionsLocation
 /configuration
 /plugin
 {code}

--
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] (JXR-63) Bottom line in jxr report does not correspond to Javadoc style


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

Michael Osipov updated JXR-63:
--

Attachment: JXR-63.patch

Salut Olivier,

have a look at the patch. I have fully aligned the generation to the JavaDoc 
plugin. They do resemble now.

 Bottom line in jxr report does not correspond to Javadoc style
 --

 Key: JXR-63
 URL: https://jira.codehaus.org/browse/JXR-63
 Project: Maven JXR
  Issue Type: Bug
  Components: maven2 jxr plugin
Affects Versions: 2.1
Reporter: Michael Osipov
 Attachments: JXR-63.patch


 I user JXR with Maven and produce Javadoc too.
 I've set:
 inceptionYear2004/inceptionYear
 organizationMyOrg/organization
 organizationUrlhttp://www.somedomain.com/organizationUrl
 What the JAvadoc plugin does for the javadoc report is, it creates a bottom 
 line like this:
 {code}
 Copyright #169; 2004-2008 a href=http://www.somedomain.com;MyOrg/a. All 
 Rights Reserved.
 {code}
 but what jxr produces is
 {code}
 Copyright copy; 2004-2008 MyOrg. All Rights Reserved.
 {code}
 Because JXR tries to resemble javadoc, this bottom line should produce the 
 same ouput

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

[jira] (SUREFIRE-952) Incompatibility with future release 4.12 of junit (Categories)

[
https://jira.codehaus.org/browse/SUREFIRE-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318403#comment-318403
]

Andreas Gudian commented on SUREFIRE-952:
-

First of all, thanks for the example. But I still don't really get what the
remaining problem is.

This is what I tried with your demo projects (I changed the junit-dependencies
to junit:junit:4.12-SNAPSHOT and removed the junitArtifactName-property):

* Groups and excludedGroups work as expected with the dummy test class and the
@Category annotation on the super class. *No problem observed* (Which is what
you meant with your first comment, right?)
* Leaving the groups-setting in the parent pom, but removing the
junit-dependency in the module that does not contain any tests worked as
expected (no tests were executed, no error was shown). *No problem observed*

So, I did some digging into the code and tried around a bit more: When using
groups/excludedGroups, the artifacts of either {{testNGArtifactName}} or
{{junitArtifactName}} (manually overwritten or default values) need to be on
the classpath. Surefire will ignore that only if not target/test-classes
directory was created by the build, which is typically the case when you have
nothing within your src/test/java directory. That sounds somewhat reasonable to
me, I guess it is not in violation of the documentation, and it is not that
hard to accomplish (in my project, when I configure surefire in a parent pom, I
also add the test-scope dependency for junit right away). So, I see *no real
problem* here, too.

I tried Surefire 2.12.2 (what you included in the pom), 2.13 (the current
release) and 2.14-SNAPSHOT (which will be released within the next very few
weeks). I did not try 2.3 - too old for my taste ;).

From where I'm standing, I see no action to take in Surefire. Did I miss
something? Do you have an other opinion?

Btw, since 2.13 we do not try to compute the outcome of the JUnit
{{@Category}}-filtering anymore and leave it to the JUnit implementation
itself. :)

Incompatibility with future release 4.12 of junit (Categories)
--

[jira] (SUREFIRE-952) Incompatibility with future release 4.12 of junit (Categories)


[ 
https://jira.codehaus.org/browse/SUREFIRE-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318403#comment-318403
 ] 

Andreas Gudian edited comment on SUREFIRE-952 at 1/31/13 1:38 PM:
--

First of all, thanks for the example. But I still don't really get what the 
remaining problem is.

This is what I tried with your demo projects (I changed the junit-dependencies 
to junit:junit:4.12-SNAPSHOT and removed the junitArtifactName-property):

* Groups and excludedGroups work as expected with the dummy test class and the 
@Category annotation on the super class. *No problem observed* (Which is what 
you meant with your first comment, right?)
* Leaving the groups-setting in the parent pom, but removing the 
junit-dependency in the module that does not contain any tests worked as 
expected (no tests were executed, no error was shown). *No problem observed*

So, I did some digging into the code and tried around a bit more: When using 
groups/excludedGroups, the artifacts of either {{testNGArtifactName}} or 
{{junitArtifactName}} (manually overwritten or default values) need to be on 
the classpath. Surefire will ignore that only if no target/test-classes 
directory was created by the build, which is typically the case when you have 
nothing within your src/test/java and src/test/resources directories. That 
sounds somewhat reasonable to me, I guess it is not in violation of the 
documentation, and it is not that hard to accomplish (in my project, when I 
configure surefire in a parent pom, I also add the test-scope dependency for 
junit right away). So, I see *no real problem* here, too.

I tried Surefire 2.12.2 (what you included in the pom), 2.13 (the current 
release) and 2.14-SNAPSHOT (which will be released within the next very few 
weeks). I did not try 2.3 - too old for my taste ;).

From where I'm standing, I see no action to take in Surefire. Did I miss 
something? Do you have an other opinion?

Btw, since 2.13 we do not try to compute the outcome of the JUnit 
{{@Category}}-filtering anymore and leave it to the JUnit implementation 
itself. :)



  was (Author: agudian):
First of all, thanks for the example. But I still don't really get what the 
remaining problem is.

This is what I tried with your demo projects (I changed the junit-dependencies 
to junit:junit:4.12-SNAPSHOT and removed the junitArtifactName-property):

* Groups and excludedGroups work as expected with the dummy test class and the 
@Category annotation on the super class. *No problem observed* (Which is what 
you meant with your first comment, right?)
* Leaving the groups-setting in the parent pom, but removing the 
junit-dependency in the module that does not contain any tests worked as 
expected (no tests were executed, no error was shown). *No problem observed*

So, I did some digging into the code and tried around a bit more: When using 
groups/excludedGroups, the artifacts of either {{testNGArtifactName}} or 
{{junitArtifactName}} (manually overwritten or default values) need to be on 
the classpath. Surefire will ignore that only if not target/test-classes 
directory was created by the build, which is typically the case when you have 
nothing within your src/test/java directory. That sounds somewhat reasonable to 
me, I guess it is not in violation of the documentation, and it is not that 
hard to accomplish (in my project, when I configure surefire in a parent pom, I 
also add the test-scope dependency for junit right away). So, I see *no real 
problem* here, too.

I tried Surefire 2.12.2 (what you included in the pom), 2.13 (the current 
release) and 2.14-SNAPSHOT (which will be released within the next very few 
weeks). I did not try 2.3 - too old for my taste ;).

From where I'm standing, I see no action to take in Surefire. Did I miss 
something? Do you have an other opinion?

Btw, since 2.13 we do not try to compute the outcome of the JUnit 
{{@Category}}-filtering anymore and leave it to the JUnit implementation 
itself. :)


  
 Incompatibility with future release 4.12 of junit (Categories)
 --

 Key: SUREFIRE-952
 URL: https://jira.codehaus.org/browse/SUREFIRE-952
 Project: Maven Surefire
  Issue Type: Bug
  Components: Junit 4.x support
Affects Versions: 2.12.2, 2.12.4
Reporter: Henning Gross
Priority: Blocker
 Attachments: surefire-952.zip


 Junit is introducing some interesting new features on Categories in 4.12. 
 @Category will become @Inherited and @ExcludeCategory/@IncludeCategory will 
 accept a class-array instead of just a single class. As we need these 
 urgently we are currently testing with the current snapshot of junit

[jira] (MNG-5181) New resolution from local repository is very confusing

2013-01-31 Thread JIRA

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

Jörg Hohwiller commented on MNG-5181:
-

Yes, please add a property to disable this feautre. The property could be
declated on the commandline as well as in my settings.xml. This would preserve
tons of trouble and headaches I had supporting other maven users with this
issue.

New resolution from local repository is very confusing
--

Key: MNG-5181
URL: https://jira.codehaus.org/browse/MNG-5181
Project: Maven 2 3
Issue Type: Improvement
Components: Dependencies
Affects Versions: 3.0, 3.0.1, 3.0.2, 3.0.3
Reporter: Arnaud Heritier
Assignee: Jason van Zyl

I just discover the change introduced in Maven 3.x to try to improve the
resolution mechanism and to avoid to use a local artifact which may not be
available in its remote repository :
https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository
Even if the feature is interesting it has several problems :
# When an artifact isn't accessible from its remote repository it isn't used
by maven which replies a classical dependency not found error. It is really
annoying for a user with some Maven 2 skills which will have a look at his
local repo, will find the artifact and won't understand why Maven doesn't use
it. At least the error reported by Maven should be clear that even if the
dependency is available locally, it isn't used because it's remote repository
isn't available.
# This behavior cannot be configured to be only a warning for example. It is
really annoying because it doesn't take care of some context and constraints
we may have in a development team. Let's imagine that the remote artifact is
really removed. Cool Maven broke the build to warn us. But it brakes the
build of all the team whereas perhaps only one of them may try to solve the
issue (and it can be a long resolution). Thus having the ability to configure
if this control is blocker or warning may allow the team to configure it as
blocker on the CI server and as warning on the development environment.
# This behavior may introduce some bad practices for example when we are
using a staging feature on a repository manager. In our case my teams have a
dedicated profile to activate a staging repository when we are validating a
release. I recommend to not have this profile always activated but to do it
only on-demand to avoid them to DL staging stuffs they don't need. With this
new feature they need for all builds they run to activate this staging
profile while binaries are stored in it. When you have to do it 20 times per
day minimum let's imagine what the developer does : It adds it as an
alwaysActive profile and then forget to remove it when the release is ended.
For all these reason I would like we improve this feature to make it more
usable and before all bet understandable for ours users.

[jira] (MNG-5185) Improve missing dependency error message when _maven.repositories conflict


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

Olivier Lamy updated MNG-5185:
--

Affects Version/s: 3.0.2
   3.0.3
   3.0.4
Fix Version/s: 3.1.0
 Assignee: Olivier Lamy

 Improve missing dependency error message when _maven.repositories conflict
 

 Key: MNG-5185
 URL: https://jira.codehaus.org/browse/MNG-5185
 Project: Maven 2  3
  Issue Type: Improvement
Affects Versions: 3.0.2, 3.0.3, 3.0.4
Reporter: Mark Derricutt
Assignee: Olivier Lamy
 Fix For: 3.1.0

 Attachments: 
 0001-MNG-5185-Warn-about-artifacts-present-but-not-availa.patch


 Based on a discussion on the users list [1], Maven 3 has changed how it 
 resolves artifacts from custom repositories.  Unfortunately, when conflicts 
 arise ( GAV is in local repo, but POM has no matching repository id declared 
 ) Maven just tells the user that the artifact could not be resolved.
 This leads to confusion from users who find the .jar files in their local 
 repository, and they just get frustrated and complain that maven sucks.
 It would be good if Maven was updated with some improved error messages along 
 the lines of:
 The {GAV} artifact was found in your local repository, but came from the 
 undeclared repository xxx, either configure this in your pom with {insert 
 sample XML block in error message}, or in your yyy mirror.
 The mirror section of the error message should be included -if- the current 
 ~/.m2/settings.xml declares a mirror.  By improving the messages here we can 
 help the users move on to building software, rather than pulling out their 
 hair :)
 [1] 
 http://maven.40175.n5.nabble.com/Maven-3-maven-repositories-and-lastUpdated-td4927537.html

--
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-5428) Update documentation to make it clear released artifacts are never updated in the local cache

2013-01-31 Thread Kent Moore (JIRA)

Kent Moore created MNG-5428:
---

 Summary: Update documentation to make it clear released artifacts 
are *never* updated in the local cache
 Key: MNG-5428
 URL: https://jira.codehaus.org/browse/MNG-5428
 Project: Maven 2  3
  Issue Type: Improvement
  Components: Documentation:  General
Affects Versions: 3.0.4
Reporter: Kent Moore
Priority: Minor


A literal reading of the updatePolicy section of 
http://maven.apache.org/ref/3.0.4/maven-settings/settings.html, as well as  
Maven help for the -U option, makes it seem as though Maven is capable of 
updating release artifacts in the local cache.  But that is not the case.

I believe the documentation in both areas should be updated to make it clear 
released artifacts are *never* re-downloaded to the local Maven cache, even if 
the repository manager contains a newer version of the release (which shouldn't 
ever happen, but).

See 
http://mail-archives.apache.org/mod_mbox/maven-users/201301.mbox/%3CCANdpH_0qHU5grD%3D%3DPRWDJiU7YFsoqw8T0Az0XTJRD7%3DOtwMjtw%40mail.gmail.com%3E.




--
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] (MPH-90) help:effective-pom does not show full effective-pom

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

Michael Osipov reopened MPH-90:
---

Hi Robert, I need to reopen this one. Either you misunderstood my case or I did
not make it clear enough.

Here is the case in more detail:
Say you define the previously mentioned properties, then run the effective pom
goal and inspect the compiler plugin configuration, it is empty. This means
that configuration of properties is not written back to the model. See attached
screenshot, POM file and logfile.

Your testcase inspects the properties section only, this isn't what I was
talking about.

help:effective-pom does not show full effective-pom
---

Key: MPH-90
URL: https://jira.codehaus.org/browse/MPH-90
Project: Maven 2.x Help Plugin
Issue Type: Bug
Affects Versions: 2.1.1
Environment: Maven 2.2.1 and Maven 3.0.3
Reporter: Michael Osipov
Assignee: Robert Scholte

When I define something like this in my POM:
{code:xml}
properties
maven.compiler.source1.6/maven.compiler.source
maven.compiler.target1.6/maven.compiler.target
/properties
{code}
the compiler plugin picks this up but this settings is not reflected in the
{{Model}} and not written out as part of the effective POM.
Either this is fixed within the system or the docs of this plugin need to
mention this clearly.
This is related to MJAVADOC-310 and MPIR-263.
I a workaround for now by passing those properties to the plugin but this
does not solve this problem.

[jira] (MPH-90) help:effective-pom does not show full effective-pom


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

Michael Osipov updated MPH-90:
--

Attachment: effective-pom.log
pom.xml
target-option.png
compiler-debug.png

 help:effective-pom does not show full effective-pom
 ---

 Key: MPH-90
 URL: https://jira.codehaus.org/browse/MPH-90
 Project: Maven 2.x Help Plugin
  Issue Type: Bug
Affects Versions: 2.1.1
 Environment: Maven 2.2.1 and Maven 3.0.3
Reporter: Michael Osipov
Assignee: Robert Scholte
 Attachments: compiler-debug.png, effective-pom.log, pom.xml, 
 target-option.png


 When I define something like this in my POM:
 {code:xml}
 properties
   maven.compiler.source1.6/maven.compiler.source
   maven.compiler.target1.6/maven.compiler.target
 /properties
 {code}
 the compiler plugin picks this up but this settings is not reflected in the 
 {{Model}} and not written out as part of the effective POM.
 Either this is fixed within the system or the docs of this plugin need to 
 mention this clearly.
 This is related to MJAVADOC-310 and MPIR-263.
 I a workaround for now by passing those properties to the plugin but this 
 does not solve this problem.

--
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-1977) Global dependency exclusions

2013-01-31 Thread Neale (JIRA)


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

Neale commented on MNG-1977:


JvZ - why not Maven 3.1 for this?  It's highly voted and there's a patch, yet 
no comment on the patch has been made.  That's not good for goodwill :(

 Global dependency exclusions
 

 Key: MNG-1977
 URL: https://jira.codehaus.org/browse/MNG-1977
 Project: Maven 2  3
  Issue Type: New Feature
  Components: POM
Reporter: Kees de Kooter
 Fix For: 3.2

 Attachments: global_excls_it-test_v2.patch, 
 global_excls_it-test_v3.patch, global_excls_maven3_v2.patch, 
 global_excls_maven3_v3.patch


 I depend on some libraries, which in turn depend on something
 (which in turn depend on something) that I don't want, because I declare
 some other artifact in my pom.xml.
 A concrete example: I don't want that the artifact xerces is imported in
 my project because I declare to depend on  xercesImpl which ships newer
 libraries but with the same namespaces.
 I guess I would need an exclude transitive dependency at all, either
 globally or from this and that artifact. I saw the exclusions tag, but it
 forces me to be very verbose and have exact control on what is required by a
 dependency.

--
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] (MPH-90) help:effective-pom does not show full effective-pom


[ 
https://jira.codehaus.org/browse/MPH-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318410#comment-318410
 ] 

Robert Scholte commented on MPH-90:
---

No problem that it is reopened.

I'm not interested in what the debugger is saying halfway the execution, but 
I'm more interested in what kind of output you would expect. Please check out 
this project and run {{mvn clean verify -Prun-its 
-Dinvoker.test=effective-pom_properties}} and have a look at the 
{{target/it/effective-pom_properties/build.log}}. 

If you change the {{invoker.goals}} to {{compile}} you'll see something like 
{noformat}
[DEBUG] Configuring mojo 
org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile from plugin realm 
ClassRealm[pluginorg.apache.maven.plugins:maven-compiler-plugin:2.3.2, parent: 
sun.misc.Launcher$AppClassLoader@5acac268]
[DEBUG] Configuring mojo 
'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic 
configurator --
[DEBUG]   (f) basedir = 
E:\java-workspace\apache-maven-plugins\maven-help-plugin\target\it\effective-pom_properties
[DEBUG]   (f) buildDirectory = 
E:\java-workspace\apache-maven-plugins\maven-help-plugin\target\it\effective-pom_properties\target
[DEBUG]   (f) classpathElements = 
[E:\java-workspace\apache-maven-plugins\maven-help-plugin\target\it\effective-pom_properties\target\classes]
[DEBUG]   (f) compileSourceRoots = 
[E:\java-workspace\apache-maven-plugins\maven-help-plugin\target\it\effective-pom_properties\src\main\java]
[DEBUG]   (f) compilerId = javac
[DEBUG]   (f) debug = true
[DEBUG]   (f) failOnError = true
[DEBUG]   (f) fork = false
[DEBUG]   (f) generatedSourcesDirectory = 
E:\java-workspace\apache-maven-plugins\maven-help-plugin\target\it\effective-pom_properties\target\generated-sources\annotations
[DEBUG]   (f) optimize = false
[DEBUG]   (f) outputDirectory = 
E:\java-workspace\apache-maven-plugins\maven-help-plugin\target\it\effective-pom_properties\target\classes
[DEBUG]   (f) outputFileName = mph-90-1.0-SNAPSHOT
[DEBUG]   (f) projectArtifact = 
org.apache.maven.its.help:mph-90:jar:1.0-SNAPSHOT
[DEBUG]   (f) session = org.apache.maven.execution.MavenSession@2bbd9de3
[DEBUG]   (f) showDeprecation = false
[DEBUG]   (f) showWarnings = false
[DEBUG]   (f) source = 1.6
[DEBUG]   (f) staleMillis = 0
[DEBUG]   (f) target = 1.6
[DEBUG]   (f) verbose = false
[DEBUG] -- end configuration --
{noformat}

IMO {{effective-pom}} is not about the build-plan and build-configuration, but 
only about merging the current pom with all its parent up to the super-pom 
provided by Maven.

 help:effective-pom does not show full effective-pom
 ---

 Key: MPH-90
 URL: https://jira.codehaus.org/browse/MPH-90
 Project: Maven 2.x Help Plugin
  Issue Type: Bug
Affects Versions: 2.1.1
 Environment: Maven 2.2.1 and Maven 3.0.3
Reporter: Michael Osipov
Assignee: Robert Scholte
 Attachments: compiler-debug.png, effective-pom.log, pom.xml, 
 target-option.png


 When I define something like this in my POM:
 {code:xml}
 properties
   maven.compiler.source1.6/maven.compiler.source
   maven.compiler.target1.6/maven.compiler.target
 /properties
 {code}
 the compiler plugin picks this up but this settings is not reflected in the 
 {{Model}} and not written out as part of the effective POM.
 Either this is fixed within the system or the docs of this plugin need to 
 mention this clearly.
 This is related to MJAVADOC-310 and MPIR-263.
 I a workaround for now by passing those properties to the plugin but this 
 does not solve this problem.

--
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] (MPH-90) help:effective-pom does not show full effective-pom

[
https://jira.codehaus.org/browse/MPH-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318411#comment-318411
]

Michael Osipov commented on MPH-90:
---

Robert, I see the same output. But as you can see yourself, the debug output of
the compiler plugin says source/target 1.6 and effective-pom does not carry the
very same information in the configuration section. The description of the
effective-pom goal says
bq. Displays the effective POM as an XML for this build, with the active
profiles factored in.

As far as I can see, the build system does not inject that kind of information
back to the XPP3Dom object. This cannot be fixed in the help plugin itself
though the documention of the goal should be altered to reflect this limitation.

help:effective-pom does not show full effective-pom
---

[jira] (MPH-90) help:effective-pom does not show full effective-pom

[
https://jira.codehaus.org/browse/MPH-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318412#comment-318412
]

Robert Scholte commented on MPH-90:
---

What kind of desciption would you suggest? Is the word 'effective' confusing?
The {{effective-pom}} is a standalone pom.xml, where all parents are merged
into. Notice that it doesn't refer to a parent anymore.

help:effective-pom does not show full effective-pom
---

[jira] (WAGON-383) Regression for SSLv3


[ 
https://jira.codehaus.org/browse/WAGON-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318414#comment-318414
 ] 

Olivier Lamy commented on WAGON-383:


bin.zip or bin.tar.gz available for testing here 
https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x/

 Regression for SSLv3
 

 Key: WAGON-383
 URL: https://jira.codehaus.org/browse/WAGON-383
 Project: Maven Wagon
  Issue Type: Bug
  Components: wagon-http
Affects Versions: 2.2, 2.3
 Environment: Operation system independent, but tested on Macbook Pro 
 with 10.6 and Red Hat Enterprise Linux 6 on a virtual machine.
Reporter: James Kionka
Priority: Critical
 Fix For: 2.4


 When attempting to access a Maven repository which uses SSLv3, you get the 
 following error, javax.net.ssl.SSLException: Received fatal alert: 
 bad_record_mac.
 Earlier versions of Maven used java.net.URLConnection which respects the 
 https.protocols system property. This allowed us to set it to SSLv3, which is 
 what our Maven repository uses. However, HttpClient ignores that property. In 
 other situations, we programmatically tell HttpClient to use SSLv3, which we 
 cannot do from our end.
 You can find another person in the same situation here: 
 http://stackoverflow.com/questions/12787657/received-fatal-alert-bad-record-mac-when-deploying-to-sonatype

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

[jira] (WAGON-372) SSL client-side certificates stopped working in maven 3.0.4


[ 
https://jira.codehaus.org/browse/WAGON-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318413#comment-318413
 ] 

Olivier Lamy commented on WAGON-372:


bin.zip or bin.tar.gz available for testing here 
https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x/

 SSL client-side certificates stopped working in maven 3.0.4
 ---

 Key: WAGON-372
 URL: https://jira.codehaus.org/browse/WAGON-372
 Project: Maven Wagon
  Issue Type: Bug
  Components: wagon-http
Affects Versions: 2.2
 Environment: Fedora, Ubuntu
Reporter: Igor von Nyssen
Assignee: Olivier Lamy
 Fix For: 2.4

 Attachments: maven-httpwagen-httpclient-ssl-setup.patch, 
 maven-httpwagen-httpclient-ssl-setup-refactoring.patch


 The following command works perfectly in Maven 3.0.3, but 3.0.4 does not seem 
 to open the key store and therefore client side certificate authentication 
 fails as maven never presents a certificate to the server.
 mvn deploy -Djavax.net.ssl.keyStore=/home/user/ssl/key.p12 
 -Djavax.net.ssl.keyStorePassword=** -Djavax.net.ssl.keyStoreType=pkcs12
 adding -Djavax.net.debug=all reveals that the keystore is never loaded. 
 Confirmed with strace that the keystore file is never touched or opened.

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

[jira] (MSITE-672) Interpolation of site deploy URL not done in child


[ 
https://jira.codehaus.org/browse/MSITE-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318424#comment-318424
 ] 

Olivier Lamy edited comment on MSITE-672 at 1/31/13 5:01 PM:
-

regarding interpolation like 
urlscp://private-site/home/private/site/releases/${project.groupId}/${project.artifactId}/${project.version}//url
values come from the pom where the element is located.
A possible solution/workaround (but not working currently) is to use something 
like:
{code}

properties
  
deploySiteUrlscp://private-site/home/private/site/releases/${project.groupId}/${project.artifactId}/${project.version}/deploySiteUrl
/properties
distributionManagement
  site
url${deploySiteUrl}/url
  /site
/distributionManagement

{code}

But this won't work currently as current project artifact is appended.
This issue cannot be fixed in the site plugin as all is done in maven core.
See classes called  MavenModelMerger and ModelMerger (see method mergeSite_Url).
A possible fix could be done with a flag preventing appending (but must off per 
default)


  was (Author: olamy):
regarding interpolation like 
urlscp://private-site/home/private/site/releases/${project.groupId}/${project.artifactId}/${project.version}//url
values come from the pom where the element is located.
A possible solution/workaround (but not working currently) is to use something 
like:
{code}
properties
  
deploySiteUrlscp://private-site/home/private/site/releases/${project.groupId}/${project.artifactId}/${project.version}/deploySiteUrl
/properties
distributionManagement
  site
url${deploySiteUrl}/url
  /site
/distributionManagement
{code}
But this won't work currently as current project artifact is appended.
This issue cannot be fixed in the site plugin as all is done in maven core.
See classes called  MavenModelMerger and ModelMerger (see method mergeSite_Url).
A possible fix could be done with a flag preventing appending (but must off per 
default)

  
 Interpolation of site deploy URL not done in child
 --

 Key: MSITE-672
 URL: https://jira.codehaus.org/browse/MSITE-672
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Bug
  Components: site:deploy
Affects Versions: 3.0
 Environment: Debian Linux OpenJDK 7 mvn 3.0.4 
Reporter: Fred Cooke

 I have my parent distribution site config filled out like so:
 {{urlscp://private-site/home/private/site/releases/$\{project.groupId}/$\{project.artifactId}/$\{project.version}//url}}
 When the child tries to release:perform or {{site:deploy}} it tries to upload 
 with the parent arifactId, groupId and version instead of the current project 
 values. These should be interpolated like any other variables in the POM to 
 prevent needless duplication in all children.

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

[jira] (MSITE-672) Interpolation of site deploy URL not done in child

2013-01-31 Thread Fred Cooke (JIRA)


[ 
https://jira.codehaus.org/browse/MSITE-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318425#comment-318425
 ] 

Fred Cooke commented on MSITE-672:
--

Thanks for the insight! I have to say, I'm quite surprised to find that the 
interpolation is done almost manually on a per field basis. That just seems 
insane. 

For reference:

https://maven.apache.org/ref/3.0.4/xref/org/apache/maven/model/merge/MavenModelMerger.html#419

Your possible fix around would work for me, I think.

Currently my work around is to declare the property with vars in the parent 
with a short name, and just fill out the site distribution with that variable 
in the children, but I strongly dislike the duplication of it. My goal is an 
empty pom for simple library builds.

 Interpolation of site deploy URL not done in child
 --

 Key: MSITE-672
 URL: https://jira.codehaus.org/browse/MSITE-672
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Bug
  Components: site:deploy
Affects Versions: 3.0
 Environment: Debian Linux OpenJDK 7 mvn 3.0.4 
Reporter: Fred Cooke

 I have my parent distribution site config filled out like so:
 {{urlscp://private-site/home/private/site/releases/$\{project.groupId}/$\{project.artifactId}/$\{project.version}//url}}
 When the child tries to release:perform or {{site:deploy}} it tries to upload 
 with the parent arifactId, groupId and version instead of the current project 
 values. These should be interpolated like any other variables in the POM to 
 prevent needless duplication in all children.

--
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] (MINSTALL-94) Optional: limit install to packaging x and or make install plugin not fail if no artifacts were created for some modules.

[
https://jira.codehaus.org/browse/MINSTALL-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318426#comment-318426
]

Henning Gross commented on MINSTALL-94:
---

Hi Robert!
I think you did not get my use-case. Its in the nature of a
multi-module-project that there are dependencies between modules. For instance
lets say you have 3 or 4 libraries, a core-lib and maybe like 10 to 20
consumers. You cannot run mvn test on the parent as the dependencies will be
missing (or old if already deployed before). You would have to run mvn install
to make sure those artifacts are deployed. When running the install-goal there
are some other phases in the default lifecycle that are passed before. As we
have a rather large amount of war-files with overlays and a lot of javascript
and less-foo configured those phases like packaging take forever. With no
benefit at all. I think the test-install jar thing that I have in mind is a
pretty valid requirement and a lot of projects do need it. In huge projects it
is essential to save as much time as possible in the basic jenkins-Jobs to
allow feedback early.
The approach of running two jenkins-jobs (one that installs the libs and the
other one that runs the tests on the consumers) brings a lot of configuration
overhead. Modules need to be wrapped in profiles and a build-pipeline on
Jenkins is necessary to make sure you are getting exactly the jars that were
just build and not something deployed from anywhere.
To your last question (what is wrong with the skip-parameter?): as I stated
and hopefully now explained: its not about skipping anything really. Its about
being able to install stuff w/o running all phases before install (which causes
eg wars to not being build). Of course we could configure the skip-parameter in
every single consumer-module wrapped in a profile but that feels like a hack to
me. Dont you think so? Also I do not have the source available right now. Is
the skip-param evaluated before the check for the artifact is done? That would
be necessary for this approach. Can I ask you the other way around? What is
wrong with making this behaviour configurable? Other plugins also expose
switches for fail-behaviour.

Optional: limit install to packaging x and or make install plugin not fail if
no artifacts were created for some modules.
-

Key: MINSTALL-94
URL: https://jira.codehaus.org/browse/MINSTALL-94
Project: Maven 2.x Install Plugin
Issue Type: Improvement
Reporter: Henning Gross
Attachments: MINSTALL-94.patch

[jira] (MDEP-395) get doesn't copy transitive dependencies to output directory

2013-01-31 Thread Craig Forster (JIRA)

Craig Forster created MDEP-395:
--

 Summary: get doesn't copy transitive dependencies to output 
directory
 Key: MDEP-395
 URL: https://jira.codehaus.org/browse/MDEP-395
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
  Components: get
Affects Versions: 2.6
Reporter: Craig Forster


The documentation for the 'get' operation declares:

Downloads a single artifact transitively from the specified remote 
repositories.

However, only the artifact specified is copied to the 'dest' directory.  All 
the dependencies are downloaded into the local repository, however.

For example:

cforster-mbp:maven craig.forster$ mvn 
org.apache.maven.plugins:maven-dependency-plugin:2.6:copy 
-Dartifact=com.sun.jersey:jersey-bundle:1.9.1 -Ddest=out/ 
-Dtransitive=true[INFO] Scanning for projects...
[INFO]
[INFO] 
[INFO] Building Maven Stub Project (No POM) 1
[INFO] 
[INFO]
[INFO] --- maven-dependency-plugin:2.6:copy (default-cli) @ standalone-pom ---
[INFO] Configured Artifact: com.sun.jersey:jersey-bundle:1.9.1:jar
[INFO] Copying jersey-bundle-1.9.1.jar to 
/Users/craig.forster/tmp/maven/${project.basedir}/target/dependency/jersey-bundle-1.9.1.jar
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 1.157s
[INFO] Finished at: Thu Jan 31 17:15:17 CST 2013
[INFO] Final Memory: 6M/81M
[INFO] 
cforster-mbp:maven craig.forster$ ll out
total 2776
drwxr-xr-x  3 craig.forster  SAILPOINT\Domain Users  102 Jan 31 17:04 .
drwxr-xr-x  4 craig.forster  SAILPOINT\Domain Users  136 Jan 31 17:15 ..
-rw-r--r--  1 craig.forster  SAILPOINT\Domain Users  1420500 Jan 30 15:42 
jersey-bundle-1.9.1.jar

--
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] (MINSTALL-94) Optional: limit install to packaging x and or make install plugin not fail if no artifacts were created for some modules.

[
https://jira.codehaus.org/browse/MINSTALL-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318426#comment-318426
]

Henning Gross edited comment on MINSTALL-94 at 1/31/13 5:24 PM:

Hi Robert!
I think you did not get my use-case. Its in the nature of a
multi-module-project that there are dependencies between modules. For instance
lets say you have 3 or 4 libraries, a core-lib and maybe like 10 to 20
consumers. You cannot run mvn test on the parent as the dependencies will be
missing (or old if already deployed before). You would have to run mvn install
to make sure those artifacts are deployed. When running the install-goal there
are some other phases in the default lifecycle that are passed before. As we
have a rather large amount of war-files with overlays and a lot of javascript
and less-foo configured those phases like packaging take forever. With no
benefit at all. I think the test-install jar thing that I have in mind is a
pretty valid requirement and a lot of projects do need it. In huge projects it
is essential to save as much time as possible in the basic jenkins-Jobs to
allow feedback early.
The approach of running two jenkins-jobs (one that installs the libs and the
other one that runs the tests on the consumers) brings a lot of configuration
overhead. Modules need to be wrapped in profiles and a build-pipeline on
Jenkins is necessary to make sure you are getting exactly the jars that were
just build and not something deployed from anywhere.
To your last question (what is wrong with the skip-parameter?): Of course we
could configure the skip-parameter in every single consumer-module wrapped in a
profile but that feels like a hack to me and is a lot of overhead compared to
just one line in the parent. Dont you think so? Thank you anyway for that idea.
I will probably implement it as fast is more important than nice. But fast and
nice would be even better ;)
Can I ask you the other way around? What is wrong with making this behaviour
configurable? Other plugins also expose switches for fail-behaviour.

was (Author: gaffa):
Hi Robert!
I think you did not get my use-case. Its in the nature of a
multi-module-project that there are dependencies between modules. For instance
lets say you have 3 or 4 libraries, a core-lib and maybe like 10 to 20
consumers. You cannot run mvn test on the parent as the dependencies will be
missing (or old if already deployed before). You would have to run mvn install
to make sure those artifacts are deployed. When running the install-goal there
are some other phases in the default lifecycle that are passed before. As we
have a rather large amount of war-files with overlays and a lot of javascript
and less-foo configured those phases like packaging take forever. With no
benefit at all. I think the test-install jar thing that I have in mind is a
pretty valid requirement and a lot of projects do need it. In huge projects it
is essential to save as much time as possible in the basic jenkins-Jobs to
allow feedback early.
The approach of running two jenkins-jobs (one that installs the libs and the
other one that runs the tests on the consumers) brings a lot of configuration
overhead. Modules need to be wrapped in profiles and a build-pipeline on
Jenkins is necessary to make sure you are getting exactly the jars that were
just build and not something deployed from anywhere.
To your last question (what is wrong with the skip-parameter?): as I stated
and hopefully now explained: its not about skipping anything really. Its about
being able to install stuff w/o running all phases before install (which causes
eg wars to not being build). Of course we could configure the skip-parameter in
every single consumer-module wrapped in a profile but that feels like a hack to
me. Dont you think so? Also I do not have the source available right now. Is
the skip-param evaluated before the check for the artifact is done? That would
be necessary for this approach. Can I ask you the other way around? What is
wrong with making this behaviour configurable? Other plugins also expose
switches for fail-behaviour.

Optional: limit install to packaging x and or make install plugin not fail if
no artifacts were created for some modules.
-

Key: MINSTALL-94
URL: https://jira.codehaus.org/browse/MINSTALL-94
Project: Maven 2.x Install Plugin
Issue Type: Improvement
Reporter: Henning Gross
Attachments: MINSTALL-94.patch

Background: I am working in a huge project with a lot of modules having a lot
of javascript-optimization and stuff happening in lifecycle-steps after
compile. This results in bad

[jira] (SUREFIRE-952) Incompatibility with future release 4.12 of junit (Categories)

[
https://jira.codehaus.org/browse/SUREFIRE-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318427#comment-318427
]

Henning Gross commented on SUREFIRE-952:

Hi! I am sorry. I got confused while putting together the example. Of course I
wanted to do that with 2.13 not 2.3. That may also be the reason why I couldnt
reproduce the issue. Your information solves all my confusion:

Surefire will ignore that only if no target/test-classes directory was
created by the build

I am not sure and will not be able to check soon but this could be the reason
why sometimes it would fail and in other modules not. I am really sorry for all
the confusion but I just could not get it together. I has some example project
and a real-life multi-module-project and simply did not get the behaviour. I
dont know if that explains everything but I would suggest we close this issue
and if I really come across a bug i can reproduce I will open a new issue w/o
all this confusion.

Regards!

Incompatibility with future release 4.12 of junit (Categories)
--

[jira] (MNG-5181) New resolution from local repository is very confusing

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

Olivier Lamy closed MNG-5181.
-

Resolution: Fixed
Fix Version/s: 3.1.0
Assignee: Olivier Lamy (was: Jason van Zyl)

New resolution from local repository is very confusing
--

[jira] (MNG-5181) New resolution from local repository is very confusing


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

Olivier Lamy commented on MNG-5181:
---

pushed 
can be desactivated using:
* new cli option: -slrm,--simple-local-repository-manager
* or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true

 New resolution from local repository is very confusing
 --

 Key: MNG-5181
 URL: https://jira.codehaus.org/browse/MNG-5181
 Project: Maven 2  3
  Issue Type: Improvement
  Components: Dependencies
Affects Versions: 3.0, 3.0.1, 3.0.2, 3.0.3
Reporter: Arnaud Heritier
Assignee: Jason van Zyl
 Fix For: 3.1.0


 I just discover the change introduced in Maven 3.x to try to improve the 
 resolution mechanism and to avoid to use a local artifact which may not be 
 available in its remote repository : 
 https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository
 Even if the feature is interesting it has several problems :
 # When an artifact isn't accessible from its remote repository it isn't used 
 by maven which replies a classical dependency not found error. It is really 
 annoying for a user with some Maven 2 skills which will have a look at his 
 local repo, will find the artifact and won't understand why Maven doesn't use 
 it. At least the error reported by Maven should be clear that even if the 
 dependency is available locally, it isn't used because it's remote repository 
 isn't available.
 # This behavior cannot be configured to be only a warning for example. It is 
 really annoying because it doesn't take care of some context and constraints 
 we may have in a development team. Let's imagine that the remote artifact is 
 really removed. Cool Maven broke the build to warn us. But it brakes the 
 build of all the team whereas perhaps only one of them may try to solve the 
 issue (and it can be a long resolution). Thus having the ability to configure 
 if this control is blocker or warning may allow the team to configure it as 
 blocker on the CI server and as warning on the development environment.
 # This behavior may introduce some bad practices for example when we are 
 using a staging feature on a repository manager. In our case my teams have a 
 dedicated profile to activate a staging repository when we are validating a 
 release. I recommend to not have this profile always activated but to do it 
 only on-demand to avoid them to DL staging stuffs they don't need. With this 
 new feature they need for all builds they run to activate this staging 
 profile while binaries are stored in it. When you have to do it 20 times per 
 day minimum let's imagine what the developer does : It adds it as an 
 alwaysActive profile and then forget to remove it when the release is ended.
 For all these reason I would like we improve this feature to make it more 
 usable and before all bet understandable for ours users.

--
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-5185) Improve missing dependency error message when _maven.repositories conflict


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

Olivier Lamy commented on MNG-5185:
---

will be available here: 
https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x/
build #368


 Improve missing dependency error message when _maven.repositories conflict
 

 Key: MNG-5185
 URL: https://jira.codehaus.org/browse/MNG-5185
 Project: Maven 2  3
  Issue Type: Improvement
Affects Versions: 3.0.2, 3.0.3, 3.0.4
Reporter: Mark Derricutt
Assignee: Olivier Lamy
 Fix For: 3.1.0

 Attachments: 
 0001-MNG-5185-Warn-about-artifacts-present-but-not-availa.patch


 Based on a discussion on the users list [1], Maven 3 has changed how it 
 resolves artifacts from custom repositories.  Unfortunately, when conflicts 
 arise ( GAV is in local repo, but POM has no matching repository id declared 
 ) Maven just tells the user that the artifact could not be resolved.
 This leads to confusion from users who find the .jar files in their local 
 repository, and they just get frustrated and complain that maven sucks.
 It would be good if Maven was updated with some improved error messages along 
 the lines of:
 The {GAV} artifact was found in your local repository, but came from the 
 undeclared repository xxx, either configure this in your pom with {insert 
 sample XML block in error message}, or in your yyy mirror.
 The mirror section of the error message should be included -if- the current 
 ~/.m2/settings.xml declares a mirror.  By improving the messages here we can 
 help the users move on to building software, rather than pulling out their 
 hair :)
 [1] 
 http://maven.40175.n5.nabble.com/Maven-3-maven-repositories-and-lastUpdated-td4927537.html

--
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-5289) -Dmaven.repo.local not honored