[jira] Closed: (MNG-2472) set up a staging site

[Marvin King (JIRA)]

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

Marvin King closed MNG-2472.


Resolution: Fixed

> set up a staging site
> -
>
> Key: MNG-2472
> URL: http://jira.codehaus.org/browse/MNG-2472
> Project: Maven 2
>  Issue Type: Task
>  Components: Documentation:  General
>Reporter: Marvin King
> Assigned To: Marvin King
>


-- 
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-2472) set up a staging site

[Marvin King (JIRA)]

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

Marvin King updated MNG-2472:
-

Issue Type: Task  (was: Improvement)

> set up a staging site
> -
>
> Key: MNG-2472
> URL: http://jira.codehaus.org/browse/MNG-2472
> Project: Maven 2
>  Issue Type: Task
>  Components: Documentation:  General
>Reporter: Marvin King
> Assigned To: Marvin King
>


-- 
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-2472) set up a staging site

[Marvin King (JIRA)]

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

Marvin King commented on MNG-2472:
--


  found a staging area

> set up a staging site
> -
>
> Key: MNG-2472
> URL: http://jira.codehaus.org/browse/MNG-2472
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Documentation:  General
>Reporter: Marvin King
>


-- 
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-2471) Add search box to the index page

[Brett Porter (JIRA)]

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

Brett Porter commented on MNG-2471:
---

I like the separate box with no image better - can we get that one as a patch 
with the focus javascript?

> Add search box to the index page
> 
>
> Key: MNG-2471
> URL: http://jira.codehaus.org/browse/MNG-2471
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Documentation:  General
>Reporter: Marvin King
> Assigned To: Marvin King
> Attachments: index-with-focus.html, 
> index-without-logo-with-mojocodehausoption.html, index.html, 
> MNG-2471-site.patch, site-without-logo-with-mojocodehausoption.css
>
>
>   - google for now

-- 
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: (MRM-130) improve search results page

[Brett Porter (JIRA)]

 [ http://jira.codehaus.org/browse/MRM-130?page=all ]

Brett Porter updated MRM-130:
-

Remaining Estimate: 3 hours
 Original Estimate: 3 hours

we also need to keep the same search form at the top as we had originally 
(quick search or find artifact)

> improve search results page
> ---
>
> Key: MRM-130
> URL: http://jira.codehaus.org/browse/MRM-130
> Project: Maven Repository Manager
>  Issue Type: Improvement
>  Components: web application
>Reporter: Brett Porter
> Fix For: 1.0-beta-1
>
>   Original Estimate: 3 hours
>  Remaining Estimate: 3 hours
>
> currently, the search results are very plain. We should:
> - provide more information about the artifact
> - provide more information about the relevance of the result
> - provide information about how the search hit occurred (what field)
> - paginate the results

-- 
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-132) browse interface should accept URL paths

[Brett Porter (JIRA)]

 [ http://jira.codehaus.org/browse/MRM-132?page=all ]

Brett Porter closed MRM-132.


Resolution: Fixed

> browse interface should accept URL paths
> 
>
> Key: MRM-132
> URL: http://jira.codehaus.org/browse/MRM-132
> Project: Maven Repository Manager
>  Issue Type: Improvement
>Reporter: Brett Porter
> Assigned To: Brett Porter
> Fix For: 1.0-beta-1
>
>   Original Estimate: 30 minutes
>  Time Spent: 30 minutes
>  Remaining Estimate: 0 minutes
>
> currently browsing the repository uses inconvenient URLs:
> - browse.action
> - browseGroup.action?groupId=...
> - browseArtifact.action?artifactId=...&groupId=
> - showArtifact.action?artifactId=...&groupId=...&version=...
> Instead, the following paths should be used:
> /browse/[groupId[/artifactId[/version]]]

-- 
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: (MRM-132) browse interface should accept URL paths

[Brett Porter (JIRA)]

 [ http://jira.codehaus.org/browse/MRM-132?page=all ]

Brett Porter updated MRM-132:
-

Remaining Estimate: 30 minutes
 Original Estimate: 30 minutes

> browse interface should accept URL paths
> 
>
> Key: MRM-132
> URL: http://jira.codehaus.org/browse/MRM-132
> Project: Maven Repository Manager
>  Issue Type: Improvement
>Reporter: Brett Porter
> Assigned To: Brett Porter
> Fix For: 1.0-beta-1
>
>   Original Estimate: 30 minutes
>  Remaining Estimate: 30 minutes
>
> currently browsing the repository uses inconvenient URLs:
> - browse.action
> - browseGroup.action?groupId=...
> - browseArtifact.action?artifactId=...&groupId=
> - showArtifact.action?artifactId=...&groupId=...&version=...
> Instead, the following paths should be used:
> /browse/[groupId[/artifactId[/version]]]

-- 
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-2481) project builder should make the processed project cache configurable

[Brett Porter (JIRA)]

project builder should make the processed project cache configurable


 Key: MNG-2481
 URL: http://jira.codehaus.org/browse/MNG-2481
 Project: Maven 2
  Issue Type: Bug
  Components: Performance, POM
Affects Versions: 2.0.4
Reporter: Brett Porter


the cache in the project builder is a simple map. This is usually fine for 
Maven, but in long lived processes (Continuum, MRM, and I imagine the IDE 
plugins as it gets used more) it can chew up quite some memory.

I'd suggest we make it configurable:
- can turn it on or off using plexus configuration
- can limit its size using plexus configuration
- can change other options, such as adding expiry ages to items regardless of 
size

Rather than implementing something in the project builder itself, I suggest 
having a cache plexus component that does everything we need it to (this could 
be reused in the webapps as well). I'm not sure of any existing caching 
solutions (I know OSCache has a general Java cache but don't know how suitable 
it is). One alterantive might be to round out commons-cache with some features 
and plexus descriptors.

-- 
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-2481) project builder should make the processed project cache configurable

[Brett Porter (JIRA)]

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

Brett Porter commented on MNG-2481:
---

another thought - perhaps the cachability of poms that were accessed as parents 
or have been identified as dependencies could get a higher weighting since they 
are more likely to be reused later.

> project builder should make the processed project cache configurable
> 
>
> Key: MNG-2481
> URL: http://jira.codehaus.org/browse/MNG-2481
> Project: Maven 2
>  Issue Type: Bug
>  Components: POM, Performance
>Affects Versions: 2.0.4
>Reporter: Brett Porter
>
> the cache in the project builder is a simple map. This is usually fine for 
> Maven, but in long lived processes (Continuum, MRM, and I imagine the IDE 
> plugins as it gets used more) it can chew up quite some memory.
> I'd suggest we make it configurable:
> - can turn it on or off using plexus configuration
> - can limit its size using plexus configuration
> - can change other options, such as adding expiry ages to items regardless of 
> size
> Rather than implementing something in the project builder itself, I suggest 
> having a cache plexus component that does everything we need it to (this 
> could be reused in the webapps as well). I'm not sure of any existing caching 
> solutions (I know OSCache has a general Java cache but don't know how 
> suitable it is). One alterantive might be to round out commons-cache with 
> some features and plexus descriptors.

-- 
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: (MRM-142) possible memory leak

[Brett Porter (JIRA)]

 [ http://jira.codehaus.org/browse/MRM-142?page=all ]

Brett Porter updated MRM-142:
-

Fix Version/s: (was: 1.0-beta-1)

> possible memory leak
> 
>
> Key: MRM-142
> URL: http://jira.codehaus.org/browse/MRM-142
> Project: Maven Repository Manager
>  Issue Type: Bug
>  Components: indexing
>Reporter: Brett Porter
> Assigned To: Brett Porter
>   Original Estimate: 1 hour
>  Time Spent: 30 minutes
>  Remaining Estimate: 30 minutes
>
> need to investigate if there is a memory leak, since the server received an 
> OOME some time after successfully completing a full index with 1Gb heap with 
> just some browsing/searching. It is most likely in the indexing itself, but 
> there may be some in the browse/search interface 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] Updated: (MJAVADOC-81) Additional doclets do not run.

[Shinobu Kawai (JIRA)]

 [ http://jira.codehaus.org/browse/MJAVADOC-81?page=all ]

Shinobu Kawai updated MJAVADOC-81:
--

Attachment: MJAVADOC-81

Patch to expose name, description, and outputName.

Applied, I can add the following to my pom to make it work:
...

  DocCheck
  DocCheck documentation
  doccheck/index
...

> Additional doclets do not run.
> --
>
> Key: MJAVADOC-81
> URL: http://jira.codehaus.org/browse/MJAVADOC-81
> Project: Maven 2.x Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Shinobu Kawai
>Priority: Critical
> Attachments: MJAVADOC-81, pom.xml
>
>
> Although it is stated in the docs [1] that you can generate alternate doclet 
> in addition to the project javadocs, only the first reportSet is run.
> This is due to the fact that JavadocReport#getOutputName(...) returns a fixed 
> value, "apidocs/index".  This should be configurable per reportSet.
> [1] http://maven.apache.org/plugins/maven-javadoc-plugin/configuration.html

-- 
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: (MJAVADOC-81) Additional doclets do not run.

[Shinobu Kawai (JIRA)]

 [ http://jira.codehaus.org/browse/MJAVADOC-81?page=all ]

Shinobu Kawai updated MJAVADOC-81:
--

Attachment: pom.xml

The pom that doesn't work.

I get the following in the log:
[INFO] Skipped "JavaDocs" report, file "apidocs/index.html" already exists for 
the English version.


> Additional doclets do not run.
> --
>
> Key: MJAVADOC-81
> URL: http://jira.codehaus.org/browse/MJAVADOC-81
> Project: Maven 2.x Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Shinobu Kawai
>Priority: Critical
> Attachments: pom.xml
>
>
> Although it is stated in the docs [1] that you can generate alternate doclet 
> in addition to the project javadocs, only the first reportSet is run.
> This is due to the fact that JavadocReport#getOutputName(...) returns a fixed 
> value, "apidocs/index".  This should be configurable per reportSet.
> [1] http://maven.apache.org/plugins/maven-javadoc-plugin/configuration.html

-- 
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-42) Update the mojo archetype to be compliant with the plugin documentation standard

[Edwin Punzalan (JIRA)]

[ http://jira.codehaus.org/browse/ARCHETYPE-42?page=comments#action_71454 ] 

Edwin Punzalan commented on ARCHETYPE-42:
-

I've just found out that I have commit access in archetypes...

I'm not committing this bec I don't know if the plugin-parent of the apache 
plugins should be setup as its parent too?

This needs some work also as its a bit outdated against the plugin 
documentation standards.

> Update the mojo archetype to be compliant with the plugin documentation 
> standard
> 
>
> Key: ARCHETYPE-42
> URL: http://jira.codehaus.org/browse/ARCHETYPE-42
> Project: Maven Archetype
>  Issue Type: Task
>  Components: Archetypes
>Reporter: Edwin Punzalan
> Assigned To: Edwin Punzalan
> Attachments: ARCHETYPE-42-maven-archetype-mojo.patch
>
>   Original Estimate: 4 hours
>  Time Spent: 3 hours
>  Remaining Estimate: 0 minutes
>


-- 
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: (MRM-142) possible memory leak

[Brett Porter (JIRA)]

[ http://jira.codehaus.org/browse/MRM-142?page=comments#action_71447 ] 

Brett Porter commented on MRM-142:
--

the comment above seems a bit misleading. reading the files/classes inside a 
JAR is not time consuming. Indexing data (both jars and poms) is the most, 
followed by checksumming jars and by reading POMs (as the breakdown indicates)

> possible memory leak
> 
>
> Key: MRM-142
> URL: http://jira.codehaus.org/browse/MRM-142
> Project: Maven Repository Manager
>  Issue Type: Bug
>  Components: indexing
>Reporter: Brett Porter
> Assigned To: Brett Porter
> Fix For: 1.0-beta-1
>
>   Original Estimate: 1 hour
>  Time Spent: 30 minutes
>  Remaining Estimate: 30 minutes
>
> need to investigate if there is a memory leak, since the server received an 
> OOME some time after successfully completing a full index with 1Gb heap with 
> just some browsing/searching. It is most likely in the indexing itself, but 
> there may be some in the browse/search interface 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: (MJAVADOC-81) Additional doclets do not run.

[Wendy Smoak (JIRA)]

[ http://jira.codehaus.org/browse/MJAVADOC-81?page=comments#action_71448 ] 

Wendy Smoak commented on MJAVADOC-81:
-

Can you post the config that is not working?  

I was able to run the UmlGraph doclet in addition to the normal Javadoc doclet 
by:
   1. assigning an  to each 
   2. Using  to direct the output of the second doclet somewhere else.



> Additional doclets do not run.
> --
>
> Key: MJAVADOC-81
> URL: http://jira.codehaus.org/browse/MJAVADOC-81
> Project: Maven 2.x Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Shinobu Kawai
>Priority: Critical
>
> Although it is stated in the docs [1] that you can generate alternate doclet 
> in addition to the project javadocs, only the first reportSet is run.
> This is due to the fact that JavadocReport#getOutputName(...) returns a fixed 
> value, "apidocs/index".  This should be configurable per reportSet.
> [1] http://maven.apache.org/plugins/maven-javadoc-plugin/configuration.html

-- 
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-81) Additional doclets do not run.

[Shinobu Kawai (JIRA)]

Additional doclets do not run.
--

 Key: MJAVADOC-81
 URL: http://jira.codehaus.org/browse/MJAVADOC-81
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.0
Reporter: Shinobu Kawai
Priority: Critical


Although it is stated in the docs [1] that you can generate alternate doclet in 
addition to the project javadocs, only the first reportSet is run.

This is due to the fact that JavadocReport#getOutputName(...) returns a fixed 
value, "apidocs/index".  This should be configurable per reportSet.

[1] http://maven.apache.org/plugins/maven-javadoc-plugin/configuration.html

-- 
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: (MRM-142) possible memory leak

[Brett Porter (JIRA)]

[ http://jira.codehaus.org/browse/MRM-142?page=comments#action_71445 ] 

Brett Porter commented on MRM-142:
--

did some performance analysis while I was there. It appears that indexing the 
JAR files is not the time consuming operation, but rather the indexing, 
checksumming and reading the POMs:

discovery: 7% (mostly the directory scanner - a total of 6%)
indexing records: 53%
reading records: 32%

Breaking down the last one:
reading pom: 16%
reading checksum: 14%

Breaking down reading the POM:
resolving: 3% (these are all local)
building: 13%

Breaking down building:
interpolation: 5%

This was with no existing index. It may be more skewed towards indexing if it 
has to delete all the records as it goes.


> possible memory leak
> 
>
> Key: MRM-142
> URL: http://jira.codehaus.org/browse/MRM-142
> Project: Maven Repository Manager
>  Issue Type: Bug
>  Components: indexing
>Reporter: Brett Porter
> Assigned To: Brett Porter
> Fix For: 1.0-beta-1
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> need to investigate if there is a memory leak, since the server received an 
> OOME some time after successfully completing a full index with 1Gb heap with 
> just some browsing/searching. It is most likely in the indexing itself, but 
> there may be some in the browse/search interface 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: (MRM-142) possible memory leak

[Brett Porter (JIRA)]

[ http://jira.codehaus.org/browse/MRM-142?page=comments#action_71442 ] 

Brett Porter commented on MRM-142:
--

this simply seems to be the size of the processedProjectCache in the project 
builder. We should probably restrict the size of that in general, but for the 
MRM we should flush it whenever the index is (for now, just at the end will do)

> possible memory leak
> 
>
> Key: MRM-142
> URL: http://jira.codehaus.org/browse/MRM-142
> Project: Maven Repository Manager
>  Issue Type: Bug
>  Components: indexing
>Reporter: Brett Porter
> Assigned To: Brett Porter
> Fix For: 1.0-beta-1
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> need to investigate if there is a memory leak, since the server received an 
> OOME some time after successfully completing a full index with 1Gb heap with 
> just some browsing/searching. It is most likely in the indexing itself, but 
> there may be some in the browse/search interface 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] Updated: (MRM-142) possible memory leak

[Brett Porter (JIRA)]

 [ http://jira.codehaus.org/browse/MRM-142?page=all ]

Brett Porter updated MRM-142:
-

Remaining Estimate: 1 hour
 Original Estimate: 1 hour

> possible memory leak
> 
>
> Key: MRM-142
> URL: http://jira.codehaus.org/browse/MRM-142
> Project: Maven Repository Manager
>  Issue Type: Bug
>  Components: indexing
>Reporter: Brett Porter
> Fix For: 1.0-beta-1
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> need to investigate if there is a memory leak, since the server received an 
> OOME some time after successfully completing a full index with 1Gb heap with 
> just some browsing/searching. It is most likely in the indexing itself, but 
> there may be some in the browse/search interface 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: (MAVEN-1768) wrong directory structure in src distribution package (maven-dist-plugin-1.7)

[Lukas Theussl (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-1768?page=all ]

Lukas Theussl closed MAVEN-1768.


Resolution: Won't Fix

It's not necessary to open the same issue again under another project as we can 
just move it there.

> wrong directory structure in src distribution package (maven-dist-plugin-1.7)
> -
>
> Key: MAVEN-1768
> URL: http://jira.codehaus.org/browse/MAVEN-1768
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.1-beta-2
>Reporter: Jarkko Viinamäki
>
> With Maven 1.1-beta-2 and maven-dist-plugin-1.7:
> if my project.xml defines:
>   
> src/main/java
> ...
> Then the dist:build-src target generates an incorrect src distribution file 
> since the source files are packaged to path src/foo/bar/MyClass.java instead 
> of src/main/java/foo/bar/MyClass.java
> --
> To fix this, change the dist:prepare-src-filesystem goal in 
> maven-dist-plugin-1.7 to read:
> 
>   
> 
>   
> 
> This will preserve the actual directory structure.

-- 
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-1028) Upload Joda-Time 1.3

[Stephen Colebourne (JIRA)]

Upload Joda-Time 1.3


 Key: MAVENUPLOAD-1028
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1028
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Stephen Colebourne


http://joda-time.sourceforge.net/joda-time-1.3-bundle.jar
  
http://joda-time.sourceforge.net
http://joda-time.sourceforge.net/team-list.html
  
Please upload joda-time 1.3


-- 
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-31) add ability to configure JBoss-specific deployment options in plugin configuration that will result in a jboss-app.xml descriptor being generated

[Stephane Nicoll (JIRA)]

[ http://jira.codehaus.org/browse/MEAR-31?page=comments#action_71439 ] 

Stephane Nicoll commented on MEAR-31:
-

jboss app is now generated. I need to bind it to the lifecycle + disable 
application.xml inclusion as a connector when it makes sense.

> add ability to configure JBoss-specific deployment options in plugin 
> configuration that will result in a jboss-app.xml descriptor being generated
> -
>
> Key: MEAR-31
> URL: http://jira.codehaus.org/browse/MEAR-31
> Project: Maven 2.x Ear Plugin
>  Issue Type: New Feature
>Affects Versions: 2.2
>Reporter: Ian Springer
> Assigned To: Stephane Nicoll
> Fix For: 2.3
>
>
> The correct way to configure a SAR bundled in an EAR is not via a connector 
> module, but by adding a service module entry in META-INF/jboss-app.xml, e.g.:
>  "http://www.jboss.org/j2ee/dtd/jboss-app_4_0.dtd";>
> 
> 
> my.sar
> 
> 
> This tells JBoss to load the JBoss service from the file my.sar located in 
> the root directory of the EAR.
> I suggest adding a JBoss-specfic section in the EAR plugin's configuration 
> for configuring stuff that needs to be written to jboss-app.xml, e.g.:
> 
>   
> 4
> ...
>   
> 
> The jbossVersion would tell the plugin which version of JBoss is being 
> targeted, which would determine the docType of the file (a bunch of new 
> elements were added in JBoss 4.x - for example, the ability to deploy 
> Hibernate archives (HARs). We could sgtart out with just the ability to 
> deploy SARs and perhaps HARs and eventually add support for the other items 
> in jboss-app.xml.

-- 
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: (MEV-426) Quartz 1.5.2 missing pom and jar. Has source.

[Lee Meador (JIRA)]

 [ http://jira.codehaus.org/browse/MEV-426?page=all ]

Lee Meador updated MEV-426:
---

Attachment: pom.xml

I seem to have lost a couple of optional true lines in the previous version. 
Now they are in the pom.

> Quartz 1.5.2 missing pom and jar. Has source.
> -
>
> Key: MEV-426
> URL: http://jira.codehaus.org/browse/MEV-426
> Project: Maven Evangelism
>  Issue Type: Improvement
>Reporter: Lee Meador
> Attachments: maven-repo-quartz-1.5.2.zip, pom.xml, pom.xml
>
>
> The pom and jar are missing but the source jar, etc are there. Quartz 1.5.1 
> has a pom with no dependencies. The supplied file has a pom with all the 
> dependencies needed to compile quartz EXCEPT ejb.jar and servlet.jar (or 
> servlet-api.jar) JTA and MAIL are marked optional. The others are things like 
> beanutils and such that are already in the repository.
> Here's what I did:
> 1) Download 1.5.2 from http://www.opensymphony.com/quartz/download.action
> 2) Unzip and take the jar from the lib directory of what unzipped..
> 3) Build an Eclipse project with a the maven 2 plugin, using the maven layout.
> 4) Copy all the unzipped source into src/main/java from the src/java 
> directory of what unzipped.
> 5) Create a pom by turning on the maven2 eclipse plugin for the project.
> 5) Add dependencies to the pom based on what wouldn't compile in eclipse.
> 6) Repeat step 5 and building with mvn compile until there were no errors.
> Then I copied the pom to quartz-1.5.2.pom and edited it a bit more:
> 1) I removed ejb.jar and servlet.jar since I figured those would be around if 
> needed in quartz.
> 2) I added true to jta and java mail since those jars 
> are Sun's and aren't in the repo
> 3) I added runtime to everything else.
> That is what I am sending you. 

-- 
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-2479) add support for optional 'packagingName' element in dependency blocks

[Ian Springer (JIRA)]

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

Ian Springer commented on MNG-2479:
---

Hmm, I'm not sure I agree with this. If it was desired to override the default 
filename for transitive deps, this could be achieved by explicitly declaring 
the transitive deps in the J2EE pom. In your example, W's pom could explicitly 
declare A, in addition to B, in order to specify packaging names for both.  The 
same thing would basically be true for plugin-by-plugin defined configuration 
schemes. That is, transitive artifacts would only need to be explicitly defined 
if you needed to override the packaging name or some other setting specific to 
that artifact. For me, one of the biggest pros of Maven is consistency in how 
things are done. By not having a central way of specifying packaging filenames 
(and packaging target directories), you end up with ten different plugins doing 
it ten different ways, or not doing it at all.


> add support for optional 'packagingName' element in dependency blocks
> -
>
> Key: MNG-2479
> URL: http://jira.codehaus.org/browse/MNG-2479
> Project: Maven 2
>  Issue Type: New Feature
>  Components: Dependencies
>Affects Versions: 2.0.4
>Reporter: Ian Springer
> Assigned To: Brett Porter
>
> The various deployment artifact types (war, ear, sar, etc.) package their 
> dependencies within the target archive during the package phase. For example, 
> the war plugin includes jar dependencies within WEB-INF/lib, and the ear 
> plugin includes jar and J2EE dependencies at the top level. Sometimes it is 
> not desirable to package the dependencies with their full Maven-repo-style 
> names (i.e. artifactName-version.xar). In particular, the version component 
> is often not desired. Currently, some plugins provide a way to rename these 
> dependency artifacts when they are packaged (e.g. the ear plugin), and others 
> do not (e.g. the war plugin), making it necessary to use an antrun or 
> dependency plugin hack to rename the artifacts as desired. I think it would 
> be much nicer if there was a standard way to specify a "packaging name" (or 
> whatever other name makes sense) for a dependency in its dependency block in 
> the pom. Then all plugins that package their dependencies could leverage this 
> standard setting. 
> Here is an example of a war dependency declared in an ear pom:
> 
>   org.jboss.on
>   on-enterprise-gui-portal
>   2.0-SNAPSHOT
>   war
>   on-portal
> 
> This would cause the war to be bundled in the ear with the filename 
> "on-portal.war", instead of the default 
> on-enterprise-gui-portal-2.0-SNAPSHOT.war.

-- 
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-2479) add support for optional 'packagingName' element in dependency blocks

[Brett Porter (JIRA)]

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

Brett Porter closed MNG-2479.
-

  Assignee: Brett Porter
Resolution: Won't Fix

this should be available as plugin configuration for the various packaging 
plugins already - if not it should be requested for each, both on an artifact 
by artifact basis and to be able to map all names using a mapper. A generic 
solution in the dependency element is not desired since it will not work with 
transitive dependencies (W, a WAR depends on B with depends on A - B's 
dependency on A doesn't know to specify this element because it doesn't know it 
will later be used in a WAR).

> add support for optional 'packagingName' element in dependency blocks
> -
>
> Key: MNG-2479
> URL: http://jira.codehaus.org/browse/MNG-2479
> Project: Maven 2
>  Issue Type: New Feature
>  Components: Dependencies
>Affects Versions: 2.0.4
>Reporter: Ian Springer
> Assigned To: Brett Porter
>
> The various deployment artifact types (war, ear, sar, etc.) package their 
> dependencies within the target archive during the package phase. For example, 
> the war plugin includes jar dependencies within WEB-INF/lib, and the ear 
> plugin includes jar and J2EE dependencies at the top level. Sometimes it is 
> not desirable to package the dependencies with their full Maven-repo-style 
> names (i.e. artifactName-version.xar). In particular, the version component 
> is often not desired. Currently, some plugins provide a way to rename these 
> dependency artifacts when they are packaged (e.g. the ear plugin), and others 
> do not (e.g. the war plugin), making it necessary to use an antrun or 
> dependency plugin hack to rename the artifacts as desired. I think it would 
> be much nicer if there was a standard way to specify a "packaging name" (or 
> whatever other name makes sense) for a dependency in its dependency block in 
> the pom. Then all plugins that package their dependencies could leverage this 
> standard setting. 
> Here is an example of a war dependency declared in an ear pom:
> 
>   org.jboss.on
>   on-enterprise-gui-portal
>   2.0-SNAPSHOT
>   war
>   on-portal
> 
> This would cause the war to be bundled in the ear with the filename 
> "on-portal.war", instead of the default 
> on-enterprise-gui-portal-2.0-SNAPSHOT.war.

-- 
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: (MRELEASE-122) Versionless Extension causes NullPointerException in release:prepare

[Matthew Beermann (JIRA)]

 [ http://jira.codehaus.org/browse/MRELEASE-122?page=all ]

Matthew Beermann updated MRELEASE-122:
--

Attachment: patch.txt

It's a very simple fix - the other functions in the class have this logic, but 
it got missed for extensions.

> Versionless Extension causes NullPointerException in release:prepare
> 
>
> Key: MRELEASE-122
> URL: http://jira.codehaus.org/browse/MRELEASE-122
> Project: Maven 2.x Release Plugin
>  Issue Type: Bug
>Affects Versions: 2.0-beta-4
>Reporter: Stefan Hübner
> Attachments: patch.txt
>
>
> I'm getting a NullPointerException when invoking "mvn release:prepare
> -DdryRun=true" (don't know, if the dryRun-parameter makes any
> difference). See the stack trace below.
> My POM does make use of the wagon-ssh-extension, but without declaring a 
> certain version of that extension - which is not necessary, as far as I know.
> A workaround to this is to declare a version to the extension.
> See this mail thread for a discussion on this issue: 
> 
> Stefan
> ava.lang.NullPointerException 
>at 
> org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.updateDomVersion(AbstractRewritePomsPhase.java:388)
>at 
> org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.rewriteExtensions(AbstractRewritePomsPhase.java:352)
>at 
> org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.transformDocument(AbstractRewritePomsPhase.java:230)
>at 
> org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:165)
>at 
> org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:102)
>at 
> org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.simulate(AbstractRewritePomsPhase.java:529)
>at 
> org.apache.maven.plugins.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:135)

-- 
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-2480) Support for different types of version ranges in dependencies

[Peter Monks (JIRA)]

Support for different types of version ranges in dependencies
-

 Key: MNG-2480
 URL: http://jira.codehaus.org/browse/MNG-2480
 Project: Maven 2
  Issue Type: Improvement
  Components: Dependencies
Affects Versions: 2.0.4
 Environment: n/a
Reporter: Peter Monks


G'day,

It would be ideal if Maven supported different types of dependency version 
ranges, to allow for more flexible dependency version resolution.  For example, 
if I was the provider of an open source library I might like to be able to 
state that my code is dependent on some other library, and in the dependency 
version section be able to say that it's been tested with one or two specific 
versions (say [1.1,1.2]), but should theoretically work over a range of 
versions (say [1.1,2.0)  ).  In this example the two version ranges might be 
called the "soft" range and the "hard" range (or "certified" and "uncertified" 
or whatever - the idea is what's important, not the terminology).

Currently many of the poms for open source libraries in the public Maven 
repositories specify precise version numbers which invariably causes version 
mismatches (which then tickles bug MNG-2123, but that's another story...).  I 
suspect that one of the reasons that open source teams do this is because 
they've only tested their code against one version of each library they're 
dependent upon, so it's understandable that they don't want to put a wider 
range of version numbers in their poms.  But this increases the changes of a 
version number mismatch which forces the ultimate consumer of the library (and 
its dependencies) to manually fiddle with poms until the various version number 
ranges overlap.

If it were possible to specify "hard" vs "soft" version number ranges in the 
poms directly, then open source providers may have more incentive to be more 
permissive in their version number ranges, while still making it clear which 
versions of their dependencies they've actually tested against.

Cheers,
Peter


-- 
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: (MJAR-55) possibility to add arbitrary elements to the manifest classpath

[Brett Porter (JIRA)]

 [ http://jira.codehaus.org/browse/MJAR-55?page=all ]

Brett Porter closed MJAR-55.


  Assignee: Brett Porter
Resolution: Duplicate

> possibility to add arbitrary elements to the manifest classpath
> ---
>
> Key: MJAR-55
> URL: http://jira.codehaus.org/browse/MJAR-55
> Project: Maven 2.x Jar Plugin
>  Issue Type: Improvement
>Reporter: Michel Verbist
> Assigned To: Brett Porter
>Priority: Minor
>
> I want to add '.' (the current directory) to the classpath.
> The main reason for this is to be able to access files like
> log4j.properties
> hibernate.cfg.xml
> ...
> outside the jar, so I don't have to rebuild my jar if, e.g., I want to 
> increase the log4j level for a particular class.
> Or ask my client over the phone to increase the level and send me the log 
> file.
> The only thing I came up with was this possible improvement:
> current config of the manifest:
> 
>   
>   
>   true
>   
> be.brail.b38c.loadtester.AppLoadTester
>   
>   
> 
> possible extension of manifest config
> 
>   
>   
>   true
> 
>   ./
>   help/
>   resources/
> 
>   
> be.brail.b38c.loadtester.AppLoadTester
>   
>   
> 
> By adding 
> public List 
> org.apache.maven.archiver.ManifestConfiguration.getAdditionalClasspathEntries()
> people could be allowed to add not only the dependent jars to the classpath 
> but also any arbitrary directory.

-- 
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: (MEV-426) Quartz 1.5.2 missing pom and jar. Has source.

[Carlos Sanchez (JIRA)]

[ http://jira.codehaus.org/browse/MEV-426?page=comments#action_71432 ] 

Carlos Sanchez commented on MEV-426:


as is said, ejb and servlet must have true

> Quartz 1.5.2 missing pom and jar. Has source.
> -
>
> Key: MEV-426
> URL: http://jira.codehaus.org/browse/MEV-426
> Project: Maven Evangelism
>  Issue Type: Improvement
>Reporter: Lee Meador
> Attachments: maven-repo-quartz-1.5.2.zip, pom.xml
>
>
> The pom and jar are missing but the source jar, etc are there. Quartz 1.5.1 
> has a pom with no dependencies. The supplied file has a pom with all the 
> dependencies needed to compile quartz EXCEPT ejb.jar and servlet.jar (or 
> servlet-api.jar) JTA and MAIL are marked optional. The others are things like 
> beanutils and such that are already in the repository.
> Here's what I did:
> 1) Download 1.5.2 from http://www.opensymphony.com/quartz/download.action
> 2) Unzip and take the jar from the lib directory of what unzipped..
> 3) Build an Eclipse project with a the maven 2 plugin, using the maven layout.
> 4) Copy all the unzipped source into src/main/java from the src/java 
> directory of what unzipped.
> 5) Create a pom by turning on the maven2 eclipse plugin for the project.
> 5) Add dependencies to the pom based on what wouldn't compile in eclipse.
> 6) Repeat step 5 and building with mvn compile until there were no errors.
> Then I copied the pom to quartz-1.5.2.pom and edited it a bit more:
> 1) I removed ejb.jar and servlet.jar since I figured those would be around if 
> needed in quartz.
> 2) I added true to jta and java mail since those jars 
> are Sun's and aren't in the repo
> 3) I added runtime to everything else.
> That is what I am sending you. 

-- 
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-31) add ability to configure JBoss-specific deployment options in plugin configuration that will result in a jboss-app.xml descriptor being generated

[Stephane Nicoll (JIRA)]

[ http://jira.codehaus.org/browse/MEAR-31?page=comments#action_71431 ] 

Stephane Nicoll commented on MEAR-31:
-

also we need to disable the connector stuff when the jboss-app.xml is generated

> add ability to configure JBoss-specific deployment options in plugin 
> configuration that will result in a jboss-app.xml descriptor being generated
> -
>
> Key: MEAR-31
> URL: http://jira.codehaus.org/browse/MEAR-31
> Project: Maven 2.x Ear Plugin
>  Issue Type: New Feature
>Affects Versions: 2.2
>Reporter: Ian Springer
> Assigned To: Stephane Nicoll
> Fix For: 2.3
>
>
> The correct way to configure a SAR bundled in an EAR is not via a connector 
> module, but by adding a service module entry in META-INF/jboss-app.xml, e.g.:
>  "http://www.jboss.org/j2ee/dtd/jboss-app_4_0.dtd";>
> 
> 
> my.sar
> 
> 
> This tells JBoss to load the JBoss service from the file my.sar located in 
> the root directory of the EAR.
> I suggest adding a JBoss-specfic section in the EAR plugin's configuration 
> for configuring stuff that needs to be written to jboss-app.xml, e.g.:
> 
>   
> 4
> ...
>   
> 
> The jbossVersion would tell the plugin which version of JBoss is being 
> targeted, which would determine the docType of the file (a bunch of new 
> elements were added in JBoss 4.x - for example, the ability to deploy 
> Hibernate archives (HARs). We could sgtart out with just the ability to 
> deploy SARs and perhaps HARs and eventually add support for the other items 
> in jboss-app.xml.

-- 
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: (MEV-426) Quartz 1.5.2 missing pom and jar. Has source.

[Lee Meador (JIRA)]

 [ http://jira.codehaus.org/browse/MEV-426?page=all ]

Lee Meador updated MEV-426:
---

Attachment: pom.xml

Here is a better pom.

I had the previous one totally messed up. What I forgot was that when dealing 
with "transitive" dependencies maven2 will convert the scopes in the pom for 
the "direct" dependency to something different for the transitive ones.

So, to fix the problem, I added some scopes and optionals to the pom I used to 
build Quartz 1.5.2 on my machine. I haven't removed each dependency to make 
sure this is the smalled list that will work but I did add the se one by one 
and when I got to this list it started compiling.

> Quartz 1.5.2 missing pom and jar. Has source.
> -
>
> Key: MEV-426
> URL: http://jira.codehaus.org/browse/MEV-426
> Project: Maven Evangelism
>  Issue Type: Improvement
>Reporter: Lee Meador
> Attachments: maven-repo-quartz-1.5.2.zip, pom.xml
>
>
> The pom and jar are missing but the source jar, etc are there. Quartz 1.5.1 
> has a pom with no dependencies. The supplied file has a pom with all the 
> dependencies needed to compile quartz EXCEPT ejb.jar and servlet.jar (or 
> servlet-api.jar) JTA and MAIL are marked optional. The others are things like 
> beanutils and such that are already in the repository.
> Here's what I did:
> 1) Download 1.5.2 from http://www.opensymphony.com/quartz/download.action
> 2) Unzip and take the jar from the lib directory of what unzipped..
> 3) Build an Eclipse project with a the maven 2 plugin, using the maven layout.
> 4) Copy all the unzipped source into src/main/java from the src/java 
> directory of what unzipped.
> 5) Create a pom by turning on the maven2 eclipse plugin for the project.
> 5) Add dependencies to the pom based on what wouldn't compile in eclipse.
> 6) Repeat step 5 and building with mvn compile until there were no errors.
> Then I copied the pom to quartz-1.5.2.pom and edited it a bit more:
> 1) I removed ejb.jar and servlet.jar since I figured those would be around if 
> needed in quartz.
> 2) I added true to jta and java mail since those jars 
> are Sun's and aren't in the repo
> 3) I added runtime to everything else.
> That is what I am sending you. 

-- 
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-771) Add user management screens

[Carlos Sanchez (JIRA)]

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

Carlos Sanchez commented on CONTINUUM-771:
--

Applied patches but the last one that doesn't apply correctly. Also the 
solution goes through using maven-user as stated in CONTINUUM-800

> Add user management screens
> ---
>
> Key: CONTINUUM-771
> URL: http://jira.codehaus.org/browse/CONTINUUM-771
> Project: Continuum
>  Issue Type: Sub-task
>  Components: Web interface
>Reporter: Carlos Sanchez
> Assigned To: Henry S. Isidro
> Fix For: 1.1
>
> Attachments: CONTINUUM-771-continuum-webapp-menu.patch, 
> CONTINUUM-771-continuum-webapp-refactored_user_management_actions.patch, 
> CONTINUUM-771-continuum-webapp-using-PlexusActionSupport.patch, 
> CONTINUUM-771-continuum-webapp-with-improved-logging.patch, 
> CONTINUUM-771-continuum-webapp.patch, CONTINUUM-771-continuum-webapp.patch
>
>
> Add a page for listing the users, with options to add/edit/delete user
> Users can have an unlimited number of roles (Continuum Permission) like 
> addProject, addUser,... they are already created by the ContinuumInitializer 
> and are static (no new roles/permissions can be added)

-- 
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-2479) add support for optional 'packagingName' element in dependency blocks

[Ian Springer (JIRA)]

add support for optional 'packagingName' element in dependency blocks
-

 Key: MNG-2479
 URL: http://jira.codehaus.org/browse/MNG-2479
 Project: Maven 2
  Issue Type: New Feature
  Components: Dependencies
Affects Versions: 2.0.4
Reporter: Ian Springer


The various deployment artifact types (war, ear, sar, etc.) package their 
dependencies within the target archive during the package phase. For example, 
the war plugin includes jar dependencies within WEB-INF/lib, and the ear plugin 
includes jar and J2EE dependencies at the top level. Sometimes it is not 
desirable to package the dependencies with their full Maven-repo-style names 
(i.e. artifactName-version.xar). In particular, the version component is often 
not desired. Currently, some plugins provide a way to rename these dependency 
artifacts when they are packaged (e.g. the ear plugin), and others do not (e.g. 
the war plugin), making it necessary to use an antrun or dependency plugin hack 
to rename the artifacts as desired. I think it would be much nicer if there was 
a standard way to specify a "packaging name" (or whatever other name makes 
sense) for a dependency in its dependency block in the pom. Then all plugins 
that package their dependencies could leverage this standard setting. 

Here is an example of a war dependency declared in an ear pom:


  org.jboss.on
  on-enterprise-gui-portal
  2.0-SNAPSHOT
  war
  on-portal


This would cause the war to be bundled in the ear with the filename 
"on-portal.war", instead of the default 
on-enterprise-gui-portal-2.0-SNAPSHOT.war.


-- 
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: (MEAR-29) EAR:generate-application-xml : Ability to deactivate generation to be compliant with portlet deployment

[Stephane Nicoll (JIRA)]

 [ http://jira.codehaus.org/browse/MEAR-29?page=all ]

Stephane Nicoll closed MEAR-29.
---

Resolution: Fixed

Fixed.

set true for the related web module.

> EAR:generate-application-xml : Ability to deactivate  
> generation to be compliant with portlet deployment
> --
>
> Key: MEAR-29
> URL: http://jira.codehaus.org/browse/MEAR-29
> Project: Maven 2.x Ear Plugin
>  Issue Type: Improvement
>Affects Versions: 2.1
> Environment: OS: WIN2K (likely any platform)
> Application Server: JBOSS 4.0.3 (likely not relevant)
>Reporter: Thierry Barnier
> Assigned To: Stephane Nicoll
> Fix For: 2.3
>
> Attachments: no-context-root for Maven-EARplugin.patch
>
>
> I embed a WAR portlet module inside an EAR module
> I configure the EAR module as follows
> 
>  org.apache.maven.plugins
> maven-ear-plugin
> 2.1
> 
> Portlet
> JBOSS portlet
> 
> 
> myApp
> JBPortlet1-war
> 
> 
> 
> 
> 
> The maven-EAR-module generates an application.xml of the following form:
> 
>   Thierry Portlet
>   JBOSS portlet
>   
> 
>JBPortlet1-war-1.0.war
>   /portlet<<< I would like to 
> remove automatically this line
> 
>   
> 
> The problem is:
> In case of a portlet deployment, the  element must be omitted, 
> or the application server reject the EAR package.
> There is no way today to disable  generation in application.xml
> If i comment / remove the  line in the POM file , it takes the 
> WAR filename as context-root in the application.xml
> I would like to remove automatically the  line.
> what could be the strategy?
> =>a  tag added to the ear plugin config
> 
>   tutorials
>   JBPortlet1-war
>   
> 
> =>a way to specify that application-xml has to be generated regarding portlet 
> constraints? ( property)
> 
>   tutorials
>   JBPortlet1-war
>   true
> 

-- 
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-29) EAR:generate-application-xml : Ability to deactivate generation to be compliant with portlet deployment

[Stephane Nicoll (JIRA)]

[ http://jira.codehaus.org/browse/MEAR-29?page=comments#action_71426 ] 

Stephane Nicoll commented on MEAR-29:
-

which portlet container are you using? This problem sounds weird to me and is 
maybe a limitation of the container you are using.

> EAR:generate-application-xml : Ability to deactivate  
> generation to be compliant with portlet deployment
> --
>
> Key: MEAR-29
> URL: http://jira.codehaus.org/browse/MEAR-29
> Project: Maven 2.x Ear Plugin
>  Issue Type: Improvement
>Affects Versions: 2.1
> Environment: OS: WIN2K (likely any platform)
> Application Server: JBOSS 4.0.3 (likely not relevant)
>Reporter: Thierry Barnier
> Assigned To: Stephane Nicoll
> Fix For: 2.3
>
> Attachments: no-context-root for Maven-EARplugin.patch
>
>
> I embed a WAR portlet module inside an EAR module
> I configure the EAR module as follows
> 
>  org.apache.maven.plugins
> maven-ear-plugin
> 2.1
> 
> Portlet
> JBOSS portlet
> 
> 
> myApp
> JBPortlet1-war
> 
> 
> 
> 
> 
> The maven-EAR-module generates an application.xml of the following form:
> 
>   Thierry Portlet
>   JBOSS portlet
>   
> 
>JBPortlet1-war-1.0.war
>   /portlet<<< I would like to 
> remove automatically this line
> 
>   
> 
> The problem is:
> In case of a portlet deployment, the  element must be omitted, 
> or the application server reject the EAR package.
> There is no way today to disable  generation in application.xml
> If i comment / remove the  line in the POM file , it takes the 
> WAR filename as context-root in the application.xml
> I would like to remove automatically the  line.
> what could be the strategy?
> =>a  tag added to the ear plugin config
> 
>   tutorials
>   JBPortlet1-war
>   
> 
> =>a way to specify that application-xml has to be generated regarding portlet 
> constraints? ( property)
> 
>   tutorials
>   JBPortlet1-war
>   true
> 

-- 
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-2471) Add search box to the index page

[Dennis Lundberg (JIRA)]

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

Dennis Lundberg updated MNG-2471:
-

Attachment: index-with-focus.html

Using the original proposal, I added a small javascript that sets focus to the 
searchbox so that you can start typing right away.

I also moved the image outside of the form and removed a paragraph to minimize 
the space above the image.

> Add search box to the index page
> 
>
> Key: MNG-2471
> URL: http://jira.codehaus.org/browse/MNG-2471
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Documentation:  General
>Reporter: Marvin King
> Assigned To: Marvin King
> Attachments: index-with-focus.html, 
> index-without-logo-with-mojocodehausoption.html, index.html, 
> MNG-2471-site.patch, site-without-logo-with-mojocodehausoption.css
>
>
>   - google for now

-- 
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: (MDEP-32) -Sibling Dependency Not Included in copy-dependencies output during multi-project build

[Matt Brozowski (JIRA)]

 [ http://jira.codehaus.org/browse/MDEP-32?page=all ]

Matt Brozowski updated MDEP-32:
---

Attachment: dependency-revised.zip

> -Sibling Dependency Not Included in copy-dependencies output during 
> multi-project build
> ---
>
> Key: MDEP-32
> URL: http://jira.codehaus.org/browse/MDEP-32
> Project: Maven 2.x Dependency Plugin
>  Issue Type: Bug
>Reporter: Matt Brozowski
> Assigned To: Kenney Westerhof
> Fix For: 1.1
>
> Attachments: dependency-revised.zip
>
>
> Using the following structure
> dependency-test
>  - module1
>  - module2
>  I have the dependency-maven-plugin:copy-dependencies goal attached
> the package phase of the module2 module.
> "module2" has a dependency on "module1".  When I run "mvn package" from the
> "module2" folder, it correctly includes the "module1" jar in the
> target/dependency folder.
> When I run "mvn package" from the "dependency-test" folder, the "module1" jar 
> is
> not included in the impl/target/dependency folder.
> A simple example of the problem is attached.

-- 
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: (MDEP-32) -Sibling Dependency Not Included in copy-dependencies output during multi-project build

[Matt Brozowski (JIRA)]

[ http://jira.codehaus.org/browse/MDEP-32?page=comments#action_71422 ] 

Matt Brozowski commented on MDEP-32:


I have reopened this because it doesn't appear to be fixed in 
maven-dependency-plugin.

I have revised the original test to use the maven-dependency-plugin and am 
attaching it.

Matt Brozowski

> -Sibling Dependency Not Included in copy-dependencies output during 
> multi-project build
> ---
>
> Key: MDEP-32
> URL: http://jira.codehaus.org/browse/MDEP-32
> Project: Maven 2.x Dependency Plugin
>  Issue Type: Bug
>Reporter: Matt Brozowski
> Assigned To: Kenney Westerhof
> Fix For: 1.1
>
> Attachments: dependency-revised.zip
>
>
> Using the following structure
> dependency-test
>  - module1
>  - module2
>  I have the dependency-maven-plugin:copy-dependencies goal attached
> the package phase of the module2 module.
> "module2" has a dependency on "module1".  When I run "mvn package" from the
> "module2" folder, it correctly includes the "module1" jar in the
> target/dependency folder.
> When I run "mvn package" from the "dependency-test" folder, the "module1" jar 
> is
> not included in the impl/target/dependency folder.
> A simple example of the problem is attached.

-- 
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: (MDEP-32) -Sibling Dependency Not Included in copy-dependencies output during multi-project build

[Matt Brozowski (JIRA)]

-Sibling Dependency Not Included in copy-dependencies output during 
multi-project build
---

 Key: MDEP-32
 URL: http://jira.codehaus.org/browse/MDEP-32
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
Reporter: Matt Brozowski
 Assigned To: Kenney Westerhof
 Fix For: 1.1


Using the following structure

dependency-test
 - module1
 - module2

 I have the dependency-maven-plugin:copy-dependencies goal attached
the package phase of the module2 module.

"module2" has a dependency on "module1".  When I run "mvn package" from the
"module2" folder, it correctly includes the "module1" jar in the
target/dependency folder.

When I run "mvn package" from the "dependency-test" folder, the "module1" jar is
not included in the impl/target/dependency folder.

A simple example of the problem is attached.

-- 
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: (MAVEN-1768) wrong directory structure in src distribution package (maven-dist-plugin-1.7)

[JIRA]

[ http://jira.codehaus.org/browse/MAVEN-1768?page=comments#action_71421 ] 

Jarkko Viinamäki commented on MAVEN-1768:
-

Ah sorry. I didn't notice that there are separate Jira areas for all plugins. 
Reported this to the maven-dist-plugin subproject. This issue can be 
closed/deleted.

> wrong directory structure in src distribution package (maven-dist-plugin-1.7)
> -
>
> Key: MAVEN-1768
> URL: http://jira.codehaus.org/browse/MAVEN-1768
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.1-beta-2
>Reporter: Jarkko Viinamäki
>
> With Maven 1.1-beta-2 and maven-dist-plugin-1.7:
> if my project.xml defines:
>   
> src/main/java
> ...
> Then the dist:build-src target generates an incorrect src distribution file 
> since the source files are packaged to path src/foo/bar/MyClass.java instead 
> of src/main/java/foo/bar/MyClass.java
> --
> To fix this, change the dist:prepare-src-filesystem goal in 
> maven-dist-plugin-1.7 to read:
> 
>   
> 
>   
> 
> This will preserve the actual directory structure.

-- 
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: (MPDIST-29) src distribution archive has incorrect directory structure

[JIRA]

src distribution archive has incorrect directory structure
--

 Key: MPDIST-29
 URL: http://jira.codehaus.org/browse/MPDIST-29
 Project: maven-dist-plugin
  Issue Type: Bug
Affects Versions: 1.7
Reporter: Jarkko Viinamäki


With Maven 1.1-beta-2 and maven-dist-plugin-1.7:

if my project.xml defines:


src/main/java
...

Then the dist:build-src target generates an incorrect src distribution file 
since the source files are packaged to path src/foo/bar/MyClass.java instead of 
src/main/java/foo/bar/MyClass.java

-

To fix this, change the dist:prepare-src-filesystem goal in 
maven-dist-plugin-1.7 to read:







This will preserve the actual directory structure.

-- 
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-1768) wrong directory structure in src distribution package (maven-dist-plugin-1.7)

[JIRA]

wrong directory structure in src distribution package (maven-dist-plugin-1.7)
-

 Key: MAVEN-1768
 URL: http://jira.codehaus.org/browse/MAVEN-1768
 Project: Maven
  Issue Type: Bug
  Components: core
Affects Versions: 1.1-beta-2
Reporter: Jarkko Viinamäki


With Maven 1.1-beta-2 and maven-dist-plugin-1.7:

if my project.xml defines:

  
src/main/java
...

Then the dist:build-src target generates an incorrect src distribution file 
since the source files are packaged to path src/foo/bar/MyClass.java instead of 
src/main/java/foo/bar/MyClass.java

--

To fix this, change the dist:prepare-src-filesystem goal in 
maven-dist-plugin-1.7 to read:


  

  


This will preserve the actual directory structure.


-- 
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: (MRELEASE-137) proposed SCM release tag or label in multiproject

[Matthew Beermann (JIRA)]

 [ http://jira.codehaus.org/browse/MRELEASE-137?page=all ]

Matthew Beermann updated MRELEASE-137:
--

Attachment: patch.txt

This seems like a relatively straightforward fix - the root project is last on 
the list, not first. Could someone get this checked in?

> proposed SCM release tag or label in multiproject
> -
>
> Key: MRELEASE-137
> URL: http://jira.codehaus.org/browse/MRELEASE-137
> Project: Maven 2.x Release Plugin
>  Issue Type: Bug
>Affects Versions: 2.0-beta-4
>Reporter: Gilles Scokart
>Priority: Minor
> Attachments: patch.txt
>
>
> If we have
> - pom.xml (name : root)
>   --- module1
>   pom.xml (name : module1)
>   --- module2
>   pom.xml (name : module1)
> and we prepare a release at the root level, the name proposed for the tag is 
> module1-${version} instead  root-${version}.
> Note that except the name, everything is stored as expected with SVN.
> NB: I don't know if it has an impact, but the pom in module1 and module 
> doesn't inherit from the root (no parent tags).

-- 
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-801) Maven2: Add Project Homepage URL to the project info page and build result page.

[Sharmarke Aden (JIRA)]

Maven2: Add Project Homepage URL to the project info page and build result page.


 Key: CONTINUUM-801
 URL: http://jira.codehaus.org/browse/CONTINUUM-801
 Project: Continuum
  Issue Type: Improvement
  Components: Web interface
Affects Versions: 1.0.3
Reporter: Sharmarke Aden
Priority: Minor
 Attachments: continuum_webinterface_homepage.patch

In maven 2 you can specify a URL for your project's homepage in the pom.xml. It 
would be nice if a link to this URL could be show on the project info page and 
the build result page of continuum web interface. 

Attached is a patch that adds a row containing project homepage to both View.vm 
and ProjectBuild.vm if the property "$project.url" exists.

-- 
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: (MPWAR-62) maven-war-plugin doesn't compile java sources when used with maven-test-plugin 1.8

[nicolas de loof (JIRA)]

[ http://jira.codehaus.org/browse/MPWAR-62?page=comments#action_71417 ] 

nicolas de loof commented on MPWAR-62:
--

Latest patch should also solve this. I'll try it ASAP.

>  maven-war-plugin doesn't compile java sources when used with 
> maven-test-plugin 1.8
> ---
>
> Key: MPWAR-62
> URL: http://jira.codehaus.org/browse/MPWAR-62
> Project: maven-war-plugin
>  Issue Type: Bug
>Affects Versions: 1.6.2
>Reporter: nicolas de loof
> Assigned To: Lukas Theussl
> Fix For: 1.6.3
>
> Attachments: MPWAR-62, MPWAR-62.patch
>
>
> I've found an issue when using latest versions of maven-test-plugin (1.8) :
> when maven.test.skip=true is set, the  goal is not executed. 
> This sounds good, BUT the maven-war-plugin use "test:test" goal to attain the 
> "java:compile" goal, so the generated war has no classes !
> The war:resources plugin should have 
> prereqs="war:war-resources,*java:compile*,test:test".

-- 
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: (MPXDOC-197) report fails if repository is not defined

[Lukas Theussl (JIRA)]

 [ http://jira.codehaus.org/browse/MPXDOC-197?page=all ]

Lukas Theussl updated MPXDOC-197:
-

 Assignee: Lukas Theussl
Fix Version/s: 1.10.1

> report fails if repository is not defined
> -
>
> Key: MPXDOC-197
> URL: http://jira.codehaus.org/browse/MPXDOC-197
> Project: maven-xdoc-plugin
>  Issue Type: Bug
>Affects Versions: 1.10
> Environment: maven 1.1-beta-3-SNAPSHOT(20060729), Operating system 
> Windows 2000
>Reporter: Piotr Kania
> Assigned To: Lukas Theussl
> Fix For: 1.10.1
>
>
> If project definition contain empty repository tag then report fails:
> Project definition
> 
> 
> 3
> rfl-project-main
> RFL Project Main
> ${groupId}
> ${version}
> 
> 
>   
> maven-faq-plugin  
> maven-multiproject-plugin
> maven-dashboard-plugin
>
> 
> xdoc:register-reports:
> faq:init:
> maven-faq-plugin:register:
> xdoc:generate-from-pom:
> [echo] Generating xdocs from POM ...
> BUILD FAILED
> org.apache.velocity.exception.ResourceNotFoundException: Unable to find 
> resource 'scm/${connscm}.xml
> '
> at 
> org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl
> .java:458)
> at 
> org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.
> java:341)
> at 
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:831)
> at org.apache.velocity.runtime.directive.Parse.render(Parse.java:141)
> at 
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:114)
> at 
> org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:55)
> at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:230)
> at 
> org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:89)
> at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:230)
> at org.apache.velocity.Template.merge(Template.java:256)
> at 
> org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:450)
> at 
> org.apache.commons.jelly.tags.velocity.MergeTag.mergeTemplate(MergeTag.java:186)
> at 
> org.apache.commons.jelly.tags.velocity.MergeTag.doTag(MergeTag.java:68)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
> at org.apache.commons.jelly.tags.core.WhenTag.doTag(WhenTag.java:46)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
> at 
> org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:38)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
> at 
> org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:150)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at 
> org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:82)
> at 
> org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag
> .java:115)
> at org.apache.maven.werkz.Goal.fire(Goal.java:647)
> at org.apache.maven.werkz.Goal.attain(Goal.java:582)
> at org.apache.maven.werkz.Goal.attainPrecursors(Goal.java:494)
> at org.apache.maven.werkz.Goal.attain(Goal.java:580)
> at 
> org.apache.maven.werkz.WerkzProject.attainGoal(WerkzProject.java:208)
> at 
> org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:114)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at 
> org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:82)
> at 
> org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag
> .java:115)
> at org.apache.maven.werkz.Goal.fire(Goal.java:647)
> at org.apache.maven.werkz.Goal.attain(Goal.java:582)
> at 
> org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:709)
> at org.apache.maven.MavenSession.attainGoals(MavenSession.java:264)
> at org.apache.maven.

[jira] Commented: (MPMULTIPROJECT-69) report failed throwing NullPointerException invoking getProjects

[Lukas Theussl (JIRA)]

[ 
http://jira.codehaus.org/browse/MPMULTIPROJECT-69?page=comments#action_71400 ] 

Lukas Theussl commented on MPMULTIPROJECT-69:
-

We'll need more information to reproduce this (eg what's in the parent pom?). 
Please try to attach a small test project that demonstrates the problem.

> report failed throwing NullPointerException invoking getProjects
> 
>
> Key: MPMULTIPROJECT-69
> URL: http://jira.codehaus.org/browse/MPMULTIPROJECT-69
> Project: maven-multiproject-plugin
>  Issue Type: Bug
>Affects Versions: 1.5
> Environment: maven 1.1-beta-3-SNAPSHOT (20060729), windows 2000
>Reporter: Piotr Kania
>Priority: Blocker
>
> running command maven site for project containing report 
> maven-multiproject-plugin following error occurs:
> multiproject:dependency-convergence-report:
> BUILD FAILED
> org.apache.velocity.exception.MethodInvocationException: Invocation of method 
> 'getProjects' in  clas
> s org.apache.maven.multiproject.harmonizer.MultiDependency threw exception 
> class java.lang.NullPoint
> erException : null
> at 
> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:246)
> at 
> org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:175)
> at 
> org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:327)
> at 
> org.apache.velocity.runtime.directive.Foreach.render(Foreach.java:131)
> at 
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:114)
> at 
> org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:55)
> at 
> org.apache.velocity.runtime.directive.Foreach.render(Foreach.java:166)
> at 
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:114)
> at 
> org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:55)
> at 
> org.apache.velocity.runtime.directive.Foreach.render(Foreach.java:166)
> at 
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:114)
> at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:230)
> at org.apache.velocity.Template.merge(Template.java:256)
> at 
> org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:450)
> at 
> org.apache.commons.jelly.tags.velocity.MergeTag.mergeTemplate(MergeTag.java:186)
> at 
> org.apache.commons.jelly.tags.velocity.MergeTag.doTag(MergeTag.java:68)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at 
> org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:82)
> at 
> org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag
> .java:115)
> at org.apache.maven.werkz.Goal.fire(Goal.java:647)
> at org.apache.maven.werkz.Goal.attain(Goal.java:582)
> at 
> org.apache.maven.werkz.WerkzProject.attainGoal(WerkzProject.java:208)
> at 
> org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:114)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at 
> org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:82)
> at 
> org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag
> .java:115)
> at org.apache.maven.werkz.Goal.fire(Goal.java:647)
> at org.apache.maven.werkz.Goal.attain(Goal.java:582)
> at 
> org.apache.maven.werkz.WerkzProject.attainGoal(WerkzProject.java:208)
> at 
> org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:114)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
> at org.apache.commons.jelly.tags.core.WhenTag.doTag(WhenTag.java:46)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
> at 
> org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:38)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
> at org.apache.common

[jira] Closed: (MAVENUPLOAD-1026) JHighlight 1.0

[Carlos Sanchez (JIRA)]

 [ http://jira.codehaus.org/browse/MAVENUPLOAD-1026?page=all ]

Carlos Sanchez closed MAVENUPLOAD-1026.
---

  Assignee: Carlos Sanchez
Resolution: Fixed

> JHighlight 1.0
> --
>
> Key: MAVENUPLOAD-1026
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1026
> Project: maven-upload-requests
>  Issue Type: Task
>Reporter: Hervé BOUTEMY
> Assigned To: Carlos Sanchez
>
> stable version 1.0 of the library

-- 
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-1027) Upload Rhino 1.6R3 to ibiblio

[Carlos Sanchez (JIRA)]

 [ http://jira.codehaus.org/browse/MAVENUPLOAD-1027?page=all ]

Carlos Sanchez closed MAVENUPLOAD-1027.
---

  Assignee: Carlos Sanchez
Resolution: Fixed

> Upload Rhino 1.6R3 to ibiblio
> -
>
> Key: MAVENUPLOAD-1027
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1027
> Project: maven-upload-requests
>  Issue Type: Task
>Reporter: Matt Whitlock
> Assigned To: Carlos Sanchez
>
> http://www.mattwhitlock.com/js-1.6R3-bundle.jar
> http://www.mozilla.org/rhino/
> Rhino is an open-source implementation of JavaScript written entirely in 
> Java. It is typically embedded into Java applications to provide scripting to 
> end users.
> The web site has not yet been updated to reflect the 1.6R3 release, but it is 
> available at the download site:
> ftp://ftp.mozilla.org/pub/mozilla.org/js/
> The 1.6R3 download on that FTP site has a modification date of 24 July 2006.

-- 
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] Moved: (MJAR-55) possibility to add arbitrary elements to the manifest classpath

[Lukas Theussl (JIRA)]

 [ http://jira.codehaus.org/browse/MJAR-55?page=all ]

Lukas Theussl moved MPJAR-55 to MJAR-55:


Workflow: Maven New  (was: jira)
 Key: MJAR-55  (was: MPJAR-55)
 Project: Maven 2.x Jar Plugin  (was: maven-jar-plugin)

> possibility to add arbitrary elements to the manifest classpath
> ---
>
> Key: MJAR-55
> URL: http://jira.codehaus.org/browse/MJAR-55
> Project: Maven 2.x Jar Plugin
>  Issue Type: Improvement
>Reporter: Michel Verbist
>Priority: Minor
>
> I want to add '.' (the current directory) to the classpath.
> The main reason for this is to be able to access files like
> log4j.properties
> hibernate.cfg.xml
> ...
> outside the jar, so I don't have to rebuild my jar if, e.g., I want to 
> increase the log4j level for a particular class.
> Or ask my client over the phone to increase the level and send me the log 
> file.
> The only thing I came up with was this possible improvement:
> current config of the manifest:
> 
>   
>   
>   true
>   
> be.brail.b38c.loadtester.AppLoadTester
>   
>   
> 
> possible extension of manifest config
> 
>   
>   
>   true
> 
>   ./
>   help/
>   resources/
> 
>   
> be.brail.b38c.loadtester.AppLoadTester
>   
>   
> 
> By adding 
> public List 
> org.apache.maven.archiver.ManifestConfiguration.getAdditionalClasspathEntries()
> people could be allowed to add not only the dependent jars to the classpath 
> but also any arbitrary directory.

-- 
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-2471) Add search box to the index page

[Marvin King (JIRA)]

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

Marvin King updated MNG-2471:
-

Attachment: index-without-logo-with-mojocodehausoption.html

> Add search box to the index page
> 
>
> Key: MNG-2471
> URL: http://jira.codehaus.org/browse/MNG-2471
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Documentation:  General
>Reporter: Marvin King
> Assigned To: Marvin King
> Attachments: index-without-logo-with-mojocodehausoption.html, 
> index.html, MNG-2471-site.patch, site-without-logo-with-mojocodehausoption.css
>
>
>   - google for now

-- 
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-2471) Add search box to the index page

[Marvin King (JIRA)]

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

Marvin King updated MNG-2471:
-

Attachment: (was: index-without-logo-with-mojocodehausoption.html)

> Add search box to the index page
> 
>
> Key: MNG-2471
> URL: http://jira.codehaus.org/browse/MNG-2471
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Documentation:  General
>Reporter: Marvin King
> Assigned To: Marvin King
> Attachments: index-without-logo-with-mojocodehausoption.html, 
> index.html, MNG-2471-site.patch, site-without-logo-with-mojocodehausoption.css
>
>
>   - google for now

-- 
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-2471) Add search box to the index page

[Marvin King (JIRA)]

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

Marvin King updated MNG-2471:
-

Attachment: site-without-logo-with-mojocodehausoption.css

> Add search box to the index page
> 
>
> Key: MNG-2471
> URL: http://jira.codehaus.org/browse/MNG-2471
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Documentation:  General
>Reporter: Marvin King
> Assigned To: Marvin King
> Attachments: index-without-logo-with-mojocodehausoption.html, 
> index.html, MNG-2471-site.patch, site-without-logo-with-mojocodehausoption.css
>
>
>   - google for now

-- 
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-2471) Add search box to the index page

[Marvin King (JIRA)]

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

Marvin King updated MNG-2471:
-

Attachment: index-without-logo-with-mojocodehausoption.html


 - applied dennis's suggestion

> Add search box to the index page
> 
>
> Key: MNG-2471
> URL: http://jira.codehaus.org/browse/MNG-2471
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Documentation:  General
>Reporter: Marvin King
> Assigned To: Marvin King
> Attachments: index-without-logo-with-mojocodehausoption.html, 
> index.html, MNG-2471-site.patch
>
>
>   - google for now

-- 
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: (MNGECLIPSE-77) Add support for WSAD specifics on a J2EE project.

[Andrew Perepelytsya (JIRA)]

[ http://jira.codehaus.org/browse/MNGECLIPSE-77?page=comments#action_71394 
] 

Andrew Perepelytsya commented on MNGECLIPSE-77:
---

Well, I have the WSAD extensions in the works. You know, it's different from 
RAD or Eclipse ;)

Just a preview of what is already available:

* Generates .project, .classpath files from the pom.xml model with WSAD natures 
and builders
* Enables WebSphere AS 5.1 J2EE targeting for projects
* Enables EJB Client module preference by default
* Adds M2_REPO classpath variable to WSAD workspace (it's different from what 
Eclipse 3.x plugin does)
* Configures JDK compliance to be 1.4 level
* Enables multiple output paths for the compiler to accomodate m2 folder layout
* Switches the workspace to JDK 1.4 (IBM one), and ensures all projects use it, 
and not 1.3 (the default one)

I will check the MECLIPSE-137 to see if some logic can be reused.

> Add support for WSAD specifics on a J2EE project.
> -
>
> Key: MNGECLIPSE-77
> URL: http://jira.codehaus.org/browse/MNGECLIPSE-77
> Project: Maven 2.x Extension for Eclipse
>  Issue Type: New Feature
>Reporter: Joakim Erdfelt
>Priority: Minor
> Attachments: sample-projects-wsad6.x.tar.bz2
>
>
> Need the ability to support the WSAD / J2EE specific configurations.
> The Eclipse extension needs to either ...
> # map the WSAD / J2EE project directory structure to a Maven pom.  
>   This way allows the user to use the WSAD J2EE wizards.
> # map a Maven J2EE pom to the WSAD / J2EE project configuration.
>   This way makes Maven the start of all J2EE applications.
>   This could be done by Eclipse extension specifics, or 
>   with the use of pre-defined Archetypes that show up on the New Project / 
> Maven Archetype Wizards within Eclipse.

-- 
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: (MSUREFIRE-153) Ability to add additions to classpath

[David J. M. Karlsen (JIRA)]

 [ http://jira.codehaus.org/browse/MSUREFIRE-153?page=all ]

David J. M. Karlsen updated MSUREFIRE-153:
--

Attachment: SurefirePlugin.java-diff

Patch which appends arbritary elements to the surefire classpaths

> Ability to add additions to classpath
> -
>
> Key: MSUREFIRE-153
> URL: http://jira.codehaus.org/browse/MSUREFIRE-153
> Project: Maven 2.x Surefire Plugin
>  Issue Type: Improvement
> Environment: N/A
>Reporter: David J. M. Karlsen
> Attachments: SurefirePlugin.java-diff
>
>
> There should be a possibility to add arbritary resources to the classpath 
> while executing the tests. These resources would only be available while 
> executing the tests, so they won't be added in the archive.
> i suggest a configuration element
> 
>  some/path
>  /some/other/path
> 
> This issue somewhat related to http://jira.codehaus.org/browse/MJAR-13 / 
> ability to exclude/include filtering in archiver/jar-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: (CONTINUUM-799) One sub module randomly appears twice after adding a parent multi-module

[Sanjiv Jivan (JIRA)]

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

Sanjiv Jivan commented on CONTINUUM-799:


I'm seeing the same behavior.

> One sub module randomly appears twice after adding a parent multi-module 
> -
>
> Key: CONTINUUM-799
> URL: http://jira.codehaus.org/browse/CONTINUUM-799
> Project: Continuum
>  Issue Type: Bug
>  Components: Database
>Affects Versions: 1.0.3
> Environment: Linux Red Hat 
>Reporter: Jonathan Johnson
> Fix For: 1.0.3
>
>
> One sub module randomly appears twice after adding a parent multi-module to 
> continuum 1.0.3.
> I have a parent maven 2 pom with 16 sub-modules.  If I reset the database ( 
> by removing the database directory) and add my parent pom.xml all the modules 
> will be added correctly except one random module will be added twice.  I 
> tried this three times and a different module in the list is duplicated once. 
>  This also happens after a fresh install of version 1.0.3.
> If I run a "Build All" one of the duplicate modules builds, while the other 
> remains with a "New" status. When attempting to remove the duplicate module 
> with the "New" status I get the error below.
> --
> [EMAIL PROTECTED] also reported this...
> "I've had a similar problem when using continuum with SVN. I end up with two 
> projects that have the exact same SCM url, but different continuum build id's 
> (sequential, in my case). Updating the build definition for one, 
> automatically updates it for the other. However, updates inside svn only 
> trigger one of them to be built by continuum, and not both. If I try to 
> delete the duplicated project, I get the continuum error page with the same 
> error output."
> --
> Additional findinds...
> I looked in the working directory.  I have 1-15 directories under 
> working-directory.  The module that is duplicated has an id of 10 and another 
> of 16.  The one that is 16 is the module that still has the status of "New" 
> and throws the database DELETE exception when I try to remove the module from 
> the Continuum list.
> the duplicateD module has different ids (10 and 16) but working directory 
> does not have a "16" folder.
> Here is theexception when removing the duplicate module with the id of "16"
> ognl.MethodFailedException: Method "removeProject" failed for object [EMAIL 
> PROTECTED] [javax.jdo.JDOUserException: One or more instances could not be 
> deleted
> NestedThrowables:
> javax.jdo.JDODataStoreException: Delete request failed: DELETE FROM 
> BUILDDEFINITION WHERE ID = ?
> NestedThrowables:
> SQL Exception: DELETE on table 'BUILDDEFINITION' caused a violation of 
> foreign key constraint 'PROJECT_BUILP8_FK2' for key (10).  The statement has 
> been rolled back.]
>   at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:796)
>   at ognl.ObjectMethodAccessor.callMethod(ObjectMethodAccessor.java:61)
>   at ognl.OgnlRuntime.callMethod(OgnlRuntime.java:819)
>   at ognl.ASTMethod.getValueBody(ASTMethod.java:75)
>   at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170)
>   at ognl.SimpleNode.getValue(SimpleNode.java:210)
>   at ognl.Ognl.getValue(Ognl.java:333)
>   at ognl.Ognl.getValue(Ognl.java:378)
>   at ognl.Ognl.getValue(Ognl.java:357)
>   at 
> org.codehaus.plexus.formica.action.DeleteEntity.uponSuccessfulValidation(DeleteEntity.java:57)
>   at 
> org.codehaus.plexus.formica.action.DeleteEntity.execute(DeleteEntity.java:47)
>   at 
> org.codehaus.plexus.summit.pipeline.valve.ActionValve.invoke(ActionValve.java:68)
>   at 
> org.codehaus.plexus.summit.pipeline.AbstractPipeline.invoke(AbstractPipeline.java:70)
>   at org.codehaus.plexus.summit.Summit.doGet(Summit.java:54)
>   at org.codehaus.plexus.summit.Summit.doPost(Summit.java:108)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>   at 
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358)
>   at 
> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294)
>   at 
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567)
>   at org.mortbay.http.HttpContext.handle(HttpContext.java:1807)
>   at 
> org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525)
>   at org.mortbay.http.HttpContext.handle(HttpContext.java:1757)
>   at org.mortbay.http.HttpServer.service(HttpServer.java:879)
>   at org.mortbay.http.HttpConnection.service(HttpConnection.java:789)
>   at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:960)
>   at org.mortbay.http.HttpConnection.handle(HttpConnection.java:806)
>   

[jira] Commented: (CONTINUUM-618) Refresh after "Build Now" create multiple builds

[Bugittaa Pahasti (JIRA)]

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

Bugittaa Pahasti commented on CONTINUUM-618:


I'll get two builds every time I do a forced build, even without refresh. The 
log has many warnings or errors, like:

[defaultScheduler_Worker-13] WARN  Continuum  - Cycle 
detected while sorting projects for building, falling back to unsorted build.
[SocketListener0-3] WARN  SQL- Object with id "0" 
not found !
[SocketListener0-3] WARN  ViewContextPopulator   - Cannot find a value 
for the expression getProject(#id)in [EMAIL PROTECTED]
[SocketListener0-3] ERROR VelocityComponent  - Method addPathInfo 
threw exception for reference $link in template screens/ProjectBuilds.vm at  
[14,26]
[SocketListener0-3] ERROR Renderer:velocity  - Error rendering 
template:
INFO   | jvm 1| 2006/08/02 14:46:39 | java.lang.NullPointerException
INFO   | jvm 1| 2006/08/02 14:46:39 |   at 
org.codehaus.plexus.summit.util.UriBuilder.addPathInfo(UriBuilder.java:263)

Don't know if this is related to this refresh bug. Happens with Continuum 1.0.3 
and Firefox 1.5.0.x (all minor versions including the latest 1.5.0.5).


> Refresh after "Build Now" create multiple builds
> 
>
> Key: CONTINUUM-618
> URL: http://jira.codehaus.org/browse/CONTINUUM-618
> Project: Continuum
>  Issue Type: Bug
>  Components: Web interface
>Affects Versions: 1.0.3
> Environment: xp
>Reporter: Dan Tran
> Fix For: 1.1
>
>
> After hitting "build now", the browser pauses for sometime and user loses 
> patient by hitting multiple refreshes 
> creating multiple forced builds
> For  a long build, it can be very annoyed.
> Worst, we user put up a daily release build in Continuum, it will cause 
> multiple release builds

-- 
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: (MPJAR-55) possibility to add arbitrary elements to the manifest classpath

[Michel Verbist (JIRA)]

possibility to add arbitrary elements to the manifest classpath
---

 Key: MPJAR-55
 URL: http://jira.codehaus.org/browse/MPJAR-55
 Project: maven-jar-plugin
  Issue Type: Improvement
Reporter: Michel Verbist
Priority: Minor


I want to add '.' (the current directory) to the classpath.

The main reason for this is to be able to access files like
log4j.properties
hibernate.cfg.xml
...
outside the jar, so I don't have to rebuild my jar if, e.g., I want to increase 
the log4j level for a particular class.
Or ask my client over the phone to increase the level and send me the log file.

The only thing I came up with was this possible improvement:
current config of the manifest:



true

be.brail.b38c.loadtester.AppLoadTester




possible extension of manifest config



true
  
./
help/
resources/
  

be.brail.b38c.loadtester.AppLoadTester




By adding 
public List 
org.apache.maven.archiver.ManifestConfiguration.getAdditionalClasspathEntries()
people could be allowed to add not only the dependent jars to the classpath but 
also any arbitrary directory.




-- 
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-120) change default skin to match Continuum

[Brett Porter (JIRA)]

 [ http://jira.codehaus.org/browse/MRM-120?page=all ]

Brett Porter closed MRM-120.


Resolution: Fixed

restructured to use Maven site layout (css/xhtml).

> change default skin to match Continuum
> --
>
> Key: MRM-120
> URL: http://jira.codehaus.org/browse/MRM-120
> Project: Maven Repository Manager
>  Issue Type: Task
>  Components: web application
>Reporter: Brett Porter
> Assigned To: Brett Porter
> Fix For: 1.0-beta-1
>
>   Original Estimate: 1 hour
>  Time Spent: 4 hours
>  Remaining Estimate: 0 minutes
>
> look into the WW templates being used, as well as updating the sitemesh 
> template.
> Try to drive as much as possible by the sitemesh template and CSS - however 
> if the WW theme needs to be changed, try to have it in a reusable JAR instead 
> of copying the files from Continuum

-- 
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: (MSUREFIREREP-24) Review Plugin Documentation

[Allan Ramirez (JIRA)]

 [ http://jira.codehaus.org/browse/MSUREFIREREP-24?page=all ]

Allan Ramirez closed MSUREFIREREP-24.
-

Resolution: Fixed

Applied Patch. Thanks

> Review Plugin Documentation
> ---
>
> Key: MSUREFIREREP-24
> URL: http://jira.codehaus.org/browse/MSUREFIREREP-24
> Project: Maven 2.x Surefire report Plugin
>  Issue Type: Task
>Reporter: Allan Ramirez
> Assigned To: Allan Ramirez
> Attachments: MSUREFIREREP-24-maven-surefire-report-plugin.patch
>
>   Original Estimate: 16 hours
>  Time Spent: 17 hours
>  Remaining Estimate: 0 minutes
>


-- 
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: (MDEP-31) ERROR: Cannot override read-only parameter: scope in goal: dependency:copy-dependencies

[David J. M. Karlsen (JIRA)]

ERROR:  Cannot override read-only parameter: scope in goal: 
dependency:copy-dependencies


 Key: MDEP-31
 URL: http://jira.codehaus.org/browse/MDEP-31
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
Reporter: David J. M. Karlsen


http://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html
 
states that  is a valid (and writable) configuration element, but the 
following configuration:



maven-dependency-plugin
2.0-SNAPSHOT


copy-dependencies
package


copy-dependencies



true
compile






will fail with:

[snip...]
Building index for all classes...
Generating 
C:/dnbnorapi/kildekode/utvikling/dnbnorapi-client/target/site/apidocs\allclasses-frame.html...
Generating 
C:/dnbnorapi/kildekode/utvikling/dnbnorapi-client/target/site/apidocs\allclasses-noframe.html...
Generating 
C:/dnbnorapi/kildekode/utvikling/dnbnorapi-client/target/site/apidocs\index.html...
Generating 
C:/dnbnorapi/kildekode/utvikling/dnbnorapi-client/target/site/apidocs\help-doc.html...
Generating 
C:/dnbnorapi/kildekode/utvikling/dnbnorapi-client/target/site/apidocs\stylesheet.css...
[INFO] Building jar: 
C:\dnbnorapi\kildekode\utvikling\dnbnorapi-client\target\dnbnorapi-client-1.0-SNAPSHOT-javadoc.jar
[INFO] [jar:test-jar {execution: default}]
[INFO] Building jar: 
C:\dnbnorapi\kildekode\utvikling\dnbnorapi-client\target\dnbnorapi-client-1.0-SNAPSHOT-tests.jar
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Error configuring: org.apache.maven.plugins:maven-dependency-plugin. 
Reason: ERROR: Cannot override read-only par
ameter: scope in goal: dependency:copy-dependencies
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 1 minute 3 seconds
[INFO] Finished at: Wed Aug 02 13:09:21 CEST 2006
[INFO] Final Memory: 13M/27M
[INFO] 

-- 
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: (MRAR-12) Review Plugin Documentation

[Allan Ramirez (JIRA)]

 [ http://jira.codehaus.org/browse/MRAR-12?page=all ]

Allan Ramirez closed MRAR-12.
-

Resolution: Fixed

Applied Patch. Thanks!

> Review Plugin Documentation
> ---
>
> Key: MRAR-12
> URL: http://jira.codehaus.org/browse/MRAR-12
> Project: Maven 2.x Rar Plugin
>  Issue Type: Task
>Reporter: Allan Ramirez
> Assigned To: Allan Ramirez
> Attachments: MRAR-12-maven-rar-plugin.patch
>
>   Original Estimate: 14 hours
>  Time Spent: 19 hours, 30 minutes
>  Remaining Estimate: 0 minutes
>


-- 
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-1024) sigh.. another upload of testng 5.0.1 (please)

[Carlos Sanchez (JIRA)]

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

Carlos Sanchez commented on MAVENUPLOAD-1024:
-

actually it's better a zip with the contents of the folder eg. the contents of 
http://www.ibiblio.org/maven2/org/testng/testng/5.0.1/
The script we have doesn't handle the classifiers

> sigh.. another upload of testng 5.0.1 (please)
> --
>
> Key: MAVENUPLOAD-1024
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1024
> Project: maven-upload-requests
>  Issue Type: Task
>Reporter: Jesse Kuhnert
> Assigned To: Carlos Sanchez
> Attachments: testng-5.0.1-jdk14.jar, testng-5.0.1-jdk15.jar, 
> testng.zip
>
>
> I screwed up the last 5.0.1 set of jars by not including the testng dtd file 
> in the jars. These two attached jars should resolve that issue. (if ibiblio 
> allows overwrites)

-- 
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: (MDEP-28) Incorregect information on "How to use" web page

[David J. M. Karlsen (JIRA)]

[ http://jira.codehaus.org/browse/MDEP-28?page=comments#action_71371 ] 

David J. M. Karlsen commented on MDEP-28:
-

Probably not:

In the copy-dependencies section the howto 
(http://maven.apache.org/plugins/maven-dependency-plugin/howto.html) states:


org.apache.maven.plugin
dependency-maven-plugin



should be:


maven-dependency-plugin



related in general to:
http://jira.codehaus.org/browse/MDEP-30

> Incorregect information on "How to use" web page
> 
>
> Key: MDEP-28
> URL: http://jira.codehaus.org/browse/MDEP-28
> Project: Maven 2.x Dependency Plugin
>  Issue Type: Improvement
>Reporter: Jimisola Laursen
>Priority: Trivial
>
> On the "How to use" web page 
> (http://mojo.codehaus.org/dependency-maven-plugin/howto.html)
> "" needs to be replaced with ""

-- 
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: (MJAVADOC-79) Review plugin documentation

[Maria Odea Ching (JIRA)]

 [ http://jira.codehaus.org/browse/MJAVADOC-79?page=all ]

Maria Odea Ching closed MJAVADOC-79.


Resolution: Fixed

> Review plugin documentation
> ---
>
> Key: MJAVADOC-79
> URL: http://jira.codehaus.org/browse/MJAVADOC-79
> Project: Maven 2.x Javadoc Plugin
>  Issue Type: Task
>Reporter: Maria Odea Ching
> Assigned To: Maria Odea Ching
> Attachments: MJAVADOC-79-alternate-doclet-wsmoak.diff
>
>  Time Spent: 1 day, 10 hours
>  Remaining Estimate: 0 minutes
>


-- 
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-158) Review and revise plugin documentation

[Maria Odea Ching (JIRA)]

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

Maria Odea Ching closed MSITE-158.
--

Resolution: Fixed

> Review and revise plugin documentation
> --
>
> Key: MSITE-158
> URL: http://jira.codehaus.org/browse/MSITE-158
> Project: Maven 2.x Site Plugin
>  Issue Type: Task
>Reporter: Maria Odea Ching
> Assigned To: Maria Odea Ching
>   Original Estimate: 1 day, 9 hours
>  Time Spent: 1 day, 6 hours
>  Remaining Estimate: 3 hours
>


-- 
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: (MPLUGIN-23) Review and revise plugin documentation

[Maria Odea Ching (JIRA)]

 [ http://jira.codehaus.org/browse/MPLUGIN-23?page=all ]

Maria Odea Ching closed MPLUGIN-23.
---

Resolution: Fixed

> Review and revise plugin documentation
> --
>
> Key: MPLUGIN-23
> URL: http://jira.codehaus.org/browse/MPLUGIN-23
> Project: Maven 2.x Plugin Plugin
>  Issue Type: Task
>Reporter: Maria Odea Ching
> Assigned To: Maria Odea Ching
>   Original Estimate: 22 hours
>  Time Spent: 21 hours
>  Remaining Estimate: 1 hour
>


-- 
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-1027) Upload Rhino 1.6R3 to ibiblio

[Matt Whitlock (JIRA)]

Upload Rhino 1.6R3 to ibiblio
-

 Key: MAVENUPLOAD-1027
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1027
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Matt Whitlock


http://www.mattwhitlock.com/js-1.6R3-bundle.jar

http://www.mozilla.org/rhino/

Rhino is an open-source implementation of JavaScript written entirely in Java. 
It is typically embedded into Java applications to provide scripting to end 
users.

The web site has not yet been updated to reflect the 1.6R3 release, but it is 
available at the download site:
ftp://ftp.mozilla.org/pub/mozilla.org/js/

The 1.6R3 download on that FTP site has a modification date of 24 July 2006.

-- 
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: (MAVEN-1125) ant:java fork issues

[Arnaud Heritier (JIRA)]

[ http://jira.codehaus.org/browse/MAVEN-1125?page=comments#action_71366 ] 

Arnaud Heritier commented on MAVEN-1125:


I 'll have a look at this issue

> ant:java fork issues
> 
>
> Key: MAVEN-1125
> URL: http://jira.codehaus.org/browse/MAVEN-1125
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 1.0-rc2
> Environment: Linux, JDK1.4.2
>Reporter: Andy Jefferson
> Assigned To: Arnaud Heritier
> Attachments: maven-console-test.jar
>
>
> I have a Java app that I want to invoke via Maven. The Java app uses stdin 
> and stdout. 
> If I invoke using ant:java using "fork=true" then stdin doesn not respond 
> correctly. That is, the app prompts, but the user can type to their hearts 
> content and nothing reaches the app.
> If I invoke using ant:java using "fork=false" then I get strange XML related 
> errors about unresolved references org/w3c/dom/Node, org/w3c/dom/Document

-- 
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: (MAVEN-1755) Backward Incompability : Usage of xml entities in the POM doesn't work in maven 1.1 beta 1 & 2

[Arnaud Heritier (JIRA)]

[ http://jira.codehaus.org/browse/MAVEN-1755?page=comments#action_71367 ] 

Arnaud Heritier commented on MAVEN-1755:


I'll try them. Thx for the idea.

> Backward Incompability : Usage of xml entities in the POM doesn't work in 
> maven 1.1 beta 1 & 2
> --
>
> Key: MAVEN-1755
> URL: http://jira.codehaus.org/browse/MAVEN-1755
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.1-beta-2, 1.1-beta-1, 1.1-beta-3
>Reporter: Arnaud Heritier
> Assigned To: Arnaud Heritier
>Priority: Critical
> Attachments: project-entities.zip
>
>
> In maven 1.0.X it was possible to use entities in the POM.
> It was used for example to share some elements like the organization, ...

-- 
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: (MANTRUN-55) Review Plugin Documentation

[Franz Allan Valencia See (JIRA)]

 [ http://jira.codehaus.org/browse/MANTRUN-55?page=all ]

Franz Allan Valencia See updated MANTRUN-55:


Attachment: MANTRUN-55-maven-antrun-plugin-3.patch

Changes with MANTRUN-55-maven-antrun-plugin-3.patch

In usage.html
* maven.dependency.classpath (Reported by Vincent Siveton)
* Review <<> (Reported by Vincent Siveton)
   - it seems that there is bug here (from what i can dig up in the maven 
user's mailing list) such that referencing maven.xxx.classpath's within the 
build.xml does not work. thus, i changed the example to a workaround (assigning 
the maven.xxx.classpath's value to an ant property). Furthermore, this page may 
not be needed in the future once Vincent Siventon's submits his example of 
using external build.xml
* changed "maven-dependencies-plugin" to "maven-dependency-plugin"

In FAQ.html
* "Maven for Ant Users" is for Maven1 and it's link is wrong (Reported by 
Vincent Siventon)
  - thus, i removed this link



> Review Plugin Documentation
> ---
>
> Key: MANTRUN-55
> URL: http://jira.codehaus.org/browse/MANTRUN-55
> Project: Maven 2.x Antrun Plugin
>  Issue Type: Task
>Reporter: Allan Ramirez
> Assigned To: Allan Ramirez
> Attachments: MANTRUN-55-maven-antrun-plugin-2.patch, 
> MANTRUN-55-maven-antrun-plugin-3.patch, MANTRUN-55-maven-antrun-plugin.patch
>
>   Original Estimate: 12 hours
>  Remaining Estimate: 12 hours
>


-- 
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: (MECLIPSE-137) Developed RAD-6 Plugin Extention

[Richard van Nieuwenhoven (JIRA)]

 [ http://jira.codehaus.org/browse/MECLIPSE-137?page=all ]

Richard van Nieuwenhoven updated MECLIPSE-137:
--

Attachment: maven-rad-plugin.tar.gz

sorry that it took so long but i was not at work...

this is the tarball with the plugin.
some hints for RAD6 users
- do not use java classes in a war project, put all java classes in dependent 
projects
- best thing to do is to make all jars in the war project provided and put them 
in the ear dependencys
- there will be a classpath directory included in ejb projects here you can put 
your generated ejb classes for nor i use the websphere-ant jobs in the 
project-pom to generate them. (in the package phase overwiting the jar and the 
client-jar and copieing the classes to the classes-folder included by this 
plugin, the ant-job does not generate the java files...)
- the META-INF of the ejb project MUST!!! be a toplevel folder so include this 
top-level-folder in your resources list of the pom (the java files can stay in 
src/main/java
- don't forget to fill the ".cvsignore" files especialy the jar's and wars in 
the ear-project's and the war-project's

regards,
Ritchie


> Developed RAD-6 Plugin Extention
> 
>
> Key: MECLIPSE-137
> URL: http://jira.codehaus.org/browse/MECLIPSE-137
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: New Feature
>Reporter: Richard van Nieuwenhoven
> Attachments: maven-rad-plugin.tar.gz
>
>
> I just finisched developing a RAD-6 (IBM Rational Application Developer 6.0) 
> extention to the eclipse plugin.
> It supports J2EE projects with the websphere development envorment, supported 
> are
> - EJB projects
> - Web projects
> - EAR- projects
> all these projects are recognized by rad-6 as what they. The websphere 
> development enviorment including hot-deployment features funktions out of the 
> box.
> i wrote writers for:
> - the ".j2ee" files
> - the "application.xml" and the "modulemaps" file
> - copying the extrenal libs in the ear project root
> - adapting the MANIFEST.MF of the projects (nessesary for the websphere 
> development enviorment)
> - the ".websettings" file
> - the ".websiteconfig" file
> - the ".project" (only alternative project natures/builders)
> do you want to include it the the eclipse plugin or sould it be an extra 
> plugin? i should not be complicated to include it because i did the real work 
> in writer-classes.
> should i add a tgz with the sources? or how do you want the sources?

-- 
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-2471) Add search box to the index page

[Denis Cabasson (JIRA)]

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

Denis Cabasson commented on MNG-2471:
-

Now, that is a big box!!!

Isn't there a way to make the Google logo a bit smaller? (I guess there are 
legals considerations there).

For the design part, I would prefer 2 separate boxes for search and download.

Would it be possible to add a radio button to include search in the 
mojo.codehaus.org domain (in addition to maven.apache.org) (maybe legal 
considerations there too)?

> Add search box to the index page
> 
>
> Key: MNG-2471
> URL: http://jira.codehaus.org/browse/MNG-2471
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Documentation:  General
>Reporter: Marvin King
> Assigned To: Marvin King
> Attachments: index.html, MNG-2471-site.patch
>
>
>   - google for now

-- 
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-2471) Add search box to the index page

[Marvin King (JIRA)]

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

Marvin King commented on MNG-2471:
--


 the search box will only search within the maven site.

> Add search box to the index page
> 
>
> Key: MNG-2471
> URL: http://jira.codehaus.org/browse/MNG-2471
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Documentation:  General
>Reporter: Marvin King
> Assigned To: Marvin King
> Attachments: index.html, MNG-2471-site.patch
>
>
>   - google for now

-- 
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: (MPXDOC-197) report fails if repository is not defined

[Piotr Kania (JIRA)]

report fails if repository is not defined
-

 Key: MPXDOC-197
 URL: http://jira.codehaus.org/browse/MPXDOC-197
 Project: maven-xdoc-plugin
  Issue Type: Bug
Affects Versions: 1.10
 Environment: maven 1.1-beta-3-SNAPSHOT(20060729), Operating system 
Windows 2000
Reporter: Piotr Kania


If project definition contain empty repository tag then report fails:

Project definition


3
rfl-project-main
RFL Project Main
${groupId}
${version}



maven-faq-plugin  
maven-multiproject-plugin
maven-dashboard-plugin
 



xdoc:register-reports:
faq:init:

maven-faq-plugin:register:


xdoc:generate-from-pom:
[echo] Generating xdocs from POM ...





BUILD FAILED
org.apache.velocity.exception.ResourceNotFoundException: Unable to find 
resource 'scm/${connscm}.xml
'
at 
org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl
.java:458)
at 
org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.
java:341)
at 
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:831)
at org.apache.velocity.runtime.directive.Parse.render(Parse.java:141)
at 
org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:114)
at 
org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:55)
at 
org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:230)
at 
org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:89)
at 
org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:230)
at org.apache.velocity.Template.merge(Template.java:256)
at 
org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:450)
at 
org.apache.commons.jelly.tags.velocity.MergeTag.mergeTemplate(MergeTag.java:186)
at 
org.apache.commons.jelly.tags.velocity.MergeTag.doTag(MergeTag.java:68)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
at org.apache.commons.jelly.tags.core.WhenTag.doTag(WhenTag.java:46)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
at org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:38)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
at 
org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:150)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:82)
at 
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag
.java:115)
at org.apache.maven.werkz.Goal.fire(Goal.java:647)
at org.apache.maven.werkz.Goal.attain(Goal.java:582)
at org.apache.maven.werkz.Goal.attainPrecursors(Goal.java:494)
at org.apache.maven.werkz.Goal.attain(Goal.java:580)
at org.apache.maven.werkz.WerkzProject.attainGoal(WerkzProject.java:208)
at 
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:114)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:82)
at 
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag
.java:115)
at org.apache.maven.werkz.Goal.fire(Goal.java:647)
at org.apache.maven.werkz.Goal.attain(Goal.java:582)
at 
org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:709)
at org.apache.maven.MavenSession.attainGoals(MavenSession.java:264)
at org.apache.maven.cli.App.doMain(App.java:546)
at org.apache.maven.cli.App.main(App.java:1390)
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 com.werken.forehead.Forehead.run(F