[jira] Updated: (MNG-2580) UNC in MAVEN_HOME not working

[Kenney Westerhof (JIRA)]

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

Kenney Westerhof updated MNG-2580:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.0.x

> UNC in MAVEN_HOME not working
> -
>
> Key: MNG-2580
> URL: http://jira.codehaus.org/browse/MNG-2580
> Project: Maven 2
>  Issue Type: Bug
>  Components: Command Line
>Affects Versions: 2.0.4
> Environment: Windows XP
>Reporter: Remy COQUEUGNIOT
>Priority: Blocker
> Fix For: 2.0.x
>
>
> Maven2 is installed in a corporate server : SERVER
> From my computer, this installation is accesible on a network share : 
> \\SERVER\MAVEN2
> From a command line I setup MAVEN_HOME with this UNC:
> > set MAVEN_HOME=\\SERVER\MAVEN2
> And put it in the PATH
> > set PATH=%MAVEN_HOME%\bin;%PATH%
> When I try to build any projects, maven is unable to acces my global settings 
> which is stored in %MAVEN_HOME%\conf\settings.xml
> But when I mount a network share to this UNC:
> > net use Z: \\SERVER\MAVEN2
> ...Setup MAVEN_HOME ...
> > set MAVEN_HOME=Z:\
> ...And put it in the PATH ...
> > set PATH=%MAVEN_HOME%\bin;%PATH%
> The global settings.xml is read.
> This useCase seems OK with Maven 1.
> mvn -X doesn't give too any informations about the final %MAVEN_HOME%\conf 
> which is used.
> But it prints the plugin-registry.xml locations which are based on the 
> %MAVEN_HOME% 
> In this case \\SERVER\MAVEN2 is badly transformed in C:\SERVER\MAVEN2 :
> >set MAVEN_HOME=\\frmlefsi20\inet_dev\DEVPLATFORM\maven-2.0.4
> >mvn clean -X
> (...)
> [DEBUG] Building Maven global-level plugin registry from: 
> 'C:\frmlefsi20\inet_dev\DEVPLATFORM\maven-2.0.4\bin\..\conf\plugin-registry.xml'
> (...)
> Thanks for your support and this great tool !

-- 
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-3058) Allow artifact aliases

[Dimitry Voytenko (JIRA)]

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

Dimitry Voytenko commented on MNG-3058:
---

It does work. Thanks a lot, Wendy! Sorry, I never ran into this part of the 
guide.

> Allow artifact aliases
> --
>
> Key: MNG-3058
> URL: http://jira.codehaus.org/browse/MNG-3058
> Project: Maven 2
>  Issue Type: New Feature
>  Components: POM
>Reporter: Dimitry Voytenko
>
> The unfortunate fact is that there's a number of different artifacts that 
> essentially mean the same thing. 
> For instance:
> - javax.servlet:jsp-api vs javax.servlet.jsp:jsp-api
> - commons-logging:commons-logging vs commons-logging:commons-logging-api
> The number of such artifacts is only growing, increasing the ambiguity.
> One way to deal with this situations could be by introducing "aliases" for 
> artifacts. This would be a way to tell Maven that two artifacts basically 
> mean the same thing. Such an alias-artifact could be deployed in the 
> entierprise repository to help resolve ambiguities within a single workshop.
> For instance, we've been using "berkeleydb:je" artifact for some time, but 
> now, since acquisition by Oracle, some tool vendors use 
> "com.sleepycat.berkleydb:bdbje" and other names. These, in turn, mean the 
> same thing, but from the Maven's standpoint they're completely different, so 
> if one library referred to "berkeleydb:je:2.1.30" and the other referred to 
> "com.sleepycat.berkleydb:bdbje:3.1.0" the WAR (for instance) will endup with 
> two jars "je_2_1_30.jar" and "bdbje_3_1_0.jar", and further which of this 
> will be used is unknown. Here, if there was a way to specify that 
> com.sleepycat.berkleydb:bdbje == berkeleydb:je, Maven would simply pick 
> whichever has a higher version, thus removing the ambiguity w/o manual 
> intervention.
> I understand, this could somewhat complicate current Maven's artifact 
> resolution (which was perfectly simple so far), but it could also help to 
> deal with mounting addressing issues.

-- 
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-3058) Allow artifact aliases

[Dimitry Voytenko (JIRA)]

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

Dimitry Voytenko closed MNG-3058.
-

Resolution: Fixed

> Allow artifact aliases
> --
>
> Key: MNG-3058
> URL: http://jira.codehaus.org/browse/MNG-3058
> Project: Maven 2
>  Issue Type: New Feature
>  Components: POM
>Reporter: Dimitry Voytenko
>
> The unfortunate fact is that there's a number of different artifacts that 
> essentially mean the same thing. 
> For instance:
> - javax.servlet:jsp-api vs javax.servlet.jsp:jsp-api
> - commons-logging:commons-logging vs commons-logging:commons-logging-api
> The number of such artifacts is only growing, increasing the ambiguity.
> One way to deal with this situations could be by introducing "aliases" for 
> artifacts. This would be a way to tell Maven that two artifacts basically 
> mean the same thing. Such an alias-artifact could be deployed in the 
> entierprise repository to help resolve ambiguities within a single workshop.
> For instance, we've been using "berkeleydb:je" artifact for some time, but 
> now, since acquisition by Oracle, some tool vendors use 
> "com.sleepycat.berkleydb:bdbje" and other names. These, in turn, mean the 
> same thing, but from the Maven's standpoint they're completely different, so 
> if one library referred to "berkeleydb:je:2.1.30" and the other referred to 
> "com.sleepycat.berkleydb:bdbje:3.1.0" the WAR (for instance) will endup with 
> two jars "je_2_1_30.jar" and "bdbje_3_1_0.jar", and further which of this 
> will be used is unknown. Here, if there was a way to specify that 
> com.sleepycat.berkleydb:bdbje == berkeleydb:je, Maven would simply pick 
> whichever has a higher version, thus removing the ambiguity w/o manual 
> intervention.
> I understand, this could somewhat complicate current Maven's artifact 
> resolution (which was perfectly simple so far), but it could also help to 
> deal with mounting addressing issues.

-- 
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-1603) Upload JIDE Common Layer to maven repository

[David Qiao (JIRA)]

Upload JIDE Common Layer to maven repository


 Key: MAVENUPLOAD-1603
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1603
 Project: maven-upload-requests
  Issue Type: Task
Reporter: David Qiao


JIDE Common Layer is Swing component library built on top of Java/Swing. It is 
also the foundation of other component products from JIDE. This project has 
over 30 Swing components and over 100k lines of code. It greatly enhanced the 
default component set provided by Swing and allow developers to focus on 
business logic layer instead of making components.

JIDE Common Layer was originally developed by JIDE Software developers as a 
foundation in order to build other more advanced components. In April of 2007, 
JIDE Software decided to open source this common layer so that more and more 
developers can leverage them instead of wasting time building them again. 

For more information, please visit project home page on JIDE Software website 
at http://www.jidesoft.com/products/oss.htm or on java.net at 
https://jide-oss.dev.java.net.



-- 
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-3058) Allow artifact aliases

[Wendy Smoak (JIRA)]

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

Wendy Smoak commented on MNG-3058:
--

You can 'relocate' artifacts in the repository.  See:  
http://maven.apache.org/guides/mini/guide-relocation.html

> Allow artifact aliases
> --
>
> Key: MNG-3058
> URL: http://jira.codehaus.org/browse/MNG-3058
> Project: Maven 2
>  Issue Type: New Feature
>  Components: POM
>Reporter: Dimitry Voytenko
>
> The unfortunate fact is that there's a number of different artifacts that 
> essentially mean the same thing. 
> For instance:
> - javax.servlet:jsp-api vs javax.servlet.jsp:jsp-api
> - commons-logging:commons-logging vs commons-logging:commons-logging-api
> The number of such artifacts is only growing, increasing the ambiguity.
> One way to deal with this situations could be by introducing "aliases" for 
> artifacts. This would be a way to tell Maven that two artifacts basically 
> mean the same thing. Such an alias-artifact could be deployed in the 
> entierprise repository to help resolve ambiguities within a single workshop.
> For instance, we've been using "berkeleydb:je" artifact for some time, but 
> now, since acquisition by Oracle, some tool vendors use 
> "com.sleepycat.berkleydb:bdbje" and other names. These, in turn, mean the 
> same thing, but from the Maven's standpoint they're completely different, so 
> if one library referred to "berkeleydb:je:2.1.30" and the other referred to 
> "com.sleepycat.berkleydb:bdbje:3.1.0" the WAR (for instance) will endup with 
> two jars "je_2_1_30.jar" and "bdbje_3_1_0.jar", and further which of this 
> will be used is unknown. Here, if there was a way to specify that 
> com.sleepycat.berkleydb:bdbje == berkeleydb:je, Maven would simply pick 
> whichever has a higher version, thus removing the ambiguity w/o manual 
> intervention.
> I understand, this could somewhat complicate current Maven's artifact 
> resolution (which was perfectly simple so far), but it could also help to 
> deal with mounting addressing issues.

-- 
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-1314) NPE in DefaultContinuum.java - isInBuildingQueue

[Anh Vo (JIRA)]

NPE in DefaultContinuum.java - isInBuildingQueue


 Key: CONTINUUM-1314
 URL: http://jira.codehaus.org/browse/CONTINUUM-1314
 Project: Continuum
  Issue Type: Bug
Affects Versions: 1.1-alpha-2
 Environment: Windows Vista
Reporter: Anh Vo


Not sure what exactly causes this. When the schedule activates, sometimes it 
would throw this exception and will not proceed with other projects (it will 
process the one project that it started with, but will not continue on). The 
problem doesnt happen everytime the schedule activates, but about half of the 
time. The log is pasted below.

It's the section of code that is throwing the error
 for ( Iterator it = queue.iterator(); it.hasNext(); )
{
BuildProjectTask task = (BuildProjectTask) it.next();

else
{
if ( task.getProjectId() == projectId && 
task.getBuildDefinitionId() == buildDefinitionId ) < HERE

   
Log:
jvm 1| 2007-06-15 14:32:00,426 [defaultScheduler_Worker-1] INFO  
SchedulesActivator:default - > Executing build job 
(HalfH
ourly)...
jvm 1| 2007-06-15 14:32:00,574 [defaultScheduler_Worker-1] INFO  
Continuum:default  - Enqueuing 'X12Parser' (Build definition id=7).
jvm 1| 2007-06-15 14:32:00,575 [pool-1-thread-1] INFO  
BuildController:default- Initializing build
jvm 1| 2007-06-15 14:32:00,575 [defaultScheduler_Worker-1] ERROR 
JobRunShell- Job DEFAULT.HalfHourly threw an unhandled 
Except
ion:
jvm 1| java.lang.NullPointerException
jvm 1|  at 
org.apache.maven.continuum.DefaultContinuum.isInBuildingQueue(DefaultContinuum.java:490)
jvm 1|  at 
org.apache.maven.continuum.DefaultContinuum.buildProjects(DefaultContinuum.java:843)
jvm 1|  at 
org.apache.maven.continuum.scheduler.ContinuumBuildJob.execute(ContinuumBuildJob.java:66)
jvm 1|  at org.quartz.core.JobRunShell.run(JobRunShell.java:191)
jvm 1|  at 
org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:516)
jvm 1| 2007-06-15 14:32:00,578 [defaultScheduler_Worker-1] ERROR 
ErrorLogger- Job (DEFAULT.HalfHourly threw an exception.
jvm 1| org.quartz.SchedulerException: Job threw an unhandled exception. 
[See nested exception: java.lang.NullPointerException]
jvm 1|  at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
jvm 1|  at 
org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:516)
jvm 1| * Nested Exception (Underlying Cause) ---
jvm 1| java.lang.NullPointerException
jvm 1|  at 
org.apache.maven.continuum.DefaultContinuum.isInBuildingQueue(DefaultContinuum.java:490)
jvm 1|  at 
org.apache.maven.continuum.DefaultContinuum.buildProjects(DefaultContinuum.java:843)
jvm 1|  at 
org.apache.maven.continuum.scheduler.ContinuumBuildJob.execute(ContinuumBuildJob.java:66)
jvm 1|  at org.quartz.core.JobRunShell.run(JobRunShell.java:191)
jvm 1|  at 
org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:516)
jvm 1| 2007-06-15 14:32:00,596 [pool-1-thread-1] INFO  
BuildController:default- Starting build of X12Parser
jvm 1| 2007-06-15 14:32:00,665 [pool-1-thread-1] INFO  
BuildController:default- Updating working dir
jvm 1| 2007-06-15 14:32:00,665 [pool-1-thread-1] INFO  
BuildController:default- Performing action check-working-directory
jvm 1| 2007-06-15 14:32:00,666 [pool-1-thread-1] INFO  
BuildController:default- Performing action 
update-working-directory-from-scm
jvm 1| 2007-06-15 14:32:00,709 [pool-1-thread-1] INFO  ContinuumScm:default 
  - Updating project: id: '3', name 'X12Parser'.
jvm 1| 2007-06-15 14:32:00,729 [pool-1-thread-1] INFO  ScmManager:default   
  - Executing: svn --non-interactive update
jvm 1| 2007-06-15 14:32:00,729 [pool-1-thread-1] INFO  ScmManager:default   
  - Working directory: C:\buildecosystem\working-directory\3
jvm 1| 2007-06-15 14:32:01,159 [pool-1-thread-1] INFO  
BuildController:default- Merging SCM results
jvm 1| 2007-06-15 14:32:01,166 [pool-1-thread-1] INFO  
BuildController:default- The project was not built because there are no 
changes.
jvm 1| 2007-06-15 14:32:01,168 [pool-1-thread-1] INFO  
BuildController:default- No changes, not building
jvm 1| 2007-06-15 15:02:00,046 [defaultScheduler_Worker-5] INFO  
SchedulesActivator:default - > Executing build job 
(HalfH
ourly)...
jvm 1| 2007-06-15 15:02:00,190 [defaultScheduler_Worker-5] INFO  
Continuum:default  - Enqueuing 'X12Parser' (Build definition id=7).
jvm 1| 2007-06-15 15:02:00,191 [defaultScheduler_Worker-5] INFO  
Continuum:default  - Enqueuing 'light-he

[jira] Created: (MNG-3058) Allow artifact aliases

[Dimitry Voytenko (JIRA)]

Allow artifact aliases
--

 Key: MNG-3058
 URL: http://jira.codehaus.org/browse/MNG-3058
 Project: Maven 2
  Issue Type: New Feature
  Components: POM
Reporter: Dimitry Voytenko


The unfortunate fact is that there's a number of different artifacts that 
essentially mean the same thing. 

For instance:
- javax.servlet:jsp-api vs javax.servlet.jsp:jsp-api
- commons-logging:commons-logging vs commons-logging:commons-logging-api

The number of such artifacts is only growing, increasing the ambiguity.

One way to deal with this situations could be by introducing "aliases" for 
artifacts. This would be a way to tell Maven that two artifacts basically mean 
the same thing. Such an alias-artifact could be deployed in the entierprise 
repository to help resolve ambiguities within a single workshop.

For instance, we've been using "berkeleydb:je" artifact for some time, but now, 
since acquisition by Oracle, some tool vendors use 
"com.sleepycat.berkleydb:bdbje" and other names. These, in turn, mean the same 
thing, but from the Maven's standpoint they're completely different, so if one 
library referred to "berkeleydb:je:2.1.30" and the other referred to 
"com.sleepycat.berkleydb:bdbje:3.1.0" the WAR (for instance) will endup with 
two jars "je_2_1_30.jar" and "bdbje_3_1_0.jar", and further which of this will 
be used is unknown. Here, if there was a way to specify that 
com.sleepycat.berkleydb:bdbje == berkeleydb:je, Maven would simply pick 
whichever has a higher version, thus removing the ambiguity w/o manual 
intervention.

I understand, this could somewhat complicate current Maven's artifact 
resolution (which was perfectly simple so far), but it could also help to deal 
with mounting addressing issues.

-- 
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-3006) Maven does not always download artifacts from specified repos

[Wendy Smoak (JIRA)]

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

Wendy Smoak commented on MNG-3006:
--

You can configure the update policy for each repository.  See:  
http://maven.apache.org/ref/2.0.4/maven-model/maven.html#class_repository

Sounds like you want either 'always' or an interval in minutes.



> Maven does not always download artifacts from specified repos
> -
>
> Key: MNG-3006
> URL: http://jira.codehaus.org/browse/MNG-3006
> Project: Maven 2
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.0.6
> Environment: Windows XP SP2
>Reporter: David Hoffer
> Fix For: 2.1.x
>
> Attachments: settings.xml
>
>
> Performing maven2 builds does not always downloaded requested artifacts from 
> specified repos before complaining that the required artifact is not 
> available and giving up.  However if I delete my local repo then it always 
> works.
> Here is the failure log:
> [12:42:04]: Couldn't find a version in [1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 
> 1.7, 1.8, 1.9, 1.10, 1.9-SNAPSHOT, 1.11-SNAPSHOT] to match range [1.11,)
> [12:42:04]: com.xrite.retail:retail-commons-classic:jar:null
> [12:42:04]:
> [12:42:04]: from the specified remote repositories:
> [12:42:04]: central (http://xrbuild3:8081/artifactory/repo),
> [12:42:04]: snapshots (http://xrbuild3:8082/artifactory/repo)
> An HTTP port monitor shows that maven refuses to contact the servers until I 
> delete my local repo.  Maven should always check the remote server before 
> giving up.
> I will attach my settings.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] Commented: (MNG-3006) Maven does not always download artifacts from specified repos

[David Hoffer (JIRA)]

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

David Hoffer commented on MNG-3006:
---

We have discovered that fundamentally what is going on here is that maven2 is 
not, by default, really configured to work well in a company with an automated 
build system where artifact release versions change often.

The main issue here is that maven2, by default, only checks for version updates 
daily.  This may be fine for situations where you have a few static maven 
dependencies but is really bad for corporate component/application development 
where you are making/consuming lots of locally generated artifacts.

If I always run maven with the -U option this problem does not occur because 
maven then always checks for newer versions much like it does if you have no 
prior artifact version.

When I release a component artifact (to our proxy server) I also have lots of 
other components/applications with dependencies on it using set notation for 
the version.  Builds of these other components/applications must be able to 
find the just released component on our proxy server.  The default behavior of 
maven is to not find the new release until tomorrow!

In our environment I can see no reason for the daily update option for the 
local/corporate repo usage.  I have a hard time seeing a large benefit to it 
for remote repos as well, other than using a bit more network bandwidth.

This feature should be reworked so that I can say either globally (or possibly 
per project) that I want to always check for updates.  I suggest that this be 
configured in the settings.xml file for the global settings.

Also the -U option is misnamed as it implies it only effects snapshots when in 
fact it effects snapshots and releases.


> Maven does not always download artifacts from specified repos
> -
>
> Key: MNG-3006
> URL: http://jira.codehaus.org/browse/MNG-3006
> Project: Maven 2
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.0.6
> Environment: Windows XP SP2
>Reporter: David Hoffer
> Fix For: 2.1.x
>
> Attachments: settings.xml
>
>
> Performing maven2 builds does not always downloaded requested artifacts from 
> specified repos before complaining that the required artifact is not 
> available and giving up.  However if I delete my local repo then it always 
> works.
> Here is the failure log:
> [12:42:04]: Couldn't find a version in [1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 
> 1.7, 1.8, 1.9, 1.10, 1.9-SNAPSHOT, 1.11-SNAPSHOT] to match range [1.11,)
> [12:42:04]: com.xrite.retail:retail-commons-classic:jar:null
> [12:42:04]:
> [12:42:04]: from the specified remote repositories:
> [12:42:04]: central (http://xrbuild3:8081/artifactory/repo),
> [12:42:04]: snapshots (http://xrbuild3:8082/artifactory/repo)
> An HTTP port monitor shows that maven refuses to contact the servers until I 
> delete my local repo.  Maven should always check the remote server before 
> giving up.
> I will attach my settings.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] Commented: (CONTINUUM-1313) Document changes to XMLRPC

[Wendy Smoak (JIRA)]

[ 
http://jira.codehaus.org/browse/CONTINUUM-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99630
 ] 

Wendy Smoak commented on CONTINUUM-1313:


Should answer the questions raised by Steven Cummings in this thread:  
http://www.nabble.com/Remote-API-for-1.1-t3929020.html

> Document changes to XMLRPC
> --
>
> Key: CONTINUUM-1313
> URL: http://jira.codehaus.org/browse/CONTINUUM-1313
> Project: Continuum
>  Issue Type: Bug
>  Components: XMLRPC Interface
>Affects Versions: 1.1-alpha-2
>Reporter: Wendy Smoak
> Fix For: 1.1-alpha-3
>
>
> Document the changes made for CONTINUUM-1269, which include a complete 
> refactoring, use of the webapp port, and the addition of security

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

[jira] Updated: (CONTINUUM-1313) Document changes to XMLRPC

[Wendy Smoak (JIRA)]

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

Wendy Smoak updated CONTINUUM-1313:
---

Fix Version/s: 1.1-alpha-3

> Document changes to XMLRPC
> --
>
> Key: CONTINUUM-1313
> URL: http://jira.codehaus.org/browse/CONTINUUM-1313
> Project: Continuum
>  Issue Type: Bug
>  Components: XMLRPC Interface
>Affects Versions: 1.1-alpha-2
>Reporter: Wendy Smoak
> Fix For: 1.1-alpha-3
>
>
> Document the changes made for CONTINUUM-1269, which include a complete 
> refactoring, use of the webapp port, and the addition of security

-- 
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-1313) Document changes to XMLRPC

[Wendy Smoak (JIRA)]

Document changes to XMLRPC
--

 Key: CONTINUUM-1313
 URL: http://jira.codehaus.org/browse/CONTINUUM-1313
 Project: Continuum
  Issue Type: Bug
  Components: XMLRPC Interface
Affects Versions: 1.1-alpha-2
Reporter: Wendy Smoak


Document the changes made for CONTINUUM-1269, which include a complete 
refactoring, use of the webapp port, and the addition of security

-- 
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-1269) XMLRPC server must be a servlet on the same port used by the webapp instead of a specific port

[Wendy Smoak (JIRA)]

[ 
http://jira.codehaus.org/browse/CONTINUUM-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99629
 ] 

Wendy Smoak commented on CONTINUUM-1269:


Were the changes documented anywhere?

> XMLRPC server must be a servlet on the same port used by the webapp instead 
> of a specific port
> --
>
> Key: CONTINUUM-1269
> URL: http://jira.codehaus.org/browse/CONTINUUM-1269
> Project: Continuum
>  Issue Type: Bug
>  Components: XMLRPC Interface
>Reporter: Emmanuel Venisse
>Assignee: Emmanuel Venisse
> Fix For: 1.1-alpha-2
>
>


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

[jira] Moved: (MNGSITE-15) Create an archetype demonstrating the use of profiles targeting different environments

[Brett Porter (JIRA)]

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

Brett Porter moved ARCHETYPE-80 to MNGSITE-15:
--

Component/s: (was: Archetypes)
Key: MNGSITE-15  (was: ARCHETYPE-80)
Project: Maven Project Web Site  (was: Maven Archetype)

> Create an archetype demonstrating the use of profiles targeting different 
> environments
> --
>
> Key: MNGSITE-15
> URL: http://jira.codehaus.org/browse/MNGSITE-15
> Project: Maven Project Web Site
>  Issue Type: New Feature
>Reporter: Jason van Zyl
>
> Having an archetype which encapsulates how to use profiles to in order to do 
> things like filtering log4.properties files according to their target 
> environment would be useful.

-- 
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: (MNGSITE-14) Maven Site Refinements

[Brett Porter (JIRA)]

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

Brett Porter moved MNG-2467 to MNGSITE-14:
--

Fix Version/s: (was: Documentation)
  Component/s: (was: Documentation:  General)
  Key: MNGSITE-14  (was: MNG-2467)
  Project: Maven Project Web Site  (was: Maven 2)

> Maven Site Refinements
> --
>
> Key: MNGSITE-14
> URL: http://jira.codehaus.org/browse/MNGSITE-14
> Project: Maven Project Web Site
>  Issue Type: Improvement
>Reporter: Marvin King
>
> - apply the maven site skin consistently (MNG-1212)
> - site structuring (this already had concrete proposals):
>   * http://mail-archives.apache.org/mod_mbox/maven-dev/200602.mbox/[EMAIL 
> PROTECTED]
>   * http://mail-archives.apache.org/mod_mbox/maven-dev/200602.mbox/[EMAIL 
> PROTECTED]
>   * see also Better Builds with Maven section on "separating developer and 
> user content"
> - set up a staging site
> - remove "2" from Maven 2 references (it's just Maven). We'll still refer to 
> Maven 1.x in comparisons and pointing to the Maven 1.1 docs.
> - create a plugin link page that is categorised (j2ee, ide, artifact 
> handling, test, packaging, CI, archetypes, source generators, reports) - to 
> be automated later by additional metadata
> - enhance plugin link page (more plugins, add current release version and 
> quality (dev, alpha, beta, stable) - to be automated later (MNG-1213)
> - add search box to the index page (google for now)
> - chop up the getting started guide so it is again something you could do in 
> 10 minutes to get a feel for Maven (perhaps go back to the level of the 
> original guide). Maybe rename to something else? I used to call it "the 10 
> minute test" on Maven 1.
> - categorise the guides page, rename the page as "Index" (not index.html) - 
> MNG-1540
> - relabel "other projects FAQ" as "guide for sync partners" or similar. It 
> should go into a repository related subsection. 

-- 
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: (MNGSITE-12) Ancient documentation is confusing users.

[Brett Porter (JIRA)]

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

Brett Porter moved MNG-1496 to MNGSITE-12:
--

Fix Version/s: (was: Documentation)
  Component/s: (was: Documentation:  General)
  Key: MNGSITE-12  (was: MNG-1496)
  Project: Maven Project Web Site  (was: Maven 2)

> Ancient documentation is confusing users.
> -
>
> Key: MNGSITE-12
> URL: http://jira.codehaus.org/browse/MNGSITE-12
> Project: Maven Project Web Site
>  Issue Type: Improvement
> Environment: N/A
>Reporter: Joakim Erdfelt
>Priority: Minor
> Attachments: listing.txt.gz
>
>
> I work in an environment where maven has been in active use since pre-1.0 
> days.
> The users and developers here have links to documentation on the 
> maven.apache.org website that points to bad or old documentation.
> Can they be removed, or better yet have an apache url rewrite to the 
> appropriate page?
> Examples of ones I've found.
> http://maven.apache.org/reference/plugins/core-plugins.html
>   From November 2003 - so old it mentions ApacheCon 2003 and maven 
> 1.0-rc2-SNAPSHOT
> http://maven.apache.org/reference/plugins/optional/optional.html
>   From March 2004
> Both of those should redirect to 
> http://maven.apache.org/reference/plugins/index.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] Moved: (MNGSITE-13) Plugin cookbook is empty

[Brett Porter (JIRA)]

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

Brett Porter moved MNG-2976 to MNGSITE-13:
--

Affects Version/s: (was: 2.1)
   (was: 2.2.x)
   (was: 2.1-alpha-2)
   (was: 2.1-alpha-1)
   (was: 2.1.x)
   (was: 2.0.x)
   (was: 2.0.8)
   (was: 2.0.7)
   (was: 2.2)
Fix Version/s: (was: Documentation)
  Component/s: (was: Documentation: Guides)
  Key: MNGSITE-13  (was: MNG-2976)
  Project: Maven Project Web Site  (was: Maven 2)

> Plugin cookbook is empty
> 
>
> Key: MNGSITE-13
> URL: http://jira.codehaus.org/browse/MNGSITE-13
> Project: Maven Project Web Site
>  Issue Type: Improvement
>Reporter: Lennart Jörelid
>
> The "plugin cookbook" section on the maven site is empty.
> The cookbook section is the means to bridge the skill gap between trivial 
> "hello world"-plugin examples and real plugin development.
> Populating this section with examples and recipes assist in Maven2 adoption 
> and promotes common plugin coding standards.

-- 
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: (MNGSITE-11) review and link to POMstrap

[Brett Porter (JIRA)]

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

Brett Porter moved MNG-2380 to MNGSITE-11:
--

Fix Version/s: (was: Documentation)
  Component/s: (was: Documentation:  General)
  Key: MNGSITE-11  (was: MNG-2380)
  Project: Maven Project Web Site  (was: Maven 2)

> review and link to POMstrap
> ---
>
> Key: MNGSITE-11
> URL: http://jira.codehaus.org/browse/MNGSITE-11
> Project: Maven Project Web Site
>  Issue Type: Improvement
>Reporter: Brett Porter
>
> http://pomstrap.tigris.org/
> Heard about this a while back - it seems to have matured a bit. Let's you 
> execute your project from a 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] Moved: (MNGSITE-10) Improve Site Structuring

[Brett Porter (JIRA)]

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

Brett Porter moved MNG-2473 to MNGSITE-10:
--

Fix Version/s: (was: Documentation)
  Component/s: (was: Documentation:  General)
  Key: MNGSITE-10  (was: MNG-2473)
  Project: Maven Project Web Site  (was: Maven 2)

> Improve Site Structuring
> 
>
> Key: MNGSITE-10
> URL: http://jira.codehaus.org/browse/MNGSITE-10
> Project: Maven Project Web Site
>  Issue Type: Task
>Reporter: Marvin King
> Attachments: index[new_nav_items].html, 
> index[new_nav_items_w_top_right_quicklinks].html, 
> MNG-2473-site-[new_nav_items].patch, 
> MNG-2473-site-[new_nav_items_w_top_right_quicklinks].patch
>
>  Time Spent: 6 hours
>  Remaining Estimate: 0 minutes
>
> See my proposal here:
> http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/[EMAIL 
> PROTECTED]
> See also:
> http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/<[EMAIL 
> PROTECTED]>
> http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/<[EMAIL 
> PROTECTED]>
> Key to this is particularly changing the content of the front page, as well 
> as the navigation.

-- 
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: (MNGSITE-9) set up a plugin developer centre

[Brett Porter (JIRA)]

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

Brett Porter moved MNG-2574 to MNGSITE-9:
-

Fix Version/s: (was: Documentation)
  Component/s: (was: Documentation:  General)
  Key: MNGSITE-9  (was: MNG-2574)
  Project: Maven Project Web Site  (was: Maven 2)

> set up a plugin developer centre
> 
>
> Key: MNGSITE-9
> URL: http://jira.codehaus.org/browse/MNGSITE-9
> Project: Maven Project Web Site
>  Issue Type: Task
>Reporter: Brett Porter
>
> we should have a specific subsection of the site that deals with issues that 
> plugin developers would encounter (both at Maven and those who develop them 
> independantly). Incorporating the cookbook format by slurping in the wiki 
> would also be particularly helpful here.

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

[jira] Moved: (MNGSITE-8) improve physical layout of the web site

[Brett Porter (JIRA)]

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

Brett Porter moved MNG-2514 to MNGSITE-8:
-

Fix Version/s: (was: Documentation)
  Component/s: (was: Documentation:  General)
  Key: MNGSITE-8  (was: MNG-2514)
  Project: Maven Project Web Site  (was: Maven 2)

> improve physical layout of the web site
> ---
>
> Key: MNGSITE-8
> URL: http://jira.codehaus.org/browse/MNGSITE-8
> Project: Maven Project Web Site
>  Issue Type: Task
>Reporter: Brett Porter
>
> *  http://mail-archives.apache.org/mod_mbox/maven-dev/200602.mbox/[EMAIL 
> PROTECTED]
> * http://mail-archives.apache.org/mod_mbox/maven-dev/200602.mbox/[EMAIL 
> PROTECTED]
> * see also Better Builds with Maven section on "separating developer and 
> user content"

-- 
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: (MNGSITE-5) Create a Developers centre

[Brett Porter (JIRA)]

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

Brett Porter moved MNG-2600 to MNGSITE-5:
-

Fix Version/s: (was: Documentation)
  Component/s: (was: Documentation:  General)
  Key: MNGSITE-5  (was: MNG-2600)
  Project: Maven Project Web Site  (was: Maven 2)

> Create a Developers centre 
> ---
>
> Key: MNGSITE-5
> URL: http://jira.codehaus.org/browse/MNGSITE-5
> Project: Maven Project Web Site
>  Issue Type: Task
>Reporter: Vincent Siveton
>
> Already discuss on the dev list by brett and myself

-- 
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: (MNGSITE-4) broken links on http://maven.apache.org/plugins

[Brett Porter (JIRA)]

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

Brett Porter moved MNG-2665 to MNGSITE-4:
-

Fix Version/s: (was: Documentation)
  Component/s: (was: Documentation:  General)
  Key: MNGSITE-4  (was: MNG-2665)
  Project: Maven Project Web Site  (was: Maven 2)

> broken links on http://maven.apache.org/plugins
> ---
>
> Key: MNGSITE-4
> URL: http://jira.codehaus.org/browse/MNGSITE-4
> Project: Maven Project Web Site
>  Issue Type: Bug
>Reporter: Tom Huybrechts
>
> a list of broken links on the maven site
> http://maven.apache.org/plugins/maven-repository-plugin/faq.html
> http://maven.apache.org/plugins/maven-war-plugin/faq.html
> http://maven.apache.org/plugins/maven-dependency-plugin/faq.html
> http://maven.apache.org/plugins/maven-docck-plugin/taglist.html
> http://maven.apache.org/plugins/maven-repository-plugin/usage.html
> http://maven.apache.org/plugins/maven-jxr-plugin/faq.html
> http://maven.apache.org/plugins/maven-checkstyle-plugin/dependencies.html
> http://maven.apache.org/plugins/maven-verifier-plugin/faq.html
> http://maven.apache.org/plugins/maven-doap-plugin/examples/options.html
> http://maven.apache.org/plugins/maven-ejb-plugin/usage.html
> http://maven.apache.org/plugins/maven-ejb-plugin/faq.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] Moved: (MNGSITE-6) update team list

[Brett Porter (JIRA)]

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

Brett Porter moved MNG-1818 to MNGSITE-6:
-

Fix Version/s: (was: Documentation)
  Component/s: (was: Documentation:  General)
  Key: MNGSITE-6  (was: MNG-1818)
  Project: Maven Project Web Site  (was: Maven 2)

> update team list
> 
>
> Key: MNGSITE-6
> URL: http://jira.codehaus.org/browse/MNGSITE-6
> Project: Maven Project Web Site
>  Issue Type: Task
>Reporter: Brett Porter
>Assignee: Brian Fox
>
> 1) list all pmc members
> 2) list all committers in 
> 3) seek out "Submitted by" in svn logs to populate 

-- 
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: (MNGSITE-3) Developers and Contributors information is not being inherited

[Brett Porter (JIRA)]

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

Brett Porter moved MNG-2842 to MNGSITE-3:
-

Affects Version/s: (was: 2.0.4)
   (was: 2.0.5)
Fix Version/s: (was: Documentation)
  Component/s: (was: Documentation: Guides)
   (was: Inheritance and Interpolation)
  Key: MNGSITE-3  (was: MNG-2842)
  Project: Maven Project Web Site  (was: Maven 2)

> Developers and Contributors information is not being inherited
> --
>
> Key: MNGSITE-3
> URL: http://jira.codehaus.org/browse/MNGSITE-3
> Project: Maven Project Web Site
>  Issue Type: Bug
> Environment: Linux (Fedora Core 6)
> JDK 1.5.0_10
>Reporter: Brad Szabo
>
> The developers and contributors information is not being merged into the 
> effective POM of child projects.
> According to the Project Inheritance section of the following two POM 
> references, this info should be merged.
> http://maven.apache.org/guides/introduction/introduction-to-the-pom.html
> http://maven.apache.org/pom.html#Inheritance

-- 
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: (MNGSITE-7) document more about "how to get help" on the mailing lists

[Brett Porter (JIRA)]

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

Brett Porter moved MNG-2389 to MNGSITE-7:
-

Fix Version/s: (was: Documentation)
  Component/s: (was: Documentation:  General)
  Key: MNGSITE-7  (was: MNG-2389)
  Project: Maven Project Web Site  (was: Maven 2)

> document more about "how to get help" on the mailing lists
> --
>
> Key: MNGSITE-7
> URL: http://jira.codehaus.org/browse/MNGSITE-7
> Project: Maven Project Web Site
>  Issue Type: Task
>Reporter: Brett Porter
>
> see: http://mail-archives.apache.org/mod_mbox/maven-users/200601.mbox/[EMAIL 
> PROTECTED]
> including later posts in the thread.
> We should have this in a place that we can point to more often.

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

[jira] Moved: (ARCHETYPE-80) Create an archetype demonstrating the use of profiles targeting different environments

[Brett Porter (JIRA)]

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

Brett Porter moved MNG-1128 to ARCHETYPE-80:


Fix Version/s: (was: Documentation)
  Component/s: (was: Documentation:  General)
   Archetypes
   Complexity:   (was: Intermediate)
  Key: ARCHETYPE-80  (was: MNG-1128)
  Project: Maven Archetype  (was: Maven 2)

> Create an archetype demonstrating the use of profiles targeting different 
> environments
> --
>
> Key: ARCHETYPE-80
> URL: http://jira.codehaus.org/browse/ARCHETYPE-80
> Project: Maven Archetype
>  Issue Type: New Feature
>  Components: Archetypes
>Reporter: Jason van Zyl
>
> Having an archetype which encapsulates how to use profiles to in order to do 
> things like filtering log4.properties files according to their target 
> environment would be useful.

-- 
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: (MPA-103) Freshmeat entry of maven is not up to date

[Brett Porter (JIRA)]

[ 
http://jira.codehaus.org/browse/MPA-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99628
 ] 

Brett Porter commented on MPA-103:
--

I've tried to get it updated in the past, but they'll only listen to Jason 
since he created it.

> Freshmeat entry of maven is not up to date
> --
>
> Key: MPA-103
> URL: http://jira.codehaus.org/browse/MPA-103
> Project: Maven Project Administration
>  Issue Type: Wish
>Reporter: Raphaël Piéroni
>Priority: Trivial
> Fix For: 2007-q2
>
>
> The maven freshmeat is not up to date :
> http://freshmeat.net/projects/maven
> Please take any action.
> extract from irc
> 18:07 < rafale> Hi, I talk about maven to a friend last WE, he tried the 
> freshmeat site and we both see that the maven page on freshmeat wasn't 
> updated since maven was at jakarta/turbine/maven. 
> 18:07 < rafale> should i raise a jira for that ?
> 18:10 < jvanzyl> we should just erase that page

-- 
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: (ARCHETYPE-79) Project namespaces not added to sub projects

[Brett Porter (JIRA)]

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

Brett Porter moved MNG-2955 to ARCHETYPE-79:


Affects Version/s: (was: 2.0.6)
   (was: 2.0.4)
   (was: 2.0.5)
   (was: 2.0.2)
   (was: 2.0.3)
   (was: 2.0.1)
   (was: 2.0)
Fix Version/s: (was: Reviewed Pending Version Assignment)
   Complexity:   (was: Intermediate)
  Key: ARCHETYPE-79  (was: MNG-2955)
  Project: Maven Archetype  (was: Maven 2)

> Project namespaces not added to sub projects
> 
>
> Key: ARCHETYPE-79
> URL: http://jira.codehaus.org/browse/ARCHETYPE-79
> Project: Maven Archetype
>  Issue Type: Bug
> Environment: All
>Reporter: Oskar Carlstedt
>Priority: Trivial
>
> When creating a sub project, the namespace in the pom is not set. The root 
> pom will allways look like:
> http://maven.apache.org/POM/4.0.0";
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
> http://maven.apache.org/maven-v4_0_0.xsd";>
> ...
> 
> The sub projects pom will allways look like:
> 
> Not a major thing. Maybe there is a reason for this.
> With Kind Regards
> Oskar

-- 
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: (MPA-103) Freshmeat entry of maven is not up to date

[Brett Porter (JIRA)]

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

Brett Porter moved MNG-2887 to MPA-103:
---

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2007-q2
   Complexity:   (was: Intermediate)
  Key: MPA-103  (was: MNG-2887)
  Project: Maven Project Administration  (was: Maven 2)

> Freshmeat entry of maven is not up to date
> --
>
> Key: MPA-103
> URL: http://jira.codehaus.org/browse/MPA-103
> Project: Maven Project Administration
>  Issue Type: Wish
>Reporter: Raphaël Piéroni
>Priority: Trivial
> Fix For: 2007-q2
>
>
> The maven freshmeat is not up to date :
> http://freshmeat.net/projects/maven
> Please take any action.
> extract from irc
> 18:07 < rafale> Hi, I talk about maven to a friend last WE, he tried the 
> freshmeat site and we both see that the maven page on freshmeat wasn't 
> updated since maven was at jakarta/turbine/maven. 
> 18:07 < rafale> should i raise a jira for that ?
> 18:10 < jvanzyl> we should just erase that page

-- 
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-2736) Decouple Settings from the ProfileManager

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2736:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.1.x
  Component/s: Settings
   Profiles

> Decouple Settings from the ProfileManager 
> --
>
> Key: MNG-2736
> URL: http://jira.codehaus.org/browse/MNG-2736
> Project: Maven 2
>  Issue Type: Task
>  Components: Profiles, Settings
>Reporter: Jason van Zyl
>Assignee: Jason van Zyl
> Fix For: 2.1.x
>
>
> We can populate the profiles that are present in the settings.xml into the 
> profile manager from the embedder.

-- 
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-2872) Don't append artifactId when parent pom already has artifactId in URL

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2872:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.1.x
  Component/s: Inheritance and Interpolation

> Don't append artifactId when parent pom already has artifactId in URL
> -
>
> Key: MNG-2872
> URL: http://jira.codehaus.org/browse/MNG-2872
> Project: Maven 2
>  Issue Type: Wish
>  Components: Inheritance and Interpolation
>Affects Versions: 2.0.5
>Reporter: Papick G. Taboada
>Priority: Trivial
> Fix For: 2.1.x
>
>
> I want to define the url for all my projects from one central pom. the pom 
> project itself has the same url structure as the child projects.
> This is for all urls that can be inherited, e.g. distribution site, 
> deployment url, etc.
> I would like to specify some complete url like
> protocol:/my.server.com/some/path/to/the/${groupId}/${artifactId}
> For example, with the actual implementation I get either the parent pom site 
> deployed to the groupId directory, or I get the child projects deployed to 
> the grouId/artifactId/artifactId directory.
> At the moment I have add the urls on every project, although they always have 
> the same pattern.

-- 
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-3049) settings.xml needs a tag for the http.auth.preference parameter

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-3049:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.1.x
  Component/s: Settings

passing through properties to wagon would be a better way to make this more 
extensible.

> settings.xml needs a tag for the http.auth.preference parameter
> ---
>
> Key: MNG-3049
> URL: http://jira.codehaus.org/browse/MNG-3049
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Settings
>Affects Versions: 2.0.6
>Reporter: Mathias Arens
>Priority: Minor
> Fix For: 2.1.x
>
>
> If you run maven on solaris with a proxy that has NTLM configured as the 
> standard authorisation you cannot set the authentication scheme to basic in 
> the settings.xml. You have to pass this parameter over the command line 'mvn 
> -Dhttp.auth.preference=basic install'. But this option essential because it 
> is not easy to get NTLM authentication running on solaris.
> Maybe further http.auth parameters should be added to the settings.xml. Here 
> is a list of the java parameters:
> http://java.sun.com/javase/6/docs/technotes/guides/net/http-auth.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: (MNG-2786) [IMPROVEMENT] Namespace qualify all xml documents

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2786:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.1.x
  Component/s: POM

> [IMPROVEMENT] Namespace qualify all xml documents
> -
>
> Key: MNG-2786
> URL: http://jira.codehaus.org/browse/MNG-2786
> Project: Maven 2
>  Issue Type: Improvement
>  Components: POM
>Affects Versions: 2.0.4
>Reporter: Ole Ersoy
>Priority: Minor
> Fix For: 2.1.x
>
>
> Currently only pom's that have no parent and pom's with packaging pom
> are namespace qualified.  Also maven-metadata.xml instances need to be 
> namespace qualified.
> Once they are namespaced qualified, versioned document can be 
> loaded using the xs:targetLocation attribute as a key to lookup 
> a version specific model package (Containing the classes for the model),
> and corresponding factory.
> Cheers,
> - Ole

-- 
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-2719) Request for Summary element in POM

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2719:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.1.x
  Component/s: POM

> Request for Summary element in POM
> --
>
> Key: MNG-2719
> URL: http://jira.codehaus.org/browse/MNG-2719
> Project: Maven 2
>  Issue Type: New Feature
>  Components: POM
>Reporter: Ole Ersoy
>Priority: Minor
> Fix For: 2.1.x
>
>
> If a summary element were added it would make RPM
> Spec file generation more efficient, since spec files
> "require" both a description and a summary.
> A summary element can also be handy for 
> for other tools that want to generate reports
> giving a summary, as well as a longer description
> of the project.
> If this sounds reasonable I will update the XML Schema for maven with the 
> summary
> element and submit.
> Cheers,
> - Ole

-- 
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] Deleted: (MNG-2592) CLONE -M2 / maven-theme.css file not overiden from project resources/css/ folder

[Brett Porter (JIRA)]

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

Brett Porter deleted MNG-2592:
--


> CLONE -M2 / maven-theme.css file not overiden from project resources/css/ 
> folder
> 
>
> Key: MNG-2592
> URL: http://jira.codehaus.org/browse/MNG-2592
> Project: Maven 2
>  Issue Type: Bug
> Environment: w2k
>Reporter: Sonya Lowry
>Assignee: Emmanuel Venisse
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> The css files are copied from site/resources/css file to the target folder.
> but the maven-theme.css and the maven-base.css files are also copied from the 
> maven orginal (default) files.
> these defaults files are copied after the site/resources/css, erasing the 
> project's ones.
> should be copied in first position, so site/resources/css with same names 
> overwritte them.
> better solution : allow to choose exactly what is written in the  part 
> of the html file, so we can put and use the css file the user want, and from 
> any location

-- 
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-3005) Support multiple source directories

[Brett Porter (JIRA)]

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

Brett Porter closed MNG-3005.
-

   Resolution: Won't Fix
Fix Version/s: (was: Reviewed Pending Version Assignment)

already possible using the build-helper plugin from mojo

> Support multiple source directories
> ---
>
> Key: MNG-3005
> URL: http://jira.codehaus.org/browse/MNG-3005
> Project: Maven 2
>  Issue Type: New Feature
> Environment: general
>Reporter: Thorsten Möller
>Priority: Minor
>
> Apologies if there is already a feature request on this.
> Today I came around the need to support multiple source directories in one of 
> my artifacts. The reason is that I have generated source code (and 'normal' 
> source code) which I don't want to put under version control. By using a 
> single source dir this would become a tedious task since all generated source 
> files would have to be excluded almost manually and over and over again for 
> each file. Separating such derived files in another dir is much more 
> convenient since only the root folder has to be marked for exclusion.
> I've found a discussion thread on this:
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg32712.html
> My opinion is that not only me would appreciate this feature, thus, I thought 
> it would be good to make this explicit.

-- 
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-2999) Receiving a 403 response from a mirror server should attempt other mirrors

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2999:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.0.x
  Component/s: Artifacts and Repositories

> Receiving a 403 response from a mirror server should attempt other mirrors
> --
>
> Key: MNG-2999
> URL: http://jira.codehaus.org/browse/MNG-2999
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Artifacts and Repositories
>Affects Versions: 2.0.4
>Reporter: Matt Ryall
>Priority: Minor
> Fix For: 2.0.x
>
>
> Trying to download asm:asm:3.0:jar from several of the central mirrors fails 
> with a 403, but it would work if it attempted download from the main site.
> I'm not sure whether this is an issue caused by the fact that the mirrors 
> aren't true mirrors, or that Maven should attempt other mirrors if one of 
> them fails with a 403 (or perhaps also 404) error.

-- 
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-2428) Mojo fields @component and no @parameter annotations are still considered parameters and can't be distinguished when it became a Parameter Object

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2428:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.0.x
  Component/s: Plugin Creation Tools

> Mojo fields @component and no @parameter annotations are still considered 
> parameters and can't be distinguished when it became a Parameter Object
> -
>
> Key: MNG-2428
> URL: http://jira.codehaus.org/browse/MNG-2428
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Plugin Creation Tools
>Reporter: Edwin Punzalan
>Priority: Minor
> Fix For: 2.0.x
>
>
> Two possible solutions:
> 1] Do not consider fields with @component and no @parameter as a mojo 
> parameter
> or
> 2] Add a method boolean isComponent() in the Parameter Object to distinguish 
> them from actual parameters.
> Btw, this causes @component fields to appear in the mojo parameters list.

-- 
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-2655) Revise Introduction to the Build Lifecycle

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2655:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   Documentation
  Component/s: Documentation: Introductions

> Revise Introduction to the Build Lifecycle
> --
>
> Key: MNG-2655
> URL: http://jira.codehaus.org/browse/MNG-2655
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Documentation: Introductions
>Reporter: Franz Allan Valencia See
>Priority: Minor
> Fix For: Documentation
>
> Attachments: MNG-2655-maven-site.patch
>
>
> * Provide a Table of Contents (the page is too long).
> * Enumerate the available lifecycles (default, clean, site).
> * Provide references to the list of phases for those lifecycles lifecycles .
> * Explain goals and how they relate to the build phases.
> * Provide references to the default goal bindings on the build phases.
> * Explain what plugins are and how they relate to goals
> * Transfer the "...For developers" section to Guide to Java Plugin 
> Development. Users don't need to know tihs.

-- 
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-2705) add jar sources in repository for snapshot builds

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2705:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.1.x
  Component/s: POM
   Deployment

> add jar sources in repository for snapshot builds
> -
>
> Key: MNG-2705
> URL: http://jira.codehaus.org/browse/MNG-2705
> Project: Maven 2
>  Issue Type: Task
>  Components: Deployment, POM
>Reporter: Barrie Treloar
>Assignee: Brett Porter
>Priority: Minor
> Fix For: 2.1.x
>
>
> When using IDE like eclipse, it would be great to have dependecies sources 
> (optionnaly) added to repository.
> This way eclipse plugin (and others) could generate a .classpath file that 
> set "source attachement" and allow code and javadoc consult, debuging and 
> inherited methods implementation with original parameters names.

-- 
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-2141) Extra phase 'assemble' used for ear/war and copy without overwrite

[Brett Porter (JIRA)]

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

Brett Porter closed MNG-2141.
-

   Resolution: Incomplete
Fix Version/s: (was: Reviewed Pending Version Assignment)

please file the requests under the respective plugins. Note that the phase 
prepare-package already exists in 2.1 (trunk).

> Extra phase 'assemble' used for ear/war and copy without overwrite 
> ---
>
> Key: MNG-2141
> URL: http://jira.codehaus.org/browse/MNG-2141
> Project: Maven 2
>  Issue Type: Improvement
>Reporter: Konstantin Polyzois
>Priority: Minor
>
> We are using maven to build some war and ear files for weblogic. To catch 
> errors early we aree precompiling the ears and wars using a inhouse written 
> weblogic.appc plugin. Two things are a bit annoying :-)
> 1 The ear and war plugin always overwrites each file, I have tracked this 
> behaviuor to a org.codehaus.plexus.util.FileUtils class. Is it possible to 
> change the behaviuor of this class (add another method) that uses timestamps 
> a la Ant?
> 2 There would be nice with a phase between 'test' and 'package' where the 
> war/ear would be exploded. Maybe 'mvn assemble'? Then I could call my plugin 
> in that phase and the package would basically just jar the thing together. It 
> would also make development quicker because you could use 'mvn assemble' to 
> deploy your ear/war in an exploded state in your appserver/servletcontainer.
> /Konstantin

-- 
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: (MWAR-107) CLONE -Dependency type "ejb-client" includes main ejb-jar in WAR build.

[Brett Porter (JIRA)]

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

Brett Porter moved MNG-2501 to MWAR-107:


Fix Version/s: (was: Reviewed Pending Version Assignment)
  Key: MWAR-107  (was: MNG-2501)
  Project: Maven 2.x War Plugin  (was: Maven 2)

> CLONE -Dependency type "ejb-client" includes main ejb-jar in WAR build.
> ---
>
> Key: MWAR-107
> URL: http://jira.codehaus.org/browse/MWAR-107
> Project: Maven 2.x War Plugin
>  Issue Type: Bug
> Environment: Windows XP SP2, J2SE 5.0
>Reporter: Heinrich Nirschl
>Assignee: Brett Porter
>
> When I specify a dependency as type "ejb-client" for a project whose 
> packaging is set to "war", the build includes the main EJB JAR in the 
> WEB-INF/lib directory, not the EJB client JAR.

-- 
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-2695) -o makes build fail for snapshot plugins

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2695:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.1.x
  Component/s: Artifacts and Repositories

> -o makes build fail for snapshot plugins
> 
>
> Key: MNG-2695
> URL: http://jira.codehaus.org/browse/MNG-2695
> Project: Maven 2
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.0-alpha-1
>Reporter: Kenney Westerhof
> Fix For: 2.1.x
>
>
> I've set the maven-eclipse-plugin version to 2.3-SNAPSHOT in my root pom.
> When I run without -o, the build works fine. All 100 non-deployed 
> snapshot artifacts are resolved 100 times from all of my 10 remote 
> repo's so the build takes ages.
> After a succesful build, I run with -o and the build fails:
> {noformat}
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Failed to resolve artifact.
> GroupId: org.apache.maven.plugins
> ArtifactId: maven-eclipse-plugin
> Version: 2.3-SNAPSHOT
> Reason: System is offline.
>   org.apache.maven.plugins:maven-eclipse-plugin:pom:2.3-SNAPSHOT
> NOTE: Maven is executing in offline mode. Any artifacts not already in your 
> local
> repository will be inaccessible.
> [INFO] 
> 
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Unable to build 
> project for plugin 'org.apache.maven.plugins:maven-eclipse-plugin': POM 
> 'org.apache.maven.
> plugins:maven-eclipse-plugin' not found in repository: System is offline.
>   org.apache.maven.plugins:maven-eclipse-plugin:pom:2.3-SNAPSHOT
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1269)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1517)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListByAggregationNeeds(DefaultLifecycleExecutor.java:381)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:135)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:393)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:182)
> at 
> org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:746)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:394)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.InvalidPluginException: Unable to build 
> project for plugin 'org.apache.maven.plugins:maven-eclipse-plugin': POM 
> 'org.apache.mav
> en.plugins:maven-eclipse-plugin' not found in repository: System is offline.
>   org.apache.maven.plugins:maven-eclipse-plugin:pom:2.3-SNAPSHOT
> at 
> org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:266)
> at 
> org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:184)
> at 
> org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:164)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1252)
> ... 15 more
> Caused by: org.apache.maven.project.ProjectBuildingException: POM 
> 'org.apache.maven.plugins:maven-eclipse-plugin' not found in repository: 
> System is offline.
>   org.apache.maven.plugins:maven-eclipse-plugin:pom:2.3-SNAPSHOT
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:522)
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:227)
> at 
> org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:250)
> ... 18 more
> Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: 
> System is offline.
>   org.apache.maven.plugins:maven-eclipse-plugin:pom:2.3-SNAPSHOT
> at 
> org.apache.maven.artifact.resolver.D

[jira] Closed: (MNG-3041) Apply filters to files in WEB-INF/*.xml

[Brett Porter (JIRA)]

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

Brett Porter closed MNG-3041.
-

   Resolution: Incomplete
Fix Version/s: (was: Reviewed Pending Version Assignment)

> Apply filters to files in WEB-INF/*.xml
> ---
>
> Key: MNG-3041
> URL: http://jira.codehaus.org/browse/MNG-3041
> Project: Maven 2
>  Issue Type: Improvement
>Affects Versions: 2.0.6
>Reporter: Anthony Whitford
>
> I have a WEB-INF/components.xml file that I would like to apply filters to.  
> I figured I could do something like:
> 
> 
> 
> src/main/resources
> 
> components.xml
> 
> 
> 
> src/main/resources
> 
> components.xml
> 
> true
> ..
> 
> 
> 
> And this works -- except for one silly thing:  the components.xml file, now 
> sitting in the target directory, is not included in the war.  I tried several 
> different targetPaths and I can't get it to work...
> It might be easier to to separate filtering from just processing resources.  
> (It might be nice to be able to tokenize almost any file.)

-- 
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-3017) Profile activation by file fails when maven is run outside the pom's directory

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-3017:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.0.x
  Component/s: Profiles

> Profile activation by file fails when maven is run outside the pom's directory
> --
>
> Key: MNG-3017
> URL: http://jira.codehaus.org/browse/MNG-3017
> Project: Maven 2
>  Issue Type: Bug
>  Components: Profiles
>Affects Versions: 2.0.6
> Environment: Darwin Kernel Version 8.9.1
> java version "1.6.0-dp"
> Java(TM) SE Runtime Environment (build 1.6.0-dp-b88-34)
> Java HotSpot(TM) Client VM (build 1.6.0-b88-17-release, mixed mode, sharing)
>Reporter: Jean-Luc Wasmer
> Fix For: 2.0.x
>
> Attachments: maven-test.tgz
>
>
> When calling maven outside the pom's directory, the profile activation fails:
> macb:~/Development/maven-test/parent jl$ mvn install
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO]   Example parent
> [INFO]   Example module1
> [INFO]   Example module2
> [INFO] 
> 
> 
> macb:~/Development/maven-test jl$ mvn -f parent/pom.xml install
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO]   Example parent
> [INFO]   Example module1
> [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] Issue Comment Edited: (MNG-2839) Non-unique-version snapshots not updated

[Pavel Halas (JIRA)]

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

Pavel Halas edited comment on MNG-2839 at 6/15/07 10:45 AM:


Sample projects.

How to use it:
- deploy the dep1 project into a repository with non-unique version setup.
- work with the test project (like c:/temp/test/> mvn package)
- change the local repository content of the dep1-1.0-SNAPSHOT.jar
- enforce updating the dependencies (like c:/temp/test/> mvn package -U)
- check the dep1-1.0-SNAPSHOT.jar local repository content. Sometimes the 
remote repository version is not used.


 was:
Sample projects.

> Non-unique-version snapshots not updated
> 
>
> Key: MNG-2839
> URL: http://jira.codehaus.org/browse/MNG-2839
> Project: Maven 2
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.0.5
>Reporter: Pavel Halas
>Assignee: Brett Porter
> Fix For: 2.0.x
>
> Attachments: dep-update.zip
>
>
> Test case:
> - let's have a repository with[uniqueVersion]false[/uniqueVersion].
> - let your project download any snapshot dependency (with non-unique version) 
> (like abc-1.0-SNAPSHOT.jar).
> - go to your local repository and change the file content. You can also 
> remove all the metadata.
> - run "mvn -U" on your project
> - you get "[INFO] snapshot abc:abc-1.0-SNAPSHOT: checking for updates from 
> YOUR-REPOSITORY"
> - the abc-1.0-SNAPSHOT.jar in your local repository is NOT updated.
> The same (I think) bug has been reported (and closed) several times before 
> (MNG-1908 etc.) but it still appears in 2.0.5.

-- 
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-2839) Non-unique-version snapshots not updated

[Pavel Halas (JIRA)]

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

Pavel Halas updated MNG-2839:
-

Attachment: dep-update.zip

Sample projects.

> Non-unique-version snapshots not updated
> 
>
> Key: MNG-2839
> URL: http://jira.codehaus.org/browse/MNG-2839
> Project: Maven 2
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.0.5
>Reporter: Pavel Halas
>Assignee: Brett Porter
> Fix For: 2.0.x
>
> Attachments: dep-update.zip
>
>
> Test case:
> - let's have a repository with[uniqueVersion]false[/uniqueVersion].
> - let your project download any snapshot dependency (with non-unique version) 
> (like abc-1.0-SNAPSHOT.jar).
> - go to your local repository and change the file content. You can also 
> remove all the metadata.
> - run "mvn -U" on your project
> - you get "[INFO] snapshot abc:abc-1.0-SNAPSHOT: checking for updates from 
> YOUR-REPOSITORY"
> - the abc-1.0-SNAPSHOT.jar in your local repository is NOT updated.
> The same (I think) bug has been reported (and closed) several times before 
> (MNG-1908 etc.) but it still appears in 2.0.5.

-- 
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-2817) Add identity specification in maven-model and maven-settings

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2817:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.1.x
  Component/s: Settings
   POM

> Add identity specification in maven-model and maven-settings
> 
>
> Key: MNG-2817
> URL: http://jira.codehaus.org/browse/MNG-2817
> Project: Maven 2
>  Issue Type: Bug
>  Components: POM, Settings
>Reporter: Vincent Siveton
> Fix For: 2.1.x
>
>
> Some generated objects are used in lists. Thus, it will be very useful to 
> have identity specification for them: equals(..) and hashcode() (see 
> MODELLO-43)
> For instance, see org.apache.maven.model.Resource used in 
> model/build/resources

-- 
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-2901) Cannot have 2 modules as SNAPSHOT in same group id

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2901:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.0.x
  Component/s: Dependencies

> Cannot have 2 modules as SNAPSHOT in same group id
> --
>
> Key: MNG-2901
> URL: http://jira.codehaus.org/browse/MNG-2901
> Project: Maven 2
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 2.0.5
>Reporter: Thomas Carrie
> Fix For: 2.0.x
>
> Attachments: manySnapshotModuleBug.tgz
>
>
> In my project I have base 2 modules : metadatafiles and core
> A third module called metadata depends on the 1st  2 as SNAPSHOT
> Bug reproduction :
> 1) deploy module 1
> 2) deploy module 2
> 3) attemt to compile module 3, it fails
> Expected result : successfull build since there are snapshots for the 2 
> modules in the repository
> It seems that maven2 expects that there should be a most snapshot build for 
> all the modules, it looks to me like an unwanted feature, that's why I submit 
> it as a bug

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

[jira] Updated: (MNG-2852) process-test-classes phase is run even when maven.test.skip is called

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2852:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.2.x
  Component/s: Plugins and Lifecycle

maven.test.skip is nothing really special - it's plugin configuration. To 
support this, we'd need some way to alter the lifecycle to drop all the test 
phases out.

> process-test-classes phase is run even when maven.test.skip is called
> -
>
> Key: MNG-2852
> URL: http://jira.codehaus.org/browse/MNG-2852
> Project: Maven 2
>  Issue Type: Bug
>  Components: Plugins and Lifecycle
>Affects Versions: 2.0.5
>Reporter: Dan Diephouse
> Fix For: 2.2.x
>
>
> I'm have some bytecode processing which occurs in the process-test-classes 
> phase. when I skip the tests, it still tries to run my ant task:
> [INFO] [compiler:testCompile]
> [INFO] Not compiling test sources
> [INFO] [antrun:run {execution: default}]
>  [echo] Running Jibx Ant task
> My task definition looks like this:
> 
> maven-antrun-plugin
> 
>   
> process-test-classes
> 
>   run
> 
> 
>   
> Running Jibx Ant task
>  classpathref="maven.test.classpath" name="jibx" />
>  binding="${basedir}/src/jibx/binding.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: (MNG-2523) OS name activation does not work for Mac OS X

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2523:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.0.x
  Component/s: Profiles

> OS name activation does not work for Mac OS X
> -
>
> Key: MNG-2523
> URL: http://jira.codehaus.org/browse/MNG-2523
> Project: Maven 2
>  Issue Type: Bug
>  Components: Profiles
>Reporter: Jason van Zyl
> Fix For: 2.0.x
>
>
> Using something like:
>   
> 
>   macosx
>   
> 
>   mac os x
> 
>   
>   
> Mac OS X
>   
> 
>  
> Does not work on Mac OS X. The profile is never activated.

-- 
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-2463) Uniform access to phase properties of MavenProject

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2463:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.1.x
  Component/s: Plugin API

> Uniform access to phase properties of MavenProject
> --
>
> Key: MNG-2463
> URL: http://jira.codehaus.org/browse/MNG-2463
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Plugin API
>Affects Versions: 2.0.4
>Reporter: Jochen Kuhnle
> Fix For: 2.1.x
>
>
> MavenProject has a distinct accessor for each phase's properties, e.g. 
> getCompileSourceRoots for the compile and getTestCompileSourceRoots for the 
> test phase. There are also many plugins that essentially do the same in more 
> than one phase (e.g. the compiler plugin). If there was a uniform way to 
> access the same property in different phases, these plugins would be easier 
> to write, because we wouldn't need an abstract base class and different 
> implementations for each phase.
> So what I propose basically is:
> MavenProject.getCompilePhase().getSourceRoots() and 
> MavenProject.getTestPhase().getSourceRoots()

-- 
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-76) Let META-INF/maven/../pom.properties|pom.xml be generated in generate-resources

[Brett Porter (JIRA)]

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

Brett Porter moved MNG-2579 to MJAR-76:
---

Fix Version/s: (was: Reviewed Pending Version Assignment)
   Complexity:   (was: Intermediate)
  Key: MJAR-76  (was: MNG-2579)
  Project: Maven 2.x Jar Plugin  (was: Maven 2)

> Let META-INF/maven/../pom.properties|pom.xml be generated in 
> generate-resources
> ---
>
> Key: MJAR-76
> URL: http://jira.codehaus.org/browse/MJAR-76
> Project: Maven 2.x Jar Plugin
>  Issue Type: Improvement
>Reporter: Kenney Westerhof
>
> Some applications use the META-INF/maven/../pom.properties to read the 
> application/jar version at runtime.
> This file is generated in the package phase.
> During unit tests, or running applications from the workspace (project tree), 
> these files
> are not available, which causes problems.
> Suggest to move the pom.(properties|xml) generating code in the 
> maven-jar-plugin to a separate
> mojo that's bound to generate-resources.

-- 
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-2469) Refactor and refine the getting started guide so that you could do it 10 min

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2469:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   Documentation
  Component/s: Documentation: Guides

> Refactor and refine the getting started guide so that you could do it 10 min
> 
>
> Key: MNG-2469
> URL: http://jira.codehaus.org/browse/MNG-2469
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Documentation: Guides
>Reporter: Marvin King
> Fix For: Documentation
>
>
> "chop up the getting started guide so it is again something you could do in 
> 10 minutes to get a feel for Maven (perhaps go back to the level of the 
> original guide). Maybe rename to something else? I used to call it "the 10 
> minute test" on Maven 1." 

-- 
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-3008) Multiple executions of embedder reuse the ProjectBuildCache

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-3008:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.1.x
  Component/s: Embedding

> Multiple executions of embedder reuse the ProjectBuildCache
> ---
>
> Key: MNG-3008
> URL: http://jira.codehaus.org/browse/MNG-3008
> Project: Maven 2
>  Issue Type: Bug
>  Components: Embedding
>Affects Versions: 2.1-alpha-1
>Reporter: Carlos Sanchez
> Fix For: 2.1.x
>
>
> In DefaultModelLineageBuilder.resumeBuildingModelLineage( ModelLineage 
> lineage, ArtifactRepository localRepository, ProfileManager profileManager )
> there's a call to resolveParentPom passing the projectBuildCache
> This test breaks
> /trunk/pom.xml (a:b:1.0-SNAPSHOT)
> /trunk/child/pom.xml (has a:b:1.0-SNAPSHOT as parent)
> when running a goal in /trunk/child/pom.xml it will cache that 
> a:b:1.0-SNAPSHOT is in /trunk/pom.xml
> now if it's moved or copied to /trunk2 or any other place and the embedder is 
> called again it will use the parent in /trunk/pom.xml instead of 
> /trunk2/pom.xml as it's in the cache
> If it doesn't exist it will throw a FileNotFoundException

-- 
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-2974) Unable to resolve & download snapshot versions from CLI

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2974:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.0.x
  Component/s: Artifacts and Repositories

> Unable to resolve & download snapshot versions from CLI
> ---
>
> Key: MNG-2974
> URL: http://jira.codehaus.org/browse/MNG-2974
> Project: Maven 2
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.0.6
> Environment: Windows
>Reporter: Yves Van Steen
> Fix For: 2.0.x
>
>
> When I try to use a snapshot released version of a plugin on the command line 
> interface maven doesn't resolve these and download them from registered the 
> plugin repositories. When using non snapshot versions it is not a problem to 
> resolve and download them.  When I add the plugin (a snapshot version) to a 
> POM and run it it does download it.  So the problem does not lie with the 
> repo which is registered in the settings.xml in a profile which is active.  
> The problem just seems to lie with the resolving and dowloading part of the 
> process.   Cause after the snapshot plugin is download using the POM way it 
> does find the plugin when running it from the CLI.
> I first discovered this bug when trying to use the Maven install plugin.  
> Here are commands used in the process.  Reproding this way of use I got the 
> same result when requesting other snapshot version of plugins that were not 
> in the repository.
> Command used to load snapshot version from the CLI (this gives the error you 
> find below)
> mvn org.apache.maven.plugins:maven-install-plugin:2.2-SNAPSHOT:install-file 
> (... + correct plugin params ) 
> Command used to load a specific released version from the CLI
> mvn org.apache.maven.plugins:maven-install-plugin:2.1:install-file (... + 
> correct plugin params ) 
> Command used to load a the top released version from the CLI
> mvn org.apache.maven.plugins:maven-install-plugin:install-file (... + correct 
> plugin params ) 
> Settings.xml File
>   
>   apachesnapshots
>   
>   
>   d
>   
> http://people.apache.org/repo/m2-snapshot-repository/
>   
>   false
>   
>   
>   true
>   
> allways
>   
> ignore
>   
>   
>   
>   
> Hope I gave you enough information to fix this error.  It's not major but 
> does hinder me at this point cause now I have to manually place this plugin 
> in everyone of my developers local 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] Updated: (MNG-2941) Sometime SNAPSHOTs can not be downloaded in an an online build

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2941:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.0.x
  Component/s: Artifacts and Repositories

> Sometime SNAPSHOTs can not be downloaded in an an online build
> --
>
> Key: MNG-2941
> URL: http://jira.codehaus.org/browse/MNG-2941
> Project: Maven 2
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.0.5
> Environment: All
>Reporter: Anita Kulshreshtha
> Fix For: 2.0.x
>
>
>  When an offline build fails because a SNPSHOT was not available locally, 
> the SNAPSHOT can not be downloaded during a subsequent online build. During 
> the offline build a  file maven-metadata-apache-snpshots.xml (with the 
> following contents in this example) is created in .m2 repo:
> 
>   org.apache.geronimo.genesis
>   genesis
>   1.2-SNAPSHOT
> 
>All subsequent online builds fail to download this artifact from the 
> repository with error message given below. After deleting the metadata file 
> corresponding to the repository in which this artifact is available 
> (maven-metadata-apache-snpshots.xml file in this example) , the artifact can 
> be downloaded successfully. 
> This trace can be produced by any SNAPSHOT in any project, the following 
> steps are for geronimo:
> 1. Delete the above SNAPSHOT from the local repo.
> 2. Build geronimo offlne, the build will fail.
> 3. Build online, the following message will be generated.
> 4. Delete the above metadata file, and build online, the SNAPSHOT will get 
> downloaded successfully.
> [INFO] Scanning for projects...
> Downloading: 
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/ger
> onimo/genesis/genesis/1.2-SNAPSHOT/genesis-1.2-SNAPSHOT.pom
> [WARNING] Unable to get resource 
> 'org.apache.geronimo.genesis:genesis:pom:1.2-SN
> APSHOT' from repository apache-snapshots 
> (http://people.apache.org/repo/m2-snaps
> hot-repository)
> Downloading: 
> http://snapshots.repository.codehaus.org/org/apache/geronimo/genesi
> s/genesis/1.2-SNAPSHOT/genesis-1.2-SNAPSHOT.pom
> [WARNING] Unable to get resource 
> 'org.apache.geronimo.genesis:genesis:pom:1.2-SN
> APSHOT' from repository codehaus-snapshots 
> (http://snapshots.repository.codehaus
> .org)
> [INFO] 
> 
> [ERROR] FATAL ERROR
> [INFO] 
> 
> [INFO] Failed to resolve artifact.
> GroupId: org.apache.geronimo.genesis
> ArtifactId: genesis
> Version: 1.2-SNAPSHOT
> Reason: Unable to download the artifact from any repository
>   org.apache.geronimo.genesis:genesis:pom:1.2-SNAPSHOT
> from the specified remote repositories:
>   central (http://repo1.maven.org/maven2),
>   apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository),
>   codehaus-snapshots (http://snapshots.repository.codehaus.org),
>   apache-incubator (http://people.apache.org/repo/m2-incubating-repository/),
>   tomcat-m2-repo (http://tomcat.apache.org/dev/dist/m2-repository)
> [INFO] 
> 
> [INFO] Trace
> org.apache.maven.reactor.MavenExecutionException: Cannot find parent: 
> org.apache
> .geronimo.genesis:genesis for project: 
> org.apache.geronimo.genesis.config:config
> :pom:null
> at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:373)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:286)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
> 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:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find 
> parent
> : org.apache.geronimo.genesis:genesis for project: 
> org.apache.geronimo.genesis.c
> onfig:config:pom:null
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(D
> efaultMavenProjectBuilder.java:1198)
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(D
> efaultM

[jira] Moved: (MSITE-236) multi module reporting - main page doesn't show links to contained modules

[Brett Porter (JIRA)]

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

Brett Porter moved MNG-2497 to MSITE-236:
-

Affects Version/s: (was: 2.0.4)
Fix Version/s: (was: Reviewed Pending Version Assignment)
   Complexity:   (was: Intermediate)
  Key: MSITE-236  (was: MNG-2497)
  Project: Maven 2.x Site Plugin  (was: Maven 2)

> multi module reporting - main page doesn't show links to contained modules
> --
>
> Key: MSITE-236
> URL: http://jira.codehaus.org/browse/MSITE-236
> Project: Maven 2.x Site Plugin
>  Issue Type: Bug
>Reporter: Jan Vissers
>
> In a multi module project, the "site" generates a main page index.html, which 
> has the contained modules on the upper left hand corner in bold face. These 
> should be hyperlinks to the actual module's index.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: (MNG-671) implement a license clickthrough

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-671:
-

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.1.x
  Component/s: Dependencies

> implement a license clickthrough
> 
>
> Key: MNG-671
> URL: http://jira.codehaus.org/browse/MNG-671
> Project: Maven 2
>  Issue Type: New Feature
>  Components: Dependencies
>Reporter: Brett Porter
>Assignee: Brett Porter
> Fix For: 2.1.x
>
> Attachments: maven-artifact-manager-patch-2.txt, 
> maven-artifact-manager-patch.txt, maven-artifact-patch-2.txt, 
> maven-license-patches-3.zip, maven-settings-patch-2.txt, 
> maven-settings-patch.txt
>
>
> we need some basic license acceptance policy for downloadable artifacts. For 
> now, this can just be a Y/N that is saved forever.

-- 
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-2443) Don't download pom if artifact is already in the local repository

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2443:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.1.x
  Component/s: Artifacts and Repositories

> Don't download pom if artifact is already in the local repository
> -
>
> Key: MNG-2443
> URL: http://jira.codehaus.org/browse/MNG-2443
> Project: Maven 2
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.0.4
>Reporter: Carsten Ziegeler
> Fix For: 2.1.x
>
>
> There are many projects out there just providing their artifact without a pom 
> (whether this is good or not is a different question). Now in this case m2 
> always tries to download a pom for those artifacts, even if the artifact 
> itself is already in the local repository. And if you have several of those 
> artifacts combined with more than one repository configured, then there are a 
> lot of unnecessary download attempts.
> I think this falls into the same category as changing a pom in the repository 
> (which should be forbidden) - so if for the first time the artifact is 
> downloaded no pom available, then there will never be a pom for this specific 
> artifact.

-- 
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-2725) Make sure MavenEmbedder.execute( request ) always returns a MavenProject instance

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2725:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.1.x
  Component/s: Embedding

> Make sure MavenEmbedder.execute( request ) always returns a MavenProject 
> instance
> -
>
> Key: MNG-2725
> URL: http://jira.codehaus.org/browse/MNG-2725
> Project: Maven 2
>  Issue Type: Bug
>  Components: Embedding
>Reporter: Jason van Zyl
> Fix For: 2.1.x
>
>
> The MavenProject is not being returned correctly when there are failures in 
> the lifecycle. The exceptions need to be propagated back to the caller.

-- 
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-2504) explore how provided app server deps map to app server platform definitions in Netbeans IDE.

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2504:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.1.x
  Component/s: Dependencies

> explore how provided app server deps map to app server platform definitions 
> in Netbeans IDE.
> 
>
> Key: MNG-2504
> URL: http://jira.codehaus.org/browse/MNG-2504
> Project: Maven 2
>  Issue Type: Sub-task
>  Components: Dependencies
>Reporter: Milos Kleint
>Assignee: Milos Kleint
> Fix For: 2.1.x
>
>
> see subject, could be important for IDE integration fo j2ee maven projects.

-- 
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-2584) Rebuild on pom change

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2584:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.2.x
  Component/s: Design, Patterns & Best Practices

> Rebuild on pom change
> -
>
> Key: MNG-2584
> URL: http://jira.codehaus.org/browse/MNG-2584
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Design, Patterns & Best Practices
>Reporter: Kenney Westerhof
> Fix For: 2.2.x
>
>
> After a succesful build, all classes are compiled.
> Following builds won't recompile the classes since the sources
> haven't changed.
> When a user changes a dependency in the pom and then mvn installs, the sources
> aren't checked with the modified dependency.
> I propose we save a timestamp (or the pom itself) in target/ for each build,
> and let plugins that do some sort intelligent checking take this into account.
> There are a few options:
> - define a default location for the pom and let plugins implement timestamp 
> or content checking
>   as they please
> - define some api to ask if the project has changed
> - bind the clean plugin to some startup phase and let it auto-clean if the 
> pom (or possibly parent poms/dependent poms)
>   have changed.
>  

-- 
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-2893) Update the DefaultPluginManager to not use a project depMan for controlling it's transitive dependencies

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2893:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.0.x
  Component/s: Plugins and Lifecycle

> Update the DefaultPluginManager to not use a project depMan for controlling 
> it's transitive dependencies
> 
>
> Key: MNG-2893
> URL: http://jira.codehaus.org/browse/MNG-2893
> Project: Maven 2
>  Issue Type: Task
>  Components: Plugins and Lifecycle
>Affects Versions: 2.0.5
>Reporter: Jason van Zyl
>Assignee: Jason van Zyl
> Fix For: 2.0.x
>
>
> An adjustment to MNG-1577. The classpath for plugins should not be affected 
> by a projects depMan.

-- 
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-2412) global variable filtering of pom.xml for parent and sub module pom.xml files is not working when deploying to a repository.

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2412:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.1.x
  Component/s: Inheritance and Interpolation
   Deployment

> global variable filtering of pom.xml for parent and sub module pom.xml files 
> is not working when deploying to a repository.
> ---
>
> Key: MNG-2412
> URL: http://jira.codehaus.org/browse/MNG-2412
> Project: Maven 2
>  Issue Type: Bug
>  Components: Deployment, Inheritance and Interpolation
>Affects Versions: 2.0.4
> Environment: Windows XP., JDK 1.5
>Reporter: Bill Brown
> Fix For: 2.1.x
>
>
> Greetings:  
> I have a maven2 project with two sub modules.  I run into an issue when I 
> build and deploy a SNAPSHOT of this project and try to reference one of the 
> modules as a dependency when I build another project.  
> here is the project structure. 
> project
> module1
> pom.xml
> module2
> pom.xml
> pom.xml
> The parent pom declares a global property in the properties section:
> 
> 1.1.2-SNAPSHOT
>   
> The parent pom declares the project version in the following way:
> ${applicationVersion}
> The module poms refrence the parent pom with the parent tags:
> 
> com.gocsc
> sam
> ${applicationVersion}
>   
> The module poms both declare the project version in the same way:
> ${applicationVersion}
> The project deploys the artifacts to the corporate repository without error 
> but the generated poms for each sub module and also the parent module do not 
> resolve the  ${applicationVersion} in all of the locations:  
> The parent pom project version remains the same in the deployed pom.
> ${applicationVersion}
> The parent tags in the sub module poms remain the same:
> 
> com.gocsc
> sam
> ${applicationVersion}
>   
> The only section that gets resolved / filtered is the project version tags of 
> the sub modules.
> 1.1.2-20060628.195852-10
> This seems to be what is causing the problem when I use one of the sub 
> modules as dependency in another project and try to build it.  Here is the 
> output: 
> *
> [INFO] snapshot com.gocsc:sam-common:1.1.2-SNAPSHOT: checking for updates 
> from com.gocsc
> Downloading: 
> file:///\\gatling\maven2\repository/com/gocsc/sam/${applicationVersion}/sam-${applicationVersion}.pom
> [WARNING] Unable to get resource from repository com.gocsc 
> (file:///\\gatling\maven2\repository)
> Downloading: 
> http://repo1.maven.org/maven2/com/gocsc/sam/${applicationVersion}/sam-${applicationVersion}.pom
> [WARNING] Unable to get resource from repository central 
> (http://repo1.maven.org/maven2)
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Failed to resolve artifact.
> GroupId: com.gocsc
> ArtifactId: sam
> Version: ${applicationVersion}
> Reason: Unable to download the artifact from any repository
>   com.gocsc:sam:pom:${applicationVersion}
> from the specified remote repositories:
>   central (http://repo1.maven.org/maven2),
>   com.gocsc (file:///\\gatling\maven2\repository)
> ***
> Even if I manually modify the repository pom files to use the timstamp 
> version of: 
> 1.1.2-20060628.195852-10
> I still get the same error above.  
> Is this the expected behavior of the system?  Is this a bug? 

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

[jira] Closed: (MNG-3014) java.lang.NoClassDefFoundError: com/bea/wlw/filesystem/IFileFilter getting this error while running "APPC"

[Brett Porter (JIRA)]

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

Brett Porter closed MNG-3014.
-

   Resolution: Incomplete
Fix Version/s: (was: Reviewed Pending Version Assignment)

please consult the user list for questions - this isn't a problem occuring in 
Maven itself from what I can see.

>  java.lang.NoClassDefFoundError: com/bea/wlw/filesystem/IFileFilter getting 
> this error while running "APPC"
> ---
>
> Key: MNG-3014
> URL: http://jira.codehaus.org/browse/MNG-3014
> Project: Maven 2
>  Issue Type: Bug
>Affects Versions: 2.0.4
> Environment: window xp,maven 2.0.4
>Reporter: Debabrat
>
>  Hello --
> I'm building my application using weblogic9.2 and am up to the part where 
> weblogic.appc ant task kicks in. I get the following error message:
> [
> <[ComplianceChecker] Check
> ing servlet-mapping for servlet name : "ImageViewer".>
> [jspc]  -webapp specified, searching . for JSPs
> java.lang.NoClassDefFoundError: com/bea/wlw/filesystem/IFileFilter
> at weblogic.servlet.jsp.jspc20.runBodyInternal(jspc20.java:420)
> at weblogic.servlet.jsp.jspc20.runJspc(jspc20.java:195)
> at weblogic.servlet.jsp.JspcInvoker.compile(JspcInvoker.java:239)
> at 
> weblogic.application.compiler.AppcUtils.compileWAR(AppcUtils.java:353)
> at 
> weblogic.application.compiler.WARCompiler.compile(WARCompiler.java:78)
> at 
> weblogic.application.compiler.flow.AppCompilerFlow.compileInput(AppCompi
> lerFlow.java:118)
> at 
> weblogic.application.compiler.flow.AppCompilerFlow.compile(AppCompilerFl
> ow.java:43)
> at 
> weblogic.application.compiler.FlowDriver$FlowStateChange.next(FlowDriver
> .java:69)
> at 
> weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriv
> er.java:26)
> at 
> weblogic.application.compiler.FlowDriver.nextState(FlowDriver.java:36)
> at weblogic.application.compiler.FlowDriver.run(FlowDriver.java:26)
> at weblogic.application.compiler.Appc.runBody(Appc.java:163)
> at weblogic.utils.compiler.Tool.run(Tool.java:158)
> at weblogic.utils.compiler.Tool.run(Tool.java:115)
> at weblogic.application.compiler.Appc.main(Appc.java:174)
> at weblogic.appc.main(appc.java:14)
> at org.codehaus.mojo.weblogic.AppcMojo.execute(AppcMojo.java:129)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginMa
> nager.java:412)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Default
> LifecycleExecutor.java:534)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifec
> ycle(DefaultLifecycleExecutor.java:475)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultL
> ifecycleExecutor.java:454)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle
> Failures(DefaultLifecycleExecutor.java:306)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(
> DefaultLifecycleExecutor.java:273)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifec
> ycleExecutor.java:140)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
> a:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
> Impl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> [ERROR] Exception encountered during APPC processing
> java.lang.NoClassDefFoundError: com/bea/wlw/filesystem/IFileFilter
> at weblogic.servlet.jsp.jspc20.runBodyInternal(jspc20.java:420)
> at weblogic.servlet.jsp.jspc20.runJspc(jspc20.java:195)
> at weblogic.servlet.jsp.JspcInvoker.compile(JspcInvoker.java:239)
> at 
> weblogic.application.compiler.AppcUtils.compileWAR(AppcUtils.java:353)
> at 
> weblogic.application.compiler.WARCompiler.compile(WARCompiler.java:78)
> at 
> weblogic.application.compiler.flow.AppCompilerFlow.compileInput(AppCompi
> lerFlow.java:118)
> at 
> weblogic.application.compiler.flow.AppCo

[jira] Moved: (SUREFIRE-341) Surefire fails with java.lang.ClassNotFoundException: org.apache.maven.surefire.Surefire

[Brett Porter (JIRA)]

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

Brett Porter moved MNG-3045 to SUREFIRE-341:


Affects Version/s: (was: 2.0.6)
Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.5
  Key: SUREFIRE-341  (was: MNG-3045)
  Project: Maven Surefire  (was: Maven 2)

> Surefire fails with java.lang.ClassNotFoundException: 
> org.apache.maven.surefire.Surefire
> 
>
> Key: SUREFIRE-341
> URL: http://jira.codehaus.org/browse/SUREFIRE-341
> Project: Maven Surefire
>  Issue Type: Bug
>Reporter: Pär Wenåker
> Fix For: 2.5
>
>
> Surefire fails with exception:
> org.apache.maven.surefire.booter.SurefireExecutionException: Unable to 
> instantiate and execute Surefire; nested exception is 
> java.lang.ClassNotFoundException: org.apache.maven.surefire.Surefire
> java.lang.ClassNotFoundException: org.apache.maven.surefire.Surefire
> at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> at 
> org.apache.maven.surefire.booter.IsolatedClassLoader.loadClass(IsolatedClassLoader.java:103)
> at 
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:281)
> at 
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818)
> This is probably due to the maven repository being located in a director 
> containing a Swedish letter (C:\Documents and Settings\Pär\.m2\repository). 
> When I changed the location of the repository the problem disappeared

-- 
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-2858) Maven isn't looking in all repositories

[Brett Porter (JIRA)]

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

Brett Porter closed MNG-2858.
-

   Resolution: Incomplete
Fix Version/s: (was: Reviewed Pending Version Assignment)

we need more information to reproduce this, as stated... hasn't gotten a 
response since.

> Maven isn't looking in all repositories
> ---
>
> Key: MNG-2858
> URL: http://jira.codehaus.org/browse/MNG-2858
> Project: Maven 2
>  Issue Type: Bug
>Affects Versions: 2.0.5
>Reporter: David Jackman
>
> I've created a settings.xml that lists all of our internal repositories (some 
> Maven 1, some Maven 2).  One of these repositories contains the parent POM 
> for the project I'm trying to build.  However, Maven reports that it can't 
> "locate resource in repository" and lists all of the repositories in 
> settings.xml.
>  
> Looking at the debug output, it seems like Maven is only looking for the 
> parent pom in the first of the repositories in this list (the one just after 
> central).  The correct repository is the second one in the list.
>  
> To test this theory, I removed the repository it was having problems with 
> from settings.xml.  Sure enough, Maven found the parent pom just fine.  I 
> also changed the ID of the repository in settings.xml (which changes its 
> position in the list--must be a HashMap or something) and it found the parent 
> pom just fine in this situation, 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: (MNG-2532) System properties cannot be set from Profiles or Settings.xml

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2532:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.0.x
  Component/s: Settings
   Profiles

> System properties cannot be set from Profiles or Settings.xml
> -
>
> Key: MNG-2532
> URL: http://jira.codehaus.org/browse/MNG-2532
> Project: Maven 2
>  Issue Type: Bug
>  Components: Profiles, Settings
>Affects Versions: 2.0.4
> Environment: Windows XP 
>Reporter: Peter Pilgrim
> Fix For: 2.0.x
>
>
> Hi All
> With the maven-antrun-plugin in Maven 2.0.4 is it possibly to define a system 
> property. Instead of me doing this all the time.
> mvn install -Duser.install.root="C:\Program Files\IBM\WebSphere\AppServer"
> For more info on the context see my blog 
> http://www.jroller.com/page/peter_pilgrim?entry=how_to_configure_xemacs_http
> Specifically  the system properties is not set up following to either a 
> profiles.xml or settings.xml file by Maven 2
> Possibly the system property I need is not also transfered to the Ant task 
> using the maven-antrun-plugin.
> /* profiles.xml */
> 
>   
> user-install-root
> 
>   
> !user.install.root
>   
> 
> 
>   C:\\Program 
> Files\\IBM\\WebSphere\\AppServer
> 
>   
> 
> Running mvn help:active-profiles, however, does show that the profile has 
> been read.
> C:\WORKSP~2\M2SPRI~1\ejb>mvn help:active-profiles
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'help'.
> [INFO] 
> -
> ---
> [INFO] Building Maven 2.0 Spring EJB Research Project (EJB Module)
> [INFO]task-segment: [help:active-profiles] (aggregator-style)
> [INFO] 
> -
> ---
> [INFO] [help:active-profiles]
> [INFO]
> Active Profiles for Project 
> 'com.ubs.firc.ptsp.research.ejb:M2SpringEJBExample-e
> jb:ejb:1.0-SNAPSHOT':
> The following profiles are active:
>  - user-install-root (source: profiles.xml)
> [INFO] 
> 
> [INFO] BUILD SUCCESSFUL
> [INFO] 
> 
> [INFO] Total time: 1 second
> [INFO] Finished at: Tue Aug 29 10:46:31 BST 2006
> [INFO] Final Memory: 2M/5M
> [INFO] 
> 
> C:\WORKSP~2\M2SPRI~1\ejb>
> Thanks Peter Pilgrim

-- 
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: (MPIR-68) Actual Time field of Project Team report contains wrong timezone info

[Brett Porter (JIRA)]

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

Brett Porter moved MNG-2775 to MPIR-68:
---

Affects Version/s: (was: 2.0.4)
Fix Version/s: (was: Reviewed Pending Version Assignment)
   Complexity:   (was: Intermediate)
  Key: MPIR-68  (was: MNG-2775)
  Project: Maven 2.x Project Info Reports Plugin  (was: Maven 2)

> Actual Time field of Project Team report contains wrong timezone info
> -
>
> Key: MPIR-68
> URL: http://jira.codehaus.org/browse/MPIR-68
> Project: Maven 2.x Project Info Reports Plugin
>  Issue Type: Bug
> Environment: Windows XP Pro
> Local timezone is set to GMT-05:00 Estern Time (US & Canada)
> Regional and Language Settings: Standards and Formats is set to English 
> (Canada) and Location is set to Canada.
>Reporter: Louis Dourte
> Attachments: pom.xml, team-list.html
>
>
> In a project whith developers in multiple timezones, the "Actual Time" field 
> of all developers have "GMT-0500 (Eastern Standard Time)" shown after the 
> local time even for those developers whose timezone is set to somethign other 
> than "-5". See attached pom.xml and team-list.html files.

-- 
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-2679) Support proper project identity in site URLs

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2679:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.2.x
  Component/s: Sites & Reporting

> Support proper project identity in site URLs
> 
>
> Key: MNG-2679
> URL: http://jira.codehaus.org/browse/MNG-2679
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Sites & Reporting
>Reporter: John Allen
> Fix For: 2.2.x
>
>
> IMHO there is a lack of proper POM UID namespace management in the URL 
> inheritence and extension  schemes used in site generation. I may have 
> a latest version of a project and this may have a nice site but i need to be 
> able to continue to access, and critically link to (from other projects), 
> older versions of the same project's sites. The 'latest' version can always 
> be made accessible via some nice URL mapping e.g. 
> http://maven.apache.org/plugins/maven-clean-plugin/ == 
> http://maven.apache.org/org/apache/maven/plugins/maven-clean-plugin/2.1.1/
> For me a site is simply another 'view' onto a project's products and in the 
> same way one can access different versions of those products based on specify 
> the version one can not access the various different sites. Note this can be 
> done by manually specifying the project.url and 
> project.distributionManagement.site.url for every project such that the URLS 
> include the group, artefact and versionId information but this is error prone 
> and nasty.
> In a nutshell, for us a project's site is just another project artefact and 
> therefore its identity should be preserved in the same robust way the the 
> other project products are (jars, pom, src-jars etc), i.e. stored in a unique 
> federated namespace. 
>  

-- 
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-2502) mvn package does not work on J2EE multi module build

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2502:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.0.x
  Component/s: Reactor and workspace

> mvn package does not work on J2EE multi module build
> 
>
> Key: MNG-2502
> URL: http://jira.codehaus.org/browse/MNG-2502
> Project: Maven 2
>  Issue Type: Bug
>  Components: Reactor and workspace
>Affects Versions: 2.0.4
> Environment: Linux, J2SE 1.4
>Reporter: Heinrich Nirschl
> Fix For: 2.0.x
>
>
> In a multi module build consisting of an ejb.jar (with an ejb-client.jar), a 
> war, and an ear where the war depends on the ejb-client.jar and the ear 
> depends on the ejb.jar and the war, a reactor build with
> mvn package
> fails. The war build tries to download the ejb-client.jar from the repository 
> instead of using the just built version.
> If I first run 'mvn install' in the ejb module the following multi module 
> 'mvn package' succeeds.
> This issue causes also problems for the realease plugin since the sub build 
> fails.

-- 
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-2675) add getModules() method which return a MavenProject List instead of module name String list

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2675:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.1.x
  Component/s: POM

> add getModules() method which return a MavenProject List instead of module 
> name String list
> ---
>
> Key: MNG-2675
> URL: http://jira.codehaus.org/browse/MNG-2675
> Project: Maven 2
>  Issue Type: Improvement
>  Components: POM
>Affects Versions: 2.0.4
> Environment: Maven 2.0.4, Windows 2000
>Reporter: David Vicente
> Fix For: 2.1.x
>
>
> Hi,
> i try to develop a dashboard report plugin.
> But i have a problem with a multi-project pom which i used to test my plugin.
> I have a master project with modules which have some modules or project.
> Until now, i get the modules list with project.getModules() method and i 
> compare each module name with the project name that i get with 
> project.getCollectedProjects() method.
> And for each MavenProject object i retreive, i repeat the last algorithm 
> (getModules() .)
> all module names are the same as ArtifactId and my plugin work well.
> But with this new project, the module names and ArtifactId are different.
> and i can't retreive MavenProjects which are direct module of my pom.
> can you add a method to MavenProject object which return the list of modules 
> as MavenProject object instead of String object ?

-- 
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-2785) Incorrect system dependency results the compile-dependent libraries not be included into war

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2785:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.1.x
  Component/s: Dependencies

> Incorrect system dependency results the compile-dependent libraries not be 
> included into war
> 
>
> Key: MNG-2785
> URL: http://jira.codehaus.org/browse/MNG-2785
> Project: Maven 2
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 2.0.4
> Environment: $ java -version
> java version "1.5.0_04"
> $ mvn -v
> Maven version: 2.0.4
>Reporter: Dmitry Katsubo
> Fix For: 2.1.x
>
>
> I want to build a .war file in {{frontend}} project, that depends on 
> {{sabre-lib}} library:
> {code:xml|title=frontend/pom.xml}
> 
>   
>   com.company.sabre
>   sabre-lib
>   0.5
>   
> ...
> {code} 
> The {{sabre-lib}} library itself has the system dependency, that refers the 
> library within the same project, plus one {{sabre-ota-common}} library with 
> common classes:
> {code:xml|title=sabre-lib/pom.xml}
> 
>   
>   ${project.groupId}
>   sabre-ota-common
>   0.1
>   
>   
>   com.sun.xml.messaging.saaj
>   saaj-impl
>   1.3
>   system
>   ${basedir}/lib/saaj-ri.jar
>   true
>   
> ...
> {code}
> When building {{frontend}}, the following message is produced:
> {quote}
> [WARNING] POM for 'com.company:sabre-lib:pom:0.5:compile' is invalid. It will 
> be ignored for artifact resolution. Reason: Failed to validate POM
> [DEBUG] Reason: Failed to validate POM
> [DEBUG] Validation Errors:
> [DEBUG] For dependency Dependency \{groupId=com.sun.xml.messaging.saaj, 
> artifactId=saaj-impl, version=1.3, type=jar\}: system-scoped dependency must 
> specify an absolute path systemPath.
> {quote}
> and, as the result, {{sabre-lib}} is packaged into .war, and 
> {{sabre-ota-common}} is not. I think, this is because 
> {{$\{basedir\}/lib/saaj-ri.jar}} is resolved in {{frontend}} project scope to 
> its directory. However:
> # As soon as optional system dependencies should not be packaged, why to 
> check the path? (solution, provided in [MNG-1173] and [MNG-1187] does not 
> help)
> # Even with  {{$\{basedir\}}} of {{frontend}} project, the path is still 
> absolute, though non-existent. The error message is incorrect then.
> # The build process should fail, as soon as .war is finally incorrectly 
> packaged.

-- 
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-2973) Cannot specify a version range for build extensions

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2973:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.1.x
  Component/s: Plugins and Lifecycle
   Artifacts and Repositories

> Cannot specify a version range for build extensions
> ---
>
> Key: MNG-2973
> URL: http://jira.codehaus.org/browse/MNG-2973
> Project: Maven 2
>  Issue Type: Bug
>  Components: Artifacts and Repositories, Plugins and Lifecycle
>Affects Versions: 2.0.5
>Reporter: Tim Meighen
> Fix For: 2.1.x
>
> Attachments: pom.xml
>
>
> When specifying a version range in a build extension, I get the following:
> + Error stacktraces are turned on.
> Maven version: 2.0.6
> [DEBUG] Building Maven user-level plugin registry from: 
> '/Users/tmeighen/.m2/plugin-registry.xml'
> [DEBUG] Building Maven global-level plugin registry from: 
> '/Users/tmeighen/maven/conf/plugin-registry.xml'
> [INFO] Scanning for projects...
> [DEBUG] Initialising extension: junit:junit
> [INFO] 
> 
> [ERROR] FATAL ERROR
> [INFO] 
> 
> [INFO] An invalid artifact was detected.
> This artifact might be in your project's POM, or it might have been included 
> transitively during the resolution process. Here is the information we do 
> have for this artifact:
> o GroupID: junit
> o ArtifactID:  junit
> o Version: <<< MISSING >>>
> o Type:pom
> [INFO] 
> 
> [DEBUG] Trace
> org.apache.maven.artifact.InvalidArtifactRTException: For artifact 
> {junit:junit:null:pom}: The version cannot be empty.
> at 
> org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:147)
> at 
> org.apache.maven.artifact.DefaultArtifact.(DefaultArtifact.java:122)
> at 
> org.apache.maven.artifact.factory.DefaultArtifactFactory.createArtifact(DefaultArtifactFactory.java:158)
> at 
> org.apache.maven.artifact.factory.DefaultArtifactFactory.createArtifact(DefaultArtifactFactory.java:117)
> at 
> org.apache.maven.artifact.factory.DefaultArtifactFactory.createArtifact(DefaultArtifactFactory.java:111)
> at 
> org.apache.maven.artifact.factory.DefaultArtifactFactory.createArtifact(DefaultArtifactFactory.java:40)
> at 
> org.apache.maven.artifact.factory.DefaultArtifactFactory.createProjectArtifact(DefaultArtifactFactory.java:95)
> at 
> org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:94)
> at 
> org.apache.maven.extension.DefaultExtensionManager.addExtension(DefaultExtensionManager.java:98)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.findExtensions(DefaultLifecycleExecutor.java:158)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:141)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> [INFO] 
> 
> [INFO] Total time: < 1 second
> [INFO] Finished at: Tue May 01 17:53:00 PDT 2007
> [INFO] Final Memory: 2M/1016M
> [INFO] 
> 
> Note that this works with Maven 2.0.5.  Also the same version range works 
> with 2.0.6 when specified in the dependencies section (i.e. not a build 
> extension).

-- 
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-2542) Remove carriage returns and tabs from field values in the manifest file

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2542:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   Shared Components
  Component/s: maven-archiver

> Remove carriage returns and tabs from field values in the manifest file
> ---
>
> Key: MNG-2542
> URL: http://jira.codehaus.org/browse/MNG-2542
> Project: Maven 2
>  Issue Type: Bug
>  Components: maven-archiver
>Affects Versions: 2.0.4
>Reporter: Tim O'Brien
> Fix For: Shared Components
>
>
> When creating a JAR Manfiest, maven needs to remove CR and Tabs from the 
> description taken from the POM.  
> This is a critical issue with JAR files created from Maven.  The issue is 
> that Maven can create a MANIFEST file for a JAR, but it creates an invalid 
> manifest if you jsut happen to have a description in your POM like thi:
> 
> this is an library for idiots
> 
> The issue is that your description element has new line characters and thejar 
> plugin just take those new line characters and blindly copies them into the 
> Manfiest, creating an invalid Manifest.   This doesn't show up until you try 
> to use the JAR in another application.  Then you get a very cryptic error 
> message about having an invalid jar.
> This used to be 1247 but it was closed and marked as Won't Fix with no 
> explanation as to why it isn't worth fixing.

-- 
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-2971) Variables are not replaced into installed pom file

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2971:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.0.x
  Component/s: Inheritance and Interpolation
   Deployment

> Variables are not replaced into installed pom file
> --
>
> Key: MNG-2971
> URL: http://jira.codehaus.org/browse/MNG-2971
> Project: Maven 2
>  Issue Type: Bug
>  Components: Deployment, Inheritance and Interpolation
> Environment: Windows, Solaris
> Maven version 2.0.4
>Reporter: Laurent Dauvilaire
> Fix For: 2.0.x
>
>
> Variables are not replaced into installed pom file.
> Here is a sample pom file
> http://maven.apache.org/POM/4.0.0";
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
> http://maven.apache.org/maven-v4_0_0.xsd";>
>   4.0.0
>   com.xxx.root
>   root
>   pom
>   ${prop.version}
>   My Project
> ...
>   
>   3.0.20
>   
> 
> The installed pom is into 
> ${localRepository}/com/xxx/root/root/3.0.20/root-3.0.20.pom
> is the same as the project pom file but the version referenced into the 
> installed pom file is ${prop.version} instead of 3.0.20
> which creates problem to artifacts depending of this one.
> Thanks in advance

-- 
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-2944) relativePath tag doesn't work correctly

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2944:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.0.x
  Component/s: Reactor and workspace
   Inheritance and Interpolation

> relativePath tag doesn't work correctly
> ---
>
> Key: MNG-2944
> URL: http://jira.codehaus.org/browse/MNG-2944
> Project: Maven 2
>  Issue Type: Bug
>  Components: Inheritance and Interpolation, Reactor and workspace
>Affects Versions: 2.0.6
> Environment: WinXP Pro, Sun JDK 1.6b2, Maven 2.0.6
>Reporter: Stefano Lenzi
> Fix For: 2.0.x
>
>
> The parent / relativePath tag seems to buggy, because sometimes it generates 
> a path that ends with ../pom.xml instead of pom.xml
> I'll add some example:
> 1st Case: WORKS OK
> Child POM:
>  
>felix
>org.apache.felix
>0.9.0-incubator-SNAPSHOT
>../../pom.xml
>  
> Genereted Path:
> [WARNING] Unable to load parent project from repository: Could not find the 
> model file 
> 'D:\Progetti\Felix\trunk\tools\maven2\maven-bundle-plugin\..\..\pom.xml'.
> 2nd Case: WORKS BAD
> Child POM:
>  
>felix
>org.apache.felix
>0.9.0-incubator-SNAPSHOT
>../../../pom.xml
>  
> Genereted Path:
> [WARNING] Unable to load parent project from repository: Could not find the 
> model file 
> 'D:\Progetti\Felix\trunk\tools\maven2\maven-bundle-plugin\..\..\..\..\pom.xml'.
> 3rd Case: WORKS BAD
> Child POM:
>  
>felix
>org.apache.felix
>0.9.0-incubator-SNAPSHOT
>../../../../trunk/pom.xml
>  
> Genereted Path:
> [WARNING] Unable to load parent project from repository: Could not find the 
> model file 
> 'D:\Progetti\Felix\trunk\tools\maven2\maven-bundle-plugin\..\..\..\..\trunk\..\pom.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: (MNG-2500) Zip files are not included in the test classpath

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2500:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.0.x
  Component/s: Dependencies

> Zip files are not included in the test classpath
> 
>
> Key: MNG-2500
> URL: http://jira.codehaus.org/browse/MNG-2500
> Project: Maven 2
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 2.0.4
> Environment: windows xp
>Reporter: rudi grasmuck
> Fix For: 2.0.x
>
>
> when i added a dependency that was zip file 
> eg
>   hsqldb
>   hsqldb
>   1.7.3.0
>   provided
>   zip
>   
>  this file was not included in the test classpath and so the test would not 
> pass

-- 
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-2906) version ranges don't work after a day has passed

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2906:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.1.x
  Component/s: Artifacts and Repositories

> version ranges don't work after a day has passed
> 
>
> Key: MNG-2906
> URL: http://jira.codehaus.org/browse/MNG-2906
> Project: Maven 2
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Reporter: Bill Dudney
> Fix For: 2.1.x
>
>
> dependency A has a range dependency on B
> my project has a dependency on A (not directly on B)
> I build my project with a fresh clean repo (i.e. rm -rf ~/.m2/repository)
> B's latest is downloaded as expected
> the next morning I rebuild my project and I get error messages that no 
> suitable version can be found;
> No versions are present in the repository for the artifact with a range 
> [1.02b,) com.lowagie:itext-null.jar
> the particulars are jfreereports depending on [1.02b,) of lowagie.

-- 
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-2599) Repository Mirrors in settings.xml need to specify layout

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2599:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.1.x
  Component/s: Settings
   Artifacts and Repositories

> Repository Mirrors in settings.xml need to specify layout
> -
>
> Key: MNG-2599
> URL: http://jira.codehaus.org/browse/MNG-2599
> Project: Maven 2
>  Issue Type: Bug
>  Components: Artifacts and Repositories, Settings
>Reporter: John Casey
> Fix For: 2.1.x
>
>
> Mirrors are different sites from the main one. Since they could be arranged 
> in almost any directory structure and still be a logical mirror of the 
> artifacts on the original site, and since we now support 
> * in the mirror specification, they also need to 
> allow/require the  element from the repository, to specify how the 
> mirrored artifact repository should be constructed/accessed.

-- 
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-3044) A dependency on a test-jar should bring in the main artifact as a dependency

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-3044:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.1.x
  Component/s: Dependencies

> A dependency on a test-jar should bring in the main artifact as a dependency
> 
>
> Key: MNG-3044
> URL: http://jira.codehaus.org/browse/MNG-3044
> Project: Maven 2
>  Issue Type: Bug
>  Components: Dependencies
>Reporter: Kenney Westerhof
> Fix For: 2.1.x
>
>
> Note that this issue is NOT a duplicate of MNG-1378 ea.
> Since test-classes (src/test/java) have src/main/java in the classpath while 
> compiling, and often use code from it,
> the main classes should be included in the classpath if there's a dependency 
> on the test jar.
> Consider:
> Project A has src/main/java/Main.java and src/test/java/Test.java, where 
> Test.java uses Main.java.
> Project A is packaged as a normal jar and has an attached test-jar.
> Project B depends on A's test-jar, because it wants to use Test.java 
> (Test.class).
> This fails because of a NoClassDefFound on Main.class: B's compiletime 
> classpath contains B's sources and the test-jar. It should also contain
> A's main artifact.
> Test-jars have a compile-time (and runtime) dependency on the main classes; 
> maven should bring in the main artifact aswell.

-- 
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-2957) attached artifact is not included in classpath when a sub-project depended on it is compiled in multi-project

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2957:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.0.x
  Component/s: Inheritance and Interpolation

> attached artifact is not included in classpath when a sub-project depended on 
> it is compiled in multi-project
> -
>
> Key: MNG-2957
> URL: http://jira.codehaus.org/browse/MNG-2957
> Project: Maven 2
>  Issue Type: Bug
>  Components: Inheritance and Interpolation
>Affects Versions: 2.0.6
>Reporter: YOKOTA Takehiko
> Fix For: 2.0.x
>
>
> I have a mult-project. It contains two sub-project A and B, and A has an 
> attached artifact A.jar (main artifact is A.zip).
> In addition, B depends on A.jar in compile scope. When I build this 
> mult-project like 'mvn install', it fails because
> A.jar is not included in the classpath for compiling B.
> The reason is that, as for A.jar, 
> org.apache.maven.project.MavenProject#replaceWithActiveArtifact() returns a 
> copied Artifact
> of the AttachedArtifact object created by 
> org.apache.maven.projectMavenProjectHelper#attachArtifact() and
> the value of its scope property is null. So this Artifact is ignored in 
> MavenProject#getCompileClasspathElements().
> In MavenProject#replaceWithActiveArtifact(), the scope property's value of a 
> copied Artifact from attached should be the
> same as one's value of pluginArtifact.

-- 
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-3053) Define an Repository Manager API for reaching far RMs for various inquiries

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-3053:
--

Component/s: (was: Shared)
 (was: Settings)
 (was: Repositories)
 Artifacts and Repositories

> Define an Repository Manager API for reaching far RMs for various inquiries
> ---
>
> Key: MNG-3053
> URL: http://jira.codehaus.org/browse/MNG-3053
> Project: Maven 2
>  Issue Type: Wish
>  Components: Artifacts and Repositories
>Reporter: Tamás Cservenák
> Fix For: Reviewed Pending Version Assignment
>
>
> Maven Community should define a common API for reaching Repository Managers 
> in programmatic way. Repository Manager implementations could implement this 
> API fully or just partially (depending on their capabilities, etc).
> This API could be used by various Maven related tools (like M2Eclipse plugin) 
> in searches, indexing etc.
> Possible RM published functionalities:
>  - direct searching by passing some expressions/lucene queries/whatever
>  - preparing and offering Lucene/Compass index downloads
>  - turning reposes online/offine, reachable/unreachable, etc
>  - Basic RM configurations, repo blackouts, repo controlling
>  - Advanced RM configurations (probably RM specific?)

-- 
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-2773) Plugin repositories are chekced for SNAPSHOTS on every run in the 2.0.5 candidate

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2773:
--

Component/s: (was: Repositories)

> Plugin repositories are chekced for SNAPSHOTS on every run in the 2.0.5 
> candidate
> -
>
> Key: MNG-2773
> URL: http://jira.codehaus.org/browse/MNG-2773
> Project: Maven 2
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.0.5
>Reporter: Trygve Laugstol
>Assignee: Kenney Westerhof
> Fix For: 2.0.5
>
>
> Trussing the mvn process shows that Maven tries to connect to the plugin 
> repository on every run, instead of the daily check.
> {code}
> [16:38:[EMAIL PROTECTED]:monitor-core]$ truss -t connect mvn 
> -Dmaven.test.skip=true install
> [INFO] Scanning for projects...
> [INFO] 
> 
> [INFO] Building Unnamed - no.java.monitor:monitor-core:jar:1.0-SNAPSHOT
> [INFO]task-segment: [install]
> [INFO] 
> 
> [INFO] artifact org.apache.maven.plugins:maven-resources-plugin: checking for 
> updates from codehaus-snapshots
> /1: connect(8, 0xFFBFBAF4, 16, SOV_DEFAULT) = 0
> /1: connect(7, 0xFFBFBD98, 16, SOV_DEFAULT) = 0
> [INFO] artifact org.apache.maven.plugins:maven-compiler-plugin: checking for 
> updates from codehaus-snapshots
> /1: connect(7, 0xFFBFBD80, 16, SOV_DEFAULT) = 0
> [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking for 
> updates from codehaus-snapshots
> /1: connect(9, 0xFFBFBD98, 16, SOV_DEFAULT) = 0
> [INFO] artifact org.apache.maven.plugins:maven-jar-plugin: checking for 
> updates from codehaus-snapshots
> /1: connect(7, 0xFFBFBD80, 16, SOV_DEFAULT) = 0
> [INFO] artifact org.apache.maven.plugins:maven-install-plugin: checking for 
> updates from codehaus-snapshots
> [INFO] [plexus:descriptor {execution: default}]
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [WARNING] 
> Artifact junit:junit:jar:3.8.1:test retains local scope 'test' 
> overriding broader scope 'compile'
> given by a dependency. If this is not intended, modify or remove the 
> local scope.
> {code}

-- 
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-2555) maven-metadata.xml for springframework.spring is missing recent versions

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2555:
--

Component/s: (was: Repositories)
 Artifacts and Repositories

> maven-metadata.xml for springframework.spring is missing recent versions
> 
>
> Key: MNG-2555
> URL: http://jira.codehaus.org/browse/MNG-2555
> Project: Maven 2
>  Issue Type: Bug
>  Components: Artifacts and Repositories
> Environment: all
>Reporter: Stephen Coy
>Assignee: Carlos Sanchez
>Priority: Minor
>
> The maven-metadata.xml file for springframework.spring @ ibiblio 
>  
> is missing recent version information - 1.2.7, 1.2.8 and all the 2.0RC 
> releases.
> The main consequence of this (for me) is that the version range [1.2,1.3) 
> resolves to 1.2.6 instead of 1.2.8.

-- 
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-2474) missing jar files in javax repository

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2474:
--

Component/s: (was: Repositories)
 Artifacts and Repositories

> missing jar files in javax repository
> -
>
> Key: MNG-2474
> URL: http://jira.codehaus.org/browse/MNG-2474
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Artifacts and Repositories
>Affects Versions: 2.0.4
> Environment: independent
>Reporter: Marcel Baumann
>Assignee: Vincent Siveton
> Fix For: 2.0.5
>
>
> Hi all 
> I do not know, who is responsible for the Raven 2 repository javax. There are 
> missing jar files in:
> javax.transaction
> javax.security
> ...more?
> Missing:
> --
> 1) javax.transaction:jta:jar:1.0.1B
> In the repository only these files exist:
> http://www.ibiblio.org/maven2/javax/transaction/jta/1.0.1B/
>  jta-1.0.1B.pom  08-Nov-2005 16:58 1k  
>  jta-1.0.1B.pom.md5  08-Nov-2005 17:45 1k  
>  jta-1.0.1B.pom.sha1 08-Nov-2005 17:45 1k  
> Thanks.
> Marcel

-- 
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-3007) Resolving legacy dependency ignores transitive dependencies

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-3007:
--

Component/s: (was: Repositories)
 (was: Dependencies)
 Artifacts and Repositories

> Resolving legacy dependency ignores transitive dependencies
> ---
>
> Key: MNG-3007
> URL: http://jira.codehaus.org/browse/MNG-3007
> Project: Maven 2
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.0.6
>Reporter: Dirk Olmes
> Fix For: Reviewed Pending Version Assignment
>
>
> Trying to resolve a dependency from a repo with legacy layout 
> (dist.codehaus.org) seems to ignore this dependency's transitive dependencies.
> I stumbled over this issue while building mule: the xfire module depends on 
> jaxen which is available from dist.codehaus.org (legacy layout) and from 
> central (m2 repo layout). For xfire we need to have dist.codehaus.org in the 
> pom.
> When pulling jaxen from the legacy layout all transitive dependencies, 
> although declared in the legacy pom, will not be included in this module's 
> dependencies. If I happen to have jaxen already fetched from central into my 
> local repo, the transitive dependencies will show up, causing the entire 
> build to fail.
> IMHO the dependency resolution of m1 poms should consider that artifact's 
> transitive dependencies as it is the case with m2 poms.

-- 
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-2747) Maven doesn't detect invalid dependency descriptions in the pom

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2747:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.1.x
  Component/s: POM

> Maven doesn't detect invalid dependency descriptions in the pom
> ---
>
> Key: MNG-2747
> URL: http://jira.codehaus.org/browse/MNG-2747
> Project: Maven 2
>  Issue Type: Bug
>  Components: POM
>Affects Versions: 2.0.4
> Environment: Ubuntu 6.10
>Reporter: Tim Kettler
> Fix For: 2.1.x
>
> Attachments: testpom.tgz
>
>
> Maven doesn't detect that the following pom snippet is not valid:
> [...]
> 
> jdom
> jdom
> 1.0  
> 
> [...]
> if 'mvn compile' is run on the included test project, this is what happens:
> [EMAIL PROTECTED]:~/Develop/testpom$ mvn compile
> [INFO] Scanning for projects...
> [INFO] 
> 
> [INFO] Building testproject
> [INFO]task-segment: [compile]
> [INFO] 
> 
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:compile]
> Compiling 1 source file to /home/tik/Develop/testpom/target/classes
> [INFO] 
> 
> [ERROR] BUILD FAILURE
> [INFO] 
> 
> [INFO] Compilation failure
> /home/tik/Develop/testpom/src/main/java/TestClass.java:[1,16] package 
> org.jdom does not exist
> /home/tik/Develop/testpom/src/main/java/TestClass.java:[5,12] cannot find 
> symbol
> symbol  : class Element
> location: class TestClass
> [INFO] 
> 
> [INFO] For more information, run Maven with the -e switch
> [INFO] 
> 
> [INFO] Total time: 2 seconds
> [INFO] Finished at: Mon Jan 08 19:23:14 CET 2007
> [INFO] Final Memory: 3M/8M
> [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] Updated: (MNG-2581) Mojo's with @execute don't get configured with executedProject

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2581:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.1.x
  Component/s: Plugins and Lifecycle

> Mojo's with @execute don't get configured with executedProject
> --
>
> Key: MNG-2581
> URL: http://jira.codehaus.org/browse/MNG-2581
> Project: Maven 2
>  Issue Type: Bug
>  Components: Plugins and Lifecycle
>Reporter: Kenney Westerhof
> Fix For: 2.1.x
>
>
> Not sure if this is a bug or an improvement, but here's a scenario:
> A custom plugin defines a MavenProject property with a timestamp. That 
> timestamp
> is used in ${project.artifactId}-${timestamp}.
> During the normal plugin execution, this field is evaluated correctly.
> When running mvn assembly:assembly, the normal (forked) lifecycle also 
> functions correctly.
> But the assembly Mojo is configured with the original MavenProject, that 
> doesn't have the ${timestamp} property,
> so the  parameter on the assembly mojo will be "someArtifact-null".
> A tough problem, but it goes further: Ideally you never want to use 
> ${project} as a parameter, but
> the objects fields directly. Say you want to use the source roots and define 
> that as a parameter. Then you
> never get access the generated-sources unless you manually examine the 
> executedProject.
> Right now, mojo's have to use different logic depending on whether they 
> specify @execute phase="X",
> (and examine fields of the executedProject).
> Can we drop the original MavenProject object and replace that with 
> executedProject instance, so we only have
> 1 instance of MavenProject? 
> Or, if there are plugins that MUST use the original MavenProject, or use both 
> MavenProject instances (we might
> want to scan all existing mojo's to see what they do), can we add
> a plugin flag that specifies that that mojo must be configured using the 
> executedProject instead?

-- 
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-3006) Maven does not always download artifacts from specified repos

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-3006:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.1.x
  Component/s: Artifacts and Repositories

> Maven does not always download artifacts from specified repos
> -
>
> Key: MNG-3006
> URL: http://jira.codehaus.org/browse/MNG-3006
> Project: Maven 2
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.0.6
> Environment: Windows XP SP2
>Reporter: David Hoffer
> Fix For: 2.1.x
>
> Attachments: settings.xml
>
>
> Performing maven2 builds does not always downloaded requested artifacts from 
> specified repos before complaining that the required artifact is not 
> available and giving up.  However if I delete my local repo then it always 
> works.
> Here is the failure log:
> [12:42:04]: Couldn't find a version in [1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 
> 1.7, 1.8, 1.9, 1.10, 1.9-SNAPSHOT, 1.11-SNAPSHOT] to match range [1.11,)
> [12:42:04]: com.xrite.retail:retail-commons-classic:jar:null
> [12:42:04]:
> [12:42:04]: from the specified remote repositories:
> [12:42:04]: central (http://xrbuild3:8081/artifactory/repo),
> [12:42:04]: snapshots (http://xrbuild3:8082/artifactory/repo)
> An HTTP port monitor shows that maven refuses to contact the servers until I 
> delete my local repo.  Maven should always check the remote server before 
> giving up.
> I will attach my settings.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] Commented: (MNG-2839) Non-unique-version snapshots not updated

[Brett Porter (JIRA)]

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

Brett Porter commented on MNG-2839:
---

please provide the sample project you refer to so we can be sure we are talking 
about the same thing. MNG-1908 was certainly fixed according to the tests cases 
given.

> Non-unique-version snapshots not updated
> 
>
> Key: MNG-2839
> URL: http://jira.codehaus.org/browse/MNG-2839
> Project: Maven 2
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.0.5
>Reporter: Pavel Halas
>Assignee: Brett Porter
> Fix For: 2.0.x
>
>
> Test case:
> - let's have a repository with[uniqueVersion]false[/uniqueVersion].
> - let your project download any snapshot dependency (with non-unique version) 
> (like abc-1.0-SNAPSHOT.jar).
> - go to your local repository and change the file content. You can also 
> remove all the metadata.
> - run "mvn -U" on your project
> - you get "[INFO] snapshot abc:abc-1.0-SNAPSHOT: checking for updates from 
> YOUR-REPOSITORY"
> - the abc-1.0-SNAPSHOT.jar in your local repository is NOT updated.
> The same (I think) bug has been reported (and closed) several times before 
> (MNG-1908 etc.) but it still appears in 2.0.5.

-- 
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-2618) pom.xml with amperstands and variables

[Brett Porter (JIRA)]

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

Brett Porter closed MNG-2618.
-

   Resolution: Duplicate
Fix Version/s: (was: Reviewed Pending Version Assignment)

> pom.xml with amperstands and variables
> --
>
> Key: MNG-2618
> URL: http://jira.codehaus.org/browse/MNG-2618
> Project: Maven 2
>  Issue Type: Bug
>Affects Versions: 2.0.4
>Reporter: Łukasz Dywicki
>
> I've got an exception with structure:
> 
>   
>   Autoguard & Insurance Sp. z o.o
>   
> the ${project.organization.name} makes an exception.

-- 
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-2637) Logs improvment when using sub-projects

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2637:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.1.x
  Component/s: Logging
   Dependencies

> Logs improvment when using sub-projects
> ---
>
> Key: MNG-2637
> URL: http://jira.codehaus.org/browse/MNG-2637
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Dependencies, Logging
>Reporter: Emmanuel Lécharny
>Priority: Critical
> Fix For: 2.1.x
>
> Attachments: maven-stack.txt
>
>
> When compiling a hierarchy of projects, and if something went wrong, like a 
> missing plugin, there is absolutly now way to know, without grep through many 
> pom.xml, which pom.xml is incorrect. 
> It would be much more than cool to have a simple line like :
> [INFO] Getting plugins needed by project /
> or
> [INFO] Getting dependency  from repo  
> for project 
> instead of a flood of line which makes no sense for the mere mortal  ;) 

-- 
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-2839) Non-unique-version snapshots not updated

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2839:
--

 Assignee: Brett Porter
Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.0.x
  Component/s: Artifacts and Repositories

> Non-unique-version snapshots not updated
> 
>
> Key: MNG-2839
> URL: http://jira.codehaus.org/browse/MNG-2839
> Project: Maven 2
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.0.5
>Reporter: Pavel Halas
>Assignee: Brett Porter
> Fix For: 2.0.x
>
>
> Test case:
> - let's have a repository with[uniqueVersion]false[/uniqueVersion].
> - let your project download any snapshot dependency (with non-unique version) 
> (like abc-1.0-SNAPSHOT.jar).
> - go to your local repository and change the file content. You can also 
> remove all the metadata.
> - run "mvn -U" on your project
> - you get "[INFO] snapshot abc:abc-1.0-SNAPSHOT: checking for updates from 
> YOUR-REPOSITORY"
> - the abc-1.0-SNAPSHOT.jar in your local repository is NOT updated.
> The same (I think) bug has been reported (and closed) several times before 
> (MNG-1908 etc.) but it still appears in 2.0.5.

-- 
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-2377) maven-metadata not re-read after failure

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2377:
--

Component/s: Artifacts and Repositories

> maven-metadata not re-read after failure
> 
>
> Key: MNG-2377
> URL: http://jira.codehaus.org/browse/MNG-2377
> Project: Maven 2
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.0-alpha-1
>Reporter: Kenney Westerhof
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: 2.1-alpha-1
>
>
> A bug in deploy (not setting filePermissions correctly on deploy) caused the 
> maven-metadata...xml and the artifacts/poms
> to be unreadable.
> When building a project with a dep on a SNAPSHOT artifact on the faulty 
> remote repository, the maven-metadata can not be read.
> Maven creates a maven-metadata...xml with the following content (sample):
> {noformat}
> 
>   com.neonics.container
>   bundle-factory-maven
>   1.0-SNAPSHOT
> 
> {noformat}
> After fixing the permissions I restart the build, but the metadata file is 
> not re-read, resulting in Maven thinking
> 1.0-SNAPSHOT is the actual version and trying to get  
> ...artifact/1.0-SNAPSHOT/artifact-1.0-SNAPSHOT.pom
> which does not exist.
> Touching the files on the remote repo doesn't help either.
> Only when running with -U the metadata file is retrieved (another solution is 
> to purge files from
> the local repository).
> I think Maven should not create the metadata file if it can't be retrieved 
> AND if the non-timestamped
> SNAPSHOT version doesn't exist.
> I can see why the placeholder metadata files reduces future requests for this 
> file,
> but that's only useful if there _are_ future requests. There are indeed 
> repeated requests for the pom
> and artifact, even though they also don't exist. I think that only when the 
> artifact 1.0-SNAPSHOT exists
> and the metadata file doesn't, it's safe to put a placeholder metadata file 
> in the local repository.

-- 
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-2202) Improve pom to handle daylight saving changes

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2202:
--

Fix Version/s: (was: 2.2.x)
   2.1.x
  Component/s: POM

> Improve pom to handle daylight saving changes
> -
>
> Key: MNG-2202
> URL: http://jira.codehaus.org/browse/MNG-2202
> Project: Maven 2
>  Issue Type: Improvement
>  Components: POM
>Reporter: Andreas Guther
>Priority: Minor
> Fix For: 2.1.x
>
>
> It would be great if the timezone element in Maven 2 could be extendend in a 
> way that makes it able to determine  the offset own its own as well as to be 
> able to make adjustments to daylight savings.
> The following suggestion from the Maven Users mailing list seems to be an 
> interesting approach.  Note: In addition to the posting from Ian Stewart I 
> would like to add that I believe that the offset element is not needed in 
> case the timezone has a name and the dayligh savings element.
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, April 04, 2006 6:36 AM
> To: Maven Users List
> Subject: Re: TimeZone Element in pom.xml
> Note that the observation of Summertime/Daylight Savings Time does not
> change the timezone where a developer resides.
> Instead of changing everybody's timezone twice a year, I would recommend
> making the timezone element its own complex type, more inline with the
> java.util.TimeZone class:
> 
>   Eastern
>   -5
>   true
> 
> It's better to be hated for who you are
> than loved for who you are not
> Ian D. Stewart
> Appl Dev Analyst-Advisory, DCS Automation
> JPMorganChase Global Technology Infrastructure
> Phone: (614) 244-2564
> Pager: (888) 260-0078
>   
>  
>   "Andreas Guther"
>  
>   <[EMAIL PROTECTED]To:   "Maven Users List" 
> <[EMAIL PROTECTED]>   
>   ttools.com>  cc:
>  
>Subject:  TimeZone Element 
> in pom.xml   
>   04/04/2006 12:43 AM 
>  
>   Please respond to   
>  
>   "Maven Users List"  
>  
>   
>  
> Hi,
> Is there a way in Maven to adjust the TimeZone element in the pom.xml to
> daylight savings time?
> We have an international team and I like the fact that we can see on the
> maven generated web site's team list what time it is for a specific
> developer.  What I am missing is the automatic adjustment for example for
> my time zone which is in winter times -8 and in summer times -7.  I just
> made a global search and replace in my pom.xml but actually it would be
> more convenient maven could do that for me.
> Is there anything that helps me solving the problem or is this worth an
> enhancement request?
> Andreas

-- 
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-2715) Maven does not comply to XML rules regarding prefixes.

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2715:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.1.x
  Component/s: POM

> Maven does not comply to XML rules regarding prefixes.
> --
>
> Key: MNG-2715
> URL: http://jira.codehaus.org/browse/MNG-2715
> Project: Maven 2
>  Issue Type: Bug
>  Components: POM
> Environment: Ubuntu 6.10
> Maven 2.0.4
>Reporter: Seva Safris
>Priority: Critical
> Fix For: 2.1.x
>
>
> I am new to Maven and have been trying to learn how to create a simple 
> project.
> Let me walk through my scenario of creating a pom.xml file:
> 1. I bind the {http://maven.apache.org/POM/4.0.0} namespace (defined at 
> "http://maven.apache.org/maven-v4_0_0.xsd";) to Java classes using an XML 
> Binding solution.
> 2. I use the bound classes to create a simple  as one would expect 
> to see in a pom.xml file.
> 3. I marshal the bound Java objects into xml and write it into pom.xml. Here 
> is the xml I use:
>xmlns:ns1="http://maven.apache.org/POM/4.0.0";>
>   4.0.0
>   com.myapp
>   sample-project
>   Sample Maven Project
>   1.0
>   
>   
>   ssafris
>   Seva Safris
>   
>   
>   
>   ${basedir}/src/java
>   
> 
> 4. I run mvn, and am promptly given a "Not a v4.0.0 POM." exception.
> Tracing through Maven's source, I went to the exact location of the exception 
> in DefaultMavenProjectBuilder.java. On line 1297 it has:
> if ( modelSource.indexOf( "4.0.0" ) < 0 )
> {
> throw new InvalidProjectModelException( projectId, pomLocation, "Not a 
> v4.0.0 POM." );
> }
> Since modelSource is checked explicitly for  
> xml as shown above will fail this test because it has:  This is most definitely a bug in Maven and should be fixed as soon as 
> possible. The workaround is to use a 
> xmlns="http://maven.apache.org/POM/4.0.0"; and define all elements without a 
> prefix. However, my use of xmlns:ns1="http://maven.apache.org/POM/4.0.0"; 
> should not break Maven as it is not merely legal by xml conventions, but is 
> also a better practice for xml documents.
> I hope you see the importance of getting this bug fixed: My use of a XML 
> Binding solution to bind Maven's xml to Java allows me a strongly-typed level 
> of indirection that will deterministically create proper xml that will 
> validate successfully. If this bug is not fixed, then this level of 
> indirection is not possible (or very very very difficult because the XML 
> Binding solution would have to be hacked to use the xmlns="[...]" 
> convention). I have only found this one instance of where the bug is obvious, 
> but perhaps there are more locations in Maven where the same kind of error 
> can occur.
> Thank you for your time, and I hope you consider this issue as seriously as I 
> do.
> Sincerely,
> Seva Safris

-- 
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-2903) Snapshots are being packaged with datestamps in their filename instead of "SNAPSHOT",

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2903:
--

Fix Version/s: (was: Reviewed Pending Version Assignment)
   2.1.x
  Component/s: Artifacts and Repositories

> Snapshots are being packaged with datestamps in their filename instead of 
> "SNAPSHOT", 
> --
>
> Key: MNG-2903
> URL: http://jira.codehaus.org/browse/MNG-2903
> Project: Maven 2
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.0.5
>Reporter: Tim Cederman
>Priority: Critical
> Fix For: 2.1.x
>
>
> When I run mvn package on a project, it collects all the correct and most 
> recent
> jar files for me in the lib directory, however in the zip file instead
> of naming them -3.0-SNAPSHOT.jar (for example) it will name
> them -20070318.080720-37.jar.  
> Meanwhile in the project's own jar file, the manifest will point to
> ./lib/-3.0-SNAPSHOT.jar.  This means the packaged project does
> not run.
> It doesn't do this for every single dependency snapshot, and I can't
> seem to work out a pattern as to which get named correctly and which
> don't.
> I have two repositories in my pom file:
> 
>   
>   common-repository
>Common Repository
>   http://repository/common-repository
>   
>   
>   snapshot-repository
>   Trovix Snapshot Repository
>   http://repository/snapshots
>   
>   true
>   always
>   
>   
> 
> If I try to disable them manually (and use only the local repository),
> the problem persists.  However, this is where it gets weird.  If I
> unplug my network cable - my package file is created perfectly!
> However - if I unplug my network cable with the snapshot repository
> removed, it creates the package incorrectly once again!
> This seems to be the key part of what is making it work (blacklisting
> the snapshot-repository):
> [INFO]task-segment: [package]
> [INFO]
> -
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] snapshot com:com.benchmark:3.0-SNAPSHOT: checking for updates
> from snapshot-repository
> [WARNING] repository metadata for: 'snapshot
> com:com.benchmark:3.0-SNAPSHOT' could not be retrieved from repository:
>  snapshot-repository due to an error: Error transferring file
> [INFO] Repository 'snapshot-repository' will be blacklisted
> [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] No sources to compile
> [INFO] [surefire:test]
> [INFO] No tests to run.
> [INFO] [jar:jar]
> I have also run mvn -X package, and the debug log shows that it thinks
> it is collecting all the correct SNAPSHOT named jars, even though it
> then stores the date-stamped ones.

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