It's a break in how Jaxen works.

Unless we upgrade all of Jelly to work with the code changes in Jaxen,
the failures will continue.

Personally, I'd rather stick where we are with jaxen in Jelly and stop
Gump from nagging us.

12/2/05, Henri Yandell <flamefew (AT) gmail (DOT) comwrote:
These seem to have been going on for months.

Any chance they can be fixed and stop spamming us?

Hen

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
--

Irritating. :)

The classic one, where if we turn it off we'll never turn it on again,
but fixing the problem is not in the forseeable future.

I'm +1 on turning it off. Maybe stick a note in the root dir of the Jelly svn.

Hen

12/1/05, Dion Gillard <dion.gillard (AT) gmail (DOT) comwrote:
It's a break in how Jaxen works.

Unless we upgrade all of Jelly to work with the code changes in Jaxen,
the failures will continue.

Personally, I'd rather stick where we are with jaxen in Jelly and stop
Gump from nagging us.

12/2/05, Henri Yandell <flamefew (AT) gmail (DOT) comwrote:
These seem to have been going on for months.

Any chance they can be fixed and stop spamming us?

Hen

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
>
>
>
>

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.

12/16/05, Brett Porter <brett (AT) apache (DOT) orgwrote:
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 SNAPSHT
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_HME}/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: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
>
>
>

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
--