On 21 June 2011 16:02, Ate Douma <[email protected]> wrote: > 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! >
Interesting, I named this issue "Fix classloading issue" but still blamed Maven. I should have had a clue... > > +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) Maybe handy for people stuck in Ant without Ivy, but useless for Maven ;) > I will create and submit a new patch. >> > Cool, thanks! > > Done. I cannot delete previous patches, that's why there are 2 now. Jasha > >> 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.****<https://issues.apache.org/**jira/browse/RAVE-81?page=com.**> >>>> atlassian.jira.plugin.system.****issuetabpanels:all-tabpanel<h** >>>> ttps://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> >>>>> <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<http://www.atlassian.com/software/jira> >>>> > >>>> >>>> >>>> >>>> >>> >> >
