date:20061023

[jira] Created: (MNG-2629) Command Line argument too long

2006-10-23 Thread Manri Offermann (JIRA)

Command Line argument too long
--

 Key: MNG-2629
 URL: http://jira.codehaus.org/browse/MNG-2629
 Project: Maven 2
  Issue Type: Bug
  Components: Command Line
 Environment: XP, command prompt
Reporter: Manri Offermann
Priority: Critical


When Maven is started from command line (for example 'mvn clean compile'), the 
compile process fails, when compiling a large number of files or if working 
path name is long. Reason: "Under Windows XP, the command line is limited to 
8190 characters." (googled)

example error:

Caused by: java.io.IOException: CreateProcess: CMD.EXE /X /C javac -d 
D:\projects\wazap-core\target\main\classes -classpath 
"D:\projects\wazap-core\target\main\classes;E:\Documents and 
Settings\tsasaki\.m2\repository\objectweb\ow-monolog\2.1.1\ow-monolog-2.1.1.jar;E:\Documents
 and 
Settings\tsasaki\.m2\repository\concurrent\concurrent\1.3.4\concurrent-1.3.4.jar;E:\Documents
 and 
Settings\tsasaki\.m2\repository\struts\struts\1.1\struts-1.1.jar;E:\Documents 
and 
Settings\tsasaki\.m2\repository\aopalliance\aopalliance\1.0\aopalliance-1.0.jar;E:\Documents
 and Settings\tsasaki\.m2\repository\javax\jsp\jsp\2.0\jsp-2.0.jar;E:\Documents 
and 
Settings\tsasaki\.m2\repository\commons\commons-pool\1.2\commons-pool-1.2.jar;E:\Documents
 and Settings\tsasaki\.m2\repository\ant\ant\1.6.5\ant-1.6.5.jar;E:\Documents 
and 
Settings\tsasaki\.m2\repository\spring\spring\1.2.8\spring-1.2.8.jar;E:\Documents
 and 
Settings\tsasaki\.m2\repository\woodstox\woodstox\3.0.0\woodstox-3.0.0.jar;E:\Documents
 and Settings\tsasaki\.m2\repository\jp\co\eastbeam\eastbeam-web\1.0-SNAP?
 at java.lang.ProcessImpl.create(Native Method)
 at java.lang.ProcessImpl.(Unknown Source)
 at java.lang.ProcessImpl.start(Unknown Source)
 at java.lang.ProcessBuilder.start(Unknown Source)
 at java.lang.Runtime.exec(Unknown Source)
 at org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java:692)
 ... 16 more

-- 
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: (MAVEN-1807) SCM Parse Connection output is wrong / misleading

2006-10-23 Thread James Shute (JIRA)

SCM Parse Connection output is wrong / misleading
-

 Key: MAVEN-1807
 URL: http://jira.codehaus.org/browse/MAVEN-1807
 Project: Maven 1.x
  Issue Type: Bug
Affects Versions: 1.1-rc1
Reporter: James Shute
 Fix For: 1.1


If I do "maven scm:perform-release", and have maven.scm.url set to 
scm:cvs:pserver:anon:@cvshost:/home/source:MyModule then it works absolutely 
fine, but the scm:parse-connection goal produces some very misleading output:

scm:parse-connection:
 [echo] Using SCM method: cvs
 [echo] Using CVSROOT: :pserver:anon:@cvshost
 [echo] Using module: /home/source

This is obviously quite wrong.  Removing the : from after "anon" in the url 
(i.e. the bit that says "use a blank password") makes the output from 
scm:parse-connection correct, but then the checkout step fails (presumably 
because it's no longer tying to use a blank password)


-- 
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: (MNG-1880) Add new pre and post phases to the integration-test phase

2006-10-23 Thread Vincent Massol (JIRA)

 [ http://jira.codehaus.org/browse/MNG-1880?page=all ]

Vincent Massol closed MNG-1880.
---

Resolution: Fixed

Thanks Kenney. Yes I did implement this a long time ago and I probably missed 
this issue. I tried to look for a duplicate but couldn't so this must be the 
original issue for the pre/post it phases.

> Add new pre and post phases to the integration-test phase
> -
>
> Key: MNG-1880
> URL: http://jira.codehaus.org/browse/MNG-1880
> Project: Maven 2
>  Issue Type: Wish
>  Components: Plugins and Lifecycle
>Affects Versions: 2.0.1
>Reporter: Vincent Massol
> Assigned To: Vincent Massol
> Fix For: 2.0.5
>
>
> Here's an example:
> Imagine I want to use the cargo plugin for starting/stopping my container. I 
> need to attach the cargo:start goal to a phase and I need to do the same for 
> the cargo:stop goal. I can't do that today.
> Of course, I could modify the cargo plugin and offer some cargo:test goal 
> that would do it all. But that violates the concept of phases and reduces the 
> options for the users (note: I may still offer a cargo:test goal but I'd like 
> to user to be able to map cargo goals to phases himself too).
> This is just an example. By definition IT require a running environment so 
> there'll always be a need to set up and tear down stuff.

-- 
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: (SCM-230) mercurial plugin

2006-10-23 Thread Ryan Daum (JIRA)

[ http://jira.codehaus.org/browse/SCM-230?page=comments#action_78299 ] 

Ryan Daum commented on SCM-230:
---

Sorry for being so spammy, but I just added the above kludge to fake addition 
for empty directories.  Now the remaining problems are log and diff file format 
as mentioned by Alain above.

> mercurial plugin
> 
>
> Key: SCM-230
> URL: http://jira.codehaus.org/browse/SCM-230
> Project: Maven SCM
>  Issue Type: New Feature
>Reporter: solo turn
> Attachments: maven-scm-hg.tar.gz, maven-scm-provider-hg-0.09.tbz, 
> maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg-0.8.tbz, 
> maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg.diff.gz, 
> maven-scm-provider-hg.tgz
>
>
> it would be nice to have a mercurial source provider. and if not, it would be 
> nice to update the documentation on http://maven.apache.org/scm/ so that 
> anybody could just copy the bzr provider and make a mercurial provider out of 
> it. it should be nearly the same implementation.
> mercurial is (currently) much faster than bzr and therefor really useable.

-- 
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: (SCM-230) mercurial plugin

2006-10-23 Thread Ryan Daum (JIRA)

[ http://jira.codehaus.org/browse/SCM-230?page=comments#action_78296 ] 

Ryan Daum commented on SCM-230:
---

I have done some work and put a branch of thurner's repository up at: 

http://darksleep.com/~ryan/maven-scm-provider-hg.cgi

I made changes so that all tests but 3 pass.  One of these failures is related 
to the diff format as noted above.  

The other one, I cannot see an easy way to resolve, as it is part of the Scm 
tests packaged with Maven SCM itself.  Basically, the test tries to add an 
empty directory, then expects to see a status result saying "added" for the 
directory addition.  Hg knows nothing of directories, just the files in them, 
so the hg command returns 0 for the # of files in the status results.  The test 
then fails.  The only thing I can think to do is make the add command "lie" for 
empty directory additions, but this is so hacky I fear it.  Perhaps the CVS SCM 
plugin has some ideas I can pilfer.

> mercurial plugin
> 
>
> Key: SCM-230
> URL: http://jira.codehaus.org/browse/SCM-230
> Project: Maven SCM
>  Issue Type: New Feature
>Reporter: solo turn
> Attachments: maven-scm-hg.tar.gz, maven-scm-provider-hg-0.09.tbz, 
> maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg-0.8.tbz, 
> maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg.diff.gz, 
> maven-scm-provider-hg.tgz
>
>
> it would be nice to have a mercurial source provider. and if not, it would be 
> nice to update the documentation on http://maven.apache.org/scm/ so that 
> anybody could just copy the bzr provider and make a mercurial provider out of 
> it. it should be nearly the same implementation.
> mercurial is (currently) much faster than bzr and therefor really useable.

-- 
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-1197) Upload jsch.0.1.29 to the maven central repository

2006-10-23 Thread Antoine Levy-Lambert (JIRA)

Upload jsch.0.1.29 to the maven central repository
--

 Key: MAVENUPLOAD-1197
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1197
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Antoine Levy-Lambert
 Attachments: jsch-0.1.29-bundle.jar

Hi,

Ant 1.7.0 will soon be released and depends upon jsch 0.1.29 for the ssh and 
scp tasks.
I created an upload bundle based on the previous POM found here 
http://jira.codehaus.org/browse/MAVENUPLOAD-758 and based on the jar and source 
zips made available by jcraft.

Regards,

Antoine

-- 
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: (MSUREFIRE-177) [PATCH] make the basedir system property optional

2006-10-23 Thread Antoine Levy-Lambert (JIRA)

[PATCH] make the basedir system property optional
-

 Key: MSUREFIRE-177
 URL: http://jira.codehaus.org/browse/MSUREFIRE-177
 Project: Maven 2.x Surefire Plugin
  Issue Type: Improvement
Affects Versions: 2.3
 Environment: tested on Win2K with cygwin and JDK1.5, but this is 
indifferent.
Reporter: Antoine Levy-Lambert
 Attachments: patch.txt

I wanted to run the ant testcases using the maven-surefire-plugin (I actually 
built all the ant jars using maven).
The problem is that the plugin sets a system property basedir that ant cannot 
override. Since the BuildFileTest s are heavily dependent upon this property 
that ant normally sets to be the directory of the build file, most tests fail 
...

Here a patch adding the possibility not to set the basedir by setting a 
configuration attribute omitbasedir to true. 

The pom.xml of maven-surefile-plugin was also missing a dependency to 
surefire-api (or at least I needed to add this to build properly).

Regards,

Antoine

-- 
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: (MSUREFIRE-172) Bug into xml report generation

2006-10-23 Thread Antoine Levy-Lambert (JIRA)

[ http://jira.codehaus.org/browse/MSUREFIRE-172?page=comments#action_78288 
] 

Antoine Levy-Lambert commented on MSUREFIRE-172:


Hi,
I built maven-surefire-plugin from HEAD to run the testcases of ... ant and I 
also observed the same issue.

Regards,

Antoine

> Bug into xml report generation
> --
>
> Key: MSUREFIRE-172
> URL: http://jira.codehaus.org/browse/MSUREFIRE-172
> Project: Maven 2.x Surefire Plugin
>  Issue Type: Bug
>  Components: xml generation
> Environment: release 2.0 of maven-surfire-plugin
> mvn 2.0.4
>Reporter: Christophe Lallement
> Attachments: nick.zip, 
> TEST-deai.ft.archi.common.debug.ThreadWarningSystemTest.xml, 
> ThreadWarningSystem.java, ThreadWarningSystemTest.java
>
>
> since 2-3 weeks i have wrong information into my junit test tun (mvn test for 
> example)
> In fact, the *.txt are right, but the corresponding xml file have wrong 
> entry. i means additionnal testcase are present ninto the testcase section.
> you can find exmple in attachement (ThreadWarningSystemTest for example). You 
> can see that the error number are good (because read into the attribute of 
> the first xml tag) but in several TestSuite, we have testcase form other 
> testsuite.
> I don't know if this errors comes from maven dependancies update.
> What i am sure is: 
> 1/ a little bit of source modification into my project since this error 
> appears.
> 2/ no new maven dependancies into my project
> 3/ i use only ibilio/maven2 as repository.
> This errors can'be shown on other projet and other not ...
> I have a workaround to solve this issue but with low performance:
>  I use the option "fork per test" and the reports is right.
> Maybe a way to be investigate can be the temporaly file created by the 
> command line: 
> Forking command line: java -classpath 
> > C:\HOMEWARE\maven-2_local\org\apache\maven\surefire\surefire-api\2.0\surefire-api-2.0.jar;C:\HOMEWARE\maven-2_local\o
> > rg\codehaus\plexus\plexus-utils\1.1\plexus-utils-1.1.jar;C:\HOMEWARE\maven-2_local\org\apache\maven\surefire\surefire-booter\2.0\surefire-booter-2.0.jar
> >  or
> > g.apache.maven.surefire.booter.SurefireBooter C:\temp\surefire40840tmp 
> > C:\temp\surefire40841tmp
> Any Idea ?
> Thx
> Christophe

-- 
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: (MPPDF-57) Unable to remove cover type and version

2006-10-23 Thread Wendy Smoak (JIRA)

Unable to remove cover type and version
---

 Key: MPPDF-57
 URL: http://jira.codehaus.org/browse/MPPDF-57
 Project: maven-pdf-plugin
  Issue Type: Bug
Affects Versions: 2.5
 Environment: Maven 1.1-RC1-SNAPSHOT
Reporter: Wendy Smoak


I'm trying to remove the 'cover type' and 'cover version' (set them to 
blank/nothing.)  If I put the following in project.properties:

   maven.pdf.cover.type=
   maven.pdf.cover.version=

I get the text '-PARAM' for the cover type, and 'v1.0' for the cover version.

If I try it again with '.' for both of those properties, cover type works (just 
prints a dot) but cover version prints 'v..'.  

This seems to call for something like a 'maven.pdf.cover.version.prefix' 
property (that can be set to blank.)



-- 
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-468) ability to consistently apply a toolchain across plugins

2006-10-23 Thread John Casey (JIRA)

[ http://jira.codehaus.org/browse/MNG-468?page=comments#action_78283 ] 

John Casey commented on MNG-468:


One way to avoid locking this into the plugin api would be to make the Mojo 
interface extent ToolchainAware, then AbstractMojo could provide a default 
(empty) implementation of the methods in ToolchainAware. This allows the plugin 
API to bring in ToolchainAware from a dependency, which could also be used 
elsewhere in Maven.

> ability to consistently apply a toolchain across plugins
> 
>
> Key: MNG-468
> URL: http://jira.codehaus.org/browse/MNG-468
> Project: Maven 2
>  Issue Type: New Feature
>Reporter: Brett Porter
> Assigned To: Jason van Zyl
>Priority: Minor
> Fix For: 2.1
>
> Attachments: build.properties, project.properties
>
>
> for things like the JDK, it may be desirable to compile, jar etc. across the 
> board with a particular version of the toolchain, other than the one 
> currently executing. It would be good to be able to configure this location 
> in the settings.xml and have the plugins use it, forking the compiler, using 
> a particular runtime, and generating an appropriate manifest.
> This is likely to be relevant to other languages too.

-- 
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-468) ability to consistently apply a toolchain across plugins

2006-10-23 Thread John Casey (JIRA)

[ http://jira.codehaus.org/browse/MNG-468?page=comments#action_78282 ] 

John Casey commented on MNG-468:


I'm assuming from the comments above that we're now planning to implement 
multi-language support through the toolchain now...I'm really not sure this is 
wise, since some languages will require additional steps beyond a single-step 
compile, or possibly a rearrangement of a multi-step compile sprinkled through 
several phases. No, Jason, I don't have concrete examples...but I strongly 
suspect that's because I've stopped working with the project that required me 
to orchestrate Make-ish builds with Maven. I think adapting the Java lifecycle 
using toolchain is a bit simplistic, if that's what we're attempting here.

Beyond all that, I'd say we definitely need to provide for more than just 
plugins gaining access to the toolchain in use. For one thing, I can see it 
being useful to determine an alternative artifact resolver (or set of 
resolvers, or even derivative repository URLs) based on the language being 
used. In addition, I can easily see Wagon implementations looking at the 
toolchain to decide between a pure-java version of scp and one on the 
filesystem somewhere...that belongs here (it could be used in many places 
within the build: SCM, resolution, deployment...).



> ability to consistently apply a toolchain across plugins
> 
>
> Key: MNG-468
> URL: http://jira.codehaus.org/browse/MNG-468
> Project: Maven 2
>  Issue Type: New Feature
>Reporter: Brett Porter
> Assigned To: Jason van Zyl
>Priority: Minor
> Fix For: 2.1
>
> Attachments: build.properties, project.properties
>
>
> for things like the JDK, it may be desirable to compile, jar etc. across the 
> board with a particular version of the toolchain, other than the one 
> currently executing. It would be good to be able to configure this location 
> in the settings.xml and have the plugins use it, forking the compiler, using 
> a particular runtime, and generating an appropriate manifest.
> This is likely to be relevant to other languages too.

-- 
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: (MSITE-185) -Dproject.reporting.outputDirectory is not read

2006-10-23 Thread Kenney Westerhof (JIRA)

 [ http://jira.codehaus.org/browse/MSITE-185?page=all ]

Kenney Westerhof closed MSITE-185.
--

 Assignee: Kenney Westerhof
   Resolution: Fixed
Fix Version/s: 2.0

Fixed in revision 467170.

The expression was ${project.reporting.outputDirectory} which is always 
resolved from the (super) pom,
so commandline options don't work.

Moved the expression the 'default-value' attribute and renamed expression to 
'siteOutputDirectory'.

Tested both with -DsiteOutputDirectory=/tmp and without it (site generated in 
target/site as usual).

> -Dproject.reporting.outputDirectory is not read
> ---
>
> Key: MSITE-185
> URL: http://jira.codehaus.org/browse/MSITE-185
> Project: Maven 2.x Site Plugin
>  Issue Type: Bug
> Environment: Tried it on debian etch, windows2003 and windows xp. 
> Maven version: 2.0.4
>Reporter: Erik Drolshammer
> Assigned To: Kenney Westerhof
> Fix For: 2.0
>
>
> mvn site -Dproject.reporting.outputDirectory=/tmp and mvn site 
> -Dproject.reporting.outputDirectory=d:/tmp builds sucessfully, but nothing is 
> written to /tmp. The site is instead output to the default /target/site. The 
> output states "Build sucessfully". 
> When editing the configuration for the site-plugin in pom.xml it works just 
> fine. 

-- 
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: (MSITE-185) -Dproject.reporting.outputDirectory is not read

2006-10-23 Thread Erik Drolshammer (JIRA)

-Dproject.reporting.outputDirectory is not read
---

 Key: MSITE-185
 URL: http://jira.codehaus.org/browse/MSITE-185
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
 Environment: Tried it on debian etch, windows2003 and windows xp. 
Maven version: 2.0.4

Reporter: Erik Drolshammer


mvn site -Dproject.reporting.outputDirectory=/tmp and mvn site 
-Dproject.reporting.outputDirectory=d:/tmp builds sucessfully, but nothing is 
written to /tmp. The site is instead output to the default /target/site. The 
output states "Build sucessfully". 

When editing the configuration for the site-plugin in pom.xml it works just 
fine. 








-- 
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: (CONTINUUM-968) Tests for continuum-release fail randomly

2006-10-23 Thread Jesse McConnell (JIRA)

[ http://jira.codehaus.org/browse/CONTINUUM-968?page=comments#action_78280 
] 

Jesse McConnell commented on CONTINUUM-968:
---

Why can't the state of the files just be returned to normal after each test 
case completes and then work within the intended junit behavior?

> Tests for continuum-release fail randomly
> -
>
> Key: CONTINUUM-968
> URL: http://jira.codehaus.org/browse/CONTINUUM-968
> Project: Continuum
>  Issue Type: Test
>Affects Versions: 1.1
> Environment: tests fail for some environments and pass for others. 
> For some they fail at random
>Reporter: Philippe Faes
>Priority: Minor
> Attachments: continuum-release.diff
>
>
> The test for continuum-release fails randomly. This is because the two test 
> methods are executed in a random order (this is intended JUnit behavior), and 
> the tests alter files. 
> Solution is to restore files between tests (method setUp) and to force the 
> order of the two tests (create one test method that calls the two other 
> methods one by one).
> Patch is attached. Please verify and commit.

-- 
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: (SCM-230) mercurial plugin

2006-10-23 Thread Ryan Daum (JIRA)

[ http://jira.codehaus.org/browse/SCM-230?page=comments#action_78279 ] 

Ryan Daum commented on SCM-230:
---

I would like to assist with the development of this plugin.  I've checked out 
all the source I need, and used thurner's 0.09 tbz (with its hg repos), but 
only 2 of the unit tests pass.  Is all of Alain's work patched into that 
version?  Can somebody host an hg repository somewhere that will hold the 
mainline of this work?

> mercurial plugin
> 
>
> Key: SCM-230
> URL: http://jira.codehaus.org/browse/SCM-230
> Project: Maven SCM
>  Issue Type: New Feature
>Reporter: solo turn
> Attachments: maven-scm-hg.tar.gz, maven-scm-provider-hg-0.09.tbz, 
> maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg-0.8.tbz, 
> maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg.diff.gz, 
> maven-scm-provider-hg.tgz
>
>
> it would be nice to have a mercurial source provider. and if not, it would be 
> nice to update the documentation on http://maven.apache.org/scm/ so that 
> anybody could just copy the bzr provider and make a mercurial provider out of 
> it. it should be nearly the same implementation.
> mercurial is (currently) much faster than bzr and therefor really useable.

-- 
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-2628) (patch) If not necessary, don't extract the integration tests to $TEMP

2006-10-23 Thread Dan Fabulich (JIRA)

(patch) If not necessary, don't extract the integration tests to $TEMP
--

 Key: MNG-2628
 URL: http://jira.codehaus.org/browse/MNG-2628
 Project: Maven 2
  Issue Type: Improvement
  Components: integration tests
Reporter: Dan Fabulich
 Attachments: 467135simpleExtractResources.txt

Whenever you run the integration tests, they currently extract resources into 
$TEMP, even if the resources are already just lying around as files on the file 
system.  Under this patch, tests can use "simpleExtractResources" to force the 
ResourceExtractor to guess the proper location where the tests should be run, 
and hand back a File pointing to the resources to use.

To use this, the tests will need to be changed as well.  The tests should now 
go like this:

public void testit() throws Exception {
File testDir = ResourceExtractor.simpleExtractResources( getClass(), 
"/it");
Verifier verifier = new Verifier( testDir.getAbsolutePath() );
verifier.executeGoal( "package" );
}


-- 
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] Updated: (CONTINUUM-967) ProjectGroup Notifier: Hook Edit notifier actions and validations

2006-10-23 Thread Jesse McConnell (JIRA)

 [ http://jira.codehaus.org/browse/CONTINUUM-967?page=all ]

Jesse McConnell updated CONTINUUM-967:
--

Assignee: (was: Jesse McConnell)

thanks rahul, just ping me with the fix for the cascading error messages, you 
might need to be clearing them depending on how you have the flow for this 
working.   You might want to also double check the components.xml is getting 
created correctly for this and the per-lookup is being set correctly, that can 
cause this to happen as well.

I have applied this since it is helping in the fixing up of the dispatcher 
anyway...just add the other patch. 

I can't seem to assign this back to you either atm..I'll take a look at that in 
a bit

> ProjectGroup Notifier: Hook Edit notifier actions and validations
> -
>
> Key: CONTINUUM-967
> URL: http://jira.codehaus.org/browse/CONTINUUM-967
> Project: Continuum
>  Issue Type: Task
>Reporter: Rahul Thakur
> Attachments: CONTINUUM-967.patch
>
>


-- 
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-1880) Add new pre and post phases to the integration-test phase

2006-10-23 Thread Kenney Westerhof (JIRA)

[ http://jira.codehaus.org/browse/MNG-1880?page=comments#action_78265 ] 

Kenney Westerhof commented on MNG-1880:
---

This is applied both on trunk (2.1) and the 2.0.5 branch. Close?

> Add new pre and post phases to the integration-test phase
> -
>
> Key: MNG-1880
> URL: http://jira.codehaus.org/browse/MNG-1880
> Project: Maven 2
>  Issue Type: Wish
>  Components: Plugins and Lifecycle
>Affects Versions: 2.0.1
>Reporter: Vincent Massol
> Fix For: 2.0.5
>
>
> Here's an example:
> Imagine I want to use the cargo plugin for starting/stopping my container. I 
> need to attach the cargo:start goal to a phase and I need to do the same for 
> the cargo:stop goal. I can't do that today.
> Of course, I could modify the cargo plugin and offer some cargo:test goal 
> that would do it all. But that violates the concept of phases and reduces the 
> options for the users (note: I may still offer a cargo:test goal but I'd like 
> to user to be able to map cargo goals to phases himself too).
> This is just an example. By definition IT require a running environment so 
> there'll always be a need to set up and tear down stuff.

-- 
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-1179) openutils repo sync

2006-10-23 Thread fabrizio giustina (JIRA)

[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1179?page=comments#action_78254 ] 

fabrizio giustina commented on MAVENUPLOAD-1179:


script committed. Carlos, could you please run it? (I guess I still don't have 
the karma to do that by myself)
thanks

> openutils repo sync
> ---
>
> Key: MAVENUPLOAD-1179
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1179
> Project: maven-upload-requests
>  Issue Type: Wish
>Reporter: fabrizio giustina
>
> Could you please add the openutils repo (hosted on sourceforge) to the list 
> of repository synced directly to central?
> The repository is on the sourceforge web server, at the following dir:
> /home/groups/o/op/openutils/htdocs/repository/releases
> This repo only contains clean releases of artifacts for the openutils project 
> (no snapshots, no dependencies from other projects): 
> http://openutils.sourceforge.net/repository/releases/

-- 
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: (MCLOVER-58) Instrumentation fails on class with inner enum

2006-10-23 Thread Vincent Massol (JIRA)

[ http://jira.codehaus.org/browse/MCLOVER-58?page=comments#action_78250 ] 

Vincent Massol commented on MCLOVER-58:
---

Are you sure you've set the  property as shown on 
http://maven.apache.org/plugins/maven-clover-plugin/usage.html#Using%20Clover%20with%20different%20JDK%20versions
 ?

-Vincent

> Instrumentation fails on class with inner enum 
> ---
>
> Key: MCLOVER-58
> URL: http://jira.codehaus.org/browse/MCLOVER-58
> Project: Maven 2.x Clover Plugin
>  Issue Type: Bug
> Environment: JDK 1.5, WinXP
>Reporter: Geir Pettersen
>
> I get the following exception when i try to instrument a class that has an 
> inner enum.
> my class looks like the following:
> class Request implements Serializable {
> (...)
> // Clover instrumentation fails on this enum
> public enum Code implements Serializable {
> WRITE, TAKE, READ;
> }
> }
> ERROR: C:\Data()\Request.java:66:14:unexpected token: Code
> ERROR: Error parsing C:\Data(.)\Request.java: line 66: unexpected token: 
> Code
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Clover has failed to instrument the source files
> [INFO] 
> 
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Clover has failed to 
> instrument the source files
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:47
> 5)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:891)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:734)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:505)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav
> a:306)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
> 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:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Clover has failed 
> to instrument the source files
> at 
> org.apache.maven.plugin.clover.CloverInstrumentInternalMojo.instrumentSources(CloverInstrumentInternalMojo.ja
> va:184)
> at 
> org.apache.maven.plugin.clover.CloverInstrumentInternalMojo.execute(CloverInstrumentInternalMojo.java:147)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
> ... 20 more

-- 
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: (MWAR-9) WAR plugin should support minimal WARs for inclusion within an EAR

2006-10-23 Thread Bryan Loofbourrow (JIRA)

[ http://jira.codehaus.org/browse/MWAR-9?page=comments#action_78249 ] 

Bryan Loofbourrow commented on MWAR-9:
--

I agree that adding an ear scope seems like the most straightforward from a 
user point of view. Philosophically, it's like a variation on provided, but 
meaning "provided in the ear."  

I also agree with those who say that supporting a mixture of in-war and in-ear 
jars is essential. Some jars have to be in the war. Examples: either jstl or 
standard tag library jars (haven't narrowed it down to discover which) must be 
in the war, it appears. The same appears to apply to myfaces. Perhaps a 
consequence of loading resources with a path instead of classpath.

> WAR plugin should support minimal WARs for inclusion within an EAR
> --
>
> Key: MWAR-9
> URL: http://jira.codehaus.org/browse/MWAR-9
> Project: Maven 2.x War Plugin
>  Issue Type: Improvement
>Reporter: Mike Perham
>
> I noticed that when I build a WAR, I get a gigantic WEB-INF/lib with all my 
> deps.  This is fine for a default but maven should also support "skeleton" 
> WARs which will be packaged within an EAR.  We have EARs which package 3-4 
> WARs each and to have the deps duplicated within each WAR means we cannot 
> have shared data (since the classes are loaded within each WAR's classloader, 
> rather than by the parent EAR's classloader).  It also means 80MB EARs!  :-)
> It seems like two things need to happen:
> 1) Add a "skeleton" flag which prevents copying any dependencies to 
> WEB-INF/lib.
> 2) Instead generate a META-INF/MANIFEST.MF which has a Class-Path entry which 
> lists the relative locations of the dependencies within the parent EAR.
> Fabrice has basically the same idea written down here.  Starting with "- for 
> a War..." : 
> http://marc.theaimsgroup.com/?l=turbine-maven-user&m=112737860024530&w=2

-- 
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: (SCM-243) SVN provider reports a warning for 'X' status as unknown, but it's an external link

2006-10-23 Thread Nathan Beyer (Cerner) (JIRA)

SVN provider reports a warning for 'X' status as unknown, but it's an external
link
---

Key: SCM-243
URL: http://jira.codehaus.org/browse/SCM-243
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-svn
Affects Versions: 1.0-beta-3
Environment: Windows XP SP2, Sun JDK 1.4.2_12, Maven 2.0.4, SVN 1.4.0
Reporter: Nathan Beyer (Cerner)
Priority: Minor

When performing a 'release:prepare' on a project that contains an
'svn:externals' linked folder, the following warnings and messages are produced.

[INFO] Unknown file status: 'X'.
[WARNING] Unexpected input, the line must be at least seven characters long.
Line: ''.
[INFO] Unknown file status: 'P'.

I'm not sure what's causing the "unexpected input" and "P" message, but the "X"
message is from a folder in the project that is pulled into the working copy
via the svn:externals property [1]. This is an SVN property that's set on a
folder and makes the SVN client perform an additional "unversioned" checkout of
a URL. The externals will only exist in the working copy. When the "svn status"
is run on a project an external item is given the status "X". As such, the
status X can safely be ignored and treated as either "no modification" or
"ignored" would be.

Here's a dump of the help from svn status for more information.

C:\temp>svn help status
status (stat, st): Print the status of working copy files and directories.
usage: status [PATH...]

With no args, print only locally modified items (no network access).
With -u, add working revision and server out-of-date information.
With -v, print full revision information on every item.

The first six columns in the output are each one character wide:
First column: Says if item was added, deleted, or otherwise changed
' ' no modifications
'A' Added
'C' Conflicted
'D' Deleted
'I' Ignored
'M' Modified
'R' Replaced
'X' item is unversioned, but is used by an externals definition
'?' item is not under version control

[1]
http://svnbook.red-bean.com/nightly/en/svn.advanced.props.html#svn.advanced.props.special.externals

--
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: (CONTINUUM-969) Problem with french characters in subversion log

2006-10-23 Thread Dominique Jean-Prost (JIRA)

Problem with french characters in subversion log


 Key: CONTINUUM-969
 URL: http://jira.codehaus.org/browse/CONTINUUM-969
 Project: Continuum
  Issue Type: Bug
  Components: SCM
Affects Versions: 1.0.3
 Environment: french language
Reporter: Dominique Jean-Prost
Priority: Minor


In the changes area of the build result, the scm log doesn't deal french 
characters from subversion correctly : it shows 
correction des d?\195?\169pendances suite ?\195?\160 erreur de manip 

instead of 
correction des dépendances suite à erreur de manip 

-- 
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-212) configure checksum policty for proxied repository

2006-10-23 Thread nicolas de loof (JIRA)

configure checksum policty for proxied repository
-

 Key: MRM-212
 URL: http://jira.codehaus.org/browse/MRM-212
 Project: Archiva
  Issue Type: Improvement
  Components: remote proxy
Reporter: nicolas de loof
Priority: Minor


Some artifact on repo1.maven.org have bad checksum. This need fix, but this 
also make archiva not usable as a replacement for maven-proxy.

As maven itself allow to configure a checksum policy, a new configuration 
parameter on proxied repo would be nice.

-- 
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] Updated: (MNG-1577) dependencyManagement does not work for transitive dependencies

2006-10-23 Thread Ralph Goers (JIRA)

 [ http://jira.codehaus.org/browse/MNG-1577?page=all ]

Ralph Goers updated MNG-1577:
-

Attachment: mng1577d.patch

After digging into it it turns out I just didn't understand the results I was 
seeing. I've added a few tests to test the optional/non-optional behavior, but 
otherwise the patch is the same.  Please test this.  I'll also try to create 
the patch for trunk.

> dependencyManagement does not work for transitive dependencies
> --
>
> Key: MNG-1577
> URL: http://jira.codehaus.org/browse/MNG-1577
> Project: Maven 2
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.0
>Reporter: Joerg Schaible
> Fix For: 2.1
>
> Attachments: mng1577.patch, mng1577a.patch, mng1577b.patch, 
> mng1577c.patch, mng1577d.patch, mng1577trunk.patch
>
>
> The dependencyManagement does not work for transient dependencies. The 
> specified version is ignored.
> Use case:
> Main POM defines commons-digester-1.6 and commons-beanutils-1.7.0, A-SNAPSHOT 
> and B-SNAPSHOT
> Project A is child of Main and depends directly on commons-beanutils (version 
> inherited from Main)
> Project B is child of Main and depends directly on commons-digester (version 
> inherited from Main)
> Project C is child of Main and depends directly on A & B (versions inherited 
> from Main)
> A is compiled and tests are run using commons-beanutils-1.7.0
> B is compiled and tests are run using commons-digester-1.6 and 
> commons-beanutils-1.6, since digester is dependend on this
> C is compiled and tests are run using commons-beanutils-1.7.0
> Integration tests of B did not verify, that B is behaving as expected in this 
> scenario. B might fail with 1.7.0 and it is not even recognized.
> If I add beanutils also as direct dependency to B, it works fine, but then 
> are transitive dependency useless. It should be possible to define at least 
> in the dependencyManagement, that the versions of transient dependencies also 
> defined in the dependencyManagement have priority.
> - Jörg

-- 
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: (MECLIPSE-119) Allow custom project name for eclipse projects

2006-10-23 Thread Andrea Aime (JIRA)

[ http://jira.codehaus.org/browse/MECLIPSE-119?page=comments#action_78208 ] 

Andrea Aime commented on MECLIPSE-119:
--

This inability to customize the project is byting us (Geotools/Geoserver 
projects) as well... we do have a "main" module in both projects, and at the 
same time maven works better if you have directory name=module name (see scm 
tags handling) even having the ability to just write to the "project" 
property would be nice, it would allow for a customisation like:


   org.apache.maven.plugins
   maven-eclipse-plugin
   
   gt2-${project}
   
  

> Allow custom project name for eclipse projects
> --
>
> Key: MECLIPSE-119
> URL: http://jira.codehaus.org/browse/MECLIPSE-119
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: New Feature
>Affects Versions: 2.2
>Reporter: David Rice
> Attachments: MNG-1920-maven-eclipse-plugin.patch
>
>
> If you download 2 versions of the same artifact, or 2 artifacts with the same 
> artifactId then when you create eclipse the projects you have to load them 
> into different workspaces because the eclipse project name is the same (ie. 
> based on artifactId).  I added a parameter eclipse.projectName to allow you 
> to specify an alternate name to artifactId to get around this problem.
> Example uses:
> -Declipse.projectName='${project.artifactId}:${project.version}'
> -Declipse.projectName='${project.groupId}:${project.artifactId}:${project.version}'
> -Declipse.projectName=my-different-project-name

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

70 matches

Mail list logo