date:20060803

Id in POM is deprecated.


 Key: MPPOM-6
 URL: http://jira.codehaus.org/browse/MPPOM-6
 Project: maven-pom-plugin
  Issue Type: Bug
Affects Versions: 1.5
Reporter: Arnaud Heritier
Priority: Critical
 Fix For: 1.5.1


The pom:validate goal uses a schema which is false. The id element is 
deprecated and replaced by groupId/artifactId.

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

[jira] Created: (MAVEN-1769) Upgrade plugins

Upgrade plugins
---

 Key: MAVEN-1769
 URL: http://jira.codehaus.org/browse/MAVEN-1769
 Project: Maven
  Issue Type: Task
  Components: planning
Affects Versions: 1.1-beta-3
Reporter: Arnaud Heritier
 Fix For: 1.1-rc1


Upgrade maven-pom-plugin to v 1.5.1
Upgrade maven-xdoc-plugin to v 1.11.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] Created: (MAVEN-1770) Upgrade maven-pom-plugin to v 1.5.1

Upgrade maven-pom-plugin to v 1.5.1
---

 Key: MAVEN-1770
 URL: http://jira.codehaus.org/browse/MAVEN-1770
 Project: Maven
  Issue Type: Sub-task
  Components: planning
Affects Versions: 1.1-beta-3
Reporter: Arnaud Heritier
 Fix For: 1.1-rc1




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

[jira] Created: (MAVEN-1771) Upgrade maven-xdoc-plugin to v 1.11.1

Upgrade maven-xdoc-plugin to v 1.11.1
-

 Key: MAVEN-1771
 URL: http://jira.codehaus.org/browse/MAVEN-1771
 Project: Maven
  Issue Type: Sub-task
  Components: planning
Affects Versions: 1.1-beta-3
Reporter: Arnaud Heritier
 Fix For: 1.1-rc1




-- 
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: (MAVEN-1769) Upgrade plugins

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

Arnaud Heritier updated MAVEN-1769:
---

Description: 
These upgrades are needed to solve different problems encoutered in the beta 3.
Only minor releases a accepted here.
Plugins updates are only bug fixes (perhaps dependencies upgrades). 
No new features must be added to ensure us to keep the stability.


  was:
Upgrade maven-pom-plugin to v 1.5.1
Upgrade maven-xdoc-plugin to v 1.11.1



> Upgrade plugins
> ---
>
> Key: MAVEN-1769
> URL: http://jira.codehaus.org/browse/MAVEN-1769
> Project: Maven
>  Issue Type: Task
>  Components: planning
>Affects Versions: 1.1-beta-3
>Reporter: Arnaud Heritier
> Fix For: 1.1-rc1
>
>
> These upgrades are needed to solve different problems encoutered in the beta 
> 3.
> Only minor releases a accepted here.
> Plugins updates are only bug fixes (perhaps dependencies upgrades). 
> No new features must be added to ensure us to keep the stability.

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

[jira] Created: (MAVEN-1772) Upgrade maven-war-plugin to v 1.6.3

Upgrade maven-war-plugin to v 1.6.3
---

 Key: MAVEN-1772
 URL: http://jira.codehaus.org/browse/MAVEN-1772
 Project: Maven
  Issue Type: Sub-task
  Components: planning
Affects Versions: 1.1-beta-3
Reporter: Arnaud Heritier
 Fix For: 1.1-rc1




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

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

Arnaud Heritier updated MPDIST-29:
--

Fix Version/s: 1.7.1

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

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

[jira] Created: (MAVEN-1773) Upgrade maven-dist-plugin to v 1.7.1

Upgrade maven-dist-plugin to v 1.7.1


 Key: MAVEN-1773
 URL: http://jira.codehaus.org/browse/MAVEN-1773
 Project: Maven
  Issue Type: Sub-task
Reporter: Arnaud Heritier




-- 
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: (MAVEN-1771) Upgrade maven-xdoc-plugin to v 1.11.1

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

Arnaud Heritier updated MAVEN-1771:
---

Description: 
http://jira.codehaus.org/browse/MPXDOC?report=com.atlassian.jira.plugin.system.project:roadmap-panel

> Upgrade maven-xdoc-plugin to v 1.11.1
> -
>
> Key: MAVEN-1771
> URL: http://jira.codehaus.org/browse/MAVEN-1771
> Project: Maven
>  Issue Type: Sub-task
>  Components: planning
>Affects Versions: 1.1-beta-3
>Reporter: Arnaud Heritier
> Fix For: 1.1-rc1
>
>
> http://jira.codehaus.org/browse/MPXDOC?report=com.atlassian.jira.plugin.system.project:roadmap-panel

-- 
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: (MAVEN-1770) Upgrade maven-pom-plugin to v 1.5.1

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

Arnaud Heritier updated MAVEN-1770:
---

Description: 
http://jira.codehaus.org/browse/MPPOM?report=com.atlassian.jira.plugin.system.project:roadmap-panel

> Upgrade maven-pom-plugin to v 1.5.1
> ---
>
> Key: MAVEN-1770
> URL: http://jira.codehaus.org/browse/MAVEN-1770
> Project: Maven
>  Issue Type: Sub-task
>  Components: planning
>Affects Versions: 1.1-beta-3
>Reporter: Arnaud Heritier
> Fix For: 1.1-rc1
>
>
> http://jira.codehaus.org/browse/MPPOM?report=com.atlassian.jira.plugin.system.project:roadmap-panel

-- 
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: (MAVEN-1772) Upgrade maven-war-plugin to v 1.6.3

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

Arnaud Heritier updated MAVEN-1772:
---

Description: 
http://jira.codehaus.org/browse/MPWAR?report=com.atlassian.jira.plugin.system.project:roadmap-panel

> Upgrade maven-war-plugin to v 1.6.3
> ---
>
> Key: MAVEN-1772
> URL: http://jira.codehaus.org/browse/MAVEN-1772
> Project: Maven
>  Issue Type: Sub-task
>  Components: planning
>Affects Versions: 1.1-beta-3
>Reporter: Arnaud Heritier
> Fix For: 1.1-rc1
>
>
> http://jira.codehaus.org/browse/MPWAR?report=com.atlassian.jira.plugin.system.project:roadmap-panel

-- 
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: (MAVEN-1773) Upgrade maven-dist-plugin to v 1.7.1

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

Arnaud Heritier updated MAVEN-1773:
---

  Description: 
http://jira.codehaus.org/browse/MPDIST?report=com.atlassian.jira.plugin.system.project:roadmap-panel
Affects Version/s: 1.1-beta-3
Fix Version/s: 1.1-rc1
  Component/s: planning

> Upgrade maven-dist-plugin to v 1.7.1
> 
>
> Key: MAVEN-1773
> URL: http://jira.codehaus.org/browse/MAVEN-1773
> Project: Maven
>  Issue Type: Sub-task
>  Components: planning
>Affects Versions: 1.1-beta-3
>Reporter: Arnaud Heritier
> Fix For: 1.1-rc1
>
>
> http://jira.codehaus.org/browse/MPDIST?report=com.atlassian.jira.plugin.system.project:roadmap-panel

-- 
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: (MAVEN-1769) Upgrade plugins

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

Arnaud Heritier updated MAVEN-1769:
---

Description: 
These upgrades are needed to solve different problems encoutered in the beta 3.
Only minor releases (bug fixes and perhaps dependencies upgrades) are accepted 
here.
No new features must be added to ensure us to keep the stability.


  was:
These upgrades are needed to solve different problems encoutered in the beta 3.
Only minor releases a accepted here.
Plugins updates are only bug fixes (perhaps dependencies upgrades). 
No new features must be added to ensure us to keep the stability.



> Upgrade plugins
> ---
>
> Key: MAVEN-1769
> URL: http://jira.codehaus.org/browse/MAVEN-1769
> Project: Maven
>  Issue Type: Task
>  Components: planning
>Affects Versions: 1.1-beta-3
>Reporter: Arnaud Heritier
> Fix For: 1.1-rc1
>
>
> These upgrades are needed to solve different problems encoutered in the beta 
> 3.
> Only minor releases (bug fixes and perhaps dependencies upgrades) are 
> accepted here.
> No new features must be added to ensure us to keep the stability.

-- 
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: (MAVEN-1771) Upgrade maven-xdoc-plugin to v 1.10.1

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

Arnaud Heritier updated MAVEN-1771:
---

Summary: Upgrade maven-xdoc-plugin to v 1.10.1  (was: Upgrade 
maven-xdoc-plugin to v 1.11.1)

> Upgrade maven-xdoc-plugin to v 1.10.1
> -
>
> Key: MAVEN-1771
> URL: http://jira.codehaus.org/browse/MAVEN-1771
> Project: Maven
>  Issue Type: Sub-task
>  Components: planning
>Affects Versions: 1.1-beta-3
>Reporter: Arnaud Heritier
> Fix For: 1.1-rc1
>
>
> http://jira.codehaus.org/browse/MPXDOC?report=com.atlassian.jira.plugin.system.project:roadmap-panel

-- 
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: (MPXDOC-111) is transformed into

[ http://jira.codehaus.org/browse/MPXDOC-111?page=comments#action_71491 ] 

Arnaud Heritier commented on MPXDOC-111:


Isn't it fixed in the current plugin with the last upgrade of dom4J ? I'll 
check this...

>  is transformed into 
> ---
>
> Key: MPXDOC-111
> URL: http://jira.codehaus.org/browse/MPXDOC-111
> Project: maven-xdoc-plugin
>  Issue Type: Bug
>Reporter: Carlos Sanchez
>
> This causes two line breaks (at least in IE 6)
> For example (at 
> http://cvs.apache.org/viewcvs.cgi/maven-plugins/aspectj/xdocs/index.xml?rev=1.7&view=auto)
> 
>   
> To install or update the plugin do the following:
> maven plugin:download -DgroupId=maven 
> -DartifactId=maven-aspectj-plugin -Dversion=
>   
> 
> is transformed into (at http://maven.apache.org/reference/plugins/aspectj/)
> 
>   Installing
>   
> To install or update the plugin do the following:
> maven plugin:download -DgroupId=maven 
> -DartifactId=maven-aspectj-plugin -Dversion=
>   
> 

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

[jira] Updated: (MPXDOC-14) HTML encode the email addresses displayed on the html page pls

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

Arnaud Heritier updated MPXDOC-14:
--

Issue Type: Improvement  (was: Bug)

> HTML encode the email addresses displayed on the html page pls
> --
>
> Key: MPXDOC-14
> URL: http://jira.codehaus.org/browse/MPXDOC-14
> Project: maven-xdoc-plugin
>  Issue Type: Improvement
>
> to avoid having the email addresses being harvested by spammer ( for example 
> the team page ), please html encode them !!! see 
> http://www.ohlone.cc.ca.us/org/webcenter/emailencoding.html for a lenghtier 
> explaination on encoding the addresses

-- 
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: (MPWAR-45) [PATCH] war:inplace should check for maven.war.src

 [ http://jira.codehaus.org/browse/MPWAR-45?page=all ]

Arnaud Heritier updated MPWAR-45:
-

Fix Version/s: 1.6.3

It can be considered as a bug

> [PATCH] war:inplace should check for maven.war.src
> --
>
> Key: MPWAR-45
> URL: http://jira.codehaus.org/browse/MPWAR-45
> Project: maven-war-plugin
>  Issue Type: Improvement
>Affects Versions: 1.6
>Reporter: Kim Dykeman
>Priority: Minor
> Fix For: 1.6.3
>
> Attachments: maven-plugins-war-inplace.patch
>
>
> The war:inplace goal doesn't check to see if maven.war.src is present prior 
> to running war:webapp.  The result when used with the multiproject plugin is 
> several webapp directories being created in subprojects that don't build a 
> war 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: (MPWAR-36) tld folder is always created

 [ http://jira.codehaus.org/browse/MPWAR-36?page=all ]

Arnaud Heritier updated MPWAR-36:
-

Affects Version/s: 1.6.3
Fix Version/s: 1.6.3
   Issue Type: Bug  (was: Improvement)

Can be considered as a non-blocking bug

> tld folder is always created
> 
>
> Key: MPWAR-36
> URL: http://jira.codehaus.org/browse/MPWAR-36
> Project: maven-war-plugin
>  Issue Type: Bug
>Affects Versions: 1.7, 1.6.3
>Reporter: Alexey Adamov
>Priority: Trivial
> Fix For: 1.6.3
>
>
> maven-1.1-SNAPSHOT, maven-war-plugin-1.7-SNAPSHOT
> Problem: web application may not use tld and even jsp, so tld is not always 
> needed
> Now i need to set ${mave.war.tld.dir}=WEB-INF, it works, but it is an anal 
> solution.
> Proposal:
>   do not create ${mave.war.tld.dir} folder when no tld libs are defined   in 
> the dependencies (so no file need to be copied)
> --
> Great thanks in prior

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

[jira] Commented: (MNG-2471) Add search box to the index page

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

Denis Cabasson commented on MNG-2471:
-

After a bit of research, it seems we have to keep Google's logo:
http://www.google.com/searchcode.html

So I guess we can still go for the smaller logo:
http://www.google.com/logos/Logo_25wht.gif

I guess the last version, with google Logo aboce the search box would be fine 
for me (but now, I'm just a user, so my view is not that important :) )

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

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

[jira] Created: (MRELEASE-145) release:prepare requires all modules to be SNAPSHOTS

2006-08-03 Thread JIRA

release:prepare requires all modules to be SNAPSHOTS


 Key: MRELEASE-145
 URL: http://jira.codehaus.org/browse/MRELEASE-145
 Project: Maven 2.x Release Plugin
  Issue Type: Improvement
Reporter: Jörg Hohwiller
 Fix For: 2.0-beta-4


The biggest need for the maven-release-plugin is in complex projects with a lot 
of modules (that may again have modules). If I do not get it wrong, the current 
released version forces all modules to be snapshots and releases them 
individually. This is completely useless in my situation because in the end 
this forces me to release alle modules together for every change that is to be 
released and more or less causes that all modules have the same version number. 
When I call mvn replease:prepare on my toplevel project this is no snapshot, it 
fails with this error:
The project : isn't a snapshot ().

I would expect release:prepare to leave non SNAPSHOT modules untouched (and 
only verify that they do not have SNAPSHOT dependencies, what should never be 
the case if the version is no snapshot).
All reactor projects that have a "-SNAPHSOT" version should be released and 
theier project-internal dependencies should also be set to the acording 
released version (and later be set to the new SNAPSHOT).
Additionally I want to have the complete project to be tagged as a whole 
instead of each module. This could potentially be configureable (especially 
which directory is actually tagged, e.g. if the toplevel project is not in 
trunk/ but somewhere deeper say trunk/develop because other directories in 
trunk are huge but do not need to be checked out by every developer but need to 
be tagged).

I personally think that the best flexibility and final freedom would be to 
split off the release:prepare goal into 3 goals:
-create release version(s)
-create tag(s)
-update to snapshot version(s)

These goals could be used individually and one could add some custom steps or 
replace one with something else.

For creating the snapshot versions there is also the problem, that you do not 
know right away which project will be modified when in the future. The coolest 
thing would be if this would happen automatically when the first change is 
commited to the module. But this is of cause not praticable in reality (maybe 
if all commits would be done with maven).

-- 
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: (MNGECLIPSE-172) Eclipse PDE seems slightly incompatible with plugin

2006-08-03 Thread Yuri Schimke (JIRA)

Eclipse PDE seems slightly incompatible with plugin
---

 Key: MNGECLIPSE-172
 URL: http://jira.codehaus.org/browse/MNGECLIPSE-172
 Project: Maven 2.x Extension for Eclipse
  Issue Type: Improvement
Affects Versions: 0.0.9
Reporter: Yuri Schimke
 Assigned To: Eugene Kuleshov


Eclipse PDE Rich Clients seem to have trouble when using the maven plugin.

To actually build the client application it seems to need the dependency jars 
within the project.  To get around this we use the dependency:copy-dependencies 
task.  However this setup stops debugging from working. It also means you need 
to run mvn install for the other projects each time before you copy the 
dependencies.

In constrast, after applying the patch from MNGECLIPSE-59, non-PDE projects 
work brilliantly.

I'm reporting this improvement for a number of reasons 1) in case others are 
facing the same problem, 2) in case other have solved the same problem already 
and 3) in case it might be something you guys can fix easily.

You guys might be the best candidates to answer 2) since you presumably use 
Eclipse to edit the maven2 plugin anyway.

Another option might be to make each maven JAR a valid OSGI plugin, which is 
mainly a couple of extra files in the JAR.  This could potentially be done with 
a MOJO that added the default, most liberal OSGI settings into the JAR.  But 
this seems a bit extreme, and also inflexible in the case of truly internal 
dependencies.

-- 
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: (MAVEN-1636) cryptic error message

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

Arnaud Heritier updated MAVEN-1636:
---

Fix Version/s: 1.1-rc1

We'll try to create the directory before to extract the plugin. If we can't 
we'll throw a message about it.

> cryptic error message
> -
>
> Key: MAVEN-1636
> URL: http://jira.codehaus.org/browse/MAVEN-1636
> Project: Maven
>  Issue Type: Bug
>  Components: plugin manager
>Affects Versions: 1.1-beta-1
> Environment: Windows XP, network profile
>Reporter: Jan Haderka
>Priority: Trivial
> Fix For: 1.1-rc1
>
>
> Using nework profile with top level directory of the profile without 
> privilege to create new directoriew, makes maven to fail on first startup 
> with a bit cryptic message: 
> org.apache.maven.MavenException: Unable to extract plugin: C:\Maven 
> 1.1-beta-1\plugins\maven-nsis-plugin-1.1.jar
> at 
> org.apache.maven.plugin.PluginManager.unpackPlugin(PluginManager.java:1097)
> ...
> --- Nested Exception ---
> java.io.FileNotFoundException: 
> \\server\username$\.maven\cache\maven-nsis-plugin-1.1\META-INF\MANIFEST.MF 
> (The system cannot find the path specified)
> at java.io.FileOutputStream.open(Native Method)
> at java.io.FileOutputStream.(FileOutputStream.java:179)
> at java.io.FileOutputStream.(FileOutputStream.java:131)
> at org.apache.maven.util.Expand.extractFile(Expand.java:147)
> at org.apache.maven.util.Expand.expandFile(Expand.java:85)
> at org.apache.maven.util.Expand.execute(Expand.java:67)
> at 
> org.apache.maven.plugin.PluginManager.unpackPlugin(PluginManager.java:1093)
> ...
> The reason for failure is not that plugin is corrupted but that .maven 
> directory can't be created.
> Work around is to set MAVEN_HOME_LOCAL to point somewhere in the user space.

-- 
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: (MAVEN-1660) DependencyVerifier class doesn't resolve an snapshot artifact after attaining a first goal.

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

Arnaud Heritier updated MAVEN-1660:
---


I'll have a look at it for the RC1

> DependencyVerifier class doesn't resolve an snapshot artifact after attaining 
> a first goal.
> ---
>
> Key: MAVEN-1660
> URL: http://jira.codehaus.org/browse/MAVEN-1660
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.1-beta-1
>Reporter: Pascal Larin
>Priority: Minor
>
> Since revision 179556 of 
> src/java/org/apache/maven/verifier/DependencyVerifier.java, the 
> satisfyDependencies() method check if an artifact has already been resolved. 
> It changes the behavior from version 1.0.
> For example, if you call maven with goals multiproject:clean and 
> multiproject:deploy with artifact versions set to snaphot, maven doesn't 
> resolve the dependencies for the multiproject:deploy because it has been 
> already done for the multiproject:clean.
> I know that a multiproject:clean should not resolve the project dependencies 
> but it can probably cause problems in other cases. 

-- 
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: (MAVEN-1660) DependencyVerifier class doesn't resolve an snapshot artifact after attaining a first goal.

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

Arnaud Heritier updated MAVEN-1660:
---

Fix Version/s: 1.1-rc1

> DependencyVerifier class doesn't resolve an snapshot artifact after attaining 
> a first goal.
> ---
>
> Key: MAVEN-1660
> URL: http://jira.codehaus.org/browse/MAVEN-1660
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.1-beta-1
>Reporter: Pascal Larin
>Priority: Minor
> Fix For: 1.1-rc1
>
>
> Since revision 179556 of 
> src/java/org/apache/maven/verifier/DependencyVerifier.java, the 
> satisfyDependencies() method check if an artifact has already been resolved. 
> It changes the behavior from version 1.0.
> For example, if you call maven with goals multiproject:clean and 
> multiproject:deploy with artifact versions set to snaphot, maven doesn't 
> resolve the dependencies for the multiproject:deploy because it has been 
> already done for the multiproject:clean.
> I know that a multiproject:clean should not resolve the project dependencies 
> but it can probably cause problems in other cases. 

-- 
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: (MAVEN-1440) Clearing maven.repo.remote results in incorrect reporting of unsatisfied dependencies

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

Arnaud Heritier updated MAVEN-1440:
---

Fix Version/s: 1.1-rc1

I don't want to put the build offline if maven.repo.remote isn't defined. It's 
not logical.
I prefer to fail the build if maven.repo.remote is empty and the build is 
online.


> Clearing maven.repo.remote results in incorrect reporting of unsatisfied 
> dependencies
> -
>
> Key: MAVEN-1440
> URL: http://jira.codehaus.org/browse/MAVEN-1440
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 1.0
> Environment: Solaris
>Reporter: Cameron Horn
>Priority: Minor
> Fix For: 1.1-rc1
>
>
> Running "maven -Dmaven.repo.remote= -Dmaven.mode.online=false"
> 
> The use of the remote repository has been disabled. (x10)
> BUILD FAILED
> File.. 
> /export/home/cruise/.maven/cache/maven-multiproject-plugin-1.3.1/plugin.jelly
> Element... maven:reactor
> Line.. 217
> Column 9
> The build cannot continue because of the following unsatisfied dependency:
> kernel-core-SNAPSHOT.jar
> 
> Which is misleading. kernel-core-SNAPSHOT.jar failed to build because it was 
> missing dependencies.  Running "maven -o -Dmaven.repo.remote= 
> multiproject:install-snapshot" shows the correct dependencies:
> 
> The use of the remote repository has been disabled. (x10)
> You are working offline so the build will continue, but 
> kernel-core-SNAPSHOT.jar may be out of date!
> You are working offline so the build will continue, but 
> kernel-container-SNAPSHOT.jar may be out of date!
> BUILD FAILED
> File.. 
> /export/home/cruise/.maven/cache/maven-multiproject-plugin-1.3.1/plugin.jelly
> Element... maven:reactor
> Line.. 217
> Column 9
> The build cannot continue because of the following unsatisfied dependencies:
> commons-beanutils-1.6.1.jar
> commons-digester-1.4.1.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: (MAVEN-1677) "No directory specified for fileset" when debugging for org.apache.commons.jelly.tags.ant.AntTag on

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

Arnaud Heritier updated MAVEN-1677:
---

Fix Version/s: 1.1-rc1

To be checked for the RC1

> "No directory specified for fileset" when debugging for 
> org.apache.commons.jelly.tags.ant.AntTag on
> ---
>
> Key: MAVEN-1677
> URL: http://jira.codehaus.org/browse/MAVEN-1677
> Project: Maven
>  Issue Type: Bug
>  Components: jelly/ant integration
>Affects Versions: 1.1-beta-1
> Environment: OS X 10.4.2, java version "1.5.0_02"
>Reporter: Scott Lamb
>Priority: Minor
> Fix For: 1.1-rc1
>
>
> I've been trying to debug problems by specifying an alternate 
> log4j.configuration:
> $ MAVEN_OPTS="-Dlog4j.configuration=file:$HOME/log4j.properties" maven
> In the process, I discovered that when the level for 
> org.apache.commons.jelly.tags.ant.AntTag is set to DEBUG, maven yields this 
> error:
> File.. ${1}
> Element... ant:fileset
> Line.. 49
> Column 45
> No directory specified for fileset.
> When logging for that class is at INFO level, this error does not occur.
> This happens on the "java:compile" goal of even the simplest project. I can 
> attach full exception info, the project I used, and the log4j config file I 
> used if desired.
> I'd like to figure out what jelly file this occurred in. The file "${1}" is 
> not too helpful, though.

-- 
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: (MAVEN-1704) artifactId is used as groupId when the latest is not defined

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

Arnaud Heritier updated MAVEN-1704:
---

Fix Version/s: 1.1-rc1

To be check

> artifactId is used as groupId when the latest is not defined
> 
>
> Key: MAVEN-1704
> URL: http://jira.codehaus.org/browse/MAVEN-1704
> Project: Maven
>  Issue Type: Bug
>  Components: inheritance
>Affects Versions: 1.1-beta-2
>Reporter: Carlos Sanchez
> Fix For: 1.1-rc1
>
>
> artifactId is used as groupId when the latest is not defined (using extends 
> at least), both in 1.0.2 and 1.1b2, which I believe it's a problem, maven 
> should complain.
> Which is really a problem is that if pom a extends pom b, and no groupId is 
> defined in any of both, in 1.0.2 the artifactId of a is chosen as groupId, 
> while in 1.1 artifactId of b is the chosen one.

-- 
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: (MAVEN-1688) The ${pom.versions} List behaves differently when running plugins under maven 1.1 and maven 1.0

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

Arnaud Heritier updated MAVEN-1688:
---

Fix Version/s: 1.1-rc1

By default if id isn't set, wa can returns the name (with a warning message)

> The ${pom.versions} List behaves differently when running plugins under maven 
> 1.1 and maven 1.0
> ---
>
> Key: MAVEN-1688
> URL: http://jira.codehaus.org/browse/MAVEN-1688
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.1-beta-2
>Reporter: Henning Schmiedehausen
> Fix For: 1.1-rc1
>
>
> Consider the following POM snipped:
> 
> 
>   2.1
>   TURBINE_2_1
> 
> 
>   2.2
>   TURBINE_2_2_0
> 
> 
>   2.3-rc1
>   TURBINE_2_3_RC1
> 
> 
>   2.3-rc2
>   TURBINE_2_3_RC2
> 
> 
>   2.3
>   TURBINE_2_3
> 
> 
>   2.3.1-RC1
>   TURBINE_2_3_1_RC1
> 
> 
>   2.3.1-RC2
>   TURBINE_2_3_1_RC2
> 
> 
>   2.3.1
>   TURBINE_2_3_1
>   2.3.1
> 
> 
>   2.3.2-RC1
>   TURBINE_2_3_2_RC1
> 
>   
> echoing ${pom.versions} under the 1.0.2 maven release issues the following 
> output:
> [echo] [2.1, 2.2, 2.3-rc1, 2.3-rc2, 2.3, 2.3.1-RC1, 2.3.1-RC2, 2.3.1, 
> 2.3.2-RC1]
> doing the same thing under the 1.1-beta 2 core results in
> [echo] [null, null, null, null, null, null, null, 2.3.1, null]
> It seems that 1.0 uses the name as key and 1.1 uses the id. This causes e.g. 
> the clirr plugin to fail if a project
> defines names for a version entry but no id.
> If it is necessary that a version entry contains name and/or id, it should be 
> enforced by the maven core and bad
> entries should be reported.

-- 
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: (MAVEN-410) maven plugins seem to choke on properties containing a "-"?

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

Arnaud Heritier updated MAVEN-410:
--

Fix Version/s: 1.1-rc1

I agree to add a documentation about it. If it's not supported by Jelly, we 
won't fix it.

> maven plugins seem to choke on properties containing a "-"?
> ---
>
> Key: MAVEN-410
> URL: http://jira.codehaus.org/browse/MAVEN-410
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.0-beta-9
> Environment: RedHat Linux 7.3, JDK 1.3.1
>Reporter: Henning Schmiedehausen
> Fix For: 1.1-rc1
>
>
> I'm using the Torque plugin to create id-table init sql files from my
> XML schemas. If I download maven 1.0b9 from apache.org, install it and
> then issue
> % maven -X torque
> I get
> torque:id-table-init-sql:
> Using contextProperties file: 
> /mnt/home.net/henning/cvs/turbine-2/project.properties
> [torque-sql] [VERBOSE] Using templatePath: 
> /mnt/home.net/henning/cvs/turbine-2/src/torqueTemplates
> [torque-sql] Using classpath
> [torque-sql] Generating to file 
> /mnt/home.net/henning/cvs/turbine-2/target/sql/report.idtable-init.sql.generation
> [torque-sql] [DEBUG] fileset: Setup scanner in dir 
> /mnt/home.net/henning/cvs/turbine-2/target with patternSet{ includes: [0] 
> excludes: [0] }
> BUILD SUCCESSFUL
> Total time:  7 seconds
> Note the [0] for include and exclude list in the file scanner.
> If I now load the plugin.properties and plugin.jelly file from
> Torque and replace in both files for the properties
> torque.schema.init-sql.includes
> torque.schema.init-sql.excludes
> the "init-sql" part with "initsql"
> and re-issue the command:
> % maven -X torque
> then I get
> torque:id-table-init-sql:
> Using contextProperties file: 
> /mnt/home.net/henning/cvs/turbine-2/project.properties
> [torque-sql] [VERBOSE] Using templatePath: 
> /mnt/home.net/henning/cvs/turbine-2/src/torqueTemplates
> [torque-sql] Using classpath
> [torque-sql] Generating to file 
> /mnt/home.net/henning/cvs/turbine-2/target/sql/report.idtable-init.sql.generation
> [torque-sql] [DEBUG] fileset: Setup scanner in dir 
> /mnt/home.net/henning/cvs/turbine-2/target with patternSet{ includes: 
> [*-schema.xml] excludes: [id-table-schema.xml] }
> Parsing file: 'scheduler-schema.xml'
> log4j:WARN No appenders could be found for logger 
> (org.apache.torque.engine.database.transform.DTDResolver).
> log4j:WARN Please initialize the log4j system properly.
> Parsing file: 'torque-security-schema.xml'
> Parsing file: 'scheduler-idtable-schema.xml'
> Parsing file: 'torque-security-idtable-schema.xml'
> BUILD SUCCESSFUL
> Total time:  9 seconds
> Note that now the file scanner correctly picks up my schema files
> and builds the sql init 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: (MAVEN-1659) Dependency jars are not downloading from remote repository placed in Subversion with http access

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

Arnaud Heritier updated MAVEN-1659:
---

Fix Version/s: 1.1-rc1

If nobody can reproduce it before the end of the month, we'll close it.


> Dependency jars are not downloading from remote repository placed in 
> Subversion with http access
> 
>
> Key: MAVEN-1659
> URL: http://jira.codehaus.org/browse/MAVEN-1659
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 1.1-beta-1
> Environment: Server: Apache 1.3.x with Subversion 1.1.1
> Client: Linux 2.6/Windows 2000, J2SE 5.0
>Reporter: Roman Krutyakov
> Fix For: 1.1-rc1
>
>
> Dependencies are not downloading from remote repository if it's placed in 
> Subversion with http access (with apache and mod_davsvn)
> In verbose mode maven logs (under linux):
> ---
> Getting failed dependencies: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL 
> PROTECTED]
> Attempting to download slamd_client-1.8.1.jar.
> http://server.net:81/svn/v2/trunk/target/maven//slamd/jars/slamd_client-1.8.1.jar
>  - Status code: 200
> Local file is newer: not downloaded
> Attempting to download slamd_server-1.8.1.jar.
> http://server.net:81/svn/v2/trunk/target/maven//slamd/jars/slamd_server-1.8.1.jar
>  - Status code: 200
> Local file is newer: not downloaded
> 
> Artifact '/opt/maven-repository/slamd/jars/slamd_client-1.8.1.jar' not found 
> to add to classpath
> Artifact '/opt/maven-repository/slamd/jars/slamd_server-1.8.1.jar' not found 
> to add to classpath
> ---
> in local repository appropriate paths are created, but jar files are missing
> this was checked against repository server with basic auth and without 
> authentication - result is the same
> affected version 1.1-beta-1, 1.0.x works well

-- 
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: (MAVEN-1482) some genuine errors result in "fatal" errors

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

Arnaud Heritier updated MAVEN-1482:
---

Fix Version/s: 1.1-rc1

To be checked before the RC1

> some genuine errors result in "fatal" errors
> 
>
> Key: MAVEN-1482
> URL: http://jira.codehaus.org/browse/MAVEN-1482
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Reporter: Brett Porter
> Fix For: 1.1-rc1
>
>
> for example: extend a POM that doesn't exist.
> Need to gracefully catch such exceptions and handle differently.

-- 
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: (MAVEN-1656) Doco that explains the protocols required to allow maven.xml or any plugin.jelly to inject values into or retrieve values from another plugin

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

Arnaud Heritier updated MAVEN-1656:
---

Fix Version/s: 1.1-rc1

To be documented if it's not yet done

> Doco that explains the protocols required to allow maven.xml or any 
> plugin.jelly to inject values into or retrieve values from another plugin
> -
>
> Key: MAVEN-1656
> URL: http://jira.codehaus.org/browse/MAVEN-1656
> Project: Maven
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 1.1-beta-1
> Environment: All
>Reporter: Andy Glick
> Fix For: 1.1-rc1
>
>
> Brett recently posted a suggestion to someone who asked how to access the 
> contents of "plugin a" from the context of "plugin b" or from maven.xml. 
> Brett stated that "plugin a" would have to be initialized before it could be 
> accessed, and that from what I could understand he recommended 1 or 2 ways to 
> do that:
> 1) reference the artifact plugin's namespace in the project tag 
> 2) specify  value="some.value"/>  (I think that this is the proper syntax, but I'm not 
> sure :-).
> Thierry Lach, who asked the question this time around, reported that using 
> the artifact namespace didn't work in his instance, but that setting the 
> scope to parent did. I'm hoping that we can put together a fairly 
> comprehensive explanation about what is going on here, and if that means 
> explaining why the project gave up on Jelly and switched to M2, then so be it.
> See http://news.gmane.org/gmane.comp.jakarta.turbine.maven.user for the 
> postings
> Given that during the last couple of months Vincent Massol recommended that 
> people use the now deprecated  mechanism on the 
> mavenbook.org site (see Tip #2), I should think that there ought to be a 
> priority on documenting this issue in an obvious place, probably the FAQ, but 
> also on the Maven Jelly tags get and set entries. 
> If this is actually explicitly documented somewhere, I'm sorry to have wasted 
> anyone's time. I have seen several plugins that have successfully used the 
> artifact namespace tag, so there must be some way that people have learned 
> this. I simply wish that I knew how they had done so. ;-) 
> I'm willing to write the doco if someone would explain the details.

-- 
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: (MNGECLIPSE-173) doesn't execute the right profile

2006-08-03 Thread femke ongenae (JIRA)

doesn't execute the right profile
-

 Key: MNGECLIPSE-173
 URL: http://jira.codehaus.org/browse/MNGECLIPSE-173
 Project: Maven 2.x Extension for Eclipse
  Issue Type: Bug
  Components: Maven Launcher
Affects Versions: 0.0.9
 Environment: Windows Xp, Eclipse 3.2
Reporter: femke ongenae
 Assigned To: Eugene Kuleshov
Priority: Blocker
 Fix For: 0.0.9
 Attachments: pom.xml

When i do run -> maven2 build...
i get a screen.
In my pom i have to profiles :  1) a dev profile, that is active by default
  2) a test profile (in 
command promt activated by -Ptest)

but i can't get this maven integration for eclipse to run the test profile
i have tried to fill in anything at the parameters 

name  value

P   test
-P  test
ptest
-p test
active-profiles  test

if you could resolve this i would be very happy, cause it's very annoying that 
i can
only execute the default profile from eclipse.

i have included the 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] Commented: (MAVEN-1492) use whole id, not artifact ID, for identifying plugins

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

Arnaud Heritier commented on MAVEN-1492:


Must be checked but I'm not sure that we can do it easily for the RC1 without 
risking to create some problems...

> use whole id, not artifact ID, for identifying plugins
> --
>
> Key: MAVEN-1492
> URL: http://jira.codehaus.org/browse/MAVEN-1492
> Project: Maven
>  Issue Type: Bug
>  Components: plugin manager
>Affects Versions: 1.0.1
>Reporter: Brett Porter
>
> currently we map artifactId's to plugins. This is not guaranteed to be 
> unique, so switch to mapping the groupId:artifactId combo.

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

[jira] Commented: (MAVEN-1676) Problem generation with antlr

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

Arnaud Heritier commented on MAVEN-1676:


I'll test it, but it was certainly due to MAVEN-1691 which was fixed in the 
beta 3

> Problem generation with antlr
> -
>
> Key: MAVEN-1676
> URL: http://jira.codehaus.org/browse/MAVEN-1676
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 1.1-beta-1
> Environment: Linux
>Reporter: Emmanuel Lécharny
>
> The 1.1-beta-1 version cannot handle multiple antlr generation. 1.0.2 version 
> handles it correctly. 
> Here is a sample of this error :
> on apacheds, in shared/ldap/common, 
> $ maven clean
>  __  __
> |  \/  |__ _Apache__ ___
> | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
> |_|  |_\__,_|\_/\___|_||_|  v. 1.1-beta-1
> plugin maven-cruisecontrol-plugin-1.6 is cached (dynatag dep) but no longer 
> present
> Cache invalidated due to out of date plugins
> DEPRECATED: the default goal should be specified in the  section of 
> project.xml instead of maven.xml
> build:start:
> clean:clean:
> xdoc:clean:
> [delete] Deleting directory 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/target
> BUILD SUCCESSFUL
> Total time   : 3 seconds
> Finished at  : Friday, August 26, 2005 12:24:38 PM CEST
> $ maven java:compile
> |  \/  |__ _Apache__ ___
> | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
> |_|  |_\__,_|\_/\___|_||_|  v. 1.1-beta-1
> DEPRECATED: the default goal should be specified in the  section of 
> project.xml instead of maven.xml
> build:start:
> java:prepare-filesystem:
> [mkdir] Created dir: 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/target/classes
> java:compile:
> [copy] Copying 1 file to 
> /home/elecharny/workspace-ads-auto/shared-ldap/common
> antlr:prepare-filesystem:
> [mkdir] Created dir: 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/target/antlr
> antlr:generate:
> ANTLR Parser Generator   Version 2.7.2   1989-2003 jGuru.com
> warning: public lexical rule SIMPLE_STRING is optional (can match "nothing")
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> [delete] Deleting: 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/DnCommonTokenTypes.txt
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> [echo] Compiling to 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/target/classes
> [javac] Compiling 200 source files to 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/target/classes
> [javac] 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/src/java/org/apache/ldap/common/filter/FilterParserImpl.java:31:
>  cannot find symbol
> [javac] symbol  : class AntlrFilterParser
> [javac] location: class org.apache.ldap.common.filter.FilterParserImpl
> [javac] private AntlrFilterParser parser;
> [javac] ^
> (... many errors)
> [javac] 16 errors
> BUILD FAILED
> File.. /home/elecharny/.maven/cache/maven-java-plugin-1.5/plugin.jelly
> Element... ant:javac
> Line.. 63
> Column 48
> Compile failed; see the compiler error output for details.
> Total time   : 4 seconds
> Finished at  : Friday, August 26, 2005 12:24:50 PM CEST
> The very same operation using maven-1.0.2 :
> $ maven clean
>  __  __
> |  \/  |__ _Apache__ ___
> | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
> |_|  |_\__,_|\_/\___|_||_|  v. 1.0.2
> build:start:
> clean:clean:
> [delete] Deleting directory 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/target
> BUILD SUCCESSFUL
> Total time: 1 seconds
> Finished at: Fri Aug 26 12:24:11 CEST 2005
> $maven java:compile
>  __  __
> |  \/  |__ _Apache__ ___
> | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
> |_|  |_\__,_|\_/\___|_||_|  v. 1.0.2
> build:start:
> java:prepare-filesystem:
> [mkdir] Created dir: 
> /home/elecharny/workspace-ads-auto/shared-ldap/com

[jira] Closed: (MAVEN-1576) expecects ForeheadClassLoader, finds sun.misc.Launcher$AppClassLoader

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

Arnaud Heritier closed MAVEN-1576.
--

Resolution: Won't Fix

Not enough important to fix it.

> expecects ForeheadClassLoader, finds sun.misc.Launcher$AppClassLoader
> -
>
> Key: MAVEN-1576
> URL: http://jira.codehaus.org/browse/MAVEN-1576
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.0.2
> Environment: Linux
>Reporter: Willie Milnor
>
> I am trying to get around using com.werken.forehead.Forehead to run Maven, 
> and instead use my own class that extends org.apache.maven.cli.App.  However, 
> I get the following error no matter what I try:
> java.lang.ClassCastException: sun.misc.Launcher$AppClassLoader
> at 
> org.apache.maven.plugin.PluginManager.processDependencies(PluginManager.java:437)
> at 
> org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:642)
> at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
> at MyApp.myDoMain(MyApp.java:80)
> at MyApp.main(MyApp.java:575)
> I know that this is caused by the following line:
> ForeheadClassLoader projectClassLoader = 
> (ForeheadClassLoader)project.getContext().getClassLoader();
> I assume that when com.werken.forehead.Forehead is called, it somehow sets 
> the class loader (for the context) to an instance of ForeheadClassLoader; but 
> by calling my class directly, the context uses an instance of 
> sun.misc.Launcher$AppClassLoader.
> I am able to run my own class calling com.werken.forehead.Forehead first (I 
> edited the forehead.conf file), and it works as it should.  I tried setting 
> the class loader for the context using a ForeheadClassLoader, but that loader 
> is changed somewhere along the way to processing the dependencies.
> Is there a way around this problem?  I am using maven 1.0.2...is there a 
> newer beta version of maven that expects simply a ClassLoader rather than a 
> ForeheadClassLoader?

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

2006-08-03 Thread Daniel Gredler (JIRA)

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

Daniel Gredler updated MNG-671:
---

Attachment: maven-artifact-manager-patch-2.txt
maven-artifact-patch-2.txt
maven-settings-patch-2.txt

Thanks for the comments.

I'm attaching new patches to three of the modules (maven-settings, 
maven-artifact and maven-artifact-manager). They address the issues you raised 
previously. Let me know what you think.

The only unknowns are still basically the same as last time, namely:
 - How to get access to the current Settings object (right now ArtifactResolver 
interface has been modified to take it as a parameter).
 - How to persist changes to the current Settings object.

Any response on the dev list?

> implement a license clickthrough
> 
>
> Key: MNG-671
> URL: http://jira.codehaus.org/browse/MNG-671
> Project: Maven 2
>  Issue Type: New Feature
>Reporter: Brett Porter
> Fix For: 2.1
>
> Attachments: maven-artifact-manager-patch-2.txt, 
> maven-artifact-manager-patch.txt, maven-artifact-patch-2.txt, 
> 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] Created: (CONTINUUM-802) Use fine grained permissions per project

Use fine grained permissions per project


 Key: CONTINUUM-802
 URL: http://jira.codehaus.org/browse/CONTINUUM-802
 Project: Continuum
  Issue Type: Sub-task
Reporter: Carlos Sanchez
 Assigned To: Carlos Sanchez




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

[jira] Commented: (MAVEN-1676) Problem generation with antlr

2006-08-03 Thread JIRA

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

Emmanuel Lécharny commented on MAVEN-1676:
--

Don't loose your time on this pb. Since I filled the JIRA last year, it has 
been fixed, and we have switched to m2, which is far better !!!

I will close the issue

Thanks anyway.

> Problem generation with antlr
> -
>
> Key: MAVEN-1676
> URL: http://jira.codehaus.org/browse/MAVEN-1676
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 1.1-beta-1
> Environment: Linux
>Reporter: Emmanuel Lécharny
>
> The 1.1-beta-1 version cannot handle multiple antlr generation. 1.0.2 version 
> handles it correctly. 
> Here is a sample of this error :
> on apacheds, in shared/ldap/common, 
> $ maven clean
>  __  __
> |  \/  |__ _Apache__ ___
> | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
> |_|  |_\__,_|\_/\___|_||_|  v. 1.1-beta-1
> plugin maven-cruisecontrol-plugin-1.6 is cached (dynatag dep) but no longer 
> present
> Cache invalidated due to out of date plugins
> DEPRECATED: the default goal should be specified in the  section of 
> project.xml instead of maven.xml
> build:start:
> clean:clean:
> xdoc:clean:
> [delete] Deleting directory 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/target
> BUILD SUCCESSFUL
> Total time   : 3 seconds
> Finished at  : Friday, August 26, 2005 12:24:38 PM CEST
> $ maven java:compile
> |  \/  |__ _Apache__ ___
> | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
> |_|  |_\__,_|\_/\___|_||_|  v. 1.1-beta-1
> DEPRECATED: the default goal should be specified in the  section of 
> project.xml instead of maven.xml
> build:start:
> java:prepare-filesystem:
> [mkdir] Created dir: 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/target/classes
> java:compile:
> [copy] Copying 1 file to 
> /home/elecharny/workspace-ads-auto/shared-ldap/common
> antlr:prepare-filesystem:
> [mkdir] Created dir: 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/target/antlr
> antlr:generate:
> ANTLR Parser Generator   Version 2.7.2   1989-2003 jGuru.com
> warning: public lexical rule SIMPLE_STRING is optional (can match "nothing")
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> [delete] Deleting: 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/DnCommonTokenTypes.txt
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> [echo] Compiling to 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/target/classes
> [javac] Compiling 200 source files to 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/target/classes
> [javac] 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/src/java/org/apache/ldap/common/filter/FilterParserImpl.java:31:
>  cannot find symbol
> [javac] symbol  : class AntlrFilterParser
> [javac] location: class org.apache.ldap.common.filter.FilterParserImpl
> [javac] private AntlrFilterParser parser;
> [javac] ^
> (... many errors)
> [javac] 16 errors
> BUILD FAILED
> File.. /home/elecharny/.maven/cache/maven-java-plugin-1.5/plugin.jelly
> Element... ant:javac
> Line.. 63
> Column 48
> Compile failed; see the compiler error output for details.
> Total time   : 4 seconds
> Finished at  : Friday, August 26, 2005 12:24:50 PM CEST
> The very same operation using maven-1.0.2 :
> $ maven clean
>  __  __
> |  \/  |__ _Apache__ ___
> | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
> |_|  |_\__,_|\_/\___|_||_|  v. 1.0.2
> build:start:
> clean:clean:
> [delete] Deleting directory 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/target
> BUILD SUCCESSFUL
> Total time: 1 seconds
> Finished at: Fri Aug 26 12:24:11 CEST 2005
> $maven java:compile
>  __  __
> |  \/  |__ _Apache__ ___
> | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
> |_|  |_\__,_|\_/\___|_||_|  v. 1.0.2
> build:start:
> java

[jira] Closed: (MAVEN-1676) Problem generation with antlr

2006-08-03 Thread JIRA

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

Emmanuel Lécharny closed MAVEN-1676.


Resolution: Fixed

One year old beta bugs are not anymore valid :) Let's burry it...

> Problem generation with antlr
> -
>
> Key: MAVEN-1676
> URL: http://jira.codehaus.org/browse/MAVEN-1676
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 1.1-beta-1
> Environment: Linux
>Reporter: Emmanuel Lécharny
>
> The 1.1-beta-1 version cannot handle multiple antlr generation. 1.0.2 version 
> handles it correctly. 
> Here is a sample of this error :
> on apacheds, in shared/ldap/common, 
> $ maven clean
>  __  __
> |  \/  |__ _Apache__ ___
> | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
> |_|  |_\__,_|\_/\___|_||_|  v. 1.1-beta-1
> plugin maven-cruisecontrol-plugin-1.6 is cached (dynatag dep) but no longer 
> present
> Cache invalidated due to out of date plugins
> DEPRECATED: the default goal should be specified in the  section of 
> project.xml instead of maven.xml
> build:start:
> clean:clean:
> xdoc:clean:
> [delete] Deleting directory 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/target
> BUILD SUCCESSFUL
> Total time   : 3 seconds
> Finished at  : Friday, August 26, 2005 12:24:38 PM CEST
> $ maven java:compile
> |  \/  |__ _Apache__ ___
> | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
> |_|  |_\__,_|\_/\___|_||_|  v. 1.1-beta-1
> DEPRECATED: the default goal should be specified in the  section of 
> project.xml instead of maven.xml
> build:start:
> java:prepare-filesystem:
> [mkdir] Created dir: 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/target/classes
> java:compile:
> [copy] Copying 1 file to 
> /home/elecharny/workspace-ads-auto/shared-ldap/common
> antlr:prepare-filesystem:
> [mkdir] Created dir: 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/target/antlr
> antlr:generate:
> ANTLR Parser Generator   Version 2.7.2   1989-2003 jGuru.com
> warning: public lexical rule SIMPLE_STRING is optional (can match "nothing")
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> [delete] Deleting: 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/DnCommonTokenTypes.txt
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> antlr:prepare-filesystem:
> antlr:generate:
> Overriding previous definition of reference to maven.antlr.compile.src.set
> [echo] Compiling to 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/target/classes
> [javac] Compiling 200 source files to 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/target/classes
> [javac] 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/src/java/org/apache/ldap/common/filter/FilterParserImpl.java:31:
>  cannot find symbol
> [javac] symbol  : class AntlrFilterParser
> [javac] location: class org.apache.ldap.common.filter.FilterParserImpl
> [javac] private AntlrFilterParser parser;
> [javac] ^
> (... many errors)
> [javac] 16 errors
> BUILD FAILED
> File.. /home/elecharny/.maven/cache/maven-java-plugin-1.5/plugin.jelly
> Element... ant:javac
> Line.. 63
> Column 48
> Compile failed; see the compiler error output for details.
> Total time   : 4 seconds
> Finished at  : Friday, August 26, 2005 12:24:50 PM CEST
> The very same operation using maven-1.0.2 :
> $ maven clean
>  __  __
> |  \/  |__ _Apache__ ___
> | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
> |_|  |_\__,_|\_/\___|_||_|  v. 1.0.2
> build:start:
> clean:clean:
> [delete] Deleting directory 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/target
> BUILD SUCCESSFUL
> Total time: 1 seconds
> Finished at: Fri Aug 26 12:24:11 CEST 2005
> $maven java:compile
>  __  __
> |  \/  |__ _Apache__ ___
> | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
> |_|  |_\__,_|\_/\___|_||_|  v. 1.0.2
> build:start:
> java:prepare-filesystem:
> [mkdir] Created dir: 
> /home/elecharny/workspace-ads-auto/shared-ldap/common/target/classes
> java:compile

[jira] Updated: (MNG-2471) Add search box to the index page

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

Denis Cabasson updated MNG-2471:


Attachment: MNG-2471-site[wlogo_wfocus_XHTML].patch
index[wlogo_wfocus_XHTML].html

Submitted my recommended changes:
* Include smallest Google logo, for legal reasons
* Strip br in the box, as they don't have any use
* Change id of new box, and make use of classes instead
* Try to comply with XHTML standard. Only 3 issues remaining on this point, but 
they are already there in current version.

+ Make use of existing focus script (with improvement to Javascript code).

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

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

[jira] Updated: (MNG-2471) Add search box to the index page

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

Denis Cabasson updated MNG-2471:


Attachment: site[wlogo_wfocus_XHTML].css

corrected CSS stylesheet

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

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

[jira] Updated: (MNG-2471) Add search box to the index page

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

Denis Cabasson updated MNG-2471:


Attachment: index[wlogo_wfocus_XHTML_CSS].html

Corrected link to css (so that HTML page can be viewed)

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

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

[jira] Created: (CONTINUUM-803) Unable to upload pom

2006-08-03 Thread Napoleon Esmundo C. Ramirez (JIRA)

Unable to upload pom


 Key: CONTINUUM-803
 URL: http://jira.codehaus.org/browse/CONTINUUM-803
 Project: Continuum
  Issue Type: Bug
  Components: Web interface
 Environment: Linux FC4, Maven 2.0.4, JDK 1.5
Reporter: Napoleon Esmundo C. Ramirez


When uploading a pom, I see the ff In the logs:

21:09:41,890 ERROR 
com.opensymphony.webwork.dispatcher.multipart.MultiPartRequest 
[com.opensymphony.webwork.dispatcher.multipart.JakartaMultiPartRequest] 
org.apache.commons.fileupload.FileUploadException: Processing of 
multipart/form-data request failed. 
~/tmp/upload__376f5d97_10cd425ed0c__8000_0001.tmp (No such file or 
directory)
21:09:41,893 ERROR com.opensymphony.webwork.interceptor.FileUploadInterceptor 
[com.opensymphony.webwork.interceptor.FileUploadInterceptor] Processing of 
multipart/form-data request failed. 
~/tmp/upload__376f5d97_10cd425ed0c__8000_0001.tmp (No such file or 
directory)
21:09:42,349 ERROR com.opensymphony.webwork.interceptor.FileUploadInterceptor 
[com.opensymphony.webwork.interceptor.FileUploadInterceptor] Processing of 
multipart/form-data request failed. 
~/tmp/upload__376f5d97_10cd425ed0c__8000_0001.tmp (No such file or 
directory)
21:09:42,369 WARN  com.opensymphony.xwork.DefaultActionInvocation 
[com.opensymphony.xwork.DefaultActionInvocation] No result defined for action 
org.apache.maven.continuum.web.action.ConfigurationAction and result input

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

[jira] Updated: (MNG-2471) Add search box to the index page

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

Denis Cabasson updated MNG-2471:


Attachment: index[wlogo_wfocus_XHTML_CSS2].html

I'm getting crazy Hope this time uploaded html will be right.

I guess this entry need a little clean-up (but I haven't got the necessary 
credentials).

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

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

[jira] Created: (MNG-2482) defining a plugin within affects configuration of the same plugin defined within

2006-08-03 Thread Martin Ploeckinger (JIRA)

defining a plugin within  affects configuration of the same plugin 
defined within 
-

 Key: MNG-2482
 URL: http://jira.codehaus.org/browse/MNG-2482
 Project: Maven 2
  Issue Type: Bug
  Components: Ant tasks, Plugin API
Affects Versions: 2.0.4
 Environment: windows xp sp2
Reporter: Martin Ploeckinger
 Attachments: build_part_of_pom.xml

a problem occurs using the antrun-plugin in maven for some different tasks.

first i defined the antrun-plugin within  for execution tasks 
only in the child poms, even with 2 different execution tags and phases and it 
worked perfect.

and now i wanted to add an ant job which should be executed only once at top 
level and therefore i had to "redefine" the antrun-plugin outside of 
 with an false option.

but however this does not work, the ant tasks within  are now 
executed at top level too

it is funny that both definitions work, the top-level job and the child jobs, 
but not togehter in one pom...i always have to leave the other ones aside

i used the attached build section in my top level pom.xml and the error i get 
is that "rmic" is also executed at top level pom where no source is available 
understandably

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

[jira] Commented: (MAVEN-1704) artifactId is used as groupId when the latest is not defined

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

Lukas Theussl commented on MAVEN-1704:
--

Checked and verified. I don't think the first point should be fixed (for 
backwards compat), but we could give a warning message. For the second 
observation, I'd like to know what is the expected/defined behavior?

> artifactId is used as groupId when the latest is not defined
> 
>
> Key: MAVEN-1704
> URL: http://jira.codehaus.org/browse/MAVEN-1704
> Project: Maven
>  Issue Type: Bug
>  Components: inheritance
>Affects Versions: 1.1-beta-2
>Reporter: Carlos Sanchez
> Fix For: 1.1-rc1
>
>
> artifactId is used as groupId when the latest is not defined (using extends 
> at least), both in 1.0.2 and 1.1b2, which I believe it's a problem, maven 
> should complain.
> Which is really a problem is that if pom a extends pom b, and no groupId is 
> defined in any of both, in 1.0.2 the artifactId of a is chosen as groupId, 
> while in 1.1 artifactId of b is the chosen one.

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

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

Carlos Sanchez closed MEV-426.
--

  Assignee: Carlos Sanchez
Resolution: Fixed

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

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

[jira] Commented: (MAVEN-410) maven plugins seem to choke on properties containing a "-"?

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

Lukas Theussl commented on MAVEN-410:
-

I have added a comment already: 
http://maven.apache.org/maven-1.x/using/customising.html#Extending_the_Build_with_Properties.

> maven plugins seem to choke on properties containing a "-"?
> ---
>
> Key: MAVEN-410
> URL: http://jira.codehaus.org/browse/MAVEN-410
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.0-beta-9
> Environment: RedHat Linux 7.3, JDK 1.3.1
>Reporter: Henning Schmiedehausen
> Fix For: 1.1-rc1
>
>
> I'm using the Torque plugin to create id-table init sql files from my
> XML schemas. If I download maven 1.0b9 from apache.org, install it and
> then issue
> % maven -X torque
> I get
> torque:id-table-init-sql:
> Using contextProperties file: 
> /mnt/home.net/henning/cvs/turbine-2/project.properties
> [torque-sql] [VERBOSE] Using templatePath: 
> /mnt/home.net/henning/cvs/turbine-2/src/torqueTemplates
> [torque-sql] Using classpath
> [torque-sql] Generating to file 
> /mnt/home.net/henning/cvs/turbine-2/target/sql/report.idtable-init.sql.generation
> [torque-sql] [DEBUG] fileset: Setup scanner in dir 
> /mnt/home.net/henning/cvs/turbine-2/target with patternSet{ includes: [0] 
> excludes: [0] }
> BUILD SUCCESSFUL
> Total time:  7 seconds
> Note the [0] for include and exclude list in the file scanner.
> If I now load the plugin.properties and plugin.jelly file from
> Torque and replace in both files for the properties
> torque.schema.init-sql.includes
> torque.schema.init-sql.excludes
> the "init-sql" part with "initsql"
> and re-issue the command:
> % maven -X torque
> then I get
> torque:id-table-init-sql:
> Using contextProperties file: 
> /mnt/home.net/henning/cvs/turbine-2/project.properties
> [torque-sql] [VERBOSE] Using templatePath: 
> /mnt/home.net/henning/cvs/turbine-2/src/torqueTemplates
> [torque-sql] Using classpath
> [torque-sql] Generating to file 
> /mnt/home.net/henning/cvs/turbine-2/target/sql/report.idtable-init.sql.generation
> [torque-sql] [DEBUG] fileset: Setup scanner in dir 
> /mnt/home.net/henning/cvs/turbine-2/target with patternSet{ includes: 
> [*-schema.xml] excludes: [id-table-schema.xml] }
> Parsing file: 'scheduler-schema.xml'
> log4j:WARN No appenders could be found for logger 
> (org.apache.torque.engine.database.transform.DTDResolver).
> log4j:WARN Please initialize the log4j system properly.
> Parsing file: 'torque-security-schema.xml'
> Parsing file: 'scheduler-idtable-schema.xml'
> Parsing file: 'torque-security-idtable-schema.xml'
> BUILD SUCCESSFUL
> Total time:  9 seconds
> Note that now the file scanner correctly picks up my schema files
> and builds the sql init 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] Commented: (MPXDOC-111) is transformed into

[ http://jira.codehaus.org/browse/MPXDOC-111?page=comments#action_71522 ] 

Lukas Theussl commented on MPXDOC-111:
--

I checked it and it's still not fixed.

The bug I opened in dom4j is fixed in the version we are shipping with m11b3, 
but the feature has to be switched on explicitly, and it's an issue of jelly 
using dom4j, and I forgot to check that when I custom-built our own jelly, so 
it's not fixed yet... :(

>  is transformed into 
> ---
>
> Key: MPXDOC-111
> URL: http://jira.codehaus.org/browse/MPXDOC-111
> Project: maven-xdoc-plugin
>  Issue Type: Bug
>Reporter: Carlos Sanchez
>
> This causes two line breaks (at least in IE 6)
> For example (at 
> http://cvs.apache.org/viewcvs.cgi/maven-plugins/aspectj/xdocs/index.xml?rev=1.7&view=auto)
> 
>   
> To install or update the plugin do the following:
> maven plugin:download -DgroupId=maven 
> -DartifactId=maven-aspectj-plugin -Dversion=
>   
> 
> is transformed into (at http://maven.apache.org/reference/plugins/aspectj/)
> 
>   Installing
>   
> To install or update the plugin do the following:
> maven plugin:download -DgroupId=maven 
> -DartifactId=maven-aspectj-plugin -Dversion=
>   
> 

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

[jira] Commented: (MAVEN-1704) artifactId is used as groupId when the latest is not defined

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

Arnaud Heritier commented on MAVEN-1704:


If groupId isn't defined, groupId=artifactId thus the behaviour described seems 
normal. The parent and the child projects will have a different groupId.
The solution could be to force users to define groupId/artifactId if id isn't 
defined. Otherwise we fail the build. Will it broke so many projects ? I don't 
think.

> artifactId is used as groupId when the latest is not defined
> 
>
> Key: MAVEN-1704
> URL: http://jira.codehaus.org/browse/MAVEN-1704
> Project: Maven
>  Issue Type: Bug
>  Components: inheritance
>Affects Versions: 1.1-beta-2
>Reporter: Carlos Sanchez
> Fix For: 1.1-rc1
>
>
> artifactId is used as groupId when the latest is not defined (using extends 
> at least), both in 1.0.2 and 1.1b2, which I believe it's a problem, maven 
> should complain.
> Which is really a problem is that if pom a extends pom b, and no groupId is 
> defined in any of both, in 1.0.2 the artifactId of a is chosen as groupId, 
> while in 1.1 artifactId of b is the chosen one.

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

[jira] Commented: (MAVEN-410) maven plugins seem to choke on properties containing a "-"?

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

Arnaud Heritier commented on MAVEN-410:
---

It's perhaps not enough visible but I think that we can close this issue.

> maven plugins seem to choke on properties containing a "-"?
> ---
>
> Key: MAVEN-410
> URL: http://jira.codehaus.org/browse/MAVEN-410
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.0-beta-9
> Environment: RedHat Linux 7.3, JDK 1.3.1
>Reporter: Henning Schmiedehausen
> Fix For: 1.1-rc1
>
>
> I'm using the Torque plugin to create id-table init sql files from my
> XML schemas. If I download maven 1.0b9 from apache.org, install it and
> then issue
> % maven -X torque
> I get
> torque:id-table-init-sql:
> Using contextProperties file: 
> /mnt/home.net/henning/cvs/turbine-2/project.properties
> [torque-sql] [VERBOSE] Using templatePath: 
> /mnt/home.net/henning/cvs/turbine-2/src/torqueTemplates
> [torque-sql] Using classpath
> [torque-sql] Generating to file 
> /mnt/home.net/henning/cvs/turbine-2/target/sql/report.idtable-init.sql.generation
> [torque-sql] [DEBUG] fileset: Setup scanner in dir 
> /mnt/home.net/henning/cvs/turbine-2/target with patternSet{ includes: [0] 
> excludes: [0] }
> BUILD SUCCESSFUL
> Total time:  7 seconds
> Note the [0] for include and exclude list in the file scanner.
> If I now load the plugin.properties and plugin.jelly file from
> Torque and replace in both files for the properties
> torque.schema.init-sql.includes
> torque.schema.init-sql.excludes
> the "init-sql" part with "initsql"
> and re-issue the command:
> % maven -X torque
> then I get
> torque:id-table-init-sql:
> Using contextProperties file: 
> /mnt/home.net/henning/cvs/turbine-2/project.properties
> [torque-sql] [VERBOSE] Using templatePath: 
> /mnt/home.net/henning/cvs/turbine-2/src/torqueTemplates
> [torque-sql] Using classpath
> [torque-sql] Generating to file 
> /mnt/home.net/henning/cvs/turbine-2/target/sql/report.idtable-init.sql.generation
> [torque-sql] [DEBUG] fileset: Setup scanner in dir 
> /mnt/home.net/henning/cvs/turbine-2/target with patternSet{ includes: 
> [*-schema.xml] excludes: [id-table-schema.xml] }
> Parsing file: 'scheduler-schema.xml'
> log4j:WARN No appenders could be found for logger 
> (org.apache.torque.engine.database.transform.DTDResolver).
> log4j:WARN Please initialize the log4j system properly.
> Parsing file: 'torque-security-schema.xml'
> Parsing file: 'scheduler-idtable-schema.xml'
> Parsing file: 'torque-security-idtable-schema.xml'
> BUILD SUCCESSFUL
> Total time:  9 seconds
> Note that now the file scanner correctly picks up my schema files
> and builds the sql init 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] Commented: (MPXDOC-111) is transformed into

[ http://jira.codehaus.org/browse/MPXDOC-111?page=comments#action_71525 ] 

Arnaud Heritier commented on MPXDOC-111:


Can we plan to upgrade our custom Jelly to fix this in the RC1 ?

>  is transformed into 
> ---
>
> Key: MPXDOC-111
> URL: http://jira.codehaus.org/browse/MPXDOC-111
> Project: maven-xdoc-plugin
>  Issue Type: Bug
>Reporter: Carlos Sanchez
>
> This causes two line breaks (at least in IE 6)
> For example (at 
> http://cvs.apache.org/viewcvs.cgi/maven-plugins/aspectj/xdocs/index.xml?rev=1.7&view=auto)
> 
>   
> To install or update the plugin do the following:
> maven plugin:download -DgroupId=maven 
> -DartifactId=maven-aspectj-plugin -Dversion=
>   
> 
> is transformed into (at http://maven.apache.org/reference/plugins/aspectj/)
> 
>   Installing
>   
> To install or update the plugin do the following:
> maven plugin:download -DgroupId=maven 
> -DartifactId=maven-aspectj-plugin -Dversion=
>   
> 

-- 
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: (MPPOM-6) Id in POM is deprecated.

[ http://jira.codehaus.org/browse/MPPOM-6?page=comments#action_71526 ] 

Lukas Theussl commented on MPPOM-6:
---

Sorry but I am quite annoyed by this. Trygve mentioned on the user list that 
the id element was deprecated some 3 years ago, that's 2 years before I joined 
the Maven team. I haven't been aware that it was deprecated until this recent 
thread on the user list. Apparently the docs patch by Dennis at MAVEN-1410 has 
never been applied. When I released the last version of the pom plugin, I spent 
quite some time getting the validation routines to work and I compiled a table 
of required elements [1]. That was about half a year ago, nobody complained 
since, nor during vote. 

The main problem is that I'm not sure if some plugins don't still expect/use 
the id element, I'd have to check. Also, as pointed out at MAVEN-1410, we can't 
just change the POM-3 xsd, as it might break some existing builds. The 
consensus at MAVEN-1410 seems to have been to just document the deprecation, 
but not to change anything. The pom plugin only validates against a given xsd, 
so if an element is required by the xsd then it can hardly be considered a bug 
if the plugin complains. 

My personal preference would be to keep the id element required by the xsd, but 
to document that it's actually not used anymore by the maven core (it might 
still be used by some plugins). WDYT?

[1] 
http://maven.apache.org/maven-1.x/plugins/pom/validation.html#Required_elements

> Id in POM is deprecated.
> 
>
> Key: MPPOM-6
> URL: http://jira.codehaus.org/browse/MPPOM-6
> Project: maven-pom-plugin
>  Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Arnaud Heritier
>Priority: Critical
> Fix For: 1.5.1
>
>
> The pom:validate goal uses a schema which is false. The id element is 
> deprecated and replaced by groupId/artifactId.

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

[jira] Commented: (MPXDOC-111) is transformed into

[ http://jira.codehaus.org/browse/MPXDOC-111?page=comments#action_71528 ] 

Lukas Theussl commented on MPXDOC-111:
--

Another custom jelly build? :( If that carries on like that we might as well 
take over jelly maintenance... ;) I don't think this issue is important enough 
for that...

>  is transformed into 
> ---
>
> Key: MPXDOC-111
> URL: http://jira.codehaus.org/browse/MPXDOC-111
> Project: maven-xdoc-plugin
>  Issue Type: Bug
>Reporter: Carlos Sanchez
>
> This causes two line breaks (at least in IE 6)
> For example (at 
> http://cvs.apache.org/viewcvs.cgi/maven-plugins/aspectj/xdocs/index.xml?rev=1.7&view=auto)
> 
>   
> To install or update the plugin do the following:
> maven plugin:download -DgroupId=maven 
> -DartifactId=maven-aspectj-plugin -Dversion=
>   
> 
> is transformed into (at http://maven.apache.org/reference/plugins/aspectj/)
> 
>   Installing
>   
> To install or update the plugin do the following:
> maven plugin:download -DgroupId=maven 
> -DartifactId=maven-aspectj-plugin -Dversion=
>   
> 

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

[jira] Updated: (MSUREFIRE-153) Ability to add additions to classpath

2006-08-03 Thread David J. M. Karlsen (JIRA)

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

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

Attachment: MSUREFIRE-153-maven-surefire-plugin.patch

The first patch was incorrect.
Please delete the first attachment and use this one.

Thanks,

David

> Ability to add additions to classpath
> -
>
> Key: MSUREFIRE-153
> URL: http://jira.codehaus.org/browse/MSUREFIRE-153
> Project: Maven 2.x Surefire Plugin
>  Issue Type: Improvement
> Environment: N/A
>Reporter: David J. M. Karlsen
> Attachments: MSUREFIRE-153-maven-surefire-plugin.patch, 
> SurefirePlugin.java-diff
>
>
> There should be a possibility to add arbritary resources to the classpath 
> while executing the tests. These resources would only be available while 
> executing the tests, so they won't be added in the archive.
> i suggest a configuration element
> 
>  some/path
>  /some/other/path
> 
> This issue somewhat related to http://jira.codehaus.org/browse/MJAR-13 / 
> ability to exclude/include filtering in archiver/jar-plugin

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

[jira] Closed: (MASSEMBLY-128) Refactor and improve unit testing

 [ http://jira.codehaus.org/browse/MASSEMBLY-128?page=all ]

John Casey closed MASSEMBLY-128.


  Assignee: John Casey
Resolution: Fixed

refactor complete, and unit tests have 50% coverage, including the generated 
classes.

Items left to test:

- the mojos themselves (these are simple facades for the rest of the plugin)
- default repository assembler
- DigestUtils (not sure I have the expertise to test this one)
- the remainder of the generated classes (esp the reader and writer classes)

I believe we have a workable set of unit tests here, and I'd like to start 
investigating how to reinstate the functional tests as actual Maven builds that 
get run in the integration-test phase...

> Refactor and improve unit testing
> -
>
> Key: MASSEMBLY-128
> URL: http://jira.codehaus.org/browse/MASSEMBLY-128
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: John Casey
> Assigned To: John Casey
>Priority: Blocker
> Fix For: 2.2
>
>
> The current implementation of the assembly plugin is that of a few really 
> hard to manage monoliths, from which all the mojos extend. Also, the tests 
> included in this plugin are not true unit tests, but more functional tests, 
> in that they test the entirety of a mojo under a particular use case, as if 
> it were a black box.
> If we break the assembly plugin's abstract classes up into a reasonable set 
> of helper/utility classes, we should be able to unit test individual pieces 
> of the system without resorting to black-box testing of an entire mojo. This 
> should improve the resilience of these tests when a new feature is added. 
> Currently, it's nearly impossible to add a feature without spending a day 
> trying to figure out why the tests are failing (a day is not an exaggeration, 
> BTW).

-- 
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: (MPPOM-6) Id in POM is deprecated.

[ http://jira.codehaus.org/browse/MPPOM-6?page=comments#action_71531 ] 

Arnaud Heritier commented on MPPOM-6:
-

I'm sorry, but it was my fault. I didn't noticed this problem.
I don't know why MAVEN-1410 was closed without to fix the schema.
For me we must change the schema and maven-model to avoid errors from users.
But for me the choice is id or groupId+artifactId.
If need the model and the xsd can become a version 3.1 instead of a 3.0.2
WDYT ?


> Id in POM is deprecated.
> 
>
> Key: MPPOM-6
> URL: http://jira.codehaus.org/browse/MPPOM-6
> Project: maven-pom-plugin
>  Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Arnaud Heritier
>Priority: Critical
> Fix For: 1.5.1
>
>
> The pom:validate goal uses a schema which is false. The id element is 
> deprecated and replaced by groupId/artifactId.

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

[jira] Commented: (MCHECKSTYLE-51) Rules summary flexibility:add possibility to hide non-violated rules and to sort by descending number of occurences

2006-08-03 Thread Olivier Vierlinck (JIRA)

[ http://jira.codehaus.org/browse/MCHECKSTYLE-51?page=comments#action_71532 
] 

Olivier Vierlinck commented on MCHECKSTYLE-51:
--

ok, I see more documentation there on the possibile customization of the plugin.

I'm ok to put the doc for the 2 new settings... if my patch is accepted!
What are the next steps? 


> Rules summary flexibility:add possibility to hide non-violated rules and to 
> sort by descending number of occurences
> ---
>
> Key: MCHECKSTYLE-51
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-51
> Project: Maven 2.x Checkstyle Plugin
>  Issue Type: Improvement
>Affects Versions: 2.1
> Environment: NA
>Reporter: Olivier Vierlinck
>Priority: Minor
> Attachments: MNG-39787-maven-plugin-checkstyle.patch
>
>
> While using maven + Checkstyle on a new project, the amount of 
> errors/warnings was quite high, due both because checkstyle was not yet 
> configured to match our preferences.. and also to real style errors.
> To refine this, it very useful to tackle first the big problems=the one 
> occuring often
> Similarly, it is helpful NOT to see the rules that are not violated, so that 
> we can concentrate on the existing problems

-- 
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: (ARCHETYPE-50) archetype:create-from-project

2006-08-03 Thread Adam Leggett (JIRA)

archetype:create-from-project
-

 Key: ARCHETYPE-50
 URL: http://jira.codehaus.org/browse/ARCHETYPE-50
 Project: Maven Archetype
  Issue Type: Improvement
  Components: Creator
 Environment: winxpsp2
jdk1.5
maven2.0.4
Reporter: Adam Leggett
 Attachments: archetype-creator-src.zip

I've created a prototype patch for the create-from-project ArchetypeCreator 
impl.

I was hoping to work out how to invoke this using -DarchetypeCreator= at the 
cli but am not sure as yet.

I created a template method in an abstract class to define the steps in 
creation so i could understand it better. Also with one eye on doing a 
multi-mod implementation. Also refactored some of the logic into a utility so 
the main creator class is cleaner.

Code attached.

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

[jira] Commented: (MPXDOC-111) is transformed into

[ http://jira.codehaus.org/browse/MPXDOC-111?page=comments#action_71534 ] 

Arnaud Heritier commented on MPXDOC-111:


One more, one less ;-)
But it's a good idea we can propose that you join the jakarta-commons team !! 
;-)

>  is transformed into 
> ---
>
> Key: MPXDOC-111
> URL: http://jira.codehaus.org/browse/MPXDOC-111
> Project: maven-xdoc-plugin
>  Issue Type: Bug
>Reporter: Carlos Sanchez
>
> This causes two line breaks (at least in IE 6)
> For example (at 
> http://cvs.apache.org/viewcvs.cgi/maven-plugins/aspectj/xdocs/index.xml?rev=1.7&view=auto)
> 
>   
> To install or update the plugin do the following:
> maven plugin:download -DgroupId=maven 
> -DartifactId=maven-aspectj-plugin -Dversion=
>   
> 
> is transformed into (at http://maven.apache.org/reference/plugins/aspectj/)
> 
>   Installing
>   
> To install or update the plugin do the following:
> maven plugin:download -DgroupId=maven 
> -DartifactId=maven-aspectj-plugin -Dversion=
>   
> 

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

[jira] Commented: (MNGECLIPSE-172) Eclipse PDE seems slightly incompatible with plugin

2006-08-03 Thread Eugene Kuleshov (JIRA)

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

Eugene Kuleshov commented on MNGECLIPSE-172:


How this issue is different from MNGECLIPSE-106 ? Please let me know if this is 
a duplicate. Otherwise please provide example Eclipse project that can be used 
to reproduce your issues.

I don't think we should be tweaking maven jars. Though it doesn't seem like PDE 
will recognize dependencies that came from maven container. Unless PDE build 
process will take it into the account, the only option I see is to completely 
use Maven to build plugins. There is an issue in Maven eclipse plugin about 
this.

Currently our plugin is not using maven and we have all the dependencies (both 
embedder and new lucene) as internal jars.


> Eclipse PDE seems slightly incompatible with plugin
> ---
>
> Key: MNGECLIPSE-172
> URL: http://jira.codehaus.org/browse/MNGECLIPSE-172
> Project: Maven 2.x Extension for Eclipse
>  Issue Type: Improvement
>Affects Versions: 0.0.9
>Reporter: Yuri Schimke
> Assigned To: Eugene Kuleshov
>
> Eclipse PDE Rich Clients seem to have trouble when using the maven plugin.
> To actually build the client application it seems to need the dependency jars 
> within the project.  To get around this we use the 
> dependency:copy-dependencies task.  However this setup stops debugging from 
> working. It also means you need to run mvn install for the other projects 
> each time before you copy the dependencies.
> In constrast, after applying the patch from MNGECLIPSE-59, non-PDE projects 
> work brilliantly.
> I'm reporting this improvement for a number of reasons 1) in case others are 
> facing the same problem, 2) in case other have solved the same problem 
> already and 3) in case it might be something you guys can fix easily.
> You guys might be the best candidates to answer 2) since you presumably use 
> Eclipse to edit the maven2 plugin anyway.
> Another option might be to make each maven JAR a valid OSGI plugin, which is 
> mainly a couple of extra files in the JAR.  This could potentially be done 
> with a MOJO that added the default, most liberal OSGI settings into the JAR.  
> But this seems a bit extreme, and also inflexible in the case of truly 
> internal dependencies.

-- 
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-803) Unable to upload pom

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

Carlos Sanchez commented on CONTINUUM-803:
--

This was in continuum trunk

> Unable to upload pom
> 
>
> Key: CONTINUUM-803
> URL: http://jira.codehaus.org/browse/CONTINUUM-803
> Project: Continuum
>  Issue Type: Bug
>  Components: Web interface
> Environment: Linux FC4, Maven 2.0.4, JDK 1.5
>Reporter: Napoleon Esmundo C. Ramirez
>
> When uploading a pom, I see the ff In the logs:
> 21:09:41,890 ERROR 
> com.opensymphony.webwork.dispatcher.multipart.MultiPartRequest 
> [com.opensymphony.webwork.dispatcher.multipart.JakartaMultiPartRequest] 
> org.apache.commons.fileupload.FileUploadException: Processing of 
> multipart/form-data request failed. 
> ~/tmp/upload__376f5d97_10cd425ed0c__8000_0001.tmp (No such file or 
> directory)
> 21:09:41,893 ERROR com.opensymphony.webwork.interceptor.FileUploadInterceptor 
> [com.opensymphony.webwork.interceptor.FileUploadInterceptor] Processing of 
> multipart/form-data request failed. 
> ~/tmp/upload__376f5d97_10cd425ed0c__8000_0001.tmp (No such file or 
> directory)
> 21:09:42,349 ERROR com.opensymphony.webwork.interceptor.FileUploadInterceptor 
> [com.opensymphony.webwork.interceptor.FileUploadInterceptor] Processing of 
> multipart/form-data request failed. 
> ~/tmp/upload__376f5d97_10cd425ed0c__8000_0001.tmp (No such file or 
> directory)
> 21:09:42,369 WARN  com.opensymphony.xwork.DefaultActionInvocation 
> [com.opensymphony.xwork.DefaultActionInvocation] No result defined for action 
> org.apache.maven.continuum.web.action.ConfigurationAction and result input

-- 
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: (MPA-76) Process Shinobu Kawai

Process Shinobu Kawai
-

 Key: MPA-76
 URL: http://jira.codehaus.org/browse/MPA-76
 Project: Maven Project Administration
  Issue Type: Task
  Components: New Committers
Reporter: Lukas Theussl
 Assigned To: Jason van Zyl
 Fix For: 2006-q3




-- 
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: (MPA-77) Process Jeff Jensen

Process Jeff Jensen
---

 Key: MPA-77
 URL: http://jira.codehaus.org/browse/MPA-77
 Project: Maven Project Administration
  Issue Type: Task
  Components: New Committers
Reporter: Lukas Theussl
 Assigned To: Jason van Zyl
 Fix For: 2006-q3




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

Assembly including binaries: Bug on a n depth hierarchy

2006-08-03 Thread Alexis Midon


Hi all,

I have the following complex but common pom hierarchy (sample) :
The syntax is packaging:pom:level.#

pom:pom0.0
   /\
  /  \
 /\
/  \
   /\
   jar:pom1.0   pom:pom1.1
   /\
  /  \
 /\
/  \
   /\
jar:pom2.0  jar:pom2.1


I'd like to use the assembly plugin to gather all the output jars in a
single directory.
(So every child/target/artifact.jar must copy to root/target/assembly/...)

To do so I execute the assemby:assembly goal with the following descriptor :


   collect-alljars
   
   dir
   
false
   
   
   
   false
   
   
   


Unfortunately this always fails into an exception: "pom:pom1.1 does not have
an artifact with a file. Please ensure the package phase (...)"

This use case highlights 2 problems I think:

  1. the assembly plugin does not support n depth hierarchy
  Actually pom:pom1.1 should not be included in the module list while
  jar:pom2.0 and jar:pom2.1 should.
  2. the  tag must not throw an exception if there is no
  file, I think


To understand what's going on with bug #1, I decided to debug the plugin.
The problem occurs in AbstractAssemblyMojo.processModules (...) line 471
The getModulesFromReactor() method is invoked but with recurse set to false!

As a result when jar:pom2.0 is tested, the isProjectModule() method returns
false, which is not correct (in our case).
May be 'recurse' could be a plugin parameter?

I don't know if everybody will call this a bug, nor if this list is the
right place to report but I hope it will help.

Thanks in advance if you have any workaround.

Alexis

[jira] Commented: (MAVEN-1771) Upgrade maven-xdoc-plugin to v 1.10.1

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

Lukas Theussl commented on MAVEN-1771:
--

Not sure this is really necessary. We should only schedule plugin issues if 
they are relevant for a core release. MPXDOC-197 is is just a minor issue that 
can be fixed independently.

> Upgrade maven-xdoc-plugin to v 1.10.1
> -
>
> Key: MAVEN-1771
> URL: http://jira.codehaus.org/browse/MAVEN-1771
> Project: Maven
>  Issue Type: Sub-task
>  Components: planning
>Affects Versions: 1.1-beta-3
>Reporter: Arnaud Heritier
> Fix For: 1.1-rc1
>
>
> http://jira.codehaus.org/browse/MPXDOC?report=com.atlassian.jira.plugin.system.project:roadmap-panel

-- 
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-2464) [regression] maven 2.1 uses snapshot repository to look for plugins

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

John Casey updated MNG-2464:


Fix Version/s: 2.1

Carlos, do you know whether this is happening on the current 2.0.x branch as 
well? I'm assigning Fix For to 2.1 for now...

> [regression] maven 2.1 uses snapshot repository to look for plugins
> ---
>
> Key: MNG-2464
> URL: http://jira.codehaus.org/browse/MNG-2464
> Project: Maven 2
>  Issue Type: Bug
>  Components: Plugins and Lifecycle, Dependencies
>Affects Versions: 2.1
>Reporter: Carlos Sanchez
> Fix For: 2.1
>
> Attachments: mvn2.0.4.log, mvn2.1.log
>
>
> Building components trunk with 2.0.4 and 2.1-SNAPSHOT from 
> http://maven.zones.apache.org/~maven/builds/trunk/m2-20060724.103002.tar.gz

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

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

John Casey updated MNG-2481:


Fix Version/s: 2.0.5

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

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

[jira] Commented: (MNG-2481) project builder should make the processed project cache configurable

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

John Casey commented on MNG-2481:
-

Do you think this requires a full-blown caching solution, or will a WeakHashMap 
suffice?

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

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

[jira] Created: (MNG-2483) Review caching strategies throughout Maven for long-lived processes

Review caching strategies throughout Maven for long-lived processes
---

 Key: MNG-2483
 URL: http://jira.codehaus.org/browse/MNG-2483
 Project: Maven 2
  Issue Type: Improvement
  Components: Ant tasks, Artifacts, Artifacts and Repositories, 
Dependencies, Deployment, Embedding, General, Inheritence and Interpolation, 
Logging, maven-archiver, Performance, Plugin API, Plugin Creation Tools, Plugin 
Requests, Plugins and Lifecycle, Reactor and workspace, Repositories, Settings, 
Sites & Reporting
Affects Versions: 2.0.4, 2.0.5
Reporter: John Casey
Priority: Critical


We need to revisit all instances where Maps, etc. are used to cache data inside 
Maven (maven-artifact has some, as does maven-project, f.e.). Wherever caching 
is used, we need to apply some sort of aging and/or size-limiting 
implementation to keep Maven from chewing up massive amounts of memory in 
long-lived processes, such as IDE extensions.

-- 
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-2483) Review caching strategies throughout Maven for long-lived processes

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

John Casey updated MNG-2483:


Fix Version/s: 2.1

> Review caching strategies throughout Maven for long-lived processes
> ---
>
> Key: MNG-2483
> URL: http://jira.codehaus.org/browse/MNG-2483
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Artifacts and Repositories, Plugins and Lifecycle, 
> Plugin Creation Tools, Logging, maven-archiver, Plugin API, Ant tasks, 
> Inheritence and Interpolation, Embedding, Plugin Requests, Reactor and 
> workspace, Performance, Dependencies, Deployment, Sites & Reporting, General, 
> Repositories, Artifacts, Settings
>Affects Versions: 2.0.5, 2.0.4
>Reporter: John Casey
>Priority: Critical
> Fix For: 2.1
>
>
> We need to revisit all instances where Maps, etc. are used to cache data 
> inside Maven (maven-artifact has some, as does maven-project, f.e.). Wherever 
> caching is used, we need to apply some sort of aging and/or size-limiting 
> implementation to keep Maven from chewing up massive amounts of memory in 
> long-lived processes, such as IDE extensions.

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

Re: Assembly including binaries: Bug on a n depth hierarchy

2006-08-03 Thread Alexis Midon


I forgot to add that there is a real bug in
AbstractAssemblyMojo.isProjectModule() method.
A return statement is missing line716


   private boolean isProjectModule( String parentId, MavenProject
reactorProject, boolean recurse )
   {
   MavenProject parent = reactorProject.getParent();

   if ( parent != null )
   {
   if ( parent.getId().equals( parentId ) )
   {
   return true;
   }
   else if ( recurse )
   {
   return isProjectModule( parentId, parent, true );
   }
   }

   return false;
   }

On 8/3/06, Alexis Midon <[EMAIL PROTECTED]> wrote:



Hi all,

I have the following complex but common pom hierarchy (sample) :
The syntax is packaging:pom:level.#

 pom:pom0.0
/\
   /  \
  /\
 /  \
/\
jar:pom1.0   pom:pom1.1
/\
   /  \
  /\
 /  \
/\
 jar:pom2.0  jar:pom2.1


I'd like to use the assembly plugin to gather all the output jars in a
single directory.
(So every child/target/artifact.jar must copy to root/target/assembly/...)


To do so I execute the assemby:assembly goal with the following descriptor
:


collect-alljars

dir

 false



false





Unfortunately this always fails into an exception: "pom:pom1.1 does not
have an artifact with a file. Please ensure the package phase (...)"

This use case highlights 2 problems I think:

   1. the assembly plugin does not support n depth hierarchy
   Actually pom:pom1.1 should not be included in the module list while
   jar:pom2.0 and jar:pom2.1 should.
   2. the  tag must not throw an exception if there is no
   file, I think


To understand what's going on with bug #1, I decided to debug the plugin.
The problem occurs in AbstractAssemblyMojo.processModules (...) line 471
The getModulesFromReactor() method is invoked but with recurse set to
false!

As a result when jar:pom2.0 is tested, the isProjectModule() method
returns false, which is not correct (in our case).
May be 'recurse' could be a plugin parameter?

I don't know if everybody will call this a bug, nor if this list is the
right place to report but I hope it will help.

Thanks in advance if you have any workaround.

Alexis

[jira] Closed: (MNGECLIPSE-172) Eclipse PDE seems slightly incompatible with plugin

2006-08-03 Thread Yuri Schimke (JIRA)

 [ http://jira.codehaus.org/browse/MNGECLIPSE-172?page=all ]

Yuri Schimke closed MNGECLIPSE-172.
---

Resolution: Duplicate

duplicate of MNGECLIPSE-106

> Eclipse PDE seems slightly incompatible with plugin
> ---
>
> Key: MNGECLIPSE-172
> URL: http://jira.codehaus.org/browse/MNGECLIPSE-172
> Project: Maven 2.x Extension for Eclipse
>  Issue Type: Improvement
>Affects Versions: 0.0.9
>Reporter: Yuri Schimke
> Assigned To: Eugene Kuleshov
>
> Eclipse PDE Rich Clients seem to have trouble when using the maven plugin.
> To actually build the client application it seems to need the dependency jars 
> within the project.  To get around this we use the 
> dependency:copy-dependencies task.  However this setup stops debugging from 
> working. It also means you need to run mvn install for the other projects 
> each time before you copy the dependencies.
> In constrast, after applying the patch from MNGECLIPSE-59, non-PDE projects 
> work brilliantly.
> I'm reporting this improvement for a number of reasons 1) in case others are 
> facing the same problem, 2) in case other have solved the same problem 
> already and 3) in case it might be something you guys can fix easily.
> You guys might be the best candidates to answer 2) since you presumably use 
> Eclipse to edit the maven2 plugin anyway.
> Another option might be to make each maven JAR a valid OSGI plugin, which is 
> mainly a couple of extra files in the JAR.  This could potentially be done 
> with a MOJO that added the default, most liberal OSGI settings into the JAR.  
> But this seems a bit extreme, and also inflexible in the case of truly 
> internal dependencies.

-- 
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: (MNGECLIPSE-174) settings.xml ignored when building classpath

2006-08-03 Thread Justin Edelson (JIRA)

settings.xml ignored when building classpath


 Key: MNGECLIPSE-174
 URL: http://jira.codehaus.org/browse/MNGECLIPSE-174
 Project: Maven 2.x Extension for Eclipse
  Issue Type: Bug
Affects Versions: 0.0.10
Reporter: Justin Edelson
 Assigned To: Eugene Kuleshov
 Attachments: m2eclipse.patch

It appears that the current trunk (targetting 0.0.10) fixes most of the bugs 
related to using the user settings.xml file when running a maven 2 build. 
However, it still does not use settings.xml when building the classpath 
entries. I first encountered this problem when the parent pom was contained in 
a repository added by my settings.xml.

In any case, the solution seems to be to create a MavenEmbedRequest object with 
the user settings file and pass it to embedder.start().

Patch attached.

This did make me wonder if the plugin should lose the local repository 
preference and instead have a user settings file preference. Thoughts?

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

[jira] Commented: (MNGECLIPSE-174) settings.xml ignored when building classpath

2006-08-03 Thread Eugene Kuleshov (JIRA)

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

Eugene Kuleshov commented on MNGECLIPSE-174:


Please attach Eclipse Eclipse project, settings.xml and exact steps to 
reproduce this issue. Thanks.

> settings.xml ignored when building classpath
> 
>
> Key: MNGECLIPSE-174
> URL: http://jira.codehaus.org/browse/MNGECLIPSE-174
> Project: Maven 2.x Extension for Eclipse
>  Issue Type: Bug
>Affects Versions: 0.0.10
>Reporter: Justin Edelson
> Assigned To: Eugene Kuleshov
> Attachments: m2eclipse.patch
>
>
> It appears that the current trunk (targetting 0.0.10) fixes most of the bugs 
> related to using the user settings.xml file when running a maven 2 build. 
> However, it still does not use settings.xml when building the classpath 
> entries. I first encountered this problem when the parent pom was contained 
> in a repository added by my settings.xml.
> In any case, the solution seems to be to create a MavenEmbedRequest object 
> with the user settings file and pass it to embedder.start().
> Patch attached.
> This did make me wonder if the plugin should lose the local repository 
> preference and instead have a user settings file preference. Thoughts?

-- 
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-2464) [regression] maven 2.1 uses snapshot repository to look for plugins

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

Carlos Sanchez commented on MNG-2464:
-

IIRC 2.0.x worked fine

> [regression] maven 2.1 uses snapshot repository to look for plugins
> ---
>
> Key: MNG-2464
> URL: http://jira.codehaus.org/browse/MNG-2464
> Project: Maven 2
>  Issue Type: Bug
>  Components: Plugins and Lifecycle, Dependencies
>Affects Versions: 2.1
>Reporter: Carlos Sanchez
> Fix For: 2.1
>
> Attachments: mvn2.0.4.log, mvn2.1.log
>
>
> Building components trunk with 2.0.4 and 2.1-SNAPSHOT from 
> http://maven.zones.apache.org/~maven/builds/trunk/m2-20060724.103002.tar.gz

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

[jira] Created: (MASSEMBLY-131) Missing 'return' statement in AbstractAssemblyMojo#isProjectModule()

2006-08-03 Thread Alexis Midon (JIRA)

Missing 'return' statement in AbstractAssemblyMojo#isProjectModule()


 Key: MASSEMBLY-131
 URL: http://jira.codehaus.org/browse/MASSEMBLY-131
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Alexis Midon
 Attachments: AbstractAssemblyMojo.java

A 'return' statement is missing line 716, in 
AbstractAssemblyMojo#isProjectModule()
Check the "else if ( recurse )" close.

Path is delimited by : 
// PATCH BEGIN
// PATCH END

-- 
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: (MNGECLIPSE-174) settings.xml ignored when building classpath

2006-08-03 Thread Justin Edelson (JIRA)

 [ http://jira.codehaus.org/browse/MNGECLIPSE-174?page=all ]

Justin Edelson updated MNGECLIPSE-174:
--

Attachment: settings.xml
plugintest.zip

Basic steps to reproduce:
install this settings.xml file
ensure there's nothing in org/apache/maven/maven directory in your local 
repository
add the zipped project to your Eclipse workspace

Observe this error in the M2 console:
8/3/06 1:07:14 PM EDT: Project build error Cannot find parent: 
org.apache.maven:maven for project: test:plugintest:jar:2.1-SNAPSHOT

> settings.xml ignored when building classpath
> 
>
> Key: MNGECLIPSE-174
> URL: http://jira.codehaus.org/browse/MNGECLIPSE-174
> Project: Maven 2.x Extension for Eclipse
>  Issue Type: Bug
>Affects Versions: 0.0.10
>Reporter: Justin Edelson
> Assigned To: Eugene Kuleshov
> Attachments: m2eclipse.patch, plugintest.zip, settings.xml
>
>
> It appears that the current trunk (targetting 0.0.10) fixes most of the bugs 
> related to using the user settings.xml file when running a maven 2 build. 
> However, it still does not use settings.xml when building the classpath 
> entries. I first encountered this problem when the parent pom was contained 
> in a repository added by my settings.xml.
> In any case, the solution seems to be to create a MavenEmbedRequest object 
> with the user settings file and pass it to embedder.start().
> Patch attached.
> This did make me wonder if the plugin should lose the local repository 
> preference and instead have a user settings file preference. Thoughts?

-- 
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-1884) settings.xml in home directory/.m2/ doesn't have an effect

2006-08-03 Thread Milos Kleint (JIRA)

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

Milos Kleint commented on MNG-1884:
---

i think the stuff in trunk should work fine already, it least it is for the 
netbeans integration..


> settings.xml in home directory/.m2/ doesn't have an effect
> --
>
> Key: MNG-1884
> URL: http://jira.codehaus.org/browse/MNG-1884
> Project: Maven 2
>  Issue Type: Bug
>  Components: Embedding
> Environment: Windows XP + J2SE 1.5 + Eclipse 3.1.0
>Reporter: Simon Vos
> Assigned To: Jason van Zyl
> Fix For: 2.1
>
>
> I have to use a proxy-server to connect to the internet and for that I use a 
> settings.xml file for maven2 which is configured to use the proxy server and 
> a local remote server. This remote server is a server in our network which 
> contains our jars, ejbs, etc. and most of the packages we use to develop our 
> applications. This all works fine, but the plugin doesn't seem to keep the 
> settings.xml file into account when trying to retrieve the dependencies.
> What I tried was just putting the settings.xml file I use in my home 
> directory/.m2/, but the plugin doesn't react to that, eventhough it says it's 
> looking there when I choose to see the debug output..

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

[jira] Created: (MRELEASE-146) Release tag with SVN under Cygwin fails when sending the svn command a bad absolute path

2006-08-03 Thread Christian Gruber (JIRA)

Release tag with SVN under Cygwin fails when sending the svn command a bad
absolute path

Key: MRELEASE-146
URL: http://jira.codehaus.org/browse/MRELEASE-146
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-4
Environment: Windows XP
Reporter: Christian Gruber

When release:prepare is invoked, on a cygwin system using svn provided with
cygwin, the following error occurs.

[INFO] Checking in modified POMs...
[INFO] Executing: svn --non-interactive commit --file
E:\DOCUME~1\CGRUBE~1.DJI\LOCALS~1\Temp\maven-scm-1141263545.commit
E:/projects/israfil-fw/net.israfil.foundation-JDK1.4/pom.xml
[INFO] Working directory: E:\projects\israfil-fw\net.israfil.foundation-JDK1.4
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Unable to commit files
Provider message:
The svn command failed.
Command output:
svn:
'/projects/israfil-fw/net.israfil.foundation-JDK1.4/E:/projects/israfil-fw/net.israfil.foundation-JDK1.4'
is not a working copy
...
SVN on cygwin interprets
E:/projects/israfil-fw/net.israfil.foundation-JDK1.4/pom.xml to be
/projects/israfil-fw/net.israfil.foundation-JDK1.4/E:/projects/israfil-fw/net.israfil.foundation-JDK1.4,
essentially appending the absolute path on the current working driectory as if
it were a relative path.

This is very odd, since "svn
E:/projects/israfil-fw/net.israfil.foundation-JDK1.4" works like a charm. I
tried it with E: and e: to no avail.

Proposed solution: Use relative paths
Alternative - really really bad alternative: detect the presence of cygwin and
re-structure the file path to use /cygdrive/e/blah/blah format.
Ultimate remedy: Figure out why SVN is interpreting this way and fix in svn.

-Christian.

--
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: (MPPOM-6) Id in POM is deprecated.

2006-08-03 Thread Dennis Lundberg (JIRA)

[ http://jira.codehaus.org/browse/MPPOM-6?page=comments#action_71556 ] 

Dennis Lundberg commented on MPPOM-6:
-

I was a bit surprised by this myself, as I had had seen MAVEN-1410 being 
closed. I thought that the xsd had been changed according to the previous 
comments in that issue. I didn't realize that the pom-plugin needed to be 
changed as well.

Anyway, how about releasing a new version of the pom-plugin that is Maven 1.1 
only. This has been done with other plugins already. That new version would 
then use a new xsd, call it 3.0.1 or 3.1 or whatever, in which the id element 
is not required and artifactId/groupId is.

> Id in POM is deprecated.
> 
>
> Key: MPPOM-6
> URL: http://jira.codehaus.org/browse/MPPOM-6
> Project: maven-pom-plugin
>  Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Arnaud Heritier
>Priority: Critical
> Fix For: 1.5.1
>
>
> The pom:validate goal uses a schema which is false. The id element is 
> deprecated and replaced by groupId/artifactId.

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

[jira] Created: (JXR-21) Greather than sign not handle as predefined entity

2006-08-03 Thread Vincent Siveton (JIRA)

Greather than sign not handle as predefined entity
--

 Key: JXR-21
 URL: http://jira.codehaus.org/browse/JXR-21
 Project: Maven JXR
  Issue Type: Bug
Affects Versions: 1.1
Reporter: Vincent Siveton


Currently, the less than sign ( < ) is correctly handle:

{code}
"<" is replaced by "<"
{code}

Should be the same for greather than sign ( > ) 

-- 
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: (JXR-21) Greather than sign not handle as predefined entity

2006-08-03 Thread Vincent Siveton (JIRA)

 [ http://jira.codehaus.org/browse/JXR-21?page=all ]

Vincent Siveton updated JXR-21:
---

Attachment: JXR-21.diff

Associated patch

> Greather than sign not handle as predefined entity
> --
>
> Key: JXR-21
> URL: http://jira.codehaus.org/browse/JXR-21
> Project: Maven JXR
>  Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Vincent Siveton
> Attachments: JXR-21.diff
>
>
> Currently, the less than sign ( < ) is correctly handle:
> {code}
> "<" is replaced by "<"
> {code}
> Should be the same for greather than sign ( > ) 

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

[jira] Commented: (CONTINUUM-799) One sub module randomly appears twice after adding a parent multi-module

2006-08-03 Thread Jonathan Johnson (JIRA)

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

Jonathan Johnson commented on CONTINUUM-799:


Adam  [EMAIL PROTECTED] found that if you delete the build definitions from the 
doubled project, you should be able to delete the project then.  I tried that 
and it worked.  This is a workaround for now.


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

[jira] Commented: (MAVEN-1771) Upgrade maven-xdoc-plugin to v 1.10.1

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

Arnaud Heritier commented on MAVEN-1771:


In theory yes ;-)
You have to know that our users have the habit to take a release and to not 
update their plugins.
Why ? Because in maven 1 you can't easily update them like in maven 2.
You have to ensure that all the developers in the team use the same set of 
plugins.
It's based on my own experience I saw that several times ...
It's why the users consider we didn't make a release since september, even if 
we republished a lot of plugins

> Upgrade maven-xdoc-plugin to v 1.10.1
> -
>
> Key: MAVEN-1771
> URL: http://jira.codehaus.org/browse/MAVEN-1771
> Project: Maven
>  Issue Type: Sub-task
>  Components: planning
>Affects Versions: 1.1-beta-3
>Reporter: Arnaud Heritier
> Fix For: 1.1-rc1
>
>
> http://jira.codehaus.org/browse/MPXDOC?report=com.atlassian.jira.plugin.system.project:roadmap-panel

-- 
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] Reopened: (MAVEN-1410) pom.artifactId is missing from XML schema and pom.id should be removed

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

Arnaud Heritier reopened MAVEN-1410:


 
The Id is always mandatory in the xsd. and thus in the pom plugin

> pom.artifactId is missing from XML schema and pom.id should be removed
> --
>
> Key: MAVEN-1410
> URL: http://jira.codehaus.org/browse/MAVEN-1410
> Project: Maven
>  Issue Type: Bug
>  Components: model
>Affects Versions: 1.0
>Reporter: Dennis Lundberg
> Fix For: 1.1-beta-1
>
> Attachments: maven-project-3.xsd.patch, 
> maven-project.xsd-1_0-BRANCH.patch, xdocs-artifactId-version2.patch, 
> xdocs-artifactId.patch
>
>
> After some discussion on the dev-list "pom.id versus pom.artifactId - which 
> is correct?" there seems to be some inconsistencies in the 1.0 release.
> The discussion resulted in the following conclusions:
> 1. The element project.id should be removed from the XML schema
> 2. The element project.artifactId should be added to the XML schema
> 3. Documentation needs to be updated to reflect the above issues
> 1 and 2 should probably be done by one of the core developers, including 
> decisions regarding version numbers for the XML schema. I can make a patch 
> for it if you think that's ok.
> I can make patches for the xdocs to fix 3. On which branch should I create 
> the patches?

-- 
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: (MPPOM-6) Id in POM is deprecated.

[ http://jira.codehaus.org/browse/MPPOM-6?page=comments#action_71567 ] 

Arnaud Heritier commented on MPPOM-6:
-

I reopened MAVEN-1410

> Id in POM is deprecated.
> 
>
> Key: MPPOM-6
> URL: http://jira.codehaus.org/browse/MPPOM-6
> Project: maven-pom-plugin
>  Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Arnaud Heritier
>Priority: Critical
> Fix For: 1.5.1
>
>
> The pom:validate goal uses a schema which is false. The id element is 
> deprecated and replaced by groupId/artifactId.

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

[jira] Updated: (MRELEASE-116) Wrong SCM info put by the release plugin for modules

2006-08-03 Thread Matthew Beermann (JIRA)

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

Matthew Beermann updated MRELEASE-116:
--

Attachment: patch.txt

This is a possible fix... at the very least, it's a band-aid that appears to 
work around the problem.

> Wrong SCM info put by the release plugin for modules
> 
>
> Key: MRELEASE-116
> URL: http://jira.codehaus.org/browse/MRELEASE-116
> Project: Maven 2.x Release Plugin
>  Issue Type: Bug
>Affects Versions: 2.0-beta-4
> Environment: Sun JDK 1.5, M2 2.0.3-SNAPSHOT (2006-01-30), Subversion 
> SCM
>Reporter: Arik Kfir
> Fix For: 2.0
>
> Attachments: patch.txt
>
>
> Hi,
> I have a project with several modules in it. The entire project is
> stored in one SVN repository, in the following layout:
> myproject
>   |
>   +-- module A
>   |
>   +-- module B
>   |
>   +-- .
> The root pom has a  url like "http://svn.myserver/.../trunk/";, and each 
> sub module also has its own  tag with a url such as 
> "http://svn.myserver/.../trunk/moduleA";, etc.
> When running "release:prepare", the URL encoded back into the modules' POMs 
> (the back-to-trunk pom, not the released one) is the same URL as the root 
> POM, rather than the original module's SCM url. So module A's  urls 
> would be "http://svn.myserver/.../trunk/"; without the "moduleA" directory 
> appended to it (as it was before releasing).
> Carlos has pointed out to me that the best practice for this use case is not 
> specifying the  tag for the modules' POMs at all. He did, however, also 
> noted that it's still a bug - hence this JIRA ;-)
> Cheers.

-- 
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: (MRELEASE-116) Wrong SCM info put by the release plugin for modules

2006-08-03 Thread Matthew Beermann (JIRA)

[ http://jira.codehaus.org/browse/MRELEASE-116?page=comments#action_71569 ] 

Matthew Beermann commented on MRELEASE-116:
---

Make that band-aid for sure, because it doesn't cover the case where the 
modules are nested a couple of levels deep. I'm having a hard time finding the 
point in the code where all of the information needed for correctness (the 
items that Emmanuel mentioned) are visible.

> Wrong SCM info put by the release plugin for modules
> 
>
> Key: MRELEASE-116
> URL: http://jira.codehaus.org/browse/MRELEASE-116
> Project: Maven 2.x Release Plugin
>  Issue Type: Bug
>Affects Versions: 2.0-beta-4
> Environment: Sun JDK 1.5, M2 2.0.3-SNAPSHOT (2006-01-30), Subversion 
> SCM
>Reporter: Arik Kfir
> Fix For: 2.0
>
> Attachments: patch.txt
>
>
> Hi,
> I have a project with several modules in it. The entire project is
> stored in one SVN repository, in the following layout:
> myproject
>   |
>   +-- module A
>   |
>   +-- module B
>   |
>   +-- .
> The root pom has a  url like "http://svn.myserver/.../trunk/";, and each 
> sub module also has its own  tag with a url such as 
> "http://svn.myserver/.../trunk/moduleA";, etc.
> When running "release:prepare", the URL encoded back into the modules' POMs 
> (the back-to-trunk pom, not the released one) is the same URL as the root 
> POM, rather than the original module's SCM url. So module A's  urls 
> would be "http://svn.myserver/.../trunk/"; without the "moduleA" directory 
> appended to it (as it was before releasing).
> Carlos has pointed out to me that the best practice for this use case is not 
> specifying the  tag for the modules' POMs at all. He did, however, also 
> noted that it's still a bug - hence this JIRA ;-)
> Cheers.

-- 
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-804) Problem with continuum-webapp test and aspectj plugin

Problem with continuum-webapp test and aspectj plugin
-

 Key: CONTINUUM-804
 URL: http://jira.codehaus.org/browse/CONTINUUM-804
 Project: Continuum
  Issue Type: Sub-task
Reporter: Carlos Sanchez
 Assigned To: Jesse McConnell




-- 
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-804) Problem with continuum-webapp test and aspectj plugin