date:20090124

[jira] Commented: (MSHADE-30) duplicate entry error

2009-01-24 Thread Benjamin Bentmann (JIRA)


[ 
http://jira.codehaus.org/browse/MSHADE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162288#action_162288
 ] 

Benjamin Bentmann commented on MSHADE-30:
-

bq. [...] if you run it for the entire structure, it errs with the same thing.
Yeah, another known issue: MNG-3284

 duplicate entry error
 -

 Key: MSHADE-30
 URL: http://jira.codehaus.org/browse/MSHADE-30
 Project: Maven 2.x Shade Plugin
  Issue Type: Bug
Affects Versions: 1.0.1
Reporter: Michael Mattox
Assignee: Benjamin Bentmann
 Fix For: 1.2

 Attachments: mshade-30-patch.txt


 I receive this error:
 Embedded error: duplicate entry: org/apache/xmlbeans/FilterXmlObject.class
 It started with a javax.xml.namespace class.  So I started putting excludes, 
 and then I kept getting one new class after another.  If I exclude everything 
 then I doubt my application is going to work.
 I really don't understand this error.  I have never seen this type of error 
 with the fatjar eclipse plugin.  I understand it's complaining about having 
 the same class twice, but if it's not a problem for my eclipse project or the 
 maven build, why is it a problem for shade?
 I feel the shade plugin should be able to handle this gracefully.

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

[jira] Commented: (DOXIA-277) Specify the language identification

2009-01-24 Thread Dennis Lundberg (JIRA)

[
http://jira.codehaus.org/browse/DOXIA-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162293#action_162293
]

Dennis Lundberg commented on DOXIA-277:
---

The language identification needs to be dynamic to work properly, and I'm not
sure it will even work with that.

Example 1
A Maven generated site with multiple languages
Doxia needs to be told which language the pages are in. For each of the
non-default languages there should be no problem, because the docs are in a
directory named after the language id.

Example 2
A Maven generated site in a single language - not English. We have company
internal documentation in Swedish only.
How does Doxia know which language it is in? It is not mentioned in the
document sources.

Specify the language identification
---

Key: DOXIA-277
URL: http://jira.codehaus.org/browse/DOXIA-277
Project: Maven Doxia
Issue Type: Improvement
Components: Module - Xhtml
Affects Versions: 1.1
Reporter: Vincent Siveton

Actually, the sink generates:
{noformat}
html xmlns=http://www.w3.org/1999/xhtml;
{noformat}
We need to add the language identification i.e.
{noformat}
html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en lang=en
{noformat}

--
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-3271) excludeDefaults does not seem to work

2009-01-24 Thread Benjamin Bentmann (JIRA)


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

Benjamin Bentmann closed MNG-3271.
--

 Assignee: Benjamin Bentmann
   Resolution: Fixed
Fix Version/s: (was: 2.0.x)
   2.1.0-M2
   2.0.10

Fixed by Brett in 
[r705567|http://svn.eu.apache.org/viewvc?view=revrevision=705567] and 
[r705574|http://svn.eu.apache.org/viewvc?view=revrevision=705574], 
respectively.

 excludeDefaults does not seem to work
 ---

 Key: MNG-3271
 URL: http://jira.codehaus.org/browse/MNG-3271
 Project: Maven 2
  Issue Type: Bug
  Components: POM
Affects Versions: 2.0.7
Reporter: Grégory Joseph
Assignee: Benjamin Bentmann
 Fix For: 2.0.10, 2.1.0-M2


 As far as I understand, adding
 excludeDefaultstrue/excludeDefaults
 in the  reporting  section of my pom should have the same effect as
 {code}
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-project-info-reports-plugin/artifactId
 reportSets
 reportSet/reportSet
 /reportSets
 /plugin
 {code}
 ... but only that latter had any effect.
 (I was mainly trying to disable the dependencies report, because I have many 
 dependencies build with m1 which don't have a proper m2 pom)

-- 
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: (MDEPLOY-44) Add uniqueVersion parameter to deploy goal as deploy-file goal

2009-01-24 Thread JIRA


[ 
http://jira.codehaus.org/browse/MDEPLOY-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162310#action_162310
 ] 

Thorsten Möller commented on MDEPLOY-44:


The proposed workaround by Kalle Korhonen does not work for me either (using 
Maven 2.0.9 and deploy plugin 2.4).

I really appreciate if this issue would be fixed!

Thanks,
Thorsten

 Add uniqueVersion parameter to deploy goal as deploy-file goal
 --

 Key: MDEPLOY-44
 URL: http://jira.codehaus.org/browse/MDEPLOY-44
 Project: Maven 2.x Deploy Plugin
  Issue Type: Improvement
Affects Versions: 2.2.1
 Environment: Maven 2.0.4
Reporter: David Vicente

 We developp a big application which we deploy in our local repository with 
 deploy goal.
 But deploy goal use a timestamp to name the archive file and we have many 
 problems of disk space that obliges us to clean manually our local repository.
 it's possible to add the uniqueVersion parameter to deploy goal as done with 
 deploy-file goal which would remove us the obligation to purge ?
 thanks

-- 
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: (MDEPLOY-93) Deploy plugin does not honor modification of final name by assembly plugin

2009-01-24 Thread JIRA

Deploy plugin does not honor modification of final name by assembly plugin
--

 Key: MDEPLOY-93
 URL: http://jira.codehaus.org/browse/MDEPLOY-93
 Project: Maven 2.x Deploy Plugin
  Issue Type: Bug
Affects Versions: 2.4
Reporter: Thorsten Möller


When using the Maven assembly plugin to create an assembly for a project and 
using fileName parameter inside the plugin to change the final name of the 
assembly this new name will not be used by the deploy plugin. The deploy plugin 
always uses the default behavior. The following excerpt from a POM illustrates 
this:

groupIdmyGoupID/groupId
artifactIdmyArtifactID/artifactId
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-assembly-plugin/artifactId
configuration
descriptors

descriptorsrc/main/assembly/bin.xml/descriptor
/descriptors
appendAssemblyIdfalse/appendAssemblyId
finalNamefoo/finalName
tarLongFileModegnu/tarLongFileMode
/configuration
executions
execution
idminimal/id
phasepackage/phase
goals
goalsingle/goal
/goals
/execution
/executions
/plugin
/plugins
/build

With this configuration an assembly named foo.{tar.gz|zip} will be created in 
the target folder of the project (note that the artifact is attached because 
the assembly plugin is attached to the package lifecycle phase). However, when 
deploying the project file to the distribution repository it will be named 
myArtifactId.{tar.gz|zip}, which is the default behavior if finalName is 
not specified. Interesting is that in the local repository the file name always 
corresponds to what is specified by fileName, just for the distribution 
repository the parameter is not honored.

BTW, the other parameter appendAssemblyId is honored correctly, i.e,  
depending on the boolean value the assembly Id will be appended to the name, or 
not.



-- 
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: (MDEPLOY-93) Deploy plugin does not honor modification of final name by assembly plugin

2009-01-24 Thread JIRA


[ 
http://jira.codehaus.org/browse/MDEPLOY-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162312#action_162312
 ] 

Thorsten Möller commented on MDEPLOY-93:


I forgot to mention that the bug was observed when using Maven 2.0.9, assembly 
plugin 2.2-beta-3, and deploy plugin 2.4.

 Deploy plugin does not honor modification of final name by assembly plugin
 --

 Key: MDEPLOY-93
 URL: http://jira.codehaus.org/browse/MDEPLOY-93
 Project: Maven 2.x Deploy Plugin
  Issue Type: Bug
Affects Versions: 2.4
Reporter: Thorsten Möller

 When using the Maven assembly plugin to create an assembly for a project and 
 using fileName parameter inside the plugin to change the final name of the 
 assembly this new name will not be used by the deploy plugin. The deploy 
 plugin always uses the default behavior. The following excerpt from a POM 
 illustrates this:
 groupIdmyGoupID/groupId
 artifactIdmyArtifactID/artifactId
 build
   plugins
   plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-assembly-plugin/artifactId
   configuration
   descriptors
   
 descriptorsrc/main/assembly/bin.xml/descriptor
   /descriptors
   appendAssemblyIdfalse/appendAssemblyId
   finalNamefoo/finalName
   tarLongFileModegnu/tarLongFileMode
   /configuration
   executions
   execution
   idminimal/id
   phasepackage/phase
   goals
   goalsingle/goal
   /goals
   /execution
   /executions
   /plugin
   /plugins
 /build
 With this configuration an assembly named foo.{tar.gz|zip} will be created 
 in the target folder of the project (note that the artifact is attached 
 because the assembly plugin is attached to the package lifecycle phase). 
 However, when deploying the project file to the distribution repository it 
 will be named myArtifactId.{tar.gz|zip}, which is the default behavior if 
 finalName is not specified. Interesting is that in the local repository the 
 file name always corresponds to what is specified by fileName, just for the 
 distribution repository the parameter is not honored.
 BTW, the other parameter appendAssemblyId is honored correctly, i.e,  
 depending on the boolean value the assembly Id will be appended to the name, 
 or not.

-- 
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: (DOXIA-277) Specify the language identification

2009-01-24 Thread Vincent Siveton (JIRA)


[ 
http://jira.codehaus.org/browse/DOXIA-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162313#action_162313
 ] 

Vincent Siveton commented on DOXIA-277:
---

The Doxia API (forget the Maven integration) misses this feature in xdoc, 
docbook and xhtml

Yes it should be dynamic, I imagine this integration with Maven:
- the Maven site plugin allows i18n by directories and with 
site.xml/site_LANG.xml using the _locales_ parameter. The default language id 
could be the default locale language for the default site, and the locale 
language from the language dir. So, you could defined localesse/locales and 
all your documents in the default site will be tagged as Swedish.
- known limitation: in a given site (default or i18n dir) you *should* have the 
same language in all documents inside.


 Specify the language identification
 ---

 Key: DOXIA-277
 URL: http://jira.codehaus.org/browse/DOXIA-277
 Project: Maven Doxia
  Issue Type: Improvement
  Components: Module - Xhtml
Affects Versions: 1.1
Reporter: Vincent Siveton

 Actually, the sink generates:
 {noformat}
 html xmlns=http://www.w3.org/1999/xhtml;
 {noformat}
 We need to add the language identification i.e.
 {noformat}
 html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en lang=en
 {noformat}

-- 
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: (MDEPLOY-44) Add uniqueVersion parameter to deploy goal as deploy-file goal

2009-01-24 Thread Benjamin Bentmann (JIRA)


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

Benjamin Bentmann updated MDEPLOY-44:
-

Attachment: MDEPLOY-44.zip

The approach described by Kalle is not a workaround but the primary means to 
control the snapshot naming. The attached demo project works for me. 

The only pitfall I could imagine here is that people have a dedicated 
{{snapshotRepository}} configured in their POM but set the 
{{uniqueVersion}} flag on the {{repository}} element instead of 
{{snapshotRepository}}.

bq. But, it'd be very useful if you could override uniqueVersion setting from 
the command line.
That's already possible via a profile that overrides {{snapshotRepository}}.

Please provide more details (debug log, demo project) if the usage of 
{{uniqueVersionfalse/uniqueVersion}} really does not work.

 Add uniqueVersion parameter to deploy goal as deploy-file goal
 --

 Key: MDEPLOY-44
 URL: http://jira.codehaus.org/browse/MDEPLOY-44
 Project: Maven 2.x Deploy Plugin
  Issue Type: Improvement
Affects Versions: 2.2.1
 Environment: Maven 2.0.4
Reporter: David Vicente
 Attachments: MDEPLOY-44.zip


 We developp a big application which we deploy in our local repository with 
 deploy goal.
 But deploy goal use a timestamp to name the archive file and we have many 
 problems of disk space that obliges us to clean manually our local repository.
 it's possible to add the uniqueVersion parameter to deploy goal as done with 
 deploy-file goal which would remove us the obligation to purge ?
 thanks

-- 
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: (MDEPLOY-44) Add uniqueVersion parameter to deploy goal as deploy-file goal

2009-01-24 Thread Benjamin Bentmann (JIRA)


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

Benjamin Bentmann closed MDEPLOY-44.


  Assignee: Benjamin Bentmann
Resolution: Won't Fix

 Add uniqueVersion parameter to deploy goal as deploy-file goal
 --

 Key: MDEPLOY-44
 URL: http://jira.codehaus.org/browse/MDEPLOY-44
 Project: Maven 2.x Deploy Plugin
  Issue Type: Improvement
Affects Versions: 2.2.1
 Environment: Maven 2.0.4
Reporter: David Vicente
Assignee: Benjamin Bentmann
 Attachments: MDEPLOY-44.zip


 We developp a big application which we deploy in our local repository with 
 deploy goal.
 But deploy goal use a timestamp to name the archive file and we have many 
 problems of disk space that obliges us to clean manually our local repository.
 it's possible to add the uniqueVersion parameter to deploy goal as done with 
 deploy-file goal which would remove us the obligation to purge ?
 thanks

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

[jira] Created: (MSITE-378) Support polymorphism for menu inheritance

2009-01-24 Thread JIRA

Support polymorphism for menu inheritance
-

 Key: MSITE-378
 URL: http://jira.codehaus.org/browse/MSITE-378
 Project: Maven 2.x Site Plugin
  Issue Type: New Feature
  Components: inheritance
Affects Versions: 2.0-beta-7
Reporter: Thorsten Möller


Inheritance of menus in an multimodule project environment does not work as 
intuitively expected (as in OO languages). The following excerpts try to 
illustrate this. Assume there is a root project R that has one module (project) 
S. Both contain a site descriptor. Let the site descriptor for R be as follows:

{code:xml}
project name=${project.name}

!-- ... --

body
menu name=Main
item name=Introduction href=/index.html /
item name=News href=/news.html /
item name=Overwrite href=/documentation.html /
/menu
/body

!-- ... --

/project
{code}


And let the site descriptor for S be:

{code:xml}
project name=${project.name}

!-- ... --

body
menu name=Main
item name=Introduction href=/index.html /
item name=Overwrite href=/overwrite.html /
item name=Added href=/added.html /
/menu
/body

!-- ... --

/project
{code}

As I'm used to the way inheritance and polymorphism are defined in OO languages 
such as Java, I would expect the following properties for the Main menu in S:
- item Introduction is overwritten in S but refers to the same index.html 
file; of course, its path is relative to start directory of S
- item News is missing for S but will be inherited from R, thus, it will be 
rendered to the site as in R
- item Overwrite is overwritten in S and refers now to overwrite.html 
(instead of documentation.html as in R)
- item Added is new in S, thus, it will be rendered to the site in addition

Unfortunately, with the current implementation of the site plugin inheritance 
is as follows:
- Main menu of R is inherited by S as-is, that is, all changes made to the 
menu in S are not visible/rendered to the site.

I would like to propose to implement polymorphism regarding menu inheritance as 
described above. In addition, I would like to propose a new boolean parameter 
inherited (or inherit) that can be added to menu items. Its semantics would 
be equivalent to the inherited tag in pom.xml. In the following one example 
for R:

{code:xml}
project name=${project.name}

!-- ... --

body
menu name=Main
item name=Introduction href=/index.html /
item name=News 1 href=/news1.html  
inherited=false/
item name=News 2 href=/news2.html  
inherited=true/
item name=Overwrite href=/documentation.html /
/menu
/body

!-- ... --

/project
{code}

With this example only menu item News 2 would appear in S because its 
inheritance is not disabled, while menu item News 1 appears only in R and not 
in S because its inheritance was disabled (false). The default if the parameter 
is missing should be true.

Btw, the same extension should be made to the menu ...  tag to allow to 
enable or disable inheritance of menus entirely.

Regards,
Thorsten



-- 
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: (MSITE-378) Support polymorphism for menu inheritance

2009-01-24 Thread Mark Struberg (JIRA)

[
http://jira.codehaus.org/browse/MSITE-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162324#action_162324
]

Mark Struberg commented on MSITE-378:
-

There was such a functionality in a very rudimentary form in beta-6 already,
but it did not work properly.

{noformat}
Site descriptors are inherited along the same lines as project descriptors are.
When you deploy a project, its site descriptor is also deployed so that it can
be inherited.

By default, only the basic settings are inherited. From the body, only the
links are inherited, and these accumulate to contain all the parents' site
descriptor links.

However, it is possible to inherit menus as well. To do so, use the inherit
attribute in the site descriptor. This can be either top or bottom , indicating
where in the menu it will be placed after inheritance. For example:
{noformat}
See
http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html
for more information

This has lead to menu items in sub menus which are not intended because even if
you inherit a menu entry to news1.html, where does the page come from?

I am cured from this weird behaviour since I use beta-7 now.

To only inherit menu items is simply not enough sadly...

Support polymorphism for menu inheritance
-

Key: MSITE-378
URL: http://jira.codehaus.org/browse/MSITE-378
Project: Maven 2.x Site Plugin
Issue Type: New Feature
Components: inheritance
Affects Versions: 2.0-beta-7
Reporter: Thorsten Möller

Inheritance of menus in an multimodule project environment does not work as
intuitively expected (as in OO languages). The following excerpts try to
illustrate this. Assume there is a root project R that has one module
(project) S. Both contain a site descriptor. Let the site descriptor for R be
as follows:
{code:xml}
project name=${project.name}
!-- ... --
body
menu name=Main
item name=Introduction href=/index.html /
item name=News href=/news.html /
item name=Overwrite href=/documentation.html /
/menu
/body
!-- ... --

/project
{code}
And let the site descriptor for S be:
{code:xml}
project name=${project.name}
!-- ... --
body
menu name=Main
item name=Introduction href=/index.html /
item name=Overwrite href=/overwrite.html /
item name=Added href=/added.html /
/menu
/body
!-- ... --

/project
{code}
As I'm used to the way inheritance and polymorphism are defined in OO
languages such as Java, I would expect the following properties for the
Main menu in S:
- item Introduction is overwritten in S but refers to the same index.html
file; of course, its path is relative to start directory of S
- item News is missing for S but will be inherited from R, thus, it will be
rendered to the site as in R
- item Overwrite is overwritten in S and refers now to overwrite.html
(instead of documentation.html as in R)
- item Added is new in S, thus, it will be rendered to the site in addition
Unfortunately, with the current implementation of the site plugin inheritance
is as follows:
- Main menu of R is inherited by S as-is, that is, all changes made to the
menu in S are not visible/rendered to the site.
I would like to propose to implement polymorphism regarding menu inheritance
as described above. In addition, I would like to propose a new boolean
parameter inherited (or inherit) that can be added to menu items. Its
semantics would be equivalent to the inherited tag in pom.xml. In the
following one example for R:
{code:xml}
project name=${project.name}
!-- ... --
body
menu name=Main
item name=Introduction href=/index.html /
item name=News 1 href=/news1.html
inherited=false/
item name=News 2 href=/news2.html
inherited=true/
item name=Overwrite href=/documentation.html /
/menu
/body
!-- ... --

/project
{code}
With this example only menu item News 2 would appear in S because its
inheritance is not disabled, while menu item News 1 appears only in R and
not in S because its inheritance was disabled (false). The default if the
parameter is missing should be true.
Btw, the same extension should be made to the menu ... tag to allow to
enable or disable inheritance of menus entirely.
Regards,
Thorsten

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

[jira] Closed: (MNG-3885) Modules of Maven projects are deployed with Timestamp during reactor build when uniqueVersion is set to false in parent profile

2009-01-24 Thread Benjamin Bentmann (JIRA)


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

Benjamin Bentmann closed MNG-3885.
--

 Assignee: Benjamin Bentmann
   Resolution: Fixed
Fix Version/s: 2.1.0-M1
   2.0.11

Fixed in [r737402|http://svn.eu.apache.org/viewvc?view=revrevision=737402]. 
Already works in Maven 2.1.x as of 
[r689163|http://svn.eu.apache.org/viewvc?view=revrevision=689163].

 Modules of Maven projects are deployed with Timestamp during reactor build 
 when uniqueVersion is set to false in parent profile
 ---

 Key: MNG-3885
 URL: http://jira.codehaus.org/browse/MNG-3885
 Project: Maven 2
  Issue Type: Bug
  Components: Deployment
Affects Versions: 2.0.8
 Environment: Red Hat Linux, Maven 2.0.8, Java 1.6, Cruisecontrol
Reporter: Matthias Wegerhoff
Assignee: Benjamin Bentmann
 Fix For: 2.0.11, 2.1.0-M1

 Attachments: minimizedPOM.xml, minimizedPOM.xml, 
 minimizedSETTINGS.xml, MNG-3885.zip


 When deploying artifacts into local repository with cruisecontrol by using 
 the following command:
 mvn -U -P mvn-profile  ...  -DuniqueVersion=false deploy
 The parent is always beeing deployed correctly, without timestamp as 
 MODULE_VERSION-SNAPSHOT. But all Modules are beeing deployed with Timestamp.

-- 
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: (MDEPLOY-44) Add uniqueVersion parameter to deploy goal as deploy-file goal

2009-01-24 Thread Benjamin Bentmann (JIRA)


[ 
http://jira.codehaus.org/browse/MDEPLOY-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162331#action_162331
 ] 

Benjamin Bentmann commented on MDEPLOY-44:
--

There was indeed a bug with the handling of {{uniqueVersion}} in the Maven 
core (MNG-3885) in combination with profiles and inheritance.

 Add uniqueVersion parameter to deploy goal as deploy-file goal
 --

 Key: MDEPLOY-44
 URL: http://jira.codehaus.org/browse/MDEPLOY-44
 Project: Maven 2.x Deploy Plugin
  Issue Type: Improvement
Affects Versions: 2.2.1
 Environment: Maven 2.0.4
Reporter: David Vicente
Assignee: Benjamin Bentmann
 Attachments: MDEPLOY-44.zip


 We developp a big application which we deploy in our local repository with 
 deploy goal.
 But deploy goal use a timestamp to name the archive file and we have many 
 problems of disk space that obliges us to clean manually our local repository.
 it's possible to add the uniqueVersion parameter to deploy goal as done with 
 deploy-file goal which would remove us the obligation to purge ?
 thanks

-- 
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: (MDEPLOY-57) uniqueVersionfalse/uniqueVersion not honored inside profile

2009-01-24 Thread Benjamin Bentmann (JIRA)


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

Benjamin Bentmann closed MDEPLOY-57.


  Assignee: Benjamin Bentmann
Resolution: Duplicate

This was actually a bug in the Maven core (MNG-3885).

 uniqueVersionfalse/uniqueVersion not honored inside profile
 -

 Key: MDEPLOY-57
 URL: http://jira.codehaus.org/browse/MDEPLOY-57
 Project: Maven 2.x Deploy Plugin
  Issue Type: Bug
Affects Versions: 2.3
 Environment: Windows XP SP2
 Maven 2.0.7
 Java 6 U1
Reporter: Matthew McCullough
Assignee: Benjamin Bentmann
Priority: Critical
 Attachments: effectivepom2.txt, pom.xml


 I am invoking maven as:
 mvn deploy -DCCDistribution
 The appropriate section of my pom.xml is below.
 In the attachment, I've provided the redirected output of mvn 
 help:effective-pom -DCCDistribution.
 And lastly, I've provided a snippet of build console output.
 - SECTION OF POMNOT BEING HONORED 
  profile
   idCCDistribution/id
   activation
 property
   nameCCDistribution/name
 /property
   /activation
   distributionManagement
 repository
 idKenanFX_M2_Repo/id
 nameKenanFX Maven 2 Repository/name
 urlftp://maven.kenan.com/KenanFX/m2_repo/url
 uniqueVersionfalse/uniqueVersion
 /repository
   /distributionManagement
 /profile
  CONSOLE OUTPUT SNIPPET SHOWING UNIQUE DATESTAMPED VERSIONS, 
 THOUGH NONUNIQUE ARE DESIRED 
 [INFO] 
 
 [INFO] Building CCBS UDT Functional API
 [INFO]task-segment: [deploy]
 [INFO] 
 
 [INFO] [site:attach-descriptor]
 [INFO] [install:install]
 [INFO] Installing c:\ClearCaseSource\mccm03_view3\single_api_src\udt\pom.xml 
 to C:\Documents and Settings\mccm03\.m2\repository\com\comverse\api\udt\c
 cbs-udt\1.0.M1-SNAPSHOT\ccbs-udt-1.0.M1-SNAPSHOT.pom
 [INFO] [deploy:deploy]
 altDeploymentRepository = null
 [INFO] Retrieving previous build number from KenanFX_M2_Repo
 Uploading: 
 ftp://maven.kenan.com/KenanFX/m2_repo/com/comverse/api/udt/ccbs-udt/1.0.M1-SNAPSHOT/ccbs-udt-1.0.M1-SNAPSHOT.pom
 721b uploaded
 [INFO] Retrieving previous metadata from KenanFX_M2_Repo
 [INFO] Uploading repository metadata for: 'artifact 
 com.comverse.api.udt:ccbs-udt'
 [INFO] Retrieving previous metadata from KenanFX_M2_Repo
 [INFO] Uploading repository metadata for: 'snapshot 
 com.comverse.api.udt:ccbs-udt:1.0.M1-SNAPSHOT'
 [INFO] 
 
 [INFO] Building CCBS UDT Shared
 [INFO]task-segment: [deploy]
 [INFO] 
 
 [INFO] [resources:resources]
 [INFO] Using default encoding to copy filtered resources.
 [INFO] [compiler:compile]
 [INFO] Nothing to compile - all classes are up to date
 [INFO] [resources:testResources]
 [INFO] Using default encoding to copy filtered resources.
 [INFO] [compiler:testCompile]
 [INFO] Not compiling test sources
 [INFO] [surefire:test]
 [INFO] Tests are skipped.
 [INFO] [jar:jar]
 [INFO] Building jar: 
 C:\ClearCaseSource\mccm03_view3\single_api_src\udt\shared\target\ccbs-udt-shared-1.0.M1-SNAPSHOT.jar
 [INFO] [install:install]
 [INFO] Installing 
 C:\ClearCaseSource\mccm03_view3\single_api_src\udt\shared\target\ccbs-udt-shared-1.0.M1-SNAPSHOT.jar
  to C:\Documents and Settings\mc
 cm03\.m2\repository\com\comverse\api\udt\ccbs-udt-shared\1.0.M1-SNAPSHOT\ccbs-udt-shared-1.0.M1-SNAPSHOT.jar
 [INFO] [deploy:deploy]
 altDeploymentRepository = null
 [INFO] Retrieving previous build number from KenanFX_M2_Repo
 Uploading: 
 ftp://maven.kenan.com/KenanFX/m2_repo/com/comverse/api/udt/ccbs-udt-shared/1.0.M1-SNAPSHOT/ccbs-udt-shared-1.0.M1-20070718.004617-1.jar
 6K uploaded
 [INFO] Retrieving previous metadata from KenanFX_M2_Repo
 [INFO] Uploading repository metadata for: 'artifact 
 com.comverse.api.udt:ccbs-udt-shared'
 [INFO] Retrieving previous metadata from KenanFX_M2_Repo
 [INFO] Uploading repository metadata for: 'snapshot 
 com.comverse.api.udt:ccbs-udt-shared:1.0.M1-SNAPSHOT'
 [INFO] Retrieving previous metadata from KenanFX_M2_Repo

-- 
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: (WAGON-256) FTP deploy

2009-01-24 Thread Benjamin Bentmann (JIRA)


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

Benjamin Bentmann moved MDEPLOY-72 to WAGON-256:


Affects Version/s: (was: 2.3)
   1.0-beta-2
  Key: WAGON-256  (was: MDEPLOY-72)
  Project: Maven Wagon  (was: Maven 2.x Deploy Plugin)

 FTP deploy
 --

 Key: WAGON-256
 URL: http://jira.codehaus.org/browse/WAGON-256
 Project: Maven Wagon
  Issue Type: Bug
Affects Versions: 1.0-beta-2
Reporter: Artem Pasko

 I use the following command 
 {code}
 mvn deploy:deploy-file -DgroupId=my.product -DartifactId=myproduct 
 -Dversion=1.1 
 -Dpackaging=jar -Dfile=D:\myproduct.jar -Durl=ftp://ftp.mycompany.com/maven2 
 -DrepositoryId=mycompanyftp
 {code}
 and get the error
 {code}
 [INFO] Scanning for projects...
 [INFO] Searching repository for plugin with prefix: 'deploy'.
 [INFO] 
 
 [INFO] Building downloader-web
 [INFO]task-segment: [deploy:deploy-file] (aggregator-style)
 [INFO] 
 
 [INFO] [deploy:deploy-file]
 Uploading: 
 ftp://ftp.mycompany.com/maven2/my/product/myproduct/1.1/myproduct.jar
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] Error deploying artifact: Required directory: '/maven2' is missing
 [INFO] 
 
 [INFO] For more information, run Maven with the -e switch
 [INFO] 
 
 [INFO] Total time: 1 second
 [INFO] Finished at: Wed Jan 30 13:55:28 EET 2008
 [INFO] Final Memory: 2M/6M
 [INFO] 
 
 {code}
 and stacktrace
 {code}
 [INFO] Trace
 org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying 
 artifact
 : Required directory: '/maven2' is missing
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
 ultLifecycleExecutor.java:564)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone
 Goal(DefaultLifecycleExecutor.java:493)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
 ltLifecycleExecutor.java:463)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
 dleFailures(DefaultLifecycleExecutor.java:311)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
 ts(DefaultLifecycleExecutor.java:224)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
 fecycleExecutor.java:143)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
 java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
 sorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at 
 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 Caused by: org.apache.maven.plugin.MojoExecutionException: Error deploying 
 artif
 act: Required directory: '/maven2' is missing
 at 
 org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.
 java:243)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
 nManager.java:447)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
 ultLifecycleExecutor.java:539)
 ... 16 more
 Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException: 
 Error
  deploying artifact: Required directory: '/maven2' is missing
 at 
 org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(Def
 aultArtifactDeployer.java:94)
 at 
 org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.
 java:239)
 ... 18 more
 Caused by: org.apache.maven.wagon.TransferFailedException: Required 
 directory: '
 /maven2' is missing
 at 
 org.apache.maven.wagon.providers.ftp.FtpWagon.fillOutputData(FtpWagon
 .java:232)
 at org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:133)
 at

[jira] Updated: (WAGON-256) FTP deploy

2009-01-24 Thread Benjamin Bentmann (JIRA)


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

Benjamin Bentmann updated WAGON-256:


Description: 
I use the following command 
{code}
mvn deploy:deploy-file -DgroupId=my.product -DartifactId=myproduct 
-Dversion=1.1 
-Dpackaging=jar -Dfile=D:\myproduct.jar -Durl=ftp://ftp.mycompany.com/maven2 
-DrepositoryId=mycompanyftp
{code}
and get the error
{code}
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'deploy'.
[INFO] 
[INFO] Building downloader-web
[INFO]task-segment: [deploy:deploy-file] (aggregator-style)
[INFO] 
[INFO] [deploy:deploy-file]
Uploading: ftp://ftp.mycompany.com/maven2/my/product/myproduct/1.1/myproduct.jar
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Error deploying artifact: Required directory: '/maven2' is missing

[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 1 second
[INFO] Finished at: Wed Jan 30 13:55:28 EET 2008
[INFO] Final Memory: 2M/6M
[INFO] 
{code}
and stacktrace
{code}
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying 
artifact: Required directory: '/maven2' is missing
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error deploying 
artifact: Required directory: '/maven2' is missing
at 
org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.java:243)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
... 16 more
Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException: 
Error deploying artifact: Required directory: '/maven2' is missing
at 
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:94)
at 
org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.java:239)
... 18 more
Caused by: org.apache.maven.wagon.TransferFailedException: Required directory: 
'/maven2' is missing
at 
org.apache.maven.wagon.providers.ftp.FtpWagon.fillOutputData(FtpWagon.java:232)
at org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:133)
at 
org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:237)
at 
org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:153)
at 
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:80)
... 19 more
{code}
The maven2 directory is present on ftp and i can connect to it.
I look to the FtpWagon.fillOutputData() method and find the code which throw 
exception
{code}
if(!ftp.changeWorkingDirectory(getRepository().getBasedir()))
throw new TransferFailedException(Required

[jira] Commented: (MSITE-378) Support polymorphism for menu inheritance

2009-01-24 Thread JIRA


[ 
http://jira.codehaus.org/browse/MSITE-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162336#action_162336
 ] 

Thorsten Möller commented on MSITE-378:
---

bq. This has lead to menu items in sub menus which are not intended because 
even if you inherit a menu entry to news1.html, where does the page come from?

O.k., to clarify this I give the directory structure for S and R (second 
example) and assuming only *.apt files:

{code}
R/src/site/apt/
 |
 +-- index.apt
 +-- news1.apt
 +-- news2.apt
 +-- documentation.apt
{code}

{code}
S/src/site/apt/
 |
 +-- index.apt
 +-- news2.apt
 +-- overwrite.apt
 +-- added.apt
{code}

And I just realized that with the proposed polymorphism one detail problem 
arises, which is the *order* in which to render the menu items eventually. I 
would suggest to use that order implied at the lowest level.



 Support polymorphism for menu inheritance
 -

 Key: MSITE-378
 URL: http://jira.codehaus.org/browse/MSITE-378
 Project: Maven 2.x Site Plugin
  Issue Type: New Feature
  Components: inheritance
Affects Versions: 2.0-beta-7
Reporter: Thorsten Möller

 Inheritance of menus in an multimodule project environment does not work as 
 intuitively expected (as in OO languages). The following excerpts try to 
 illustrate this. Assume there is a root project R that has one module 
 (project) S. Both contain a site descriptor. Let the site descriptor for R be 
 as follows:
 {code:xml}
 project name=${project.name}
   !-- ... --
   body
   menu name=Main
   item name=Introduction href=/index.html /
   item name=News href=/news.html /
   item name=Overwrite href=/documentation.html /
   /menu
   /body
   !-- ... --
   
 /project
 {code}
 And let the site descriptor for S be:
 {code:xml}
 project name=${project.name}
   !-- ... --
   body
   menu name=Main
   item name=Introduction href=/index.html /
   item name=Overwrite href=/overwrite.html /
   item name=Added href=/added.html /
   /menu
   /body
   !-- ... --
   
 /project
 {code}
 As I'm used to the way inheritance and polymorphism are defined in OO 
 languages such as Java, I would expect the following properties for the 
 Main menu in S:
 - item Introduction is overwritten in S but refers to the same index.html 
 file; of course, its path is relative to start directory of S
 - item News is missing for S but will be inherited from R, thus, it will be 
 rendered to the site as in R
 - item Overwrite is overwritten in S and refers now to overwrite.html 
 (instead of documentation.html as in R)
 - item Added is new in S, thus, it will be rendered to the site in addition
 Unfortunately, with the current implementation of the site plugin inheritance 
 is as follows:
 - Main menu of R is inherited by S as-is, that is, all changes made to the 
 menu in S are not visible/rendered to the site.
 I would like to propose to implement polymorphism regarding menu inheritance 
 as described above. In addition, I would like to propose a new boolean 
 parameter inherited (or inherit) that can be added to menu items. Its 
 semantics would be equivalent to the inherited tag in pom.xml. In the 
 following one example for R:
 {code:xml}
 project name=${project.name}
   !-- ... --
   body
   menu name=Main
   item name=Introduction href=/index.html /
   item name=News 1 href=/news1.html  
 inherited=false/
   item name=News 2 href=/news2.html  
 inherited=true/
   item name=Overwrite href=/documentation.html /
   /menu
   /body
   !-- ... --
   
 /project
 {code}
 With this example only menu item News 2 would appear in S because its 
 inheritance is not disabled, while menu item News 1 appears only in R and 
 not in S because its inheritance was disabled (false). The default if the 
 parameter is missing should be true.
 Btw, the same extension should be made to the menu ...  tag to allow to 
 enable or disable inheritance of menus entirely.
 Regards,
 Thorsten

-- 
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-4001) Unable to resolve Dashboard mojo from Central

2009-01-24 Thread Anthony Whitford (JIRA)

Unable to resolve Dashboard mojo from Central
-

 Key: MNG-4001
 URL: http://jira.codehaus.org/browse/MNG-4001
 Project: Maven 2
  Issue Type: Bug
  Components: Sites  Reporting
Affects Versions: 2.0.9
 Environment: Windows, JDK 1.6
Reporter: Anthony Whitford
 Attachments: dashbug.zip

I have a simple test project that declares the dashboard-maven-plugin (see 
http://mojo.codehaus.org/dashboard-maven-plugin/usage.html ).

Note that the usage does explicitly state that the Codehaus repository must be 
specified as a plugin repository...
However, according to:  
http://maven.apache.org/guides/introduction/introduction-to-plugin-prefix-mapping.html
I'm pretty sure that Maven should be able to resolve the dashboard-maven-plugin 
from the central repo.

I validated that the [dashboard-maven-plugin residing in 
central|http://repo1.maven.org/maven2/org/codehaus/mojo/dashboard-maven-plugin/1.0.0-beta-1/]
 is indeed the same artifact as that which lives at the [codehaus 
repository|http://repository.codehaus.org/org/codehaus/mojo/dashboard-maven-plugin/1.0.0-beta-1/].

But as you can see from my attached test case, the codehaus mojo is NOT being 
resolved without the special plugin repository defined.  When running 
{noformat}mvn dashboard:dashboard{noformat}, I get the following error message:
{noformat}
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'dashboard'.
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] The plugin 'org.apache.maven.plugins:maven-dashboard-plugin' does not 
exist or no valid version could be found
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time:  1 second
[INFO] Finished at: Sat Jan 24 12:40:55 PST 2009
[INFO] Final Memory: 1M/254M
[INFO] 
{noformat}

If you edit the pom.xml to uncomment out the plugin repository declaration for 
codehaus, it works as one would expect.

My understanding is that the only reason why the Dashboard Usage mentions their 
plugin repository is because the artifact was not available on the central 
repository -- but it certainly is today.

I also thought that perhaps the maven-metadata.xml might be incorrect (perhaps 
the dashboard plugin prefix is missing or different).  I checked:
* http://repo1.maven.org/maven2/org/codehaus/mojo/maven-metadata.xml
* http://repository.codehaus.org/org/codehaus/mojo/maven-metadata.xml

and they both look OK to me...  I clearly see:{code:xml}
plugin
nameMaven Dashboard Report Plugin/name 
prefixdashboard/prefix 
artifactIddashboard-maven-plugin/artifactId 
/plugin
{code}

And I don't see any plugin with a dashboard prefix specified as an Apache Maven 
Plugin here:
* http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-metadata.xml

If I explicitly specify the dashboard plugin like:  {noformat}mvn 
org.codehaus.mojo:dashboard-maven-plugin:dashboard{noformat}
that works...

Overall, I am recording a bug because the 
[documentation|http://maven.apache.org/guides/introduction/introduction-to-plugin-prefix-mapping.html]
 states:{quote}
Maven will always search the following groupId's after searching any plugin 
groups specified in the user's settings:
* org.apache.maven.plugins 
* org.codehaus.mojo 
{quote}

I don't see this being done.

Finally, I even tried adding a {{pluginGroups}} to my 
{{settings.xml}}:{code:xml}
pluginGroups
  pluginGrouporg.codehaus.mojo/pluginGroup
/pluginGroups
{code}
But that did not work either...


-- 
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: (MINVOKER-76) Have invoker:run generate report files to allow reporting on the results of running invoker

2009-01-24 Thread Olivier Lamy (JIRA)


[ 
http://jira.codehaus.org/browse/MINVOKER-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162353#action_162353
 ] 

Olivier Lamy commented on MINVOKER-76:
--

Good idea but I would prefer to have an auto documented xml format with using a 
mdo file.

 Have invoker:run generate report files to allow reporting on the results of 
 running invoker
 ---

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


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

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

[jira] Commented: (MINVOKER-76) Have invoker:run generate report files to allow reporting on the results of running invoker

2009-01-24 Thread Stephen Connolly (JIRA)


[ 
http://jira.codehaus.org/browse/MINVOKER-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162373#action_162373
 ] 

Stephen Connolly commented on MINVOKER-76:
--

point me at an example and I'll rewrite the patch

 Have invoker:run generate report files to allow reporting on the results of 
 running invoker
 ---

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


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

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

[jira] Created: (MERCURY-78) mercury repository does not process timestamped dependencies correctly

2009-01-24 Thread Oleg Gusakov (JIRA)

mercury repository does not process timestamped dependencies correctly
--

 Key: MERCURY-78
 URL: http://jira.codehaus.org/browse/MERCURY-78
 Project: Mercury
  Issue Type: Bug
Affects Versions: 1.0.0-alpha-3
Reporter: Oleg Gusakov
Assignee: Oleg Gusakov


when asking for dependencies of a particular snapshot TS, mercury uses actual 
TS folder for GAV.

For example: when asking for SN version a:a:1.0-20081122.062742-13, it will try 
the path

a/a/1.0-20081122.062742-13 instead of a/a/1.0-SNAPSHOT

-- 
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: (MERCURY-78) mercury repository does not process timestamped dependencies correctly

2009-01-24 Thread Oleg Gusakov (JIRA)


[ 
http://jira.codehaus.org/browse/MERCURY-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162392#action_162392
 ] 

Oleg Gusakov commented on MERCURY-78:
-

Fixed in the trunk. 

There is a UT testing for reading a timestamp without dependencies, and it 
works. Need to add a test, reading TS with dependencies

 mercury repository does not process timestamped dependencies correctly
 --

 Key: MERCURY-78
 URL: http://jira.codehaus.org/browse/MERCURY-78
 Project: Mercury
  Issue Type: Bug
Affects Versions: 1.0.0-alpha-3
Reporter: Oleg Gusakov
Assignee: Oleg Gusakov
 Fix For: 1.0.0-alpha-4


 when asking for dependencies of a particular snapshot TS, mercury uses actual 
 TS folder for GAV.
 For example: when asking for SN version a:a:1.0-20081122.062742-13, it will 
 try the path
 a/a/1.0-20081122.062742-13 instead of a/a/1.0-SNAPSHOT

-- 
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: (MERCURY-78) mercury repository does not process timestamped dependencies correctly

2009-01-24 Thread Oleg Gusakov (JIRA)


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

Oleg Gusakov updated MERCURY-78:


Fix Version/s: 1.0.0-alpha-4

 mercury repository does not process timestamped dependencies correctly
 --

 Key: MERCURY-78
 URL: http://jira.codehaus.org/browse/MERCURY-78
 Project: Mercury
  Issue Type: Bug
Affects Versions: 1.0.0-alpha-3
Reporter: Oleg Gusakov
Assignee: Oleg Gusakov
 Fix For: 1.0.0-alpha-4


 when asking for dependencies of a particular snapshot TS, mercury uses actual 
 TS folder for GAV.
 For example: when asking for SN version a:a:1.0-20081122.062742-13, it will 
 try the path
 a/a/1.0-20081122.062742-13 instead of a/a/1.0-SNAPSHOT

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

41 matches

Mail list logo