[jira] [Comment Edited] (MDEP-690) go-offline fails when optional dependencies cannot be resolved

[Stephen Coy (Jira)]

[ 
https://issues.apache.org/jira/browse/MDEP-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17273481#comment-17273481
 ] 

Stephen Coy edited comment on MDEP-690 at 1/28/21, 10:13 AM:
-

This has just bitten us too.

{{go-offline}} should not be downloading optional dependencies at all. 

If the end user requires the dependency then they must declare it explicitly 
sans the {{optional}} tag, otherwise they would never see it at runtime.

 


was (Author: sfcoy):
go-offline should not be downloading optional dependencies at all. 

If the end user requires the dependency then they must declare it explicitly 
sans the `optional` tag, otherwise they would never see it at runtime.

 

> go-offline fails when optional dependencies cannot be resolved
> --
>
> Key: MDEP-690
> URL: https://issues.apache.org/jira/browse/MDEP-690
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: go-offline
>Affects Versions: 3.1.2
>Reporter: Stephan Schroevers
>Priority: Major
>
> Consider the following dummy project:
> {code:xml}
> 
> 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 
> https://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> com.example
> example
> 0.0.1-SNAPSHOT
> 
> 
> io.projectreactor.addons
> reactor-extra
> 3.3.3.RELEASE
> 
> 
> 
> {code}
> Running {{org.apache.maven.plugins:maven-dependency-plugin:3.1.1:go-offline}} 
> against this project passes. With version 3.1.2 the goal fails with:
> {noformat}
> org.eclipse.aether.resolution.DependencyResolutionException: Could not find 
> artifact org.eclipse.swt:org.eclipse.swt.gtk.linux.x86_64:jar:4.5.2 in 
> central (https://repo.maven.apache.org/maven2)
> {noformat}
> The reason for the failure appears to be that {{reactor-extra}} declares an
> [optional|https://repo1.maven.org/maven2/io/projectreactor/addons/reactor-extra/3.3.3.RELEASE/reactor-extra-3.3.3.RELEASE.pom]
>  dependency on {{org.eclipse.swt.gtk.linux.x86_64}}, an artifact which is not 
> present in Maven Central.
> It'd be nice if the version 3.1.1 behavior of the plugin could be reinstated. 
> Alternatively (perhaps better?) it should be possible to conditionally 
> exclude optional dependencies, just like the goal allows one to exclude 
> dependencies by artifact ID, group ID, classifier, scope and type.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MDEP-690) go-offline fails when optional dependencies cannot be resolved

[Stephen Coy (Jira)]

[ 
https://issues.apache.org/jira/browse/MDEP-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17273481#comment-17273481
 ] 

Stephen Coy commented on MDEP-690:
--

go-offline should not be downloading optional dependencies at all. 

If the end user requires the dependency then they must declare it explicitly 
sans the `optional` tag, otherwise they would never see it at runtime.

 

> go-offline fails when optional dependencies cannot be resolved
> --
>
> Key: MDEP-690
> URL: https://issues.apache.org/jira/browse/MDEP-690
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: go-offline
>Affects Versions: 3.1.2
>Reporter: Stephan Schroevers
>Priority: Major
>
> Consider the following dummy project:
> {code:xml}
> 
> 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 
> https://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> com.example
> example
> 0.0.1-SNAPSHOT
> 
> 
> io.projectreactor.addons
> reactor-extra
> 3.3.3.RELEASE
> 
> 
> 
> {code}
> Running {{org.apache.maven.plugins:maven-dependency-plugin:3.1.1:go-offline}} 
> against this project passes. With version 3.1.2 the goal fails with:
> {noformat}
> org.eclipse.aether.resolution.DependencyResolutionException: Could not find 
> artifact org.eclipse.swt:org.eclipse.swt.gtk.linux.x86_64:jar:4.5.2 in 
> central (https://repo.maven.apache.org/maven2)
> {noformat}
> The reason for the failure appears to be that {{reactor-extra}} declares an
> [optional|https://repo1.maven.org/maven2/io/projectreactor/addons/reactor-extra/3.3.3.RELEASE/reactor-extra-3.3.3.RELEASE.pom]
>  dependency on {{org.eclipse.swt.gtk.linux.x86_64}}, an artifact which is not 
> present in Maven Central.
> It'd be nice if the version 3.1.1 behavior of the plugin could be reinstated. 
> Alternatively (perhaps better?) it should be possible to conditionally 
> exclude optional dependencies, just like the goal allows one to exclude 
> dependencies by artifact ID, group ID, classifier, scope and type.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MDEP-568) dependency:go-offline -DexcludeGroupIds=xxxx still try to resolve artifacts in the excluded group xxxx

[Stephen Coy (Jira)]

[ 
https://issues.apache.org/jira/browse/MDEP-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17273474#comment-17273474
 ] 

Stephen Coy commented on MDEP-568:
--

+1 here too. This plugin is standard for prepping an environment via CircleCI

 

> dependency:go-offline -DexcludeGroupIds= still try to resolve artifacts 
> in the excluded group 
> --
>
> Key: MDEP-568
> URL: https://issues.apache.org/jira/browse/MDEP-568
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: go-offline, resolve
>Affects Versions: 2.3, 3.0.0
> Environment: windows / cygwin xp64 bit / bash / maven 3.0.3
>Reporter: Archimedes Trajano
>Priority: Major
> Attachments: MDEP-568-maven-dependency-plugin.patch, 
> go-offline_copy-dependencies_patch_sample.zip, test.tgz
>
>
> see thread: 
> http://mail-archives.apache.org/mod_mbox/maven-users/201109.mbox/%3c0B02C46601D44673A4A2DF4C4F907E9E@black%3e
> in attached sample pom structure:
> mvn org.apache.maven.plugins:maven-dependency-plugin:2.3:go-offline 
> -DexcludeGroupIds=us.pdinc.foo.maven.test
> fails



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] Issue Comment Edited: (MEAR-118) Invalid application.xml generated

[Stephen Coy (JIRA)]

[ 
http://jira.codehaus.org/browse/MEAR-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250451#action_250451
 ] 

Stephen Coy edited comment on MEAR-118 at 1/4/11 4:17 PM:
--

This is correct for J2EE 1.3.
J2EE 1.4 moved from DTDs to schemas where the order of the elements was made 
more consistent for all of the different deployment descriptors.
Perhaps you need to specify the J(2)EE version in the plugin config?

  was (Author: sfcoy):
This is correct for J2EE 1.3.
J2EE 1.4 moved from DTDs to schemas where the order of the elements was made 
more consistent for all of the different deployment descriptors.

  
> Invalid application.xml generated
> -
>
> Key: MEAR-118
> URL: http://jira.codehaus.org/browse/MEAR-118
> Project: Maven 2.x Ear Plugin
>  Issue Type: Bug
>Affects Versions: 2.4
> Environment: Maven 2.2.1
>Reporter: Stephen Coy
>Assignee: Stephane Nicoll
>Priority: Critical
> Fix For: 2.4.1
>
> Attachments: ApplicationXmlWriter.java.patch
>
>
> If a project description is specified in the pom.xml, then the plugin 
> generates a corresponding description from pom 
> element in the application.xml file.
> Unfortunately, it places it in the wrong location according to the schema 
> (for both J2EE 1.4 and JEE 5):
>   artifact name
>   project description
>   
>   ...
> instead of:
>   project description
>   artifact name
>   
>   ...
> This results in deployment failure on WebSphere.
> Work around is to roll back to version 2.3.2 of the ear 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: (MEAR-118) Invalid application.xml generated

[Stephen Coy (JIRA)]

[ 
http://jira.codehaus.org/browse/MEAR-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250451#action_250451
 ] 

Stephen Coy commented on MEAR-118:
--

This is correct for J2EE 1.3.
J2EE 1.4 moved from DTDs to schemas where the order of the elements was made 
more consistent for all of the different deployment descriptors.


> Invalid application.xml generated
> -
>
> Key: MEAR-118
> URL: http://jira.codehaus.org/browse/MEAR-118
> Project: Maven 2.x Ear Plugin
>  Issue Type: Bug
>Affects Versions: 2.4
> Environment: Maven 2.2.1
>Reporter: Stephen Coy
>Assignee: Stephane Nicoll
>Priority: Critical
> Fix For: 2.4.1
>
> Attachments: ApplicationXmlWriter.java.patch
>
>
> If a project description is specified in the pom.xml, then the plugin 
> generates a corresponding description from pom 
> element in the application.xml file.
> Unfortunately, it places it in the wrong location according to the schema 
> (for both J2EE 1.4 and JEE 5):
>   artifact name
>   project description
>   
>   ...
> instead of:
>   project description
>   artifact name
>   
>   ...
> This results in deployment failure on WebSphere.
> Work around is to roll back to version 2.3.2 of the ear 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: (MEAR-60) Improve support for skinny war files

[Stephen Coy (JIRA)]

[ 
http://jira.codehaus.org/browse/MEAR-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=236354#action_236354
 ] 

Stephen Coy commented on MEAR-60:
-

Actually we need to be a little careful of the "all" approach because spec 
wise, the container will only look for taglibs in jars within the WEB-INF/lib 
directory of the WAR.


> Improve support for skinny war files
> 
>
> Key: MEAR-60
> URL: http://jira.codehaus.org/browse/MEAR-60
> Project: Maven 2.x Ear Plugin
>  Issue Type: Improvement
>Affects Versions: 2.3
> Environment: mvn 2.0.5
>Reporter: Marcel Schutte
>Priority: Critical
> Attachments: maven-ear-plugin-MEAR-60.patch
>
>
> Provide a boolean configuration option for webModules to include the war's 
> transitive dependencies.
> As described on 
> http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html it 
> is very common in a J2EE environment to use so called skinny wars. Here the 
> war's WEB-INF/lib will not contain the dependent jars, but instead they are 
> packaged inside the EAR. The war references them through its 
> META-INF/MANIFEST.MF
> This option could be used to avoid the 'painful part' mentioned in the above 
> web page. The war's dependencies wouldn't have to be duplicated alongside the 
> ear's.
> I also found an old issue (MEAR-14) which has asked for the current default 
> behavior of not including the transitive dependencies. It suggests a property 
> to include specific dependencies of the war. As far as I can tell this has 
> never been implemented and this is also not what I am asking for. My proposal 
> is an all of nothing kind of option for each war module in the ear.
> On a side note, for me this is the part where removal of the old maven 1 
> style properties per dependency is missed the most. With them it was possible 
> to decide for each single dependency whether to put it in WEB-INF/lib or 
> reference it through the manifest classpath. But of course, then we didn't 
> have the transitive dependencies

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

[jira] Commented: (MWAR-237) packagingIncludes configuration has disappeared

[Stephen Coy (JIRA)]

[ 
http://jira.codehaus.org/browse/MWAR-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=236039#action_236039
 ] 

Stephen Coy commented on MWAR-237:
--

Isn't the plugin documentation generated from the source? It does not appear on 
. This is what 
makes me think it has disappeared. Furthermore, it works fine using 2.1-beta-1.

The only practical work around is to downgrade, hence the blocker.

In any event, here is the plugin configuration:


maven-war-plugin



false



true
src/main/webapp

MessageResources.properties






default-war
package

war



slim-war
package

war


slim

fusioncharts/**/*,
fusionwidgets/**/*,
global-theme/**/*,
home.do,
images/**/*,
META-INF/**/*,
scripts/**/*,
WEB-INF/classes/**/*,
WEB-INF/config/**/*,
WEB-INF/**/*.xml,
WEB-INF/jsp/**/*,
WEB-INF/lib/sitemesh*.jar,
WEB-INF/lib/struts*.jar,
WEB-INF/lib/json-lib*.jar,
WEB-INF/lib/ezmorph*.jar,
WEB-INF/lib/displaytag*.jar,
WEB-INF/lib/commons-fileupload*.jar,
WEB-INF/tlds/**/*







> packagingIncludes configuration has disappeared
> ---
>
> Key: MWAR-237
> URL: http://jira.codehaus.org/browse/MWAR-237
> Project: Maven 2.x WAR Plugin
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: 2.2.1, 3.0RC1
>Reporter: Stephen Coy
>Assignee: Stephane Nicoll
>Priority: Minor
>
> The packagingIncludes configuration element has completely disappeared from 
> this plugin.
> This not only breaks our "skinny-war" build, it also invalidates the 
> documentation at 
> .

-- 
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: (MWAR-237) packagingIncludes configuration has disappeared

[Stephen Coy (JIRA)]

packagingIncludes configuration has disappeared
---

 Key: MWAR-237
 URL: http://jira.codehaus.org/browse/MWAR-237
 Project: Maven 2.x WAR Plugin
  Issue Type: Bug
Affects Versions: 2.1
 Environment: 2.2.1, 3.0RC1
Reporter: Stephen Coy
Priority: Blocker


The packagingIncludes configuration element has completely disappeared from 
this plugin.

This not only breaks our "skinny-war" build, it also invalidates the 
documentation at 
.



-- 
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: (SUREFIRE-647) Memory Leak

[Stephen Coy (JIRA)]

Memory Leak
---

 Key: SUREFIRE-647
 URL: http://jira.codehaus.org/browse/SUREFIRE-647
 Project: Maven Surefire
  Issue Type: Bug
Affects Versions: 2.6
 Environment: Maven 2.2.1, 3.0RC1
Reporter: Stephen Coy
Priority: Critical
 Attachments: surefire dump.png

We have a module containing over 500 unit tests, most of which create Hibernate 
sessions with a largish data model.

Surefire 2.6 fails to complete these tests, even with:
 -Xmx512m
specified.

Surefire 2.5 (and earlier) completes these tests with no trouble at all, 
without jvmArg settings.

I performed a heapdump (which is too big to upload here) and it shows that 
org.apache.maven.surefire.util.TeeStream seems to be hanging on to data in 
memory. The 20 biggest objects by retained size were all instances of this. 
I've attached a screen dump


-- 
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: (MNGSITE-112) Sample mirror settings at http://maven.apache.org/guides/mini/guide-configuring-maven.html contains an outdated link

[Stephen Coy (JIRA)]

Sample mirror settings at 
http://maven.apache.org/guides/mini/guide-configuring-maven.html contains an 
outdated link


 Key: MNGSITE-112
 URL: http://jira.codehaus.org/browse/MNGSITE-112
 Project: Maven 2 Project Web Site
  Issue Type: Improvement
Reporter: Stephen Coy


The Australian mirror site that is referenced has not worked in years. It will 
only add to user confusion when it fails to work as advertised.

-- 
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-118) Invalid application.xml generated

[Stephen Coy (JIRA)]

[ 
http://jira.codehaus.org/browse/MEAR-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207026#action_207026
 ] 

Stephen Coy commented on MEAR-118:
--

Be very careful with this because the order of the elements was reversed 
between J2EE 1.3 and J2EE 1.4.

This plugin currently works correctly for J2EE 1.3 ear files.


> Invalid application.xml generated
> -
>
> Key: MEAR-118
> URL: http://jira.codehaus.org/browse/MEAR-118
> Project: Maven 2.x Ear Plugin
>  Issue Type: Bug
>Affects Versions: 2.4
> Environment: Maven 2.2.1
>Reporter: Stephen Coy
>Priority: Critical
> Fix For: 2.4.1
>
> Attachments: ApplicationXmlWriter.java.patch
>
>
> If a project description is specified in the pom.xml, then the plugin 
> generates a corresponding description from pom 
> element in the application.xml file.
> Unfortunately, it places it in the wrong location according to the schema 
> (for both J2EE 1.4 and JEE 5):
>   artifact name
>   project description
>   
>   ...
> instead of:
>   project description
>   artifact name
>   
>   ...
> This results in deployment failure on WebSphere.
> Work around is to roll back to version 2.3.2 of the ear 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] Created: (MEAR-118) Invalid application.xml generated

[Stephen Coy (JIRA)]

Invalid application.xml generated
-

 Key: MEAR-118
 URL: http://jira.codehaus.org/browse/MEAR-118
 Project: Maven 2.x Ear Plugin
  Issue Type: Bug
Affects Versions: 2.4
 Environment: Maven 2.2.1
Reporter: Stephen Coy
Priority: Critical


If a project description is specified in the pom.xml, then the plugin generates 
a corresponding description from pom element in the 
application.xml file.

Unfortunately, it places it in the wrong location according to the schema (for 
both J2EE 1.4 and JEE 5):

  artifact name
  project description
  
  ...

instead of:

  project description
  artifact name
  
  ...

This results in deployment failure on WebSphere.

Work around is to roll back to version 2.3.2 of the ear 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] Created: (WAGON-288) wagon-http uses old and cranky JTidy implementation

[Stephen Coy (JIRA)]

wagon-http uses old and cranky JTidy implementation
---

 Key: WAGON-288
 URL: http://jira.codehaus.org/browse/WAGON-288
 Project: Maven Wagon
  Issue Type: Bug
  Components: wagon-http
Affects Versions: 1.0-beta-6
 Environment: Java 6
Reporter: Stephen Coy


JTidy version "4aug2000r7-dev" contains obsolete org.w3c.dom.* and 
org.xml.sax.* classes which arguably should not be there at all. This can cause 
java.lang.LinkageError to occur. 

The JTidy project at  has seen a new lease of 
life recently, and there are new builds that no longer include these classes.

So, the JTidy developers need to be encouraged to deploy to the central maven 
repo so that wagon can then make use of the new jtidy artifact.

I found this while hacking Continuum 1.3.4 so that it deploys and runs in JBoss 
5.1 and Java 6. I've replaced the old jtidy with jtidy-r918.jar from the 
sourceforge site.





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

[jira] Commented: (MRELEASE-270) release:prepare doesn't fail when the project it is building fails to compile

[Stephen Coy (JIRA)]

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

Stephen Coy commented on MRELEASE-270:
--

We have noticed the same behavior when unit tests fail too.

I think this is a regression in one of the maven components because the same 
release plugin behaves correctly with maven 2.0.5.



> release:prepare doesn't fail when the project it is building fails to compile
> -
>
> Key: MRELEASE-270
> URL: http://jira.codehaus.org/browse/MRELEASE-270
> Project: Maven 2.x Release Plugin
>  Issue Type: Bug
>Affects Versions: 2.0-beta-6
>Reporter: William Ferguson
> Attachments: MRELEASE-XXX.zip
>
>
> Unusual situation on our build server, where one of the dependent libraries 
> had been corrupted in its local repository.
> 'mvn compile' would fail with compilation errors - it couldn't find the 
> classes from the corrupt jar.
> 'mvn release:prepare' would note compilation errors and indicate build 
> failure, but would continue on with the release, modify the POMs, tag the 
> source and finally complete indicating success.
> I noted that the same thing can happen if uncompilable source is checked in, 
> though at least then you would get the compilation failure on your local 
> machine too.
> I think release:prepare should clearly fail (it wasn't clear in this instance 
> unless you scrolled back through the build output) if any part of the 
> release:prepare fails.
> To replicate either
> a) Attempt top release uncompilable code.
> b) Replace a dependent jar with a renamed text file and attempt to release.

-- 
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: (SUREFIRE-288) Surefire tries to instantiate nested TestCase classes

[Stephen Coy (JIRA)]

Surefire tries to instantiate nested TestCase classes
-

 Key: SUREFIRE-288
 URL: http://jira.codehaus.org/browse/SUREFIRE-288
 Project: Maven Surefire
  Issue Type: Bug
  Components: JUnit 3.x support, Junit 4.x support
Affects Versions: 2.0 (2.2 plugin)
 Environment: Windows XP, Java 1.4.2
Reporter: Stephen Coy


If a JUnit TestCase contains any kind of nested class (static or not), Surefire 
feels obliged to try and instantiate it. This will fail with access violations 
if the class is not public.

Work around seems to be to make the nested class public, but surely Surefire 
has no business doing this anyway?

Here is a sample stack trace:

org.apache.maven.surefire.booter.SurefireExecutionException: Unable to 
instantiate POJO 'class 
au.com.optus.eFulfilment.sap.test.moduleTest.TestSapOrderComponent$MySapOrderComponent';
 nested exception is java.lang.InstantiationException: 
au.com.optus.eFulfilment.sap.test.moduleTest.TestSapOrderComponent$MySapOrderComponent;
 nested exception is org.apache.maven.surefire.testset.TestSetFailedException: 
Unable to instantiate POJO 'class 
au.com.optus.eFulfilment.sap.test.moduleTest.TestSapOrderComponent$MySapOrderComponent';
 nested exception is java.lang.InstantiationException: 
au.com.optus.eFulfilment.sap.test.moduleTest.TestSapOrderComponent$MySapOrderComponent
org.apache.maven.surefire.testset.TestSetFailedException: Unable to instantiate 
POJO 'class 
au.com.optus.eFulfilment.sap.test.moduleTest.TestSapOrderComponent$MySapOrderComponent';
 nested exception is java.lang.InstantiationException: 
au.com.optus.eFulfilment.sap.test.moduleTest.TestSapOrderComponent$MySapOrderComponent
java.lang.InstantiationException: 
au.com.optus.eFulfilment.sap.test.moduleTest.TestSapOrderComponent$MySapOrderComponent
at java.lang.Class.newInstance0(Class.java:293)
at java.lang.Class.newInstance(Class.java:261)
at 
org.apache.maven.surefire.testset.PojoTestSet.(PojoTestSet.java:52)
at 
org.apache.maven.surefire.junit.JUnitDirectoryTestSuite.createTestSet(JUnitDirectoryTestSuite.java:61)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:93)
at 
org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:147)
at org.apache.maven.surefire.Surefire.run(Surefire.java:108)
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:324)
at 
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225)
at 
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747)


-- 
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: (WAGON-70) Deploying using scp:// hangs when proxy configured in settings.xml

[Stephen Coy (JIRA)]

[ http://jira.codehaus.org/browse/WAGON-70?page=comments#action_85210 ] 

Stephen Coy commented on WAGON-70:
--

Here is the proxy config from settings.xml:


  optus
  false
  steve.coy
  XXX
  http
  proxy.optus.com.au
  8080
  *.optus.com.au


and here is the  element from distributionManagement section of the 
pom.xml:


  inhouse
  Maven Project Web Server
  
scp://webdevappl005.optus.com.au/var/webdev/master/${project.version}



> Deploying using scp:// hangs when proxy configured in settings.xml
> --
>
> Key: WAGON-70
> URL: http://jira.codehaus.org/browse/WAGON-70
> Project: wagon
>  Issue Type: Bug
>  Components: wagon-ssh
>Affects Versions: 1.0-beta-2
> Environment: Windows XP in a corporate environment that is proxied 
> and firewalled to everywhere
>Reporter: Stephen Coy
>
> For some reason, wagon-ssh is attempting to connect to the proxy defined in 
> settings.xml (irrespective of whether it is enabled or not) in order to 
> perform an scp transfer.
> This causes goals such as site:deploy to hang for some time before proceeding 
> normally.
> A thread dump taken during the hang:
> [INFO] [site:deploy]
> Full thread dump Java HotSpot(TM) Client VM (1.4.2_13-b06 mixed mode):
> "Signal Dispatcher" daemon prio=10 tid=0x009cf600 nid=0xa7c waiting on 
> condition [0x..0x]
> "Finalizer" daemon prio=9 tid=0x009ccbb8 nid=0xb84 in Object.wait() 
> [0x02b6f000..0x02b6fd68]
>   at java.lang.Object.wait(Native Method)
>   - waiting on <0x104fb160> (a java.lang.ref.ReferenceQueue$Lock)
>   at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111)
>   - locked <0x104fb160> (a java.lang.ref.ReferenceQueue$Lock)
>   at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127)
>   at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
> "Reference Handler" daemon prio=10 tid=0x009cb830 nid=0xf38 in Object.wait() 
> [0x02b2f000..0x02b2fd68]
>   at java.lang.Object.wait(Native Method)
>   - waiting on <0x104fb1c8> (a java.lang.ref.Reference$Lock)
>   at java.lang.Object.wait(Object.java:429)
>   at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:115)
>   - locked <0x104fb1c8> (a java.lang.ref.Reference$Lock)
> "main" prio=5 tid=0x00035b28 nid=0xe90 runnable [0x0007f000..0x0007fc38]
>   at java.net.SocketInputStream.socketRead0(Native Method)
>   at java.net.SocketInputStream.read(SocketInputStream.java:129)
>   at java.net.SocketInputStream.read(SocketInputStream.java:182)
>   at com.jcraft.jsch.ProxyHTTP.connect(Unknown Source)
>   at 
> org.apache.maven.wagon.providers.ssh.AbstractSshWagon.openConnection(AbstractSshWagon.java:181)
>   at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143)
>   at 
> org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:149)
>   at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:324)
>   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)

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

[jira] Created: (WAGON-70) Deploying using scp:// hangs when proxy configured in settings.xml

[Stephen Coy (JIRA)]

Deploying using scp:// hangs when proxy configured in settings.xml
--

 Key: WAGON-70
 URL: http://jira.codehaus.org/browse/WAGON-70
 Project: wagon
  Issue Type: Bug
  Components: wagon-ssh
Affects Versions: 1.0-beta-2
 Environment: Windows XP in a corporate environment that is proxied and 
firewalled to everywhere
Reporter: Stephen Coy


For some reason, wagon-ssh is attempting to connect to the proxy defined in 
settings.xml (irrespective of whether it is enabled or not) in order to perform 
an scp transfer.

This causes goals such as site:deploy to hang for some time before proceeding 
normally.

A thread dump taken during the hang:

[INFO] [site:deploy]
Full thread dump Java HotSpot(TM) Client VM (1.4.2_13-b06 mixed mode):


"Signal Dispatcher" daemon prio=10 tid=0x009cf600 nid=0xa7c waiting on 
condition [0x..0x]


"Finalizer" daemon prio=9 tid=0x009ccbb8 nid=0xb84 in Object.wait() 
[0x02b6f000..0x02b6fd68]

at java.lang.Object.wait(Native Method)

- waiting on <0x104fb160> (a java.lang.ref.ReferenceQueue$Lock)

at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111)

- locked <0x104fb160> (a java.lang.ref.ReferenceQueue$Lock)

at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127)

at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)


"Reference Handler" daemon prio=10 tid=0x009cb830 nid=0xf38 in Object.wait() 
[0x02b2f000..0x02b2fd68]

at java.lang.Object.wait(Native Method)

- waiting on <0x104fb1c8> (a java.lang.ref.Reference$Lock)

at java.lang.Object.wait(Object.java:429)

at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:115)

- locked <0x104fb1c8> (a java.lang.ref.Reference$Lock)


"main" prio=5 tid=0x00035b28 nid=0xe90 runnable [0x0007f000..0x0007fc38]

at java.net.SocketInputStream.socketRead0(Native Method)

at java.net.SocketInputStream.read(SocketInputStream.java:129)

at java.net.SocketInputStream.read(SocketInputStream.java:182)

at com.jcraft.jsch.ProxyHTTP.connect(Unknown Source)

at 
org.apache.maven.wagon.providers.ssh.AbstractSshWagon.openConnection(AbstractSshWagon.java:181)

at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143)

at 
org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:149)

at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)

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

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488)

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458)

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)

at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)

at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)

at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:324)

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)




-- 
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-53) ejb-client dependencies should not be treated as J2EE application client modules

[Stephen Coy (JIRA)]

[ http://jira.codehaus.org/browse/MEAR-53?page=comments#action_83697 ] 

Stephen Coy commented on MEAR-53:
-

I agree that adding ejb-client type artifacts as modules by default is 
incorrect. In fact, it should be completely unnecessary to have these kinds of 
artiifacts in an ear file, unless they refer to ejbs in a different ear. 
Application server classloaders make the ejb interfaces visible to other 
modules by default within an ear file.

Default behaviour should always be spec conformant.



> ejb-client dependencies should not be treated as J2EE application client 
> modules
> 
>
> Key: MEAR-53
> URL: http://jira.codehaus.org/browse/MEAR-53
> Project: Maven 2.x Ear Plugin
>  Issue Type: Bug
>Affects Versions: 2.3
> Environment: mvn 2.0.4
>Reporter: Marcel Schutte
>
> With the release of maven-ear-plugin 2.3, it has become default behavior to 
> include a  tag in the generated application.xml for 
> dependencies of type ejb-client.
> This is not the intended use of the  tag and it also causes 
> errors in Websphere 5.1.  is for application client modules 
> (j2ee modules with an application-client.xml deployment descriptor) and 
> certainly not for ejb-client jars (which are from a j2ee perspective regular 
> java jar files).
> I understand from the discussion in MEAR-46 that JBoss users sometimes use 
> the  tags as a means to document the jars that make up an ear. 
> This is al fine, but don't make this the default.
> I suggest turning the behavior around and switching the default to no 
> inclusion in the generated application.xml

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

[jira] Commented: (MEJB-23) Add classifier support

[Stephen Coy (JIRA)]

[ http://jira.codehaus.org/browse/MEJB-23?page=comments#action_82562 ] 

Stephen Coy commented on MEJB-23:
-

Note that the unit tests have been revised so that each one creates a unique 
jar, otherwise the results of previous tests can create false positives

> Add classifier support
> --
>
> Key: MEJB-23
> URL: http://jira.codehaus.org/browse/MEJB-23
> Project: Maven 2.x Ejb Plugin
>  Issue Type: New Feature
>Affects Versions: 2.0, 2.1
> Environment: n/a
>Reporter: Stephen Coy
> Attachments: ejb-classifier.patch
>
>
> Both maven-war-plugin and maven-ear-plugin support the specification of a 
> classifier for the generated artifacts. The maven-ear-plugin even supports 
> specifying a classifier for component ejb-jars.
> However this feature is missing from the maven-ejb-plugin.
> The attached patch adds this feature.
> I've found the classifier to be an essential element when creating builds 
> targeted at different deployment environments.

-- 
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-23) Add classifier support

[Stephen Coy (JIRA)]

Add classifier support
--

 Key: MEJB-23
 URL: http://jira.codehaus.org/browse/MEJB-23
 Project: Maven 2.x Ejb Plugin
  Issue Type: New Feature
Affects Versions: 2.0, 2.1
 Environment: n/a
Reporter: Stephen Coy
 Attachments: ejb-classifier.patch

Both maven-war-plugin and maven-ear-plugin support the specification of a 
classifier for the generated artifacts. The maven-ear-plugin even supports 
specifying a classifier for component ejb-jars.

However this feature is missing from the maven-ejb-plugin.

The attached patch adds this feature.

I've found the classifier to be an essential element when creating builds 
targeted at different deployment environments.




-- 
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-2555) maven-metadata.xml for springframework.spring is missing recent versions

[Stephen Coy (JIRA)]

maven-metadata.xml for springframework.spring is missing recent versions


 Key: MNG-2555
 URL: http://jira.codehaus.org/browse/MNG-2555
 Project: Maven 2
  Issue Type: Bug
  Components: Repositories
 Environment: all
Reporter: Stephen Coy
Priority: Minor


The maven-metadata.xml file for springframework.spring @ ibiblio 
 
is missing recent version information - 1.2.7, 1.2.8 and all the 2.0RC releases.

The main consequence of this (for me) is that the version range [1.2,1.3) 
resolves to 1.2.6 instead of 1.2.8.


-- 
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-94) Allow eclipse:eclipse to work on pom (and other) projects

[Stephen Coy (JIRA)]

[ http://jira.codehaus.org/browse/MECLIPSE-94?page=comments#action_70031 ] 

Stephen Coy commented on MECLIPSE-94:
-

I don't think Kenny's remarks are quite right regarding the use of 'pom' 
projects.

There's at least a couple of scenarios where 'pom' projects are used where the 
generated artifact is not one of the traditional java archives.

1) Ch 6 of the bbwm book uses a pom project for a user guide module where the 
generated artifact is a web site.

2) The assembly plugin seems to require that the project type be 'pom' when the 
primary artifact of the module is an assembly.

I think it's quite reasonable for the eclipse plugin to generate a 'simple' 
.project for this kind of module.

The fact that we have to set the project type to 'pom' in these cases seems to 
be semantically wrong at least, but that is what we have to live with at 
present.


> Allow eclipse:eclipse to work on pom (and other) projects
> -
>
> Key: MECLIPSE-94
> URL: http://jira.codehaus.org/browse/MECLIPSE-94
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Felipe Leme
>
> I'm creating a Java EE project based on the m2book (which I was reviewing; 
> it's not available yet...) and one of the projects is a pom-packaging project 
> used for integration tests. According to Vincent, currently this project must 
> be a pom (in fact, I tried to set it as jar, but then the test phase would be 
> run anyway, which would cause the tests to fail), as it doesn't produces a 
> jar. But as it has java files (on the src/main/it/java directory), I tried to 
> call eclipse:eclipse but it fails, saying that "Not running eclipse plugin 
> goal for pom project".
> For these scenarios, I think a propery would be enough. At first I thought 
> something about a 'force' or 'forceGeneration' property, would enough, which 
> the code change being from:
>  if ( "pom".equals( packaging ) && eclipseProjectDir == null ) 
> to:
>  if (  "pom".equals( packaging ) && eclipseProjectDir == null && 
> !forceGeneration ) 
> Then I realized there is other place where the pom nature is checked:
>  if (  "pom".equals( packaging ) && eclipseProjectDir == null && 
> !forceGeneration ) 
> So, I think a better name for the property would be 'javaProject' and the 
> change would be:
> final boolean isJavaProjectProperty = // read property; defaults to false...
>  if (  "pom".equals( packaging ) && eclipseProjectDir == null && 
> !isJavaProjectProperty ) 
> isJavaProject = isJavaProjectProperty || !"ear".equals( packaging ) && 
> !"pom".equals( packaging );
> If nobody objects and someone is willing to apply the changes, I can provide 
> such patch (with the proper test cases).
> -- Felipe
> PS: I'm assigning it to Vincent for now, as he 'dreamed' that such features 
> already existed :-)

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