date:20090212

[jira] Created: (MNG-4032) Test jar dependency not available for for main classes in multi module builds

2009-02-12 Thread Henrik Brautaset Aronsen (JIRA)

Test jar dependency not available for for main classes in multi module builds
-

 Key: MNG-4032
 URL: http://jira.codehaus.org/browse/MNG-4032
 Project: Maven 2
  Issue Type: Bug
  Components: Bootstrap  Build, Class Loading, Dependencies, 
Inheritance and Interpolation
Affects Versions: 2.1.0-M1, 2.0.9
 Environment: MacOSX, Linux
Reporter: Henrik Brautaset Aronsen
 Attachments: tests-dependency.zip

I have a module layout like this:
{noformat}
root -+- first
  +- second
{noformat}
I have the test-jar plugin enabled, thus a *-tests.jar is built for each 
module.  In the second module, I have defined a dependency to first's tests jar:
{noformat}
   dependency
  groupIdme/groupId
  artifactIdfirst/artifactId
  classifiertests/classifier
  version1.0-SNAPSHOT/version
  scopecompile/scope
   /dependency
{noformat}

And here's the problem:  A class in the second main folder imports a class from 
the first test folder.   If I build the second module separately it builds like 
it should.  But if I build both modules from the root module I get a 
compilation failure:
{noformat}
/.../root/second/src/main/java/me/SecondMain.java:[3,10] cannot find symbol
symbol  : class FirstTest
location: package me
{noformat}
A class in second's test folder also includes me.FirstTest, and it always 
compiles.  The scope somehow seems to be overridden when doing multi module 
builds.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-362) Not able to include ejb-client artifact in jar-with-dependencies

2009-02-12 Thread Henrik Brautaset Aronsen (JIRA)


[ 
http://jira.codehaus.org/browse/MASSEMBLY-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=165221#action_165221
 ] 

Henrik Brautaset Aronsen commented on MASSEMBLY-362:


Maybe using 
[maven-shade-plugin|http://maven.apache.org/plugins/maven-shade-plugin/] 
instead of the assembly plugin will solve it?  I haven't had time to test it 
yet.



 Not able to include ejb-client artifact in jar-with-dependencies
 

 Key: MASSEMBLY-362
 URL: http://jira.codehaus.org/browse/MASSEMBLY-362
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-2
Reporter: Henrik Brautaset Aronsen

 The assembly:assembly target with jar-with-dependencies does not include my 
 ejb-client dependency.  The jar dependencies are included.  I've tried 
 specifiying my own assembly.xml, but the artifact isn't included nonetheless:
 assembly.xml:
 {code}includes
includemygroup:myartifact-ejb/include
 /includes
 {code}
 pom.xml:
 {code}dependency
groupIdmygroup/groupId
artifactIdmyartifact-ejb/artifactId
typeejb-client/type
 /dependency
 {code}
 I've also tried {{mygroup:myartifact-ejb:*}}, 
 {{mygroup:myartifact-ejb:ejb-client}} and a couple of other combinations.  
 Maven still complains:
 {code}[WARNING] The following patterns were never triggered in this artifact 
 inclusion filter:
 o  'mygroup:myartifact-ejb'
 {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: (MSITE-129) modules list empty if modules don't use this project as parent in reactor build

2009-02-12 Thread Per Lindfors (JIRA)


[ 
http://jira.codehaus.org/browse/MSITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=165254#action_165254
 ] 

Per Lindfors commented on MSITE-129:


I have done some quick testing of 2.0-SNAPSHOT from people.apache.org, and this 
is what I've found so far:

I have the following project structure:

{noformat}
+- myproj/ (parent - super-pom-A)
 +- module-1 (parent - super-pom-B)
 +- module-2 (parent - super-pom-C)
 +- module-3 (parent - super-pom-D)
 +- src/
  +- site/
   +- site.xml
{noformat}

The directory layout for my deployment site is still not correct/different from 
the layout created when you have aggregation and inheritence between the 
top/current project and the modules. This is what I get:

{noformat}
+- super-pom-A
 +- myproj
+- super-pom-B
 +- module-1
+- super-pom-C
 +- module-2
+- super-pom-D
 +- module-3
{noformat}

This is what it should look like:

{noformat}
+- myproj
 +- module-1
 +- module-2
 +- module-3
 +- css/
 +- images/
 +- index.html
 +- ...

{noformat}


*Result*
- The module links are created but broken (in beta-7 the links weren't even 
created - I think). 
- Incorrect structure of site
- the site.xml is not propagated to modules, only to myproj(I don't have 
site.xml in modules so maybe this isn't a bug/issue?)


 modules list empty if modules don't use this project as parent in reactor 
 build
 ---

 Key: MSITE-129
 URL: http://jira.codehaus.org/browse/MSITE-129
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
  Components: multi module
Affects Versions: 2.0-beta-5
Reporter: Kenney Westerhof
Assignee: Dennis Lundberg
Priority: Minor
 Fix For: 2.0


 The code in the AbstractSiteRenderingMojo does the following:
 - if it's running in a reactor build (i.e. more than 1 project in the reactor 
 projects) it scans all
 projects to see if it's parent project equals the current project. If so, 
 it's marked as a module.
 - if it's running on a single project, the project.build.modules is consulted 
 and those modules
 are marked as modules.
 I've got a 'fake' root pom, for utility purposes: it lists all projects as 
 modules so that I can easily
 built everything and generate a site. However, this fake root pom is never 
 used as a parent - there's
 a /pom/pom.xml project for that.
 The result of this is that the modules list is empty.
 A workaround is to first run 'mvn site' and then 'mvn site -N'.
 I'm not sure what the correct solution should be - basically now 2 site 
 layouts are implemented:
 - a physical layout where the modules match the modules section of the pom, 
 reflecting filesystem layout,
 - a project hierarchy layout based on parent
 and one or the other is used depending on wheter the build contains more than 
 1 project or not.
 My first feeling is that since the tag is called ${modules} (or menu 
 ref=modules/) that
 the site should use the modules, not the parent. 
 It should also take into consideration, that IF a reactor build is running, 
 it should only use the modules that are also
 in the reactor (so you can use -r -Dmaven.reactor.excludes=.. to generate a 
 site with not all projects in it).
 Thoughts?

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

[jira] Closed: (MWAR-107) CLONE -Dependency type ejb-client includes main ejb-jar in WAR build.

2009-02-12 Thread Dennis Lundberg (JIRA)


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

Dennis Lundberg closed MWAR-107.


  Assignee: (was: Brett Porter)
Resolution: Cannot Reproduce

I have tried this using Maven 2.0.9 and Maven WAR Plugin 2.1-alpha-2 and I 
cannot reproduce this issue.

 CLONE -Dependency type ejb-client includes main ejb-jar in WAR build.
 ---

 Key: MWAR-107
 URL: http://jira.codehaus.org/browse/MWAR-107
 Project: Maven 2.x War Plugin
  Issue Type: Bug
 Environment: Windows XP SP2, J2SE 5.0
Reporter: Heinrich Nirschl

 When I specify a dependency as type ejb-client for a project whose 
 packaging is set to war, the build includes the main EJB JAR in the 
 WEB-INF/lib directory, not the EJB client JAR.

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

[jira] Closed: (MWAR-80) Classifier in jar file name is removed once assembled into war file

2009-02-12 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg closed MWAR-80.
---

Assignee: Dennis Lundberg
Resolution: Fixed
Fix Version/s: 2.1

I have documented the current behavior better.
I also added a test case to verify that the classifier of a dependency is not
lost in translation.

Classifier in jar file name is removed once assembled into war file
---

Key: MWAR-80
URL: http://jira.codehaus.org/browse/MWAR-80
Project: Maven 2.x War Plugin
Issue Type: Bug
Environment: Maven 2.0.4, JDK 1.5, maven-war-plugin version 2.0
Reporter: Andreas Guther
Assignee: Dennis Lundberg
Fix For: 2.1

We use the Maven classifier to distinguish between different jar files of the
same version build for different purposes. An example would be the
classifier used for TestNG to distinguish between jdk15 and jdk14 jar files.
I noticed that the jar file (for example test-1.0-classifier.jar) ends up in
the WEB-INF/lib folder with the classifier removed (i.e. following the
example test.1.0.jar).
This is unexpected and confusing. Since there is very little documentation
about the expected behavior while using classifiers, it is not clear if this
is intenionally or a bug.
If intenionally, it should be mentioned in the maven-war-plugin
documentation. Maybe in that case it would be an enhancement to configure if
the classifier should be preserved or removed.
However, the current behavior is undocumented and unexpected.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MWAR-182) warSourceIncludes no longer works

2009-02-12 Thread Dennis Lundberg (JIRA)


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

Dennis Lundberg updated MWAR-182:
-

Description: 
The warSourceIncludes element no longer seems to work, as of 2.1-alpha-2. It 
does seem to work in 2.1-alpha-1. I am attaching a pom.xml file which will 
demonstrate the problem when used as follows:

1) From the directory containing the pom.xml, create a web.xml, because 
otherwise it fails (setting failsOnMissingWebXml didn't seem to do the trick):
  mkdir -p src/main/webapp/WEB-INF
  touch src/main/webapp/WEB-INF/web.xml

2) Build with the 2.1-alpha-1 plugin
 mvn clean install -Dwar.plugin.version=2.1-alpha-1

3) Dump out the jar contents to verify that only commons-logging and the 
web.xml were packaged, as requested
[warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war
META-INF/
META-INF/MANIFEST.MF
WEB-INF/
WEB-INF/web.xml
WEB-INF/lib/
WEB-INF/lib/commons-logging-1.1.jar
META-INF/maven/
META-INF/maven/example/
META-INF/maven/example/example-war/
META-INF/maven/example/example-war/pom.xml
META-INF/maven/example/example-war/pom.properties

4) Now build using the 2.1-alpha-2 plugin version:
 mvn clean install -Dwar.plugin.version=2.1-alpha-2

5) Dump out the jar contents and notice that warSourceIncludes was ignored this 
time:
[warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war
META-INF/
META-INF/MANIFEST.MF
WEB-INF/
WEB-INF/classes/
WEB-INF/lib/
WEB-INF/web.xml
WEB-INF/lib/commons-logging-1.1.jar
WEB-INF/lib/log4j-1.2.12.jar
WEB-INF/lib/logkit-1.0.1.jar
WEB-INF/lib/avalon-framework-4.1.3.jar
WEB-INF/lib/servlet-api-2.3.jar
META-INF/maven/
META-INF/maven/example/
META-INF/maven/example/example-war/
META-INF/maven/example/example-war/pom.xml
META-INF/maven/example/example-war/pom.properties



  was:
The warSourceExcludes element no longer seems to work, as of 2.1-alpha-2. It 
does seem to work in 2.1-alpha-1. I am attaching a pom.xml file which will 
demonstrate the problem when used as follows:

1) From the directory containing the pom.xml, create a web.xml, because 
otherwise it fails (setting failsOnMissingWebXml didn't seem to do the trick):
  mkdir -p src/main/webapp/WEB-INF
  touch src/main/webapp/WEB-INF/web.xml

2) Build with the 2.1-alpha-1 plugin
 mvn clean install -Dwar.plugin.version=2.1-alpha-1

3) Dump out the jar contents to verify that only commons-logging and the 
web.xml were packaged, as requested
[warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war
META-INF/
META-INF/MANIFEST.MF
WEB-INF/
WEB-INF/web.xml
WEB-INF/lib/
WEB-INF/lib/commons-logging-1.1.jar
META-INF/maven/
META-INF/maven/example/
META-INF/maven/example/example-war/
META-INF/maven/example/example-war/pom.xml
META-INF/maven/example/example-war/pom.properties

4) Now build using the 2.1-alpha-2 plugin version:
 mvn clean install -Dwar.plugin.version=2.1-alpha-2

5) Dump out the jar contents and notice that warSourceIncludes was ignored this 
time:
[warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war
META-INF/
META-INF/MANIFEST.MF
WEB-INF/
WEB-INF/classes/
WEB-INF/lib/
WEB-INF/web.xml
WEB-INF/lib/commons-logging-1.1.jar
WEB-INF/lib/log4j-1.2.12.jar
WEB-INF/lib/logkit-1.0.1.jar
WEB-INF/lib/avalon-framework-4.1.3.jar
WEB-INF/lib/servlet-api-2.3.jar
META-INF/maven/
META-INF/maven/example/
META-INF/maven/example/example-war/
META-INF/maven/example/example-war/pom.xml
META-INF/maven/example/example-war/pom.properties



Summary: warSourceIncludes no longer works  (was: warSourceExcludes no 
longer works)

 warSourceIncludes no longer works
 -

 Key: MWAR-182
 URL: http://jira.codehaus.org/browse/MWAR-182
 Project: Maven 2.x War Plugin
  Issue Type: Bug
Affects Versions: 2.1-alpha-2
 Environment: RHEL 3
Reporter: Bryan Loofbourrow
 Attachments: pom.xml


 The warSourceIncludes element no longer seems to work, as of 2.1-alpha-2. 
 It does seem to work in 2.1-alpha-1. I am attaching a pom.xml file which will 
 demonstrate the problem when used as follows:
 1) From the directory containing the pom.xml, create a web.xml, because 
 otherwise it fails (setting failsOnMissingWebXml didn't seem to do the trick):
   mkdir -p src/main/webapp/WEB-INF
   touch src/main/webapp/WEB-INF/web.xml
 2) Build with the 2.1-alpha-1 plugin
  mvn clean install -Dwar.plugin.version=2.1-alpha-1
 3) Dump out the jar contents to verify that only commons-logging and the 
 web.xml were packaged, as requested
 [warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war
 META-INF/
 META-INF/MANIFEST.MF
 WEB-INF/
 WEB-INF/web.xml
 WEB-INF/lib/
 WEB-INF/lib/commons-logging-1.1.jar
 META-INF/maven/
 META-INF/maven/example/
 META-INF/maven/example/example-war/
 META-INF/maven/example/example-war/pom.xml

[jira] Commented: (MAVENUPLOAD-2323) Upload of FDS-API 1.04

2009-02-12 Thread JIRA


[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-2323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=165286#action_165286
 ] 

Rémy Sanlaville commented on MAVENUPLOAD-2323:
--

It would be nice to redeploy the correct bundle.
It's blocking for us.
Thanks

 Upload of FDS-API 1.04
 --

 Key: MAVENUPLOAD-2323
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2323
 Project: Maven Upload Requests
  Issue Type: Wish
Reporter: Edouard Hue
Assignee: Carlos Sanchez
 Attachments: fdsapi-1.0.4-bundle.jar, fdsapi-1.0.4-bundle.jar


 This is not a Maven project. The author (Steve Souza) isn't currently 
 intersted in migrating fdsapi to Maven. This bundle was generated from the 
 1_04 release available at 
 http://sourceforge.net/project/showfiles.php?group_id=87044package_id=90549release_id=317647
  using the repository plugin.
 Thanks for uploading !

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

[jira] Reopened: (MWAR-181) warSourceExcludes does not work in 2.1-alpha-2

2009-02-12 Thread Dennis Lundberg (JIRA)


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

Dennis Lundberg reopened MWAR-181:
--


On closer inspection it is not the same issue as MWAR-182.

 warSourceExcludes does not work in 2.1-alpha-2
 --

 Key: MWAR-181
 URL: http://jira.codehaus.org/browse/MWAR-181
 Project: Maven 2.x War Plugin
  Issue Type: Bug
Affects Versions: 2.1-alpha-2
Reporter: Petr Kozelka
Priority: Critical

 we use following configuration to produce jar-less war artifacts, in order to 
 embed them to EAR:
 {{warSourceExcludesWEB-INF/lib/*.jar/warSourceExcludes}}
 This does not work with release 2.1-alpha-2.
 Switching to 2.1-alpha-1 solves the problem.

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

[jira] Closed: (MWAR-181) warSourceExcludes does not work in 2.1-alpha-2

2009-02-12 Thread Dennis Lundberg (JIRA)


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

Dennis Lundberg closed MWAR-181.


Resolution: Not A Bug

This was a deliberate change between 2.1-alpha-1 and 2.1-alpha-2. From 
2.1-alpha-2 onwards warSourceExcludes works *only* on the files in the 
warSourceDirectory.

To exclude files that are added during the packaging of the WAR you should use 
this instead:

{code:xml}
packagingExcludesWEB-INF/lib/*.jar/packagingExcludes
{code}

 warSourceExcludes does not work in 2.1-alpha-2
 --

 Key: MWAR-181
 URL: http://jira.codehaus.org/browse/MWAR-181
 Project: Maven 2.x War Plugin
  Issue Type: Bug
Affects Versions: 2.1-alpha-2
Reporter: Petr Kozelka
Priority: Critical

 we use following configuration to produce jar-less war artifacts, in order to 
 embed them to EAR:
 {{warSourceExcludesWEB-INF/lib/*.jar/warSourceExcludes}}
 This does not work with release 2.1-alpha-2.
 Switching to 2.1-alpha-1 solves the problem.

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

[jira] Commented: (MWAR-182) warSourceIncludes no longer works

2009-02-12 Thread Dennis Lundberg (JIRA)


[ 
http://jira.codehaus.org/browse/MWAR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=165291#action_165291
 ] 

Dennis Lundberg commented on MWAR-182:
--

The behavior of warSourceIncludes was deliberately changed between 
2.1-alpha-1 and 2.1-alpha-2. From 2.1-alpha-2 onwards warSourceIncludes works 
only on the files in the warSourceDirectory.

To exclude files that are added during the packaging of the WAR you can use 
this:

packagingExcludesWEB-INF/lib/*.jar/packagingExcludes

But there is no corresponding packagingIncludes parameter. Do you really need 
such a parameter?

 warSourceIncludes no longer works
 -

 Key: MWAR-182
 URL: http://jira.codehaus.org/browse/MWAR-182
 Project: Maven 2.x War Plugin
  Issue Type: Bug
Affects Versions: 2.1-alpha-2
 Environment: RHEL 3
Reporter: Bryan Loofbourrow
 Attachments: pom.xml


 The warSourceIncludes element no longer seems to work, as of 2.1-alpha-2. 
 It does seem to work in 2.1-alpha-1. I am attaching a pom.xml file which will 
 demonstrate the problem when used as follows:
 1) From the directory containing the pom.xml, create a web.xml, because 
 otherwise it fails (setting failsOnMissingWebXml didn't seem to do the trick):
   mkdir -p src/main/webapp/WEB-INF
   touch src/main/webapp/WEB-INF/web.xml
 2) Build with the 2.1-alpha-1 plugin
  mvn clean install -Dwar.plugin.version=2.1-alpha-1
 3) Dump out the jar contents to verify that only commons-logging and the 
 web.xml were packaged, as requested
 [warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war
 META-INF/
 META-INF/MANIFEST.MF
 WEB-INF/
 WEB-INF/web.xml
 WEB-INF/lib/
 WEB-INF/lib/commons-logging-1.1.jar
 META-INF/maven/
 META-INF/maven/example/
 META-INF/maven/example/example-war/
 META-INF/maven/example/example-war/pom.xml
 META-INF/maven/example/example-war/pom.properties
 4) Now build using the 2.1-alpha-2 plugin version:
  mvn clean install -Dwar.plugin.version=2.1-alpha-2
 5) Dump out the jar contents and notice that warSourceIncludes was ignored 
 this time:
 [warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war
 META-INF/
 META-INF/MANIFEST.MF
 WEB-INF/
 WEB-INF/classes/
 WEB-INF/lib/
 WEB-INF/web.xml
 WEB-INF/lib/commons-logging-1.1.jar
 WEB-INF/lib/log4j-1.2.12.jar
 WEB-INF/lib/logkit-1.0.1.jar
 WEB-INF/lib/avalon-framework-4.1.3.jar
 WEB-INF/lib/servlet-api-2.3.jar
 META-INF/maven/
 META-INF/maven/example/
 META-INF/maven/example/example-war/
 META-INF/maven/example/example-war/pom.xml
 META-INF/maven/example/example-war/pom.properties

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MWAR-178) war plugin documentation and probably implementation is unaware of javaee 5

2009-02-12 Thread Dennis Lundberg (JIRA)


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

Dennis Lundberg updated MWAR-178:
-

Issue Type: New Feature  (was: Bug)

 war plugin documentation and probably implementation is unaware of javaee 5
 ---

 Key: MWAR-178
 URL: http://jira.codehaus.org/browse/MWAR-178
 Project: Maven 2.x War Plugin
  Issue Type: New Feature
Reporter: David Jencks

 The example I'm aware of:
 http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html 
 talks about using the war's manifest.mf classpath to include jars in the ear 
 in the war module's classloader.  In ee5, there's a ear lib directory: 
 everything in that is automatically included in the ear level classloader, 
 which is certainly available to every war, most likely by being a parent 
 classloader to the war classloader.  One consequence of this is that using 
 the manifest classpath in a 1.4 container will likely result in each war 
 getting separate copies of the lib jar classes whereas the ee5 lib directory 
 will result in shared classes.

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

[jira] Commented: (MWAR-176) when archiveClasses is true, jar file has incorrect name

2009-02-12 Thread Dennis Lundberg (JIRA)


[ 
http://jira.codehaus.org/browse/MWAR-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=165293#action_165293
 ] 

Dennis Lundberg commented on MWAR-176:
--

Can you give us a POM that shows the configurations needed to reproduce this?

 when archiveClasses is true, jar file has incorrect name
 

 Key: MWAR-176
 URL: http://jira.codehaus.org/browse/MWAR-176
 Project: Maven 2.x War Plugin
  Issue Type: Bug
Affects Versions: 2.1-alpha-2
 Environment: jdk 1.6 - maven 2.0.9
Reporter: Hugues Narjoux

 I have a parent pom which defines a build number using the build number 
 plugin. My project's finalName is of the form :
 ${artifcatId}_${version}_${buildNumber}
 The war is correctly named, but the when using archiveClasses the jar is not 
 named properly: it is named the same but without replacing the buildNumber 
 property, e.g:
 myAtifcat_1.0_${buildNumber}.jar
 It works fine if the build number is defined in the pom itself. This happens 
 if the buidlNumber is defined in a parent pom.

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

[jira] Commented: (MRELEASE-220) Add property to keep released versions for dependencies

2009-02-12 Thread Peter Liljenberg (JIRA)


[ 
http://jira.codehaus.org/browse/MRELEASE-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=165292#action_165292
 ] 

Peter Liljenberg commented on MRELEASE-220:
---

After digging into the code it looks like the actual bug is in ReleaseManager 
rather than the plugin itself:

   //MRELEASE-220
if ( mappedVersion != null  mappedVersion.endsWith( 
SNAPSHOT ) 
!dependencyVersion.endsWith( SNAPSHOT )  
!releaseDescriptor.isUpdateDependencies() )
{
return;
}

Shouldn't we check the dependencyVersion here?
if (  !dependencyVersion.endsWith( SNAPSHOT )  
!releaseDescriptor.isUpdateDependencies() )
{
return;
}


 Add property to keep released versions for dependencies
 ---

 Key: MRELEASE-220
 URL: http://jira.codehaus.org/browse/MRELEASE-220
 Project: Maven 2.x Release Plugin
  Issue Type: Improvement
  Components: prepare
Affects Versions: 2.0-beta-4
Reporter: Daniel Beland
Assignee: Emmanuel Venisse

 When I release a project with many modules with internal dependencies.
 I would like those dependencies to keep the released version rather than the 
 next development version.
 ie: I only release some modules at a time (those that were changed only since 
 last release).
 So when my webapp is released, I want it to become SNAPSHOT again(as it is 
 done already) but want the internal dependencies to keep the released version.
 I want to update them manually whenever I change one.

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

[jira] Closed: (MWAR-154) documentation for overlay is incorrect

2009-02-12 Thread Dennis Lundberg (JIRA)


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

Dennis Lundberg closed MWAR-154.


Resolution: Fixed

This seems to have solved itself in some way.

 documentation for overlay is incorrect
 --

 Key: MWAR-154
 URL: http://jira.codehaus.org/browse/MWAR-154
 Project: Maven 2.x War Plugin
  Issue Type: Task
Reporter: Olaf Kittelmann
Assignee: Stephane Nicoll

 The documentation on 
 http://maven.apache.org/plugins/maven-war-plugin/overlays.html describes a 
 feature that only works with 
 version 2.1-alpha-1 of the plugin. 
 yet the pom snippets on the documentation page always point to version 2.0. 
  [...]
 plugins
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-war-plugin/artifactId
 version2.0/version
 configuration
   !-- default value is ** --
   dependentWarIncludes**/IncludeME,**/images/dependentWarIncludes 
   
 /configuration
/plugin
 /plugins  
   [...]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MWAR-182) warSourceIncludes no longer works

2009-02-12 Thread Bryan Loofbourrow (JIRA)


[ 
http://jira.codehaus.org/browse/MWAR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=165306#action_165306
 ] 

Bryan Loofbourrow commented on MWAR-182:


Not only do I need it, I am using it in a large, multimodule project, and it is 
hard to know what would substitute for it. Not packagingExcludes. My need is to 
package a small, but nonempty, subset of the jars into the war. That's hard to 
do well, and impossible to do in a stable manner, using a specification that 
can only tell what to exclude.

The need to package a small, but nonempty, subset of jars into a war, comes 
from the longstanding skinny war problem ( 
http://docs.codehaus.org/display/MAVENUSER/Solving+the+Skinny+Wars+problem ). 
In making an ear of skinny wars, one wants to package all of the jars into the 
ear, with, in some cases, a short list of exceptions that must be packaged into 
the war in order to work properly (generally tag libraries, in my case).

There are few decent solutions to the skinny war problem as things stand in 
Maven. By removing this includes functionality from the war plugin, the team 
would be taking away what is, in the current state of things, by far the best 
one, in my opinion.  


 warSourceIncludes no longer works
 -

 Key: MWAR-182
 URL: http://jira.codehaus.org/browse/MWAR-182
 Project: Maven 2.x War Plugin
  Issue Type: Bug
Affects Versions: 2.1-alpha-2
 Environment: RHEL 3
Reporter: Bryan Loofbourrow
 Attachments: pom.xml


 The warSourceIncludes element no longer seems to work, as of 2.1-alpha-2. 
 It does seem to work in 2.1-alpha-1. I am attaching a pom.xml file which will 
 demonstrate the problem when used as follows:
 1) From the directory containing the pom.xml, create a web.xml, because 
 otherwise it fails (setting failsOnMissingWebXml didn't seem to do the trick):
   mkdir -p src/main/webapp/WEB-INF
   touch src/main/webapp/WEB-INF/web.xml
 2) Build with the 2.1-alpha-1 plugin
  mvn clean install -Dwar.plugin.version=2.1-alpha-1
 3) Dump out the jar contents to verify that only commons-logging and the 
 web.xml were packaged, as requested
 [warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war
 META-INF/
 META-INF/MANIFEST.MF
 WEB-INF/
 WEB-INF/web.xml
 WEB-INF/lib/
 WEB-INF/lib/commons-logging-1.1.jar
 META-INF/maven/
 META-INF/maven/example/
 META-INF/maven/example/example-war/
 META-INF/maven/example/example-war/pom.xml
 META-INF/maven/example/example-war/pom.properties
 4) Now build using the 2.1-alpha-2 plugin version:
  mvn clean install -Dwar.plugin.version=2.1-alpha-2
 5) Dump out the jar contents and notice that warSourceIncludes was ignored 
 this time:
 [warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war
 META-INF/
 META-INF/MANIFEST.MF
 WEB-INF/
 WEB-INF/classes/
 WEB-INF/lib/
 WEB-INF/web.xml
 WEB-INF/lib/commons-logging-1.1.jar
 WEB-INF/lib/log4j-1.2.12.jar
 WEB-INF/lib/logkit-1.0.1.jar
 WEB-INF/lib/avalon-framework-4.1.3.jar
 WEB-INF/lib/servlet-api-2.3.jar
 META-INF/maven/
 META-INF/maven/example/
 META-INF/maven/example/example-war/
 META-INF/maven/example/example-war/pom.xml
 META-INF/maven/example/example-war/pom.properties

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MWAR-176) when archiveClasses is true, jar file has incorrect name

2009-02-12 Thread Hugues Narjoux (JIRA)


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

Hugues Narjoux updated MWAR-176:


Attachment: parent_pom.xml

The parent pom with the war plugin declaration

 when archiveClasses is true, jar file has incorrect name
 

 Key: MWAR-176
 URL: http://jira.codehaus.org/browse/MWAR-176
 Project: Maven 2.x War Plugin
  Issue Type: Bug
Affects Versions: 2.1-alpha-2
 Environment: jdk 1.6 - maven 2.0.9
Reporter: Hugues Narjoux
 Attachments: parent_pom.xml


 I have a parent pom which defines a build number using the build number 
 plugin. My project's finalName is of the form :
 ${artifcatId}_${version}_${buildNumber}
 The war is correctly named, but the when using archiveClasses the jar is not 
 named properly: it is named the same but without replacing the buildNumber 
 property, e.g:
 myAtifcat_1.0_${buildNumber}.jar
 It works fine if the build number is defined in the pom itself. This happens 
 if the buidlNumber is defined in a parent pom.

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

[jira] Commented: (MWAR-176) when archiveClasses is true, jar file has incorrect name

2009-02-12 Thread Hugues Narjoux (JIRA)


[ 
http://jira.codehaus.org/browse/MWAR-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=165309#action_165309
 ] 

Hugues Narjoux commented on MWAR-176:
-

I attached a sample parent pom which contains the declaration of the war plugin 
and the build number plugin.

The child pom does not contain anything special, except inheriting the parent 
pom.


 when archiveClasses is true, jar file has incorrect name
 

 Key: MWAR-176
 URL: http://jira.codehaus.org/browse/MWAR-176
 Project: Maven 2.x War Plugin
  Issue Type: Bug
Affects Versions: 2.1-alpha-2
 Environment: jdk 1.6 - maven 2.0.9
Reporter: Hugues Narjoux
 Attachments: parent_pom.xml


 I have a parent pom which defines a build number using the build number 
 plugin. My project's finalName is of the form :
 ${artifcatId}_${version}_${buildNumber}
 The war is correctly named, but the when using archiveClasses the jar is not 
 named properly: it is named the same but without replacing the buildNumber 
 property, e.g:
 myAtifcat_1.0_${buildNumber}.jar
 It works fine if the build number is defined in the pom itself. This happens 
 if the buidlNumber is defined in a parent pom.

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

[jira] Created: (MNG-4033) Introduce 2.1.x password encryption to the trunk

2009-02-12 Thread Oleg Gusakov (JIRA)

Introduce 2.1.x password encryption to the trunk


 Key: MNG-4033
 URL: http://jira.codehaus.org/browse/MNG-4033
 Project: Maven 2
  Issue Type: New Feature
  Components: Settings
Affects Versions: 3.0-alpha-2
Reporter: Oleg Gusakov




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

[jira] Commented: (MSITE-129) modules list empty if modules don't use this project as parent in reactor build

2009-02-12 Thread John Allen (JIRA)

[
http://jira.codehaus.org/browse/MSITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=165319#action_165319
]

John Allen commented on MSITE-129:
--

modules list empty if modules don't use this project as parent in reactor
build
---

Key: MSITE-129
URL: http://jira.codehaus.org/browse/MSITE-129
Project: Maven 2.x Site Plugin
Issue Type: Bug
Components: multi module
Affects Versions: 2.0-beta-5
Reporter: Kenney Westerhof
Assignee: Dennis Lundberg
Priority: Minor
Fix For: 2.0

The code in the AbstractSiteRenderingMojo does the following:
- if it's running in a reactor build (i.e. more than 1 project in the reactor
projects) it scans all
projects to see if it's parent project equals the current project. If so,
it's marked as a module.
- if it's running on a single project, the project.build.modules is consulted
and those modules
are marked as modules.
I've got a 'fake' root pom, for utility purposes: it lists all projects as
modules so that I can easily
built everything and generate a site. However, this fake root pom is never
used as a parent - there's
a /pom/pom.xml project for that.
The result of this is that the modules list is empty.
A workaround is to first run 'mvn site' and then 'mvn site -N'.
I'm not sure what the correct solution should be - basically now 2 site
layouts are implemented:
- a physical layout where the modules match the modules section of the pom,
reflecting filesystem layout,
- a project hierarchy layout based on parent
and one or the other is used depending on wheter the build contains more than
1 project or not.
My first feeling is that since the tag is called ${modules} (or menu
ref=modules/) that
the site should use the modules, not the parent.
It should also take into consideration, that IF a reactor build is running,
it should only use the modules that are also
in the reactor (so you can use -r -Dmaven.reactor.excludes=.. to generate a
site with not all projects in it).
Thoughts?

[jira] Commented: (MWAR-182) warSourceIncludes no longer works

2009-02-12 Thread Jason Pringle (JIRA)


[ 
http://jira.codehaus.org/browse/MWAR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=165322#action_165322
 ] 

Jason Pringle commented on MWAR-182:


Agreed, adding a corresponding packagingIncludes parameter would allow 
precise control over what JARs should be packaged into an almost skinny WAR.

 warSourceIncludes no longer works
 -

 Key: MWAR-182
 URL: http://jira.codehaus.org/browse/MWAR-182
 Project: Maven 2.x War Plugin
  Issue Type: Bug
Affects Versions: 2.1-alpha-2
 Environment: RHEL 3
Reporter: Bryan Loofbourrow
 Attachments: pom.xml


 The warSourceIncludes element no longer seems to work, as of 2.1-alpha-2. 
 It does seem to work in 2.1-alpha-1. I am attaching a pom.xml file which will 
 demonstrate the problem when used as follows:
 1) From the directory containing the pom.xml, create a web.xml, because 
 otherwise it fails (setting failsOnMissingWebXml didn't seem to do the trick):
   mkdir -p src/main/webapp/WEB-INF
   touch src/main/webapp/WEB-INF/web.xml
 2) Build with the 2.1-alpha-1 plugin
  mvn clean install -Dwar.plugin.version=2.1-alpha-1
 3) Dump out the jar contents to verify that only commons-logging and the 
 web.xml were packaged, as requested
 [warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war
 META-INF/
 META-INF/MANIFEST.MF
 WEB-INF/
 WEB-INF/web.xml
 WEB-INF/lib/
 WEB-INF/lib/commons-logging-1.1.jar
 META-INF/maven/
 META-INF/maven/example/
 META-INF/maven/example/example-war/
 META-INF/maven/example/example-war/pom.xml
 META-INF/maven/example/example-war/pom.properties
 4) Now build using the 2.1-alpha-2 plugin version:
  mvn clean install -Dwar.plugin.version=2.1-alpha-2
 5) Dump out the jar contents and notice that warSourceIncludes was ignored 
 this time:
 [warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war
 META-INF/
 META-INF/MANIFEST.MF
 WEB-INF/
 WEB-INF/classes/
 WEB-INF/lib/
 WEB-INF/web.xml
 WEB-INF/lib/commons-logging-1.1.jar
 WEB-INF/lib/log4j-1.2.12.jar
 WEB-INF/lib/logkit-1.0.1.jar
 WEB-INF/lib/avalon-framework-4.1.3.jar
 WEB-INF/lib/servlet-api-2.3.jar
 META-INF/maven/
 META-INF/maven/example/
 META-INF/maven/example/example-war/
 META-INF/maven/example/example-war/pom.xml
 META-INF/maven/example/example-war/pom.properties

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

[jira] Issue Comment Edited: (MSITE-129) modules list empty if modules don't use this project as parent in reactor build

2009-02-12 Thread John Allen (JIRA)

[
http://jira.codehaus.org/browse/MSITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=165319#action_165319
]

John Allen edited comment on MSITE-129 at 2/12/09 12:00 PM:

Module locations (and thus links) are based upon project.distro.site.url and
project.url. They have no bearing on where a module is on the filesystem.

The structure you have drawn as 'what it should be' is stating that the
submodules inherit from myproj, which they dont. And thats why in the generated
site they dont live under it.

There are two very different namespaces here and none of them are related.

One is the filesystem. In this case your myproj and its sub dirs. This
namespace has no bearing on the URL namespace or for that matter the project
inheritance relationships.

The next is the project hierarchy. That does have a relationship to the URL
namespace, only IF, you inherit the settings for project.url and
project.distributionManagement.site.url. However if you override those at each
project level then these two are unrelated.

When a project deploys itself into the URL space, it uses its distro.site.url
to work out where it should go. This obviously needs to be related to the
project's URL otherwise it will deploy to a location that no other project will
ever be able to find by using that project's URL.

The module projects all do the same, namely deploy to locations dependent upon
their distro.site.url.

So first up, there is no relationship between the deployemnt URL location and
the filesystem structure.

A aggregator project, such as myproj generates links to its modules. These its
calculates by asking each module, what is your DEPLOYED project url. Each
project returns its URL and the aggregator project calculates the relative
paths (if possible) to the module projects from its own URL.

You did deploy the projects to check that the module links were woerking didnt
you? They will never work in an undeployed state.

was (Author: skaze):
df

modules list empty if modules don't use this project as parent in reactor
build
---

[jira] Commented: (MNG-4030) Release maven-plugin-tools 2.4.4/2.5 to enable enhanced ant-mojo support

2009-02-12 Thread Benjamin Bentmann (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=165323#action_165323
 ] 

Benjamin Bentmann commented on MNG-4030:


Given you made significant feature additions, I feel 2.5 is more appropriate 
for the next version than 2.4.4.

 Release maven-plugin-tools 2.4.4/2.5 to enable enhanced ant-mojo support
 

 Key: MNG-4030
 URL: http://jira.codehaus.org/browse/MNG-4030
 Project: Maven 2
  Issue Type: Task
Reporter: John Casey
Assignee: John Casey
Priority: Blocker
 Fix For: 2.1.0


 This is necessary for MNG-3971.

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

[jira] Closed: (MNG-3217) a plugin's dependencies can influence other plugins in a build

2009-02-12 Thread Benjamin Bentmann (JIRA)


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

Benjamin Bentmann closed MNG-3217.
--

 Assignee: Benjamin Bentmann
   Resolution: Fixed
Fix Version/s: (was: 2.0.x)
   3.0-alpha-1

 a plugin's dependencies can influence other plugins in a build
 --

 Key: MNG-3217
 URL: http://jira.codehaus.org/browse/MNG-3217
 Project: Maven 2
  Issue Type: Bug
  Components: Artifacts and Repositories
Affects Versions: 2.0.7
Reporter: Brian Fox
Assignee: Benjamin Bentmann
 Fix For: 3.0-alpha-1


 See the linked issue for more details.
 In short, the dependency plugin has declared a dependency on the site plugin 
 (forget for now that this is probably not a good ide). The problem is that in 
 doing this, the site plugin used for other things in the user's build is now 
 pinned to the version declared in the dependency plugin. This seems to 
 indicate some kind of pollution between what a plugin needs and what gets 
 used for a build.

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

64 matches

Mail list logo