commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Benedict" <pbened...@apache.org>
Subject Re: [io] 2.0 Moving to minimum of JDK 1.5
Date Wed, 06 Feb 2008 15:41:44 GMT
Just going to throw in my two cents here...

When a project chooses a different package structure (struts/struts2,
io/io2, etc.), it's advertising itself as truly independent implementations.
That is, you could run Struts 1 and Struts 2 in one application, and also
use Commons IO 1 and Commons IO 2 in one application too.

Paul

On Feb 6, 2008 7:44 AM, Simon Kitching <simon.kitching@chello.at> wrote:

> ---- Stephen Colebourne <scolebourne@btopenworld.com> schrieb:
> > Deprecation is useful when a method has been
> > implemented incorrectly, and we want to push users
> > to a replacement, or for similar issues. Removing deprecated
> > classes/methods should be considered in a major version change,
> > but even there we should question what the gain is. Having a
> > 'nice and clean' no deprecations API release isn't sufficient a
> > reason. We must always put the convenience of our users ahead of
> > our natural refactoring and coding instincts.
>
> +1
>
> If a deprecated method is blocking significant improvement of the product,
> then ok remove it. But just to "clean up" is not really a good enough
> excuse.
>
>
> > The problem is that there is no practical solution to a jar
> > hell situation. Thus, it is our absolute responsibility to
> > do everything in our power to avoid us being the cause of it.
>
> Over the last two weeks I've been working on embedding jspwiki into a
> locally developed application. Now jspwiki is compiled against Lucene
> 1.4.3, but the app already uses Lucene 2.3.0. And yep, they are
> incompatible (slightly, but enough).
>
> Fortunately jspwiki's search functionality is "pluggable" so by rewriting
> one jspwiki class I could make things work. But if the problem library had
> been more deeply embedded into the two systems I don't know what I could
> possibly have done.
>
> Of course if the new release was org.apache.lucene2, then there would be
> no problem.
>
> Compatibility is important.
>
> Regards, Simon
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message