On 06/21/2011 03:54 PM, Jasha Joachimsthal wrote:
Ate,
The order did matter but it took me some time to find out why. After
debugging the Maven build I was still puzzled why it would not compile. The
only difference was the order in which commons-lang appeared on the
classpath. Then I opened the openjpa-all jar and found a lot of classes from
Apache commons projects, including commons-lang and that explains why it
took the older version of StringUtils when openjpa-all was decalred before
commons-lang. So apparently we shouldn't be using the openjpa-all jar but
openjpa jar.
Arggggh.
So this isn't a maven dependency management issue at all :)
Its called classloading hell!
+1 for replacing openjpa-all
(I never like those everything-and-the kitchen-sink jar solutions, even if they
are very convenient for (too) simple use-cases)
I will create and submit a new patch.
Cool, thanks!
Jasha Joachimsthal
Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522 4466
US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll free)
www.onehippo.com
On 21 June 2011 14:52, Ate Douma<[email protected]> wrote:
Jasha, I find this issue weird.
I just checked with mvn dependency:tree and (without your patch) see
commons-lang-2.6 being included, as I would expect. We have commons-lang
explicitly specified, as well as its version (2.6) configured in the
dependency-management (rave-project). That should always ensure version 2.6
is selected as its a direct/explicit dependency, no matter what transitively
derived version would be needed for openjpa (or any other).
Can you please check (without your patch) what outcome you have with mvn
dependency:tree?
If in your case maven hides the 2.6 version it should say so. Please send
you output then to the list (or on the issue) because then something else
must be wrong.
At any rate, depending on "order of definition" within a pom isn't a
reliable and good enough solution IMO.
Regards,
Ate
On 06/21/2011 02:35 PM, Jasha Joachimsthal (JIRA) wrote:
[ https://issues.apache.org/**jira/browse/RAVE-81?page=com.**
atlassian.jira.plugin.system.**issuetabpanels:all-tabpanel<https://issues.apache.org/jira/browse/RAVE-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel>]
Jasha Joachimsthal updated RAVE-81:
------------------------------**-----
Attachment: RAVE-81_fix_order_in_which_**commons-lang_is_loaded.patch
The order in which the artifacts are defined in the pom influences the
version during compile time. Moving commons-lang above openjpa-all does the
trick.
Fix classloading issue for StringUtils in ModelUtilsTest
------------------------------**--------------------------
Key: RAVE-81
URL:
https://issues.apache.org/**jira/browse/RAVE-81<https://issues.apache.org/jira/browse/RAVE-81>
Project: Rave
Issue Type: Sub-task
Affects Versions: 0.1-INCUBATING
Reporter: Jasha Joachimsthal
Assignee: Jasha Joachimsthal
Priority: Minor
Fix For: 0.2-INCUBATING
Attachments: RAVE-81_fix_order_in_which_**
commons-lang_is_loaded.patch
ModelUtilsTest contains a isAllLowercase which was introduced in
commons-lang 2.5
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/**
software/jira<http://www.atlassian.com/software/jira>
