Jexl has changed from 1.0. It used to provide all numbers as a Long, regardless of size.
Since 1.0 to allow methods that take bytes, shorts etc to be invoked easier, the results are narrowed to a smaller type. This probably will need some investigation, as the change in JEXL may have broken compatibility accidentally. On 12/16/05, Brett Porter <[EMAIL PROTECTED]> wrote: > That totally surprises me, because I didn't think Jexl had changed since > 1.0. > > Dion is the only person I'm aware of here that has looked at that code. > Dion? > > - Brett > > Paul Libbrecht wrote: > > well, that was correct... it was just a matter of trying and guessing > > which was the faulty one... > > > > Change the current parent-project.xml at Jexl from 1.0 to SNAPSHOT... > > and you get a very similar error report as gump does. > > > > Change the current parent-project.xml at everything latest (except > > Xerces) but keep jexl 1.0... and you get a successful build. > > > > Can someone jexl aware investigate issues there ? Maybe I'll give it > > some cycles next week but not earlier. > > > > That should be pretty easy. > > > > thanks > > > > paul > > > > Brett Porter wrote: > >> It doesn't matter what Maven installation you use, I don't think, though > >> IIRC Gump still uses 1.0.2 if that helps. > >> > >> I believe the failure is commons-jelly-tags-xml, not commons-jelly. > >> > >> Remember, gump uses the latest of everything, so you need to build the > >> latests Jelly library snapshot and update the dependency of the tags to > >> use that too. > >> > >> maven -X will reveal what libraries are actually in use. > >> > >> - Brett > >> > >> Paul Libbrecht wrote: > >> > >>> I'm trying hard to fail and fail to fail... > >>> As I understand it would be enough to change > >>> ${JELLY_HOME}/parent-project.xml to refer jaxen 1.1-beta-6, 1.1-beta-8 > >>> or 1.1-beta-5... but "maven clean jar" still succeeds with me. > >>> > >>> Can it be this is related to the maven classpath ?? > >>> Am I understanding something wrong of Gump or this should not be set > >>> and > >>> maven should proceeding using its own classpath ?? (in my > >>> maven-1.1-beta-2, this is only forehead.jar which itself builds other > >>> classloaders based on maven-home). > >>> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- http://www.multitask.com.au/people/dion/ "You are going to let the fear of poverty govern your life and your reward will be that you will eat, but you will not live." - George Bernard Shaw --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]