Maven 1

update commons-lang dependency

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Trivial Trivial
  • Resolution: Fixed
  • Affects Version/s: 1.0-rc2
  • Fix Version/s: 1.0-rc2
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

actually maven dependencies include commons-lang 1.0-b1.1.

It would be better to update it to commons-lang 2.0: the new release is totally compatible with the old (no methods have been removed) and this will allows to use new useful string utils method in plugin (replace, trim, ...).

Actually also if you include a commons-lang 2.0 dependency in a plugin it seems you are not able to call commons-lang 2.0 methods from jelly, since it always find the old commons-lang 1.0 classes in maven classloader first (unless specifing a root classloader in dependency).

Change: modify in project.xml
<dependency>
<id>commons-lang</id>
<version>1.0-b1.1</version>
<url>http://jakarta.apache.org/commons/</url>
</dependency>

with:

<dependency>
<artifactId>commons-lang</artifactId>
<groupId>commons-lang</groupId>
<version>2.0</version>
<url>http://jakarta.apache.org/commons/</url>
</dependency>

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Brett Porter added a comment -

I think we can actually remove the dependency, which should free it up some. The only problem is that some people who rely on it being there may need to add a dependency to their project... I'll take a look

Show
Brett Porter added a comment - I think we can actually remove the dependency, which should free it up some. The only problem is that some people who rely on it being there may need to add a dependency to their project... I'll take a look
Hide
Permalink
Joakim Erdfelt added a comment -

I have found a trick that allows us 1.0-RC1 users to get around the issues with regards to the commons-lang dependency in the maven core and/or other plugins.

I use the following inside of my plugins and/or projects to get the benefits of commons-lang-2.0.jar in my builds, plugin.jelly, and maven.xml.

<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<version>2.0</version>
<properties>
<war.bundle>true</war.bundle>
<webveer.lib>true</webveer.lib>
<!-- this is done to avoid a conflict with
commons-lang-1.0.1.jar from the higher
level plugins. -->
<classloader>root.maven</classloader>
</properties>
</dependency>

NOTE: If the switch is made to commons-lang-2.0 then you get the benefit of other objects such as StringEscapeUtils.

http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/StringEscapeUtils.html

This unified xml/html/java/javascript escaping object would make resolving of some xdoc bugs ( MPXDOC-82 / MPXDOC-66 / MPXDOC-82 / MPXDOC-27 / MPXDOC-11 / MPXDOC-17 ) easier.

Show
Joakim Erdfelt added a comment - I have found a trick that allows us 1.0-RC1 users to get around the issues with regards to the commons-lang dependency in the maven core and/or other plugins. I use the following inside of my plugins and/or projects to get the benefits of commons-lang-2.0.jar in my builds, plugin.jelly, and maven.xml. <dependency> <groupId>commons-lang</groupId> <artifactId>commons-lang</artifactId> <version>2.0</version> <properties> <war.bundle>true</war.bundle> <webveer.lib>true</webveer.lib> <!-- this is done to avoid a conflict with commons-lang-1.0.1.jar from the higher level plugins. --> <classloader>root.maven</classloader> </properties> </dependency> NOTE: If the switch is made to commons-lang-2.0 then you get the benefit of other objects such as StringEscapeUtils. http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/StringEscapeUtils.html This unified xml/html/java/javascript escaping object would make resolving of some xdoc bugs ( MPXDOC-82 / MPXDOC-66 / MPXDOC-82 / MPXDOC-27 / MPXDOC-11 / MPXDOC-17 ) easier.
Hide
Permalink
fabrizio giustina added a comment -

In my tests setting classloader to root doesn't completely solve the problem.

At least if used in jelly (using the invoke or invokeStatic tag) the reference returned is to maven commons-lang 1.0 classes. You are able to use commons-lang classes new in 2.0 but not methods added in classes already available in 1.0 (so all the new StringUtils methods).

Please remove or update old maven dependency!

Show
fabrizio giustina added a comment - In my tests setting classloader to root doesn't completely solve the problem. At least if used in jelly (using the invoke or invokeStatic tag) the reference returned is to maven commons-lang 1.0 classes. You are able to use commons-lang classes new in 2.0 but not methods added in classes already available in 1.0 (so all the new StringUtils methods). Please remove or update old maven dependency!
Hide
Permalink
Joerg Schaible added a comment -

Well, I thionk it will be not that easy to upgrade to new lang-2.0, since Jelly is broken with this version (and I did not see any effort in Jelly to solve the problems).

http://nagoya.apache.org/jira/secure/ViewIssue.jspa?key=JELLY-98

Show
Joerg Schaible added a comment - Well, I thionk it will be not that easy to upgrade to new lang-2.0, since Jelly is broken with this version (and I did not see any effort in Jelly to solve the problems). http://nagoya.apache.org/jira/secure/ViewIssue.jspa?key=JELLY-98
Hide
Permalink
fabrizio giustina added a comment -

I'm actually using a "customized" maven with a commons-lang 2.0 dependency and after many weeks everything works well, I couldn't see any error.
Testen on at least 5 mavenized project, with pratically all the report plugins, junit, cactus, clover, war, etc.

Should check what is broken in jelly with commons-lang 2.0, I'm not sure this will affect maven.

Show
fabrizio giustina added a comment - I'm actually using a "customized" maven with a commons-lang 2.0 dependency and after many weeks everything works well, I couldn't see any error. Testen on at least 5 mavenized project, with pratically all the report plugins, junit, cactus, clover, war, etc. Should check what is broken in jelly with commons-lang 2.0, I'm not sure this will affect maven.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:

Time Tracking

Estimated:
5m
Original Estimate - 5 minutes
Remaining:
5m
Remaining Estimate - 5 minutes
Logged:
Not Specified
Time Spent - Not Specified
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.