You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Michael Wechner <mi...@wyona.com> on 2006/01/12 12:06:30 UTC
Backwards Compatibility re excalibur
Hi
Somebody has removed the
lib/excalibur-io-1.1.jar
library although I have added it just recently such that Lenya is
backwards compatible.
I don't want to get into a commit war, but this library is necessary for
staying backwards compatible.
It's not sufficient to upgrade Lenya itself, but one needs to keep in
mind, that other people
might have built publications based on this library.
Michi
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Backwards Compatibility re excalibur
Posted by Antonio Gallardo <ag...@agssa.net>.
Michael Wechner wrote:
> Hi
>
> Somebody has removed the
>
> lib/excalibur-io-1.1.jar
>
> library although I have added it just recently such that Lenya is
> backwards compatible.
>
> I don't want to get into a commit war, but this library is necessary
> for staying backwards compatible.
>
> It's not sufficient to upgrade Lenya itself, but one needs to keep in
> mind, that other people
> might have built publications based on this library.
Should be enough to point out this in the release notes? That way we
also help our user by informing them they will stop using this library,
decrecated almost 2 years ago[1]. Not everybody has enough time to track
all the 30+ libraries used by lenya, right? ;-)
If we care about the resources, then we can also go deeply an explaing
how easy is the migration path. Basically we are talking about class
name changes:
****************************************************************
The excalibut-io was deprecated. To solve this issue you have 2 paths:
1- Quick and dirty: Download the excalibur-io.jar from ..... and deploy
it in your WEB-INF/lib directory.
2- Clean way (takes few minuts): Repleace all your references to the ol
excalibur-io to the new commons-io:
From --> To
org.apache.avalon.excalibur.io.FileUtil --> org.apache.commons.io.FileUtils
org.apache.avalon.excalibur.io.IOUtil --> org.apache.commons.io.IOUtils
Hint: You can use eclipse replace dialog to do this task in less than 5
minuts.
Sorry for the inconveniences.
WDYT?
Best Regards,
Antonio Gallardo.
[1] http://marc.theaimsgroup.com/?t=104576572800007&r=1&w=2
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Backwards Compatibility re excalibur
Posted by Thorsten Scherler <th...@apache.org>.
El jue, 12-01-2006 a las 12:06 +0100, Michael Wechner escribió:
> Hi
>
> Somebody has removed the
>
> lib/excalibur-io-1.1.jar
>
> library although I have added it just recently such that Lenya is
> backwards compatible.
I looked at the corresponding commit that removed this lib. I reckon to
remove it was not intended but part of the cleanup. I guess the one just
did not remember why you added it again and deleted it as part of
updating.
salu2
>
> I don't want to get into a commit war, but this library is necessary for
> staying backwards compatible.
>
> It's not sufficient to upgrade Lenya itself, but one needs to keep in
> mind, that other people
> might have built publications based on this library.
>
> Michi
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Backwards Compatibility re excalibur
Posted by Michael Wechner <mi...@wyona.com>.
Felix Röthenbacher wrote:
> Michael Wechner wrote:
>
>> Felix Röthenbacher wrote:
>>
>>> Michael Wechner wrote:
>>>
>>>> Hi
>>>>
>>>> Somebody has removed the
>>>>
>>>> lib/excalibur-io-1.1.jar
>>>>
>>>> library although I have added it just recently such that Lenya is
>>>> backwards compatible.
>>>
>>>
>>>
>>>
>>> Lenya is still backwards compatible as the functionality of the
>>> deprecated excalibur-io-1.1.jar is provided by the new commons-io
>>> library.
>>
>>
>>
>>
>> maybe the functionality, but not the API, or am I missing something?!
>>
>>>
>>>>
>>>> I don't want to get into a commit war, but this library is
>>>> necessary for staying backwards compatible.
>>>
>>>
>>>
>>>
>>> To me, it's seems to be impossible to stay backwards compatible with
>>> code that is open-source.
>>
>>
>>
>>
>> I am not going to use a strong way ;-) but that's not true at all!
>>
>> What difference is there between Open Source and closed source re
>> backwards compatibility?!
>
>
> A closed-source software vendor can rely on that no one uses
> any internal functions and he is free to modify internal processing.
exacliabur is not only about internal stuff. Lenya/Cocoon used in order to
prevent the not invented here syndrom and this is the case for many
libraries,
so it's not just about internal stuff
> Open-source Lenya may be adapted and modified in any way, that's
> open-source.
no, not if the dev community resp. PMC decides to stick to backwards
compatibility
>
> It would be best to publish a well-defined API for access to
> Lenya. Then I would agree that if Lenya does not touch the API
> it will be backward compatible, but that's not the case at the moment.
it is the case. Just because the API might sound as official as JCR for
instance, it
doesn't mean it's not an API and we need to guarantee that the same is
true for
the libraries which are being used by Lenya
>
>>
>>> Everybody can do what he wants with the code
>>> but must be aware that it will change in the future (with the exception
>>> of well-defined and agreed-on API's). Staying backwards-compatible
>>> would
>>> mean that you can't modify any functionality, even if it's buggy:
>>
>>
>>
>>
>> "bugs" is an exception to the rule
>>
>>> someone might rely on it and may even exploit the bug for achieving
>>> some tasks (see browser implementations of non-standard CSS).
>>>
>>>>
>>>> It's not sufficient to upgrade Lenya itself, but one needs to keep
>>>> in mind, that other people
>>>> might have built publications based on this library.
>>>
>>>
>>>
>>>
>>> Taken this into consideration, see my comment above. The changes
>>> re the library replacement are minor. The functionality is
>>> provided by the new library. With respect to code maintenance it's
>>> better to jettison deprecated libraries and keep a clean code base.
>>
>>
>>
>>
>> no, it's very clear what backwards compatibility means and if a
>> community agreed to
>> stay backwards compatible within a branch and people are relying on
>> it, then one
>> needs to stick to that committment, doesn't matter what it means to
>> the code base.
>
>
> This would mean to commit Lenya to a specific Cocoon version, as the
> on-going Cocoon development will break backward compatibility,
the problem is, that Cocoon shouldn't break backwards compatibility
within a branch,
at least that's what I understand from their dev community. If that's
not the case, then
we have various choices. Either stick to certain specific Cocoon version
or use something else
than Cocoon, or ...
> as seen
> recently with the library replacement. We should think again about
> saying that Lenya is compatible with Cocoon 2.1.7, 2.1.8 and 2.1.9
> as this can't be assured (e.g. Cocoon 2.1.7 is not compatible with
> 2.1.8).
but that's exactly the problem and I will send an email to the Cocoon
mailing list about this
and I think we all should complain about this.
>
>
> What if a library of Cocoon changes functionality keeping its API.
> Then it will not be possible for Lenya to add the old library as
> there will be conflicts (seen with commons-io-1.0.jar and
> commons-io.1.1.jar). What if Lenya relies on an library xy-1.0.jar but
> Cocoon request library xy-1.1.jar and the two libraries are not
> compatible? It's an imagination to say that Lenya is backward compatible
> re its codebase as this can't be assured.
it might be not always possible for whatever reasons, but in this case
it is and
we as community should do everything to make this happen.
I think it's rather simple:
1) Apache Lenya (and the ASF) decides to develop high-quality Open
Source software which is going to be used
within the entrprise world and of course all the other worlds as well ;-)
2) The enterprise world (and not just the enterprise world) is asking
for backwards compatibility for various reasons
3) From 1 and 2 it follows that Apache Lenya needs to be backwards
compatible
I am very confident that this is possible (at least in most cases,
whereas there are exceptions, e.g. bugs, etc.)
and we as a community have to make sure that we stick to 1 and 3,
otherwise we loose the trust people do have in us
and the project re its goal will fail very qickly.
One can certainly re-discuss the goals and its consequences, but as long
as the goals/rules are in place one
has to make sure to stick to them as good as one can, otherwise the
communuity/society will fall apart very quickly.
Michi
>
>
> - Felix
>
>>
>> Without backwards compatibility there will be no-one using it, except
>> people who
>> don't use it in productive environments or have infinite resources at
>> hand to upgrade
>> all the time.
>>
>> I am not saying that this is a bad thing, but the Lenya community and
>> Apache in general has
>> decided to create software on which people can rely on and backwards
>> compatibility is one of
>> the keys to this.
>>
>> Michi
>>
>>>
>>> No commit war, just my 2 cents :-)
>>>
>>> - Felix
>>>
>>>>
>>>> Michi
>>>>
>>>
>>
>>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Backwards Compatibility re excalibur
Posted by Felix Röthenbacher <fe...@wyona.com>.
Michael Wechner wrote:
> Felix Röthenbacher wrote:
>
>> Michael Wechner wrote:
>>
>>> Hi
>>>
>>> Somebody has removed the
>>>
>>> lib/excalibur-io-1.1.jar
>>>
>>> library although I have added it just recently such that Lenya is
>>> backwards compatible.
>>
>>
>>
>> Lenya is still backwards compatible as the functionality of the
>> deprecated excalibur-io-1.1.jar is provided by the new commons-io
>> library.
>
>
>
> maybe the functionality, but not the API, or am I missing something?!
>
>>
>>>
>>> I don't want to get into a commit war, but this library is necessary
>>> for staying backwards compatible.
>>
>>
>>
>> To me, it's seems to be impossible to stay backwards compatible with
>> code that is open-source.
>
>
>
> I am not going to use a strong way ;-) but that's not true at all!
>
> What difference is there between Open Source and closed source re
> backwards compatibility?!
A closed-source software vendor can rely on that no one uses
any internal functions and he is free to modify internal processing.
Open-source Lenya may be adapted and modified in any way, that's
open-source.
It would be best to publish a well-defined API for access to
Lenya. Then I would agree that if Lenya does not touch the API
it will be backward compatible, but that's not the case at the moment.
>
>> Everybody can do what he wants with the code
>> but must be aware that it will change in the future (with the exception
>> of well-defined and agreed-on API's). Staying backwards-compatible would
>> mean that you can't modify any functionality, even if it's buggy:
>
>
>
> "bugs" is an exception to the rule
>
>> someone might rely on it and may even exploit the bug for achieving
>> some tasks (see browser implementations of non-standard CSS).
>>
>>>
>>> It's not sufficient to upgrade Lenya itself, but one needs to keep in
>>> mind, that other people
>>> might have built publications based on this library.
>>
>>
>>
>> Taken this into consideration, see my comment above. The changes
>> re the library replacement are minor. The functionality is
>> provided by the new library. With respect to code maintenance it's
>> better to jettison deprecated libraries and keep a clean code base.
>
>
>
> no, it's very clear what backwards compatibility means and if a
> community agreed to
> stay backwards compatible within a branch and people are relying on it,
> then one
> needs to stick to that committment, doesn't matter what it means to the
> code base.
This would mean to commit Lenya to a specific Cocoon version, as the
on-going Cocoon development will break backward compatibility, as seen
recently with the library replacement. We should think again about
saying that Lenya is compatible with Cocoon 2.1.7, 2.1.8 and 2.1.9
as this can't be assured (e.g. Cocoon 2.1.7 is not compatible with
2.1.8).
What if a library of Cocoon changes functionality keeping its API.
Then it will not be possible for Lenya to add the old library as
there will be conflicts (seen with commons-io-1.0.jar and
commons-io.1.1.jar). What if Lenya relies on an library xy-1.0.jar but
Cocoon request library xy-1.1.jar and the two libraries are not
compatible? It's an imagination to say that Lenya is backward compatible
re its codebase as this can't be assured.
- Felix
>
> Without backwards compatibility there will be no-one using it, except
> people who
> don't use it in productive environments or have infinite resources at
> hand to upgrade
> all the time.
>
> I am not saying that this is a bad thing, but the Lenya community and
> Apache in general has
> decided to create software on which people can rely on and backwards
> compatibility is one of
> the keys to this.
>
> Michi
>
>>
>> No commit war, just my 2 cents :-)
>>
>> - Felix
>>
>>>
>>> Michi
>>>
>>
>
>
--
Felix Röthenbacher felix.roethenbacher@wyona.com
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Backwards Compatibility re excalibur
Posted by Michael Wechner <mi...@wyona.com>.
Felix Röthenbacher wrote:
> Michael Wechner wrote:
>
>> Hi
>>
>> Somebody has removed the
>>
>> lib/excalibur-io-1.1.jar
>>
>> library although I have added it just recently such that Lenya is
>> backwards compatible.
>
>
> Lenya is still backwards compatible as the functionality of the
> deprecated excalibur-io-1.1.jar is provided by the new commons-io
> library.
maybe the functionality, but not the API, or am I missing something?!
>
>>
>> I don't want to get into a commit war, but this library is necessary
>> for staying backwards compatible.
>
>
> To me, it's seems to be impossible to stay backwards compatible with
> code that is open-source.
I am not going to use a strong way ;-) but that's not true at all!
What difference is there between Open Source and closed source re
backwards compatibility?!
> Everybody can do what he wants with the code
> but must be aware that it will change in the future (with the exception
> of well-defined and agreed-on API's). Staying backwards-compatible would
> mean that you can't modify any functionality, even if it's buggy:
"bugs" is an exception to the rule
> someone might rely on it and may even exploit the bug for achieving
> some tasks (see browser implementations of non-standard CSS).
>
>>
>> It's not sufficient to upgrade Lenya itself, but one needs to keep in
>> mind, that other people
>> might have built publications based on this library.
>
>
> Taken this into consideration, see my comment above. The changes
> re the library replacement are minor. The functionality is
> provided by the new library. With respect to code maintenance it's
> better to jettison deprecated libraries and keep a clean code base.
no, it's very clear what backwards compatibility means and if a
community agreed to
stay backwards compatible within a branch and people are relying on it,
then one
needs to stick to that committment, doesn't matter what it means to the
code base.
Without backwards compatibility there will be no-one using it, except
people who
don't use it in productive environments or have infinite resources at
hand to upgrade
all the time.
I am not saying that this is a bad thing, but the Lenya community and
Apache in general has
decided to create software on which people can rely on and backwards
compatibility is one of
the keys to this.
Michi
>
> No commit war, just my 2 cents :-)
>
> - Felix
>
>>
>> Michi
>>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Backwards Compatibility re excalibur
Posted by Felix Röthenbacher <fe...@wyona.com>.
Michael Wechner wrote:
> Hi
>
> Somebody has removed the
>
> lib/excalibur-io-1.1.jar
>
> library although I have added it just recently such that Lenya is
> backwards compatible.
Lenya is still backwards compatible as the functionality of the
deprecated excalibur-io-1.1.jar is provided by the new commons-io
library.
>
> I don't want to get into a commit war, but this library is necessary for
> staying backwards compatible.
To me, it's seems to be impossible to stay backwards compatible with
code that is open-source. Everybody can do what he wants with the code
but must be aware that it will change in the future (with the exception
of well-defined and agreed-on API's). Staying backwards-compatible would
mean that you can't modify any functionality, even if it's buggy:
someone might rely on it and may even exploit the bug for achieving
some tasks (see browser implementations of non-standard CSS).
>
> It's not sufficient to upgrade Lenya itself, but one needs to keep in
> mind, that other people
> might have built publications based on this library.
Taken this into consideration, see my comment above. The changes
re the library replacement are minor. The functionality is
provided by the new library. With respect to code maintenance it's
better to jettison deprecated libraries and keep a clean code base.
No commit war, just my 2 cents :-)
- Felix
>
> Michi
>
--
Felix Röthenbacher felix.roethenbacher@wyona.com
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Backwards Compatibility re excalibur
Posted by Michael Wechner <mi...@wyona.com>.
Josias Thoeny wrote:
>On Thu, 2006-01-12 at 12:06 +0100, Michael Wechner wrote:
>
>
>>Hi
>>
>>Somebody has removed the
>>
>>lib/excalibur-io-1.1.jar
>>
>>library although I have added it just recently such that Lenya is
>>backwards compatible.
>>
>>I don't want to get into a commit war, but this library is necessary for
>>staying backwards compatible.
>>
>>It's not sufficient to upgrade Lenya itself, but one needs to keep in
>>mind, that other people
>>might have built publications based on this library.
>>
>>
>
>That was my fault. Please apologize that I didn't realize that existing
>publications are using the excalibur-io library.
>Anyway I suggest to update these publications to use commons-io, because
>it's easy to do.
>
>
that certainly makes sense, but for various reasons one cannot expect
people to upgrade.
Michi
>Josias
>
>
>
>
>>Michi
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
>For additional commands, e-mail: dev-help@lenya.apache.org
>
>
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Backwards Compatibility re excalibur
Posted by Josias Thoeny <jo...@wyona.com>.
On Thu, 2006-01-12 at 12:06 +0100, Michael Wechner wrote:
> Hi
>
> Somebody has removed the
>
> lib/excalibur-io-1.1.jar
>
> library although I have added it just recently such that Lenya is
> backwards compatible.
>
> I don't want to get into a commit war, but this library is necessary for
> staying backwards compatible.
>
> It's not sufficient to upgrade Lenya itself, but one needs to keep in
> mind, that other people
> might have built publications based on this library.
That was my fault. Please apologize that I didn't realize that existing
publications are using the excalibur-io library.
Anyway I suggest to update these publications to use commons-io, because
it's easy to do.
Josias
>
> Michi
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org