You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Simon Kitching <si...@ecnetwork.co.nz> on 2004/07/22 02:27:49 UTC
Re: [digester] dependencies for 1.6 release
On Thu, 2004-07-22 at 08:54, robert burrell donkin wrote:
> now that the beanutils release is reaching toward completion, i'm
> turning towards the digester release. the release branch was created a
> while ago but there are still some thing which need to be decided.
Woohoo!!
>
> one important issue are the dependencies: in particular, disposing with
> the commons collection dependency (which prevents compatibility with
> both 2.x and 3.x).
>
> i can see two possibilities: either we upgrade the beanutils dependency
> to the latest release (which contains the collections classes that
> digester depends on) or we keep the current beanutils dependency and
> add the necessary classes (as a temporary measure until the appropriate
> methods are deprecated).
>
> originally, i'd assumed that we'd automatically just upgrade the
> beanutils dependency but (previously) stephen made some good arguments
> for added the classes where necessary. anyone else have any opinions?
Do you have a reference to Stephen's arguments?
I'm not generally a great supporter of binary compatibility. I think if
you intend to ship a new release of a library, then you really need a
testing cycle. And if you're doing that, a recompile is no big deal.
Unless we roll back Craig McClanahan's changes to use a local ArrayStack
implementation, we have binary incompatibilities between Digester 1.5
and 1.6 anyway (as described in the current release notes).
So I'm currently in favour of upgrading the BeanUtils dependency.
However I'd like to read Stephen's arguments....
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] dependencies for 1.6 release
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
> personally speaking, i'd gladly support anyone who had the energy to
> push a digester 2 project forward. IMHO the digester one design has
> been pushed just about as far as it can. starting digester 2 would
> allow free refactoring without having to worry about binary
> compatibility (and deprecation). all it takes is a committer with
> enough energy...
That's me :-)
I am certainly willing to work on Digester2. However I would personally
like to see one more release cycle of the current Digester. In
particular, all the "plugins" stuff is new, and I would like the chance
to get this out into a production release and get feedback from users on
the API so that if there are any deficiencies I get a chance to fix them
in 2.0. There are a number of other new features, too, that it would be
good to get feedback on before 2.0.
I am leaving my job in early December this year in order to spend a year
doing a mix of study, research, open-source work and short-term
contracting. It's also a chance to get away from dealing with %$#%$
customers (politics, estimates, deadlines, etc) for a bit. This would be
a good time for me to get stuck into Digester2, particularly as
Digester1.6 would have been out around 4 months, hopefully sufficient
time to get some feedback on the new features. I'm hoping that this will
suit other people interested in Digester..fellow developers, reviewers
and interested parties.
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] dependencies for 1.6 release
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 23 Jul 2004, at 00:56, Simon Kitching wrote:
> On Fri, 2004-07-23 at 10:09, robert burrell donkin wrote:
>> On 22 Jul 2004, at 01:27, Simon Kitching wrote:
>>> On Thu, 2004-07-22 at 08:54, robert burrell donkin wrote:
<snip>
>>> So I'm currently in favour of upgrading the BeanUtils dependency.
>>> However I'd like to read Stephen's arguments....
>>
>> i don't have an url to hand but the general point is that by shipping
>> the classes in the collections package we need (as part of the
>> digester
>> jar) we maximize the choice of dependencies since this would allow
>> users to use digester with previous beanutils releases.
>
> At this point, I'm completely lost. The problem just seems intractible
> to me. We can't keep binary compatibility forever, without crushing all
> innovation. But shipping binary-incompatible releases of libs in
> container environments will, apparently, cause major pains to users of
> those containers.
>
> I might just move to Mono :-(
it's not quite as bad as that :)
better container design (plus later generation container specifications
formulated with the lessons of experience) means that (for modern
containers) these issues aren't as painful as they once were. (in
addition, a number of container vendors such as bea and tomcat 5.1
typically repackage deep libraries.)
in terms of innovation, binary compatibility doesn't quite crush it
though it does slow the pace of change. this is one of the unfortunate
aspects of working on mature, well used code. IMHO the most important
thing to avoid is a constant drip-drip-drip of binary incompatibilities
through minor versions. users are much more willing to suffer a little
pain when the gains are great. so, it's often the case that radical
innovations (where the gains are obviously great) are more likely to be
acceptable than smaller, less innovative steps.
personally speaking, i'd gladly support anyone who had the energy to
push a digester 2 project forward. IMHO the digester one design has
been pushed just about as far as it can. starting digester 2 would
allow free refactoring without having to worry about binary
compatibility (and deprecation). all it takes is a committer with
enough energy...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] dependencies for 1.6 release
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Wed, 2004-08-18 at 08:55, robert burrell donkin wrote:
> On 28 Jul 2004, at 23:23, Simon Kitching wrote:
> > On Thu, 2004-07-29 at 07:24, robert burrell donkin wrote:
>
> <snip>
>
> >> now this is sorted and the other releases i've been cutting are out of
> >> the way, i'm going to start working through the release plan
> >> (http://wiki.apache.org/jakarta-commons/Digester/
> >> 1_2e6_2e0ReleasePlan).
> >>
> >> the major item on the agenda is to review the maturity of the newer
> >> code. simon's worked very hard on the plug-in stuff and that's
> >> probably
> >> where we need to review to ensure that all the APIs are right before
> >> they are fixed by this release. simon - are they any areas in the API
> >> that you have any concerns about?
> >
> > No, I am happy with the current API. But it would be great for someone
> > else to go over it.
>
> looks fine to me :)
>
> i've completed all the pre-release tasks on my list so (unless anyone
> can think of anything else) i'll proceed to the creation of a release
> candidate tomorrow.
Woohoo!!
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] dependencies for 1.6 release
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 28 Jul 2004, at 23:23, Simon Kitching wrote:
> On Thu, 2004-07-29 at 07:24, robert burrell donkin wrote:
<snip>
>> now this is sorted and the other releases i've been cutting are out of
>> the way, i'm going to start working through the release plan
>> (http://wiki.apache.org/jakarta-commons/Digester/
>> 1_2e6_2e0ReleasePlan).
>>
>> the major item on the agenda is to review the maturity of the newer
>> code. simon's worked very hard on the plug-in stuff and that's
>> probably
>> where we need to review to ensure that all the APIs are right before
>> they are fixed by this release. simon - are they any areas in the API
>> that you have any concerns about?
>
> No, I am happy with the current API. But it would be great for someone
> else to go over it.
looks fine to me :)
i've completed all the pre-release tasks on my list so (unless anyone
can think of anything else) i'll proceed to the creation of a release
candidate tomorrow.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] dependencies for 1.6 release
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 28 Jul 2004, at 23:23, Simon Kitching wrote:
> On Thu, 2004-07-29 at 07:24, robert burrell donkin wrote:
<snip>
>> now this is sorted and the other releases i've been cutting are out of
>> the way, i'm going to start working through the release plan
>> (http://wiki.apache.org/jakarta-commons/Digester/
>> 1_2e6_2e0ReleasePlan).
>>
>> the major item on the agenda is to review the maturity of the newer
>> code. simon's worked very hard on the plug-in stuff and that's
>> probably
>> where we need to review to ensure that all the APIs are right before
>> they are fixed by this release. simon - are they any areas in the API
>> that you have any concerns about?
>
> No, I am happy with the current API. But it would be great for someone
> else to go over it.
cool. i'll try to find some time this weekend. anyone else out there
(who's got the time), speak now (or at least in the near future) or
forever hold your peace (or at the very least don't whinge on list ;)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] dependencies for 1.6 release
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Thu, 2004-07-29 at 07:24, robert burrell donkin wrote:
> On 26 Jul 2004, at 17:59, Craig McClanahan wrote:
> > On Mon, 26 Jul 2004 20:07:59 +1200, Simon Kitching
> > <si...@ecnetwork.co.nz> wrote:
> >> On Mon, 2004-07-26 at 19:13, robert burrell donkin wrote:
>
> <snip>
>
> >> And will the Digester 1.x series be committed to depending on
> >> collections, with the happy coincidence that the BeanUtils "extended"
> >> jar also happens to satisfy Digester's need for commons-collections?
> >
> > The whole goal of this exercise has been to decouple both Digester and
> > BeanUtils from the Commons Collections dependency. It's a relatively
> > large JAR file to require solely for two or three classes.
> >
> > Before these changes, Digester depended on Collections both directly
> > and indirectly. The checkin of o.a.c.d.ArrayStack fixed the direct
> > dependence, but broke backwards compatibility and needs to be undone.
> > But, from a Digester viewpoint, we're going to depend on BeanUtils no
> > matter what, and will be able to leverage what BeanUtils does to solve
> > the problem. The ideal end game, then, is that Digester 1.6 will work
> > with either
> >
> > * BeanUtils >= 1.7 (including o.a.c.c.ArrayStack)
> >
> > * BeanUtils < 1.7 plus Collections x.y
> >
> > The former will be (at a minimum) recommended in order to pick up
> > BeanUtils bugfixes, but the latter should make life easier for
> > migrations and containers.
>
> +1
>
> i think that this is the right solution. we'll ship digester without
> the extra collection classes.
>
> i plan to cut a beanutils 1.7.1 bug fix release sometime soon. we can
> probably go one better than the above (for downstream container folks).
> for the modular jar set, we can split out the collections classes from
> the beanutils-core into a separate modular jar. this should allow
> containers to depend on beanutils-core.jar plus 2.x or 3.x collections
> or the modular beanutils-collection-utils.jar (except with a better
> name).
And +1 from me.
>
> now this is sorted and the other releases i've been cutting are out of
> the way, i'm going to start working through the release plan
> (http://wiki.apache.org/jakarta-commons/Digester/1_2e6_2e0ReleasePlan).
>
> the major item on the agenda is to review the maturity of the newer
> code. simon's worked very hard on the plug-in stuff and that's probably
> where we need to review to ensure that all the APIs are right before
> they are fixed by this release. simon - are they any areas in the API
> that you have any concerns about?
No, I am happy with the current API. But it would be great for someone
else to go over it.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] dependencies for 1.6 release
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 26 Jul 2004, at 17:59, Craig McClanahan wrote:
> On Mon, 26 Jul 2004 20:07:59 +1200, Simon Kitching
> <si...@ecnetwork.co.nz> wrote:
>> On Mon, 2004-07-26 at 19:13, robert burrell donkin wrote:
<snip>
>> And will the Digester 1.x series be committed to depending on
>> collections, with the happy coincidence that the BeanUtils "extended"
>> jar also happens to satisfy Digester's need for commons-collections?
>
> The whole goal of this exercise has been to decouple both Digester and
> BeanUtils from the Commons Collections dependency. It's a relatively
> large JAR file to require solely for two or three classes.
>
> Before these changes, Digester depended on Collections both directly
> and indirectly. The checkin of o.a.c.d.ArrayStack fixed the direct
> dependence, but broke backwards compatibility and needs to be undone.
> But, from a Digester viewpoint, we're going to depend on BeanUtils no
> matter what, and will be able to leverage what BeanUtils does to solve
> the problem. The ideal end game, then, is that Digester 1.6 will work
> with either
>
> * BeanUtils >= 1.7 (including o.a.c.c.ArrayStack)
>
> * BeanUtils < 1.7 plus Collections x.y
>
> The former will be (at a minimum) recommended in order to pick up
> BeanUtils bugfixes, but the latter should make life easier for
> migrations and containers.
+1
i think that this is the right solution. we'll ship digester without
the extra collection classes.
i plan to cut a beanutils 1.7.1 bug fix release sometime soon. we can
probably go one better than the above (for downstream container folks).
for the modular jar set, we can split out the collections classes from
the beanutils-core into a separate modular jar. this should allow
containers to depend on beanutils-core.jar plus 2.x or 3.x collections
or the modular beanutils-collection-utils.jar (except with a better
name).
now this is sorted and the other releases i've been cutting are out of
the way, i'm going to start working through the release plan
(http://wiki.apache.org/jakarta-commons/Digester/1_2e6_2e0ReleasePlan).
the major item on the agenda is to review the maturity of the newer
code. simon's worked very hard on the plug-in stuff and that's probably
where we need to review to ensure that all the APIs are right before
they are fixed by this release. simon - are they any areas in the API
that you have any concerns about?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] dependencies for 1.6 release
Posted by Craig McClanahan <cr...@gmail.com>.
On Mon, 26 Jul 2004 20:07:59 +1200, Simon Kitching
<si...@ecnetwork.co.nz> wrote:
> On Mon, 2004-07-26 at 19:13, robert burrell donkin wrote:
> > hi simon
> >
> > we all agree that the long term solution is to use an ArrayStack
> > packaged as part of digester. in fact, if we new then what we know now
> > about developing libraries, we have done this from the start.
> >
> > i also agree that it's a trick and a hack but in my mind, it's the
> > least worst solution.
> >
> > ArrayStack is stable and mature. there have been no code changes (that
> > i can see) in the last 18 months
> > (http://cvs.apache.org/viewcvs.cgi/jakarta-commons/collections/src/
> > java/org/apache/commons/collections/ArrayStack.java) and there seem to
> > be no substantial ones since the code was donated from Digester. this
> > means that it's very, very unlikely that version problems will occur.
> >
> > even setting aside the issue of containers (and the risks of insoluble
> > binary compatibility issues), shipping a binary incompatible version of
> > digester would cause compatibility problems for struts users (and
> > anyone else using a framework dependent on digester). they would not be
> > able to drop the new digester jar in as a replacement for the struts
> > digester dependency. yes, they could recompile the struts release from
> > source but i'm keen to see the new enhancements used as widely as
> > possible. this means binary compatibility.
> >
>
> Ok, so the problem is that lib A (eg struts) depends on Digester 1.5.
> And lib B depends on Digester 1.6. And a user app then depends on lib A
> and lib B.
It is actually worse than that ... if the application incudes a
subclass of org.apache.commons.digester.Digester, it will either work
or fail depending on which version of commons-digester.jar happens to
be found first in the class path. That is why the commit I did
(creating o.a.c.d.ArrayStack) is broken. That is *way* too fragile to
knowingly allow.
>
> We don't want them to have to find versions of A and B which have been
> compiled against the same Digester release. Instead we want to provide a
> version of Digester that is compatible with both A and B.
>
> I guess the ugliness is only within BeanUtils, not Digester, in that
> BeanUtils is bundling the "alien" class, and Digester just wants the
> o.a.c.c.ArrayStack class to be *somewhere* in the classpath.
>
Right.
> Are you intending to have two BeanUtils jars, the "standard" one and an
> "extended" convenience jar that tosses in some external classes? With
> this, I feel a bit more comfortable about this. After all, users can
> still use the latest Digester + the latest BeanUtils "standard" release
> + a normal collections jar, and get exactly the same result as using the
> BeanUtils "extended" release + no collections lib. [sorry I haven't been
> following the BeanUtils emails more closely].
>
I don't see a reason to make life harder on BeanUtils users by
splitting out this stuff. I'd rather live with the temporary class
duplication (which the collections folks have indicated they are
unlikely to change), and resolve it later.
> What is the plan for untangling this later? Will BeanUtils 1.x always
> depend on collections, with this "extended" jar option available that
> includes the necessary dependencies?
>
My view is that BeanUtils 1.x should package o.a.c.c.ArrayStack (and
the other collection classes that it did the same thing with),
"forever" through the 1.x lifetime. The problem is that it's baked
into the public API, so it woud be extremely difficult to change.
A 2.x BeanUtils would have the opportunity to resolve this (plus apply
a lot of the other lessons we've learned over the last four years).
> And will the Digester 1.x series be committed to depending on
> collections, with the happy coincidence that the BeanUtils "extended"
> jar also happens to satisfy Digester's need for commons-collections?
The whole goal of this exercise has been to decouple both Digester and
BeanUtils from the Commons Collections dependency. It's a relatively
large JAR file to require solely for two or three classes.
Before these changes, Digester depended on Collections both directly
and indirectly. The checkin of o.a.c.d.ArrayStack fixed the direct
dependence, but broke backwards compatibility and needs to be undone.
But, from a Digester viewpoint, we're going to depend on BeanUtils no
matter what, and will be able to leverage what BeanUtils does to solve
the problem. The ideal end game, then, is that Digester 1.6 will work
with either
* BeanUtils >= 1.7 (including o.a.c.c.ArrayStack)
* BeanUtils < 1.7 plus Collections x.y
The former will be (at a minimum) recommended in order to pick up
BeanUtils bugfixes, but the latter should make life easier for
migrations and containers.
>
> Regards,
>
> Simon
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] dependencies for 1.6 release
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Mon, 2004-07-26 at 19:13, robert burrell donkin wrote:
> hi simon
>
> we all agree that the long term solution is to use an ArrayStack
> packaged as part of digester. in fact, if we new then what we know now
> about developing libraries, we have done this from the start.
>
> i also agree that it's a trick and a hack but in my mind, it's the
> least worst solution.
>
> ArrayStack is stable and mature. there have been no code changes (that
> i can see) in the last 18 months
> (http://cvs.apache.org/viewcvs.cgi/jakarta-commons/collections/src/
> java/org/apache/commons/collections/ArrayStack.java) and there seem to
> be no substantial ones since the code was donated from Digester. this
> means that it's very, very unlikely that version problems will occur.
>
> even setting aside the issue of containers (and the risks of insoluble
> binary compatibility issues), shipping a binary incompatible version of
> digester would cause compatibility problems for struts users (and
> anyone else using a framework dependent on digester). they would not be
> able to drop the new digester jar in as a replacement for the struts
> digester dependency. yes, they could recompile the struts release from
> source but i'm keen to see the new enhancements used as widely as
> possible. this means binary compatibility.
>
Ok, so the problem is that lib A (eg struts) depends on Digester 1.5.
And lib B depends on Digester 1.6. And a user app then depends on lib A
and lib B.
We don't want them to have to find versions of A and B which have been
compiled against the same Digester release. Instead we want to provide a
version of Digester that is compatible with both A and B.
I guess the ugliness is only within BeanUtils, not Digester, in that
BeanUtils is bundling the "alien" class, and Digester just wants the
o.a.c.c.ArrayStack class to be *somewhere* in the classpath.
Are you intending to have two BeanUtils jars, the "standard" one and an
"extended" convenience jar that tosses in some external classes? With
this, I feel a bit more comfortable about this. After all, users can
still use the latest Digester + the latest BeanUtils "standard" release
+ a normal collections jar, and get exactly the same result as using the
BeanUtils "extended" release + no collections lib. [sorry I haven't been
following the BeanUtils emails more closely].
What is the plan for untangling this later? Will BeanUtils 1.x always
depend on collections, with this "extended" jar option available that
includes the necessary dependencies?
And will the Digester 1.x series be committed to depending on
collections, with the happy coincidence that the BeanUtils "extended"
jar also happens to satisfy Digester's need for commons-collections?
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] dependencies for 1.6 release
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
hi simon
we all agree that the long term solution is to use an ArrayStack
packaged as part of digester. in fact, if we new then what we know now
about developing libraries, we have done this from the start.
i also agree that it's a trick and a hack but in my mind, it's the
least worst solution.
ArrayStack is stable and mature. there have been no code changes (that
i can see) in the last 18 months
(http://cvs.apache.org/viewcvs.cgi/jakarta-commons/collections/src/
java/org/apache/commons/collections/ArrayStack.java) and there seem to
be no substantial ones since the code was donated from Digester. this
means that it's very, very unlikely that version problems will occur.
even setting aside the issue of containers (and the risks of insoluble
binary compatibility issues), shipping a binary incompatible version of
digester would cause compatibility problems for struts users (and
anyone else using a framework dependent on digester). they would not be
able to drop the new digester jar in as a replacement for the struts
digester dependency. yes, they could recompile the struts release from
source but i'm keen to see the new enhancements used as widely as
possible. this means binary compatibility.
- robert
On 26 Jul 2004, at 04:45, Simon Kitching wrote:
> On Mon, 2004-07-26 at 15:23, Craig McClanahan wrote:
>>>
>>> For me, the most important decision is whether to roll back Craig
>>> McClanahan's changes to the ArrayStack class. Craig added a copy of
>>> ArrayStack as o.a.c.d.ArrayStack, to remove the dependency on
>>> commons-collections. But this creates a binary compatibility; because
>>> the field is protected, any existing code that subclasses Digester
>>> will
>>> break.
>>>
>>
>> Ah ... that's the rationale that I hadn't caught in the earlier thread
>> ... and it makes perfect sense. The problem was that the package name
>> was changed when I did the import, and that's the wrong thing to do.
>> Robert did it right when he copied o.a.c.c.ArrayStack into beanutils
>> ... the package name is still "collections".
>>
>>> If containers exist which expose the Digester to the containees,
>>> then we
>>> probably do need to roll back this change. But I'm not convinced
>>> this is
>>> the case.
>>>
>>> The other significant issue is whether to require the new BeanUtils
>>> release for Digester.
>>>
>>> I'm currently
>>> +1 on leaving Craig's changes in (-0 on removing them)
>>> +1 on requiring the latest BeanUtils.
>>
>> If we pull this change back out, and go back to
>> org.apache.commons.collections.ArrayStack, then the new Digester
>> should work with either
>> (a) old BeanUtils and old Collections, or
>> (b) new BeanUtils
>>
>> So, I'm currently:
>> +1 on pulling this change out
>> +1 on requiring new BeanUtils (and removing the
>> explicit Collections dependency).
>>
>> If someone wants to test the old-beanutils+collections scenario, we
>> can document that combination as working as well.
>
> But this concept of bundling o.a.c.collections classes with an
> o.a.c.digester distribution isn't stable long-term, right? It is only a
> short-term hack to preserve backwards compatibility for a short while
> until a better solution is implemented. It creates *really* nasty
> problems if an app ever wants to use a release of o.a.c.collections
> which has a modified ArrayStack class. And it's just not elegant.
>
> The situation with BeanUtils is slightly different, due to the public
> API which references collections; but even then, its not so different.
> A
> protected field is part of the published API to a class too.
>
> I believe the better (long-term) solution is to create
> o.a.c.d.ArrayStack, just as Craig has done. Digester can then be used
> without collections, and any version of collections can then be safely
> used in the same classloader as Digester if someone desires it.
> BeanUtils will then effectively do the same, resulting in a small
> amount
> of code duplication, but with each app's dependencies being much
> cleaner.
>
> What exactly is this ugly hack of bundling o.a.c.c.ArrayStack with
> o.a.c.beanutils giving us? What is the plan for phasing out
> o.a.c.c.ArrayStack in favour of o.a.c.d.ArrayStack?
>
> I can't currently see any real benefit in delaying implementing the
> proper solution. Yes, the change to o.a.c.d.ArrayStack is
> binary-incompatible. But as I said earlier, this is not a *bugfix*
> release (third-digit version change), but a *feature* release
> (second-digit version change), except for a fix to NodeCreateRule.
> No-one *has* to upgrade to the latest digester release. If someone
> chooses to upgrade, then they should recompile against the latest
> release, and then the problem goes away.
>
> The container/containee relationship is the only case I can see where
> it
> is not feasable to recompile against the new release; the distributor
> of
> the container can't recompile the containees, and in many cases neither
> can the sysop deploying the container. But as we've established, sane
> containers don't expose their use of Digester to the containees, so
> that
> argument is not valid.
>
> Regards,
>
> Simon
>
>
>>
>>>
>>> Regards,
>>>
>>> Simon
>>
>> Craig
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] dependencies for 1.6 release
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Mon, 2004-07-26 at 15:23, Craig McClanahan wrote:
> >
> > For me, the most important decision is whether to roll back Craig
> > McClanahan's changes to the ArrayStack class. Craig added a copy of
> > ArrayStack as o.a.c.d.ArrayStack, to remove the dependency on
> > commons-collections. But this creates a binary compatibility; because
> > the field is protected, any existing code that subclasses Digester will
> > break.
> >
>
> Ah ... that's the rationale that I hadn't caught in the earlier thread
> ... and it makes perfect sense. The problem was that the package name
> was changed when I did the import, and that's the wrong thing to do.
> Robert did it right when he copied o.a.c.c.ArrayStack into beanutils
> ... the package name is still "collections".
>
> > If containers exist which expose the Digester to the containees, then we
> > probably do need to roll back this change. But I'm not convinced this is
> > the case.
> >
> > The other significant issue is whether to require the new BeanUtils
> > release for Digester.
> >
> > I'm currently
> > +1 on leaving Craig's changes in (-0 on removing them)
> > +1 on requiring the latest BeanUtils.
>
> If we pull this change back out, and go back to
> org.apache.commons.collections.ArrayStack, then the new Digester
> should work with either
> (a) old BeanUtils and old Collections, or
> (b) new BeanUtils
>
> So, I'm currently:
> +1 on pulling this change out
> +1 on requiring new BeanUtils (and removing the
> explicit Collections dependency).
>
> If someone wants to test the old-beanutils+collections scenario, we
> can document that combination as working as well.
But this concept of bundling o.a.c.collections classes with an
o.a.c.digester distribution isn't stable long-term, right? It is only a
short-term hack to preserve backwards compatibility for a short while
until a better solution is implemented. It creates *really* nasty
problems if an app ever wants to use a release of o.a.c.collections
which has a modified ArrayStack class. And it's just not elegant.
The situation with BeanUtils is slightly different, due to the public
API which references collections; but even then, its not so different. A
protected field is part of the published API to a class too.
I believe the better (long-term) solution is to create
o.a.c.d.ArrayStack, just as Craig has done. Digester can then be used
without collections, and any version of collections can then be safely
used in the same classloader as Digester if someone desires it.
BeanUtils will then effectively do the same, resulting in a small amount
of code duplication, but with each app's dependencies being much
cleaner.
What exactly is this ugly hack of bundling o.a.c.c.ArrayStack with
o.a.c.beanutils giving us? What is the plan for phasing out
o.a.c.c.ArrayStack in favour of o.a.c.d.ArrayStack?
I can't currently see any real benefit in delaying implementing the
proper solution. Yes, the change to o.a.c.d.ArrayStack is
binary-incompatible. But as I said earlier, this is not a *bugfix*
release (third-digit version change), but a *feature* release
(second-digit version change), except for a fix to NodeCreateRule.
No-one *has* to upgrade to the latest digester release. If someone
chooses to upgrade, then they should recompile against the latest
release, and then the problem goes away.
The container/containee relationship is the only case I can see where it
is not feasable to recompile against the new release; the distributor of
the container can't recompile the containees, and in many cases neither
can the sysop deploying the container. But as we've established, sane
containers don't expose their use of Digester to the containees, so that
argument is not valid.
Regards,
Simon
>
> >
> > Regards,
> >
> > Simon
>
> Craig
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] dependencies for 1.6 release
Posted by Craig McClanahan <cr...@gmail.com>.
>
> For me, the most important decision is whether to roll back Craig
> McClanahan's changes to the ArrayStack class. Craig added a copy of
> ArrayStack as o.a.c.d.ArrayStack, to remove the dependency on
> commons-collections. But this creates a binary compatibility; because
> the field is protected, any existing code that subclasses Digester will
> break.
>
Ah ... that's the rationale that I hadn't caught in the earlier thread
... and it makes perfect sense. The problem was that the package name
was changed when I did the import, and that's the wrong thing to do.
Robert did it right when he copied o.a.c.c.ArrayStack into beanutils
... the package name is still "collections".
> If containers exist which expose the Digester to the containees, then we
> probably do need to roll back this change. But I'm not convinced this is
> the case.
>
> The other significant issue is whether to require the new BeanUtils
> release for Digester.
>
> I'm currently
> +1 on leaving Craig's changes in (-0 on removing them)
> +1 on requiring the latest BeanUtils.
If we pull this change back out, and go back to
org.apache.commons.collections.ArrayStack, then the new Digester
should work with either
(a) old BeanUtils and old Collections, or
(b) new BeanUtils
So, I'm currently:
+1 on pulling this change out
+1 on requiring new BeanUtils (and removing the
explicit Collections dependency).
If someone wants to test the old-beanutils+collections scenario, we
can document that combination as working as well.
>
> Regards,
>
> Simon
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] dependencies for 1.6 release
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Mon, 2004-07-26 at 10:02, robert burrell donkin wrote:
> On 25 Jul 2004, at 17:37, Craig McClanahan wrote:
> > On Sun, 25 Jul 2004 17:07:53 +1200, Simon Kitching
> > <si...@ecnetwork.co.nz> wrote:
>
> <snip>
>
> >> Do you know of any containers that actually do use Digester and make
> >> it
> >> visible to containee code?
> >
> > Good question.
>
> definitely know? no
>
> i do seem to vaguely recall that some early versions of weblogic or
> websphere do (i don't recall which it is or whether it's both). in
> general, classloader issues used to be common with early containers and
> less for more modern ones. i suspect that the only way we'd find out
> whether this is a real issue would be to cut our first binary
> incompatible digester release and then see how many users complained. i
> don't know of any modern container that exposes digester through it's
> root classloader.
>
> > But, regardless of the answer, wasn't the original question in this
> > thread related to whether a new Digester release should specify a new
> > BeansUtil release as a dependency (and thus allow it to not require
> > commons-collections)? I still think that's a good idea, and have lost
> > track of the current thinking on that topic.
>
> the question was: which way should be commons-collections dependency be
> removed. i offered two options:
>
> 1 demand the latest beanutils version
> 2 allow whichever beanutils version but include the collection packaged
> classes as part of the digester release
>
> i originally thought that option 1 would be best but i've been
> partially persuaded by stephen that 2 has some advantages (it has the
> greatest range of compatibility).
For me, the most important decision is whether to roll back Craig
McClanahan's changes to the ArrayStack class. Craig added a copy of
ArrayStack as o.a.c.d.ArrayStack, to remove the dependency on
commons-collections. But this creates a binary compatibility; because
the field is protected, any existing code that subclasses Digester will
break.
If containers exist which expose the Digester to the containees, then we
probably do need to roll back this change. But I'm not convinced this is
the case.
The other significant issue is whether to require the new BeanUtils
release for Digester.
I'm currently
+1 on leaving Craig's changes in (-0 on removing them)
+1 on requiring the latest BeanUtils.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] dependencies for 1.6 release
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 25 Jul 2004, at 17:37, Craig McClanahan wrote:
> On Sun, 25 Jul 2004 17:07:53 +1200, Simon Kitching
> <si...@ecnetwork.co.nz> wrote:
<snip>
>> Do you know of any containers that actually do use Digester and make
>> it
>> visible to containee code?
>
> Good question.
definitely know? no
i do seem to vaguely recall that some early versions of weblogic or
websphere do (i don't recall which it is or whether it's both). in
general, classloader issues used to be common with early containers and
less for more modern ones. i suspect that the only way we'd find out
whether this is a real issue would be to cut our first binary
incompatible digester release and then see how many users complained. i
don't know of any modern container that exposes digester through it's
root classloader.
> But, regardless of the answer, wasn't the original question in this
> thread related to whether a new Digester release should specify a new
> BeansUtil release as a dependency (and thus allow it to not require
> commons-collections)? I still think that's a good idea, and have lost
> track of the current thinking on that topic.
the question was: which way should be commons-collections dependency be
removed. i offered two options:
1 demand the latest beanutils version
2 allow whichever beanutils version but include the collection packaged
classes as part of the digester release
i originally thought that option 1 would be best but i've been
partially persuaded by stephen that 2 has some advantages (it has the
greatest range of compatibility).
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] dependencies for 1.6 release
Posted by Craig McClanahan <cr...@gmail.com>.
On Sun, 25 Jul 2004 17:07:53 +1200, Simon Kitching
<si...@ecnetwork.co.nz> wrote:
>
> I've thought some more about this.
>
> Why exactly would a container expose Digester to the "containees"?
>
> If a container wants to use Digester to parse its configuration files,
> then that is an internal matter for that container, and the Digester lib
> (plus all that it depends upon) should be loaded by a container-specific
> classloader that isn't exposed to the containees.
>
That's exactly why Tomcat supports a server/lib directory that is
visible to the internals of the container, but *not* visible to
applications. And that's where Tomcat puts its internal copy of
Digester by default.
> And with that setup, we don't need to be *overly* concerned about binary
> compatibility. The container uses version X of Digester, and each
> containee uses their own version.
>
> Surely exposing a library that is only used for internal purposes within
> a container is poor design - even worse than exposing private methods
> and variables.
>
Sounds sub-optimal to me.
> Do you know of any containers that actually do use Digester and make it
> visible to containee code?
Good question.
But, regardless of the answer, wasn't the original question in this
thread related to whether a new Digester release should specify a new
BeansUtil release as a dependency (and thus allow it to not require
commons-collections)? I still think that's a good idea, and have lost
track of the current thinking on that topic.
>
>
>
> Regards,
>
> Simon
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] dependencies for 1.6 release
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Fri, 2004-07-23 at 11:56, Simon Kitching wrote:
> On Fri, 2004-07-23 at 10:09, robert burrell donkin wrote:
> > On 22 Jul 2004, at 01:27, Simon Kitching wrote:
> > > On Thu, 2004-07-22 at 08:54, robert burrell donkin wrote:
> >
> >
> >
> > > I'm not generally a great supporter of binary compatibility. I think if
> > > you intend to ship a new release of a library, then you really need a
> > > testing cycle. And if you're doing that, a recompile is no big deal.
> >
> > i see binary compatibility as absolutely crucial for deep libraries
> > such as digester. digester is in the root classpath of many containers.
> > this means that contained applications can only use binary compatible
> > versions of the library (unless they plan to recompile the application,
> > that is). so, releasing a binary incompatible version of digester is
> > likely to cause real pain for many users.
>
> Ok, the container issue is one I overlooked.
>
> This java library versioning problem is looking nastier and nastier the
> more I learn about it. Maybe .NET got it right with its versioned
> library schema, and Java needs to adopt something like that...
I've thought some more about this.
Why exactly would a container expose Digester to the "containees"?
If a container wants to use Digester to parse its configuration files,
then that is an internal matter for that container, and the Digester lib
(plus all that it depends upon) should be loaded by a container-specific
classloader that isn't exposed to the containees.
And with that setup, we don't need to be *overly* concerned about binary
compatibility. The container uses version X of Digester, and each
containee uses their own version.
Surely exposing a library that is only used for internal purposes within
a container is poor design - even worse than exposing private methods
and variables.
Do you know of any containers that actually do use Digester and make it
visible to containee code?
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] dependencies for 1.6 release
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Fri, 2004-07-23 at 10:09, robert burrell donkin wrote:
> On 22 Jul 2004, at 01:27, Simon Kitching wrote:
> > On Thu, 2004-07-22 at 08:54, robert burrell donkin wrote:
>
> <snip>
>
> >> one important issue are the dependencies: in particular, disposing
> >> with
> >> the commons collection dependency (which prevents compatibility with
> >> both 2.x and 3.x).
> >>
> >> i can see two possibilities: either we upgrade the beanutils
> >> dependency
> >> to the latest release (which contains the collections classes that
> >> digester depends on) or we keep the current beanutils dependency and
> >> add the necessary classes (as a temporary measure until the
> >> appropriate
> >> methods are deprecated).
> >>
> >> originally, i'd assumed that we'd automatically just upgrade the
> >> beanutils dependency but (previously) stephen made some good arguments
> >> for added the classes where necessary. anyone else have any opinions?
> >
> > Do you have a reference to Stephen's arguments?
>
> not to hand.
>
> > I'm not generally a great supporter of binary compatibility. I think if
> > you intend to ship a new release of a library, then you really need a
> > testing cycle. And if you're doing that, a recompile is no big deal.
>
> i see binary compatibility as absolutely crucial for deep libraries
> such as digester. digester is in the root classpath of many containers.
> this means that contained applications can only use binary compatible
> versions of the library (unless they plan to recompile the application,
> that is). so, releasing a binary incompatible version of digester is
> likely to cause real pain for many users.
Ok, the container issue is one I overlooked.
This java library versioning problem is looking nastier and nastier the
more I learn about it. Maybe .NET got it right with its versioned
library schema, and Java needs to adopt something like that...
>
> in fact, for digester two, it might be better to use a different
> package name (digester2, say) to ensure that the two versions of the
> library can be used together in the same container without causing
> compatibility problems.
I see your point.
>
> > Unless we roll back Craig McClanahan's changes to use a local
> > ArrayStack
> > implementation, we have binary incompatibilities between Digester 1.5
> > and 1.6 anyway (as described in the current release notes).
>
> my plan is to roll back craig's changes (on the release branch) and
> ship with either the new beanutils dependency (containing the classes
> digester depends on) or to ship with copies of the collection packaged
> classes we need (as beanutils does).
>
> > So I'm currently in favour of upgrading the BeanUtils dependency.
> > However I'd like to read Stephen's arguments....
>
> i don't have an url to hand but the general point is that by shipping
> the classes in the collections package we need (as part of the digester
> jar) we maximize the choice of dependencies since this would allow
> users to use digester with previous beanutils releases.
At this point, I'm completely lost. The problem just seems intractible
to me. We can't keep binary compatibility forever, without crushing all
innovation. But shipping binary-incompatible releases of libs in
container environments will, apparently, cause major pains to users of
those containers.
I might just move to Mono :-(
In the meantime, I'm ok with whatever you decide on this.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] dependencies for 1.6 release
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 22 Jul 2004, at 01:27, Simon Kitching wrote:
> On Thu, 2004-07-22 at 08:54, robert burrell donkin wrote:
<snip>
>> one important issue are the dependencies: in particular, disposing
>> with
>> the commons collection dependency (which prevents compatibility with
>> both 2.x and 3.x).
>>
>> i can see two possibilities: either we upgrade the beanutils
>> dependency
>> to the latest release (which contains the collections classes that
>> digester depends on) or we keep the current beanutils dependency and
>> add the necessary classes (as a temporary measure until the
>> appropriate
>> methods are deprecated).
>>
>> originally, i'd assumed that we'd automatically just upgrade the
>> beanutils dependency but (previously) stephen made some good arguments
>> for added the classes where necessary. anyone else have any opinions?
>
> Do you have a reference to Stephen's arguments?
not to hand.
> I'm not generally a great supporter of binary compatibility. I think if
> you intend to ship a new release of a library, then you really need a
> testing cycle. And if you're doing that, a recompile is no big deal.
i see binary compatibility as absolutely crucial for deep libraries
such as digester. digester is in the root classpath of many containers.
this means that contained applications can only use binary compatible
versions of the library (unless they plan to recompile the application,
that is). so, releasing a binary incompatible version of digester is
likely to cause real pain for many users.
in fact, for digester two, it might be better to use a different
package name (digester2, say) to ensure that the two versions of the
library can be used together in the same container without causing
compatibility problems.
> Unless we roll back Craig McClanahan's changes to use a local
> ArrayStack
> implementation, we have binary incompatibilities between Digester 1.5
> and 1.6 anyway (as described in the current release notes).
my plan is to roll back craig's changes (on the release branch) and
ship with either the new beanutils dependency (containing the classes
digester depends on) or to ship with copies of the collection packaged
classes we need (as beanutils does).
> So I'm currently in favour of upgrading the BeanUtils dependency.
> However I'd like to read Stephen's arguments....
i don't have an url to hand but the general point is that by shipping
the classes in the collections package we need (as part of the digester
jar) we maximize the choice of dependencies since this would allow
users to use digester with previous beanutils releases.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org