date:20070412

Avoid the need for redundant specification of module type
-

 Key: MEAR-61
 URL: http://jira.codehaus.org/browse/MEAR-61
 Project: Maven 2.x Ear Plugin
  Issue Type: Improvement
Affects Versions: 2.3
 Environment: Any
Reporter: johan Eltes


The POMs of the modules to be packaged by the ear plugin, contain information 
about module type (e.g. packaging). The ear plug-in does not read this 
information. As a consequence, the ear POM has to redundantly define a type 
element on the dependencies ear module dependencies:

ear POM:

dependency
groupIdmywebapp/groupId
artifactIdmywebapp/artifactId
version1.0.0/version
typewar/type -- redundant information
/dependency

war POM:

project xmlns=http://maven.apache.org/POM/4.0.0; 
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; 
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd;
 modelVersion4.0.0/modelVersion
 groupIdmywebapp/groupId
 artifactIdmywebapp/artifactId
 packagingwar/packaging -- Should be picked up from here

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

[jira] Created: (MEAR-62) scope provided not applied

scope provided not applied


 Key: MEAR-62
 URL: http://jira.codehaus.org/browse/MEAR-62
 Project: Maven 2.x Ear Plugin
  Issue Type: Bug
Affects Versions: 2.3
 Environment: Any
Reporter: johan Eltes


When packaging an ear, the ear plugin does not exclude transitive dependencies 
with scope provided. A war or ejb project may declare provided-scoped 
dependencies (e.g. j2ee apis). The purpose is to not include these dependencies 
when packaging the archive. For enterprise applications, the EAR project is 
responsible for doing the packaging of its modules dependencies. Although scope 
packaging is defined for transitive dependencies (dependencies declared by the 
module POMs), the ear plug-in still includes these libraries in the produced 
ear.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MIDEA-86) [Patch] Add support for IDEA 7 (Selena) EJB/EAR modules

2007-04-12 Thread Arik Kfir (JIRA)

[Patch] Add support for IDEA 7 (Selena) EJB/EAR modules
---

 Key: MIDEA-86
 URL: http://jira.codehaus.org/browse/MIDEA-86
 Project: Maven 2.x Idea Plugin
  Issue Type: Improvement
Affects Versions: 2.0, 2.1
 Environment: IntelliJ IDEA 7.x (Selena)
Reporter: Arik Kfir
 Attachments: idea-7-support.patch

This patch prevents generation of an entry for the deployment descriptor if it 
does not exist, in accordance to JEE 5. This is only done if the actual IDEA 
version (set in the project's POM) is indeed 7. In IDEA 7, if a descriptor is 
specified in the IML file, but does not exist, it spits out an error on every 
compilation

Also, *unrelated* to the plugin runtime, this patch adds this snippet to the 
pom.xml:
{noformat}build
plugins
  plugin
artifactIdmaven-idea-plugin/artifactId
configuration
  jdkLevel1.4/jdkLevel
/configuration
  /plugin
/plugins
  /build{noformat} 
For those who use IDEA to work on the plugin, this makes sure that the project 
JDK level is 1.4 (which is the policy currently, to prevent IDEA's suggestions 
for JDK 5-level (e.g. don't suggest using a for-each instead of for(int 
i=...))

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

[jira] Moved: (MECLIPSE-254) Eclipse plugin to provide maven integration not packaged so it can be reused by other Eclipse plugins.

2007-04-12 Thread Lukas Theussl (JIRA)


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

Lukas Theussl moved MPECLIPSE-130 to MECLIPSE-254:
--

Affects Version/s: (was: 1.10)
 Workflow: Maven New  (was: jira)
  Key: MECLIPSE-254  (was: MPECLIPSE-130)
  Project: Maven 2.x Eclipse Plugin  (was: maven-eclipse-plugin)

 Eclipse plugin to provide maven integration not packaged so it can be reused 
 by other Eclipse plugins.
 --

 Key: MECLIPSE-254
 URL: http://jira.codehaus.org/browse/MECLIPSE-254
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Bug
 Environment: MS Windows XP running Eclipse321/Wtp151 all in one 
 package using a Sun Java 1.5 sdk.
Reporter: Gary Mohr

 The Eclipse plugin that provides maven integration is installed into Eclipse 
 as an unpacked Jar file.  This top level Jar file does not contain the class 
 files which provide the maven functionallity, instead they are found in the 
 m2plugin.jar runtime library found in this top level Jar file.
 This means that if I am developing my own Eclipse plugin, it is not possible 
 to simply list the maven plugin (org.maven.ide.eclipse) as a dependency in my 
 plugin and then gain access to the classes delivered with the maven plugin.  
 In order to use the classes delivered in the maven plugin I am required to 
 extract the runtime library m2plugin.jar and put a copy of it in my 
 plugin's lib directory then add it to my plugin's classpath.
 Somehow it seems ironic that Maven the champion of not having to manually 
 replicate Jar files within projects would leave me in this situation.
 Please provide me an easier way to write Eclipse plugins that utilize the 
 services delivered with the Maven Eclipse plugin.
 If for instance the Maven Eclipse plugin were unpacked when it is installed 
 into Eclipse, then I should be able to add the m2plugin.jar to my plugin's 
 classpath without the need to replicate it.  As a different approach if the 
 class files from the 3 runtime libraries delivered in the plugin Jar file 
 were found in the plugin Jar file instead of buried inside the runtime 
 library, then Eclipse would be able to reference these classes when I list 
 the Maven Eclipse plugin as a dependency of my plugin.
 I am sorry if the project this was submitted to is not the correct project.  
 From its name it is kinda of hard to tell if it represents the Maven plugin 
 to support Eclipse stuff or the Eclipse plugin to support Maven stuff.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MJAVADOC-116) Impossible to aggregate javadoc if snapshot never built

2007-04-12 Thread Arne Degenring (JIRA)


[ 
http://jira.codehaus.org/browse/MJAVADOC-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92690
 ] 

Arne Degenring commented on MJAVADOC-116:
-

I face the same problem. It seems to be a regression, as the problem does not 
occur with maven-javadoc-plugin 2.0.

 Impossible to aggregate javadoc if snapshot never built
 ---

 Key: MJAVADOC-116
 URL: http://jira.codehaus.org/browse/MJAVADOC-116
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.2
Reporter: Damien Lecan

 In a multi-module projet, I build an aggregated Javadoc for the site.
 The project is built with mvn clean deploy site-deploy
 When I add a new project, the next build always fails because the javadoc 
 plugin can't find at least one snapshot for the new added module
 In the following example, I added a new module tele.persistance:pers-commons, 
 which have never been built before.
 Maven tries to download it but it can't find it (never build before).
 {noformat} [INFO] [site:site]
 [WARNING] Unable to load parent project from repository: Could not find the 
 model file '/continuum-folders/working-directory/116/../pom.xml'.
 [INFO] Skipped About report, file index.html already exists for the 
 English version.
 [ERROR] VM #displayTree: error : too few arguments to macro. Wanted 2 got 0
 [ERROR] VM #menuItem: error : too few arguments to macro. Wanted 1 got 0
 [INFO] Generate JavaDocs report.
 [INFO] snapshot tele:commons:1.2.0-alpha-1-SNAPSHOT: checking for updates 
 from mirror.snapshots
 [INFO] snapshot tele.persistance:pers-data:1.2.0-alpha-1-SNAPSHOT: checking 
 for updates from mirror.snapshots
 [INFO] snapshot tele.persistance:pers-api:1.2.0-alpha-1-SNAPSHOT: checking 
 for updates from mirror.snapshots
 [INFO] snapshot tele.persistance:pers-commons:1.2.0-alpha-1-SNAPSHOT: 
 checking for updates from mirror.snapshots
 Downloading: 
 http://proxy/maven2-snapshots/repository/tele/persistance/pers-commons/1.2.0-alpha-1-SNAPSHOT/pers-commons-1.2.0-alpha-1-SNAPSHOT.jar
 [WARNING] Unable to get resource 
 'tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT' from repository 
 mirror.snapshots (http://proxy/maven2-snapshots/repository)
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] Failed to resolve artifact.
 Missing:
 --
 1) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
   Try downloading the file manually from the project website.
   Then, install it using the command: 
   mvn install:install-file -DgroupId=tele.persistance 
 -DartifactId=pers-commons \
   -Dversion=1.2.0-alpha-1-SNAPSHOT -Dpackaging=jar 
 -Dfile=/path/to/file
   Path to dependency: 
   1) tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
   2) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
 --
 1 required artifact is missing.
 for artifact: 
   tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
 from the specified remote repositories:
   central (http://repo1.maven.org/maven2),
   mirror.snapshots (http://proxy/maven2-snapshots/repository)
 {noformat}
 If I make an intermediate install, everything works fine

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-2921) ejb-client dependency no longer working

2007-04-12 Thread Frank Cornelis (JIRA)


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

Frank Cornelis commented on MNG-2921:
-

What bothers me most about this is that such a major feature of Maven (it's 
even documented in the Maven2 book) breaks without big 'community notice'. I 
really wonder how people actually build their J2EE applications...

 ejb-client dependency no longer working
 ---

 Key: MNG-2921
 URL: http://jira.codehaus.org/browse/MNG-2921
 Project: Maven 2
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 2.0.6
 Environment: Fedora Core 6
Reporter: Frank Cornelis
Priority: Blocker
 Attachments: test.zip


 When running 'mvn clean install' on the test project (see attachment) under 
 Maven 2.0.5 every builds as expected. On Maven 2.0.6 it no longer compiles. 
 On Maven 2.0.5 I get in the log:
 [DEBUG] be.frankcornelis.maven:client:jar:1.0-SNAPSHOT (selected for null)
 [DEBUG]   be.frankcornelis.maven:model:ejb-client:client:1.0-SNAPSHOT:compile 
 (selected for compile)
 Under Maven 2.0.6 I get:
 [DEBUG] be.frankcornelis.maven:client:jar:1.0-SNAPSHOT (selected for null)
 [DEBUG]   be.frankcornelis.maven:model:ejb-client:client:1.0-SNAPSHOT 
 (selected for null)
 and an error message saying it cannot find the required interfaces defined in 
 Model.
 When I remove type:ejb-client in the Client pom.xml it compiles again.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MEAR-62) scope provided not applied

2007-04-12 Thread Stephane Nicoll (JIRA)


[ 
http://jira.codehaus.org/browse/MEAR-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92707
 ] 

Stephane Nicoll commented on MEAR-62:
-

bah weird !

Do you have a test project to reproduce your problem?

 scope provided not applied
 

 Key: MEAR-62
 URL: http://jira.codehaus.org/browse/MEAR-62
 Project: Maven 2.x Ear Plugin
  Issue Type: Bug
Affects Versions: 2.3
 Environment: Any
Reporter: johan Eltes

 When packaging an ear, the ear plugin does not exclude transitive 
 dependencies with scope provided. A war or ejb project may declare 
 provided-scoped dependencies (e.g. j2ee apis). The purpose is to not 
 include these dependencies when packaging the archive. For enterprise 
 applications, the EAR project is responsible for doing the packaging of its 
 modules dependencies. Although scope packaging is defined for transitive 
 dependencies (dependencies declared by the module POMs), the ear plug-in 
 still includes these libraries in the produced ear.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MEAR-61) Avoid the need for redundant specification of module type

2007-04-12 Thread Stephane Nicoll (JIRA)


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

Stephane Nicoll closed MEAR-61.
---

Resolution: Won't Fix

No. Maven does not work that way.

Nothing prevents you to actually have

groupId: com.blah, artifactId = foo, version= 1.2 - Jar
groupId: com.blah, artifactId = foo, version= 1.2 - War
groupId: com.blah, artifactId = foo, version= 1.2 - Ear

The default type is Jar. You should provide it for other types.

(And it has *nothing* to do with EAR or any other plugin btw)

 Avoid the need for redundant specification of module type
 -

 Key: MEAR-61
 URL: http://jira.codehaus.org/browse/MEAR-61
 Project: Maven 2.x Ear Plugin
  Issue Type: Improvement
Affects Versions: 2.3
 Environment: Any
Reporter: johan Eltes

 The POMs of the modules to be packaged by the ear plugin, contain information 
 about module type (e.g. packaging). The ear plug-in does not read this 
 information. As a consequence, the ear POM has to redundantly define a type 
 element on the dependencies ear module dependencies:
 ear POM:
   dependency
   groupIdmywebapp/groupId
   artifactIdmywebapp/artifactId
   version1.0.0/version
   typewar/type -- redundant information
   /dependency
 war POM:
 project xmlns=http://maven.apache.org/POM/4.0.0; 
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; 
 xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 
 http://maven.apache.org/maven-v4_0_0.xsd;
  modelVersion4.0.0/modelVersion
  groupIdmywebapp/groupId
  artifactIdmywebapp/artifactId
  packagingwar/packaging -- Should be picked up from here

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

[jira] Commented: (MEAR-61) Avoid the need for redundant specification of module type


[ 
http://jira.codehaus.org/browse/MEAR-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92713
 ] 

johan Eltes commented on MEAR-61:
-

Aha..of casue. I'm actually naming the dependency by assigning the type 
element. Should have grasped that...

 Avoid the need for redundant specification of module type
 -

 Key: MEAR-61
 URL: http://jira.codehaus.org/browse/MEAR-61
 Project: Maven 2.x Ear Plugin
  Issue Type: Improvement
Affects Versions: 2.3
 Environment: Any
Reporter: johan Eltes
Assignee: Stephane Nicoll

 The POMs of the modules to be packaged by the ear plugin, contain information 
 about module type (e.g. packaging). The ear plug-in does not read this 
 information. As a consequence, the ear POM has to redundantly define a type 
 element on the dependencies ear module dependencies:
 ear POM:
   dependency
   groupIdmywebapp/groupId
   artifactIdmywebapp/artifactId
   version1.0.0/version
   typewar/type -- redundant information
   /dependency
 war POM:
 project xmlns=http://maven.apache.org/POM/4.0.0; 
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; 
 xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 
 http://maven.apache.org/maven-v4_0_0.xsd;
  modelVersion4.0.0/modelVersion
  groupIdmywebapp/groupId
  artifactIdmywebapp/artifactId
  packagingwar/packaging -- Should be picked up from here

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

[jira] Issue Comment Edited: (MEAR-61) Avoid the need for redundant specification of module type

[
http://jira.codehaus.org/browse/MEAR-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92713
]

johan Eltes edited comment on MEAR-61 at 4/12/07 7:57 AM:
--

Aha..of cause. I'm actually naming the dependency by assigning the type
element. Should have grasped that...

was:
Aha..of casue. I'm actually naming the dependency by assigning the type
element. Should have grasped that...

Avoid the need for redundant specification of module type
-

Key: MEAR-61
URL: http://jira.codehaus.org/browse/MEAR-61
Project: Maven 2.x Ear Plugin
Issue Type: Improvement
Affects Versions: 2.3
Environment: Any
Reporter: johan Eltes
Assignee: Stephane Nicoll

The POMs of the modules to be packaged by the ear plugin, contain information
about module type (e.g. packaging). The ear plug-in does not read this
information. As a consequence, the ear POM has to redundantly define a type
element on the dependencies ear module dependencies:
ear POM:
dependency
groupIdmywebapp/groupId
artifactIdmywebapp/artifactId
version1.0.0/version
typewar/type -- redundant information
/dependency
war POM:
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdmywebapp/groupId
artifactIdmywebapp/artifactId
packagingwar/packaging -- Should be picked up from here

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

[jira] Created: (SCM-297) scm:tag process child poms recursively and attempts to tag submodules

2007-04-12 Thread Alexander Burak (JIRA)

scm:tag process child poms recursively and attempts to tag submodules
-

 Key: SCM-297
 URL: http://jira.codehaus.org/browse/SCM-297
 Project: Maven SCM
  Issue Type: Bug
Reporter: Alexander Burak


My project contains several submodules with own poms: 
root
  pom.xml
  module1
 pom.xml
  module2
 pom.xml

When I execute 'clean package scm:tag -Dtag=tag1' root folder is tagged 
perfectly to (Subversion) /tags/tag1 but scm:tag is then executed for 
each submodule, i.e. it tries to tag module1 folder to /tags/tag1, but 
tag1 already exists and svn reports error.
I need to be able to stop recursive processing of child poms, because all 
subdirectories of root are already tagged

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MPJALOPY-12) Add a property that controls the source code encoding

2007-04-12 Thread Lukas Theussl (JIRA)


[ 
http://jira.codehaus.org/browse/MPJALOPY-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92722
 ] 

Lukas Theussl commented on MPJALOPY-12:
---

What happens if maven.compile.encoding is null (it is not set by default by the 
java plugin)?

 Add a property that controls the source code encoding
 -

 Key: MPJALOPY-12
 URL: http://jira.codehaus.org/browse/MPJALOPY-12
 Project: maven-jalopy-plugin
  Issue Type: Improvement
 Environment: working on a machine with diffrent (default) encoding 
 then the java source code
Reporter: Joachim Bader
 Fix For: 1.5.1

 Attachments: patch.diff


 from http://jalopy.sourceforge.net/existing/plugin-ant-usage.html
 encoding Sets the encoding that controls how Jalopy interprets text 
 files containing characters beyond the ASCII character set. Defaults to the 
 platform default encoding.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (SCM-298) Cannot add timestamp at the beginning of tag name

2007-04-12 Thread Alexander Burak (JIRA)

Cannot add timestamp at the beginning of tag name
-

 Key: SCM-298
 URL: http://jira.codehaus.org/browse/SCM-298
 Project: Maven SCM
  Issue Type: Improvement
Reporter: Alexander Burak
Priority: Minor


At the moment timestamp can only be added to the end of tag name, like 
tagname-MMdd, it would be nice to be able to add it to the beginning of 
tag name too: MMdd-tagname

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MEAR-62) scope provided not applied

[
http://jira.codehaus.org/browse/MEAR-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92724
]

johan Eltes commented on MEAR-62:
-

A clean-room project worked as expected. I cleaned the repository and rebuilt
the real-world system. It made me discover inconsistent group names. I changed
group namespace of my artifacts half through but left one depenency to the old
binary which - of cause - had a POM missing the concerned scope elements. Sorry
for spamming jira... Keep up the great work :-)

scope provided not applied

Key: MEAR-62
URL: http://jira.codehaus.org/browse/MEAR-62
Project: Maven 2.x Ear Plugin
Issue Type: Bug
Affects Versions: 2.3
Environment: Any
Reporter: johan Eltes
Assignee: Stephane Nicoll

When packaging an ear, the ear plugin does not exclude transitive
dependencies with scope provided. A war or ejb project may declare
provided-scoped dependencies (e.g. j2ee apis). The purpose is to not
include these dependencies when packaging the archive. For enterprise
applications, the EAR project is responsible for doing the packaging of its
modules dependencies. Although scope packaging is defined for transitive
dependencies (dependencies declared by the module POMs), the ear plug-in
still includes these libraries in the produced ear.

[jira] Commented: (MNG-2921) ejb-client dependency no longer working

2007-04-12 Thread Klaus Brunner (JIRA)


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

Klaus Brunner commented on MNG-2921:


I don't know about the 'community', but I've certainly noticed it as well. This 
is a major problem for us and I hope it's fixed very quickly.

 ejb-client dependency no longer working
 ---

 Key: MNG-2921
 URL: http://jira.codehaus.org/browse/MNG-2921
 Project: Maven 2
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 2.0.6
 Environment: Fedora Core 6
Reporter: Frank Cornelis
Priority: Blocker
 Attachments: test.zip


 When running 'mvn clean install' on the test project (see attachment) under 
 Maven 2.0.5 every builds as expected. On Maven 2.0.6 it no longer compiles. 
 On Maven 2.0.5 I get in the log:
 [DEBUG] be.frankcornelis.maven:client:jar:1.0-SNAPSHOT (selected for null)
 [DEBUG]   be.frankcornelis.maven:model:ejb-client:client:1.0-SNAPSHOT:compile 
 (selected for compile)
 Under Maven 2.0.6 I get:
 [DEBUG] be.frankcornelis.maven:client:jar:1.0-SNAPSHOT (selected for null)
 [DEBUG]   be.frankcornelis.maven:model:ejb-client:client:1.0-SNAPSHOT 
 (selected for null)
 and an error message saying it cannot find the required interfaces defined in 
 Model.
 When I remove type:ejb-client in the Client pom.xml it compiles again.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MEAR-62) scope provided not applied


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

johan Eltes closed MEAR-62.
---

Resolution: Cannot Reproduce

Requested feature already there. User error.

 scope provided not applied
 

 Key: MEAR-62
 URL: http://jira.codehaus.org/browse/MEAR-62
 Project: Maven 2.x Ear Plugin
  Issue Type: Bug
Affects Versions: 2.3
 Environment: Any
Reporter: johan Eltes
Assignee: Stephane Nicoll

 When packaging an ear, the ear plugin does not exclude transitive 
 dependencies with scope provided. A war or ejb project may declare 
 provided-scoped dependencies (e.g. j2ee apis). The purpose is to not 
 include these dependencies when packaging the archive. For enterprise 
 applications, the EAR project is responsible for doing the packaging of its 
 modules dependencies. Although scope packaging is defined for transitive 
 dependencies (dependencies declared by the module POMs), the ear plug-in 
 still includes these libraries in the produced ear.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (SCM-244) In maven-scm-test, ChangeLogCommandTckTest relies on unreliable timing and fails for some SCM systems

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

Ryan Daum reopened SCM-244:
---

Patch contained an insufficiently long wait time to make the test work.
Attaching the resolved patch.

In maven-scm-test, ChangeLogCommandTckTest relies on unreliable timing and
fails for some SCM systems
-

Key: SCM-244
URL: http://jira.codehaus.org/browse/SCM-244
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-api
Environment: Linux 2.6, JDK 1.5, Maven 2
Reporter: Ryan Daum
Assignee: Emmanuel Venisse
Fix For: 1.0-beta-5

Attachments: maven-scm-test-TickPatch.patch

I encountered this problem while fixing a new Mercurial SCM provider so that
all its unit tests pass.
A Mercurial repository which can reproduce the bug can be found at
http://darksleep.com/~ryan/maven-scm-provider-hg.cgi -- use the mercurial
client to clone this repository. The problem manifests itself in
HgChangeLogCommandTckTest.
ChangeLogCommandTckTestchecks in two revisions in sequence, and records the
time between them. It then tries, using date/time filtering to retrieve only
the later one.
This may work fine for slower network based revision control systems where
there is an appreciable pause between checkins, but for Mercurial, the
creation of the file and its checkin often happens within the same second and
so the log reports the same time for creation of both revisions.
Therefore during the date-time range query, nothing fits _between_ the date
filter range.
In _some_ cases, if the checkin happens of the second file happens to occur
after the second value of the date increments, the test passes, but this is
the exception to the rule.
The fix would be to modify ChangeLogCommandTckTest to perform a sleep of at
least 1 second between checkins.
To reproduce, checkout (as mentioned above) the Mercurial SCM provider and
run the unit tests. You will see HgChangeLogCommandTckTest fail in the
manner described above.

[jira] Updated: (SCM-244) In maven-scm-test, ChangeLogCommandTckTest relies on unreliable timing and fails for some SCM systems

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

Ryan Daum updated SCM-244:
--

Attachment: ChangeLogCommandTckTest-SCM-244.patch

Patch to fix tick timeout.

In maven-scm-test, ChangeLogCommandTckTest relies on unreliable timing and
fails for some SCM systems
-

Attachments: ChangeLogCommandTckTest-SCM-244.patch,
maven-scm-test-TickPatch.patch

[jira] Commented: (SCM-230) mercurial plugin


[ 
http://jira.codehaus.org/browse/SCM-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92734
 ] 

Ryan Daum commented on SCM-230:
---

Since I don't have check-in priviledges, and I've done work to bring this 
provider up to spec with the current 1.0-SNAPSHOT maven-scm API that is on 
trunk, I am attaching a tarball for someeone else (Emmanuel?) to check into 
Subversion.

 mercurial plugin
 

 Key: SCM-230
 URL: http://jira.codehaus.org/browse/SCM-230
 Project: Maven SCM
  Issue Type: New Feature
Reporter: solo turn
Assignee: Joakim Erdfelt
 Attachments: maven-scm-hg.tar.gz, maven-scm-provider-hg-0.09.tbz, 
 maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg-0.8.tbz, 
 maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg.diff.gz, 
 maven-scm-provider-hg.tar.gz, maven-scm-provider-hg.tgz


 it would be nice to have a mercurial source provider. and if not, it would be 
 nice to update the documentation on http://maven.apache.org/scm/ so that 
 anybody could just copy the bzr provider and make a mercurial provider out of 
 it. it should be nearly the same implementation.
 mercurial is (currently) much faster than bzr and therefor really useable.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (SCM-230) mercurial plugin


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

Ryan Daum updated SCM-230:
--

Attachment: maven-scm-provider-hg-1.0-SNAPSHOT.tar.gz

Please integrate this provider; passes all tests.

 mercurial plugin
 

 Key: SCM-230
 URL: http://jira.codehaus.org/browse/SCM-230
 Project: Maven SCM
  Issue Type: New Feature
Reporter: solo turn
Assignee: Joakim Erdfelt
 Attachments: maven-scm-hg.tar.gz, maven-scm-provider-hg-0.09.tbz, 
 maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg-0.8.tbz, 
 maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg-1.0-SNAPSHOT.tar.gz, 
 maven-scm-provider-hg.diff.gz, maven-scm-provider-hg.tar.gz, 
 maven-scm-provider-hg.tgz


 it would be nice to have a mercurial source provider. and if not, it would be 
 nice to update the documentation on http://maven.apache.org/scm/ so that 
 anybody could just copy the bzr provider and make a mercurial provider out of 
 it. it should be nearly the same implementation.
 mercurial is (currently) much faster than bzr and therefor really useable.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (SUREFIRE-310) surefire-reports failes to locate java, returns There are test failures.


[ 
http://jira.codehaus.org/browse/SUREFIRE-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92740
 ] 

Brett Porter commented on SUREFIRE-310:
---

Can't reproduce using a symlink which has spaces, but it might be resolving it. 
Try on Windows, then will close cannot reproduce.

Could be because of the unswizzled 2.0.6


 surefire-reports failes to locate java, returns There are test failures.
 --

 Key: SUREFIRE-310
 URL: http://jira.codehaus.org/browse/SUREFIRE-310
 Project: Maven Surefire
  Issue Type: Bug
  Components: report plugin
Affects Versions: 2.3.1
 Environment: Windows, Sun JDK 1.5 u10, environment variables include: 
 JAVA_HOME = C:\Program Files\Java\jdk1_5
Reporter: Steve Lewis
Priority: Critical
 Fix For: 2.3.1

 Attachments: execution_error.txt


 When the JAVA_HOME environment variable includes spaces, surefire-reports 
 execution failes to locate java 
 Partial error below, full error in context is available in attachment.
 Forking command line: C:\Program Files\Java\jdk1.5.0_10\jre\bin\java 
 -classpath [...] 
 'C:\Program' is not recognized as an internal or external command,
 operable program or batch file.
 [INFO] 
 
 [ERROR] BUILD FAILURE
 [INFO] 
 
 [INFO] There are test failures.
 [INFO] 
 
 This is similar to behavior the gwt-maven plugin experienced a little while 
 back,
 http://groups.google.com/group/gwt-maven/browse_thread/thread/b8ccf7896b0f65f0/df999ee333246567%23df999ee333246567
 WORKAROUNDS:
   Either changing JAVA_HOME to not use spaces 
 such as c:\progra~1\java\jdk1_5
   Explicitly use a previous version of the maven-surefire-plugin 
 such as
 plugin
   artifactIdmaven-surefire-plugin/artifactId
   version2.3/version
 /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: (SUREFIRE-297) argLine has changed behavior from 2.2 to 2.3.

[
http://jira.codehaus.org/browse/SUREFIRE-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92741
]

Brett Porter commented on SUREFIRE-297:
---

On Mac, quoting whole argument works on Mac in 2.2, 2.3, 2.3.1-SNAPSHOT. Check
Windows.

On Mac, -Dproperty1=value1 1 fails every time with the weird quoting - this
may be fixed by the newer plexus-utils. Review.

Seems to be an issue with the unswizzled 2.0.6. Can close, but document that
full argument quoting is necessary.

argLine has changed behavior from 2.2 to 2.3.
-

Key: SUREFIRE-297
URL: http://jira.codehaus.org/browse/SUREFIRE-297
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.3
Environment: Windows XP
Reporter: Bård Dybwad Kristensen
Priority: Critical
Fix For: 2.3.1

Hi
I have used the following configuration for the surefire plugin version 2.2:
configuration
argLine-verbose
-javaagent:D:\.m2\repository\jmockit\jmockit\0.83\jmockit-0.83.jar/argLine
/configuration
It works (not really, but that is another issue). But when I downloaded
version 2.3, this stopped working. The -verbose argument is still forwarded
to the java process, but the -javaagent is not forwarded. If I switch back to
the 2.2 version of the plug in, everything is fine. Any ideas?
regards,
bdk

[jira] Commented: (SUREFIRE-317) Properties in surefire reports are no longer escaped


[ 
http://jira.codehaus.org/browse/SUREFIRE-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92739
 ] 

Brett Porter commented on SUREFIRE-317:
---

was likely on a snapshot of 2.0.6 that didn't swizzle plexus-utils. Upgrading 
to p-u 1.4 seems like it's going to be bad for surefire's health, so sticking 
to 1.1 for now.

 Properties in surefire reports are no longer escaped
 

 Key: SUREFIRE-317
 URL: http://jira.codehaus.org/browse/SUREFIRE-317
 Project: Maven Surefire
  Issue Type: Bug
  Components: xml generation
Affects Versions: 2.3
 Environment: Mac OS X, JVM 1.5
Reporter: Jacob Bay Hansen
Assignee: Brett Porter
 Fix For: 2.3.1


 In version 2.0.4 the properties section of the surefire reports would look 
 like this:
 property value=quot;Apple Computer, Inc.quot; name=java.vm.vendor/
 in version 2.0.6 it look like this:
 property value=Apple Computer, Inc name=java.vm.vendor/
 So later reporters report XML parse errors

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (SUREFIRE-302) Inconsistent surefire artifacts are being brought into the chain causing configuration problems


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

Brett Porter closed SUREFIRE-302.
-

  Assignee: Brett Porter
Resolution: Cannot Reproduce

I believe this was pre-swizzling plexus-utils. Works now.

 Inconsistent surefire artifacts are being brought into the chain causing 
 configuration problems
 ---

 Key: SUREFIRE-302
 URL: http://jira.codehaus.org/browse/SUREFIRE-302
 Project: Maven Surefire
  Issue Type: Bug
Reporter: Jason van Zyl
Assignee: Brett Porter
 Fix For: 2.3.1


 A by product of forking being turned on in the Maven Embedder tests I can see 
 that it's looking for the executable field which doesn't exist in 2.2. The 
 POMs need to be checked and really be updated to use depMan so we can control 
 everything from a top level directory.
 Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.025 sec  
 FAILURE!  

 testEmbedderWillStillStartupWhenTheSettingsConfigurationIsCrap(org.apache.maven.embedder.MavenEmbedderCrappySettingsConfigurationTest)
   Time elapsed: 1.015 sec   ERROR!
 java.lang.NoSuchFieldError: executable
   

 at 
 org.apache.maven.surefire.booter.Commandline.getShellCommandline(Commandline.java:79)
   
  
 at 
 org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java:625)
   
 
 at 
 org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:102)
   

 at 
 org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:89)
   
 
 at 
 org.apache.maven.surefire.booter.SurefireBooter.fork(SurefireBooter.java:553) 
   
 
 at 
 org.apache.maven.surefire.booter.SurefireBooter.forkSuites(SurefireBooter.java:412)
   

 at 
 org.apache.maven.surefire.booter.SurefireBooter.runSuitesForkOnce(SurefireBooter.java:312)
   
 
 at 
 org.apache.maven.surefire.booter.SurefireBooter.run(SurefireBooter.java:202)  
   
 
 at 
 org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:398)
   
   
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:598)
   

 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:499)
   

 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:440)
  
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:419)
   
 
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:271)
  
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:238)
   
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:146)
   
 
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:303)

[jira] Closed: (SUREFIRE-301) Surefire is forking when it's not requested