On 16 Nov 2006, at 09:40, Sylvain Wallez wrote:
a vote ;-)
IIRC Rhino 1.6 is binary compatible to the version we use in 2.1
Not totally. The exception and stacktrace handling code is a bit
different, but source compatible (see LocationTrackingDebugger).
Loosing the LocationTrackingDebugger
Jeremy Quinn wrote:
On 16 Nov 2006, at 09:40, Sylvain Wallez wrote:
a vote ;-)
IIRC Rhino 1.6 is binary compatible to the version we use in 2.1
Not totally. The exception and stacktrace handling code is a bit
different, but source compatible (see LocationTrackingDebugger).
Loosing the
On 17 Nov 2006, at 23:03, Sylvain Wallez wrote:
Jeremy Quinn wrote:
On 16 Nov 2006, at 09:40, Sylvain Wallez wrote:
a vote ;-)
IIRC Rhino 1.6 is binary compatible to the version we use in 2.1
Not totally. The exception and stacktrace handling code is a bit
different, but source
Carsten Ziegeler wrote:
Nice,
to avoid all legal problems - what would it take to use this version in
2.1.x?
a vote ;-)
IIRC Rhino 1.6 is binary compatible to the version we use in 2.1
I know that this might introduce some incompatibilities, but
perhaps we can live with them?
not sure,
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Nice,
to avoid all legal problems - what would it take to use this version in
2.1.x?
a vote ;-)
Ah, right, thanks :)
IIRC Rhino 1.6 is binary compatible to the version we use in 2.1
Hmm, I'm not sure - I think we had to change some parts in
Carsten Ziegeler wrote:
Yes, and that's exactly the question, if we want go this road. Now if
people are upgrading to 2.2 in the future they have to live with these
changes anyway.
Right, but there is a difference between doing an upgrade from one patch release
to another or to a new minor
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Nice,
to avoid all legal problems - what would it take to use this version in
2.1.x?
a vote ;-)
IIRC Rhino 1.6 is binary compatible to the version we use in 2.1
Not totally. The exception and stacktrace handling code is a bit
different, but
Sylvain Wallez wrote:
AFAIK these features were never explicitely mentioned in our docs, so
not official, and thus certainly not widely used. It may be worth it to
be legally clean at the price of very few compatibility problems.
Yepp, I think being legally clean is more important here.
If
On 11/16/06, Sylvain Wallez [EMAIL PROTECTED] wrote:
...It may be worth it to
be legally clean at the price of very few compatibility problems...
+1
-Bertrand
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
AFAIK these features were never explicitely mentioned in our docs, so
not official, and thus certainly not widely used. It may be worth it to
be legally clean at the price of very few compatibility problems.
Yepp, I think being legally
Nice,
to avoid all legal problems - what would it take to use this version in
2.1.x? I know that this might introduce some incompatibilities, but
perhaps we can live with them?
Carsten
Bertrand Delacretaz wrote:
On 11/5/06, Jeremias Maerki [EMAIL PROTECTED] wrote:
FYI, Cameron McCormack
On 11/5/06, Jeremias Maerki [EMAIL PROTECTED] wrote:
FYI, Cameron McCormack (Batik) has asked the Rhino team about
relicensing Rhino under the MPL:
http://groups-beta.google.com/group/mozilla.dev.tech.js-engine/browse_thread/thread/012b1279e97d1f8a/76511e91e6263eca#dcb9a0e6ee1eaed1
And it has
FYI, Cameron McCormack (Batik) has asked the Rhino team about
relicensing Rhino under the MPL:
http://groups-beta.google.com/group/mozilla.dev.tech.js-engine/browse_thread/thread/012b1279e97d1f8a/76511e91e6263eca#dcb9a0e6ee1eaed1
On 27.10.2006 14:44:52 Jeremias Maerki wrote:
Hi Cocooners
Ralph Goers wrote:
This may not be too big a deal for Cocoon trunk. So long as flowscript
is an optional part of Cocoon I believe we are OK. However, it probably
also means that while other blocks can take advantage of flowscript they
shouldn't rely on it.
I presume that this will put
I don't believe it works like that. My understanding is that as long as
the flowscript block is an optional part of Cocoon then there is no
problem with releasing the flowscript block even if it requires a jar
under the NPL. We just have to provide notice and not include the NPL'd
jar within
I think the resolution also mentioned that we have a one year timeframe
to change this (we should definitly check this). But as already half of
the time past without us doing anything about it, well...
Carsten
Jeremias Maerki wrote:
Ok, but you guys still need to fix:
Hi Cocooners
Before I start: Sorry to be a PITA to bring up Rhino again. ;-)
Batik is starting to plan a new release and Rhino popped up in the back
of my mind. I went looking in your codebase to see what you did with
Rhino since I last checked. Turns out that Cocoon still lists Rhino as
under
This may not be too big a deal for Cocoon trunk. So long as flowscript
is an optional part of Cocoon I believe we are OK. However, it probably
also means that while other blocks can take advantage of flowscript they
shouldn't rely on it.
Jeremias Maerki wrote:
Hi Cocooners
Before I start:
Ok, but you guys still need to fix:
http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/legal/rhino1.5r4-continuations-R26.jar.license.txt
and
http://svn.apache.org/repos/asf/cocoon/trunk/commons/legal/src/main/resources/rhino-1.6R2.jar.license.txt
And does the user get an notification
19 matches
Mail list logo
