Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 1.0-rc1
-
Component/s: None
-
Labels:None
-
Environment:Windows 2000
-
Number of attachments :
Description
Compiling project without resources the resulting maven.log file contains a lot of exceptions like this:
2003-09-10 15:36:28,527 WARN org.apache.commons.jelly.expression.jexl.JexlExpression - Caught exception evaluating: org.apache.commons.jexl.ExpressionImpl@19be6ee. Reason: java.lang.NumberFormatException: For input string: "includes"
java.lang.NumberFormatException: For input string: "includes"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Integer.parseInt(Integer.java:468)
at java.lang.Integer.valueOf(Integer.java:574)
at org.apache.commons.jexl.util.Coercion.coerceInteger(Coercion.java:95)
at org.apache.commons.jexl.parser.ASTArrayAccess.evaluateExpr(ASTArrayAccess.java:177)
at org.apache.commons.jexl.parser.ASTIdentifier.execute(ASTIdentifier.java:104)
at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:106)
at java.lang.Integer.parseInt(Integer.java:468)
....
To me this seems to be due to the lack of a couple of check in the jelly script of the java plugin.
I have attached a patch that solve the problem.
Attachments
Activity
My initial analysis of the problem was utterly wrong. Now perhaps I've got a better understending.
1: the issue arise every time the java plugin is invoked whether or not you have resources.
2: it seems to me that the real cause is that the two reported paragraph of code of the java plugin treat pom.build.resources as if it is on object of class org.apache.maven.project.Resource. At now pom.build.resources is a List of Resource, but in effect it used to be a single Resource instance in the class org.apache.maven.project.Build up to version 1.17. In version 1.18 the type of the resources attribute was changed from Resource to List and this broke the jelly code
-------------
<j:choose>
<j:when test="${(!pom.build.resources.includes.isEmpty())}">
<ant:property name="maven.has.jar.resource.patterns" value="true"/>
</j:when>
<j:when test="${!pom.build.resources.excludes.isEmpty()}">
<ant:property name="maven.has.jar.resource.patterns" value="true"/>
</j:when>
<j:otherwise>
<ant:property name="maven.has.jar.resource.patterns" value="false"/>
</j:otherwise>
</j:choose>
<ant:patternset id="maven.jar.resources.set">
<j:forEach var="res" items="${pom.build.resources.includes}">
<ant:include name="${res}"/>
</j:forEach>
<j:forEach var="res" items="${pom.build.resources.excludes}">
<ant:exclude name="${res}"/>
</j:forEach>
</ant:patternset>
-----------------------
3: I couldn't find any place where the property or the pattern set are used (the CopyResources class extracts these information directly from the List of Resource to copy), but you know, the fact that you don't find a thing doesn't mean it doesn't exist.
4: if I'm not wrong the value of the property maven.has.jar.resource.patterns is always false because the two when tests raise an exception. I think that the patternset is always empty because the two forEach statements raise an exception. If this is true they are not very usefull
5: just to do an experiment I deleted the code from the plugin and performed a bootstrap, all worked fine. This can be a solution but may even break the work of sameone that uses these elements in his own plugin.In any case will use maven in this way next week
Conclusion: I think that the original author of the plugin, given the elements I reported, should decide which thing is best.
Hope this help more than the patch I previously attached to this issue. 
There's a lot wrong with this patch.
a) It uses ant:property outside the <choose>
b) It uses !(pom.build.resources != null), which means if the resources are null is the only time it does it.