[jira] [Commented] (MDEP-541) Allow for a space character as a pathSeparator in dependency:build-classpath

2017-01-09 Thread James Phillpotts (JIRA)

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

James Phillpotts commented on MDEP-541:
---

Another use-case - setting the {{Class-Path}} manifest entries when creating an 
executable jar with reduced dependencies using the maven shade plugin.

> Allow for a space character as a pathSeparator in dependency:build-classpath
> 
>
> Key: MDEP-541
> URL: https://issues.apache.org/jira/browse/MDEP-541
> Project: Maven Dependency Plugin
>  Issue Type: Improvement
>  Components: build-classpath
>Reporter: Giedrius Noreikis
>
> Currently, the {{dependency:build-classpath}} goal does not allow a space 
> character to be specified as a {{pathSeparator}}, which is necessary to 
> generate {{Class-Path}} values for manifests.
> Because of a check {{isPathSepSet = StringUtils.isNotEmpty( pathSeparator )}} 
> in {{BuildClasspathMojo.java}}, the parameter gets ignored in this case, and 
> the classpath is built with a default separator.
> The possible workaround is to fix the path with 
> {{build-helper:regex-property}}:
> {code:xml}
>   
> org.codehaus.mojo
> build-helper-maven-plugin
> 
>   
> fix-classpath-for-manifest
> prepare-package
> regex-property
> 
>   appClasspath
>   ${appClasspath}
>   ;
>
>   false
> 
>   
> 
>   
> {code}
> but a fix would allow for a more straightforward solution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MSHADE-237) ServicesResourceTransformer relocates excluded classes

2016-09-30 Thread James Phillpotts (JIRA)
James Phillpotts created MSHADE-237:
---

 Summary: ServicesResourceTransformer relocates excluded classes 
 Key: MSHADE-237
 URL: https://issues.apache.org/jira/browse/MSHADE-237
 Project: Maven Shade Plugin
  Issue Type: Bug
Affects Versions: 2.4.3, 3.0.0
Reporter: James Phillpotts


If an exclude pattern is specified on a relocator, the 
{{ServicesResourceTransformer}} ignores them.

This is demonstrated by the test, and fixed in the following:

{noformat}
Index: 
src/main/java/org/apache/maven/plugins/shade/resource/ServicesResourceTransformer.java
===
--- 
src/main/java/org/apache/maven/plugins/shade/resource/ServicesResourceTransformer.java
  (revision 1762668)
+++ 
src/main/java/org/apache/maven/plugins/shade/resource/ServicesResourceTransformer.java
  (working copy)
@@ -86,7 +86,10 @@
 String relContent = line;
 for ( Relocator relocator : relocators )
 {
-relContent = relocator.applyToSourceContent( relContent );
+if ( relocator.canRelocateClass(relContent) )
+{
+relContent = relocator.relocateClass(relContent);
+}
 }
 fout.append( relContent + "\n" );
 }
Index: 
src/test/java/org/apache/maven/plugins/shade/resource/ServiceResourceTransformerTest.java
===
--- 
src/test/java/org/apache/maven/plugins/shade/resource/ServiceResourceTransformerTest.java
   (revision 1762668)
+++ 
src/test/java/org/apache/maven/plugins/shade/resource/ServiceResourceTransformerTest.java
   (working copy)
@@ -27,6 +27,7 @@
 import java.io.File;
 import java.io.FileOutputStream;
 import java.io.InputStream;
+import java.util.Collections;
 import java.util.List;
 import java.util.jar.JarEntry;
 import java.util.jar.JarFile;
@@ -46,10 +47,11 @@
 
 @Test
 public void relocatedClasses() throws Exception {
-SimpleRelocator relocator = new SimpleRelocator("org.foo", "borg.foo", 
null, null);
+SimpleRelocator relocator = new SimpleRelocator("org.foo", "borg.foo", 
null,
+Collections.singletonList("org.foo.exclude.**"));
 List relocators = Lists.newArrayList( relocator 
);
 
-String content = "org.foo.Service\n";
+String content = "org.foo.Service\norg.foo.exclude.OtherService\n";
 byte[] contentBytes = content.getBytes( "UTF-8" );
 InputStream contentStream = new ByteArrayInputStream( contentBytes );
 String contentResource = "META-INF/services/org.foo.something.another";
@@ -73,7 +75,8 @@
 InputStream entryStream = jarFile.getInputStream( jarEntry );
 try {
 String xformedContent = IOUtils.toString(entryStream, "utf-8");
-assertEquals("borg.foo.Service" + System.getProperty( 
"line.separator" ), xformedContent);
+assertEquals("borg.foo.Service" + System.getProperty( 
"line.separator" )
++ "org.foo.exclude.OtherService" + System.getProperty( 
"line.separator" ), xformedContent);
 } finally {
 IOUtils.closeQuietly( entryStream );
 jarFile.close();
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] (MPLUGIN-260) Plugin that uses annotations in Java 8 source can't generate descriptor

2014-02-28 Thread James Phillpotts (JIRA)
James Phillpotts created MPLUGIN-260:


 Summary: Plugin that uses annotations in Java 8 source can't 
generate descriptor
 Key: MPLUGIN-260
 URL: https://jira.codehaus.org/browse/MPLUGIN-260
 Project: Maven Plugin Tools
  Issue Type: Bug
  Components: maven-plugin-tools-annotations, Plugin Plugin
Affects Versions: 3.2
Reporter: James Phillpotts
 Attachments: java8.patch

When creating a plugin using Java 8 source (see 
https://github.com/mrpotes/java8-currying), the descriptor is not generated as 
asm v3.3 cannot read Java 8 class files.

This is fixed by updating to asm 5.0_BETA.

Patch attached.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] Created: (MJAVADOC-319) Using groupId and artifactId in dependencySourceInclude results in source not being resolved

2011-06-07 Thread James Phillpotts (JIRA)
Using groupId and artifactId in dependencySourceInclude results in source not 
being resolved


 Key: MJAVADOC-319
 URL: http://jira.codehaus.org/browse/MJAVADOC-319
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.8
 Environment: Maven 3.0.3
Reporter: James Phillpotts


When using the syntax groupId:* dependencies are resolved fine.

However, when using syntax groupId:artifactIdFragment* or groupId:artifactId, 
source dependencies are not resolved.

I have done some debugging, and find that upon entering 
ResourceResolver.resolveAndUnpack, the list of Artifacts to be resolved is 
correct, but on resolution 
(http://svn.apache.org/viewvc/maven/plugins/tags/maven-javadoc-plugin-2.8/src/main/java/org/apache/maven/plugin/javadoc/resolver/ResourceResolver.java?view=markup
 line 336), the list of artifacts returned in the resolution result is null.

I don't know whether this is a bug with the javadoc plugin's use of the 
resolver, or of the resolver which I assume is part of maven core, but I'm 
raising here as I haven't seen the same problem with filtering anywhere else.

-- 
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-735) Surefire plugin does not report fatal VM creation failure

2011-05-09 Thread James Phillpotts (JIRA)

[ 
http://jira.codehaus.org/browse/SUREFIRE-735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=266080#action_266080
 ] 

James Phillpotts commented on SUREFIRE-735:
---

Originally encountered in surefire 2.6, still experienced in 2.8.1 - OS is 
Windows XP, Java 1.5.0_15, Maven 2.2.1

Surefire configuration:
{code:xml}

  maven-surefire-plugin
  2.8.1
  
once
false
true
-Xms16M -Xmx1024m -XX:MaxPermSize=256m
  

{code}

> Surefire plugin does not report fatal VM creation failure
> -
>
> Key: SUREFIRE-735
> URL: http://jira.codehaus.org/browse/SUREFIRE-735
> Project: Maven Surefire
>  Issue Type: Bug
>Reporter: James Phillpotts
>
> Background:
> In a large project with a lot of test classes and classes under test, memory 
> settings have been tuned to prevent test failure. However, Java is fussy 
> about some memory settings, and if it cannot allocate the amount of memory 
> needed, the VM will fail to start.
> Problem:
> When surefire encounters this failure to start, the problem is reported to 
> the user as follows:
> {noformat}
> [INFO] 
> 
> [ERROR] BUILD FAILURE
> [INFO] 
> 
> [INFO] There are test failures.
> Please refer to [snip]\target\surefire-reports for the individual test 
> results.
> {noformat}
> The surefire-reports directory does not exist within target.
> Using debug mode, the command that is executed is found, and when run from a 
> command prompt window, the following output is received:
> {noformat}
> Error occurred during initialization of VM
> Could not reserve enough space for object heap
> Could not create the Java virtual machine.
> {noformat}
> Obviously there is nothing surefire can do about the failure to start the VM, 
> but the error output from the VM itself should be passed back to the user, so 
> that they can do something to remedy it.
> I'd supply some steps to reproduce it, but as it would depend on the memory 
> available on the machine used to test it, they wouldn't necessarily work, but 
> by playing with the Xmx and Xms settings, it should be possible to duplicate 
> this.

-- 
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-735) Surefire plugin does not report fatal VM creation failure

2011-05-06 Thread James Phillpotts (JIRA)
Surefire plugin does not report fatal VM creation failure
-

 Key: SUREFIRE-735
 URL: http://jira.codehaus.org/browse/SUREFIRE-735
 Project: Maven Surefire
  Issue Type: Bug
Reporter: James Phillpotts


Background:

In a large project with a lot of test classes and classes under test, memory 
settings have been tuned to prevent test failure. However, Java is fussy about 
some memory settings, and if it cannot allocate the amount of memory needed, 
the VM will fail to start.

Problem:

When surefire encounters this failure to start, the problem is reported to the 
user as follows:

{noformat}
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There are test failures.

Please refer to [snip]\target\surefire-reports for the individual test results.
{noformat}

The surefire-reports directory does not exist within target.

Using debug mode, the command that is executed is found, and when run from a 
command prompt window, the following output is received:

{noformat}
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
{noformat}

Obviously there is nothing surefire can do about the failure to start the VM, 
but the error output from the VM itself should be passed back to the user, so 
that they can do something to remedy it.

I'd supply some steps to reproduce it, but as it would depend on the memory 
available on the machine used to test it, they wouldn't necessarily work, but 
by playing with the Xmx and Xms settings, it should be possible to duplicate 
this.

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