[jira] Closed: (MRM-374) Changes aren't saved when updating Archiva Managed Snapshot Repository

[Maria Odea Ching (JIRA)]

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

Maria Odea Ching closed MRM-374.


Resolution: Fixed

Fixed in -r566068

- Added the hack for the webwork checkbox in ConfigureRepositoryAction, same 
one used for 0.9-alpha-2

> Changes aren't saved when updating Archiva Managed Snapshot Repository
> --
>
> Key: MRM-374
> URL: http://jira.codehaus.org/browse/MRM-374
> Project: Archiva
>  Issue Type: Bug
>  Components: repository interface
>Reporter: Dawn Angelito
>Assignee: Maria Odea Ching
> Fix For: 1.0-beta-2
>
>
> Steps:
> 1) Log in as admin.
> 2) In the left menu, under Administration, click Repositories.
> 3) Edit Archiva Managed Snapshot Repository.
> 4) Since this is a snapshot repository, uncheck Releases Included.
> 5) Click Update Repository.
> Notice that "Releases Included" is still set to "True" for Archiva Managed 
> Snapshot Repository.

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

[jira] Closed: (MRM-407) "Scanned" is always set to true even if unchecked in the Edit Repository page

[Maria Odea Ching (JIRA)]

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

Maria Odea Ching closed MRM-407.


Resolution: Fixed

Fixed in -r566068

- Added the hack for the webwork checkbox in ConfigureRepositoryAction, same 
one used for 0.9-alpha-2

> "Scanned" is always set to true even if unchecked in the Edit Repository page
> -
>
> Key: MRM-407
> URL: http://jira.codehaus.org/browse/MRM-407
> Project: Archiva
>  Issue Type: Bug
>  Components: repository interface
>Affects Versions: 1.0-alpha-1
>Reporter: Dawn Angelito
>Assignee: Maria Odea Ching
> Fix For: 1.0-beta-2
>
>
> Steps:
> 1) Log in as admin.
> 2) In the left menu, under Administration, click Repositories.
> 3) Edit a repository.
> 4) Uncheck "Scanned".
> 5) Click Update Repository.
> Notice that "Scanned" is still set to "True" after saving.
> This is also true for "Releases Included" (see MRM-374).

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

[jira] Work started: (MRM-436) incorrect default cron expression for snapshots repository

[Maria Odea Ching (JIRA)]

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

Work on MRM-436 started by Maria Odea Ching.

> incorrect default cron expression for snapshots repository
> --
>
> Key: MRM-436
> URL: http://jira.codehaus.org/browse/MRM-436
> Project: Archiva
>  Issue Type: Bug
>Affects Versions: 1.0-beta-1
>Reporter: Brett Porter
>Assignee: Maria Odea Ching
> Fix For: 1.0-beta-2
>
>
> it is '0 0' which is not a valid value - it should probably be the same as 
> for releases

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-1386) Some data management modules use always plexus-security dependencies instead of redback

[Emmanuel Venisse (JIRA)]

Some data management modules use always plexus-security dependencies instead of 
redback
---

 Key: CONTINUUM-1386
 URL: http://jira.codehaus.org/browse/CONTINUUM-1386
 Project: Continuum
  Issue Type: Task
Affects Versions: 1.1-beta-2
Reporter: Emmanuel Venisse
 Fix For: 1.1-beta-3




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

[jira] Updated: (CONTINUUM-1386) Some data management modules use always plexus-security dependencies instead of redback

[Emmanuel Venisse (JIRA)]

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

Emmanuel Venisse updated CONTINUUM-1386:


Fix Version/s: 1.1-beta-3
  Component/s: Data Management

> Some data management modules use always plexus-security dependencies instead 
> of redback
> ---
>
> Key: CONTINUUM-1386
> URL: http://jira.codehaus.org/browse/CONTINUUM-1386
> Project: Continuum
>  Issue Type: Task
>  Components: Data Management
>Affects Versions: 1.1-beta-2
>Reporter: Emmanuel Venisse
> Fix For: 1.1-beta-3
>
>


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

[jira] Commented: (MRELEASE-124) Impossible to depend on a deployed snapshot

[Tuomas Kiviaho (JIRA)]

[ 
http://jira.codehaus.org/browse/MRELEASE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104908
 ] 

Tuomas Kiviaho commented on MRELEASE-124:
-

John Casey has written a plugin that could automate unique versioning 
.
 Blog at . Wether 
this plugin cover parent version of pom also along with dependencies is unknown 
to me.

> Impossible to depend on a deployed snapshot
> ---
>
> Key: MRELEASE-124
> URL: http://jira.codehaus.org/browse/MRELEASE-124
> Project: Maven 2.x Release Plugin
>  Issue Type: Bug
>Affects Versions: 2.0-beta-4
>Reporter: Mike Perham
>Priority: Critical
> Attachments: 
> maven-release-manager-1.0-alpha-4-SNAPSHOT.rev552741.patch, 
> maven-release-plugin-2.0-beta-7-SNAPSHOT.rev552741.patch, 
> releasePluginIgnoreSnapshot.patch, ReleaseUtils.rev552741.patch
>
>
> I have a SNAPSHOT of the war plugin that I built and deployed to fix a 
> blocker for us (MWAR-39) that has not been released.  In my POM, I refer to 
> it like this:
> 
>   
> 
>   maven-war-plugin
>   2.0.1-20060525.222101-1
> I did this specifically so the release plugin would not think it was a 
> SNAPSHOT so I could release the module.  But when I do try to release, I get 
> this error:
> [INFO] Can't release project due to non released dependencies :
> 
> org.apache.maven.plugins:maven-war-plugin:maven-plugin:2.0.1-SNAPSHOT:runtime
> in project 'UDDI WAR' (com.webify.fabric:fabric-uddi-web:war:1.1.0-SNAPSHOT)
> This is because in ArtifactUtils.isSnapshot, it specifically disallows the 
> version pattern created by the deploy plugin.
> So consider my usecase: I'm Joe Corporate, a user who needs a war bug fix in 
> their build process ASAP.  I build and deploy the latest war plugin to my 
> internal repo and reference that explicit timestamp version in my build 
> process.  Now I can understand why you disallow this because if I try to 
> build outside of our corporate walls, it will not work.  But I can't use the 
> release plugin to release either because it requires me to check the modified 
> POMs into my SCM and the war plugin is in Apache's SCM and I can't check into 
> it.
> There's only two hack workarounds I can think of: 1) explicitly reversion the 
> jar to not include SNAPSHOT or the specific timestamp pattern. 2) Check the 
> war plugin into our own SCM and release from there, effectively forking the 
> code.
> Your thoughts?  How can we fix bugs in the build process locally and still 
> use the release plugin?

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

[jira] Commented: (MASSEMBLY-211) assembly plugin and jar plugin disagree about whether to use uniqueVersion snapshot names

[John Casey (JIRA)]

[ 
http://jira.codehaus.org/browse/MASSEMBLY-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104909
 ] 

John Casey commented on MASSEMBLY-211:
--

Can you please enumerate the problems/disagreements between these two plugins, 
so we can address them? Currently, this is more of a general stylistic 
complaint than an actionable issue.

> assembly plugin and jar plugin disagree about whether to use uniqueVersion 
> snapshot names
> -
>
> Key: MASSEMBLY-211
> URL: http://jira.codehaus.org/browse/MASSEMBLY-211
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2-beta-1
>Reporter: Max Bowsher
>Priority: Blocker
> Fix For: 2.2-beta-2
>
>
> Background: Consider the following setup:
> jar-plugin configured with addClasspath=true, writing list of dependency jar 
> file names into manifest of project jar.
> assembly-plugin configured with a dependencySet pulling all dependencies into 
> a single directory.
> Result: application is runnable with with "java -jar mainartifact.jar" 
> There has long been a problem (i.e. with assembly-plugin 2.1) that when 
> deployed snapshot jars were in use, the jar and assembly plugins would 
> disagree in whether the uniqueVersion name was used, and this is MNG-2456. 
> However, assembly-plugin 2.2-beta-1 has introduced further complications to 
> the situation by not using the lifecycle's default set of resolved artifacts, 
> but by running a manual resolution of its own. This has made the two plugins 
> disagree in more scenarios than before, and broke the workaround patch that I 
> posted in MNG-2456. 
> At the root of these problems is some very peculiar handling of the 'file', 
> 'baseVersion' and 'version' fields of Artifact objects, two notable instances 
> of which are the DefaultArtifact.isSnapshot method, which despite being an 
> accessor, actually changes the state of the object, and the 
> DefaultArtifactResolver.resolve method, which contains some rather bizarre 
> manipulation of the 'file' field (more detail may comments in MNG-2456). 
> An interim fix to this issue might involve workarounds in both the jar and 
> assembly plugins to get them to agree. A true fix probably also involves 
> fixing Maven core classes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-162) In a multiproject environment, assembly takes wrong dependencies

[John Casey (JIRA)]

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

John Casey closed MASSEMBLY-162.


  Assignee: John Casey
Resolution: Fixed

It looks like this issue has been sorted out by fixing other related issues. In 
2.2-beta-1, you can eliminate the use of artifact directories using the 
literal:  (empty element).

In 2.2-beta-2-SNAPSHOT, I've changed it to be more like the 2.1 version, where 
outputFileNameMapping isn't considered when unpack == true.

> In a multiproject environment, assembly takes wrong dependencies
> 
>
> Key: MASSEMBLY-162
> URL: http://jira.codehaus.org/browse/MASSEMBLY-162
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: M. van Leeuwen
>Assignee: John Casey
>Priority: Critical
> Fix For: 2.2-beta-2
>
>
> With a projectstructure like 'Project/{ejb,war,ear,client}' packaging the 
> client as a fat jar-with-dependencies, it works fine using the following 
> configuration.
> === etc/fatjar.xml 
> fat
>   jar
>   false
>   
>   target/classes
>   /
> 
>   
> 
>   /
>   true
>   runtime
> 
>   
> 
> === pom.xml ===
> 
>   0.3-SNAPSHOT
>   4.0.0
>   mygroup
>   myapp-client
>   My Application
>   
> 
>   
> 
> 
> 
> maven-assembly-plugin
> 2.1
> 
> 
> etc/fatjar.xml
> 
> 
> path.to.MainClass
> 
> 
> 
> package
> assembly
>   
> 
> 
> 
> 
> But when I'm on the level above (packaging all) it just assembles all 
> underlying dependencies into my clientjar, and not the dependencies of the 
> childproject.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-142) Should be able to use artifact version as variable in

[John Casey (JIRA)]

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

John Casey closed MASSEMBLY-142.


  Assignee: John Casey
Resolution: Fixed

This should be fixed in 2.2-beta-2-SNAPSHOT (currently, SVN trunk). If you find 
that's incorrect, please attach a small test case displaying the problem, and 
reopen this issue.

> Should be able to use artifact version as variable in  
> 
>
> Key: MASSEMBLY-142
> URL: http://jira.codehaus.org/browse/MASSEMBLY-142
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Simon Gunzenreiner
>Assignee: John Casey
> Fix For: 2.2-beta-2
>
>
> It would be useful to be able to use the artifact version as variable in the 
>  element. If ${version} is use right now, the version of the 
> current pom is used. It seems there is no way to use the artifact version 
> 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] Commented: (MASSEMBLY-211) assembly plugin and jar plugin disagree about whether to use uniqueVersion snapshot names

[Max Bowsher (JIRA)]

[ 
http://jira.codehaus.org/browse/MASSEMBLY-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104913
 ] 

Max Bowsher commented on MASSEMBLY-211:
---

Problem: The jar plugin and the assembly plugin independently construct a list 
of artifact filenames:
 * the jar plugin builds the Class-Path manifest attribute
 * the assembly plugin builds the actual directory of jar files
They do not, in the presence of deployed uniqueVersioned snapshots, reliably 
produce the same filename. This disagreement breaks things.


> assembly plugin and jar plugin disagree about whether to use uniqueVersion 
> snapshot names
> -
>
> Key: MASSEMBLY-211
> URL: http://jira.codehaus.org/browse/MASSEMBLY-211
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2-beta-1
>Reporter: Max Bowsher
>Priority: Blocker
> Fix For: 2.2-beta-2
>
>
> Background: Consider the following setup:
> jar-plugin configured with addClasspath=true, writing list of dependency jar 
> file names into manifest of project jar.
> assembly-plugin configured with a dependencySet pulling all dependencies into 
> a single directory.
> Result: application is runnable with with "java -jar mainartifact.jar" 
> There has long been a problem (i.e. with assembly-plugin 2.1) that when 
> deployed snapshot jars were in use, the jar and assembly plugins would 
> disagree in whether the uniqueVersion name was used, and this is MNG-2456. 
> However, assembly-plugin 2.2-beta-1 has introduced further complications to 
> the situation by not using the lifecycle's default set of resolved artifacts, 
> but by running a manual resolution of its own. This has made the two plugins 
> disagree in more scenarios than before, and broke the workaround patch that I 
> posted in MNG-2456. 
> At the root of these problems is some very peculiar handling of the 'file', 
> 'baseVersion' and 'version' fields of Artifact objects, two notable instances 
> of which are the DefaultArtifact.isSnapshot method, which despite being an 
> accessor, actually changes the state of the object, and the 
> DefaultArtifactResolver.resolve method, which contains some rather bizarre 
> manipulation of the 'file' field (more detail may comments in MNG-2456). 
> An interim fix to this issue might involve workarounds in both the jar and 
> assembly plugins to get them to agree. A true fix probably also involves 
> fixing Maven core classes.

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

[jira] Commented: (MRM-476) ability to use file protocol using UNC path for Managed repository

[Patrick Gallagher (JIRA)]

[ 
http://jira.codehaus.org/browse/MRM-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104912
 ] 

Patrick Gallagher commented on MRM-476:
---

I think that Brett is right.  Treating this as a path is the right idea.  If 
you were wanting to treat the field as a java.net.URL, you could just parse the 
string input and set the host appropriately by either extracting the network 
host or using localhost for local paths.  Of course this is just for the file 
protocol but that is know from the prefix.

> ability to use file protocol using UNC path for Managed repository
> --
>
> Key: MRM-476
> URL: http://jira.codehaus.org/browse/MRM-476
> Project: Archiva
>  Issue Type: New Feature
>  Components: WebDAV interface
>Affects Versions: 1.0-beta-1
> Environment: window NT, apache tomcat 5.5, 
>Reporter: Patrick Gallagher
> Fix For: 1.0-beta-3
>
>
> Currently, if I try to use a network share with a UNC path when creating a 
> Managed Repository, the path is replaced with a newly created directory on 
> the system root.  For example, using the path of 
> file:/\\path_to_network_share gets changed to file:/C:/path_to_network share. 
>  I have tried a combination of strings for the url but have not been able to 
> connect to a network share.  

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

[jira] Updated: (MRM-265) After removing a managed repository - Browse/Search still see it

[Brett Porter (JIRA)]

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

Brett Porter updated MRM-265:
-

Fix Version/s: (was: 1.0-beta-2)
   1.0-beta-3

> After removing a managed repository - Browse/Search still see it
> 
>
> Key: MRM-265
> URL: http://jira.codehaus.org/browse/MRM-265
> Project: Archiva
>  Issue Type: Bug
>  Components: web application
>Affects Versions: 1.0-alpha-1
>Reporter: Henri Yandell
> Fix For: 1.0-beta-3
>
>
> I had a repository with lots of stuff in. I removed that (but didn't delete 
> contents), then I added a tiny repository with a couple of jars in. When I 
> goto browse and search, I still see the original, now removed, repository.
> Re-indexing didn't help [JIRA uses indexes for lists a lot, so I figured this 
> might be the case here too].

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

[jira] Updated: (MRM-397) colour inconsistencies on repository admin page

[Brett Porter (JIRA)]

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

Brett Porter updated MRM-397:
-

Fix Version/s: (was: 1.0-beta-2)
   1.0-beta-3

> colour inconsistencies on repository admin page
> ---
>
> Key: MRM-397
> URL: http://jira.codehaus.org/browse/MRM-397
> Project: Archiva
>  Issue Type: Bug
>  Components: Users/Security
>Affects Versions: 1.0-alpha-1
>Reporter: Brett Porter
>Assignee: Jesse McConnell
>Priority: Trivial
> Fix For: 1.0-beta-3
>
>
> - the grey shading seems to indicate some special property of a given 
> repository when there are just two (I presume it alternates). I don't think 
> any alternate shading is needed in boxes of this size
> - the background of the archiva logo is not transparent

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

[jira] Updated: (MRM-37) discover the deletion of artifacts

[Brett Porter (JIRA)]

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

Brett Porter updated MRM-37:


Fix Version/s: (was: 1.0-beta-2)
   1.0-beta-3

> discover the deletion of artifacts
> --
>
> Key: MRM-37
> URL: http://jira.codehaus.org/browse/MRM-37
> Project: Archiva
>  Issue Type: Improvement
>  Components: repository scanning
>Reporter: Brett Porter
> Fix For: 1.0-beta-3
>
>
> currently, the discovery mechanism is geared to walking a source repository 
> and insert into the target repository. However, there is no way to determine 
> if an artifact has been removed. We may need to track this - potentially 
> using metadata or the repository index.

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

[jira] Updated: (MRM-389) Can't log out or cancel from 'change password' page

[Brett Porter (JIRA)]

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

Brett Porter updated MRM-389:
-

Fix Version/s: (was: 1.0-beta-2)
   1.0-beta-3

> Can't log out or cancel from 'change password' page
> ---
>
> Key: MRM-389
> URL: http://jira.codehaus.org/browse/MRM-389
> Project: Archiva
>  Issue Type: Bug
>  Components: Users/Security
>Affects Versions: 1.0-alpha-1
>Reporter: Brett Porter
>Assignee: Jesse McConnell
>Priority: Minor
> Fix For: 1.0-beta-3
>
>
> 1) register a new user
> 2) click the validation link from the email
> 3) click logout
> EXPECTED: normal log out
> ACTUAL: stays on the change password page
> likewise:
> 1) register a new user
> 2) click the validation link from the email
> 3) click cancel
> EXPECTED: return to home page
> ACTUAL: stays on the change password page

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

[jira] Updated: (MRM-382) Remove index from artifacts of deleted managed repositories

[Brett Porter (JIRA)]

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

Brett Porter updated MRM-382:
-

Fix Version/s: (was: 1.0-beta-2)
   1.0-beta-3

> Remove index from artifacts of deleted managed repositories
> ---
>
> Key: MRM-382
> URL: http://jira.codehaus.org/browse/MRM-382
> Project: Archiva
>  Issue Type: Bug
>  Components: repository scanning
>Affects Versions: 1.0-alpha-1
>Reporter: Franz Allan Valencia See
> Fix For: 1.0-beta-3
>
>
> Steps to Reproduce:
> 1. Run archiva
> 2. Add managed repositories
> 3. Scan repositories
> 4. Browse
> \*.a Verify that you can see the artifacts of the added repositories
> 5. Deleted managed repositories
> 6. Browse
> \*.b Verify that you can no longer see the artifacts of the deleted 
> repositories
> 7. Add a managed repository which is empty
> 8. Scan that empty managed repository
> 9. Browse
> \*.c Verify that you can no longer see the artifacts of the deleted 
> repositories
> Results
> \*.a Correct
> \*.b Incorrect, you can still the artifacts of the deleted repositories
> \*.c Incorrect, you can still the artifacts of the deleted repositories

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

[jira] Updated: (MRM-439) No validation for 'Password' and 'Confirm Password' fields in User Management --> Create New User page

[Brett Porter (JIRA)]

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

Brett Porter updated MRM-439:
-

Fix Version/s: (was: 1.0-beta-2)
   1.0-beta-3

> No validation for 'Password' and 'Confirm Password' fields in User Management 
> --> Create New User page
> --
>
> Key: MRM-439
> URL: http://jira.codehaus.org/browse/MRM-439
> Project: Archiva
>  Issue Type: Bug
>  Components: Users/Security
>Affects Versions: 1.0-alpha-2
>Reporter: Maria Odea Ching
> Fix For: 1.0-beta-3
>
>
> See the validation for these fields during Create Admin User.

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

[jira] Updated: (MRM-204) Request for Documentation answers

[Brett Porter (JIRA)]

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

Brett Porter updated MRM-204:
-

Fix Version/s: (was: 1.0-beta-2)
   1.0-beta-3

> Request for Documentation answers
> -
>
> Key: MRM-204
> URL: http://jira.codehaus.org/browse/MRM-204
> Project: Archiva
>  Issue Type: Wish
>  Components: documentation
>Reporter: Henri Yandell
> Fix For: 1.0-beta-3
>
> Attachments: MRM-204-wsmoak1.diff
>
>
> Could somebody explain what the following mean and are used for:
> Identifiers.
> Proxied Repositories.
> Observers.

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

[jira] Updated: (MRM-185) revise logging granularity

[Brett Porter (JIRA)]

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

Brett Porter updated MRM-185:
-

Fix Version/s: (was: 1.0-beta-2)
   1.0-beta-3

> revise logging granularity
> --
>
> Key: MRM-185
> URL: http://jira.codehaus.org/browse/MRM-185
> Project: Archiva
>  Issue Type: Improvement
>  Components: system
>Reporter: Brett Porter
> Fix For: 1.0-beta-3
>
>
> in particular, check that JPOX logging is at the correct level, but generally 
> turn the noise down.

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

[jira] Closed: (MRM-382) Remove index from artifacts of deleted managed repositories

[Brett Porter (JIRA)]

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

Brett Porter closed MRM-382.


   Resolution: Duplicate
Fix Version/s: (was: 1.0-beta-3)

> Remove index from artifacts of deleted managed repositories
> ---
>
> Key: MRM-382
> URL: http://jira.codehaus.org/browse/MRM-382
> Project: Archiva
>  Issue Type: Bug
>  Components: repository scanning
>Affects Versions: 1.0-alpha-1
>Reporter: Franz Allan Valencia See
>
> Steps to Reproduce:
> 1. Run archiva
> 2. Add managed repositories
> 3. Scan repositories
> 4. Browse
> \*.a Verify that you can see the artifacts of the added repositories
> 5. Deleted managed repositories
> 6. Browse
> \*.b Verify that you can no longer see the artifacts of the deleted 
> repositories
> 7. Add a managed repository which is empty
> 8. Scan that empty managed repository
> 9. Browse
> \*.c Verify that you can no longer see the artifacts of the deleted 
> repositories
> Results
> \*.a Correct
> \*.b Incorrect, you can still the artifacts of the deleted repositories
> \*.c Incorrect, you can still the artifacts of the deleted repositories

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (DOXIA-131) HtmlTools.encodeId makes id lower case

[Lukas Theussl (JIRA)]

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

Lukas Theussl updated DOXIA-131:


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

See http://mail-archives.apache.org/mod_mbox/maven-doxia-dev/200708.mbox/[EMAIL 
PROTECTED]

> HtmlTools.encodeId makes id lower case
> --
>
> Key: DOXIA-131
> URL: http://jira.codehaus.org/browse/DOXIA-131
> Project: Maven Doxia
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0-alpha-8
>Reporter: Lukas Theussl
>Assignee: Dennis Lundberg
> Fix For: 1.0-alpha-9
>
>
> HtmlTools.encodeId uses Character.toLowerCase to convert its argument to 
> lower case. I don't see the reason for that since upper case characters are 
> legal in id's (see http://www.w3.org/TR/html4/types.html#type-name ). In 
> particular, it's a problem with anchors/links in the xhtml sink (see DOXIA-47 
> ), especially if we want to create anchors from section names, to maintain 
> backward compatibility with m1. Is there a special reason for the toLowerCase 
> or can we remove it?

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

[jira] Commented: (DOXIA-138) Review and clarify the APT guide

[Lukas Theussl (JIRA)]

[ 
http://jira.codehaus.org/browse/DOXIA-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104917
 ] 

Lukas Theussl commented on DOXIA-138:
-

I really don't like section titles as anchors. IMO, if you want to reference a 
section, you should explicitly provide an anchor.

The use of automatically constructed anchors from section titles was 
discouraged in one of the last versions of the m1 xdoc plugin [1] as it only 
led to trouble (see MPXDOC-158 and MPPDF-40 for related discussions). We will 
have the same sort of problems in doxia if we implement that, so my preference 
would be to remove this statement from the user guide.

[1] 
http://maven.apache.org/maven-1.x/plugins/xdoc/reference/xdocs.html#Referencing_sections_and_subsections

> Review and clarify the APT guide
> 
>
> Key: DOXIA-138
> URL: http://jira.codehaus.org/browse/DOXIA-138
> Project: Maven Doxia
>  Issue Type: Task
>  Components: Documentation, Module - Apt
>Affects Versions: 1.0-alpha-8
>Reporter: Lukas Theussl
> Fix For: 1.0
>
>
> Our current apt guide is a copy of 
> http://www.xmlmind.com/_aptconvert/docs/userguide2.html, but there are 
> several issues that need clarification, eg
> * case sensitivity and white space handling in anchors
> * anchors for section titles
> * figure handling, esp extensions
> * tables: is the first line always a header row?
> Some of these depend on how things are going to be implemented.
> We also decided to remove the apt guide at 
> http://maven.apache.org/guides/mini/guide-apt-format.html and only keep the 
> one on the doxia site.

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

[jira] Commented: (MAVENUPLOAD-1617) Upload cobertura 1.9 to central

[Brett Porter (JIRA)]

[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104921
 ] 

Brett Porter commented on MAVENUPLOAD-1617:
---

can we delete the 1.9 as bad and put this up as 1.9-1 then?

> Upload cobertura 1.9 to central
> ---
>
> Key: MAVENUPLOAD-1617
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1617
> Project: maven-upload-requests
>  Issue Type: Bug
>Reporter: Joakim Erdfelt
>
> Upload cobertura-1.9 to central.
> (Look for related cobertura-runtime 1.9 MAVENUPLOAD request too)

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

[jira] Created: (CONTINUUM-1387) Can't initiate a build of a new project in continuum until all modules have been checked out

[Wendy Smoak (JIRA)]

Can't initiate a build of a new project in continuum until all modules have 
been checked out


 Key: CONTINUUM-1387
 URL: http://jira.codehaus.org/browse/CONTINUUM-1387
 Project: Continuum
  Issue Type: Bug
Affects Versions: 1.1-beta-1
Reporter: Wendy Smoak


When a multi-module project is added to continuum, a working copy of each 
module is extracted from subversion.

Typically after adding a project I want to kick off a build.

If I initiate the build before all the modules are extracted, the ones that 
have not yet been fully extracted will not be queued for build. Only those 
already fully extracted will be built.

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

[jira] Commented: (MSITE-245) parent filesystem site.xml is never be found

[John Allen (JIRA)]

[ 
http://jira.codehaus.org/browse/MSITE-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104922
 ] 

John Allen commented on MSITE-245:
--

I'm not sure I exactly follow you John, I've had a look at the patch and the 
opening line in it is to remove the existing relativePath logic altogether:

{code}
-String relativePath = getRelativePath( 
siteDirectory.getAbsolutePath(), basedir.getAbsolutePath() );
{code}

When i think about this method I see a very simple purpose, namely to try and 
find a site+locale+xml file for the passed in project, and if a locale specific 
one can not be found, to assume that a default site.xml will exist. Clients of 
the method obviously know that the returned File object may or may not exist so 
it's not necessary for this methods to check for that.

Ideally we would pass in the MavenProject object we're interrogating here 
rather than it's basedir as this would provide more opportunities in the future 
to try and find the real site directory for the operand project, however as 
that is not a model parameter and is instead a configuration parameter of the 
site plugin itself, we would need a way of looking at the configuration 
settings of the site plugin for the passed in project and I don't think we have 
a ppropriate way of doing this at the moment.

This method, as you know, is used for two things. One, to get this project's 
site.xml (prefering a locale based one) and secondly to try and find other 
project's site.xml files as the client code tries to peek up the project 
inheritance hierarchy. Neither of these uses cases seem to warrant a relative 
path approach, after all there is no need to use a relative path when we have 
explicit paths to work with and, once we find the file, (or not as the case 
maybe) we instantiate a File object from it, so we loose any interest in 
whether the File object's location (i.e. the site.xml filename and path) was 
found via a relative path approach or not.

The method does have one concession to supporting a site.xml file that is being 
stored in a 'non default' location but that only comes when looking for 'this' 
project's site.xml file as we have access to this project's site plugin 
configuration. 

We could take a stance that when trying to find any project's site xml file we 
assume it will use the same site directory location that this project is using:

{code}
protected File getSiteDescriptorFile( File basedir, Locale locale )
 {
String sitePath;

if ( basedir.equals( project.getBasedir() ))
{
// it's this project's basedir so use our siteDirectory 

sitePath = siteDirectory.getAbsolutePath();
}
else
{
// it's not this project's basedir so it must be one of our parent's
// so lets assume they store their site.xml in the same location 
relative
// to their basedir as we do

   String siteRelativeDirectory = getRelativePath( 
siteDirectory.getAbsolutePath(), project.getBasedir().getAbsolutePath() );

sitePath = basedir.getAbsolutePath() + "/" + siteRelativeDirectory;
}

File siteDescriptor = new File( sitePath, "site_" + 
locale.getLanguage() + ".xml" );

if ( !siteDescriptor.exists() )
{
siteDescriptor = new File( sitePath, "site.xml" );
}

return siteDescriptor;
{code}

Thus if this project stores its site files in ${basedir}/src/foo then we will 
try and find all site.xml files in the directory src/foo. In fact we could go a 
step further and try that first and if we fail then fall back to trying the 
standard default location of src/site.

Don;t know if I've helped here:)





> parent filesystem site.xml is never be found
> 
>
> Key: MSITE-245
> URL: http://jira.codehaus.org/browse/MSITE-245
> Project: Maven 2.x Site Plugin
>  Issue Type: Bug
>Affects Versions: 2.0-beta-5
> Environment: 2.0.7
>Reporter: John Allen
>Assignee: John Casey
>Priority: Blocker
> Attachments: site-patch.txt
>
>
> The current approach used by the getSiteDescriptorFile(File, Locale) is wrong 
> as the basedir passed in to it is not just the project's own basedir, it's 
> potentially a parent project's basedir and thus the previous code makes no 
> sense as we would need to add on the parent's site.xml site directory and 
> then try and find the relative path to it and as there's no way (that I know 
> of) of a) finding that out from the parent project's object model (even if we 
> passed it in) and b) the current code does not append anything to the passed 
> in basedir so is always looking for a site.xml in the parents root directory. 
> What's more the use of a relative path here is pointless too as we simp

[jira] Issue Comment Edited: (MSITE-245) parent filesystem site.xml is never be found

[John Allen (JIRA)]

[ 
http://jira.codehaus.org/browse/MSITE-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104922
 ] 

John Allen edited comment on MSITE-245 at 8/15/07 10:49 AM:


I'm not sure I exactly follow you John, I've had a look at the patch and the 
opening line in it is to remove the existing relativePath logic altogether:

{code}
-String relativePath = getRelativePath( 
siteDirectory.getAbsolutePath(), basedir.getAbsolutePath() );
{code}

When i think about this method I see a very simple purpose, namely to try and 
find a site+locale+xml file for the passed in project, and if a locale specific 
one can not be found, to assume that a default site.xml will exist. Clients of 
the method obviously know that the returned File object may or may not exist so 
it's not necessary for this methods to check for that.

Ideally we would pass in the MavenProject object we're interrogating here 
rather than it's basedir as this would provide more opportunities in the future 
to try and find the real site directory for the operand project, however as 
that is not a model parameter and is instead a configuration parameter of the 
site plugin itself, we would need a way of looking at the configuration 
settings of the site plugin for the passed in project and I don't think we have 
a ppropriate way of doing this at the moment.

This method, as you know, is used for two things. One, to get this project's 
site.xml (prefering a locale based one) and secondly to try and find other 
project's site.xml files as the client code tries to peek up the project 
inheritance hierarchy. Neither of these uses cases seem to warrant a relative 
path approach, after all there is no need to use a relative path when we have 
explicit paths to work with and, once we find the file, (or not as the case 
maybe) we instantiate a File object from it, so we loose any interest in 
whether the File object's location (i.e. the site.xml filename and path) was 
found via a relative path approach or not.

The method does have one concession to supporting a site.xml file that is being 
stored in a 'non default' location but that only comes when looking for 'this' 
project's site.xml file as we have access to this project's site plugin 
configuration. 

We could take a stance that when trying to find any project's site xml file we 
assume it will use the same site directory location that this project is using:

{code}
protected File getSiteDescriptorFile( File basedir, Locale locale )
 {
String sitePath;

if ( basedir.equals( project.getBasedir() ))
{
// it's this project's basedir so use our siteDirectory 

sitePath = siteDirectory.getAbsolutePath();
}
else
{
// it's not this project's basedir so it must be one of our parent's
// so lets assume they store their site.xml in the same location 
relative
// to their basedir as we do

   String siteRelativeDirectory = getRelativePath( 
siteDirectory.getAbsolutePath(), project.getBasedir().getAbsolutePath() );

sitePath = basedir.getAbsolutePath() + "/" + siteRelativeDirectory;
}

File siteDescriptor = new File( sitePath, "site_" + 
locale.getLanguage() + ".xml" );

if ( !siteDescriptor.exists() )
{
siteDescriptor = new File( sitePath, "site.xml" );
}

return siteDescriptor;
{code}

Thus if this project stores its site files in ${basedir}/src/foo then we will 
try and find all site.xml files in the directory src/foo. In fact we could go a 
step further and try that first and if we fail then fall back to trying the 
standard default location of src/site.

Don't know if I've helped here:)

ps. The code block above was written in JIRA and has not been tested, its just 
for illustration




 was:
I'm not sure I exactly follow you John, I've had a look at the patch and the 
opening line in it is to remove the existing relativePath logic altogether:

{code}
-String relativePath = getRelativePath( 
siteDirectory.getAbsolutePath(), basedir.getAbsolutePath() );
{code}

When i think about this method I see a very simple purpose, namely to try and 
find a site+locale+xml file for the passed in project, and if a locale specific 
one can not be found, to assume that a default site.xml will exist. Clients of 
the method obviously know that the returned File object may or may not exist so 
it's not necessary for this methods to check for that.

Ideally we would pass in the MavenProject object we're interrogating here 
rather than it's basedir as this would provide more opportunities in the future 
to try and find the real site directory for the operand project, however as 
that is not a model parameter and is instead a configuration parameter of the 
site plugin itself, we would need a way of looking at t

[jira] Commented: (MAVENUPLOAD-1617) Upload cobertura 1.9 to central

[Carlos Sanchez (JIRA)]

[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104923
 ] 

Carlos Sanchez commented on MAVENUPLOAD-1617:
-

seems that I misunderstood Joakim and the one in the repo is not the one he 
provided, so I need to take a look first.

> Upload cobertura 1.9 to central
> ---
>
> Key: MAVENUPLOAD-1617
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1617
> Project: maven-upload-requests
>  Issue Type: Bug
>Reporter: Joakim Erdfelt
>
> Upload cobertura-1.9 to central.
> (Look for related cobertura-runtime 1.9 MAVENUPLOAD request too)

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

[jira] Commented: (CONTINUUM-1387) Can't initiate a build of a new project in continuum until all modules have been checked out

[Emmanuel Venisse (JIRA)]

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

Emmanuel Venisse commented on CONTINUUM-1387:
-

Actually, it isn't a bug but a normal way ;)

The project that isn't fully extracted is in the queue but when you initiate 
the build, Continuum check if each project is in the que. If it is, Continuum 
skip it.

We'll look at it if we can improve the process.

> Can't initiate a build of a new project in continuum until all modules have 
> been checked out
> 
>
> Key: CONTINUUM-1387
> URL: http://jira.codehaus.org/browse/CONTINUUM-1387
> Project: Continuum
>  Issue Type: Bug
>Affects Versions: 1.1-beta-1
>Reporter: Wendy Smoak
>
> When a multi-module project is added to continuum, a working copy of each 
> module is extracted from subversion.
> Typically after adding a project I want to kick off a build.
> If I initiate the build before all the modules are extracted, the ones that 
> have not yet been fully extracted will not be queued for build. Only those 
> already fully extracted will be built.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MRM-480) the NOTICE file is overzealous in declaring dependencies

[Brett Porter (JIRA)]

the NOTICE file is overzealous in declaring dependencies


 Key: MRM-480
 URL: http://jira.codehaus.org/browse/MRM-480
 Project: Archiva
  Issue Type: Improvement
Affects Versions: 1.0-beta-1
Reporter: Brett Porter
 Fix For: 1.0-beta-2


we only need to say, for example, software developed by the ASF once, and all 
the unnamed ones don't need to be there.

This might require fixes in the remote reosurces plugin and an update.

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

[jira] Moved: (CONTINUUM-1388) the NOTICE file is overzealous in declaring dependencies

[Brett Porter (JIRA)]

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

Brett Porter moved MRM-480 to CONTINUUM-1388:
-

Affects Version/s: (was: 1.0-beta-1)
   1.1-beta-2
Fix Version/s: (was: 1.0-beta-2)
   1.1-beta-3
   Complexity: Intermediate
  Key: CONTINUUM-1388  (was: MRM-480)
  Project: Continuum  (was: Archiva)

> the NOTICE file is overzealous in declaring dependencies
> 
>
> Key: CONTINUUM-1388
> URL: http://jira.codehaus.org/browse/CONTINUUM-1388
> Project: Continuum
>  Issue Type: Improvement
>Affects Versions: 1.1-beta-2
>Reporter: Brett Porter
> Fix For: 1.1-beta-3
>
>
> we only need to say, for example, software developed by the ASF once, and all 
> the unnamed ones don't need to be there.
> This might require fixes in the remote reosurces plugin and an update.

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

[jira] Issue Comment Edited: (MSITE-245) parent filesystem site.xml is never be found

[John Allen (JIRA)]

[ 
http://jira.codehaus.org/browse/MSITE-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104922
 ] 

John Allen edited comment on MSITE-245 at 8/15/07 11:10 AM:


I'm not sure I exactly follow you John, I've had a look at the patch and the 
opening line in it is to remove the existing relativePath logic altogether:

{code}
-String relativePath = getRelativePath( 
siteDirectory.getAbsolutePath(), basedir.getAbsolutePath() );
{code}

When i think about this method I see a very simple purpose, namely to try and 
find a site+locale+xml file for the passed in project, and if a locale specific 
one can not be found, to assume that a default site.xml will exist. Clients of 
the method obviously know that the returned File object may or may not exist so 
it's not necessary for this methods to check for that.

Ideally we would pass in the MavenProject object we're interrogating here 
rather than it's basedir as this would provide more opportunities in the future 
to try and find the real site directory for the operand project, however as 
that is not a model parameter and is instead a configuration parameter of the 
site plugin itself, we would need a way of looking at the configuration 
settings of the site plugin for the passed in project and I don't think we have 
a ppropriate way of doing this at the moment.

This method, as you know, is used for two things. One, to get this project's 
site.xml (prefering a locale based one) and secondly to try and find other 
project's site.xml files as the client code tries to peek up the project 
inheritance hierarchy. Neither of these uses cases seem to warrant a relative 
path approach, after all there is no need to use a relative path when we have 
explicit paths to work with and, once we find the file, (or not as the case 
maybe) we instantiate a File object from it, so we loose any interest in 
whether the File object's location (i.e. the site.xml filename and path) was 
found via a relative path approach or not.

The method does have one concession to supporting a site.xml file that is being 
stored in a 'non default' location but that only comes when looking for 'this' 
project's site.xml file as we have access to this project's site plugin 
configuration. 

We could take a stance that when trying to find any project's site xml file we 
assume it will use the same site directory location that this project is using:

{code}
protected File getSiteDescriptorFile( File basedir, Locale locale )
 {
String sitePath;

if ( basedir.equals( project.getBasedir() ))
{
// it's this project's basedir so use our siteDirectory 

sitePath = siteDirectory.getAbsolutePath();
}
else
{
// it's not this project's basedir so it must be one of our parent's
// so lets assume they store their site.xml in the same location 
relative
// to their basedir as we do

   String ourRelativeSiteDirectory = 
siteDirectory.getAbsolutePath().substring(
0, project.getBasedir().getAbsolutePath().length() );

   sitePath = basedir.getAbsolutePath() + "/" + 
ourRelativeSiteDirectory;
}  

File siteDescriptor = new File( sitePath, "site_" + 
locale.getLanguage() + ".xml" );

if ( !siteDescriptor.exists() )
{
siteDescriptor = new File( sitePath, "site.xml" );
}

return siteDescriptor;
{code}

Thus if this project stores its site files in ${basedir}/src/foo then we will 
try and find all site.xml files in the directory src/foo. In fact we could go a 
step further and try that first and if we fail then fall back to trying the 
standard default location of src/site.

Don't know if I've helped here:)

ps. The code block above was written in JIRA and has not been tested, its just 
for illustration




 was:
I'm not sure I exactly follow you John, I've had a look at the patch and the 
opening line in it is to remove the existing relativePath logic altogether:

{code}
-String relativePath = getRelativePath( 
siteDirectory.getAbsolutePath(), basedir.getAbsolutePath() );
{code}

When i think about this method I see a very simple purpose, namely to try and 
find a site+locale+xml file for the passed in project, and if a locale specific 
one can not be found, to assume that a default site.xml will exist. Clients of 
the method obviously know that the returned File object may or may not exist so 
it's not necessary for this methods to check for that.

Ideally we would pass in the MavenProject object we're interrogating here 
rather than it's basedir as this would provide more opportunities in the future 
to try and find the real site directory for the operand project, however as 
that is not a model parameter and is instead a configuration parameter of the 
site p

[jira] Created: (CONTINUUM-1389) ability to reduce per-group notifications

[Brett Porter (JIRA)]

ability to reduce per-group notifications
-

 Key: CONTINUUM-1389
 URL: http://jira.codehaus.org/browse/CONTINUUM-1389
 Project: Continuum
  Issue Type: Improvement
  Components: Notification Subsystem
Affects Versions: 1.1-beta-2
Reporter: Brett Porter


for group notifiers, don't send a mail if another build is scheduled in the 
group already (instead, have the results added to the mail for that group). 
Make this a configurable option, on the group notifier itself. Default is off 
for consistency with current behaviour.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-1390) ability to add a message throttle for identical messages

[Brett Porter (JIRA)]

ability to add a message throttle for identical messages


 Key: CONTINUUM-1390
 URL: http://jira.codehaus.org/browse/CONTINUUM-1390
 Project: Continuum
  Issue Type: Improvement
  Components: Integration - Shell, Notification Subsystem
Affects Versions: 1.1-beta-2
Reporter: Brett Porter


add a throttle on messages, particularly for errors - don't send a message that 
is identical to one sent in the last X hours.

Trying to avoid the mass-spamming when a service goes down (but ensure some 
notification does go out). As soon as the error state is reset to good, another 
message can be sent, but if it is already in error it shouldn't (currently, it 
does it every time, and alwaysSend is not granular enough).

On the flipside - I sometimes don't see errors ever get notified (or only once, 
and then they are stuck in error). We should re-send if something remains in 
error after a certain duration.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-2871) Subartifact (ejb-client for example) are not reselved as active project artifacts

[Piotr Tabor (JIRA)]

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

Piotr Tabor commented on MNG-2871:
--

Chris, could you check if your problem is resolved with current (SVN/SNAPSHOT) 
version of maven-jar-plugin. 
I hope MJAR-75 that was fixed, resolved this issue too. 

Thank you

> Subartifact (ejb-client for example) are not reselved as active project 
> artifacts
> -
>
> Key: MNG-2871
> URL: http://jira.codehaus.org/browse/MNG-2871
> Project: Maven 2
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 2.0.4, 2.0.5
> Environment: Not platform dependent
>Reporter: Piotr Tabor
>Assignee: John Casey
> Fix For: 2.1-alpha-1
>
> Attachments: MavenProject.java, MNG-2871-core-integration-tests.diff, 
> root.tar
>
>
> I have prepared simple project to show the bug.
> It contains three artifacts: 
> |-root
> \--- ejb3
> \--- client
> Client depends on ejb3 with ejb-client.
> The local and remote repository must not contain those artifacts. 
> When I do "mvn -X compile" (or even integration-tests) on root project I will
> get those errors: 
> ...
> [DEBUG] Configuring mojo 
> 'org.apache.maven.plugins:maven-resources-plugin:2.2:resources' -->
> [DEBUG] (f) filters = []
> [DEBUG] (f) outputDirectory = /home/ptab/m2/bug/root/client/target/classes
> [DEBUG] (f) project = [EMAIL PROTECTED]
> [DEBUG] (f) resources = [EMAIL PROTECTED]
> [DEBUG] -- end configuration --
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [DEBUG] pl.waw.tabor:client:jar:1.0-SNAPSHOT (selected for null)
> [DEBUG] junit:junit:jar:3.8.1:test (selected for test)
> [DEBUG] pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT:compile (selected 
> for compile)
> [DEBUG] Skipping disabled repository Newitech-repository
> [DEBUG] Skipping disabled repository central
> [DEBUG] ejb3: using locally installed snapshot
> [DEBUG] Trying repository Newitech-snapshots-repository
> Downloading: 
> scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar
> [WARNING] Unable to get resource 
> 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository 
> Newitech-snapshots-repository 
> (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots)
> [DEBUG] Skipping disabled repository Newitech-repository
> [DEBUG] Trying repository Newitech-publiczne
> Downloading: 
> scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne//pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar
> [WARNING] Unable to get resource 
> 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository 
> Newitech-publiczne 
> (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/)
> [DEBUG] Trying repository Maven Snapshots
> Downloading: 
> http://people.apache.org/maven-snapshot-repository/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar
> [WARNING] Unable to get resource 
> 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Maven 
> Snapshots (http://people.apache.org/maven-snapshot-repository)
> [DEBUG] Trying repository codehausSnapshots
> Downloading: 
> http://snapshots.maven.codehaus.org/maven2/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar
> [WARNING] Unable to get resource 
> 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository 
> codehausSnapshots (http://snapshots.maven.codehaus.org/maven2)
> [DEBUG] Skipping disabled repository central
> [DEBUG] Unable to download the artifact from any repository
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=pl.waw.tabor -DartifactId=ejb3 \
> -Dversion=1.0-SNAPSHOT -Dpackaging=ejb-client -Dfile=/path/to/file
> Path to dependency:
> 1) pl.waw.tabor:client:jar:1.0-SNAPSHOT
> 2) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT
> pl.waw.tabor:ejb3:ejb-client:1.0-SNAPSHOT
> from the specified remote repositories:
> Maven Snapshots (http://people.apache.org/maven-snapshot-repository),
> central (http://repo1.maven.org/maven2),
> codehausSnapshots (http://snapshots.maven.codehaus.org/maven2),
> Newitech-snapshots-repository 
> (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots),
> Newitech-publiczne 
> (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/),
> Newitech-repository 
> (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech)
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Failed to resolve artifact.
> Missing

[jira] Commented: (MNG-3043) Allow 'mvn test' to work with test-jar dependencies in a reactor

[Piotr Tabor (JIRA)]

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

Piotr Tabor commented on MNG-3043:
--

Kenney, could you check if your problem is resolved with current (SVN/SNAPSHOT) 
version of maven-jar-plugin. 
I hope MJAR-75 that was fixed, resolved this issue too. 

Thank you

> Allow 'mvn test' to work with test-jar dependencies in a reactor
> 
>
> Key: MNG-3043
> URL: http://jira.codehaus.org/browse/MNG-3043
> Project: Maven 2
>  Issue Type: Bug
>  Components: Dependencies, Reactor and workspace
>Affects Versions: 2.0.6, 2.0.7, 2.1
>Reporter: Kenney Westerhof
> Fix For: Reviewed Pending Version Assignment
>
>
> Basically the issue is demonstrated by MNG-2045, but instead of running 'mvn 
> install', you run 'mvn test'.
> Test classes of dependencies should be resolved from the reactor, just as 
> main classes, if there's no archive available.
> I'm not sure how to go about this. Specifying a dependency on something with 
> test-jar,
> and having that dependency declare the maven-jar-plugin with the 'test-jar' 
> goal is insufficient.
> Perhaps we can just add a standard classifier that maven is aware of, in this 
> case 'tests'. The jar packaging
> would export this as a known classifier, and tells maven how it contributes 
> to what classpath.
> Since test sources are a first class citizen, just as main sources are (they 
> have the same phases, same
> elements in the pom (but differently named)).
> It seems logical to me that somehow the test classes should be made available 
> to dependencies,
> if they declare a dependency with classifier 'tests'.

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

[jira] Commented: (MAVENUPLOAD-1617) Upload cobertura 1.9 to central

[Joakim Erdfelt (JIRA)]

[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104931
 ] 

Joakim Erdfelt commented on MAVENUPLOAD-1617:
-

The one in the repo is bad, and/or suspect.
It is not the official binary. 
No idea where it came from.

Brett's solution has merit.
Eliminate the bad/suspect binary, and create a new version 1.9-1 with the 
correct binary.

Do you need a new bundle created for that? (new MAVENUPLOAD request too)

> Upload cobertura 1.9 to central
> ---
>
> Key: MAVENUPLOAD-1617
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1617
> Project: maven-upload-requests
>  Issue Type: Bug
>Reporter: Joakim Erdfelt
>
> Upload cobertura-1.9 to central.
> (Look for related cobertura-runtime 1.9 MAVENUPLOAD request too)

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

[jira] Created: (MCHANGELOG-75) plugin uses artifactId in multi module builds, regardeless of the module name

[werner mueller (JIRA)]

plugin uses artifactId in multi module builds, regardeless of the module name
-

 Key: MCHANGELOG-75
 URL: http://jira.codehaus.org/browse/MCHANGELOG-75
 Project: Maven 2.x Changelog Plugin
  Issue Type: Improvement
Affects Versions: 2.0
 Environment: linux, java 1.4, maven 2.0.7
Reporter: werner mueller


hallo

in a multi-module build, when the changelog plugin is configured within the 
parent pom the location in scm is created using the artifactId. In our projects 
the actual modules are not named like this.

we have:
parentpom.xml
 - module.a.core.stuff (artifactId module-a-core-stuff)
 - module.b.core.things (artifactId module-b-core-stuff)
 - ...

the parent pom contains the modules section referring to the modules with 
module.a.core.stuff (the actual folder name)

the changelog plugin will use the artifactId to look up changes in scm, which 
will create a wrong path (http://localhost/trunk/module-a-core-stuff instead of 
http://localhost/trunk/module.a.core.stuff)

i would like some configuration option in the parent pom to define what name 
shall be used (${project.artifactId} or ${project.name} for example). so the 
module name can be matched if it is not the same as the artifactId.

thanks :)

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

[jira] Updated: (MAVENUPLOAD-1666) upload vraptor 2.4

[Fabio Kung (JIRA)]

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

Fabio Kung updated MAVENUPLOAD-1666:


Attachment: org.vraptor.sh

Done, thanks. We now have a syncing repo at http://www.vraptor.org/maven

Please take the attached sync script.

> upload vraptor 2.4
> --
>
> Key: MAVENUPLOAD-1666
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1666
> Project: maven-upload-requests
>  Issue Type: Task
>Reporter: Fabio Kung
> Attachments: org.vraptor.sh
>
>
> upload vraptor 2.2
> file: http://www.vraptor.org/vraptor-2.2-bundle.jar
> project: http://www.vraptor.org
> team: http://www.vraptor.org/team-list.html
> VRaptor 2.2 framework update with many improvements and new docs.
>  
>  VRaptor 2 is a mvc controller based on the idea (stolen) from Rails
>  that configuration should be minimal and conventions should be
>  maximized.

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

[jira] Created: (MAVENUPLOAD-1673) Upload Unitils 1.0 rc 4

[Tim Ducheyne (JIRA)]

Upload Unitils 1.0 rc 4
---

 Key: MAVENUPLOAD-1673
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1673
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Tim Ducheyne


Could you please upload the unitils-1.0-rc-4 bundle?

Thank you,
Tim

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-76) don't check the test code

[Dennis Lundberg (JIRA)]

[ 
http://jira.codehaus.org/browse/MCHECKSTYLE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104942
 ] 

Dennis Lundberg commented on MCHECKSTYLE-76:


Are you saying that the checkstyle plugin is *not* checking your test sources? 
But that you expect it to do so?

Can you please provide a pom.xml that shows us the configuration that you used.

> don't check the test code
> -
>
> Key: MCHECKSTYLE-76
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-76
> Project: Maven 2.x Checkstyle Plugin
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: windos, standar conf projet (juste parent pom)
>Reporter: kerboriou christophe
>Priority: Critical
> Fix For: 2.2
>
>
> the parm for excute checkstyle on test code was at true. and i have this log
> {panel} [DEBUG] Configuring mojo 
> 'org.apache.maven.plugins:maven-checkstyle-plugin:2.1:checkstyle' -->
> [DEBUG]   (f) cacheFile = 
> D:\workspaces\workspace\{sous-projet}\target/checkstyle-cachefile
> [DEBUG]   (f) configLocation = http://///checkstyle_config.xml
> [DEBUG]   (f) consoleOutput = false
> [DEBUG]   (f) enableFilesSummary = true
> [DEBUG]   (f) enableRSS = true
> [DEBUG]   (f) enableRulesSummary = true
> [DEBUG]   (f) enableSeveritySummary = true
> [DEBUG]   (f) failsOnError = false
> [DEBUG]   (f) format = sun
> [DEBUG]   (f) headerFile = D:\workspaces\workspace\{sous-projet}\LICENSE.txt
> [DEBUG]   (f) headerLocation = LICENSE.txt
> [DEBUG]   (f) includes = **/*.java
> [DEBUG]   (f) linkXRef = true
> [DEBUG]   (f) outputDirectory = 
> D:\workspaces\workspace\{sous-projet}\target\site
> [DEBUG]   (f) outputFile = 
> D:\workspaces\workspace\{sous-projet}\target\checkstyle-result.xml
> [DEBUG]   (f) outputFileFormat = xml
> [DEBUG]   (f) project = [EMAIL PROTECTED]
> [DEBUG]   {color:red} *(f) sourceDirectory = 
> D:\workspaces\workspace\{sous-projet}\src\main\java*{color}
> [DEBUG]   (f) xrefLocation = 
> D:\workspaces\workspace\{sous-projet}\target\site\xref
> [DEBUG] -- end configuration --
> [INFO] [checkstyle:checkstyle]
> [DEBUG] resolveLocation(http://///checkstyle_config.xml, 
> checkstyle-checker.xml)
> [DEBUG] Potential URL: http://///checkstyle_config.xml
> [DEBUG] resolveLocation(null, checkstyle-checker.properties)
> [DEBUG] resolveLocation(LICENSE.txt, checkstyle-header.txt)
> [DEBUG] Location is not a URL.
> [DEBUG] Location is not a File.
> [DEBUG] Potential Resource: 
> jar:file:/C:/dev/maven/bin/../lib/jsch-0.1.24.jar!/LICENSE.txt
> [DEBUG] resolveLocation(null, checkstyle-packages.xml)
> [DEBUG] resolveLocation(null, checkstyle-suppressions.xml)
> [DEBUG] File D:\workspaces\workspace\{sous-projet}\target\site/checkstyle.rss 
> created...{panel}
> the src/test/java wasn't use.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MCHANGELOG-75) plugin uses artifactId in multi module builds, regardeless of the module name

[Dennis Lundberg (JIRA)]

[ 
http://jira.codehaus.org/browse/MCHANGELOG-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104943
 ] 

Dennis Lundberg commented on MCHANGELOG-75:
---

I think that this issue really belongs in maven-scm, but first let us see if it 
hasn't been fixed already.

Please upgrade to version 2.1 of maven-changelog-plugin and try again. It has 
lots of fixes and, most importantly, uses maven-scm-1.0.

> plugin uses artifactId in multi module builds, regardeless of the module name
> -
>
> Key: MCHANGELOG-75
> URL: http://jira.codehaus.org/browse/MCHANGELOG-75
> Project: Maven 2.x Changelog Plugin
>  Issue Type: Improvement
>Affects Versions: 2.0
> Environment: linux, java 1.4, maven 2.0.7
>Reporter: werner mueller
>
> hallo
> in a multi-module build, when the changelog plugin is configured within the 
> parent pom the location in scm is created using the artifactId. In our 
> projects the actual modules are not named like this.
> we have:
> parentpom.xml
>  - module.a.core.stuff (artifactId module-a-core-stuff)
>  - module.b.core.things (artifactId module-b-core-stuff)
>  - ...
> the parent pom contains the modules section referring to the modules with 
> module.a.core.stuff (the actual folder name)
> the changelog plugin will use the artifactId to look up changes in scm, which 
> will create a wrong path (http://localhost/trunk/module-a-core-stuff instead 
> of http://localhost/trunk/module.a.core.stuff)
> i would like some configuration option in the parent pom to define what name 
> shall be used (${project.artifactId} or ${project.name} for example). so the 
> module name can be matched if it is not the same as the artifactId.
> thanks :)

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

[jira] Updated: (MASSEMBLY-222) 2.2-beta-1 regression in assembly descriptor interpolation

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-222:
-

Fix Version/s: 2.2-beta-2

We probably need a richer expression syntax to resolve this. At times, it's 
desirable to include info from each included dependency artifact in this sort 
of field, instead of using the information from the project. I'll plan on 
implementing this as ${pom.version} for project info, ${artifact.version} for 
artifact info, and make ${version} point to ${pom.version} for backward compat.

> 2.2-beta-1 regression in assembly descriptor interpolation
> --
>
> Key: MASSEMBLY-222
> URL: http://jira.codehaus.org/browse/MASSEMBLY-222
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2-beta-1
>Reporter: Max Bowsher
>Priority: Blocker
> Fix For: 2.2-beta-2
>
>
> I have found a significant change in behaviour between 2.1 and 2.2-beta-1, 
> using the following assembly descriptor:
> {code:xml}
> 
>   dist
>   
> tar.gz
>   
>   no
>   
> 
>   /foobar-${version}
>   
> README.txt
> changelog.txt
> java.policy
>   
> 
> 
>   target
>   /foobar-${version}/jars
>   
> foobar-${version}.jar
>   
> 
> 
>   src/main/scripts
>   /foobar-${version}/bin
>   0755
> 
>   
>   
> 
>   /foobar-${version}/jars
>   false
> 
>   
> 
> {code}
> Using 2.1, ${version} interpolates with the version of the project being 
> assembled.
> Using 2.2-beta-1, the ${version} in the  interpolates with the 
> version of each individual dependency, leading to the  being 
> scattered across many directories.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-66) Ability to index into a nominated dependency JAR to identify files to include in the assembly (Im thinking .so/.dll etc)

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-66:


Priority: Major  (was: Critical)

> Ability to index into a nominated dependency JAR to identify files to include 
> in the assembly (Im thinking .so/.dll etc)
> 
>
> Key: MASSEMBLY-66
> URL: http://jira.codehaus.org/browse/MASSEMBLY-66
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Improvement
> Environment: Linux, x86_64, x86, win32
>Reporter: Andy Brook
>
> Im trying to bundle a SWT application, I'm almost there, the only thing 
> missing is the ability to include .so files in the assembly that are 
> currently stored inside a dependancy.  As far as I can tell there is no neat 
> way to pull a few files out of a given dependency...
> My example is the SWT libraries, the GTK linux specific JAR in the eclipse 
> bundle also contain the native libraries.  Ive renamed this to fit into a 
> maven2 repository, but really dont want to have to copy the files manually.
> Ideally, I would like to be able to specify the dependency in mind and extend 
> the fileSet element to allow the context of the include to work only within 
> that dependency.
> If there is something Im missing and this can be done with existing plugins 
> Id like to hear about it!
> eg:
> ::POM::
>
> 
>   org.eclipse.swt
>   gtk-linux-x86
>   3.1.1
>   runtime
> 
> ::assembly-descriptor.xml::
> 
>   
>   org.eclipse.swt:gtk-linux-x86:3.1.1
>   /lib
>   
>   *.so
>   
> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-209) Service provider configuration files should be concatenated instead of overwritten

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-209:
-

Fix Version/s: 2.2-beta-2

> Service provider configuration files should be concatenated instead of 
> overwritten
> --
>
> Key: MASSEMBLY-209
> URL: http://jira.codehaus.org/browse/MASSEMBLY-209
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Improvement
>Affects Versions: 2.1, 2.2-beta-1
>Reporter: Arjohn Kampman
> Fix For: 2.2-beta-2
>
>
> Service provider configuration files are text files that define what "service 
> providers" are available for a specific interface. These files are normally 
> stored in /META-INF/services/ and are named after the interface that is 
> implemented (e.g. "java.io.spi.CharCodec"). See for more info:
> http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Service%20Provider
> and
> http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html
> Building a onejar from a multi-module project where multiple modules have 
> similarly named services files results in a jar-file that includes just one 
> of the service files. As a result, just the providers that are mentioned in 
> that file are seen by applications running from the onejar, providers that 
> were mentioned in the other service files are not. To fix this, service files 
> with identical names should simply be concatenated (making sure that there's 
> a newline between the contents of each service file).

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

[jira] Commented: (MASSEMBLY-66) Ability to index into a nominated dependency JAR to identify files to include in the assembly (Im thinking .so/.dll etc)

[John Casey (JIRA)]

[ 
http://jira.codehaus.org/browse/MASSEMBLY-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104953
 ] 

John Casey commented on MASSEMBLY-66:
-

Have you tried unpackOptions in the 2.2-beta-1 version of the assembly plugin 
to do this? I'm not sure if it's wired in yet, but I have plans to support this 
(either already, or in the relatively near future).

> Ability to index into a nominated dependency JAR to identify files to include 
> in the assembly (Im thinking .so/.dll etc)
> 
>
> Key: MASSEMBLY-66
> URL: http://jira.codehaus.org/browse/MASSEMBLY-66
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Improvement
> Environment: Linux, x86_64, x86, win32
>Reporter: Andy Brook
>Priority: Critical
>
> Im trying to bundle a SWT application, I'm almost there, the only thing 
> missing is the ability to include .so files in the assembly that are 
> currently stored inside a dependancy.  As far as I can tell there is no neat 
> way to pull a few files out of a given dependency...
> My example is the SWT libraries, the GTK linux specific JAR in the eclipse 
> bundle also contain the native libraries.  Ive renamed this to fit into a 
> maven2 repository, but really dont want to have to copy the files manually.
> Ideally, I would like to be able to specify the dependency in mind and extend 
> the fileSet element to allow the context of the include to work only within 
> that dependency.
> If there is something Im missing and this can be done with existing plugins 
> Id like to hear about it!
> eg:
> ::POM::
>
> 
>   org.eclipse.swt
>   gtk-linux-x86
>   3.1.1
>   runtime
> 
> ::assembly-descriptor.xml::
> 
>   
>   org.eclipse.swt:gtk-linux-x86:3.1.1
>   /lib
>   
>   *.so
>   
> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-176) Assembly goal does not handle ear files with zip format

[John Casey (JIRA)]

[ 
http://jira.codehaus.org/browse/MASSEMBLY-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104951
 ] 

John Casey commented on MASSEMBLY-176:
--

If you can attach a failing project example (the whole project, so we can 
include it as an integration-test), I'll try to take a look.

> Assembly goal does not handle ear files with zip format
> ---
>
> Key: MASSEMBLY-176
> URL: http://jira.codehaus.org/browse/MASSEMBLY-176
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
> Environment: Windows Server 2003 Enterprise Edition
>Reporter: Gary Tilden
>Priority: Blocker
>
> When using the assembly goal and creating a zip file with a dependency on an 
> ear the ear is lost when installed.
> However, when the directory-inline goal is used the ear is included, but with 
> a file name that has extra characters.  I don't know if the ZIP format  has a 
> problem with ear files. Another reason could be that the ear is currently a 
> SNAPSHOT version.
> I haven't found any documentation on this issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-176) Assembly goal does not handle ear files with zip format

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-176:
-

Priority: Major  (was: Blocker)

this does not affect enough of the assembly plugin use cases to be a blocker. 
There's no real evidence that it ever worked, for example, so it also wouldn't 
seem to be a regression.

> Assembly goal does not handle ear files with zip format
> ---
>
> Key: MASSEMBLY-176
> URL: http://jira.codehaus.org/browse/MASSEMBLY-176
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
> Environment: Windows Server 2003 Enterprise Edition
>Reporter: Gary Tilden
>
> When using the assembly goal and creating a zip file with a dependency on an 
> ear the ear is lost when installed.
> However, when the directory-inline goal is used the ear is included, but with 
> a file name that has extra characters.  I don't know if the ZIP format  has a 
> problem with ear files. Another reason could be that the ear is currently a 
> SNAPSHOT version.
> I haven't found any documentation on this issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-209) Service provider configuration files should be concatenated instead of overwritten

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-209:
-

Fix Version/s: (was: 2.2-beta-2)
   2.2

> Service provider configuration files should be concatenated instead of 
> overwritten
> --
>
> Key: MASSEMBLY-209
> URL: http://jira.codehaus.org/browse/MASSEMBLY-209
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Improvement
>Affects Versions: 2.1, 2.2-beta-1
>Reporter: Arjohn Kampman
> Fix For: 2.2
>
>
> Service provider configuration files are text files that define what "service 
> providers" are available for a specific interface. These files are normally 
> stored in /META-INF/services/ and are named after the interface that is 
> implemented (e.g. "java.io.spi.CharCodec"). See for more info:
> http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Service%20Provider
> and
> http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html
> Building a onejar from a multi-module project where multiple modules have 
> similarly named services files results in a jar-file that includes just one 
> of the service files. As a result, just the providers that are mentioned in 
> that file are seen by applications running from the onejar, providers that 
> were mentioned in the other service files are not. To fix this, service files 
> with identical names should simply be concatenated (making sure that there's 
> a newline between the contents of each service file).

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

[jira] Closed: (MASSEMBLY-208) Assembly plugin does not resolve version ranges correctly

[John Casey (JIRA)]

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

John Casey closed MASSEMBLY-208.


 Assignee: John Casey
   Resolution: Duplicate
Fix Version/s: 2.2-beta-2

This is an issue with Maven in general. It belongs in the MNG project (I think 
I've already seen it there, so I'm closing this one.)

> Assembly plugin does not resolve version ranges correctly
> -
>
> Key: MASSEMBLY-208
> URL: http://jira.codehaus.org/browse/MASSEMBLY-208
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: XP Pro SP2
>Reporter: David Hoffer
>Assignee: John Casey
> Fix For: 2.2-beta-2
>
>
> Similar to MRELEASE-134 in maven-release-plugin
> [1.1.0,)
> This version range can resolve to the latest dev SNAPSHOT.  The assembly 
> plugin should ignore SNAPSHOTS as that is not intended by the unbounded high 
> end of the version range.
> This document:
> http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges
> addressed the requirements for version ranges and stated that "Resolution of 
> dependency ranges should not resolve to a snapshot (development version) 
> unless it is included as an explicit boundary". I think this requirement was 
> forgetten when version ranges were implemented.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-190) Problem with dependency conflict resolution on multi-module project

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-190:
-

Fix Version/s: 2.2

> Problem with dependency conflict resolution on multi-module project
> ---
>
> Key: MASSEMBLY-190
> URL: http://jira.codehaus.org/browse/MASSEMBLY-190
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2
> Environment: Using maven 2.0.5 and assembly 2.2-SNAPSHOT
>Reporter: Frédéric ESNAULT
> Fix For: 2.2
>
>
> Hi,
> I'm trying to use the assembly plugin to gather all the jars of my project, 
> including all dependencies.
> As the project is composed of several modules, I use a descriptor which looks 
> like this :
> 
>   bin
>   
>   zip
>   
>   false
>   
>   
>   
>   /
>   false
>   true
>   
>   
>   
> 
> It seems to work fine at first sight - it creates a zip containing all the 
> jar files. However, I find in the archive several instances of the same 
> dependency with differents versions, for instance asm-1.5.3 and asm-2.2.3. 
> This is a surprise as maven is supposed to take care of conflict resolution.
> When I look at a detailed trace, it appears that conflict resolution is done 
> but on each module independently. But my modules are intended to work 
> together and I expect to get an assembly with only one version of each 
> dependency found on the whole set of mudules. It seems to me that conflict 
> resolution is not managed properly in this use case.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-159) Add FAQ about building multi-module assemblies from the top using Maven 2.0

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-159:
-

  Description: 
John's post about why 'assembly:assembly' needs to be run separately with Maven 
2.0 should be adapted for the FAQ.

http://www.nabble.com/Re%3A-building-assemblies-from-the-top-level-project-directory-p4735063.html

Related Threads:
   
http://www.nabble.com/Attaching-an-assembly-to-a-multi-module-project-t2608001s177.html
   
http://www.nabble.com/HOWTO%3A-Have-assembly-plugin-call-package-automatically-before-doing-assembly--t2542444s177.html

  was:

John's post about why 'assembly:assembly' needs to be run separately with Maven 
2.0 should be adapted for the FAQ.

http://www.nabble.com/Re%3A-building-assemblies-from-the-top-level-project-directory-p4735063.html

Related Threads:
   
http://www.nabble.com/Attaching-an-assembly-to-a-multi-module-project-t2608001s177.html
   
http://www.nabble.com/HOWTO%3A-Have-assembly-plugin-call-package-automatically-before-doing-assembly--t2542444s177.html

Fix Version/s: 2.2

> Add FAQ about building multi-module assemblies from the top using Maven 2.0
> ---
>
> Key: MASSEMBLY-159
> URL: http://jira.codehaus.org/browse/MASSEMBLY-159
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Improvement
>Affects Versions: 2.1
> Environment: Maven 2.0
>Reporter: Wendy Smoak
> Fix For: 2.2
>
>
> John's post about why 'assembly:assembly' needs to be run separately with 
> Maven 2.0 should be adapted for the FAQ.
> http://www.nabble.com/Re%3A-building-assemblies-from-the-top-level-project-directory-p4735063.html
> Related Threads:
>
> http://www.nabble.com/Attaching-an-assembly-to-a-multi-module-project-t2608001s177.html
>
> http://www.nabble.com/HOWTO%3A-Have-assembly-plugin-call-package-automatically-before-doing-assembly--t2542444s177.html

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

[jira] Updated: (MASSEMBLY-185) When using different parent and aggregator poms, the assembly plugin does not package the ModuleSets of the aggregator modules

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-185:
-

Fix Version/s: 2.2

> When using different parent and aggregator poms, the assembly plugin does not 
> package the ModuleSets of the aggregator modules
> --
>
> Key: MASSEMBLY-185
> URL: http://jira.codehaus.org/browse/MASSEMBLY-185
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Peter De Velder
> Fix For: 2.2
>
>
> As mentioned on http://maven.apache.org/pom.html#Aggregation (see: A final 
> note on Inheritance v. Aggregation), the aggregator project and parent 
> project are conceptually not the same and can be split physically into 2 
> different projects. In the example below, the aggregProj just groups 
> ChildProj1 and ChildProj2 in it's  definition, while the ChildProj 
> poms do NOT reference aggregProj, but they both refer to parentProj in their 
> 
> aggregProj
>   +-- ChildProj1  --> parentProj
>   +-- ChildProj2  --> parentProj
> mvn clean package assembly:assembly 
> in this case the ChildProj artifacts are not packaged, although they are 
> referenced in the   of the aggregProj
> In other words if  the  of aggregProj differs from the 
>  in the ChildProjX  definitions, the packaging is 
> incorrect.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-223) 2-nd element of : doesn't work

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-223:
-

Fix Version/s: 2.2-beta-2

> 2-nd  element of : doesn't work
> --
>
> Key: MASSEMBLY-223
> URL: http://jira.codehaus.org/browse/MASSEMBLY-223
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2-beta-1
>Reporter: Eugene Voytitsky
> Fix For: 2.2-beta-2
>
> Attachments: MASSEMBLY-223.patch
>
>
> I suppose that order of dependencySets:excludes:exclude doesn't make sense.
> But it seems that the plugin has a bug -- 2-nd  element of 
> : doesn't work at all!
> Having such a dependencySet
> 
> false
> 
> org.eclipse.update.*
> org.eclipse.equinox.http.*
> 
> 
> I receive warning about 
> [WARNING] The following patterns were never triggered in this artifact 
> exclusion filter:
> o  'org.eclipse.equinox.http.*'
> When I change the order of exclude elements
> 
> false
> 
> org.eclipse.equinox.http.*
> org.eclipse.update.*
> 
> 
> I receive warning about 
> [WARNING] The following patterns were never triggered in this artifact 
> exclusion filter:
> o  'org.eclipse.update.*'
> So, as you can see the both exclude patterns are workable, but 2-nd one 
> doesn't work independently of the element order.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-223) 2-nd element of : doesn't work

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-223:
-

Patch Submitted: [Yes]

> 2-nd  element of : doesn't work
> --
>
> Key: MASSEMBLY-223
> URL: http://jira.codehaus.org/browse/MASSEMBLY-223
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2-beta-1
>Reporter: Eugene Voytitsky
> Fix For: 2.2-beta-2
>
> Attachments: MASSEMBLY-223.patch
>
>
> I suppose that order of dependencySets:excludes:exclude doesn't make sense.
> But it seems that the plugin has a bug -- 2-nd  element of 
> : doesn't work at all!
> Having such a dependencySet
> 
> false
> 
> org.eclipse.update.*
> org.eclipse.equinox.http.*
> 
> 
> I receive warning about 
> [WARNING] The following patterns were never triggered in this artifact 
> exclusion filter:
> o  'org.eclipse.equinox.http.*'
> When I change the order of exclude elements
> 
> false
> 
> org.eclipse.equinox.http.*
> org.eclipse.update.*
> 
> 
> I receive warning about 
> [WARNING] The following patterns were never triggered in this artifact 
> exclusion filter:
> o  'org.eclipse.update.*'
> So, as you can see the both exclude patterns are workable, but 2-nd one 
> doesn't work independently of the element order.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-185) When using different parent and aggregator poms, the assembly plugin does not package the ModuleSets of the aggregator modules

[John Casey (JIRA)]

[ 
http://jira.codehaus.org/browse/MASSEMBLY-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104955
 ] 

John Casey commented on MASSEMBLY-185:
--

If you can attach a sample project structure where this is failing, it'll 
greatly improve the likelihood of getting this fixed sooner rather than later. 
I'd like to capture these things in the integration tests for this plugin.

> When using different parent and aggregator poms, the assembly plugin does not 
> package the ModuleSets of the aggregator modules
> --
>
> Key: MASSEMBLY-185
> URL: http://jira.codehaus.org/browse/MASSEMBLY-185
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Peter De Velder
> Fix For: 2.2
>
>
> As mentioned on http://maven.apache.org/pom.html#Aggregation (see: A final 
> note on Inheritance v. Aggregation), the aggregator project and parent 
> project are conceptually not the same and can be split physically into 2 
> different projects. In the example below, the aggregProj just groups 
> ChildProj1 and ChildProj2 in it's  definition, while the ChildProj 
> poms do NOT reference aggregProj, but they both refer to parentProj in their 
> 
> aggregProj
>   +-- ChildProj1  --> parentProj
>   +-- ChildProj2  --> parentProj
> mvn clean package assembly:assembly 
> in this case the ChildProj artifacts are not packaged, although they are 
> referenced in the   of the aggregProj
> In other words if  the  of aggregProj differs from the 
>  in the ChildProjX  definitions, the packaging is 
> incorrect.

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

[jira] Work started: (MASSEMBLY-223) 2-nd element of : doesn't work

[John Casey (JIRA)]

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

Work on MASSEMBLY-223 started by John Casey.

> 2-nd  element of : doesn't work
> --
>
> Key: MASSEMBLY-223
> URL: http://jira.codehaus.org/browse/MASSEMBLY-223
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2-beta-1
>Reporter: Eugene Voytitsky
>Assignee: John Casey
> Fix For: 2.2-beta-2
>
> Attachments: MASSEMBLY-223.patch
>
>
> I suppose that order of dependencySets:excludes:exclude doesn't make sense.
> But it seems that the plugin has a bug -- 2-nd  element of 
> : doesn't work at all!
> Having such a dependencySet
> 
> false
> 
> org.eclipse.update.*
> org.eclipse.equinox.http.*
> 
> 
> I receive warning about 
> [WARNING] The following patterns were never triggered in this artifact 
> exclusion filter:
> o  'org.eclipse.equinox.http.*'
> When I change the order of exclude elements
> 
> false
> 
> org.eclipse.equinox.http.*
> org.eclipse.update.*
> 
> 
> I receive warning about 
> [WARNING] The following patterns were never triggered in this artifact 
> exclusion filter:
> o  'org.eclipse.update.*'
> So, as you can see the both exclude patterns are workable, but 2-nd one 
> doesn't work independently of the element order.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-3150) Command line -f option should propagate to module poms.

[Paul Gier (JIRA)]

Command line -f option should propagate to module poms.
---

 Key: MNG-3150
 URL: http://jira.codehaus.org/browse/MNG-3150
 Project: Maven 2
  Issue Type: Improvement
  Components: Command Line
Reporter: Paul Gier


I have a multi module project where I would like to have parrallel builds.  The 
default pom.xml build would be using jdk1.5 or jdk6, and the parrallel build 
pom would be for creating retro compiled jdk14 artifacts.  So the pom for this 
build would be "pom-jdk14.xml".  I've explored other options such as using a 
classifier for the retro translated artifact, and using profiles to choose 
between jdk1.5 and jdk1.4 builds.  But both of these have problems that I can't 
get around without a lot of difficulty.

Using two separate poms works great for me for a single module project, but for 
a multi module project, I have no way to tell the modules to pick up a 
different pom.xml file.

So for my multi module build I would like to be able to say
mvn -f pom-jdk14.xml install

And each module should then look for it's own pom-jdk14.xml.  This could be 
made into the default behaviour of the "-f" option, or a new option could be 
introduced like "-fg" to use the other pom file globally across all the module.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-76) [assembly plugin] improve or clarify inheriting/reusing descriptors

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-76:


Fix Version/s: 2.2

> [assembly plugin] improve or clarify inheriting/reusing descriptors
> ---
>
> Key: MASSEMBLY-76
> URL: http://jira.codehaus.org/browse/MASSEMBLY-76
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Improvement
>Reporter: Jacob Robertson
> Fix For: 2.2
>
>
> I want to declare a new reusable assembly descriptor.  Then, in my parent pom 
> I can reference that descriptor, and all children projects will be able to do 
> assembly:assembly without specifying the descriptor.  This actually works 
> halfway, but then the assembly plugin can't find the descriptor - because it 
> doesn't live inside of the child project.  I was trying to play around with 
> putting the descriptor in the parent project, but since the packaging has to 
> be "pom" that of course wouldn't work.
> Unless I misunderstand, the way this currently works, I'd have to declare the 
> descriptor for each and every child project.  Which would be very 
> unfortunate, since the 3 supplied predefined descriptors don't meet my needs.
> If there is a way to do this, then the improvement request is to improve the 
> documentation for this since I couldn't figure it out...

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

[jira] Updated: (MASSEMBLY-139) Not all information from parent available in plugin?

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-139:
-

Fix Version/s: 2.2

> Not all information from parent available in plugin?
> 
>
> Key: MASSEMBLY-139
> URL: http://jira.codehaus.org/browse/MASSEMBLY-139
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Ernst Lindoorn
> Fix For: 2.2
>
> Attachments: project.zip
>
>
> In a multimodule project, it seems that not all information of the parent 
> project is passed (or otherwise available) in the assembly plugin.
> Given the attached minimalist setup, I echo the project.parent.name / version 
> and project.name / version.
> During mvn assembly:assembly it seems the project.parent.name variable is not 
> available, while the version is.
> Output: 
>  [echo] Outputting some variables
>  [echo] `-> project.parent: ${project.parent.name} - 1.0-SNAPSHOT
>  [echo] `-> project: Module Name - 0.5-SNAPSHOT
> Instead of the expected:
>  [echo] Outputting some variables
>  [echo] `-> project.parent: Project Name - 1.0-SNAPSHOT
>  [echo] `-> project: Module Name - 0.5-SNAPSHOT

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

[jira] Updated: (MASSEMBLY-189) plugin not correctly interpolating POM variables like project.build.directory

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-189:
-

Fix Version/s: 2.2

> plugin not correctly interpolating POM variables like project.build.directory
> -
>
> Key: MASSEMBLY-189
> URL: http://jira.codehaus.org/browse/MASSEMBLY-189
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: I used both released version 2.1 and also 2.2-SNAPSHOT
>Reporter: Ray Suliteanu
>Priority: Critical
> Fix For: 2.2
>
>
> I have a assembly descriptor file with ${project.build.directory} in the 
>  element of a . I get an error "Failed to create assembly: File 
> to filter not found" because the file path has "${project.build.directory}" 
> rather than the value of ${project.build.directory}.
> I have traced the problem to AssemblyInterpolator.interpolateElementValue(). 
> It tries to look up build.directory in ReflectionValueExtractor.evaluate() 
> rather than project.build.directory, and it can't evaluate build.directory. A 
> hack workaround is ...
>   if (value == null)
>   {
> try
> {
>   value = ReflectionValueExtractor.evaluate(realExpr, project);
>   if (value == null)
>   {
> // HACK: strip ${ and } and retry
> wholeExpr = wholeExpr.substring(2, wholeExpr.length() - 1);
> value = ReflectionValueExtractor.evaluate(wholeExpr, project);
>   }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-165) Test error on Windows XP + Cygwin

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-165:
-

Fix Version/s: 2.2

> Test error on Windows XP + Cygwin
> -
>
> Key: MASSEMBLY-165
> URL: http://jira.codehaus.org/browse/MASSEMBLY-165
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2
> Environment: Windows XP + Cygwin
>Reporter: Wendy Smoak
> Fix For: 2.2
>
> Attachments: 
> org.apache.maven.plugin.assembly.archive.ManifestCreationFinalizerTest.txt
>
>
> Building maven-assembly-plugin, I consistently get an error in 
> ManifestCreationFinalizerTest because it can't delete a file:
> ---
> Test set: 
> org.apache.maven.plugin.assembly.archive.ManifestCreationFinalizerTest
> ---
> Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.078 sec <<< 
> FAILURE!
> testShouldAddManifestWhenArchiverIsJarArchiver(org.apache.maven.plugin.assembly.archive.ManifestCreationFinalizerTest)
>   Time elapsed: 0.046 sec  <<< ERROR!
> java.io.IOException: File 
> c:\DOCUME~1\wsmoak\LOCALS~1\Temp\manifest-finalizer.test.1165893085085\MANIFEST.MF
>  unable to be deleted.
> Test output w/ full stack trace is attached.

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

[jira] Updated: (MASSEMBLY-45) Support for mappers in assembly desriptors

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-45:


Fix Version/s: 2.2

> Support for mappers in assembly desriptors
> --
>
> Key: MASSEMBLY-45
> URL: http://jira.codehaus.org/browse/MASSEMBLY-45
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Reporter: Anuerin Diaz
>Assignee: John Casey
> Fix For: 2.2
>
> Attachments: maven-assembly-plugin.patch
>
>
> I would like to forward a wish to have the assembly plugin support the notion 
> of file mappers similar to the ones in Ant[1]. To illustrate, assuming a 
> multi-module project with the following layout:
>  Root
>|-Module1
>|-Module2
>|-Container
>|  |-Module3
>|  |-Module4
>|-Module5
>|- pom.xml
> and an assembly desriptor entry for the contained modules like this
>   
>  
> Container
> 
> 
>   **/target/*.jar
> 
>  
>   
> The assembly plugin will be able to get all jar files produced by Module3 and 
> Module4 but the "Container//target" structure will still be 
> included. One workaround is to enumerate each  artifact but 
> problematic if the number of contained sub-modules is numerous. Support for 
> filemappers which  look like this:
>   
>  
> Container
> 
> 
>   **/target/*.jar
> 
>   
>  
>   
> will cause all contained jar files to be copied without their original 
> structure. This feature would be useful for globbing artifact names as well 
> as for physically organizing project structures according to type.
> [1] http://ant.apache.org/manual/CoreTypes/mapper.html

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

[jira] Commented: (MECLIPSE-132) "Class not found" when run/debug JUnit tests

[james obrien (JIRA)]

[ 
http://jira.codehaus.org/browse/MECLIPSE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104957
 ] 

james obrien commented on MECLIPSE-132:
---

Dude, can someone please fix this.  It's killing me.
I can't junit my projects.  My productivity is down the drain.
Thanks,
--jim


> "Class not found" when run/debug JUnit tests
> 
>
> Key: MECLIPSE-132
> URL: http://jira.codehaus.org/browse/MECLIPSE-132
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Bug
>  Components: dependency resolution
> Environment: gentoo linux 2006, kernel 2.6, sun-jdk-1.5.0.06, maven 
> 2.0.4, eclipse sdk 3.2, myeclipse 5 m2
>Reporter: Diego Ballve
> Attachments: maven-sample.zip
>
>
> This is for the behavior described in
> http://www.nabble.com/Keep-getting-%22Class-not-found%22-when-running-debugging-JUnit-tests-tf1851758.html#a5442440
> You get "Class not found" when running/debuging JUnit tests.
> For me it happened when I was importing another project and its dependencies 
> (both m2 projects).
> Clean compile works fine, problem is with run.
> The workaround to get it working is:
> In the project containing your tests, edit Java Build Path | Order and 
> Export: Make sure M2 Dependencies appears BEFORE JRE System Library. 
> Thanks,
> Diego

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-211) assembly plugin and jar plugin disagree about whether to use uniqueVersion snapshot names

[Matthew McCullough (JIRA)]

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

Matthew McCullough updated MASSEMBLY-211:
-

Attachment: CSMDirectoryListingOfJars.txt

This is a directory listing of the JARs that are pulled by assembly:assembly 
for comparison to the manifest which I'm also attaching which is produced by 
jar:jar for the same project.

> assembly plugin and jar plugin disagree about whether to use uniqueVersion 
> snapshot names
> -
>
> Key: MASSEMBLY-211
> URL: http://jira.codehaus.org/browse/MASSEMBLY-211
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2-beta-1
>Reporter: Max Bowsher
>Priority: Blocker
> Fix For: 2.2-beta-2
>
> Attachments: CSMDirectoryListingOfJars.txt
>
>
> Background: Consider the following setup:
> jar-plugin configured with addClasspath=true, writing list of dependency jar 
> file names into manifest of project jar.
> assembly-plugin configured with a dependencySet pulling all dependencies into 
> a single directory.
> Result: application is runnable with with "java -jar mainartifact.jar" 
> There has long been a problem (i.e. with assembly-plugin 2.1) that when 
> deployed snapshot jars were in use, the jar and assembly plugins would 
> disagree in whether the uniqueVersion name was used, and this is MNG-2456. 
> However, assembly-plugin 2.2-beta-1 has introduced further complications to 
> the situation by not using the lifecycle's default set of resolved artifacts, 
> but by running a manual resolution of its own. This has made the two plugins 
> disagree in more scenarios than before, and broke the workaround patch that I 
> posted in MNG-2456. 
> At the root of these problems is some very peculiar handling of the 'file', 
> 'baseVersion' and 'version' fields of Artifact objects, two notable instances 
> of which are the DefaultArtifact.isSnapshot method, which despite being an 
> accessor, actually changes the state of the object, and the 
> DefaultArtifactResolver.resolve method, which contains some rather bizarre 
> manipulation of the 'file' field (more detail may comments in MNG-2456). 
> An interim fix to this issue might involve workarounds in both the jar and 
> assembly plugins to get them to agree. A true fix probably also involves 
> fixing Maven core classes.

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

[jira] Issue Comment Edited: (MASSEMBLY-211) assembly plugin and jar plugin disagree about whether to use uniqueVersion snapshot names

[Matthew McCullough (JIRA)]

[ 
http://jira.codehaus.org/browse/MASSEMBLY-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104959
 ] 

Matthew McCullough edited comment on MASSEMBLY-211 at 8/15/07 5:59 PM:
---

I'm seeing this problem on Maven 2.0.7

Because of MDEPLOY-57, I end up getting unique versions of JARs in my 
repository even when I have explicitly declared 
false

Thus, this ripples and is made even worse by MASSEMBLY-211 because now my 
assembly:assembly pulls unique versioned jars into the assembly (ZIP), but the 
jar:jar command (when told to write a mainfest with a main class and classpath) 
points to all the non-unique-versioned jars.

Thus, the classpath on the jar's manifest points to (for example) 
ccbs-config-common-server-1.0.M2.jar while the actual zip pulled down by 
assembly:assembly is ccbs-config-common-server-1.0.M2-20070814.152448-16.jar

Thus, the application cannot be executed.


 was:
Because of MDEPLOY-57, I end up getting unique versions of JARs in my 
repository even when I have explicitly declared 
false

Thus, this ripples and is made even worse by MASSEMBLY-211 because now my 
assembly:assembly pulls unique versioned jars into the assembly (ZIP), but the 
jar:jar command (when told to write a mainfest with a main class and classpath) 
points to all the non-unique-versioned jars.

Thus, the classpath on the jar's manifest points to (for example) 
ccbs-config-common-server-1.0.M2.jar while the actual zip pulled down by 
assembly:assembly is ccbs-config-common-server-1.0.M2-20070814.152448-16.jar

Thus, the application cannot be executed.

> assembly plugin and jar plugin disagree about whether to use uniqueVersion 
> snapshot names
> -
>
> Key: MASSEMBLY-211
> URL: http://jira.codehaus.org/browse/MASSEMBLY-211
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2-beta-1
>Reporter: Max Bowsher
>Priority: Blocker
> Fix For: 2.2-beta-2
>
> Attachments: CSMDirectoryListingOfJars.txt, CSMJarManifest.txt
>
>
> Background: Consider the following setup:
> jar-plugin configured with addClasspath=true, writing list of dependency jar 
> file names into manifest of project jar.
> assembly-plugin configured with a dependencySet pulling all dependencies into 
> a single directory.
> Result: application is runnable with with "java -jar mainartifact.jar" 
> There has long been a problem (i.e. with assembly-plugin 2.1) that when 
> deployed snapshot jars were in use, the jar and assembly plugins would 
> disagree in whether the uniqueVersion name was used, and this is MNG-2456. 
> However, assembly-plugin 2.2-beta-1 has introduced further complications to 
> the situation by not using the lifecycle's default set of resolved artifacts, 
> but by running a manual resolution of its own. This has made the two plugins 
> disagree in more scenarios than before, and broke the workaround patch that I 
> posted in MNG-2456. 
> At the root of these problems is some very peculiar handling of the 'file', 
> 'baseVersion' and 'version' fields of Artifact objects, two notable instances 
> of which are the DefaultArtifact.isSnapshot method, which despite being an 
> accessor, actually changes the state of the object, and the 
> DefaultArtifactResolver.resolve method, which contains some rather bizarre 
> manipulation of the 'file' field (more detail may comments in MNG-2456). 
> An interim fix to this issue might involve workarounds in both the jar and 
> assembly plugins to get them to agree. A true fix probably also involves 
> fixing Maven core classes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-211) assembly plugin and jar plugin disagree about whether to use uniqueVersion snapshot names

[Matthew McCullough (JIRA)]

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

Matthew McCullough updated MASSEMBLY-211:
-

Attachment: CSMJarManifest.txt

For comparison to CSMDirectoryListingOfJars.txt  List of jars in the executable 
JAR manifest produced by JAR:JAR does not match the list of JARs pulled by 
ASSEMBLY:ASSEMBLY

> assembly plugin and jar plugin disagree about whether to use uniqueVersion 
> snapshot names
> -
>
> Key: MASSEMBLY-211
> URL: http://jira.codehaus.org/browse/MASSEMBLY-211
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2-beta-1
>Reporter: Max Bowsher
>Priority: Blocker
> Fix For: 2.2-beta-2
>
> Attachments: CSMDirectoryListingOfJars.txt, CSMJarManifest.txt
>
>
> Background: Consider the following setup:
> jar-plugin configured with addClasspath=true, writing list of dependency jar 
> file names into manifest of project jar.
> assembly-plugin configured with a dependencySet pulling all dependencies into 
> a single directory.
> Result: application is runnable with with "java -jar mainartifact.jar" 
> There has long been a problem (i.e. with assembly-plugin 2.1) that when 
> deployed snapshot jars were in use, the jar and assembly plugins would 
> disagree in whether the uniqueVersion name was used, and this is MNG-2456. 
> However, assembly-plugin 2.2-beta-1 has introduced further complications to 
> the situation by not using the lifecycle's default set of resolved artifacts, 
> but by running a manual resolution of its own. This has made the two plugins 
> disagree in more scenarios than before, and broke the workaround patch that I 
> posted in MNG-2456. 
> At the root of these problems is some very peculiar handling of the 'file', 
> 'baseVersion' and 'version' fields of Artifact objects, two notable instances 
> of which are the DefaultArtifact.isSnapshot method, which despite being an 
> accessor, actually changes the state of the object, and the 
> DefaultArtifactResolver.resolve method, which contains some rather bizarre 
> manipulation of the 'file' field (more detail may comments in MNG-2456). 
> An interim fix to this issue might involve workarounds in both the jar and 
> assembly plugins to get them to agree. A true fix probably also involves 
> fixing Maven core classes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MECLIPSE-132) "Class not found" when run/debug JUnit tests

[james obrien (JIRA)]

[ 
http://jira.codehaus.org/browse/MECLIPSE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104962
 ] 

james obrien commented on MECLIPSE-132:
---

I was able to fix by running "update source folders" on all related projects.

> "Class not found" when run/debug JUnit tests
> 
>
> Key: MECLIPSE-132
> URL: http://jira.codehaus.org/browse/MECLIPSE-132
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Bug
>  Components: dependency resolution
> Environment: gentoo linux 2006, kernel 2.6, sun-jdk-1.5.0.06, maven 
> 2.0.4, eclipse sdk 3.2, myeclipse 5 m2
>Reporter: Diego Ballve
> Attachments: maven-sample.zip
>
>
> This is for the behavior described in
> http://www.nabble.com/Keep-getting-%22Class-not-found%22-when-running-debugging-JUnit-tests-tf1851758.html#a5442440
> You get "Class not found" when running/debuging JUnit tests.
> For me it happened when I was importing another project and its dependencies 
> (both m2 projects).
> Clean compile works fine, problem is with run.
> The workaround to get it working is:
> In the project containing your tests, edit Java Build Path | Order and 
> Export: Make sure M2 Dependencies appears BEFORE JRE System Library. 
> Thanks,
> Diego

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-223) 2-nd element of : doesn't work

[John Casey (JIRA)]

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

John Casey closed MASSEMBLY-223.


Resolution: Fixed

Applied, and added unit tests to verify that this is fixed. Thanks!

> 2-nd  element of : doesn't work
> --
>
> Key: MASSEMBLY-223
> URL: http://jira.codehaus.org/browse/MASSEMBLY-223
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2-beta-1
>Reporter: Eugene Voytitsky
>Assignee: John Casey
> Fix For: 2.2-beta-2
>
> Attachments: MASSEMBLY-223.patch
>
>
> I suppose that order of dependencySets:excludes:exclude doesn't make sense.
> But it seems that the plugin has a bug -- 2-nd  element of 
> : doesn't work at all!
> Having such a dependencySet
> 
> false
> 
> org.eclipse.update.*
> org.eclipse.equinox.http.*
> 
> 
> I receive warning about 
> [WARNING] The following patterns were never triggered in this artifact 
> exclusion filter:
> o  'org.eclipse.equinox.http.*'
> When I change the order of exclude elements
> 
> false
> 
> org.eclipse.equinox.http.*
> org.eclipse.update.*
> 
> 
> I receive warning about 
> [WARNING] The following patterns were never triggered in this artifact 
> exclusion filter:
> o  'org.eclipse.update.*'
> So, as you can see the both exclude patterns are workable, but 2-nd one 
> doesn't work independently of the element order.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-205) Files mapped anywhere under META-INF ignored

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-205:
-

Fix Version/s: 2.2

> Files mapped anywhere under META-INF ignored
> 
>
> Key: MASSEMBLY-205
> URL: http://jira.codehaus.org/browse/MASSEMBLY-205
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2-beta-1
>Reporter: Eric Redmond
> Fix For: 2.2
>
>
> In an assembly descriptor moving a components.xml file under META-INF is 
> ignored
>   
> 
>   ${basedir}/src/main/components/xstream-components.xml
>   components.xml
>   /META-INF/plexus
>   true
> 
>   
> However, moving anywhere else, such as /meta-inf/plexus (lowercase) works 
> file.

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

[jira] Updated: (MASSEMBLY-202) Silent failure: declared with multiple includes

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-202:
-

Fix Version/s: 2.2

> Silent failure:  declared with multiple includes
> ---
>
> Key: MASSEMBLY-202
> URL: http://jira.codehaus.org/browse/MASSEMBLY-202
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2-beta-1
> Environment: java version "1.5.0_09"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_09-b01, mixed mode)
>Reporter: Graham Leggett
> Fix For: 2.2
>
>
> When attempting to add a dependency to an assembly _without_ unpacking the 
> dependency using the following snippet of assembly, the dependecies are 
> silently ignored:
> 
>   
>   
>   
> alchemy:alchemy-quant:jar:${os-platform}
> alchemy:alchemy-quant:ctf:${os-platform}
>   
>   false
>   runtime
> 
> It turns out the above config makes no sense - multiple dependencies match 
> the includes rule, and yet an outputFileNameMapping has been defined, which 
> only makes sense when it matches a single include line.
> In this case a proper error message needs to be thrown to explain that when 
> outputFileNameMapping is present, only one include can be present. Currently 
> assembly succeeds silently while doing nothing, causing much confusion.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-228) UnpackOptions filtered does not work

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-228:
-

Fix Version/s: 2.2

> UnpackOptions filtered does not work
> 
>
> Key: MASSEMBLY-228
> URL: http://jira.codehaus.org/browse/MASSEMBLY-228
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2-beta-1
> Environment: Windows XP with maven 2.0.7
>Reporter: Elid OR
> Fix For: 2.2
>
>
> Here my configuration in my assembly descriptor file :
>   
> 
>   true
>   
> true
>   
>   my-groupId:my-artifactId
>   
> And this correctly unpack my dependencies but it does not filter the token in 
> it.
> The token are put in a profile that a activate when build the project.

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

[jira] Issue Comment Edited: (MNG-2456) Maven Archiver creates incorrect Class-Path entry in Manifest for deployed snapshots

[Matthew McCullough (JIRA)]

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

Matthew McCullough edited comment on MNG-2456 at 8/15/07 6:29 PM:
--

The assembly:assembly behavior that uses the timestamped JAR name causes a 
disagreement with jar:jar thus resulting in a zip package that can't be 
executed since the jar names in the manifest are "simple names" and the jars 
actually delivered in the ZIP assembly are the date-stamped ones.


 was:
The assembly:assembly behavior to also use the timestamped JAR name causes a 
disagreement with jar:jar thus resulting in a zip package that can't be 
executed since the jar names in the manifest are "simple names" and the jars 
actually delivered in the ZIP assembly are the date-stamped ones.

> Maven Archiver creates incorrect Class-Path entry in Manifest for deployed 
> snapshots
> 
>
> Key: MNG-2456
> URL: http://jira.codehaus.org/browse/MNG-2456
> Project: Maven 2
>  Issue Type: Bug
>  Components: maven-archiver
>Affects Versions: 2.0.4
>Reporter: Barrie Treloar
>Assignee: Kenney Westerhof
> Fix For: Reviewed Pending Version Assignment
>
> Attachments: MNG-2456-maxb.patch, MNG-2456-patch.txt, 
> MNG-2456-step1-refactoring-patch.txt, 
> MNG-2456-step2-add-test-cases-patch.txt, MNG-2456-step3-fix-bug-patch.txt
>
>
> See related problems MJAR-28 and MASSEMBLY-67.
> Summary:
> The Maven-Archiver uses the file part of the artifact's filename to create 
> the Class-Path entries in the Manifest.
> This works fine for released artifacts and non-deployed snapshot.
> The problem occurs when using a deployed snapshot as the assembly plugin will 
> copy the dependency as ${artifactId}-${version}-timestampedversion.jar and 
> the entry in the Class-Path will be ${artifactId}-${version}-SNAPSHOT
> thus use of java -jar  will fail because of the differing names.

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

[jira] Updated: (MASSEMBLY-195) unpackOptions ignored

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-195:
-

Fix Version/s: 2.2-beta-2

> unpackOptions ignored
> -
>
> Key: MASSEMBLY-195
> URL: http://jira.codehaus.org/browse/MASSEMBLY-195
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2-beta-1
>Reporter: Todd Wolff
> Fix For: 2.2-beta-2
>
>
> excludes/includes defined within unpack options of dependency set are 
> effectively ignored

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-206) Filtering does not work when using in fileSet inside moduleSet

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-206:
-

Fix Version/s: 2.2

> Filtering does not work when using in fileSet inside moduleSet
> --
>
> Key: MASSEMBLY-206
> URL: http://jira.codehaus.org/browse/MASSEMBLY-206
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2-beta-1
> Environment: win32
>Reporter: Liya Jan
> Fix For: 2.2
>
>
> i have a descriptor : 
>   
> 
>   com.cc:module1
>   com.cc:module2
>   com.cc:module3
> 
> 
> 
>  
>   src/main
>   true
>   core
>   
>   conf/*
>
>   
>
>   false
>  
> 
> and although there is "true", the copied sources are not 
> filtered.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-163) In a multiproject environment Assembly causes many unneded rebuilds

[John Casey (JIRA)]

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

John Casey closed MASSEMBLY-163.


 Assignee: John Casey
   Resolution: Fixed
Fix Version/s: 2.2-beta-2

I'd suggest using the assembly:single goal (if you don't already). Also, since 
2.2-beta-1, dependencies are only resolved on-demand, if they are needed for 
that particular type of assembly.

> In a multiproject environment Assembly causes many unneded rebuilds 
> 
>
> Key: MASSEMBLY-163
> URL: http://jira.codehaus.org/browse/MASSEMBLY-163
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: Linux Gentoo, Java 1.5.0_07_b3 sun, Maven 2.0.4, plugin 
> 2.1
>Reporter: Simone Gianni
>Assignee: John Casey
> Fix For: 2.2-beta-2
>
>
> I have a project subdivided in 10 modules. 2 of these modules uses the 
> assembly plugin with the built-in descriptor "jar-with-dependencies".
> When running mvn clean install (or also only maven install) from the root of 
> the project, I see that every time it is building one of the two sub-projects 
> that uses the assembly plugin, it rebuilds some already built projects, even 
> if they are not dependencies of the "to be assembled" project, nor they have 
> any other apparent motivation to be rebuilded. One of the two project using 
> assembly doesn't even has a single dependency on other project, but triggers 
> a nearly complete rebuild.
> One of the projects is a WAR overlaying another war, useless to say that it 
> consumes a lot of time, and gets built 3 times.
> I've tested also with -o to exclude possible changes in external 
> dependencies, checked all the dependency tree to make sure that there were no 
> circular or otherwise "crossed" dependencies, changed the order of  
> in the parent pom to the best build order, checked by hand starting from an 
> empty local repository that building the artifacts (by hand, one by one, 
> commenting out the assembly) in that order satisfies all the 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: (MASSEMBLY-66) Ability to index into a nominated dependency JAR to identify files to include in the assembly (Im thinking .so/.dll etc)

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-66:


Fix Version/s: 2.2

> Ability to index into a nominated dependency JAR to identify files to include 
> in the assembly (Im thinking .so/.dll etc)
> 
>
> Key: MASSEMBLY-66
> URL: http://jira.codehaus.org/browse/MASSEMBLY-66
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Improvement
> Environment: Linux, x86_64, x86, win32
>Reporter: Andy Brook
> Fix For: 2.2
>
>
> Im trying to bundle a SWT application, I'm almost there, the only thing 
> missing is the ability to include .so files in the assembly that are 
> currently stored inside a dependancy.  As far as I can tell there is no neat 
> way to pull a few files out of a given dependency...
> My example is the SWT libraries, the GTK linux specific JAR in the eclipse 
> bundle also contain the native libraries.  Ive renamed this to fit into a 
> maven2 repository, but really dont want to have to copy the files manually.
> Ideally, I would like to be able to specify the dependency in mind and extend 
> the fileSet element to allow the context of the include to work only within 
> that dependency.
> If there is something Im missing and this can be done with existing plugins 
> Id like to hear about it!
> eg:
> ::POM::
>
> 
>   org.eclipse.swt
>   gtk-linux-x86
>   3.1.1
>   runtime
> 
> ::assembly-descriptor.xml::
> 
>   
>   org.eclipse.swt:gtk-linux-x86:3.1.1
>   /lib
>   
>   *.so
>   
> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-201) classifier not included in name of dependency set

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-201:
-

Fix Version/s: 2.2-beta-2

> classifier not included in name of dependency set
> -
>
> Key: MASSEMBLY-201
> URL: http://jira.codehaus.org/browse/MASSEMBLY-201
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2-beta-1
> Environment: 2.2-beta1 assembly plugin
>Reporter: Steve Berczuk
> Fix For: 2.2-beta-2
>
>
> in my assembly descriptor I have
>  
> /dir
> false
>
> 
> com.berczuk:appdeps:zip:linux
>com.berczuk:appdeps:zip:win32
> com.berczuk:appdeps:zip:sunos
> 
> 
> with the 2.1 plugin my assembly package would create a zip file that 
> contained the following files:
> dir/   
>   appdeps-1.1-linux.zip
>appdeps-1.1-win32.zip
>appdeps-1.1-sunos.zip
> now, there is only one zip file named  appdeps-1.1.zip
> even if I change the outputFileNameMapping to include the classifier the 
> classifier does not appear.
> This is a problem since it seemed to work so well before:)

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

[jira] Work started: (MASSEMBLY-184) components are not interpolated - i.e., ${params} are not substituted

[John Casey (JIRA)]

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

Work on MASSEMBLY-184 started by John Casey.

> components are not interpolated - i.e., ${params} are not substituted
> -
>
> Key: MASSEMBLY-184
> URL: http://jira.codehaus.org/browse/MASSEMBLY-184
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2
> Environment: all
>Reporter: John J. Franey
>Assignee: John Casey
> Attachments: CompInterpol.diff
>
>
> Components are no more than the extension of an Assembly.  As such, they 
> ought to also be interpolated.  Why is there the current restriction that the 
> ${param} will be replaced when it appears in an Assembly, but not if it 
> appears in a Component?
> Without interpolating Components, it will not be possible to refactor a 
> component out of an assembly if it contains a ${param} to be replaced.
> Attached is a diff with the code change and a test case.  The change: the 
> call to merge components into the assembly now appears before assembly's 
> interpolation in the DefaultAssemblyReader, not after.
> Regards,
> John

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-184) components are not interpolated - i.e., ${params} are not substituted

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-184:
-

Fix Version/s: 2.2-beta-2

> components are not interpolated - i.e., ${params} are not substituted
> -
>
> Key: MASSEMBLY-184
> URL: http://jira.codehaus.org/browse/MASSEMBLY-184
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2
> Environment: all
>Reporter: John J. Franey
>Assignee: John Casey
> Fix For: 2.2-beta-2
>
> Attachments: CompInterpol.diff
>
>
> Components are no more than the extension of an Assembly.  As such, they 
> ought to also be interpolated.  Why is there the current restriction that the 
> ${param} will be replaced when it appears in an Assembly, but not if it 
> appears in a Component?
> Without interpolating Components, it will not be possible to refactor a 
> component out of an assembly if it contains a ${param} to be replaced.
> Attached is a diff with the code change and a test case.  The change: the 
> call to merge components into the assembly now appears before assembly's 
> interpolation in the DefaultAssemblyReader, not after.
> Regards,
> John

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-187) Incorrect FileSet causes infinite loop

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-187:
-

Fix Version/s: 2.2

> Incorrect FileSet causes infinite loop
> --
>
> Key: MASSEMBLY-187
> URL: http://jira.codehaus.org/browse/MASSEMBLY-187
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2
> Environment: Linux
> JDK 1.5
> Maven 2.0.4
>Reporter: Jimisola Laursen
>Priority: Minor
> Fix For: 2.2
>
>
> Using an incorrect FileSet (see example below) causes an infinite loop after 
> "[INFO] Building jar: ..." have been outputed.
> 
> http://maven.apache.org/ASSEMBLY/1.1.0-SNAPSHOT"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>   xsi:schemaLocation="http://maven.apache.org/ASSEMBLY/1.1.0-SNAPSHOT 
> http://maven.apache.org/xsd/assembly-1.1.0-SNAPSHOT.xsd";>
>   package
>   
> jar
>   
>   false
>   
> 
>   
> *:jar:*
>   
>   
> *:sources
>   
> 
>   
>   
> 
>   target
> 
>   
> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-224) Support Signing assembled jars

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-224:
-

Fix Version/s: 2.2

> Support Signing assembled jars
> --
>
> Key: MASSEMBLY-224
> URL: http://jira.codehaus.org/browse/MASSEMBLY-224
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Wish
>Affects Versions: 2.2-beta-1
>Reporter: Florian Domino
>Priority: Minor
> Fix For: 2.2
>
>
> The Configuration Tag does not include the "signing parts" of the jar plugin
> you can set alias and storepassword but it is ignored/never called
> Fix: delegate the signing configuration tags to the jar plugin 

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

[jira] Commented: (MASSEMBLY-186) Download files from HTTP or FTP

[John Casey (JIRA)]

[ 
http://jira.codehaus.org/browse/MASSEMBLY-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104969
 ] 

John Casey commented on MASSEMBLY-186:
--

If you want to develop a patch to enable this sort of behavior, that would be 
okay with me...otherwise, it's a backburner issue... :-)

> Download files from HTTP or FTP
> ---
>
> Key: MASSEMBLY-186
> URL: http://jira.codehaus.org/browse/MASSEMBLY-186
> Project: Maven 2.x Assembly Plugin
>  Issue Type: New Feature
> Environment: All
>Reporter: Marcel Schoen
>Priority: Minor
>
> It would be nice if the assembly plugin could also gather files to be packed 
> from external sources over HTTP or FTP. The configuration could look like 
> this:
>   
>   http://files.acme.com/data
>   
>   **/*.jar
>   
>   /
>   
>   
>   ftp://files.acme.com/data
>   
>   **/*.jar
>   
>   /
>   
> It could support basically every available URL protocoll suitable for file 
> retrieval, like "scp:", "smb:" etc.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-108) Assembly Plugin Implicitly Excludes Empty Directory

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-108:
-

Fix Version/s: 2.3-beta-1

> Assembly Plugin Implicitly Excludes Empty Directory
> ---
>
> Key: MASSEMBLY-108
> URL: http://jira.codehaus.org/browse/MASSEMBLY-108
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Sharmarke Aden
> Fix For: 2.3-beta-1
>
>
> It seems that the inclusion of an empty directory isn't currently possible 
> with the assembly plugin. This is a problem because I would like to have an 
> empty "logs" directory included with my zip file assembly. It would be nice 
> if the assembly plugin gave you the option to add empty directories to an 
> assembly.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-171) Fix / speedup integration tests

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-171:
-

Fix Version/s: 2.3-beta-1

> Fix / speedup integration tests
> ---
>
> Key: MASSEMBLY-171
> URL: http://jira.codehaus.org/browse/MASSEMBLY-171
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Kenney Westerhof
>Priority: Blocker
> Fix For: 2.3-beta-1
>
>
> After hacking for quite a while in other projects to get the it's to run, 
> (fixing sandbox/plugins/maven-plug-it-plugin, 
> shared/maven-plugin-testing-tools and components/maven-settings)
> I found, after 9 minutes, this:
> {noformat}
> ---
> Execution Summary:
> Builds Passing: 24
> Builds Failing: 14
> ---
> The following builds failed:
> *  multimodule/twoLevel-includeSubModules-excludeSubModuleSourceDirs/pom.xml
> *  multimodule/two-level-multimodule-dontIncludeSubModules/pom.xml
> *  multimodule/two-level-multimodule/pom.xml
> *  multimodule/two-levels-includeBaseDirectory-withSources/pom.xml
> *  multimodule/twoLevel-dontIncludeSubModules-artifactIdExprOutDir/pom.xml
> *  multimodule/two-levels-includeBaseDirectory-withBinaries/pom.xml
> *  mojo-tests/single-twice-in-multimodule-hierarchy/pom.xml
> *  mojo-tests/single-in-one-project-hierarchy/pom.xml
> *  mojo-tests/single-twice-in-one-project-hierarchy/pom.xml
> *  basic-features/outputFileNameMapping-withArtifactBaseVersion/pom.xml
> *  basic-features/outputFileNameMapping-simple/pom.xml
> *  repository-assembly/pom.xml
> *  descriptor-refs/jar-with-dependencies/component-descriptors-merged/pom.xml
> *  file-sets/same-source-name-different-output/pom.xml
> [INFO] 
> 
> [ERROR] BUILD FAILURE
> [INFO] 
> 
> [INFO] : [EMAIL PROTECTED]
> One or more builds failed.
> 14 builds failed.
> [INFO] 
> 
> [INFO] Total time: 8 minutes 58 seconds
> [INFO] Finished at: Fri Dec 22 18:25:56 CET 2006
> [INFO] Final Memory: 22M/57M
> [INFO] 
> 
> FATAL ERROR: Unable to configure the Maven application
> For more information, run with the -e flag
> {noformat}
> Most failed builds had this in the build.log:
> {noformat}
> url = http://snapshots.repository.codehaus.org
> Downloading: 
> http://snapshots.repository.codehaus.org/org/apache/maven/plugins/maven-plugins/4-SNAPSHOT/maven-plugins-4-SNAPSHOT.pom
> [WARNING] Unable to get resource 
> 'org.apache.maven.plugins:maven-plugins:pom:4-SNAPSHOT' from repository 
> codehaus.org (http://snapshots.repository.codehaus.org)
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Failed to resolve artifact.
> GroupId: org.apache.maven.plugins
> ArtifactId: maven-plugins
> Version: 4-SNAPSHOT
> Reason: Unable to download the artifact from any repository
>   org.apache.maven.plugins:maven-plugins:pom:4-SNAPSHOT
> from the specified remote repositories:
>   codehaus.org (http://snapshots.repository.codehaus.org),
>   central (http://repo1.maven.org/maven2)
> [INFO] 
> 
> [INFO] For more information, run Maven with the -e switch
> [INFO] 
> 
> [INFO] Total time: 1 second
> [INFO] Finished at: Fri Dec 22 18:18:25 CET 2006
> [INFO] Final Memory: 2M/6M
> [INFO] 
> 
> FATAL ERROR: Unable to configure the Maven application
> For more information, run with the -e flag
> {noformat}
> That repo isn't used anymore, plus 4-SNAPSHOT is in my local repo already.
> I think repo isolation is good but the builds takes very very long because it 
> tries to download
> artifacts 71 times (only 57 are succesfully downloaded), using the wrong repo.
> Can't the local repo serve as a fallback, or at least serve non-snapshots, so 
> we can't install
> the test plugin? 
> Reasoning; in order to test the current plugin, it must be available in a 
> local repository
> structure for maven to find it, due to a bug in maven (MNG-2677).
> This requires a new local repo, initially empty. The plugin is added there. 
> But Maven can only handle 1 local repo at a time, so all the cached data 
> there is not used.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://j

[jira] Updated: (MASSEMBLY-115) Should avoid modifying assembly if none of the underlying files have changed.

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-115:
-

Fix Version/s: 2.3-beta-1

> Should avoid modifying assembly if none of the underlying files have changed.
> -
>
> Key: MASSEMBLY-115
> URL: http://jira.codehaus.org/browse/MASSEMBLY-115
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Improvement
>Reporter: David Boden
> Fix For: 2.3-beta-1
>
>
> At the moment, the assembly plugin always generates a the specified bundle, 
> no matter whether or not the files to be placed in the bundle are changed.
> This means that any plugins downstream (e.g. you want to digitally sign the 
> bundle) behave as if a "clean" has taken place.
> It would be better if the assembly plugin did not build a bundle if it is 
> going to be the same as what was produced during the last build. That way, 
> the last modified timestamp of the bundle won't get updated, and the 
> downstream plugins will know that nothing has changed.
> Adding an assembly to a build currently slows down the iterative "install" 
> build very significantly because of this issue. Clean builds are not effected 
> by this issue, but effectively the assembly is forcing a clean build every 
> time.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-96) using fileSet -> lineEnding will always put the selected lineEnding at the end of the file, even if the original file does not end in one

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-96:


Fix Version/s: 2.3-beta-1

> using fileSet -> lineEnding will always put the selected lineEnding at the 
> end of the file, even if the original file does not end in one
> -
>
> Key: MASSEMBLY-96
> URL: http://jira.codehaus.org/browse/MASSEMBLY-96
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Edwin Punzalan
> Fix For: 2.3-beta-1
>
>
> example
> Original File:
> {code}
> first line\r\n
> second line
> {code}
> New File:
> {code}
> first line\n
> second line\n
> {code}

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

[jira] Updated: (MASSEMBLY-94) reactorProjector projects have null Artifact files when using assembly:assembly

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-94:


Fix Version/s: 2.3-beta-1

> reactorProjector projects have null Artifact files when using 
> assembly:assembly
> ---
>
> Key: MASSEMBLY-94
> URL: http://jira.codehaus.org/browse/MASSEMBLY-94
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Edwin Punzalan
> Fix For: 2.3-beta-1
>
>
> So the work-around is to use "mvn package assembly:assembly"... also, 
> assembly:attached doesn't have this problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-22) improve integration of the site into the assembly

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-22:


Fix Version/s: 2.3-beta-1

> improve integration of the site into the assembly
> -
>
> Key: MASSEMBLY-22
> URL: http://jira.codehaus.org/browse/MASSEMBLY-22
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Reporter: Brett Porter
> Fix For: 2.3-beta-1
>
>
> it would be good to be able to automate the calling of site:site via a 
> lifecycle binding, but not sure how to make this optional depending on 
> arguments in the mojo.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-32) Provide installer support like NSIS or InnoSetup

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-32:


Fix Version/s: 2.3-beta-1

> Provide installer support like NSIS or InnoSetup
> 
>
> Key: MASSEMBLY-32
> URL: http://jira.codehaus.org/browse/MASSEMBLY-32
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Reporter: Vincent Siveton
> Fix For: 2.3-beta-1
>
> Attachments: MASSEMBLY-32.patch, maven-assembly-plugin.zip, 
> MNG-1643.diff, MNG-1643.diff, plexus-installer.diff
>
>
> Add the support of installer compiler like NSIS or InnoSetup. 
> See the thread:
> http://www.nabble.com/m2-developers-rfc%3A-The-assembly-plugin-ans-thirdparty-installation-builders-%28REPOST%29-t57.html#a1546470

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-184) components are not interpolated - i.e., ${params} are not substituted

[John Casey (JIRA)]

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

John Casey closed MASSEMBLY-184.


Resolution: Fixed

Applied. Great patch, thanks.

> components are not interpolated - i.e., ${params} are not substituted
> -
>
> Key: MASSEMBLY-184
> URL: http://jira.codehaus.org/browse/MASSEMBLY-184
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2
> Environment: all
>Reporter: John J. Franey
>Assignee: John Casey
> Fix For: 2.2-beta-2
>
> Attachments: CompInterpol.diff
>
>
> Components are no more than the extension of an Assembly.  As such, they 
> ought to also be interpolated.  Why is there the current restriction that the 
> ${param} will be replaced when it appears in an Assembly, but not if it 
> appears in a Component?
> Without interpolating Components, it will not be possible to refactor a 
> component out of an assembly if it contains a ${param} to be replaced.
> Attached is a diff with the code change and a test case.  The change: the 
> call to merge components into the assembly now appears before assembly's 
> interpolation in the DefaultAssemblyReader, not after.
> Regards,
> John

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-176) Assembly goal does not handle ear files with zip format

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-176:
-

Fix Version/s: 2.3-beta-1

> Assembly goal does not handle ear files with zip format
> ---
>
> Key: MASSEMBLY-176
> URL: http://jira.codehaus.org/browse/MASSEMBLY-176
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
> Environment: Windows Server 2003 Enterprise Edition
>Reporter: Gary Tilden
> Fix For: 2.3-beta-1
>
>
> When using the assembly goal and creating a zip file with a dependency on an 
> ear the ear is lost when installed.
> However, when the directory-inline goal is used the ear is included, but with 
> a file name that has extra characters.  I don't know if the ZIP format  has a 
> problem with ear files. Another reason could be that the ear is currently a 
> SNAPSHOT version.
> I haven't found any documentation on this issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-203) assembly:attached creates empty assemblies in reactor builds, but works fine in normal builds

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-203:
-

Fix Version/s: 2.3-beta-1

> assembly:attached creates empty assemblies in reactor builds, but works fine 
> in normal builds
> -
>
> Key: MASSEMBLY-203
> URL: http://jira.codehaus.org/browse/MASSEMBLY-203
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2-beta-1
> Environment: java version "1.5.0_09"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_09-b01, mixed mode)
>Reporter: Graham Leggett
> Fix For: 2.3-beta-1
>
>
> When attaching an assemply to the package phase as below, and running mvn 
> install, the assembly is built without a problem.
> If however the assembly is a sub-artifact built as part of a reactor / 
> multimodule build, mvn install in the root pom produces an empty assembly.
> The kludge workaround is to cd to the assembly artifact directory and run mvn 
> install from there.
>   
> maven-assembly-plugin
> 2.2-beta-1
> 
>   
> assembly.xml
>   
> 
> 
>   
> make-assembly
> package
> 
>   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] Updated: (MASSEMBLY-152) Support Ant token

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-152:
-

Fix Version/s: 2.3-beta-1

> Support Ant token
> -
>
> Key: MASSEMBLY-152
> URL: http://jira.codehaus.org/browse/MASSEMBLY-152
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Improvement
>Affects Versions: 2.2
> Environment: Maven 2.0.4
>Reporter: Rémy Sanlaville
>Priority: Critical
> Fix For: 2.3-beta-1
>
> Attachments: ant-token-fix.diff
>
>
> For the moment Maven 2.x Assembly Plugin support only maven token (${token})
> But I need to share some properties file with ant and maven.
> So It would be nice to also add Ant token support (@token@)
> For the version 2.1, I can give a patch
> The version 2.2-SNAPSHOT seems to be all refactoring and I don't have a patch 
> for the moment.
> I think we have to look at the method private String filter( String 
> rawContents ) of the org.apache.maven.plugin.assembly.format.FileFormatter 
> class. But I don't know how the RegexBasedInterpolator class works.
> Thanks

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

[jira] Updated: (MASSEMBLY-204) Make a single goal (assembly:assembly) that covers all cases of assembly:attached, directory, ...

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-204:
-

Fix Version/s: 2.3-beta-1

> Make a single goal (assembly:assembly) that covers all cases of 
> assembly:attached, directory, ...
> -
>
> Key: MASSEMBLY-204
> URL: http://jira.codehaus.org/browse/MASSEMBLY-204
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Improvement
>Affects Versions: 2.2-beta-1
>Reporter: Geoffrey De Smet
> Fix For: 2.3-beta-1
>
>
> It shouldn't be that hard to check wheter it's a multiproject or not.
> From a users perspective, when I bind the assembly plugin like this:
>   
> maven-assembly-plugin
> 
>   
> 
>   assembly
> 
>   
> it should just work, without having to figure out if it's a multiproject, etc.
> Ps: I 've read the 7 different assembly goals 5 times, and I only understand 
> the difference between unpack, attached and assembly...
> Great improvements in 2.2's descriptor 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: (MASSEMBLY-177) There should be a manifest section in an assembly [external] descriptor

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-177:
-

Fix Version/s: 2.3-beta-1

> There should be a manifest section in an assembly [external] descriptor
> ---
>
> Key: MASSEMBLY-177
> URL: http://jira.codehaus.org/browse/MASSEMBLY-177
> Project: Maven 2.x Assembly Plugin
>  Issue Type: New Feature
>Affects Versions: 2.1
>Reporter: Bernd
> Fix For: 2.3-beta-1
>
>
> Manifest modifications should be possible on a per assembly basis, e.g. 
> different  main classes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-229) Documentation of fileMode could be improved to avoid user trip hazard

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-229:
-

Fix Version/s: 2.2

> Documentation of fileMode could be improved to avoid user trip hazard
> -
>
> Key: MASSEMBLY-229
> URL: http://jira.codehaus.org/browse/MASSEMBLY-229
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Improvement
> Environment: n/a
>Reporter: Kelvin Goodson
>Priority: Minor
> Fix For: 2.2
>
>
> The website documentation for the fileMode parameter that occurs in a number 
> of places in the assembly descriptor format description such as [1] does show 
> a leading 0 for its values,  but it isn't clear that this is to declare the 
> value as octal.  Anyone who is used to using the chmod command on *nix 
> doesn't expect  to have to prefix the octal value with a 0, and therefore 
> might assume the 0 to be an insignificant digit.  It would be helpful to add 
> a comment in the descriptions of these parameters that the value is 
> interpreted as decimal unless preceded by a leading 0 to indicate an octal 
> value.
> [1] 
> http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_file

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

[jira] Updated: (MASSEMBLY-212) Assembly Descriptor Schemas (XSD) have wrong targetNamespace

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-212:
-

Fix Version/s: 2.2

> Assembly Descriptor Schemas (XSD) have wrong targetNamespace
> 
>
> Key: MASSEMBLY-212
> URL: http://jira.codehaus.org/browse/MASSEMBLY-212
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.1, 2.2-beta-1, 2.2-beta-2, 2.2
>Reporter: Manfred Geiler
>Priority: Minor
> Fix For: 2.2
>
>
> There are two versions of Assembly XSDs on the website:
> http://maven.apache.org/plugins/maven-assembly-plugin/
> Both define a targetNamespace "http://maven.apache.org/POM/4.0.0"; which is 
> wrong because those XSDs define the Schema for the Assembly Descriptor and 
> not the POM.
> Proposed fix for assembly-1.0.0.xsd:
> Change targetNamespace and xmlns to something like 
> "http://maven.apache.org/Assembly/1.0.0";
> Proposed fix for assembly-1.1.0-SNAPSHOT.xsd:
> Change targetNamespace and xmlns to something like 
> "http://maven.apache.org/Assembly/1.1.0";
> Regards,
> Manfred

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-225) Not a v4.0.0 POM

[John Casey (JIRA)]

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

John Casey closed MASSEMBLY-225.


 Assignee: John Casey
   Resolution: Fixed
Fix Version/s: 2.2-beta-2

the assembly plugins should allow the use of stub POMs when these sorts of POMs 
are encountered...in other words, they will be ignored as subtrees for the 
transitive dependency calculation.

> Not a v4.0.0 POM
> 
>
> Key: MASSEMBLY-225
> URL: http://jira.codehaus.org/browse/MASSEMBLY-225
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.0.1
> Environment: Linux Unbuntu, 1.5_07 jdk
>Reporter: C Helck
>Assignee: John Casey
> Fix For: 2.2-beta-2
>
>
>  I have a maven 1 project that builds a jar file called pps-3.0.2.jar.
>  The jar (and it's pom) are moved into my legacy style repository.
>  I have a maven 2 project that depends on pps-3.0.2. It compiles and 
>  tests the code fine. During the assembly it is suppose to creates a 
>  directory of dependent jar files and it blows up with the message:
>  --
>  Error building POM (may not be this project's POM).
>  Project ID: ebs:pps
>  POM Location: /home/chelck/.m2/repository/ebs/pps/3.0.2/pps-3.0.2.pom
>  Reason: Not a v4.0.0 POM.
> -
> In a sense the error is correct: pps-3.0.2.pom is not v4.0.0 -- it's 
> legacy. So why is mvn trying to build it's POM and why doesn't it 
> realize it's a legacy pom?
> I see this with maven 2.0.4,2.0.6, and 2.0.7.
> Here is a (2.0.4) stack trace:
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to create 
> assembly: Error retrieving POM of module-dependency: ebs:pps:jar:3.0.2; 
> Reason: Not a v4.0.0 POM.
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:585)
>   at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>   at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
>   at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to create 
> assembly: Error retrieving POM of module-dependency: ebs:pps:jar:3.0.2; 
> Reason: Not a v4.0.0 POM.
>   at 
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:302)
>   at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
>   ... 16 more
> Caused by: org.apache.maven.plugin.assembly.archive.ArchiveCreationException: 
> Error retrieving POM of module-dependency: ebs:pps:jar:3.0.2; Reason: Not a 
> v4.0.0 POM.
>   at 
> org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.addDependencySet(AddDependencySetsTask.java:114)
>   at 
> org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.execute(AddDependencySetsTask.java:90)
>   at 
> org.apache.maven.plugin.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:54)
>   at 
> org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:98)
>   at 
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:278)
>   ... 18 more
> Caused by: org.apache.maven.project.InvalidProjectModelException: Not a 
> v4.0.0 POM.
>   a

[jira] Updated: (MASSEMBLY-101) META-INF/plexus/components.xml are being processed even if it is excluded or not included

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-101:
-

Fix Version/s: 2.2

> META-INF/plexus/components.xml are being processed even if it is excluded or 
> not included
> -
>
> Key: MASSEMBLY-101
> URL: http://jira.codehaus.org/browse/MASSEMBLY-101
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Reporter: Edwin Punzalan
>Priority: Minor
> Fix For: 2.2
>
>


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

[jira] Updated: (MASSEMBLY-167) Property Expansion/Filtering does not always work for System.properties

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-167:
-

Fix Version/s: 2.2

> Property Expansion/Filtering does not always work for System.properties
> ---
>
> Key: MASSEMBLY-167
> URL: http://jira.codehaus.org/browse/MASSEMBLY-167
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2
> Environment: JDK 1.5.0_10, Maven 2.1-SNAPSHOT, Linux 2.6.18
>Reporter: Daniel Krisher
>Priority: Minor
> Fix For: 2.2
>
>
> When using filtering for a file element in an assembly descriptor, System 
> properties (e.g. java.version) are not always available (and do not get 
> replaced in the filtered file).
> For example, my assembly descriptor contains:
> {noformat} 
>  
> src/main/files/config/splash.xml
> /config
> true
>  
> {noformat} 
> and splash.xml (pre-filtering): 
> {noformat} 
> 
> ${project.name}
> ${project.version}
> ${java.version}
> 
> {noformat} 
> Which results in a post-filtered splash.xml:
> {noformat} 
> 
> ACES Viewer
> 0.7-SNAPSHOT
> ${java.version}
> 
> {noformat} 
> The problem appears to be in the 'initializeFiltering()' method of the 
> FileFormatter class.  The filter properties are initialized using:
> filterProperties = new Properties(System.getProperties());
> Changing this to:
> filterProperties = new Properties();
> filterProperties.putAll(System.getProperties());
> Seems to fix the problem.
> The Properties javadocs are a little vague on the constructor parameter:
> public Properties(Properties defaults)
> Creates an empty property list with the specified defaults.

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