[jira] Created: (MAVENUPLOAD-2339) rsync for new open source project duineframework.org

2009-01-23 Thread Peter Fennema (JIRA) 
rsync for new open source project duineframework.org


 Key: MAVENUPLOAD-2339
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2339
 Project: Maven Upload Requests
  Issue Type: Wish
Reporter: Peter Fennema




-- 
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: (MSHADE-30) duplicate entry error

2009-01-23 Thread Benjamin Bentmann (JIRA) 

[ 
http://jira.codehaus.org/browse/MSHADE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162140#action_162140
 ] 

Benjamin Bentmann commented on MSHADE-30:
-

bq. could you do me a favor and provide an example of said "non-sense 
" stuffs? 
Something like the following should do:
{code:xml}

  
void
void
  

{code}
i.e. a relocation that doesn't actually affect one's classes but exists merely 
to trigger another code path in the plugin.

bq. Also for me, at least, changing pom.xml to say [...] 1.2 
fixed it
Which isn't suprising given that this issue is marked as "Fix Version: 1.2" ;-)

> duplicate entry error
> -
>
> Key: MSHADE-30
> URL: http://jira.codehaus.org/browse/MSHADE-30
> Project: Maven 2.x Shade Plugin
>  Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Michael Mattox
>Assignee: Benjamin Bentmann
> Fix For: 1.2
>
> Attachments: mshade-30-patch.txt
>
>
> I receive this error:
> Embedded error: duplicate entry: org/apache/xmlbeans/FilterXmlObject.class
> It started with a javax.xml.namespace class.  So I started putting excludes, 
> and then I kept getting one new class after another.  If I exclude everything 
> then I doubt my application is going to work.
> I really don't understand this error.  I have never seen this type of error 
> with the fatjar eclipse plugin.  I understand it's complaining about having 
> the same class twice, but if it's not a problem for my eclipse project or the 
> maven build, why is it a problem for shade?
> I feel the shade plugin should be able to handle this gracefully.

-- 
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-3999) validation of Id's too restrictive

2009-01-23 Thread Sven Pressler (JIRA) 
validation of Id's too restrictive
--

 Key: MNG-3999
 URL: http://jira.codehaus.org/browse/MNG-3999
 Project: Maven 2
  Issue Type: Improvement
  Components: POM
 Environment: xp, SAP NetWeaver, maven 2.x 
Reporter: Sven Pressler
 Attachments: pom.xml

I guess the validation of the Id's were introduced after issue MNG-801.
I think the validation is too strong.
The problem is that a lot of valid filenames are not validated as true.

The problem is caused by the DefaultModelValidator: private static final String 
ID_REGEX = "[A-Za-z0-9_\\-.]+";

This regular expression is far too restrictive since something like 
"x=+%$ยง~!#^.jar" would be a valid filename on a windows operating system

I stumbled upon this because I'm developing tools for SAP NetWeaver, currently 
we still use maven 1 to build our projects but we're in the process of 
upgrading to maven 2.
maven 1 doesn't have this problem, since Id's didn't get validated like that.
Problem is SAP have a lot of libraries that have '~' in their names, like 
'tc~epbc~pcm~adminapi~java-5.x.y.jar'. Doesn't look any good, I don't like it, 
I didn't make it like that but I have to work with it.

Maybe someone can explain why it's a good idea to be that restrictive about the 
Ids, but as far as I see it, it's more like: before MNG-801 there was no 
validation, and after MNG-801 there was some validation, and until now, there 
was not too much complaining about it.

Attached is a pom which produces the following when trying to run mvn install:


Project ID: group:com~company~my~project
Validation Messages:

[0]  'artifactId' with value 'com~company~my~project' does not match a 
valid id pattern.


Reason: Failed to validate POM for project group:com~company~my~project at 
C:\test\validate\pom.xml


[INFO] 
[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: Failed to validate POM for 
project group:com~company~my~project at C:\test\validate\pom.xml
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
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:324)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.project.InvalidProjectModelException: Failed to 
validate POM for project group:com~company~my~project at 
C:\test\validate\pom.xml
at 
org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:1108)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:878)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:506)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:198)
at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:583)
at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:461)
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365)
... 11 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: (MINVOKER-76) Have invoker:run generate report files to allow reporting on the results of running invoker

2009-01-23 Thread Stephen Connolly (JIRA) 
Have invoker:run generate report files to allow reporting on the results of 
running invoker
---

 Key: MINVOKER-76
 URL: http://jira.codehaus.org/browse/MINVOKER-76
 Project: Maven 2.x Invoker Plugin
  Issue Type: Improvement
Reporter: Stephen Connolly
 Attachments: patch.diff

The attached patch will adds generation of basic XML reports for each invoker 
run.  This will allow other tools to report on the trends and the number of 
successes / failures.  If this patch gets picked up I'll have a Hudson plugin 
to read these reports and I can also write a Maven reporting plugin to 
integrate with site.

-- 
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: (ARCHETYPE-225) Add Camel archetypes to internal catalog

2009-01-23 Thread Jonathan Anstey (JIRA) 

[ 
http://jira.codehaus.org/browse/ARCHETYPE-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162160#action_162160
 ] 

Jonathan Anstey commented on ARCHETYPE-225:
---

Thanks Dan!

> Add Camel archetypes to internal catalog
> 
>
> Key: ARCHETYPE-225
> URL: http://jira.codehaus.org/browse/ARCHETYPE-225
> Project: Maven Archetype
>  Issue Type: Improvement
>  Components: Archetypes
>Reporter: Jonathan Anstey
>Assignee: Daniel Kulp
> Attachments: camel-archetypes.patch
>
>
> It would be nice if someone could add the Apache Camel archetypes to the 
> internal catalog. I've attached a patch so it would be really easy to do :)

-- 
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-3935) Get the Maven Integration Testing Hudson plugin installed on the grid

2009-01-23 Thread John Casey (JIRA) 

[ 
http://jira.codehaus.org/browse/MNG-3935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162161#action_162161
 ] 

John Casey commented on MNG-3935:
-

Where can I get this plugin? I haven't seen it.

> Get the Maven Integration Testing Hudson plugin installed on the grid
> -
>
> Key: MNG-3935
> URL: http://jira.codehaus.org/browse/MNG-3935
> Project: Maven 2
>  Issue Type: Task
>Reporter: Jason van Zyl
>Assignee: John Casey
> Fix For: 3.0-alpha-3
>
>
> I want to use this plugin to swap in new versions of Maven so I can build all 
> the real-world projects and touchstones projects. I know from testing 
> manually everything is working except Nexus Pro, but I'm ready to add XWiki 
> and CXF and this will be beyond manual tracking shortly. This needs to be 
> setup before the alpha-1 rolls out.

-- 
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: (DOXIA-279) update-dev eating properties

2009-01-23 Thread Richard Bondi (JIRA) 
update-dev eating properties


 Key: DOXIA-279
 URL: http://jira.codehaus.org/browse/DOXIA-279
 Project: Maven Doxia
  Issue Type: Bug
 Environment: OS X 10.5.x, Eclipse 3.4.0
Reporter: Richard Bondi


I had two pom editors open in eclipse. I entered a property in one, saved, 
switched to other and saved some change there. When I went back to the first 
pom, the property was gone!

This happened repeatedly.

The m2eclipse was downloaded from the update-dev site. Eclipse says it is: 
Maven POM Editor (incubation, optional) 0.9.7.200811301806.




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

maven sftp issues.

2009-01-23 Thread Tang, Ray 
Hi:
 
I am recently required to change our current ant build process to use
new host, which has only "sftp server" turned on and traditional "ftp
server" turned off.  
 
Can someone please shed some light on how I can do a maven-sftp call?
According to the maven website, I change my maven deployment to remote
binrepo from

"ftp://chiadvsdap73/datlib/advantage/sig/repository/snapshot
 " to
"sftp://nbs5u2j:2xadv103...@chiadvsdap62/datlib/advantage/sig/repository
/snapshot". The issues is that I kept on getting passwd prompt which
casuing the build doing infinite loopings on message listed below.
 
I wonder if anyone has seen this and if there is a way to get around
this issue.
 
Many Thanks.
 
Ray
 
 
Here is the code I try to do wth sftp.

  ftp://nbs5u2j:2xadv103...@chiadvsdap62/datlib/advantage/sig/repos
itory/snapshot" level="info"/>
  

 
 
 

 
  
   
 
 
 
Here is the log as the build stuck on deploying to remote binrepo server
and kept rolling...

deploy:
 [echo] Deploying foundation to remote
sftp://nbs5u2j:2xadv103...@chiadvsdap62/datlib/advantage/sig/repository/
snapshot...
Warning: Reference repo.local.id has not been set at runtime,
but was found during
build file parsing, attempting to resolve. Future versions of
Ant may support
 referencing ids defined in non-executed targets.
[artifact:deploy] Deploying to
sftp://chiadvsdap62/datlib/advantage/sig/repository/snapshot
[artifact:deploy] The authenticity of host 'chiadvsdap62' can't
be established.
[artifact:deploy] DSA key fingerprint is
6e:18:0c:a0:07:70:94:18:1e:af:10:e5:5a:35:94:96.
[artifact:deploy] Are you sure you want to continue connecting?
(yes/no): 
[artifact:deploy] The authenticity of host 'chiadvsdap62' can't
be established.
[artifact:deploy] DSA key fingerprint is
6e:18:0c:a0:07:70:94:18:1e:af:10:e5:5a:35:94:96.
[artifact:deploy] Are you sure you want to continue connecting?
(yes/no): 
[artifact:deploy] The authenticity of host 'chiadvsdap62' can't
be established.
[artifact:deploy] DSA key fingerprint is
6e:18:0c:a0:07:70:94:18:1e:af:10:e5:5a:35:94:96.
[artifact:deploy] Are you sure you want to continue connecting?
(yes/no): 
[artifact:deploy] The authenticity of host 'chiadvsdap62' can't
be established.


 
Ray
 
A.C.E.S. System Engineering
Global Markets Technology
Bank of America
233 S Wacker Dr Ste 2800
Chicago, IL 60606
(O) 312-234-3167
(C) 847-323-1964

[jira] Commented: (MRELEASE-387) command line versions don't seem to work on release:branch

2009-01-23 Thread Ryan Senior (JIRA) 

[ 
http://jira.codehaus.org/browse/MRELEASE-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162184#action_162184
 ] 

Ryan Senior commented on MRELEASE-387:
--

According to this: 
http://maven.apache.org/plugins/maven-release-plugin/examples/branch.html the 
arguments required to set working and branch versions are: 
-Dproject.rel.org.myCompany:projectA=1.2 \
 -Dproject.dev.org.myCompany:projectA=2.0-SNAPSHOT .  In looking at the 
patch above, it's adding new parameters rather than using project.rel and 
project.dev.  Is that correct?

> command line versions don't seem to work on release:branch
> --
>
> Key: MRELEASE-387
> URL: http://jira.codehaus.org/browse/MRELEASE-387
> Project: Maven 2.x Release Plugin
>  Issue Type: Bug
>  Components: branch
>Affects Versions: 2.0-beta-8
> Environment: maven 2.0.9 and 2.1.0 M1, maven release plugin 2.0-beta-8
>Reporter: Jeff Vogelsang
> Fix For: 2.0-beta-9
>
> Attachments: addSupportForVersion.patch
>
>
> I have tried all the various permutations for passing versions to the command 
> line while making a branch. The plugin ignores my parameters when running 
> release:branch. It either interactively prompts for new versions, or injects 
> the defaults if I pass parameters in batch mode.
> Here's an example of two commands I have tried running that don't work:
> mvn release:branch -DbranchName=RB-[top-level-project-name]-1.0.4 
> -DautoVersionSubmodules=true -DupdateBranchVersions=true 
> -DupdateWorkingCopyVersions=false -DdevelopmentVersion=1.0.4-SNAPSHOT
> mvn release:branch -DbranchName=RB-[top-level-project-name]-1.0.4 
> -DautoVersionSubmodules=true -DupdateBranchVersions=true 
> -DupdateWorkingCopyVersions=false -Dproject.dev.[org 
> package].[top-level-project-name]=1.0.4-SNAPSHOT
> Both of those commands prompt me for versions and no matter what parameters I 
> type use the current project revision as the default. If I do batch mode with 
> --batch or -B, the release plugin just injects the current project revision 
> into the branch and ignores my parameters.

-- 
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: (MRELEASE-407) Create branch documentation is incorrect

2009-01-23 Thread Ryan Senior (JIRA) 
Create branch documentation is incorrect


 Key: MRELEASE-407
 URL: http://jira.codehaus.org/browse/MRELEASE-407
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
  Components: documentation
Affects Versions: 2.0-beta-8
Reporter: Ryan Senior
Priority: Minor


According to this: 
http://maven.apache.org/plugins/maven-release-plugin/examples/branch.html at 
the bottom of the page -Dbranch-name needs to be specified, when it should be 
-DbranchName

-- 
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-3935) Get the Maven Integration Testing Hudson plugin installed on the grid

2009-01-23 Thread Jason van Zyl (JIRA) 

[ 
http://jira.codehaus.org/browse/MNG-3935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162191#action_162191
 ] 

Jason van Zyl commented on MNG-3935:


Talk to Tom, it's in our SVN somewhere.

> Get the Maven Integration Testing Hudson plugin installed on the grid
> -
>
> Key: MNG-3935
> URL: http://jira.codehaus.org/browse/MNG-3935
> Project: Maven 2
>  Issue Type: Task
>Reporter: Jason van Zyl
>Assignee: John Casey
> Fix For: 3.0-alpha-3
>
>
> I want to use this plugin to swap in new versions of Maven so I can build all 
> the real-world projects and touchstones projects. I know from testing 
> manually everything is working except Nexus Pro, but I'm ready to add XWiki 
> and CXF and this will be beyond manual tracking shortly. This needs to be 
> setup before the alpha-1 rolls out.

-- 
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] Issue Comment Edited: (MAVENUPLOAD-2338) Upload maven-timestamp-plugin 1.0

2009-01-23 Thread Antonio Agudo (JIRA) 

[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-2338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162134#action_162134
 ] 

Antonio Agudo edited comment on MAVENUPLOAD-2338 at 1/23/09 10:56 AM:
--

Well, to be honest, when I wrote it, buildnumber didn't have a timestamp. 
This is the first time I took a look at the thing in months.
But still, I don't like the way the configuration is implemented in 
buildnumber, too much noise. 

  was (Author: keyboardsamurai):
Well, to be honest, when I wrote it, buildnumber didn't have a timestamp. 
This is the first time I took a look at the thing in months.
But still, I don't like the way the configuration is implemented in 
buildnumber, too much noise. I can see what you mean though. If you don't want 
to add it to central because it's redundant that's fine with me.
  
> Upload maven-timestamp-plugin 1.0
> -
>
> Key: MAVENUPLOAD-2338
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2338
> Project: Maven Upload Requests
>  Issue Type: Wish
>Reporter: Antonio Agudo
>
> Please upload the maven-timestamp-plugin bundle from 
> http://keyboardsamurais.com/projects/maven-timestamp-plugin/ to central 
> repository.
> Thank you very much.

-- 
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: (SCM-344) VSS provider - implement checkin

2009-01-23 Thread Mateus Pimenta (JIRA) 

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

Mateus Pimenta updated SCM-344:
---

Attachment: maven-scm-provider-vss.patch

I've made some changes to the code to allow check in, edit, and tag commands 
and I've included a fix to process the filename when VSS include line breaks.
I've done some testing with release:prepare and release:perform and they work 
fine.


> VSS provider - implement checkin
> 
>
> Key: SCM-344
> URL: http://jira.codehaus.org/browse/SCM-344
> Project: Maven SCM
>  Issue Type: Improvement
>  Components: maven-scm-provider-vss
>Affects Versions: 1.0
> Environment: n/a
>Reporter: Allan Lang
> Attachments: maven-scm-provider-vss.patch
>
>
> Implement checkin command to enable usage with release plugin

-- 
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] Issue Comment Edited: (SCM-344) VSS provider - implement checkin

2009-01-23 Thread Mateus Pimenta (JIRA) 

[ 
http://jira.codehaus.org/browse/SCM-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162223#action_162223
 ] 

Mateus Pimenta edited comment on SCM-344 at 1/23/09 11:28 AM:
--

I've made some changes to the code to allow check in, edit, and tag commands 
and I've included a fix to process the filename when VSS includes line breaks.
I've done some testing with release:prepare and release:perform and they work 
fine.


  was (Author: matpimenta):
I've made some changes to the code to allow check in, edit, and tag 
commands and I've included a fix to process the filename when VSS include line 
breaks.
I've done some testing with release:prepare and release:perform and they work 
fine.

  
> VSS provider - implement checkin
> 
>
> Key: SCM-344
> URL: http://jira.codehaus.org/browse/SCM-344
> Project: Maven SCM
>  Issue Type: Improvement
>  Components: maven-scm-provider-vss
>Affects Versions: 1.0
> Environment: n/a
>Reporter: Allan Lang
> Attachments: maven-scm-provider-vss.patch
>
>
> Implement checkin command to enable usage with release plugin

-- 
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-2338) Upload maven-timestamp-plugin 1.0

2009-01-23 Thread Dan Tran (JIRA) 

[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-2338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162225#action_162225
 ] 

Dan Tran commented on MAVENUPLOAD-2338:
---

perhaps we can pull your mojo into build-helper-maven-plugin for those that 
cant stand the fat buildnumber-maven-plugin

> Upload maven-timestamp-plugin 1.0
> -
>
> Key: MAVENUPLOAD-2338
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2338
> Project: Maven Upload Requests
>  Issue Type: Wish
>Reporter: Antonio Agudo
>
> Please upload the maven-timestamp-plugin bundle from 
> http://keyboardsamurais.com/projects/maven-timestamp-plugin/ to central 
> repository.
> Thank you very much.

-- 
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-2338) Upload maven-timestamp-plugin 1.0

2009-01-23 Thread Antonio Agudo (JIRA) 

[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-2338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162230#action_162230
 ] 

Antonio Agudo commented on MAVENUPLOAD-2338:


Yeah, why not. If you find use for it, please do include it somewhere.

> Upload maven-timestamp-plugin 1.0
> -
>
> Key: MAVENUPLOAD-2338
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2338
> Project: Maven Upload Requests
>  Issue Type: Wish
>Reporter: Antonio Agudo
>
> Please upload the maven-timestamp-plugin bundle from 
> http://keyboardsamurais.com/projects/maven-timestamp-plugin/ to central 
> repository.
> Thank you very much.

-- 
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: (MEAR-85) ejb-client dependencies should be placed in defaultLibBundleDir

2009-01-23 Thread Bryan Loofbourrow (JIRA) 

[ 
http://jira.codehaus.org/browse/MEAR-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162238#action_162238
 ] 

Bryan Loofbourrow commented on MEAR-85:
---

Stephane, that sounds fine, assuming that the ear plugin has a nice unambiguous 
way to know that the build is targeting JEE5. The main point for me is that I'm 
even more eager to see a solution for this now than I was last May. Thanks for 
taking this up.

> ejb-client dependencies should be placed in defaultLibBundleDir
> ---
>
> Key: MEAR-85
> URL: http://jira.codehaus.org/browse/MEAR-85
> Project: Maven 2.x Ear Plugin
>  Issue Type: Improvement
>Affects Versions: 2.3.1
>Reporter: James Olsen
>Assignee: Stephane Nicoll
>Priority: Minor
> Fix For: 2.3.2
>
>
> ejb-client jars should be placed in the defaultLibBundleDir when specified.  
> They're just standard jar dependencies not J2EE artifacts so should be 
> treated the same as other jars.  They're currently being placed in the root 
> directory.
> A workaround is to add an ejbClientModule entry to override the bundleDir:
> 
>   
>   ...
>   ...
>   lib
>   
> 

-- 
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-4000) Plugin executions without id are lost when multiple executions are defined

2009-01-23 Thread Benjamin Bentmann (JIRA) 
Plugin executions without id are lost when multiple executions are defined
--

 Key: MNG-4000
 URL: http://jira.codehaus.org/browse/MNG-4000
 Project: Maven 2
  Issue Type: Bug
  Components: Plugins and Lifecycle
Affects Versions: 3.0-alpha-1
Reporter: Benjamin Bentmann


Input POM:
{code:xml}

  

  org.apache.maven.its.plugins
  maven-it-plugin-log-file
  2.1-SNAPSHOT
  
target/exec.log
exec-/string>
  
  

  exec-1
  validate
  
log-string
  


  
  validate
  
log-string
  

  

  

{code}
Effective POM:
{code:xml}

  

  org.apache.maven.its.plugins
  maven-it-plugin-log-file
  2.1-SNAPSHOT
  
target/exec.log
exec
  
  

  exec-1
  validate
  
log-string
  

  

  

{code}
Note that the execution without {{}} is missing.

-- 
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-4000) [regression] Plugin executions without id are lost when multiple executions are defined

2009-01-23 Thread Benjamin Bentmann (JIRA) 

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

Benjamin Bentmann updated MNG-4000:
---

Summary: [regression] Plugin executions without id are lost when multiple 
executions are defined  (was: Plugin executions without id are lost when 
multiple executions are defined)

> [regression] Plugin executions without id are lost when multiple executions 
> are defined
> ---
>
> Key: MNG-4000
> URL: http://jira.codehaus.org/browse/MNG-4000
> Project: Maven 2
>  Issue Type: Bug
>  Components: Plugins and Lifecycle
>Affects Versions: 3.0-alpha-1
>Reporter: Benjamin Bentmann
>
> Input POM:
> {code:xml}
> 
>   
> 
>   org.apache.maven.its.plugins
>   maven-it-plugin-log-file
>   2.1-SNAPSHOT
>   
> target/exec.log
> exec-/string>
>   
>   
> 
>   exec-1
>   validate
>   
> log-string
>   
> 
> 
>   
>   validate
>   
> log-string
>   
> 
>   
> 
>   
> 
> {code}
> Effective POM:
> {code:xml}
> 
>   
> 
>   org.apache.maven.its.plugins
>   maven-it-plugin-log-file
>   2.1-SNAPSHOT
>   
> target/exec.log
> exec
>   
>   
> 
>   exec-1
>   validate
>   
> log-string
>   
> 
>   
> 
>   
> 
> {code}
> Note that the execution without {{}} is missing.

-- 
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: (MASSEMBLY-385) Filtering replaces tokens it should not be replacing

2009-01-23 Thread Robert Bracewell (JIRA) 
Filtering replaces tokens it should not be replacing


 Key: MASSEMBLY-385
 URL: http://jira.codehaus.org/browse/MASSEMBLY-385
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-3
 Environment: Maven 2.0.9
Reporter: Robert Bracewell
Priority: Critical
 Attachments: component.zip

What is described below is attached as an example that duplicates this

When filtering is turned on and a token ends with .url then very strange things 
happen

The assembly descriptor uses
   
  
 ${basedir}/src/config/xml/applicationContext.xml
 xml
 true
  
   

The file being filtered contains:









After the assembly is run the file contains:









The string This is a not a URL but demonstrates the BUG comes from the url tag 
defined in parent pom
The string test1 is the artifactId


-- 
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: (MPMD-92) Using JDK 1.6 causes "ParseException: Can't use generics unless running in JDK 1.5 mode! " unless set targetJdk to 1.5, not 1.6

2009-01-23 Thread Benjamin Bentmann (JIRA) 

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

Benjamin Bentmann closed MPMD-92.
-

  Assignee: Benjamin Bentmann
Resolution: Not A Bug

> Using JDK 1.6 causes "ParseException: Can't use generics unless running in 
> JDK 1.5 mode! " unless set targetJdk to 1.5, not 1.6
> ---
>
> Key: MPMD-92
> URL: http://jira.codehaus.org/browse/MPMD-92
> Project: Maven 2.x PMD Plugin
>  Issue Type: Bug
>  Components: PMD
>Affects Versions: 2.4
>Reporter: Paul Sundling
>Assignee: Benjamin Bentmann
> Attachments: minimal.zip, MPMD-92.zip
>
>
> Related to http://jira.codehaus.org/browse/MPMD-67 , although they asked me 
> to open a new issue and since this affects a new version.
> This error does not appear when invoking 'mvn pmd:pmd', but only when doing 
> 'mvn site:site site:deploy'.
> It generates at least two types of warnings and related stacktraces:
>   1. Caused by: net.sourceforge.pmd.ast.ParseException: ERROR: Can't use enum 
> as a keyword in pre-JDK 1.5 target
>   2. Caused by: net.sourceforge.pmd.ast.ParseException: Can't use generics 
> unless running in JDK 1.5 mode!
> The following zip replicates the problem.
> Use JDK 1.6 and use 1.6 and it should fail, even if 
> you set the compiler to be 1.5.  Change to 1.5 and it 
> should work.

-- 
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: (MPMD-92) Using JDK 1.6 causes "ParseException: Can't use generics unless running in JDK 1.5 mode! " unless set targetJdk to 1.5, not 1.6

2009-01-23 Thread Benjamin Bentmann (JIRA) 

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

Benjamin Bentmann updated MPMD-92:
--

Attachment: MPMD-92.zip

Attached is a minimal test project that
a) produces the described warnings upon invocation of "mvn site"
b) succeeds upon invocation of "mvn pmd:pmd"

Please note that the test project is deliberately broken for the sake of 
demonstration: The version of the PMD Plugin under {{}} is locked 
down to 2.2 while {{}} specifies version 2.4. That 
illustrates the different plugin behavior originates from the use of different 
plugin versions.

The test project provided by Paul does not specify a version for the plugin 
under {{}}, hence defaults to LATEST because {{}} 
does *not* apply to reporting plugins (cf. MNG-3385).. LATEST in turn resolves 
to whatever the {{maven-metadata.xml}} in Paul's local repo has. Paul, if you 
run "mvn site -U", i.e. force a plugin update, you should see a message like
{noformat}
[INFO] artifact org.apache.maven.plugins:maven-pmd-plugin: checking for updates 
from central
{noformat}
indicating that the plugin version has not been locked down by the POM. If my 
diagnosis is wrong, please also attach a debug log of the build so that we can 
see what plugin version the build actually employs.

> Using JDK 1.6 causes "ParseException: Can't use generics unless running in 
> JDK 1.5 mode! " unless set targetJdk to 1.5, not 1.6
> ---
>
> Key: MPMD-92
> URL: http://jira.codehaus.org/browse/MPMD-92
> Project: Maven 2.x PMD Plugin
>  Issue Type: Bug
>  Components: PMD
>Affects Versions: 2.4
>Reporter: Paul Sundling
> Attachments: minimal.zip, MPMD-92.zip
>
>
> Related to http://jira.codehaus.org/browse/MPMD-67 , although they asked me 
> to open a new issue and since this affects a new version.
> This error does not appear when invoking 'mvn pmd:pmd', but only when doing 
> 'mvn site:site site:deploy'.
> It generates at least two types of warnings and related stacktraces:
>   1. Caused by: net.sourceforge.pmd.ast.ParseException: ERROR: Can't use enum 
> as a keyword in pre-JDK 1.5 target
>   2. Caused by: net.sourceforge.pmd.ast.ParseException: Can't use generics 
> unless running in JDK 1.5 mode!
> The following zip replicates the problem.
> Use JDK 1.6 and use 1.6 and it should fail, even if 
> you set the compiler to be 1.5.  Change to 1.5 and it 
> should work.

-- 
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: (MSHADE-30) duplicate entry error

2009-01-23 Thread Roger Pack (JIRA) 

[ 
http://jira.codehaus.org/browse/MSHADE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162267#action_162267
 ] 

Roger Pack commented on MSHADE-30:
--

Thanks much.

Note also that if you have a pom file with multiple submodules, and one of 
those submodules if
maven-shade-plugin version 1.0.x and others are 1.2, for some reason it "can" 
and "does" choose 1.0.x over the rest
so if you run
mvn install within the submodule it works fine
then if you run it for the entire structure, it errs with the same thing.

Fix:
change all references to the shade plugin to be 1.2, then it works.
Good luck.
-=r

> duplicate entry error
> -
>
> Key: MSHADE-30
> URL: http://jira.codehaus.org/browse/MSHADE-30
> Project: Maven 2.x Shade Plugin
>  Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Michael Mattox
>Assignee: Benjamin Bentmann
> Fix For: 1.2
>
> Attachments: mshade-30-patch.txt
>
>
> I receive this error:
> Embedded error: duplicate entry: org/apache/xmlbeans/FilterXmlObject.class
> It started with a javax.xml.namespace class.  So I started putting excludes, 
> and then I kept getting one new class after another.  If I exclude everything 
> then I doubt my application is going to work.
> I really don't understand this error.  I have never seen this type of error 
> with the fatjar eclipse plugin.  I understand it's complaining about having 
> the same class twice, but if it's not a problem for my eclipse project or the 
> maven build, why is it a problem for shade?
> I feel the shade plugin should be able to handle this gracefully.

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