date:20080919

[
http://jira.codehaus.org/browse/MINSTALL-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=148421#action_148421
]

Per-Jarle Sæther commented on MINSTALL-53:
--

Hello
You are right. That's why i didn't find my war-file. It was laying below the
LocalService path

It also explain why the install started out by downloading all the dependencies.

I found it now, but why did this happen?

The only thing i can think of is SP3 for Windows XP which i installed two days
ago. And if i remember correctly, yesterdays build was the first one since i
installed the SP.

/Per-Jarle

Install does not install the final war in repository

Key: MINSTALL-53
URL: http://jira.codehaus.org/browse/MINSTALL-53
Project: Maven 2.x Install Plugin
Issue Type: Bug
Affects Versions: 2.0
Environment: Maven version: 2.0.7
Java version: 1.6.0_02
OS name: windows xp version: 5.1 arch:x86
Reporter: Per-Jarle Sæther
Attachments: mvn_install_log.txt

I have been using the same pom.xml for 3 months without problems.
But when i ran mvn install this morning, it started with downloading all
libraries before the actual build.
After all unit tests have been runned, it started packaging the webapp and
said it was installing the war file to the repository.
Everything looked good until i went into the repository folder to get the
war It wasn't there
Am attaching the last part of the build log
/Per-Jarle

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

[jira] Created: (MASSEMBLY-355) I get duplicate files in my -jar-with-dependencies.jar

I get duplicate files in my -jar-with-dependencies.jar


 Key: MASSEMBLY-355
 URL: http://jira.codehaus.org/browse/MASSEMBLY-355
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
 Environment: mvn --version
Maven version: 2.0.9
Java version: 1.5.0_13
OS: OSX 10.5.5
Reporter: Bjørn Magnus Mathisen
 Attachments: testProj.zip

I get duplicate files in my -jar-with-dependencies.jar
build with mvn package, then try to unzip the mentioned jar file, it asks if 
you want to replace,
this also hampers any signing of the jar 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-355) I get duplicate files in my -jar-with-dependencies.jar


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

Benjamin Bentmann updated MASSEMBLY-355:


Affects Version/s: 2.2-beta-2

 I get duplicate files in my -jar-with-dependencies.jar
 

 Key: MASSEMBLY-355
 URL: http://jira.codehaus.org/browse/MASSEMBLY-355
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-2
 Environment: mvn --version
 Maven version: 2.0.9
 Java version: 1.5.0_13
 OS: OSX 10.5.5
Reporter: Bjørn Magnus Mathisen
 Attachments: testProj.zip


 I get duplicate files in my -jar-with-dependencies.jar
 build with mvn package, then try to unzip the mentioned jar file, it asks if 
 you want to replace,
 this also hampers any signing of the jar 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-355) I get duplicate files in my -jar-with-dependencies.jar


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

Benjamin Bentmann updated MASSEMBLY-355:


Attachment: testProj.zip

A trimmed down version of the original test project where the 
{{dependencies}} section has been removed. The assmbled JAR still contains 
two instances of the entry aoc3/App.class.

 I get duplicate files in my -jar-with-dependencies.jar
 

 Key: MASSEMBLY-355
 URL: http://jira.codehaus.org/browse/MASSEMBLY-355
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-2
 Environment: mvn --version
 Maven version: 2.0.9
 Java version: 1.5.0_13
 OS: OSX 10.5.5
Reporter: Bjørn Magnus Mathisen
 Attachments: testProj.zip, testProj.zip


 I get duplicate files in my -jar-with-dependencies.jar
 build with mvn package, then try to unzip the mentioned jar file, it asks if 
 you want to replace,
 this also hampers any signing of the jar 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: (MINSTALL-53) Install does not install the final war in repository


[ 
http://jira.codehaus.org/browse/MINSTALL-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=148433#action_148433
 ] 

Benjamin Bentmann commented on MINSTALL-53:
---

bq. but why did this happen?
Sorry, no clue. Assuming mvn.bat runs as the same user as that you originally 
logged in, you might want to check your profile settings weren't messed up. Or 
do you observe Maven using different profile/user settings than your regular 
console sesssion?

 Install does not install the final war in repository
 

 Key: MINSTALL-53
 URL: http://jira.codehaus.org/browse/MINSTALL-53
 Project: Maven 2.x Install Plugin
  Issue Type: Bug
Affects Versions: 2.0
 Environment: Maven version: 2.0.7
 Java version: 1.6.0_02
 OS name: windows xp version: 5.1 arch:x86
Reporter: Per-Jarle Sæther
 Attachments: mvn_install_log.txt


 I have been using the same pom.xml for 3 months without problems.
 But when i ran mvn install this morning, it started with downloading all 
 libraries before the actual build.
 After all unit tests have been runned, it started packaging the webapp and 
 said it was installing the war file to the repository.
 Everything looked good until i went into the repository folder to get the 
 war It wasn't there
 Am attaching the last part of the build log
 /Per-Jarle

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MINSTALL-53) Install does not install the final war in repository


[ 
http://jira.codehaus.org/browse/MINSTALL-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=148437#action_148437
 ] 

Per-Jarle Sæther commented on MINSTALL-53:
--

When running the mvn install from a fresh console, everything looks ok and the 
war-file is written where i want it

 Install does not install the final war in repository
 

 Key: MINSTALL-53
 URL: http://jira.codehaus.org/browse/MINSTALL-53
 Project: Maven 2.x Install Plugin
  Issue Type: Bug
Affects Versions: 2.0
 Environment: Maven version: 2.0.7
 Java version: 1.6.0_02
 OS name: windows xp version: 5.1 arch:x86
Reporter: Per-Jarle Sæther
 Attachments: mvn_install_log.txt


 I have been using the same pom.xml for 3 months without problems.
 But when i ran mvn install this morning, it started with downloading all 
 libraries before the actual build.
 After all unit tests have been runned, it started packaging the webapp and 
 said it was installing the war file to the repository.
 Everything looked good until i went into the repository folder to get the 
 war It wasn't there
 Am attaching the last part of the build log
 /Per-Jarle

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-355) I get duplicate files in my -jar-with-dependencies.jar


[ 
http://jira.codehaus.org/browse/MASSEMBLY-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=148490#action_148490
 ] 

Bjørn Magnus Mathisen commented on MASSEMBLY-355:
-

if you add  version2.2-beta-3-SNAPSHOT/version
to the assembly plugin, the behaviour changes, the second copy of every class 
file is then
prefixed with the entire filesystem path (i.e. 
Users/epic/Documents/git/aoc/aocClient/target/classes/), this avoids the 
duplicate problem
and I can now manage to sign the jar, but it can't be claimed to be a good 
solution...

 I get duplicate files in my -jar-with-dependencies.jar
 

 Key: MASSEMBLY-355
 URL: http://jira.codehaus.org/browse/MASSEMBLY-355
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-2
 Environment: mvn --version
 Maven version: 2.0.9
 Java version: 1.5.0_13
 OS: OSX 10.5.5
Reporter: Bjørn Magnus Mathisen
 Attachments: testProj.zip, testProj.zip


 I get duplicate files in my -jar-with-dependencies.jar
 build with mvn package, then try to unzip the mentioned jar file, it asks if 
 you want to replace,
 this also hampers any signing of the jar file..

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

[jira] Updated: (MNG-3057) properties not expanded in generated POMs when building A/B/C nested projects

2008-09-19 Thread Henrik Brautaset Aronsen (JIRA)

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

Henrik Brautaset Aronsen updated MNG-3057:
--

Attachment: InstallMojo.java.patch

properties not expanded in generated POMs when building A/B/C nested projects
-

Key: MNG-3057
URL: http://jira.codehaus.org/browse/MNG-3057
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 2.0.7
Reporter: George Armhold
Fix For: 2.0.x

Attachments: example.tar.gz, generated-poms.tar.gz,
InstallMojo.java.patch, InstallMojo.java.patch

Using Maven version: 2.0.8-SNAPSHOT, svn r547427.
I checked out and built 2.0.8 because I was interested in Jason van Zyl's
patch for MNG-2619- building from the middle pom of a
(parent,child,grandchild) heirarchy fails. The fix works for the most part,
but there still seems to be a problem with the poms that get generated during
the install goal. The poms that get installed into .m2/repository do not
have properties interpolated. If I run maven like:
$ mvn install -Dglobal-version=1.0.0
I get poms with the string ${global-version} embedded in the resulting poms
rather than what I specify on the command line (or in settings.xml). The
build works properly aside from this, and if I do mvn help:effective-pom
the properties are correctly interpolated.
I've attached a tarfile with an example A/B/C build structure that exhibits
this behavior, as well as the generated poms.
Many thanks for your attention.

[jira] Commented: (MNG-3057) properties not expanded in generated POMs when building A/B/C nested projects

2008-09-19 Thread Henrik Brautaset Aronsen (JIRA)

[
http://jira.codehaus.org/browse/MNG-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=148493#action_148493
]

Henrik Brautaset Aronsen commented on MNG-3057:
---

I've updated the patch. System properties are taken into account as well now.

properties not expanded in generated POMs when building A/B/C nested projects
-

Key: MNG-3057
URL: http://jira.codehaus.org/browse/MNG-3057
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 2.0.7
Reporter: George Armhold
Fix For: 2.0.x

Attachments: example.tar.gz, generated-poms.tar.gz,
InstallMojo.java.patch, InstallMojo.java.patch

[jira] Issue Comment Edited: (MNG-3057) properties not expanded in generated POMs when building A/B/C nested projects

2008-09-19 Thread Henrik Brautaset Aronsen (JIRA)

[
http://jira.codehaus.org/browse/MNG-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=148493#action_148493
]

henrik242 edited comment on MNG-3057 at 9/19/08 5:49 AM:

I've updated [the patch|^InstallMojo.java.patch]. System properties are taken
into account as well now.

was (Author: henrik242):
I've updated the patch. System properties are taken into account as well
now.

properties not expanded in generated POMs when building A/B/C nested projects
-

Key: MNG-3057
URL: http://jira.codehaus.org/browse/MNG-3057
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 2.0.7
Reporter: George Armhold
Fix For: 2.0.x

Attachments: example.tar.gz, generated-poms.tar.gz,
InstallMojo.java.patch, InstallMojo.java.patch

[jira] Closed: (MINSTALL-53) Install does not install the final war in repository


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

Benjamin Bentmann closed MINSTALL-53.
-

  Assignee: Benjamin Bentmann
Resolution: Cannot Reproduce

So then I feel this is more a Windows issue than a Maven issue.

 Install does not install the final war in repository
 

 Key: MINSTALL-53
 URL: http://jira.codehaus.org/browse/MINSTALL-53
 Project: Maven 2.x Install Plugin
  Issue Type: Bug
Affects Versions: 2.0
 Environment: Maven version: 2.0.7
 Java version: 1.6.0_02
 OS name: windows xp version: 5.1 arch:x86
Reporter: Per-Jarle Sæther
Assignee: Benjamin Bentmann
 Attachments: mvn_install_log.txt


 I have been using the same pom.xml for 3 months without problems.
 But when i ran mvn install this morning, it started with downloading all 
 libraries before the actual build.
 After all unit tests have been runned, it started packaging the webapp and 
 said it was installing the war file to the repository.
 Everything looked good until i went into the repository folder to get the 
 war It wasn't there
 Am attaching the last part of the build log
 /Per-Jarle

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-3018) pluginManagement configurations are not honoured when plugin is silently included

2008-09-19 Thread Michael Semb Wever (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=148496#action_148496
 ] 

Michael Semb Wever commented on MNG-3018:
-

TestCase Available.


Checkout http://sesat.no/svn/sesat-kernel/trunk
and uncomment the lines
!--pluginManagement-- !-- See http://jira.codehaus.org/browse/MNG-3018 
.Uncomment when fixed. --
and
!--/pluginManagement-- !-- See http://jira.codehaus.org/browse/MNG-3018 
.Uncomment when fixed. --

to see an example.


 pluginManagement configurations are not honoured when plugin is silently 
 included
 -

 Key: MNG-3018
 URL: http://jira.codehaus.org/browse/MNG-3018
 Project: Maven 2
  Issue Type: Bug
  Components: Embedding
Reporter: Michael Semb Wever
 Fix For: Reviewed Pending Version Assignment


 Read http://jira.codehaus.org/browse/MEVENIDE-532
 In my top parent pom.xml i've define the maven-compiler-plugin configuration 
 like:
 build
 pluginManagement
 plugins
 plugin
 artifactIdmaven-compiler-plugin/artifactId
 configuration
 source1.5/source
 target1.5/target
 encodingUTF-8/encoding
 /configuration
 /plugin ...
 since not all my subprojects require the plugin, and when they do they 
 silently include the plugin, it makes more sense to define it within the 
 pluginManagement tag.
 But when i use mevenide-netbeans all my projects are marked uncompilable 
 since the maven embedder does not report the above defined configuration for 
 the maven-compiler-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-309) outputFileNameMapping fails and includes parent's name


[ 
http://jira.codehaus.org/browse/MASSEMBLY-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=148499#action_148499
 ] 

Michael Osipov commented on MASSEMBLY-309:
--

JD,

I was able to reproduce the issue on your example with simple change which 
resembles my code:

{noformat}
--- E:/Downloads/massembly-309/src/main/assembly/bin.xmlFri Sep 19 
13:53:05 2008
+++ E:/massembly-309/src/main/assembly/bin.xml  Fri Sep 19 13:50:47 2008
@@ -1,13 +1,13 @@
 assembly
   idbin/id
   formats
-formatdir/format
+formatzip/format
   /formats
   moduleSets
 moduleSet
   binaries
 includeDependenciesfalse/includeDependencies
-
outputFileNameMappingmodule-${module.artifactId}-${module.version}.${module.extension}/outputFileNameMapping
+
outputFileNameMappingmodule-${artifactId}-${version}.${extension}/outputFileNameMapping
 unpackfalse/unpack
   /binaries
 /moduleSet
@@ -15,7 +15,7 @@
   binaries
 attachmentClassifierjavadoc/attachmentClassifier
 includeDependenciesfalse/includeDependencies
-
outputFileNameMappingmodule-${module.artifactId}-${module.version}-${module.classifier}.${module.extension}/outputFileNameMapping
+
outputFileNameMappingmodule-${artifactId}-${version}-${classifier}.${extension}/outputFileNameMapping
 unpackfalse/unpack
   /binaries
 /moduleSet
{noformat}

After that I added module. to my bin.xml and it resolved the issue somewhat. 
This simply means that omitting the module. does cause an interpolation 
error. I omitted the module. because the documenation for the asssembly 
plugin told me so.
The prop name addition resolved only the jar naming issue. The site directory 
is still broken!
You may checkout my [2.4|http://svn.fckeditor.net/FCKeditor.Java/tags/2.4/] and 
change the assembly plugin version and the properties and see the broken jars 
and the messed up site directory in the bin zip.
Additionally I added 2 images depicting the site dir issue.

 outputFileNameMapping fails and includes parent's name
 --

 Key: MASSEMBLY-309
 URL: http://jira.codehaus.org/browse/MASSEMBLY-309
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-2
 Environment: Maven 2.0.9, JDK6, WinXP SP2 AND debian 4.0, Maven 
 2.0.8, JDK6 AND Maven Embedder m2eclipse 0.9.1
Reporter: Michael Osipov
Assignee: John Casey
Priority: Critical
 Fix For: 2.2-beta-3

 Attachments: broken_example.png, expected_example.png, 
 massembly-309.zip


 I have created a bin assembly descriptor containing:
 {code}
 moduleSets
   moduleSet
   includes
   include*:jar/include
   /includes
   binaries
   includeDependenciesfalse/includeDependencies
   outputFileNameMapping
   
 fckeditor-${module.artifactId}-${module.version}.${module.extension}
   /outputFileNameMapping
   unpackfalse/unpack
   /binaries
   /moduleSet
   moduleSet
   includes
   include*:jar/include
   /includes
   binaries
   
 attachmentClassifierjavadoc/attachmentClassifier
   includeDependenciesfalse/includeDependencies
   outputFileNameMapping
   
 fckeditor-${module.artifactId}-${module.version}-${module.classifier}.${module.extension}
   /outputFileNameMapping
   unpackfalse/unpack
   /binaries
   /moduleSet
   /moduleSets
 {code}
 The expected zip distro should look like the expected attachment but 
 sometimes (80 %) the outcome is the broken example.
 It seems like it does not resolves the module but the my parent. Browser my 
 source [here|http://dev.fckeditor.net/browser/FCKeditor.Java/branches/2.4] if 
 you like.
 Interesting to say if the bin distro is fine, maven reports (note the parent 
 warning):
 {code}
 [INFO] [assembly:assembly]
 [INFO] Reading assembly descriptor: src/main/assembly/src.xml
 [INFO] Reading assembly descriptor: src/main/assembly/bin.xml
 [INFO] Adding site directory to assembly : 
 D:\workspace_\fckeditor-java\target\s
 ite
 [INFO] Processing sources for module project: 
 net.fckeditor:java-demo:war:2.4-SN
 APSHOT
 [INFO] Processing sources for module project: 
 net.fckeditor:java-core:jar:2.4-SN
 APSHOT
 [INFO] Building zip:

[jira] Issue Comment Edited: (MASSEMBLY-309) outputFileNameMapping fails and includes parent's name


[ 
http://jira.codehaus.org/browse/MASSEMBLY-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=148499#action_148499
 ] 

sgfan edited comment on MASSEMBLY-309 at 9/19/08 7:09 AM:
---

JD,

I was able to reproduce the issue on your example with simple change which 
resembles my code:

{noformat}
--- E:/Downloads/massembly-309/src/main/assembly/bin.xmlFri Sep 19 
13:53:05 2008
+++ E:/massembly-309/src/main/assembly/bin.xml  Fri Sep 19 13:50:47 2008
@@ -1,13 +1,13 @@
 assembly
   idbin/id
   formats
-formatdir/format
+formatzip/format
   /formats
   moduleSets
 moduleSet
   binaries
 includeDependenciesfalse/includeDependencies
-
outputFileNameMappingmodule-${module.artifactId}-${module.version}.${module.extension}/outputFileNameMapping
+
outputFileNameMappingmodule-${artifactId}-${version}.${extension}/outputFileNameMapping
 unpackfalse/unpack
   /binaries
 /moduleSet
@@ -15,7 +15,7 @@
   binaries
 attachmentClassifierjavadoc/attachmentClassifier
 includeDependenciesfalse/includeDependencies
-
outputFileNameMappingmodule-${module.artifactId}-${module.version}-${module.classifier}.${module.extension}/outputFileNameMapping
+
outputFileNameMappingmodule-${artifactId}-${version}-${classifier}.${extension}/outputFileNameMapping
 unpackfalse/unpack
   /binaries
 /moduleSet
{noformat}

After that I added module. to my bin.xml and it resolved the issue somewhat. 
This simply means that omitting the module. does cause an interpolation 
error. I omitted the module. because the documenation for the asssembly 
plugin told me so.
The prop name addition resolved only the jar naming issue. The site directory 
is still broken!
You may checkout my [2.4 tag|http://svn.fckeditor.net/FCKeditor.Java/tags/2.4/] 
and change the assembly plugin version and the properties and see the broken 
jars and the messed up site directory in the bin zip.
Additionally I added 2 images depicting the site dir issue.

  was (Author: sgfan):
JD,

I was able to reproduce the issue on your example with simple change which 
resembles my code:

{noformat}
--- E:/Downloads/massembly-309/src/main/assembly/bin.xmlFri Sep 19 
13:53:05 2008
+++ E:/massembly-309/src/main/assembly/bin.xml  Fri Sep 19 13:50:47 2008
@@ -1,13 +1,13 @@
 assembly
   idbin/id
   formats
-formatdir/format
+formatzip/format
   /formats
   moduleSets
 moduleSet
   binaries
 includeDependenciesfalse/includeDependencies
-
outputFileNameMappingmodule-${module.artifactId}-${module.version}.${module.extension}/outputFileNameMapping
+
outputFileNameMappingmodule-${artifactId}-${version}.${extension}/outputFileNameMapping
 unpackfalse/unpack
   /binaries
 /moduleSet
@@ -15,7 +15,7 @@
   binaries
 attachmentClassifierjavadoc/attachmentClassifier
 includeDependenciesfalse/includeDependencies
-
outputFileNameMappingmodule-${module.artifactId}-${module.version}-${module.classifier}.${module.extension}/outputFileNameMapping
+
outputFileNameMappingmodule-${artifactId}-${version}-${classifier}.${extension}/outputFileNameMapping
 unpackfalse/unpack
   /binaries
 /moduleSet
{noformat}

After that I added module. to my bin.xml and it resolved the issue somewhat. 
This simply means that omitting the module. does cause an interpolation 
error. I omitted the module. because the documenation for the asssembly 
plugin told me so.
The prop name addition resolved only the jar naming issue. The site directory 
is still broken!
You may checkout my [2.4|http://svn.fckeditor.net/FCKeditor.Java/tags/2.4/] and 
change the assembly plugin version and the properties and see the broken jars 
and the messed up site directory in the bin zip.
Additionally I added 2 images depicting the site dir issue.
  
 outputFileNameMapping fails and includes parent's name
 --

 Key: MASSEMBLY-309
 URL: http://jira.codehaus.org/browse/MASSEMBLY-309
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-2
 Environment: Maven 2.0.9, JDK6, WinXP SP2 AND debian 4.0, Maven 
 2.0.8, JDK6 AND Maven Embedder m2eclipse 0.9.1
Reporter: Michael Osipov
Assignee: John Casey
Priority: Critical
 Fix For: 2.2-beta-3

 Attachments: broken_example.png, expected_example.png, 
 massembly-309.zip


 I have created a bin assembly descriptor containing:
 {code}
 moduleSets
   moduleSet
   includes
   include*:jar/include
   /includes
   binaries
   includeDependenciesfalse/includeDependencies

[jira] Commented: (MASSEMBLY-285) regression: duplicate files added to the assembly

2008-09-19 Thread Artur Zielazny (JIRA)


[ 
http://jira.codehaus.org/browse/MASSEMBLY-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=148501#action_148501
 ] 

Artur Zielazny commented on MASSEMBLY-285:
--

With following configuration placed in parent's POM:

plugin
artifactIdmaven-assembly-plugin/artifactId
version2.2-beta-3-SNAPSHOT/version
configuration
archiverConfig

duplicateBehaviourskip/duplicateBehaviour
/archiverConfig
descriptors

descriptorsrc/main/assembly/assembly.xml/descriptor
/descriptors

outputDirectorytarget/outputDirectory
/configuration
/plugin

used in multimodule project (parent, then few modules as child), this is still 
adding duplicates into the final ZIP archive. 
duplicateBehaviourfail/duplicateBehaviour does not fail as well.

I will appreciate any help.

 regression: duplicate files added to the assembly
 -

 Key: MASSEMBLY-285
 URL: http://jira.codehaus.org/browse/MASSEMBLY-285
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-1
Reporter: Brett Porter
Assignee: John Casey
Priority: Blocker
 Fix For: 2.2-beta-3


 I found that it was possible to add a file twice to the assembly through 
 different filesets (a zip file) so that when it extracted it prompted for 
 overwrite.
 It should error out or collapse the entries (as 2.1 did).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-309) outputFileNameMapping fails and includes parent's name


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

Michael Osipov updated MASSEMBLY-309:
-

Attachment: proper_site_dir.png

 outputFileNameMapping fails and includes parent's name
 --

 Key: MASSEMBLY-309
 URL: http://jira.codehaus.org/browse/MASSEMBLY-309
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-2
 Environment: Maven 2.0.9, JDK6, WinXP SP2 AND debian 4.0, Maven 
 2.0.8, JDK6 AND Maven Embedder m2eclipse 0.9.1
Reporter: Michael Osipov
Assignee: John Casey
Priority: Critical
 Fix For: 2.2-beta-3

 Attachments: broken_example.png, broken_site_dir.png, 
 expected_example.png, massembly-309.zip, proper_site_dir.png


 I have created a bin assembly descriptor containing:
 {code}
 moduleSets
   moduleSet
   includes
   include*:jar/include
   /includes
   binaries
   includeDependenciesfalse/includeDependencies
   outputFileNameMapping
   
 fckeditor-${module.artifactId}-${module.version}.${module.extension}
   /outputFileNameMapping
   unpackfalse/unpack
   /binaries
   /moduleSet
   moduleSet
   includes
   include*:jar/include
   /includes
   binaries
   
 attachmentClassifierjavadoc/attachmentClassifier
   includeDependenciesfalse/includeDependencies
   outputFileNameMapping
   
 fckeditor-${module.artifactId}-${module.version}-${module.classifier}.${module.extension}
   /outputFileNameMapping
   unpackfalse/unpack
   /binaries
   /moduleSet
   /moduleSets
 {code}
 The expected zip distro should look like the expected attachment but 
 sometimes (80 %) the outcome is the broken example.
 It seems like it does not resolves the module but the my parent. Browser my 
 source [here|http://dev.fckeditor.net/browser/FCKeditor.Java/branches/2.4] if 
 you like.
 Interesting to say if the bin distro is fine, maven reports (note the parent 
 warning):
 {code}
 [INFO] [assembly:assembly]
 [INFO] Reading assembly descriptor: src/main/assembly/src.xml
 [INFO] Reading assembly descriptor: src/main/assembly/bin.xml
 [INFO] Adding site directory to assembly : 
 D:\workspace_\fckeditor-java\target\s
 ite
 [INFO] Processing sources for module project: 
 net.fckeditor:java-demo:war:2.4-SN
 APSHOT
 [INFO] Processing sources for module project: 
 net.fckeditor:java-core:jar:2.4-SN
 APSHOT
 [INFO] Building zip: 
 D:\workspace_\fckeditor-java\target\fckeditor-java-2.4-SNAP
 SHOT-src.zip
 [WARNING] NOTE: Currently, inclusion of module dependencies may produce 
 unpredic
 table results if a version conflict occurs.
 [WARNING] NOTE: Currently, inclusion of module dependencies may produce 
 unpredic
 table results if a version conflict occurs.
 [INFO] Processing DependencySet (output=lib)
 [WARNING] Cannot include project artifact: 
 net.fckeditor:fckeditor-java:pom:2.4-
 SNAPSHOT; it doesn't have an associated file or directory.
 [INFO] Building zip: 
 D:\workspace_\fckeditor-java\target\fckeditor-java-2.4-SNAP
 SHOT-bin.zip
 [INFO]
 [INFO]
 [INFO] 
 
 [INFO] Reactor Summary:
 [INFO] 
 
 [INFO] FCKeditor.Java Integration  SUCCESS 
 [32.797s]
 [INFO] FCKeditor.Java Integration Core ... SUCCESS 
 [15.203s]
 [INFO] FCKeditor.Java Integration Demo Webapp  SUCCESS 
 [4.609s]
 [INFO] 
 
 [INFO] 
 
 [INFO] BUILD SUCCESSFUL
 [INFO] 
 
 [INFO] Total time: 1 minute 2 seconds
 [INFO] Finished at: Mon Apr 14 12:14:40 CEST 2008
 [INFO] Final Memory: 18M/33M
 [INFO] 
 
 D:\workspace_\fckeditor-java
 {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-309) outputFileNameMapping fails and includes parent's name


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

Michael Osipov updated MASSEMBLY-309:
-

Attachment: broken_site_dir.png

 outputFileNameMapping fails and includes parent's name
 --

 Key: MASSEMBLY-309
 URL: http://jira.codehaus.org/browse/MASSEMBLY-309
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-2
 Environment: Maven 2.0.9, JDK6, WinXP SP2 AND debian 4.0, Maven 
 2.0.8, JDK6 AND Maven Embedder m2eclipse 0.9.1
Reporter: Michael Osipov
Assignee: John Casey
Priority: Critical
 Fix For: 2.2-beta-3

 Attachments: broken_example.png, broken_site_dir.png, 
 expected_example.png, massembly-309.zip, proper_site_dir.png


 I have created a bin assembly descriptor containing:
 {code}
 moduleSets
   moduleSet
   includes
   include*:jar/include
   /includes
   binaries
   includeDependenciesfalse/includeDependencies
   outputFileNameMapping
   
 fckeditor-${module.artifactId}-${module.version}.${module.extension}
   /outputFileNameMapping
   unpackfalse/unpack
   /binaries
   /moduleSet
   moduleSet
   includes
   include*:jar/include
   /includes
   binaries
   
 attachmentClassifierjavadoc/attachmentClassifier
   includeDependenciesfalse/includeDependencies
   outputFileNameMapping
   
 fckeditor-${module.artifactId}-${module.version}-${module.classifier}.${module.extension}
   /outputFileNameMapping
   unpackfalse/unpack
   /binaries
   /moduleSet
   /moduleSets
 {code}
 The expected zip distro should look like the expected attachment but 
 sometimes (80 %) the outcome is the broken example.
 It seems like it does not resolves the module but the my parent. Browser my 
 source [here|http://dev.fckeditor.net/browser/FCKeditor.Java/branches/2.4] if 
 you like.
 Interesting to say if the bin distro is fine, maven reports (note the parent 
 warning):
 {code}
 [INFO] [assembly:assembly]
 [INFO] Reading assembly descriptor: src/main/assembly/src.xml
 [INFO] Reading assembly descriptor: src/main/assembly/bin.xml
 [INFO] Adding site directory to assembly : 
 D:\workspace_\fckeditor-java\target\s
 ite
 [INFO] Processing sources for module project: 
 net.fckeditor:java-demo:war:2.4-SN
 APSHOT
 [INFO] Processing sources for module project: 
 net.fckeditor:java-core:jar:2.4-SN
 APSHOT
 [INFO] Building zip: 
 D:\workspace_\fckeditor-java\target\fckeditor-java-2.4-SNAP
 SHOT-src.zip
 [WARNING] NOTE: Currently, inclusion of module dependencies may produce 
 unpredic
 table results if a version conflict occurs.
 [WARNING] NOTE: Currently, inclusion of module dependencies may produce 
 unpredic
 table results if a version conflict occurs.
 [INFO] Processing DependencySet (output=lib)
 [WARNING] Cannot include project artifact: 
 net.fckeditor:fckeditor-java:pom:2.4-
 SNAPSHOT; it doesn't have an associated file or directory.
 [INFO] Building zip: 
 D:\workspace_\fckeditor-java\target\fckeditor-java-2.4-SNAP
 SHOT-bin.zip
 [INFO]
 [INFO]
 [INFO] 
 
 [INFO] Reactor Summary:
 [INFO] 
 
 [INFO] FCKeditor.Java Integration  SUCCESS 
 [32.797s]
 [INFO] FCKeditor.Java Integration Core ... SUCCESS 
 [15.203s]
 [INFO] FCKeditor.Java Integration Demo Webapp  SUCCESS 
 [4.609s]
 [INFO] 
 
 [INFO] 
 
 [INFO] BUILD SUCCESSFUL
 [INFO] 
 
 [INFO] Total time: 1 minute 2 seconds
 [INFO] Finished at: Mon Apr 14 12:14:40 CEST 2008
 [INFO] Final Memory: 18M/33M
 [INFO] 
 
 D:\workspace_\fckeditor-java
 {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] Commented: (MASSEMBLY-285) regression: duplicate files added to the assembly

2008-09-19 Thread Artur Zielazny (JIRA)


[ 
http://jira.codehaus.org/browse/MASSEMBLY-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=148502#action_148502
 ] 

Artur Zielazny commented on MASSEMBLY-285:
--

With duplicateBehavior instead of duplicateBehaviour (one letter changed) it 
still does not work.

 regression: duplicate files added to the assembly
 -

 Key: MASSEMBLY-285
 URL: http://jira.codehaus.org/browse/MASSEMBLY-285
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-1
Reporter: Brett Porter
Assignee: John Casey
Priority: Blocker
 Fix For: 2.2-beta-3


 I found that it was possible to add a file twice to the assembly through 
 different filesets (a zip file) so that when it extracted it prompted for 
 overwrite.
 It should error out or collapse the entries (as 2.1 did).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MENFORCER-52) multi module build fails

2008-09-19 Thread Michael Brackx (JIRA)

multi module build fails


 Key: MENFORCER-52
 URL: http://jira.codehaus.org/browse/MENFORCER-52
 Project: Maven 2.x Enforcer Plugin
  Issue Type: Bug
Affects Versions: 1.0-alpha-3, 1.0-alpha-4
 Environment: maven 2.0.9
Reporter: Michael Brackx
Assignee: Brian Fox
 Attachments: enforcer-bug.zip

alpha-4 is not fixing my multi module projects build problems
attached is a simple project that fails when building with mvn verify

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MENFORCER-52) multi module build fails

2008-09-19 Thread Michael Brackx (JIRA)


[ 
http://jira.codehaus.org/browse/MENFORCER-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=148505#action_148505
 ] 

Michael Brackx commented on MENFORCER-52:
-

this probably a duplicate of MENFORCER-42
i saw MENFORCER-27 in the alpha-4 release notes and incorrectly assumed the 
multi module problems were fixed

 multi module build fails
 

 Key: MENFORCER-52
 URL: http://jira.codehaus.org/browse/MENFORCER-52
 Project: Maven 2.x Enforcer Plugin
  Issue Type: Bug
Affects Versions: 1.0-alpha-3, 1.0-alpha-4
 Environment: maven 2.0.9
Reporter: Michael Brackx
Assignee: Brian Fox
 Attachments: enforcer-bug.zip


 alpha-4 is not fixing my multi module projects build problems
 attached is a simple project that fails when building with mvn verify

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MEJB-33) Add support for fewer dependencies in client-jars

2008-09-19 Thread Karsten Tinnefeld (JIRA)

Add support for fewer dependencies in client-jars
-

 Key: MEJB-33
 URL: http://jira.codehaus.org/browse/MEJB-33
 Project: Maven 2.x Ejb Plugin
  Issue Type: New Feature
Affects Versions: 2.1
Reporter: Karsten Tinnefeld


Given a scenario, where several application tiers are installed on different 
servers, are realized as EJB3 applications, and packaged using maven.

When configuring an ejb module, I give dependencies to all dependency jars that 
are used to implement the features. However, they are currently all added as 
dependency to the client-jar artifacts as well, so that unused libraries are 
deployed on client servers.

I'd like to mark dependencies as server-jar only, e.g. by an 
clientJarExclusions configuration element to the plugin, which takes a set of 
exclusion elements like the exclusions-element in a dependency. These 
dependencies should behave as compile-scope in the server- and provided-scope 
in the client-jars. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MINVOKER-65) Support token localRepositoryUrl for filtering settings.xml

Support token localRepositoryUrl for filtering settings.xml
-

 Key: MINVOKER-65
 URL: http://jira.codehaus.org/browse/MINVOKER-65
 Project: Maven 2.x Invoker Plugin
  Issue Type: Improvement
Affects Versions: 1.2.1
Reporter: Benjamin Bentmann
Priority: Minor


To speed up the forked builds, we suggest people to use their local repo as a 
remote repo by putting something like
{code:xml}
urlfile://@localRepository@/url
{code}
into their {{settings.xml}}.

I am not really in favor of this practice since it promotes the wrong 
assumption that the simple string concatenation file:// + path delivers a 
valid file URL. Besides, there is frequent need for this URL so why not simply 
provide a dedicated filter token for 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] Closed: (MINVOKER-65) Support token localRepositoryUrl for filtering settings.xml


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

Benjamin Bentmann closed MINVOKER-65.
-

 Assignee: Benjamin Bentmann
   Resolution: Fixed
Fix Version/s: 1.3

Done in [r697096|http://svn.apache.org/viewvc?view=revrevision=697096].

 Support token localRepositoryUrl for filtering settings.xml
 -

 Key: MINVOKER-65
 URL: http://jira.codehaus.org/browse/MINVOKER-65
 Project: Maven 2.x Invoker Plugin
  Issue Type: Improvement
Affects Versions: 1.2.1
Reporter: Benjamin Bentmann
Assignee: Benjamin Bentmann
Priority: Minor
 Fix For: 1.3


 To speed up the forked builds, we suggest people to use their local repo as a 
 remote repo by putting something like
 {code:xml}
 urlfile://@localRepository@/url
 {code}
 into their {{settings.xml}}.
 I am not really in favor of this practice since it promotes the wrong 
 assumption that the simple string concatenation file:// + path delivers a 
 valid file URL. Besides, there is frequent need for this URL so why not 
 simply provide a dedicated filter token for 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: (MENFORCER-52) multi module build fails

2008-09-19 Thread Brian Fox (JIRA)


[ 
http://jira.codehaus.org/browse/MENFORCER-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=148507#action_148507
 ] 

Brian Fox commented on MENFORCER-52:


There isn't much in the plugin to do about this. The plugin tells maven that it 
needs dependencies resolved and so before it's executed for pom2 in your 
sample, maven tries to resolve the dependencies and fails. The plugin never 
even gets executed.

If I turn off resolution, then the plugin has to attempt to resolve everything 
by itself and this is full of problems because there currently is no way to ask 
maven to resolve x and its dependencies and get the same results as maven core 
would. It's due to faulty logic in the resolver that is order dependent and 
must have the entire dependency tree the same to guarantee the same results. 
This is being fixed in maven 3.0.

In the meantime, about all i can do is make a new enforcer goal that doesn't 
require dependencies, but then certain rules would fail. I've toyed with doing 
this for a while, but it almost seems more confusing and error prone.

 multi module build fails
 

 Key: MENFORCER-52
 URL: http://jira.codehaus.org/browse/MENFORCER-52
 Project: Maven 2.x Enforcer Plugin
  Issue Type: Bug
Affects Versions: 1.0-alpha-3, 1.0-alpha-4
 Environment: maven 2.0.9
Reporter: Michael Brackx
Assignee: Brian Fox
 Attachments: enforcer-bug.zip


 alpha-4 is not fixing my multi module projects build problems
 attached is a simple project that fails when building with mvn verify

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MDEP-181) useRepositoryLayout does not create proper repository layout

2008-09-19 Thread Brian Fox (JIRA)


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

Brian Fox closed MDEP-181.
--

Resolution: Fixed

 useRepositoryLayout does not create proper repository layout
 

 Key: MDEP-181
 URL: http://jira.codehaus.org/browse/MDEP-181
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
  Components: copy-dependencies
Affects Versions: 2.1
Reporter: Igor Fedorenko
Assignee: Brian Fox
 Fix For: 2.1

 Attachments: mdep-install-to-local-2.diff, mdep-install-to-local.diff


 repository created with useRepositoryLayout=true does not contain repository 
 metadata and does not have artifacts with expanded snapshot versions properly 
 dealt with. Attached patch changes the code to use ArtifactInstaller to 
 install artifacts to the target directory.

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

[jira] Commented: (MECLIPSE-79) exclude dependencies from the Classpath Container

2008-09-19 Thread Maarten Billemont (JIRA)


[ 
http://jira.codehaus.org/browse/MECLIPSE-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=148510#action_148510
 ] 

Maarten Billemont commented on MECLIPSE-79:
---

This does not appear to prevent the dependencies from being downloaded.

 exclude dependencies from the Classpath Container
 -

 Key: MECLIPSE-79
 URL: http://jira.codehaus.org/browse/MECLIPSE-79
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Improvement
  Components: Core : Dependencies resolution and build path
 Environment: Windows, Eclipse 3.1.2
Reporter: Martin Goldhahn
Assignee: nicolas de loof
 Fix For: 2.5

 Attachments: MECLIPSE-79.patch


 There are some dependencies that need to be in the POM in order to compile 
 the project (e.g. javax.servlet). When I use Sysdeo's Tomcat plugin, I get an 
 error because the servlet classes from the POM are included in the classpath 
 via the classpath container.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MECLIPSE-492) Maven Eclipse Plugin does not take dependencyManagement excludes into account when building eclipse CP configuration.

2008-09-19 Thread Maarten Billemont (JIRA)

Maven Eclipse Plugin does not take dependencyManagement excludes into account 
when building eclipse CP configuration.
-

 Key: MECLIPSE-492
 URL: http://jira.codehaus.org/browse/MECLIPSE-492
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Bug
  Components: Core : Dependencies resolution and build path
Affects Versions: 2.5.1
Reporter: Maarten Billemont


I have a parent pom that excludes xml-apis:xml-apis from dom4j:dom4j in the 
dependencyManagement section.  To make certain that as the project development 
progresses no artifacts depend on xml-apis:xml-apis (it is superseded by 
org.apache.xerces:xml-apis) I've forced the version of xml-apis:xml-apis in the 
same dependencyManagement section to be -1.  No artifact should depend on it 
since I'm excluding all dependencies on it manually and adding 
org.apache.xerces:xml-apis as a manual dependency.  In Maven this works fine.  
When I run maven-eclipse-plugin in a child module of this pom artifact which 
depends on dom4j:dom4j however, it tries to download xml-apis:xml-apis:jar:-1 
and after failing it adds it to the project's classpath configuration (which 
obviously causes eclipse to throw errors not being able to find 
xml-apis:xml-apis:jar:-1 in my local repository.

dependencyManagement
dependencies
dependency
groupIddom4j/groupId
artifactIddom4j/artifactId
version${dom4j.version}/version

excludes
exclude
groupIdxml-apis/groupId
artifactIdxml-apis/artifactId
/exclude
/excludes
/dependency

dependency
groupIdxml-apis/groupId
artifactIdxml-apis/artifactId
version-1/version
/dependency
/dependencies
/dependencyManagement

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MSOURCES-40) Add throws MojoExecutionException on getSources() mehtod


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

John Casey closed MSOURCES-40.
--

 Assignee: John Casey
   Resolution: Fixed
Fix Version/s: 2.1

 Add throws MojoExecutionException on getSources() mehtod
 

 Key: MSOURCES-40
 URL: http://jira.codehaus.org/browse/MSOURCES-40
 Project: Maven 2.x Source Plugin
  Issue Type: Bug
Affects Versions: 2.0.4
Reporter: Marvin Froeder
Assignee: John Casey
 Fix For: 2.1


 Hi,
 I'm extending maven-source-plugin on Tycho.
 In order to resolve source paths on Tycho I need to read some file, so, there 
 is a change of getting an IOException on my getSources() implementation.
 Patch:
 Index: src/main/java/org/apache/maven/plugin/source/AbstractSourceJarMojo.java
 ===
 --- src/main/java/org/apache/maven/plugin/source/AbstractSourceJarMojo.java   
 (revision 696714)
 +++ src/main/java/org/apache/maven/plugin/source/AbstractSourceJarMojo.java   
 (working copy)
 @@ -134,7 +134,8 @@
   * @param p not null
   * @return the compile or test sources
   */
 -protected abstract List getSources( MavenProject p );
 +protected abstract List getSources( MavenProject p ) 
 + throws MojoExecutionException;
  
  /**
   * @param p not null

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-2433) Maven looks for snapshots in offline mode

2008-09-19 Thread Benjamin Francisoud (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=148516#action_148516
 ] 

Benjamin Francisoud commented on MNG-2433:
--

I have the same issue apache rampart and it's related to some invalid version 
describe in the pom.xml (https://issues.apache.org/jira/browse/RAMPART-195)

Might be the same problem here.

as a side note: I don't think maven handle this kind of situation gracefully :(

 Maven looks for snapshots in offline mode
 -

 Key: MNG-2433
 URL: http://jira.codehaus.org/browse/MNG-2433
 Project: Maven 2
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 2.0.5
Reporter: Carsten Ziegeler
Assignee: Jason van Zyl
Priority: Critical
 Fix For: 2.0.6


 It seems that sometimes Maven2 is looking for snapshots in offline mode (this 
 happens for example in the Cocoon project). here is an output that might help:
 :\dev\workspace\cocoon-2.2\core\cocoon-webappmvn -o -Dmaven.test.skip=true 
 coc
 oon:deploy
 [INFO]
 NOTE: Maven is executing in offline mode. Any artifacts not already in your 
 loca
 l
 repository will be inaccessible.
 [INFO] Scanning for projects...
 [INFO] Searching repository for plugin with prefix: 'cocoon'.
 [INFO] org.apache.maven.plugins: checking for updates from snapshots
 [INFO] org.apache.maven.plugins: checking for updates from mortbay-repo
 [INFO] org.codehaus.mojo: checking for updates from snapshots
 [INFO] org.codehaus.mojo: checking for updates from mortbay-repo
 [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
 checkin
 g for updates from snapshots
 [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
 checkin
 g for updates from mortbay-repo
 [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
 checkin
 g for updates from central
 [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
 checkin
 g for updates from apache.snapshot
 [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
 checkin
 g for updates from apache-cvs
 [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
 checkin
 g for updates from apache.snapshots
 [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
 updat
 es from snapshots
 [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
 updat
 es from mortbay-repo
 [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
 updat
 es from central
 [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
 updat
 es from apache.snapshot
 [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
 updat
 es from apache-cvs
 [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
 updat
 es from apache.snapshots
 [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
 for
 updates from snapshots
 [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
 for
 updates from mortbay-repo
 [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
 for
 updates from central
 [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
 for
 updates from apache.snapshot
 [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
 for
 updates from apache-cvs
 [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
 for
 updates from apache.snapshots
 [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
 from s
 napshots
 [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
 from m
 ortbay-repo
 [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
 from c
 entral
 [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
 from a
 pache.snapshot
 [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
 from a
 pache-cvs
 [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
 from a
 pache.snapshots

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-3759) Integrate Mercury-driven wagon into Maven

Integrate Mercury-driven wagon into Maven
-

 Key: MNG-3759
 URL: http://jira.codehaus.org/browse/MNG-3759
 Project: Maven 2
  Issue Type: Improvement
  Components: Artifacts and Repositories
Affects Versions: 2.2.0-M1
Reporter: John Casey


See MERCURY-8. This optimized wagon implementation is on the release plan 
tentatively for 2.2.0-M1.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-2433) Maven looks for snapshots in offline mode

2008-09-19 Thread Benjamin Francisoud (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=148516#action_148516
 ] 

francisoud edited comment on MNG-2433 at 9/19/08 11:27 AM:


I have the same issue with apache rampart and it's related to some invalid 
version describe in the pom.xml 
(https://issues.apache.org/jira/browse/RAMPART-195)

Might be the same problem here.

as a side note: I don't think maven handle this kind of situation gracefully :(

  was (Author: francisoud):
I have the same issue apache rampart and it's related to some invalid 
version describe in the pom.xml 
(https://issues.apache.org/jira/browse/RAMPART-195)

Might be the same problem here.

as a side note: I don't think maven handle this kind of situation gracefully :(
  
 Maven looks for snapshots in offline mode
 -

 Key: MNG-2433
 URL: http://jira.codehaus.org/browse/MNG-2433
 Project: Maven 2
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 2.0.5
Reporter: Carsten Ziegeler
Assignee: Jason van Zyl
Priority: Critical
 Fix For: 2.0.6


 It seems that sometimes Maven2 is looking for snapshots in offline mode (this 
 happens for example in the Cocoon project). here is an output that might help:
 :\dev\workspace\cocoon-2.2\core\cocoon-webappmvn -o -Dmaven.test.skip=true 
 coc
 oon:deploy
 [INFO]
 NOTE: Maven is executing in offline mode. Any artifacts not already in your 
 loca
 l
 repository will be inaccessible.
 [INFO] Scanning for projects...
 [INFO] Searching repository for plugin with prefix: 'cocoon'.
 [INFO] org.apache.maven.plugins: checking for updates from snapshots
 [INFO] org.apache.maven.plugins: checking for updates from mortbay-repo
 [INFO] org.codehaus.mojo: checking for updates from snapshots
 [INFO] org.codehaus.mojo: checking for updates from mortbay-repo
 [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
 checkin
 g for updates from snapshots
 [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
 checkin
 g for updates from mortbay-repo
 [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
 checkin
 g for updates from central
 [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
 checkin
 g for updates from apache.snapshot
 [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
 checkin
 g for updates from apache-cvs
 [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
 checkin
 g for updates from apache.snapshots
 [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
 updat
 es from snapshots
 [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
 updat
 es from mortbay-repo
 [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
 updat
 es from central
 [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
 updat
 es from apache.snapshot
 [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
 updat
 es from apache-cvs
 [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
 updat
 es from apache.snapshots
 [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
 for
 updates from snapshots
 [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
 for
 updates from mortbay-repo
 [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
 for
 updates from central
 [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
 for
 updates from apache.snapshot
 [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
 for
 updates from apache-cvs
 [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
 for
 updates from apache.snapshots
 [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
 from s
 napshots
 [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
 from m
 ortbay-repo
 [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
 from c
 entral
 [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
 from a
 pache.snapshot
 [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
 from a
 pache-cvs
 [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
 from a
 pache.snapshots

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (DOXIASITETOOLS-13) NPE when generating Maven site

2008-09-19 Thread Adrian Tarau (JIRA)


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

Adrian Tarau updated DOXIASITETOOLS-13:
---

Attachment: Fixed_NPE_when_old_path_is_an_URL_and_new_path_is_NULL.patch

This fix works for me

 NPE when generating Maven site
 --

 Key: DOXIASITETOOLS-13
 URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-13
 Project: Maven Doxia Sitetools
  Issue Type: Bug
 Environment: SunOS 5.10 Generic_127128-11 i86pc i386 i86pc
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03)
 Java HotSpot(TM) Server VM (build 1.5.0_14-b03, mixed mode)
Reporter: Adrian Tarau
 Attachments: 
 Fixed_NPE_when_old_path_is_an_URL_and_new_path_is_NULL.patch


 Recently we moved on M2  Hudson. On our build server(SunOS) it fails with 
 this exception, but on my machine(Ubuntu 8.04, Linux 2.6.24-19-386 i686 
 GNU/Linux) it works great.
 java.lang.NullPointerException
   at 
 org.apache.maven.doxia.site.decoration.inheritance.PathUtils.getRelativePath(PathUtils.java:83)
   at 
 org.apache.maven.doxia.site.decoration.inheritance.PathUtils.convertPath(PathUtils.java:43)
   at 
 org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.convertPath(DefaultDecorationModelInheritanceAssembler.java:334)
   at 
 org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.resolveLinkItemPaths(DefaultDecorationModelInheritanceAssembler.java:255)
   at 
 org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.mergeLinkItemLists(DefaultDecorationModelInheritanceAssembler.java:277)
   at 
 org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.assembleBodyInheritance(DefaultDecorationModelInheritanceAssembler.java:192)
   at 
 org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.assembleModelInheritance(DefaultDecorationModelInheritanceAssembler.java:83)
   at 
 org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getDecorationModel(AbstractSiteRenderingMojo.java:253)
   at 
 org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getDecorationModel(AbstractSiteRenderingMojo.java:527)
   at 
 org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:466)
   at 
 org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:113)
   at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96)
   at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
   at 
 hudson.maven.agent.PluginManagerInterceptor.executeMojo(PluginManagerInterceptor.java:159)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
   at 
 org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:42)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
   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 hudson.maven.agent.Main.launch(Main.java:133)
   at hudson.maven.MavenBuilder.call(MavenBuilder.java:139)
   at 
 hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:543)
   at 
 hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:489)
   at hudson.remoting.UserRequest.perform(UserRequest.java:69)
   at hudson.remoting.UserRequest.perform(UserRequest.java:23)
   at hudson.remoting.Request$2.run(Request.java:213)
   at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)

[jira] Updated: (MASSEMBLY-306) Dependency resolution fails with an NPE for a provided dependency with a fixed version


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

John Casey updated MASSEMBLY-306:
-

  Assignee: John Casey
Remaining Estimate: 0 minutes
 Original Estimate: 0 minutes

 Dependency resolution fails with an NPE for a provided dependency with a 
 fixed version
 --

 Key: MASSEMBLY-306
 URL: http://jira.codehaus.org/browse/MASSEMBLY-306
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-2
 Environment: Maven 2.0.8, Java 1.6.0_03-b05
Reporter: Thomas Dudziak
Assignee: John Casey
Priority: Critical
 Fix For: 2.2-beta-3

   Original Estimate: 0 minutes
  Remaining Estimate: 0 minutes

 A POM like this:
 ?xml version=1.0 encoding=UTF-8?project
   modelVersion4.0.0/modelVersion
   groupIdmaven-test/groupId
   artifactIdmaven-test/artifactId
   namemaven-test/name
   version1.0-SNAPSHOT/version
   urlhttp://maven.apache.org/url
   dependencies
 dependency
   groupIdlog4j/groupId
   artifactIdlog4j/artifactId
   version[1.2.13]/version
   scopeprovided/scope
 /dependency
   /dependencies
   build
 plugins
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-assembly-plugin/artifactId
 version2.2-beta-2/version
 configuration
   descriptorRefs
 descriptorRefjar-with-dependencies/descriptorRef
   /descriptorRefs
   archive
 manifest
   mainClassning.dashboard.DashboardServer/mainClass
 /manifest
   /archive
 /configuration
 executions
   execution
 idmake-assembly/id
 phasepackage/phase
 goals
   goalattached/goal
 /goals
   /execution
 /executions
   /plugin
 /plugins
   /build
 /project
 fails with this error:
 [INFO] Processing DependencySet (output=)
 [INFO] 
 
 [ERROR] FATAL ERROR
 [INFO] 
 
 [INFO] version was null for log4j:log4j
 [INFO] 
 
 [INFO] Trace
 java.lang.NullPointerException: version was null for log4j:log4j
 at 
 org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:362)
 at 
 org.apache.maven.artifact.DefaultArtifact.getId(DefaultArtifact.java:225)
 at 
 org.apache.maven.shared.artifact.filter.ScopeArtifactFilter.include(ScopeArtifactFilter.java:142)
 at 
 org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(MavenMetadataSource.java:345)
 at 
 org.apache.maven.plugin.assembly.artifact.DefaultDependencyResolver.resolveDependencies(DefaultDependencyResolver.java:123)
 at 
 org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.resolveDependencyArtifacts(AddDependencySetsTask.java:205)
 at 
 org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.addDependencySet(AddDependencySetsTask.java:132)
 at 
 org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.execute(AddDependencySetsTask.java:116)
 at 
 org.apache.maven.plugin.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:74)
 at 
 org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:129)
 at 
 org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:322)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

[jira] Work started: (MASSEMBLY-306) Dependency resolution fails with an NPE for a provided dependency with a fixed version


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

Work on MASSEMBLY-306 started by John Casey.

 Dependency resolution fails with an NPE for a provided dependency with a 
 fixed version
 --

 Key: MASSEMBLY-306
 URL: http://jira.codehaus.org/browse/MASSEMBLY-306
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-2
 Environment: Maven 2.0.8, Java 1.6.0_03-b05
Reporter: Thomas Dudziak
Assignee: John Casey
Priority: Critical
 Fix For: 2.2-beta-3

   Original Estimate: 0 minutes
  Remaining Estimate: 0 minutes

 A POM like this:
 ?xml version=1.0 encoding=UTF-8?project
   modelVersion4.0.0/modelVersion
   groupIdmaven-test/groupId
   artifactIdmaven-test/artifactId
   namemaven-test/name
   version1.0-SNAPSHOT/version
   urlhttp://maven.apache.org/url
   dependencies
 dependency
   groupIdlog4j/groupId
   artifactIdlog4j/artifactId
   version[1.2.13]/version
   scopeprovided/scope
 /dependency
   /dependencies
   build
 plugins
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-assembly-plugin/artifactId
 version2.2-beta-2/version
 configuration
   descriptorRefs
 descriptorRefjar-with-dependencies/descriptorRef
   /descriptorRefs
   archive
 manifest
   mainClassning.dashboard.DashboardServer/mainClass
 /manifest
   /archive
 /configuration
 executions
   execution
 idmake-assembly/id
 phasepackage/phase
 goals
   goalattached/goal
 /goals
   /execution
 /executions
   /plugin
 /plugins
   /build
 /project
 fails with this error:
 [INFO] Processing DependencySet (output=)
 [INFO] 
 
 [ERROR] FATAL ERROR
 [INFO] 
 
 [INFO] version was null for log4j:log4j
 [INFO] 
 
 [INFO] Trace
 java.lang.NullPointerException: version was null for log4j:log4j
 at 
 org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:362)
 at 
 org.apache.maven.artifact.DefaultArtifact.getId(DefaultArtifact.java:225)
 at 
 org.apache.maven.shared.artifact.filter.ScopeArtifactFilter.include(ScopeArtifactFilter.java:142)
 at 
 org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(MavenMetadataSource.java:345)
 at 
 org.apache.maven.plugin.assembly.artifact.DefaultDependencyResolver.resolveDependencies(DefaultDependencyResolver.java:123)
 at 
 org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.resolveDependencyArtifacts(AddDependencySetsTask.java:205)
 at 
 org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.addDependencySet(AddDependencySetsTask.java:132)
 at 
 org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.execute(AddDependencySetsTask.java:116)
 at 
 org.apache.maven.plugin.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:74)
 at 
 org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:129)
 at 
 org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:322)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at

[jira] Created: (MSHARED-74) ScopeArtifactFilter throws NPE when logging an excluded artifact that uses a version range

ScopeArtifactFilter throws NPE when logging an excluded artifact that uses a 
version range
--

 Key: MSHARED-74
 URL: http://jira.codehaus.org/browse/MSHARED-74
 Project: Maven Shared Components
  Issue Type: Bug
  Components: maven-common-artifact-filters
Reporter: John Casey




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MSHARED-74) ScopeArtifactFilter throws NPE when logging an excluded artifact that uses a version range


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

John Casey closed MSHARED-74.
-

Resolution: Fixed

fixed and unit tested.

 ScopeArtifactFilter throws NPE when logging an excluded artifact that uses a 
 version range
 --

 Key: MSHARED-74
 URL: http://jira.codehaus.org/browse/MSHARED-74
 Project: Maven Shared Components
  Issue Type: Bug
  Components: maven-common-artifact-filters
Reporter: John Casey
Assignee: John Casey



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-306) Dependency resolution fails with an NPE for a provided dependency with a fixed version


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

John Casey closed MASSEMBLY-306.


Resolution: Fixed

 Dependency resolution fails with an NPE for a provided dependency with a 
 fixed version
 --

 Key: MASSEMBLY-306
 URL: http://jira.codehaus.org/browse/MASSEMBLY-306
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-2
 Environment: Maven 2.0.8, Java 1.6.0_03-b05
Reporter: Thomas Dudziak
Assignee: John Casey
Priority: Critical
 Fix For: 2.2-beta-3

   Original Estimate: 0 minutes
  Remaining Estimate: 0 minutes

 A POM like this:
 ?xml version=1.0 encoding=UTF-8?project
   modelVersion4.0.0/modelVersion
   groupIdmaven-test/groupId
   artifactIdmaven-test/artifactId
   namemaven-test/name
   version1.0-SNAPSHOT/version
   urlhttp://maven.apache.org/url
   dependencies
 dependency
   groupIdlog4j/groupId
   artifactIdlog4j/artifactId
   version[1.2.13]/version
   scopeprovided/scope
 /dependency
   /dependencies
   build
 plugins
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-assembly-plugin/artifactId
 version2.2-beta-2/version
 configuration
   descriptorRefs
 descriptorRefjar-with-dependencies/descriptorRef
   /descriptorRefs
   archive
 manifest
   mainClassning.dashboard.DashboardServer/mainClass
 /manifest
   /archive
 /configuration
 executions
   execution
 idmake-assembly/id
 phasepackage/phase
 goals
   goalattached/goal
 /goals
   /execution
 /executions
   /plugin
 /plugins
   /build
 /project
 fails with this error:
 [INFO] Processing DependencySet (output=)
 [INFO] 
 
 [ERROR] FATAL ERROR
 [INFO] 
 
 [INFO] version was null for log4j:log4j
 [INFO] 
 
 [INFO] Trace
 java.lang.NullPointerException: version was null for log4j:log4j
 at 
 org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:362)
 at 
 org.apache.maven.artifact.DefaultArtifact.getId(DefaultArtifact.java:225)
 at 
 org.apache.maven.shared.artifact.filter.ScopeArtifactFilter.include(ScopeArtifactFilter.java:142)
 at 
 org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(MavenMetadataSource.java:345)
 at 
 org.apache.maven.plugin.assembly.artifact.DefaultDependencyResolver.resolveDependencies(DefaultDependencyResolver.java:123)
 at 
 org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.resolveDependencyArtifacts(AddDependencySetsTask.java:205)
 at 
 org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.addDependencySet(AddDependencySetsTask.java:132)
 at 
 org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.execute(AddDependencySetsTask.java:116)
 at 
 org.apache.maven.plugin.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:74)
 at 
 org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:129)
 at 
 org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:322)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at

[jira] Updated: (MASSEMBLY-196) use of repository assembly is no longer working


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

John Casey updated MASSEMBLY-196:
-

  Assignee: John Casey
Remaining Estimate: 0 minutes
 Original Estimate: 0 minutes

 use of repository assembly is no longer working
 ---

 Key: MASSEMBLY-196
 URL: http://jira.codehaus.org/browse/MASSEMBLY-196
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-1
Reporter: Brett Porter
Assignee: John Casey
 Fix For: 2.2-beta-3

   Original Estimate: 0 minutes
  Remaining Estimate: 0 minutes

 I have the following that works in 2.1:
   repositories
 repository
   outputDirectoryrepository/releases/outputDirectory
   includeMetadatatrue/includeMetadata
   groupVersionAlignments
 groupVersionAlignment
   idorg.apache.maven/id
   version2.0.5/version
   excludes
 excludemaven-plugin-surrogate-parent/exclude
 excludemaven-archetype/exclude
 excludemaven-archetype-core/exclude
 excludemaven-archiver/exclude
 excludemaven-parent/exclude
 excludemaven-jxr/exclude
 excludemaven-plugin-tools-java/exclude
 excludemaven-plugin-tools-beanshell/exclude
 excludemaven-plugin-tools-api/exclude
 excludemaven-plugin-tools/exclude
   /excludes
 /groupVersionAlignment
   /groupVersionAlignments
 /repository
   /repositories
 However, in 2.2-beta-1 it results in an empty directory being created in the 
 assembly instead of copying the repository contents.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-196) use of repository assembly is no longer working


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

Work on MASSEMBLY-196 started by John Casey.

 use of repository assembly is no longer working
 ---

 Key: MASSEMBLY-196
 URL: http://jira.codehaus.org/browse/MASSEMBLY-196
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-1
Reporter: Brett Porter
Assignee: John Casey
 Fix For: 2.2-beta-3

   Original Estimate: 0 minutes
  Remaining Estimate: 0 minutes

 I have the following that works in 2.1:
   repositories
 repository
   outputDirectoryrepository/releases/outputDirectory
   includeMetadatatrue/includeMetadata
   groupVersionAlignments
 groupVersionAlignment
   idorg.apache.maven/id
   version2.0.5/version
   excludes
 excludemaven-plugin-surrogate-parent/exclude
 excludemaven-archetype/exclude
 excludemaven-archetype-core/exclude
 excludemaven-archiver/exclude
 excludemaven-parent/exclude
 excludemaven-jxr/exclude
 excludemaven-plugin-tools-java/exclude
 excludemaven-plugin-tools-beanshell/exclude
 excludemaven-plugin-tools-api/exclude
 excludemaven-plugin-tools/exclude
   /excludes
 /groupVersionAlignment
   /groupVersionAlignments
 /repository
   /repositories
 However, in 2.2-beta-1 it results in an empty directory being created in the 
 assembly instead of copying the repository contents.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MRESOURCES-58) Filter not working on src/test/resources


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

Olivier Lamy updated MRESOURCES-58:
---

 Assignee: Olivier Lamy
Fix Version/s: 2.3

 Filter not working on src/test/resources
 

 Key: MRESOURCES-58
 URL: http://jira.codehaus.org/browse/MRESOURCES-58
 Project: Maven 2.x Resources Plugin
  Issue Type: Bug
Affects Versions: 2.2
 Environment: OS: Linux (Ubuntu gutsy) 2.6.22-14-generic. 
 Maven: 2.0.8
Reporter: Lorand Somogyi
Assignee: Olivier Lamy
 Fix For: 2.3

 Attachments: test.zip


 Filter does not work for test-resources. 
 I tried:
 1. No definition in pom.xml
 2. Defining the resource in pom.xml
 In the attached really basic case the property comes from pom.xml property, 
 but it does fail for filter file too. And even for default pom.xml variables 
 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: (MRESOURCES-24) Force overwrite resources defined in profiles


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

Olivier Lamy updated MRESOURCES-24:
---

 Assignee: Olivier Lamy  (was: Stephane Nicoll)
Fix Version/s: 2.3

 Force overwrite resources defined in profiles
 -

 Key: MRESOURCES-24
 URL: http://jira.codehaus.org/browse/MRESOURCES-24
 Project: Maven 2.x Resources Plugin
  Issue Type: Improvement
Affects Versions: 2.2
Reporter: Kees de Kooter
Assignee: Olivier Lamy
 Fix For: 2.3


 I am using profiles to package for different environments. The profile 
 typically defines a couple of properties files with db and log settings.
 The resource plugin only overwrites files that are changed, so the profile 
 specific resources with the same name are ignored and the wrong resources are 
 packaged.
 I could do a clean first, but that seems a bit of a crude approach. 
 I would prefer to have a property like overwrite=true on a resource.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MRESOURCES-68) resources:resources overwrites filtered resources in target directory even if unchanged


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

Olivier Lamy closed MRESOURCES-68.
--

Resolution: Duplicate

 resources:resources overwrites filtered resources in target directory even if 
 unchanged
 ---

 Key: MRESOURCES-68
 URL: http://jira.codehaus.org/browse/MRESOURCES-68
 Project: Maven 2.x Resources Plugin
  Issue Type: Improvement
Affects Versions: 2.2
 Environment: Linux, JDK 1.5
Reporter: Johannes Martin

 When processing filtered resources, resources:resources overwrites existing 
 files in the target directory even if they are unchanged.
 It would be helpful if the plugin would write to a temporary file, then 
 compare the contents of old and new, and overwrite only if the contents have 
 changed. That way, the jar plugin won't have to repackage the whole jar 
 (assuming forced=false) and so on.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MRESOURCES-74) configuring file extension to not filtering


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

Olivier Lamy updated MRESOURCES-74:
---

 Assignee: Olivier Lamy
Fix Version/s: 2.3

 configuring file extension to not filtering
 ---

 Key: MRESOURCES-74
 URL: http://jira.codehaus.org/browse/MRESOURCES-74
 Project: Maven 2.x Resources Plugin
  Issue Type: New Feature
Affects Versions: 2.1, 2.2, 2.3
Reporter: Olivier Lamy
Assignee: Olivier Lamy
 Fix For: 2.3


 Currently if filtered directories contains some binaries files they will be 
 filtered.
 The maven-filtering has some default extensions (jpg, jpeg, gif, bmp, png) to 
 not apply filters but users must be able to add some.
 Note : users can do it but they need to add some extra includes excludes 
 configuration elements.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MRESOURCES-37) Refactor

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

Olivier Lamy closed MRESOURCES-37.
--

Assignee: Olivier Lamy
Resolution: Won't Fix

Due to refactoring with using the maven-filtering component.
This patch is not usable anymore.

Refactor

Key: MRESOURCES-37
URL: http://jira.codehaus.org/browse/MRESOURCES-37
Project: Maven 2.x Resources Plugin
Issue Type: Improvement
Reporter: Franz Allan Valencia See
Assignee: Olivier Lamy
Priority: Minor
Attachments: MRESOURCES-37-maven-resources-plugin-2.patch,
MRESOURCES-37-maven-resources-plugin-3.patch,
MRESOURCES-37-maven-resources-plugin.patch

Good day,
Right now, ResourcesMojo is inherited by TestResourcesMojo...not the usual
setup (there's usually an abstract mojo to inherit, not a working concrete
mojo).
Furthermore, the TestResourcesMojoTest seems to be not finished as well. And
it seems as though it was going to be a duplicate of ResourcesMojoTest. Thus,
i refactored those too. Actually, i was about to complete the
TestResourcesMojoTest when I decided to refactor everything.
Anyway, I most just extracted some classes and methods. Other than that, the
overall flow is still the same. ...And deleted an unused part of
plugin-config.xml to avoid confusion when traciing the test cases.
Cheers,
Franz

[jira] Closed: (MASSEMBLY-196) use of repository assembly is no longer working


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

John Casey closed MASSEMBLY-196.


Resolution: Cannot Reproduce

I've introduced an integration test at:

http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-assembly-plugin/src/it/projects/repositories/massembly-196/

and I've been unable to reproduce the problem. If you can reproduce the 
problem, please let me know why my integration test is wrong, and reopen this 
issue.

 use of repository assembly is no longer working
 ---

 Key: MASSEMBLY-196
 URL: http://jira.codehaus.org/browse/MASSEMBLY-196
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-1
Reporter: Brett Porter
Assignee: John Casey
 Fix For: 2.2-beta-3

   Original Estimate: 0 minutes
  Remaining Estimate: 0 minutes

 I have the following that works in 2.1:
   repositories
 repository
   outputDirectoryrepository/releases/outputDirectory
   includeMetadatatrue/includeMetadata
   groupVersionAlignments
 groupVersionAlignment
   idorg.apache.maven/id
   version2.0.5/version
   excludes
 excludemaven-plugin-surrogate-parent/exclude
 excludemaven-archetype/exclude
 excludemaven-archetype-core/exclude
 excludemaven-archiver/exclude
 excludemaven-parent/exclude
 excludemaven-jxr/exclude
 excludemaven-plugin-tools-java/exclude
 excludemaven-plugin-tools-beanshell/exclude
 excludemaven-plugin-tools-api/exclude
 excludemaven-plugin-tools/exclude
   /excludes
 /groupVersionAlignment
   /groupVersionAlignments
 /repository
   /repositories
 However, in 2.2-beta-1 it results in an empty directory being created in the 
 assembly instead of copying the repository contents.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-151) Documentation for the assembly plugin is utterly confusing

[
http://jira.codehaus.org/browse/MASSEMBLY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=148553#action_148553
]

John Casey commented on MASSEMBLY-151:
--

the outputFileNameMapping documentation needs to be reviewed.

Documentation for the assembly plugin is utterly confusing
--

Key: MASSEMBLY-151
URL: http://jira.codehaus.org/browse/MASSEMBLY-151
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.1, 2.2
Reporter: Nigel Magnay
Fix For: 2.2-beta-3

This is going to come across as a whinge, I'm afraid, but the assembly plugin
is a fairly important vital component in M2; I find it very confusing and
I've been using it for a bit. I have observed it putting off other people
from using m2 at all, which is I think a shame.
I'd document it myself, but I don't understand the differences between some
of the goals (and I don't understand why the fix in MASSEMBLY-97 is
neccessary).
In the goals page,there's lots of options that seem to overlap or do the same
thing. There's no clue (other than trial and error) as to why some of them
will work some times, and some will not (e.g. in multiproject builds). What's
worse is some of the problems only appear in specific circumstances (E.g.
doing multiprojects in a 'clean' build').
This either needs documenting, or (better), fixing in the code. We have (from
the site):
assembly:assemblyAssemble an application bundle or distribution
from an assembly descriptor.
Good, seems logical to me
assembly:unpack Unpack project dependencies. Currently supports
dependencies of type jar and zip.
The reverse. Yep.
assembly:attached Assemble an application bundle or distribution from an
assembly descriptor. Do not specify a phase, so make it usable in a reactor
environment where forking would create issues.
Erk? How should a user read this? To me usable in a reactor environment
where forking would create issues reads to me as there's a bug in
assembly:assembly if used in a multiproject build.
- it assumes that the user knows a multi project build is a 'reactor' build
- why can't assembly:assembly be fixed so it does work in multiproject
builds? Why can't it detect the environment, and do the 'right thing' (or at
the very least spit out a warning) ?
This is just inviting the user to pick the wrong goal.
assembly:directoryAssemble an application bundle or distribution.
Without a descriptor? If I click the link to the goal parameters for this or
for assembly:assembly, I get identical pages of parameters. How is this
different?
assembly:directory-inline Assemble an application bundle or distribution
from an assembly descriptor without launching a parallel lifecycle build.
In what scenarios would I as a user need this? Is it for a bug workaround?
Would it not be better as a parameter to turn off/on parallel lifecycle
build ?
assembly:single Assemble an application bundle or distribution from an
assembly descriptor. Do not specify a phase, so make it usable in a reactor
environment where forking would create issues. Do not specify it as an
aggregator, so it is only for a single project. Both cases aid it in working
around issues with the Maven lifecycle that should be addressed in Maven 2.1.
A whole heap of information that seems to boil down to there is a bug, and
a heap of confusing terminology (do not specify it as an aggregator).
When should this be used ? Every time you actually want assembly:assembly in
a multiproject build? How is it different to assembly:attached?
It seems to me that the plugin does 2 things. (pack things, unpack things).
All these additional goals seem to be (I can't tell this) workarounds for
bugs.
Why can't we just have
assembly:assembly
and
assembly:unpack
and make the plugin work properly? If multiproject builds fail on fork, then
stop the plugin from forking until it can be fixed (or keep it as a cryptic
option for people that really want to optimise their builds rather than
confusing new customers).

[jira] Closed: (MASSEMBLY-309) outputFileNameMapping fails and includes parent's name


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

John Casey closed MASSEMBLY-309.


Resolution: Won't Fix

we had to change the behavior of ${artifactId} and ${version} to be consistent 
with the rest of the descriptor (i.e. to reference the project currently being 
built). To make these expressions more intuitive, we're using 
${artifact.artifactId} or ${module.artifactId} in the case of a module binary 
instead.

I've noted this as an area where the documentation needs to be updated in 
MASSEMBLY-151.

 outputFileNameMapping fails and includes parent's name
 --

 Key: MASSEMBLY-309
 URL: http://jira.codehaus.org/browse/MASSEMBLY-309
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-2
 Environment: Maven 2.0.9, JDK6, WinXP SP2 AND debian 4.0, Maven 
 2.0.8, JDK6 AND Maven Embedder m2eclipse 0.9.1
Reporter: Michael Osipov
Assignee: John Casey
Priority: Critical
 Fix For: 2.2-beta-3

 Attachments: broken_example.png, broken_site_dir.png, 
 expected_example.png, massembly-309.zip, proper_site_dir.png


 I have created a bin assembly descriptor containing:
 {code}
 moduleSets
   moduleSet
   includes
   include*:jar/include
   /includes
   binaries
   includeDependenciesfalse/includeDependencies
   outputFileNameMapping
   
 fckeditor-${module.artifactId}-${module.version}.${module.extension}
   /outputFileNameMapping
   unpackfalse/unpack
   /binaries
   /moduleSet
   moduleSet
   includes
   include*:jar/include
   /includes
   binaries
   
 attachmentClassifierjavadoc/attachmentClassifier
   includeDependenciesfalse/includeDependencies
   outputFileNameMapping
   
 fckeditor-${module.artifactId}-${module.version}-${module.classifier}.${module.extension}
   /outputFileNameMapping
   unpackfalse/unpack
   /binaries
   /moduleSet
   /moduleSets
 {code}
 The expected zip distro should look like the expected attachment but 
 sometimes (80 %) the outcome is the broken example.
 It seems like it does not resolves the module but the my parent. Browser my 
 source [here|http://dev.fckeditor.net/browser/FCKeditor.Java/branches/2.4] if 
 you like.
 Interesting to say if the bin distro is fine, maven reports (note the parent 
 warning):
 {code}
 [INFO] [assembly:assembly]
 [INFO] Reading assembly descriptor: src/main/assembly/src.xml
 [INFO] Reading assembly descriptor: src/main/assembly/bin.xml
 [INFO] Adding site directory to assembly : 
 D:\workspace_\fckeditor-java\target\s
 ite
 [INFO] Processing sources for module project: 
 net.fckeditor:java-demo:war:2.4-SN
 APSHOT
 [INFO] Processing sources for module project: 
 net.fckeditor:java-core:jar:2.4-SN
 APSHOT
 [INFO] Building zip: 
 D:\workspace_\fckeditor-java\target\fckeditor-java-2.4-SNAP
 SHOT-src.zip
 [WARNING] NOTE: Currently, inclusion of module dependencies may produce 
 unpredic
 table results if a version conflict occurs.
 [WARNING] NOTE: Currently, inclusion of module dependencies may produce 
 unpredic
 table results if a version conflict occurs.
 [INFO] Processing DependencySet (output=lib)
 [WARNING] Cannot include project artifact: 
 net.fckeditor:fckeditor-java:pom:2.4-
 SNAPSHOT; it doesn't have an associated file or directory.
 [INFO] Building zip: 
 D:\workspace_\fckeditor-java\target\fckeditor-java-2.4-SNAP
 SHOT-bin.zip
 [INFO]
 [INFO]
 [INFO] 
 
 [INFO] Reactor Summary:
 [INFO] 
 
 [INFO] FCKeditor.Java Integration  SUCCESS 
 [32.797s]
 [INFO] FCKeditor.Java Integration Core ... SUCCESS 
 [15.203s]
 [INFO] FCKeditor.Java Integration Demo Webapp  SUCCESS 
 [4.609s]
 [INFO] 
 
 [INFO] 
 
 [INFO] BUILD SUCCESSFUL
 [INFO] 
 
 [INFO] Total time: 1 minute 2 seconds
 [INFO] Finished at: Mon Apr 14 12:14:40 CEST 2008
 [INFO] Final Memory:

[jira] Commented: (MRESOURCES-31) Dependency resolution for resource filtering


[ 
http://jira.codehaus.org/browse/MRESOURCES-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=148557#action_148557
 ] 

Olivier Lamy commented on MRESOURCES-31:


can you explain your use case ?

 Dependency resolution for resource filtering
 

 Key: MRESOURCES-31
 URL: http://jira.codehaus.org/browse/MRESOURCES-31
 Project: Maven 2.x Resources Plugin
  Issue Type: Wish
Affects Versions: 2.2
Reporter: Daniel Holmen
Priority: Minor

 I've been trying to use the project.compileClasspathElements  property in a 
 filtered resource, but discovered that Resources plugin isn't set up to 
 require dependency resolution. The result of this is that i cannot use any of 
 the classpath properties in my filtered resources.
 The solution is quite simple, just add a @requiresDependencyResolution 
 annotation to ResourcesMojo. I have no idea if this causes any bad 
 side-effects - but it seemed to work properly when I tested it locally.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MRESOURCES-67) StringIndexOutOfBoundsException if last line in filtered file does not have a newline as it's last character.


[ 
http://jira.codehaus.org/browse/MRESOURCES-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=148559#action_148559
 ] 

Olivier Lamy commented on MRESOURCES-67:


can you attach a simple project test case here ?

 StringIndexOutOfBoundsException if last line in filtered file does not have a 
 newline as it's last character.
 -

 Key: MRESOURCES-67
 URL: http://jira.codehaus.org/browse/MRESOURCES-67
 Project: Maven 2.x Resources Plugin
  Issue Type: Bug
Affects Versions: 2.2
Reporter: Paul Smith
Priority: Trivial

 When doing filtering, if one of the files being filtered has it's last line 
 without a proper line feed, an exception is thrown:
 java.lang.StringIndexOutOfBoundsException: String index out of range: 0
   at java.lang.String.charAt(String.java:687)
   at 
 org.apache.maven.plugin.resources.util.InterpolationFilterReader.read(InterpolationFilterReader.java:193)
   at 
 org.apache.maven.plugin.resources.util.InterpolationFilterReader.read(InterpolationFilterReader.java:201)
   at 
 org.apache.maven.plugin.resources.util.InterpolationFilterReader.read(InterpolationFilterReader.java:162)
   at java.io.Reader.read(Reader.java:123)
   at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:212)
   at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:200)
   at 
 org.apache.maven.plugin.resources.ResourcesMojo.copyFile(ResourcesMojo.java:269)
   at 
 org.apache.maven.plugin.resources.ResourcesMojo.copyResources(ResourcesMojo.java:183)
   at 
 org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo.java:100)
   at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
   at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
   at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 Trivial workaround to add a CR/LF or whatever, but took a while to work 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] Closed: (MRESOURCES-33) testResources testResource were not mentioned in the docck-acceptable maven-resources-plugin documentation


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

Olivier Lamy closed MRESOURCES-33.
--

 Assignee: Olivier Lamy
   Resolution: Fixed
Fix Version/s: 2.3

Currently the plugin has some documentations.

 testResources  testResource were not mentioned in the docck-acceptable 
 maven-resources-plugin documentation
 

 Key: MRESOURCES-33
 URL: http://jira.codehaus.org/browse/MRESOURCES-33
 Project: Maven 2.x Resources Plugin
  Issue Type: Improvement
Reporter: Franz Allan Valencia See
Assignee: Olivier Lamy
Priority: Minor
 Fix For: 2.3


 testResources  testResource were not mentioned in the docck-acceptable 
 maven-resources-plugin documentation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-309) outputFileNameMapping fails and includes parent's name


[ 
http://jira.codehaus.org/browse/MASSEMBLY-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=148561#action_148561
 ] 

Michael Osipov commented on MASSEMBLY-309:
--

John,

I commented on #151 too. Thanks for your help. I have made some tests and you 
are right. The interpolation behavior between beta 1 and beta 2 has changed! 
The site problem is gone after I have changed
{noformat}
moduleSet
sources

includeModuleDirectoryfalse/includeModuleDirectory
fileSets
fileSet
outputDirectory
site/${artifactId}
/outputDirectory

directorytarget/site/directory
/fileSet
/fileSets
/sources
/moduleSet
{noformat}
to
{noformat}
moduleSet
sources

includeModuleDirectoryfalse/includeModuleDirectory
fileSets
fileSet
outputDirectory

site/${module.artifactId}
/outputDirectory

directorytarget/site/directory
/fileSet
/fileSets
/sources
/moduleSet
{noformat}

 outputFileNameMapping fails and includes parent's name
 --

 Key: MASSEMBLY-309
 URL: http://jira.codehaus.org/browse/MASSEMBLY-309
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-2
 Environment: Maven 2.0.9, JDK6, WinXP SP2 AND debian 4.0, Maven 
 2.0.8, JDK6 AND Maven Embedder m2eclipse 0.9.1
Reporter: Michael Osipov
Assignee: John Casey
Priority: Critical
 Fix For: 2.2-beta-3

 Attachments: broken_example.png, broken_site_dir.png, 
 expected_example.png, massembly-309.zip, proper_site_dir.png


 I have created a bin assembly descriptor containing:
 {code}
 moduleSets
   moduleSet
   includes
   include*:jar/include
   /includes
   binaries
   includeDependenciesfalse/includeDependencies
   outputFileNameMapping
   
 fckeditor-${module.artifactId}-${module.version}.${module.extension}
   /outputFileNameMapping
   unpackfalse/unpack
   /binaries
   /moduleSet
   moduleSet
   includes
   include*:jar/include
   /includes
   binaries
   
 attachmentClassifierjavadoc/attachmentClassifier
   includeDependenciesfalse/includeDependencies
   outputFileNameMapping
   
 fckeditor-${module.artifactId}-${module.version}-${module.classifier}.${module.extension}
   /outputFileNameMapping
   unpackfalse/unpack
   /binaries
   /moduleSet
   /moduleSets
 {code}
 The expected zip distro should look like the expected attachment but 
 sometimes (80 %) the outcome is the broken example.
 It seems like it does not resolves the module but the my parent. Browser my 
 source [here|http://dev.fckeditor.net/browser/FCKeditor.Java/branches/2.4] if 
 you like.
 Interesting to say if the bin distro is fine, maven reports (note the parent 
 warning):
 {code}
 [INFO] [assembly:assembly]
 [INFO] Reading assembly descriptor: src/main/assembly/src.xml
 [INFO] Reading assembly descriptor: src/main/assembly/bin.xml
 [INFO] Adding site directory to assembly : 
 D:\workspace_\fckeditor-java\target\s
 ite
 [INFO] Processing sources for module project: 
 net.fckeditor:java-demo:war:2.4-SN
 APSHOT
 [INFO] Processing sources for module project: 
 net.fckeditor:java-core:jar:2.4-SN
 APSHOT
 [INFO] Building zip: 
 D:\workspace_\fckeditor-java\target\fckeditor-java-2.4-SNAP
 SHOT-src.zip
 [WARNING] NOTE: Currently, inclusion of module dependencies may produce 
 unpredic
 table results if a version conflict occurs.
 [WARNING] NOTE: Currently, inclusion of module dependencies may

[jira] Closed: (MRESOURCES-28) Maven 2.x Resources Plugin is not compliant with maven's codestyle