You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Stefan Bodewig <bo...@apache.org> on 2006/02/18 12:42:45 UTC
Upgraded vmgump to JDK 1.5
Hi all,
I went ahead and installed JDK 1.5 and made Gump use it. If it should
turn out to create worse results than we have right now, it is just a
matter of changing a single file to turn it back.
While I was at it (actually waiting for my upload of 47 MB of JDK to
finish) I also upgraded Mono to 1.1.13.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Upgraded vmgump to JDK 1.5
Posted by Bill Barker <wb...@wilshire.com>.
"Leo Simons" <ma...@leosimons.com> wrote in message
news:20060219105358.GA34686@bali.sjc.webweaving.org...
> On Sun, Feb 19, 2006 at 10:37:37AM +0100, Stefan Bodewig wrote:
>> On Sat, 18 Feb 2006, Leo Simons <ma...@leosimons.com> wrote:
>>
>> > This is to "solve" the junit stuff right?
>>
>> JUnit is the most prominent project to require Java 5 ATM, but hardly
>> the only one. We've had other projects breaking for months now
>> because we didn't provide a Java 5 environment.
>
> Oh. Do you have a (partial) list (in your head or elsewhere)? Are these
> projects "leaf" projects or "core" projects?
>
I believe that mina was the only one with a significant number of dependant
projects (and, it still won't build since it now requires Maven2 :).
JacORB, jdbm were also on the list. I think that their were about 4 or 5
others, but I don't remember them off the top of my head.
>> > I'm personally not happy with how effectively there's this one
>> > project run by a bunch of people who don't particulary understand
>> > enough about backwards compatibility
>>
>> I don't think you are fair here. JUnit 4 uses a completely different
>> approach that has been enabled by annotations. I'm a happy NUnit user
>> (.NET unit testing framework) and can tell you that using annotations
>> really is a step forward over the JUnit 3.x approach.
>
> Right. The other big one is the template collections (whatever its called,
> the <Foo>List stuff). I understand how cool and useful it is. I agree I
> wasn't fair, sorry.
>
> However, JUnit is one of the "corest of core" projects, much like Xerces
> and/or Ant. The ant project is an example of a project which is very
> aware of its role like that. Log4j is one where its lead to friction in
> the past but where gump in the end was used as a tool to have a net
> positive effect on e.g. migration strategies and backward compatibility
> and the like.
>
> I feel that gump is failing in that role with this jdk 1.4 -> 1.5 stuff,
> and failing in a big way, and I find it frustrating that we're not able as
> a team to contribute a whole lot to easing this kind of thing and this
> kind
> of mess.
>
> Its my perception that the people working on JUnit 4 have decided to take
> a "bite the bullet" (or the "sour apple") approach to this migration, and
> I think this is wrong, and I know there is no way I can help here or
> change
> it and I probably shouldn't try (well, of course I could go and try and
> change
> the java landscape by contributing to having open source and "open" style
> change management processes for the JDK...hey...ehm...), and I'm sorry for
> mentioning "people" instead of "project" and casting it as a "personal"
> thing. The big picture is just so ugly.
>
>> And when it comes to backwards compatibility, it is very likely that
>> all our JUnit 3.8 tests in Gump will work with JUnit 4 as well. It's
>> simply that JUnit wants to use annotations and the only way forward
>> was to require Java 5 at compile time.
>
> Yeah I know.
>
> LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Upgraded vmgump to JDK 1.5
Posted by Stefan Bodewig <bo...@apache.org>.
On Sun, 19 Feb 2006, Leo Simons <ma...@leosimons.com> wrote:
> On Sun, Feb 19, 2006 at 10:37:37AM +0100, Stefan Bodewig wrote:
>> On Sat, 18 Feb 2006, Leo Simons <ma...@leosimons.com> wrote:
>>
>> > This is to "solve" the junit stuff right?
>>
>> JUnit is the most prominent project to require Java 5 ATM, but
>> hardly the only one. We've had other projects breaking for months
>> now because we didn't provide a Java 5 environment.
>
> Oh. Do you have a (partial) list (in your head or elsewhere)? Are
> these projects "leaf" projects or "core" projects?
Leaf. Some of the smartfrog things, myfaces and at least one other
that I forget right now.
Bill might know, but as he already said, myfaces needs Maven2 now, so
we won't be able to build it anyway.
> The other big one is the template collections (whatever its called,
> the <Foo>List stuff).
Generics.
> The ant project is an example of a project which is very aware of
> its role like that.
It won't compile on JDK 1.1 any longer 8-)
> I feel that gump is failing in that role with this jdk 1.4 -> 1.5
> stuff, and failing in a big way, and I find it frustrating that
> we're not able as a team to contribute a whole lot to easing this
> kind of thing and this kind of mess.
I've read somewhere that Sun was challenging people to find backwards
incompatibilities in Mustang. Maybe we should start building with a
1.6 snapshot.
> Its my perception that the people working on JUnit 4 have decided to
> take a "bite the bullet" (or the "sour apple") approach to this
> migration, and I think this is wrong,
They've decided to require JDK 1.5 at compile time. I think JUnit
still doesn't require it at runtime if you use the JUnit 3 style of
tests.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Upgraded vmgump to JDK 1.5
Posted by Leo Simons <ma...@leosimons.com>.
On Sun, Feb 19, 2006 at 10:37:37AM +0100, Stefan Bodewig wrote:
> On Sat, 18 Feb 2006, Leo Simons <ma...@leosimons.com> wrote:
>
> > This is to "solve" the junit stuff right?
>
> JUnit is the most prominent project to require Java 5 ATM, but hardly
> the only one. We've had other projects breaking for months now
> because we didn't provide a Java 5 environment.
Oh. Do you have a (partial) list (in your head or elsewhere)? Are these
projects "leaf" projects or "core" projects?
> > I'm personally not happy with how effectively there's this one
> > project run by a bunch of people who don't particulary understand
> > enough about backwards compatibility
>
> I don't think you are fair here. JUnit 4 uses a completely different
> approach that has been enabled by annotations. I'm a happy NUnit user
> (.NET unit testing framework) and can tell you that using annotations
> really is a step forward over the JUnit 3.x approach.
Right. The other big one is the template collections (whatever its called,
the <Foo>List stuff). I understand how cool and useful it is. I agree I
wasn't fair, sorry.
However, JUnit is one of the "corest of core" projects, much like Xerces
and/or Ant. The ant project is an example of a project which is very
aware of its role like that. Log4j is one where its lead to friction in
the past but where gump in the end was used as a tool to have a net
positive effect on e.g. migration strategies and backward compatibility
and the like.
I feel that gump is failing in that role with this jdk 1.4 -> 1.5 stuff,
and failing in a big way, and I find it frustrating that we're not able as
a team to contribute a whole lot to easing this kind of thing and this kind
of mess.
Its my perception that the people working on JUnit 4 have decided to take
a "bite the bullet" (or the "sour apple") approach to this migration, and
I think this is wrong, and I know there is no way I can help here or change
it and I probably shouldn't try (well, of course I could go and try and change
the java landscape by contributing to having open source and "open" style
change management processes for the JDK...hey...ehm...), and I'm sorry for
mentioning "people" instead of "project" and casting it as a "personal"
thing. The big picture is just so ugly.
> And when it comes to backwards compatibility, it is very likely that
> all our JUnit 3.8 tests in Gump will work with JUnit 4 as well. It's
> simply that JUnit wants to use annotations and the only way forward
> was to require Java 5 at compile time.
Yeah I know.
LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Upgraded vmgump to JDK 1.5
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 19.02.2006 11:08:22 Stefan Bodewig wrote:
<snip/>
> > Maybe adding a jdk compatibility mode could be interesting to use /
> > add (didn't look if this is working though) ?
>
> Well, derby would benefit from something like that as well (it needs a
> mixed JDK 1.3/1.4 environment).
Batik/FOP could also profit here. We still have to be compatible with 1.3.1
although most people work on >=1.4. Gump could help a lot in early
detection of mistakes.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Upgraded vmgump to JDK 1.5
Posted by Brett Porter <br...@gmail.com>.
Could have sworn I double checked :)
Thanks,
Brett
On 2/20/06, Martin van den Bemt <ml...@mvdb.net> wrote:
> The enum is just generating warnings.. (I missed that at first too btw)..
> Just the unicode stuff is generating compile errors..
>
> Mvgr,
> Martin
>
> Brett Porter wrote:
> > On 2/19/06, Stefan Bodewig <bo...@apache.org> wrote:
> >
> >>On Sun, 19 Feb 2006, Martin van den Bemt <ml...@mvdb.net> wrote:
> >>
> >>
> >>>It seems we traded junit for commons-lang..
> >>
> >>It is trivial to fix in commons-lang.
> >
> >
> > I thought about doing it, but it seems that the package of the classes
> > is ".enum". That'd mean breaking backwards compat to fix it. Not so
> > trivial :(
> >
> > - Brett
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> > For additional commands, e-mail: general-help@gump.apache.org
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Upgraded vmgump to JDK 1.5
Posted by Martin van den Bemt <ml...@mvdb.net>.
The enum is just generating warnings.. (I missed that at first too btw)..
Just the unicode stuff is generating compile errors..
Mvgr,
Martin
Brett Porter wrote:
> On 2/19/06, Stefan Bodewig <bo...@apache.org> wrote:
>
>>On Sun, 19 Feb 2006, Martin van den Bemt <ml...@mvdb.net> wrote:
>>
>>
>>>It seems we traded junit for commons-lang..
>>
>>It is trivial to fix in commons-lang.
>
>
> I thought about doing it, but it seems that the package of the classes
> is ".enum". That'd mean breaking backwards compat to fix it. Not so
> trivial :(
>
> - Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Upgraded vmgump to JDK 1.5
Posted by Brett Porter <br...@gmail.com>.
On 2/19/06, Stefan Bodewig <bo...@apache.org> wrote:
> On Sun, 19 Feb 2006, Martin van den Bemt <ml...@mvdb.net> wrote:
>
> > It seems we traded junit for commons-lang..
>
> It is trivial to fix in commons-lang.
I thought about doing it, but it seems that the package of the classes
is ".enum". That'd mean breaking backwards compat to fix it. Not so
trivial :(
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Upgraded vmgump to JDK 1.5
Posted by Stefan Bodewig <bo...@apache.org>.
On Sun, 19 Feb 2006, Martin van den Bemt <ml...@mvdb.net> wrote:
> It seems we traded junit for commons-lang..
It is trivial to fix in commons-lang.
> Maybe adding a jdk compatibility mode could be interesting to use /
> add (didn't look if this is working though) ?
Well, derby would benefit from something like that as well (it needs a
mixed JDK 1.3/1.4 environment).
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Upgraded vmgump to JDK 1.5
Posted by Martin van den Bemt <ml...@mvdb.net>.
It seems we traded junit for commons-lang..
Maybe adding a jdk compatibility mode could be interesting to use / add (didn't look if this is
working though) ?
Mvgr,
Martin
Stefan Bodewig wrote:
> On Sat, 18 Feb 2006, Leo Simons <ma...@leosimons.com> wrote:
>
>
>>This is to "solve" the junit stuff right?
>
>
> JUnit is the most prominent project to require Java 5 ATM, but hardly
> the only one. We've had other projects breaking for months now
> because we didn't provide a Java 5 environment.
>
>
>>I'm personally not happy with how effectively there's this one
>>project run by a bunch of people who don't particulary understand
>>enough about backwards compatibility
>
>
> I don't think you are fair here. JUnit 4 uses a completely different
> approach that has been enabled by annotations. I'm a happy NUnit user
> (.NET unit testing framework) and can tell you that using annotations
> really is a step forward over the JUnit 3.x approach.
>
> And when it comes to backwards compatibility, it is very likely that
> all our JUnit 3.8 tests in Gump will work with JUnit 4 as well. It's
> simply that JUnit wants to use annotations and the only way forward
> was to require Java 5 at compile time.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Upgraded vmgump to JDK 1.5
Posted by Stefan Bodewig <bo...@apache.org>.
On Sat, 18 Feb 2006, Leo Simons <ma...@leosimons.com> wrote:
> This is to "solve" the junit stuff right?
JUnit is the most prominent project to require Java 5 ATM, but hardly
the only one. We've had other projects breaking for months now
because we didn't provide a Java 5 environment.
> I'm personally not happy with how effectively there's this one
> project run by a bunch of people who don't particulary understand
> enough about backwards compatibility
I don't think you are fair here. JUnit 4 uses a completely different
approach that has been enabled by annotations. I'm a happy NUnit user
(.NET unit testing framework) and can tell you that using annotations
really is a step forward over the JUnit 3.x approach.
And when it comes to backwards compatibility, it is very likely that
all our JUnit 3.8 tests in Gump will work with JUnit 4 as well. It's
simply that JUnit wants to use annotations and the only way forward
was to require Java 5 at compile time.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Is Gump the obsticle?
Posted by Leo Simons <ma...@leosimons.com>.
On Sun, Feb 19, 2006 at 03:32:28PM +1030, Steve wrote:
> Incompatible version changes arise from:
>
> (a) development errors
>
> (b) planned version change typically flagged
> by a major version identifier increment
>
> The first is something we want to trap while the second is something managed
> and intentional. Gump does a good job of identifying and reporting errors
> related to (a) but it is weak with respect to supporting managed change
> arising from (b).
Agreed. I think in general most of the software landscape is not so good at
this and most developers don't spend as much effort on it as would be a Good
Thing(tm) (probably because it isn't exactly easy).
>
> > It might be a nice feature to be able to create a
> > packaged-foobar just from the metadata, without having to get
> > Stefen involved with downloading the jars himself. Maybe
> > something for Gump 3.
>
> Yep - good suggestion!
Heh. I would love to get back to working on this. Python is *so* much more
fun than java!
I wonder though whether the "true" place to work on this isn't "further down
the stack" (like in ant, make, scons, maven, ...). Gump is very focussed (or
the way we use it at least) on "latest of everything" and this focus helps
keep things somewhat understable (or so we hope). Its a useful focus. I'm
afraid of changing it (e.g. I think Stefan did the right thing by switching
to 1.5, we focus on whatever makes us build the largest part of the tree).
LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Is Gump the obsticle?
Posted by Stefan Bodewig <bo...@apache.org>.
On Sun, 19 Feb 2006, Steve <mc...@apache.org> wrote:
> Incompatible version changes arise from:
>
> (a) development errors
>
> (b) planned version change typically flagged
> by a major version identifier increment
>
> The first is something we want to trap
Yep.
> while the second is something managed and intentional.
Exactly. And we deal with it the way Bill described. We build dom4j
HEAD separately from the branch that most projects depend on, we've
built different branches of commons-httpclient, for example.
I fully agree that sometimes there may be a good reason to break
backwards compatibility. And Gump should certainly be able to deal
with it (and in most cases it is).
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
RE: Is Gump the obsticle?
Posted by Steve <mc...@apache.org>.
> -----Original Message-----
> From: Bill Barker
> Actually, the reason Gump came into being is because of
> incompatible version changes :). What it does is let other
> projects know that this is happening early enough that they
> can plan how they want to deal with it. A fair number of
> times, it's to switch from project foobar to project
> packaged-foobar, and deal with it later. But at least it's
> on their radar now :).
Incompatible version changes arise from:
(a) development errors
(b) planned version change typically flagged
by a major version identifier increment
The first is something we want to trap while the second is something managed
and intentional. Gump does a good job of identifying and reporting errors
related to (a) but it is weak with respect to supporting managed change
arising from (b).
> It might be a nice feature to be able to create a
> packaged-foobar just from the metadata, without having to get
> Stefen involved with downloading the jars himself. Maybe
> something for Gump 3.
Yep - good suggestion!
Cheers, Steve.
--------------------------
Stephen McConnell
mailto:mcconnell@dpml.net
http://www.dpml.net
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Is Gump the obsticle?
Posted by Bill Barker <wb...@wilshire.com>.
"Steve" <mc...@apache.org> wrote in message
news:000901c634ae$ed4231d0$0201a8c0@julia...
>
>
>> -----Original Message-----
>> From: Steve [mailto:mcconnell@apache.org]
>> Sent: Sunday, 19 February 2006 3:32 AM
>> To: 'Gump code and data'
>> Subject: RE: Upgraded vmgump to JDK 1.5
>>
>>
>>
>> > -----Original Message-----
>> > From: Leo Simons [mailto:mail@leosimons.com]
>> > Sent: Sunday, 19 February 2006 2:46 AM
>> > To: Gump code and data
>> > Subject: Re: Upgraded vmgump to JDK 1.5
>> >
>> > This is to "solve" the junit stuff right?
>> >
>> > Will be interesting...I'm personally not happy with how effectively
>> > there's this one project run by a bunch of people who don't
>> > particulary understand enough about backwards compatibility and the
>> > like (just like Sun really) which force this kind of thing.
>>
>> It's not like 'that bunch of people' are taking away 3.8.1!
>> Products evolve and there is a well established convention
>> concerning major version increments. The JUnit team are
>> working of 4.X - and that means they are working on a new
>> product that is not compatible with the 3.X line.
>>
>> This is a trend commonly referred to as "progress".
>>
>> > The stupidness is that this is in part a limitation that gump has.
>>
>> Yes - which is the relevant subject for this list.
>> Subscribers should not be moaning about the fact that an
>> independent project is going the next step and building an
>> even better testing framework - instead, subscribers should
>> be looking at why this is an issue for Gump.
>
> IMO - the issue is that Gump project descriptors do not include a
> definition
> a major version identifier and the underlying support that this implies
> within respect to dependent builds (i.e. group/name is not sufficient).
> The
> absence of this creates a scenario where the assumption is that
> incompatible
> version changes are not recognized as a technical reality.
>
Actually, the reason Gump came into being is because of incompatible version
changes :). What it does is let other projects know that this is happening
early enough that they can plan how they want to deal with it. A fair
number of times, it's to switch from project foobar to project
packaged-foobar, and deal with it later. But at least it's on their radar
now :).
It might be a nice feature to be able to create a packaged-foobar just from
the metadata, without having to get Stefen involved with downloading the
jars himself. Maybe something for Gump 3.
> This in-turn creates an inconsistency between:
>
> (a) the role of Gump as a technical community integrity checker
> (b) the decisions of a particular project/group concerning product
> evolution
>
> My suggestion would be to consider every Gump project as an implicit
> version
> 0 and enable an explicit major version identifier. From this consumer
> projects would be able to lock onto the assumed major version without fear
> of disruption from source project major-version evolution.
>
You can do that now: Just create a foobar-v1.xml that builds off a branch
instead of HEAD, and depend on that.
> Cheers, Steve.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Is Gump the obsticle?
Posted by Steve <mc...@apache.org>.
> -----Original Message-----
> From: Steve [mailto:mcconnell@apache.org]
> Sent: Sunday, 19 February 2006 3:32 AM
> To: 'Gump code and data'
> Subject: RE: Upgraded vmgump to JDK 1.5
>
>
>
> > -----Original Message-----
> > From: Leo Simons [mailto:mail@leosimons.com]
> > Sent: Sunday, 19 February 2006 2:46 AM
> > To: Gump code and data
> > Subject: Re: Upgraded vmgump to JDK 1.5
> >
> > This is to "solve" the junit stuff right?
> >
> > Will be interesting...I'm personally not happy with how effectively
> > there's this one project run by a bunch of people who don't
> > particulary understand enough about backwards compatibility and the
> > like (just like Sun really) which force this kind of thing.
>
> It's not like 'that bunch of people' are taking away 3.8.1!
> Products evolve and there is a well established convention
> concerning major version increments. The JUnit team are
> working of 4.X - and that means they are working on a new
> product that is not compatible with the 3.X line.
>
> This is a trend commonly referred to as "progress".
>
> > The stupidness is that this is in part a limitation that gump has.
>
> Yes - which is the relevant subject for this list.
> Subscribers should not be moaning about the fact that an
> independent project is going the next step and building an
> even better testing framework - instead, subscribers should
> be looking at why this is an issue for Gump.
IMO - the issue is that Gump project descriptors do not include a definition
a major version identifier and the underlying support that this implies
within respect to dependent builds (i.e. group/name is not sufficient). The
absence of this creates a scenario where the assumption is that incompatible
version changes are not recognized as a technical reality.
This in-turn creates an inconsistency between:
(a) the role of Gump as a technical community integrity checker
(b) the decisions of a particular project/group concerning product
evolution
My suggestion would be to consider every Gump project as an implicit version
0 and enable an explicit major version identifier. From this consumer
projects would be able to lock onto the assumed major version without fear
of disruption from source project major-version evolution.
Cheers, Steve.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
RE: Upgraded vmgump to JDK 1.5
Posted by Steve <mc...@apache.org>.
> -----Original Message-----
> From: Leo Simons [mailto:mail@leosimons.com]
> Sent: Sunday, 19 February 2006 2:46 AM
> To: Gump code and data
> Subject: Re: Upgraded vmgump to JDK 1.5
>
> This is to "solve" the junit stuff right?
>
> Will be interesting...I'm personally not happy with how
> effectively there's this one project run by a bunch of people
> who don't particulary understand enough about backwards
> compatibility and the like (just like Sun really) which force
> this kind of thing.
It's not like 'that bunch of people' are taking away 3.8.1! Products evolve
and there is a well established convention concerning major version
increments. The JUnit team are working of 4.X - and that means they are
working on a new product that is not compatible with the 3.X line.
This is a trend commonly referred to as "progress".
> The stupidness is that this is in part a
> limitation that gump has.
Yes - which is the relevant subject for this list. Subscribers should not
be moaning about the fact that an independent project is going the next step
and building an even better testing framework - instead, subscribers should
be looking at why this is an issue for Gump.
Cheers, Steve.
--------------------------
Stephen McConnell
mailto:mcconnell@dpml.net
http://www.dpml.net
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Upgraded vmgump to JDK 1.5
Posted by Leo Simons <ma...@leosimons.com>.
This is to "solve" the junit stuff right?
Will be interesting...I'm personally not happy with how effectively
there's this one project run by a bunch of people who don't particulary
understand enough about backwards compatibility and the like (just like
Sun really) which force this kind of thing. The stupidness is that this
is in part a limitation that gump has. I think I'll try and find time to
blog about this...
ciao!
Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org