date:20080118

[
http://jira.codehaus.org/browse/MJAVADOC-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Benjamin Bentmann updated MJAVADOC-168:
---

Attachment: MJAVADOC-168.zip

Here's a test project to play with. When invoking mvn javadoc:javadoc only
the class Main makes it into the api docs. If you invoke mvn compile (where
I added an execution of the javadoc plugin), you get both Main and
GeneratedClass.

If the @execute annotation really cannot be re-added due to MJAVADOC-145, there
must at least be some doc/faq about this odd behavior. However, I currently do
not believe that @execute was the real cause of this other issue. I would
rather ask why the mojo has @phase generate-sources as annotation. The Javadoc
Plugin does not really participate in the default build cycle, its usually part
of the site lifecycle.

Regression: 2.4-SNAPSHOT does not generate docs for generates sources if run
outside a build

Key: MJAVADOC-168
URL: http://jira.codehaus.org/browse/MJAVADOC-168
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.4
Environment: Maven 2.0.8, JDK 1.5.0_12, WinXP
Reporter: Benjamin Bentmann
Attachments: MJAVADOC-168.zip

The fix applied for MJAVADOC-145 causes the plugin to loose source roots that
get created during the generate-sources build phase. I.e. if one runs
{noformat}
mvn org.apache.maven.plugins:maven-javadoc-plugin:2.3:javadoc
{noformat}
the plugin properly documents generated source code but running
{noformat}
mvn org.apache.maven.plugins:maven-javadoc-plugin:2.4-SNAPSHOT:javadoc
{noformat}
only documents the default source root src/main/java.
Usually, I would expect to have the JavadocReport mojo @execute
phase=generate-sources and the TestJavadocReport mojo to have @execute
phase=generate-test-sources (although it's kind of ugly to have the compile
phase being run in the later case).
In lack of these annotations, the plugin produces different output when run
directly from the command line or indirectly as part of build.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MNG-3367) Using a property as version number in multi project, doesnt resolve

2008-01-18 Thread Dave Casserly (JIRA)

Using a property as version number in multi project, doesnt resolve
---

 Key: MNG-3367
 URL: http://jira.codehaus.org/browse/MNG-3367
 Project: Maven 2
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 2.0.8
Reporter: Dave Casserly
 Attachments: projectA.zip

 Here is my project layout


/ProjectB---ProjectBChild
   /
ProjectA
\
 \---ProjectC---ProjectCChild


1. ProjectA pom contains a property (${snapshot.version}) that will be used for 
the version in every single project and sub project.
2. ProjectCChild has a dependency on ProjectBChild
3. If i build from ProjectA, everything runs fine and it picks up the property 
fine. 
4. However, if i try and build from ProjectC, it cant resolve the dependency of 
ProjectBChild because the property ${snapshot.version} wont resolve.!


[INFO] Using default encoding to copy filtered resources.
Downloading: 
http://repo1.maven.org/maven2/com/test/projectB/projectB/${snapshot.version}/projectB-${snapshot.version}.pom
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Failed to resolve artifact.

GroupId: com.test.projectB
ArtifactId: projectB
Version: ${snapshot.version}

Reason: Unable to download the artifact from any repository

  com.test.projectB:projectB:pom:${snapshot.version}

from the specified remote repositories:
  central (http://repo1.maven.org/maven2)



Ive attached a sample project.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MNG-3368) Printing version (-v argument) should not stop lifecycle execution

2008-01-18 Thread Paul Benedict (JIRA)

Printing version (-v argument) should not stop lifecycle execution
--

 Key: MNG-3368
 URL: http://jira.codehaus.org/browse/MNG-3368
 Project: Maven 2
  Issue Type: Bug
  Components: Bootstrap  Build, Command Line
Affects Versions: 2.0.8
Reporter: Paul Benedict


I wanted to always print the Maven version when I build, but unfortunately 
Maven immediately quits after outputting the version. This option should not 
quit when a lifecycle is also specified. Example: mvn -v install

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3367) Using a property as version number in multi project, doesnt resolve

2008-01-18 Thread Dave Casserly (JIRA)

[
http://jira.codehaus.org/browse/MNG-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120482
]

Dave Casserly commented on MNG-3367:

Oh, and it will work ok if i change the version of the parent of ProjectBChild
to the property value instead of the property reference !

So i would replace this:

parent
groupIdcom.test.projectB/groupId
artifactIdprojectB/artifactId
version${snapshot.version}/version
/parent

with this...

parent
groupIdcom.test.projectB/groupId
artifactIdprojectB/artifactId
versionSNAPSHOT_123/version
/parent

and it will work.

Using a property as version number in multi project, doesnt resolve
---

Key: MNG-3367
URL: http://jira.codehaus.org/browse/MNG-3367
Project: Maven 2
Issue Type: Bug
Components: Dependencies
Affects Versions: 2.0.8
Reporter: Dave Casserly
Attachments: projectA.zip

Here is my project layout
/ProjectB---ProjectBChild
/
ProjectA
\
\---ProjectC---ProjectCChild
1. ProjectA pom contains a property (${snapshot.version}) that will be used
for the version in every single project and sub project.
2. ProjectCChild has a dependency on ProjectBChild
3. If i build from ProjectA, everything runs fine and it picks up the
property fine.
4. However, if i try and build from ProjectC, it cant resolve the dependency
of ProjectBChild because the property ${snapshot.version} wont resolve.!
[INFO] Using default encoding to copy filtered resources.
Downloading:
http://repo1.maven.org/maven2/com/test/projectB/projectB/${snapshot.version}/projectB-${snapshot.version}.pom
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Failed to resolve artifact.
GroupId: com.test.projectB
ArtifactId: projectB
Version: ${snapshot.version}
Reason: Unable to download the artifact from any repository
com.test.projectB:projectB:pom:${snapshot.version}
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
Ive attached a sample project.

[jira] Created: (WAGON-97) Make uploading progress optional

2008-01-18 Thread Bo Conroy (JIRA)

Make uploading progress optional


 Key: WAGON-97
 URL: http://jira.codehaus.org/browse/WAGON-97
 Project: wagon
  Issue Type: Improvement
  Components: wagon-file
Reporter: Bo Conroy
Priority: Minor


We have some very large artifacts that we are creating and when we deploy them 
to the our repository, the logs fill up with messages like below.  It looks 
like for every 4K it prints out its progress.  The snippet below is just the 
start of an example, the log eventually gets about 2 lines in it just with 
upload progress.  Can a feature that disables these progess messages?  Knowing 
when it starts to deploy, and when it is completed is would be sufficient.

4/78955K
8/78955K
12/78955K
16/78955K
20/78955K
24/78955K
28/78955K
32/78955K
36/78955K
40/78955K
44/78955K
48/78955K
52/78955K
56/78955K
60/78955K
64/78955K
68/78955K
72/78955K

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MJAR-90) when maven.test.Skip is set, the test-jar artifact is empty


[ 
http://jira.codehaus.org/browse/MJAR-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120469
 ] 

nicolas de loof commented on MJAR-90:
-

See comment on MJAR-68.

There is no way (AFAIK) to avoid test-scope dependency resolution based on 
-Dmaven.test.skip=true.
You should use -Dmaven.test.skip.exec=true to compile and package test, but not 
run them.

 when maven.test.Skip is set, the test-jar artifact is empty
 ---

 Key: MJAR-90
 URL: http://jira.codehaus.org/browse/MJAR-90
 Project: Maven 2.x Jar Plugin
  Issue Type: Bug
Affects Versions: 2.2
 Environment: running any project with test-jar mojo
Reporter: nicolas de loof
Assignee: nicolas de loof
Priority: Trivial
 Fix For: 2.2


 as maven.test.skip disable test compilation, the generated test-jar is empty.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MJAR-68) multi module release fails because of test-jar


[ 
http://jira.codehaus.org/browse/MJAR-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120468
 ] 

nicolas de loof commented on MJAR-68:
-

-Dmaven.test.skip=true skips all test-related : compile test, run test, create 
test-jars ...

-Dmaven.test.skip.exec=true only skip test execution. They are still compiled 
and packaged into test-jar.

 multi module release fails because of test-jar
 --

 Key: MJAR-68
 URL: http://jira.codehaus.org/browse/MJAR-68
 Project: Maven 2.x Jar Plugin
  Issue Type: Bug
Affects Versions: 2.1
 Environment: maven 2.0.5
Reporter: Yuri Schimke

 The release plugin is failing in the prepare task
 mvn release:prepare
 seemingly because it can't find the test-jar that has just been built by the 
 previous module i.e. built within.
 Are there some examples in the wild of using the test-jar on a multi module 
 project that does releases?
 The (nasty) workaround I have for now, is to wait for the build to fail and 
 then 
 mvn install
 So the test-jar (and other artifacts) are in my local repository and then 
 continue 
 mvn release:prepare

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MJAR-68) multi module release fails because of test-jar


[ 
http://jira.codehaus.org/browse/MJAR-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120466
 ] 

Chad Lyon commented on MJAR-68:
---

clarification... to skip executing tests but still compile them the switch is 
-DskipTests=true not -Dmaven.test.execute=false

Also, my initial comment might warrant its own bug.  What do you think?

 multi module release fails because of test-jar
 --

 Key: MJAR-68
 URL: http://jira.codehaus.org/browse/MJAR-68
 Project: Maven 2.x Jar Plugin
  Issue Type: Bug
Affects Versions: 2.1
 Environment: maven 2.0.5
Reporter: Yuri Schimke

 The release plugin is failing in the prepare task
 mvn release:prepare
 seemingly because it can't find the test-jar that has just been built by the 
 previous module i.e. built within.
 Are there some examples in the wild of using the test-jar on a multi module 
 project that does releases?
 The (nasty) workaround I have for now, is to wait for the build to fail and 
 then 
 mvn install
 So the test-jar (and other artifacts) are in my local repository and then 
 continue 
 mvn release:prepare

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MJAVADOC-168) Regression: 2.4-SNAPSHOT does not generate docs for generates sources if run outside a build


[ 
http://jira.codehaus.org/browse/MJAVADOC-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120464
 ] 

Benjamin Bentmann commented on MJAVADOC-168:


The TestJavadocReport mojo has [EMAIL PROTECTED] generate-test-sources}} which 
doesn't make much sense either. I bet the original committer meant [EMAIL 
PROTECTED] phase=generate-test-sources}} instead.

 Regression: 2.4-SNAPSHOT does not generate docs for generates sources if run 
 outside a build
 

 Key: MJAVADOC-168
 URL: http://jira.codehaus.org/browse/MJAVADOC-168
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.4
 Environment: Maven 2.0.8, JDK 1.5.0_12, WinXP
Reporter: Benjamin Bentmann
 Attachments: MJAVADOC-168.zip


 The fix applied for MJAVADOC-145 causes the plugin to loose source roots that 
 get created during the generate-sources build phase. I.e. if one runs
 {noformat}
 mvn org.apache.maven.plugins:maven-javadoc-plugin:2.3:javadoc
 {noformat}
 the plugin properly documents generated source code but running
 {noformat}
 mvn org.apache.maven.plugins:maven-javadoc-plugin:2.4-SNAPSHOT:javadoc
 {noformat}
 only documents the default source root src/main/java.
 Usually, I would expect to have the JavadocReport mojo @execute 
 phase=generate-sources and the TestJavadocReport mojo to have @execute 
 phase=generate-test-sources (although it's kind of ugly to have the compile 
 phase being run in the later case).
 In lack of these annotations, the plugin produces different output when run 
 directly from the command line or indirectly as part of build.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MJAR-68) multi module release fails because of test-jar

[
http://jira.codehaus.org/browse/MJAR-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120463
]

Chad Lyon commented on MJAR-68:
---

The problem is actually in the resolution of dependencies. I have a
multi-module project. The project packages up a test JAR in the first module
in the reactor order. This JAR is needed by the tests of the other modules.
If my local repository is clean and I try to build while specifying
-Dmaven.test.skip=true then two things happen that cause the build to fail:

-The building of the test JAR is skipped because tests are skipped.
-Skipping of tests does not instruct the dependency resolver for the other
modules to NOT download the test JAR of the first module.

Thus, I must first get the test-jar packaged up and in my local repo before my
build can succeed. I can either run with tests or specify
-Dmaven.test.execute=false

I think the proper fix for this would be to fix the resolution of dependencies.
Basically, if tests are skipped then don't check for deps that are scope=test.

This problem seems to be related to MJAR-90. I bet before this fix went in
this issue didn't exist.

multi module release fails because of test-jar
--

Key: MJAR-68
URL: http://jira.codehaus.org/browse/MJAR-68
Project: Maven 2.x Jar Plugin
Issue Type: Bug
Affects Versions: 2.1
Environment: maven 2.0.5
Reporter: Yuri Schimke

The release plugin is failing in the prepare task
mvn release:prepare
seemingly because it can't find the test-jar that has just been built by the
previous module i.e. built within.
Are there some examples in the wild of using the test-jar on a multi module
project that does releases?
The (nasty) workaround I have for now, is to wait for the build to fail and
then
mvn install
So the test-jar (and other artifacts) are in my local repository and then
continue
mvn release:prepare

[jira] Created: (MAVENUPLOAD-1899) Oracle JDBC driver for JDK 1.4/1.5, v10.2.0.3.0

2008-01-18 Thread Ian Springer (JIRA)

Oracle JDBC driver for JDK 1.4/1.5, v10.2.0.3.0
---

 Key: MAVENUPLOAD-1899
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1899
 Project: maven-upload-requests
  Issue Type: Wish
Reporter: Ian Springer


Latest version of Oracle JDBC jar.

Previous version is already on the central repo: 
http://repo1.maven.org/maven2/com/oracle/ojdbc14/10.2.0.2.0/


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MAVENUPLOAD-1892) SableCC 3.2 upload

2008-01-18 Thread Paul Donohue (JIRA)


[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120455
 ] 

Paul Donohue commented on MAVENUPLOAD-1892:
---

Hmmm...  Looks like my IPS was blocking it ... but the rule that's blocking it 
should have nothing to do with http traffic ... must be a bug.  I disabled the 
rule.  You should have access now.  Sorry.

 SableCC 3.2 upload
 --

 Key: MAVENUPLOAD-1892
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1892
 Project: maven-upload-requests
  Issue Type: Improvement
Reporter: Paul Donohue

 http://psd.umd.edu/sablecc-3.2-bundle.jar
 http://www.sablecc.org/
 I am not a developer for SableCC.
 SableCC 3.1 is currently in the repository.
 SableCC 3.2 was released ~3 years ago, and is still the latest stable version 
 (the unstable version 4.0 is still under active development).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MAVENUPLOAD-1887) Upload HtmlUnit-1.14

2008-01-18 Thread Julien HENRY (JIRA)


[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120448
 ] 

Julien HENRY commented on MAVENUPLOAD-1887:
---

Hi Carlos,

Just to know: why should the pluginRepositories section be removed?

Regards

 Upload HtmlUnit-1.14
 

 Key: MAVENUPLOAD-1887
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1887
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Marc Guillemot

 http://htmlunit.sourceforge.net/tmp/htmlunit-1.14-bundle.jar
 http://htmlunit.sourceforge.net/
 http://htmlunit.sourceforge.net/team-list.html
 I'm a developer of HtmlUnit, please upload!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MJAVADOC-137) javadoc:javadoc always runs as aggregator

[
http://jira.codehaus.org/browse/MJAVADOC-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120477
]

Benjamin Bentmann commented on MJAVADOC-137:

I must confess I still could not figure out how exactly [EMAIL PROTECTED]
affects the plugin's execution, the Mojo API is quite short about this. If
there are use-cases that require this annotation, then it might be worth to
consider splitting mojos into two: one that has [EMAIL PROTECTED] and one that
has not. This way, the user can choose the appropriate mojo. The [Assembly
Plugin|http://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html]
uses this approach, too.

javadoc:javadoc always runs as aggregator
---

Key: MJAVADOC-137
URL: http://jira.codehaus.org/browse/MJAVADOC-137
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.3
Reporter: Peter Hendriks
Priority: Critical
Fix For: 2.4

In version 2.2, javadoc aggregation was configurable using the configuration
property aggregate. In version 2.3, all javadoc goals got the @aggregator
attribute added to its mojos (through a change in
org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java), and the goals now
always run aggregated regardless of the configuration setting. This breaks
our build as we require non-aggregated javadoc execution in our multi-module
poms. Please fix this so this is once again configurable and backwards
compatible with previous versions of the javadoc plug-in.

[jira] Closed: (MJAVADOC-166) javadoc:javadoc fails within site lifecycle

2008-01-18 Thread Michael Osipov (JIRA)


 [ 
http://jira.codehaus.org/browse/MJAVADOC-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed MJAVADOC-166.
---

Resolution: Cannot Reproduce

This is extremely  on. I cannot reproduce the issue on my faulty machine. 
Setting to worksforme

 javadoc:javadoc fails within site lifecycle
 ---

 Key: MJAVADOC-166
 URL: http://jira.codehaus.org/browse/MJAVADOC-166
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.3
Reporter: Michael Osipov

 I have my pom.xml configured creating a javadoc report upol site goal
 this is my project: 
 http://dev.fckeditor.net/browser/FCKeditor.Java/branches/2.4
 this is my pom.xml: 
 http://dev.fckeditor.net/browser/FCKeditor.Java/branches/2.4/pom.xml 
 (reported is commented out since it produces problems)
 console log solely running: javadoc:javadoc http://rafb.net/p/U0KqMb29.html 
 works perfectly
 the documentation of javadoc plugin says that if I include it to the 
 reporting part of my pom, it will atuomatically produce javadoc for my main 
 java stream, well this is what happends: http://rafb.net/p/7xREXc27.html
 Do you see the diffrence?
 1. It generates testdocs for some reason, too
 2. it says it can't resolve types and classes which did not happen with 
 javadoc:javadoc
 I guess, this is a bug

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3351) Release plugin throws NullPointerException when using version range for dependency

2008-01-18 Thread David Hoffer (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120535
 ] 

David Hoffer commented on MNG-3351:
---

This bug occurs with release plugin version 2.0-beta-7 as well.

 Release plugin throws NullPointerException when using version range for 
 dependency
 --

 Key: MNG-3351
 URL: http://jira.codehaus.org/browse/MNG-3351
 Project: Maven 2
  Issue Type: Bug
Affects Versions: 2.0.8
Reporter: David Hoffer
Priority: Blocker

 After upgrading to 2.0.8 I find that the release plugin throws NPE if any 
 dependency uses version range.
 I have one dependency with version range version[1.0,2.0)/version the 
 rest are test scope with fixed version.
 Here is the crash stack trace:
 java.lang.NullPointerException: version was null for 
 com.xrite:xrite-colorlib-api
 [13:42:05]: at 
 org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:362)
 [13:42:05]: at 
 org.apache.maven.artifact.DefaultArtifact.isSnapshot(DefaultArtifact.java:557)
 [13:42:05]: at 
 org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkArtifact(CheckDependencySnapshotsPhase.java:252)
 [13:42:05]: at 
 org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkProject(CheckDependencySnapshotsPhase.java:138)
 [13:42:05]: at 
 org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.execute(CheckDependencySnapshotsPhase.java:106)
 [13:42:05]: at 
 org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194)
 [13:42:05]: at 
 org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:131)
 [13:42:05]: at 
 org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:94)
 [13:42:05]: at 
 org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:127)
 [13:42:05]: at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
 [13:42:05]: at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
 [13:42:05]: at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:513)
 [13:42:05]: at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483)
 [13:42:05]: at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
 [13:42:05]: at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:228)
 [13:42:05]: at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
 [13:42:05]: at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
 [13:42:05]: at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
 [13:42:05]: at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
 [13:42:05]: at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 [13:42:05]: at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 [13:42:05]: at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 [13:42:05]: at java.lang.reflect.Method.invoke(Method.java:597)
 [13:42:05]: at 
 org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 [13:42:05]: at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 [13:42:05]: at 
 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
 [13:42:05]: at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 It seems the reason version is null is that the call to 
 selectVersionFromNewRangeIfAvailable() assumes that 
 versionRange.getRecommendedVersion() will always return non-null, else it 
 sets the version to null!  However during the release:prepare phase this is 
 not true, see the output:
 [13:42:04]: [INFO] [release:prepare]
 [13:42:04]: [INFO] Verifying that there are no local modifications...
 [13:42:04]: [INFO] Executing: svn --non-interactive status
 [13:42:04]: [INFO] Working directory: C:\BuildAgent\work\23044d751bcc9843
 [13:42:05]: [INFO] Checking dependencies and plugins for snapshots ...
 [13:42:05]: TEST!!! version=null
 [13:42:05]: TEST!!! versionRange=[1.0,2.0)
 [13:42:05]: TEST!!! getRecommendedVersion=null
 TEST!!! Lines are my test code so I could see what is going on here.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3351) Release plugin throws NullPointerException when using version range for dependency

2008-01-18 Thread Brian Fox (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120536
 ] 

Brian Fox commented on MNG-3351:


can you attach a simple pom that reproduces this crash? Putting it in the 
format of an IT would be awesome: 
http://docs.codehaus.org/display/MAVEN/Creating+a+Maven+Integration+Test

This fix appears to require a new release of Maven because the crash is in core 
code.

 Release plugin throws NullPointerException when using version range for 
 dependency
 --

 Key: MNG-3351
 URL: http://jira.codehaus.org/browse/MNG-3351
 Project: Maven 2
  Issue Type: Bug
Affects Versions: 2.0.8
Reporter: David Hoffer
Priority: Blocker

 After upgrading to 2.0.8 I find that the release plugin throws NPE if any 
 dependency uses version range.
 I have one dependency with version range version[1.0,2.0)/version the 
 rest are test scope with fixed version.
 Here is the crash stack trace:
 java.lang.NullPointerException: version was null for 
 com.xrite:xrite-colorlib-api
 [13:42:05]: at 
 org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:362)
 [13:42:05]: at 
 org.apache.maven.artifact.DefaultArtifact.isSnapshot(DefaultArtifact.java:557)
 [13:42:05]: at 
 org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkArtifact(CheckDependencySnapshotsPhase.java:252)
 [13:42:05]: at 
 org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkProject(CheckDependencySnapshotsPhase.java:138)
 [13:42:05]: at 
 org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.execute(CheckDependencySnapshotsPhase.java:106)
 [13:42:05]: at 
 org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194)
 [13:42:05]: at 
 org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:131)
 [13:42:05]: at 
 org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:94)
 [13:42:05]: at 
 org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:127)
 [13:42:05]: at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
 [13:42:05]: at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
 [13:42:05]: at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:513)
 [13:42:05]: at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483)
 [13:42:05]: at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
 [13:42:05]: at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:228)
 [13:42:05]: at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
 [13:42:05]: at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
 [13:42:05]: at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
 [13:42:05]: at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
 [13:42:05]: at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 [13:42:05]: at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 [13:42:05]: at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 [13:42:05]: at java.lang.reflect.Method.invoke(Method.java:597)
 [13:42:05]: at 
 org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 [13:42:05]: at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 [13:42:05]: at 
 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
 [13:42:05]: at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 It seems the reason version is null is that the call to 
 selectVersionFromNewRangeIfAvailable() assumes that 
 versionRange.getRecommendedVersion() will always return non-null, else it 
 sets the version to null!  However during the release:prepare phase this is 
 not true, see the output:
 [13:42:04]: [INFO] [release:prepare]
 [13:42:04]: [INFO] Verifying that there are no local modifications...
 [13:42:04]: [INFO] Executing: svn --non-interactive status
 [13:42:04]: [INFO] Working directory: C:\BuildAgent\work\23044d751bcc9843
 [13:42:05]: [INFO] Checking dependencies and plugins for snapshots ...
 [13:42:05]: TEST!!! version=null
 [13:42:05]: TEST!!! versionRange=[1.0,2.0)
 [13:42:05]: TEST!!! getRecommendedVersion=null
 TEST!!! Lines are my test code so I could see what is going on here.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:

[jira] Created: (MCHECKSTYLE-82) Clarify usage of outputDirectory parameter

Clarify usage of outputDirectory parameter
--

 Key: MCHECKSTYLE-82
 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-82
 Project: Maven 2.x Checkstyle Plugin
  Issue Type: Improvement
Affects Versions: 2.1
Reporter: Benjamin Bentmann
Priority: Trivial
 Attachments: output-directory.patch

The plugin's documentation should state that the parameter outputDirectory is 
ONLY evaluated for standalone runs of a mojo and is ignored when run during a 
site generation. Otherwise, confusion is likely.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MPMD-74) Clarify usage of outputDirectory parameter

Clarify usage of outputDirectory parameter
--

 Key: MPMD-74
 URL: http://jira.codehaus.org/browse/MPMD-74
 Project: Maven 2.x PMD Plugin
  Issue Type: Improvement
  Components: CPD, PMD
Affects Versions: 2.3
Reporter: Benjamin Bentmann
Priority: Trivial
 Attachments: output-directory.patch

The plugin's documentation should state that the parameter outputDirectory is 
ONLY evaluated for standalone runs of a mojo and is ignored when run during a 
site generation. Otherwise, confusion is likely.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MAVENUPLOAD-1897) AspectJ upload: 1.5.4 and beyond (raised by AspectJ Committer)

2008-01-18 Thread Alberty Pascal (JIRA)


[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120507
 ] 

Alberty Pascal commented on MAVENUPLOAD-1897:
-

Thanks !

 AspectJ upload: 1.5.4 and beyond (raised by AspectJ Committer)
 --

 Key: MAVENUPLOAD-1897
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1897
 Project: maven-upload-requests
  Issue Type: New Feature
Reporter: Andy Clement
Assignee: Carlos Sanchez

 Hi - I am the lead committer on AspectJ.  We've had various requests to 
 upload artifacts to maven in the past and previously members of the community 
 have kindly done it for us - but I'd like us to start doing it, and doing it 
 as part of the build/release process so they are available as soon as 
 possible after release.   I have to admit I don't know a lot about maven - 
 but I've been talking to the spring guys about how they do it.  There is 
 already a group in the maven repo called 'aspectj' with our 3 jars in it, but 
 I think it ought to more properly be called org.aspectj.  I've created an 
 area in my eclipse CVS that represents the repository that I'd like to sync 
 with maven, the root is here:
 http://dev.eclipse.org/viewcvs/index.cgi/org.aspectj/releases/repo?root=Tools_Project
 I then started writing an upload script but immediately i seem to have hit a 
 snag as dev.eclipse.org is CVS and I couldn't (from the instructions and the 
 few example scripts I looked at) identify whether CVS connections were 
 supported or if I would have to use rsync.  So I thought I would open this 
 request to see if CVS was supported or if you already had a process for 
 grabbing stuff from the eclipse servers?
 The beginnings of my script are here:
 http://dev.eclipse.org/viewcvs/index.cgi/org.aspectj/releases/org.aspectj.sh?root=Tools_Projectview=markup
 And I've also asked the eclipse webmaster if other projects are doing this, 
 and whether we support rsync on dev.eclipse.org.
 If you can possibly let me know if there is anything I can do (or if I need 
 to put the jars somewhere more easily accessible on a subversion repository) 
 - and I'll get it done and hopefully reduce the number of future requests for 
 AspectJ uploads.
 cheers,
 Andy

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MAVENUPLOAD-1897) AspectJ upload: 1.5.4 and beyond (raised by AspectJ Committer)


 [ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carlos Sanchez closed MAVENUPLOAD-1897.
---

  Assignee: Carlos Sanchez
Resolution: Fixed

uploaded and put relocation poms in old aspectj groupId

 AspectJ upload: 1.5.4 and beyond (raised by AspectJ Committer)
 --

 Key: MAVENUPLOAD-1897
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1897
 Project: maven-upload-requests
  Issue Type: New Feature
Reporter: Andy Clement
Assignee: Carlos Sanchez

 Hi - I am the lead committer on AspectJ.  We've had various requests to 
 upload artifacts to maven in the past and previously members of the community 
 have kindly done it for us - but I'd like us to start doing it, and doing it 
 as part of the build/release process so they are available as soon as 
 possible after release.   I have to admit I don't know a lot about maven - 
 but I've been talking to the spring guys about how they do it.  There is 
 already a group in the maven repo called 'aspectj' with our 3 jars in it, but 
 I think it ought to more properly be called org.aspectj.  I've created an 
 area in my eclipse CVS that represents the repository that I'd like to sync 
 with maven, the root is here:
 http://dev.eclipse.org/viewcvs/index.cgi/org.aspectj/releases/repo?root=Tools_Project
 I then started writing an upload script but immediately i seem to have hit a 
 snag as dev.eclipse.org is CVS and I couldn't (from the instructions and the 
 few example scripts I looked at) identify whether CVS connections were 
 supported or if I would have to use rsync.  So I thought I would open this 
 request to see if CVS was supported or if you already had a process for 
 grabbing stuff from the eclipse servers?
 The beginnings of my script are here:
 http://dev.eclipse.org/viewcvs/index.cgi/org.aspectj/releases/org.aspectj.sh?root=Tools_Projectview=markup
 And I've also asked the eclipse webmaster if other projects are doing this, 
 and whether we support rsync on dev.eclipse.org.
 If you can possibly let me know if there is anything I can do (or if I need 
 to put the jars somewhere more easily accessible on a subversion repository) 
 - and I'll get it done and hopefully reduce the number of future requests for 
 AspectJ uploads.
 cheers,
 Andy

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MAVENUPLOAD-1899) Oracle JDBC driver for JDK 1.4/1.5, v10.2.0.3.0


 [ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carlos Sanchez closed MAVENUPLOAD-1899.
---

  Assignee: Carlos Sanchez
Resolution: Won't Fix

Put the pom and checksums for the jar from oracle.com page, the jars can't be 
uploaded due license constraints

 Oracle JDBC driver for JDK 1.4/1.5, v10.2.0.3.0
 ---

 Key: MAVENUPLOAD-1899
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1899
 Project: maven-upload-requests
  Issue Type: Wish
Reporter: Ian Springer
Assignee: Carlos Sanchez

 Latest version of Oracle JDBC jar.
 Previous version is already on the central repo: 
 http://repo1.maven.org/maven2/com/oracle/ojdbc14/10.2.0.2.0/

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MAVENUPLOAD-1900) Validator.nu HTML parser 1.0.6 to Maven repo


 [ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carlos Sanchez closed MAVENUPLOAD-1900.
---

  Assignee: Carlos Sanchez
Resolution: Fixed

 Validator.nu HTML parser 1.0.6 to Maven repo
 

 Key: MAVENUPLOAD-1900
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1900
 Project: maven-upload-requests
  Issue Type: Improvement
Reporter: Henri Sivonen
Assignee: Carlos Sanchez

 For reference, the previous version was MAVENUPLOAD-1791.
 This version fixes a crash is character decoding buffer management, improves 
 the wording of error messages and brings character encoding-related warnings 
 up-to-date with the current HTML5 draft.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MAVENUPLOAD-1887) Upload HtmlUnit-1.14


[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120503
 ] 

Carlos Sanchez commented on MAVENUPLOAD-1887:
-

http://maven.apache.org/guides/mini/guide-central-repository-upload.html

FAQ and common mistakes

* I have other repositories or pluginRepositories listed in my pom, is that 
a problem?

  Yes, the central repo must be self contained, which means that all your 
dependencies must be already in the central repository. You need to remove the 
repositories and pluginRepositories entries and make sure your project still 
builds when your local repository cache is empty.

  The only exception allowed is when a dependency can not be distributed 
from the central repository due to the license, in that case only the pom for 
that dependency is required, listing where the dependency can be downloaded. 
See an example .


 Upload HtmlUnit-1.14
 

 Key: MAVENUPLOAD-1887
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1887
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Marc Guillemot

 http://htmlunit.sourceforge.net/tmp/htmlunit-1.14-bundle.jar
 http://htmlunit.sourceforge.net/
 http://htmlunit.sourceforge.net/team-list.html
 I'm a developer of HtmlUnit, please upload!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MAVENUPLOAD-1897) AspectJ upload: 1.5.4 and beyond (raised by AspectJ Committer)

2008-01-18 Thread Andy Clement (JIRA)


[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120501
 ] 

Andy Clement commented on MAVENUPLOAD-1897:
---

group id was changed after discussion with the spring team about what it should 
be moving forward when the process is automated.  I had heard it was 
straightforward for a forwarding system to be setup that redirected aspectj - 
org.aspectj so that the change would be picked up and nothing would break.

 AspectJ upload: 1.5.4 and beyond (raised by AspectJ Committer)
 --

 Key: MAVENUPLOAD-1897
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1897
 Project: maven-upload-requests
  Issue Type: New Feature
Reporter: Andy Clement

 Hi - I am the lead committer on AspectJ.  We've had various requests to 
 upload artifacts to maven in the past and previously members of the community 
 have kindly done it for us - but I'd like us to start doing it, and doing it 
 as part of the build/release process so they are available as soon as 
 possible after release.   I have to admit I don't know a lot about maven - 
 but I've been talking to the spring guys about how they do it.  There is 
 already a group in the maven repo called 'aspectj' with our 3 jars in it, but 
 I think it ought to more properly be called org.aspectj.  I've created an 
 area in my eclipse CVS that represents the repository that I'd like to sync 
 with maven, the root is here:
 http://dev.eclipse.org/viewcvs/index.cgi/org.aspectj/releases/repo?root=Tools_Project
 I then started writing an upload script but immediately i seem to have hit a 
 snag as dev.eclipse.org is CVS and I couldn't (from the instructions and the 
 few example scripts I looked at) identify whether CVS connections were 
 supported or if I would have to use rsync.  So I thought I would open this 
 request to see if CVS was supported or if you already had a process for 
 grabbing stuff from the eclipse servers?
 The beginnings of my script are here:
 http://dev.eclipse.org/viewcvs/index.cgi/org.aspectj/releases/org.aspectj.sh?root=Tools_Projectview=markup
 And I've also asked the eclipse webmaster if other projects are doing this, 
 and whether we support rsync on dev.eclipse.org.
 If you can possibly let me know if there is anything I can do (or if I need 
 to put the jars somewhere more easily accessible on a subversion repository) 
 - and I'll get it done and hopefully reduce the number of future requests for 
 AspectJ uploads.
 cheers,
 Andy

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MJAR-90) when maven.test.Skip is set, the test-jar artifact is empty


[ 
http://jira.codehaus.org/browse/MJAR-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120500
 ] 

nicolas de loof commented on MJAR-90:
-

A blank jar is never a good think. You will have a jar in your repo that is NOT 
what it is expected to be, and can introduce strange issues when you come back 
to your IDE. It also adds the risk to deploy an empty jar if your release goal 
includes deploy.

If you don't want to execute tests as part of the release process (I also do) 
simply set arguments-Dmaven.test.skip.exec/arguments in your POM for the 
release plugin, or maybe in a parent corporate POM.

 when maven.test.Skip is set, the test-jar artifact is empty
 ---

 Key: MJAR-90
 URL: http://jira.codehaus.org/browse/MJAR-90
 Project: Maven 2.x Jar Plugin
  Issue Type: Bug
Affects Versions: 2.2
 Environment: running any project with test-jar mojo
Reporter: nicolas de loof
Assignee: nicolas de loof
Priority: Trivial
 Fix For: 2.2


 as maven.test.skip disable test compilation, the generated test-jar is empty.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MJAR-90) when maven.test.Skip is set, the test-jar artifact is empty


[ 
http://jira.codehaus.org/browse/MJAR-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120498
 ] 

Chad Lyon commented on MJAR-90:
---

Then I think creating a blank JAR is a good thing. It will cause the dependency 
resolution to not fail when tests are skipped. Perhaps this fix should be 
rolled back.

 when maven.test.Skip is set, the test-jar artifact is empty
 ---

 Key: MJAR-90
 URL: http://jira.codehaus.org/browse/MJAR-90
 Project: Maven 2.x Jar Plugin
  Issue Type: Bug
Affects Versions: 2.2
 Environment: running any project with test-jar mojo
Reporter: nicolas de loof
Assignee: nicolas de loof
Priority: Trivial
 Fix For: 2.2


 as maven.test.skip disable test compilation, the generated test-jar is empty.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MAVENUPLOAD-1897) AspectJ upload: 1.5.4 and beyond (raised by AspectJ Committer)

2008-01-18 Thread Andy Clement (JIRA)


[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120497
 ] 

Andy Clement commented on MAVENUPLOAD-1897:
---

Ok, zipped to: 
http://www.eclipse.org/downloads/download.php?file=/tools/aspectj/dev/org.aspectj.repo.154.jar

I have been trying to get some space on our springsource servers which could be 
rsync_ssh'd too - but haven't managed it yet. 

 AspectJ upload: 1.5.4 and beyond (raised by AspectJ Committer)
 --

 Key: MAVENUPLOAD-1897
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1897
 Project: maven-upload-requests
  Issue Type: New Feature
Reporter: Andy Clement

 Hi - I am the lead committer on AspectJ.  We've had various requests to 
 upload artifacts to maven in the past and previously members of the community 
 have kindly done it for us - but I'd like us to start doing it, and doing it 
 as part of the build/release process so they are available as soon as 
 possible after release.   I have to admit I don't know a lot about maven - 
 but I've been talking to the spring guys about how they do it.  There is 
 already a group in the maven repo called 'aspectj' with our 3 jars in it, but 
 I think it ought to more properly be called org.aspectj.  I've created an 
 area in my eclipse CVS that represents the repository that I'd like to sync 
 with maven, the root is here:
 http://dev.eclipse.org/viewcvs/index.cgi/org.aspectj/releases/repo?root=Tools_Project
 I then started writing an upload script but immediately i seem to have hit a 
 snag as dev.eclipse.org is CVS and I couldn't (from the instructions and the 
 few example scripts I looked at) identify whether CVS connections were 
 supported or if I would have to use rsync.  So I thought I would open this 
 request to see if CVS was supported or if you already had a process for 
 grabbing stuff from the eclipse servers?
 The beginnings of my script are here:
 http://dev.eclipse.org/viewcvs/index.cgi/org.aspectj/releases/org.aspectj.sh?root=Tools_Projectview=markup
 And I've also asked the eclipse webmaster if other projects are doing this, 
 and whether we support rsync on dev.eclipse.org.
 If you can possibly let me know if there is anything I can do (or if I need 
 to put the jars somewhere more easily accessible on a subversion repository) 
 - and I'll get it done and hopefully reduce the number of future requests for 
 AspectJ uploads.
 cheers,
 Andy

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MJAVADOC-168) Regression: 2.4-SNAPSHOT does not generate docs for generates sources if run outside a build

Regression: 2.4-SNAPSHOT does not generate docs for generates sources if run 
outside a build


 Key: MJAVADOC-168
 URL: http://jira.codehaus.org/browse/MJAVADOC-168
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.4
 Environment: Maven 2.0.8, JDK 1.5.0_12, WinXP
Reporter: Benjamin Bentmann


The fix applied for MJAVADOC-145 causes the plugin to loose source roots that 
get created during the generate-sources build phase. I.e. if one runs
{noformat}
mvn org.apache.maven.plugins:maven-javadoc-plugin:2.3:javadoc
{noformat}
the plugin properly documents generated source code but running
{noformat}
mvn org.apache.maven.plugins:maven-javadoc-plugin:2.4-SNAPSHOT:javadoc
{noformat}
only documents the default source root src/main/java.

Usually, I would expect to have the JavadocReport mojo @execute 
phase=generate-sources and the TestJavadocReport mojo to have @execute 
phase=generate-test-sources (although it's kind of ugly to have the compile 
phase being run in the later case).

In lack of these annotations, the plugin produces different output when run 
directly from the command line or indirectly as part of build.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MAVENUPLOAD-1900) Validator.nu HTML parser 1.0.6 to Maven repo

2008-01-18 Thread Henri Sivonen (JIRA)

Validator.nu HTML parser 1.0.6 to Maven repo


 Key: MAVENUPLOAD-1900
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1900
 Project: maven-upload-requests
  Issue Type: Improvement
Reporter: Henri Sivonen


For reference, the previous version was MAVENUPLOAD-1791.

This version fixes a crash is character decoding buffer management, improves 
the wording of error messages and brings character encoding-related warnings 
up-to-date with the current HTML5 draft.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MRM-268) Archivas relocation feature should be configurable


 [ 
http://jira.codehaus.org/browse/MRM-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

nicolas de loof closed MRM-268.
---

 Assignee: nicolas de loof
   Resolution: Won't Fix
Fix Version/s: (was: 1.1)
   1.0

Relocation is only applied to maven1 request and never on POM request. It will 
only occurs for maven1 that require archiva to handle it (or they will NOT get 
the artifact), and will never occur for maven2 that allways request the POM 
before the artifact.

 Archivas relocation feature should be configurable
 --

 Key: MRM-268
 URL: http://jira.codehaus.org/browse/MRM-268
 Project: Archiva
  Issue Type: Improvement
Affects Versions: 1.0-alpha-1
Reporter: Chris Wewerka
Assignee: nicolas de loof
 Fix For: 1.0


 Archiva automatically delivers the new pom and jar for a relocated artifact 
 to a maven client.
 The downside of this feature is that clients do not get a warning that the 
 artifact is relocated anymore.
 In a All-Maven2 environment this warning is quite good, and gives the 
 developer a hint and a motivation (get rid of the warning ;-) ) to use the 
 new groupId.
 So I think it would be a good idea to make this feature configurable, so the 
 archiva admin can turn it off.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (NMAVEN-104) Support .NET Assembly Manifest

2008-01-18 Thread Pavel Znamenacek (JIRA)

Support .NET Assembly Manifest
--

 Key: NMAVEN-104
 URL: http://jira.codehaus.org/browse/NMAVEN-104
 Project: NMaven
  Issue Type: New Feature
Reporter: Pavel Znamenacek


Add support for .NET Assembly Manifest in all of its forms, single file 
assembly (usually linked into assembly .dll) and multi-file assembly (more 
important part of this improvement). See more at 
http://msdn2.microsoft.com/en-us/library/1w45z383(VS.80).aspx.
I find that all process of manifest generation could be automatic and also 
argument from life-cycles of a project via the developer inputs aka command 
line, POM, sources, profiles, etc.
This should enable NMaven to build up such assembly which has custom files 
beside such as xmls or picture files or others.
The large scaled project uses multi-file assembly often.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MAVENUPLOAD-1892) SableCC 3.2 upload


 [ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carlos Sanchez closed MAVENUPLOAD-1892.
---

  Assignee: Carlos Sanchez
Resolution: Fixed

 SableCC 3.2 upload
 --

 Key: MAVENUPLOAD-1892
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1892
 Project: maven-upload-requests
  Issue Type: Improvement
Reporter: Paul Donohue
Assignee: Carlos Sanchez

 http://psd.umd.edu/sablecc-3.2-bundle.jar
 http://www.sablecc.org/
 I am not a developer for SableCC.
 SableCC 3.1 is currently in the repository.
 SableCC 3.2 was released ~3 years ago, and is still the latest stable version 
 (the unstable version 4.0 is still under active development).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MAVENUPLOAD-1897) AspectJ upload: 1.5.4 and beyond (raised by AspectJ Committer)

2008-01-18 Thread Alberty Pascal (JIRA)


[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120499
 ] 

Alberty Pascal commented on MAVENUPLOAD-1897:
-

Andy, please note that it's preferable to NOT change the groupId for this 
release because these artifact are already used with 'aspectj' as groupId in 
the Spring 2.5.1 release !!

Thanks

 AspectJ upload: 1.5.4 and beyond (raised by AspectJ Committer)
 --

 Key: MAVENUPLOAD-1897
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1897
 Project: maven-upload-requests
  Issue Type: New Feature
Reporter: Andy Clement

 Hi - I am the lead committer on AspectJ.  We've had various requests to 
 upload artifacts to maven in the past and previously members of the community 
 have kindly done it for us - but I'd like us to start doing it, and doing it 
 as part of the build/release process so they are available as soon as 
 possible after release.   I have to admit I don't know a lot about maven - 
 but I've been talking to the spring guys about how they do it.  There is 
 already a group in the maven repo called 'aspectj' with our 3 jars in it, but 
 I think it ought to more properly be called org.aspectj.  I've created an 
 area in my eclipse CVS that represents the repository that I'd like to sync 
 with maven, the root is here:
 http://dev.eclipse.org/viewcvs/index.cgi/org.aspectj/releases/repo?root=Tools_Project
 I then started writing an upload script but immediately i seem to have hit a 
 snag as dev.eclipse.org is CVS and I couldn't (from the instructions and the 
 few example scripts I looked at) identify whether CVS connections were 
 supported or if I would have to use rsync.  So I thought I would open this 
 request to see if CVS was supported or if you already had a process for 
 grabbing stuff from the eclipse servers?
 The beginnings of my script are here:
 http://dev.eclipse.org/viewcvs/index.cgi/org.aspectj/releases/org.aspectj.sh?root=Tools_Projectview=markup
 And I've also asked the eclipse webmaster if other projects are doing this, 
 and whether we support rsync on dev.eclipse.org.
 If you can possibly let me know if there is anything I can do (or if I need 
 to put the jars somewhere more easily accessible on a subversion repository) 
 - and I'll get it done and hopefully reduce the number of future requests for 
 AspectJ uploads.
 cheers,
 Andy

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MRM-659) archiva cannot serve ejb artifacts from a maven1 repository

archiva cannot serve ejb artifacts from a maven1 repository
---

 Key: MRM-659
 URL: http://jira.codehaus.org/browse/MRM-659
 Project: Archiva
  Issue Type: Bug
  Components: remote proxy
Affects Versions: 1.0
Reporter: nicolas de loof


requesting an ejb from a maven1 repository builds the path 
groupId/jars/artifactId.jar, and not the location where maven1 ejb:deploy 
places the ejb jars (groupId/ejbs/artifactId.jar). The type folder is created 
based on the file extension, with some exceptions. It should be created based 
on the artifact type. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MJAVADOC-169) Add support for i18n

Add support for i18n


 Key: MJAVADOC-169
 URL: http://jira.codehaus.org/browse/MJAVADOC-169
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Improvement
Affects Versions: 2.3
Reporter: Benjamin Bentmann
Priority: Minor
 Attachments: i18n.patch

Good reporting plugins support i18n and this is a good report plugin, isn't it?

As for the existing mojo parameters name and description, well, we already 
talked about such non-i18n things at SUREFIRE-267.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MJAR-68) multi module release fails because of test-jar