Thanks a lot Seb!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/
On Sun, Sep 12, 2010 at 2:55 PM, sebb <seb...@gmail.com> wrote: > On 12 September 2010 13:37, Simone Tripodi <simone.trip...@gmail.com> wrote: >> OK, I understand now that before I didn't understand why the Digester >> build fails. That's driving me crazy :( > > I made a change which might help. Let's see what happens. > > Note that these failures don't necessarily mean that there is a > problem with Digester. > Given that it builds OK for you and when using Continuum [1], I think > we can work on fixing Gump separately from any release. > > [1] > http://vmbuild.apache.org/continuum/buildResults.action?projectId=75&projectGroupId=16 > >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> >> >> On Sun, Sep 12, 2010 at 2:31 PM, sebb <seb...@gmail.com> wrote: >>> On 12 September 2010 13:22, Simone Tripodi <simone.trip...@gmail.com> wrote: >>>> OK thanks both guys, now I understand why the Digester build fails. >>> >>> I'm glad you understand, because I don't. >>> >>> As far as I can tell Digester should build OK, given that it depends >>> on BeanUtils which builds OK. >>> >>> Note: the current BeanUtils trunk imports >>> org.apache.commons.collections.FastHashMap, so for that to build it >>> must be able to find the class. >>> >>> So why does Digester fail during tests? >>> >>> It may be a subtle Gump problem. >>> >>>> BTW I'd update the beanutils dependency to beanutils-core if there are >>>> no objections, WDYT? >>> >>> No other projects depend on beanutils-core, so I don't think that's a good >>> idea. >>> >>>> Thanks in advance! >>>> Simo >>>> >>>> http://people.apache.org/~simonetripodi/ >>>> http://www.99soft.org/ >>>> >>>> >>>> >>>> On Sun, Sep 12, 2010 at 2:12 PM, sebb <seb...@gmail.com> wrote: >>>>> On 12 September 2010 13:07, James Carman <ja...@carmanconsulting.com> >>>>> wrote: >>>>>> From what I understand, Gump tries to make sure that our "trunks" stay >>>>>> in synch, so it's not honoring the specific BeanUtils dependency, but >>>>>> instead running the build against BeanUtils' trunk. Please correct me >>>>>> if I'm wrong someone. I've never really understood Gump very well. :) >>>>> >>>>> That is what Gump tries to do. >>>>> >>>>>> Perhaps merely adding a dependency to commons collections would fix >>>>>> your Gump issue? >>>>> >>>>> The Gump build already depends on Collections, and it is shown in the >>>>> classpath. >>>>> >>>>> I don't understand why the missing class is in BeanUtils according to >>>>> the stacktrace, yet BeanUtils appears to build OK. >>>>> >>>>> I've asked for some help on the Gump list. >>>>> >>>>>> On Sun, Sep 12, 2010 at 8:00 AM, Simone Tripodi >>>>>> <simone.trip...@gmail.com> wrote: >>>>>>> Hi James, Seb, >>>>>>> thanks for your feedbacks and your help!!! What is going to drive me >>>>>>> crazy is that the latest released digester is successfully using the >>>>>>> 1.8.0 release of BeanUtils; the current digester trunk is using the >>>>>>> 1.8.3, (with some memory leaks fixes) and doesn't cause errors >>>>>>> locally; even testing with only commons-beanutils-core-1.8.3 (a subset >>>>>>> of the whole beanutils package) it continues working. >>>>>>> >>>>>>> Follow below some bash executions on my machine... that's why I don't >>>>>>> understand why it should fail on Gump :( >>>>>>> All te best, >>>>>>> Simo >>>>>>> >>>>>>> commons-digester simone$ java -version >>>>>>> java version "1.5.0_24" >>>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>>>>> 1.5.0_24-b02-357-10M3065) >>>>>>> Java HotSpot(TM) Client VM (build 1.5.0_24-149, mixed mode, sharing) >>>>>>> >>>>>>> commons-digester simone$ mvn -version >>>>>>> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) >>>>>>> Java version: 1.5.0_24 >>>>>>> Java home: /XXXXX/JavaVM.framework/Versions/1.5.0/Home >>>>>>> Default locale: en_US, platform encoding: MacRoman >>>>>>> OS name: "mac os x" version: "10.6.4" arch: "i386" Family: "unix" >>>>>>> >>>>>>> commons-digester simone$ mvn clean test >>>>>>> [...] >>>>>>> Tests run: 174, Failures: 0, Errors: 0, Skipped: 0 >>>>>>> >>>>>>> [INFO] >>>>>>> ------------------------------------------------------------------------ >>>>>>> [INFO] BUILD SUCCESSFUL >>>>>>> [INFO] >>>>>>> ------------------------------------------------------------------------ >>>>>>> [INFO] Total time: 8 seconds >>>>>>> [INFO] Finished at: Sun Sep 12 13:45:28 CEST 2010 >>>>>>> [INFO] Final Memory: 27M/508M >>>>>>> [INFO] >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> http://people.apache.org/~simonetripodi/ >>>>>>> http://www.99soft.org/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sun, Sep 12, 2010 at 1:44 PM, James Carman >>>>>>> <ja...@carmanconsulting.com> wrote: >>>>>>>> On Sun, Sep 12, 2010 at 7:39 AM, sebb <seb...@gmail.com> wrote: >>>>>>>>> >>>>>>>>> On further investigation, it is collections/trunk - i.e. collections4 >>>>>>>>> - which does not have FastHashMap. >>>>>>>>> >>>>>>>>> The default Collections version used by Gump is based on >>>>>>>>> tags/PRE_GENERICS_MERGE which does have FastHashMap, so there is a >>>>>>>>> different problem. >>>>>>>>> >>>>>>>>> I'll look further. >>>>>>>> >>>>>>>> The BeanUtils folks recently decided to remove the collections classes >>>>>>>> from their jar(s) in favor of an optional dependency I believe. >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
