You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <ga...@gmail.com> on 2011/03/29 19:44:30 UTC
[codec] Moving on to codec 2.0
Hi All,
Now that codec 1.5 is out, I would like thoughts on this plan for codec 2.0:
- Create a SVN branch for 1.x
Then in trunk:
- Correct Maven group id, which implies:
- Repackage to o.a.c.codec2
- Use Java 5
- Use JUnit 4
What else? Thoughts?
Thank you,
Gary
--
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
Re: [codec] Moving on to codec 2.0
Posted by Simone Tripodi <si...@apache.org>.
+1 for me Gary, I strongly support this kind of initiatives!!!
Have a nice day,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Mar 29, 2011 at 7:44 PM, Gary Gregory <ga...@gmail.com> wrote:
> Hi All,
>
> Now that codec 1.5 is out, I would like thoughts on this plan for codec 2.0:
>
> - Create a SVN branch for 1.x
>
> Then in trunk:
> - Correct Maven group id, which implies:
> - Repackage to o.a.c.codec2
> - Use Java 5
> - Use JUnit 4
>
> What else? Thoughts?
>
> Thank you,
> Gary
> --
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] Moving on to codec 2.0
Posted by Jörg Schaible <jo...@gmx.de>.
sebb wrote:
> On 29 March 2011 18:44, Gary Gregory <ga...@gmail.com> wrote:
>> Hi All,
>>
>> Now that codec 1.5 is out, I would like thoughts on this plan for codec
>> 2.0:
>>
>> - Create a SVN branch for 1.x
>>
>> Then in trunk:
>> - Correct Maven group id, which implies:
>
> -1, see below.
>
>> - Repackage to o.a.c.codec2
>
> This forces all end-users to edit their source and recompile.
>
> I think that should be avoided unless the API is also being changed in
> an incompatible way, and then only if it really is impossible to
> maintain backwards compatibility.
Or the API has a big benefit using some kind of Java 5 stuff. If we move to
2.x we should not limit ourselves in first place, but keep compatibility as
long as it make sense and is technically possible.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] Moving on to codec 2.0
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Mar 29, 2011 at 2:52 PM, sebb <se...@gmail.com> wrote:
> On 29 March 2011 18:44, Gary Gregory <ga...@gmail.com> wrote:
> > Hi All,
> >
> > Now that codec 1.5 is out, I would like thoughts on this plan for codec
> 2.0:
> >
> > - Create a SVN branch for 1.x
> >
> > Then in trunk:
> > - Correct Maven group id, which implies:
>
> -1, see below.
>
> > - Repackage to o.a.c.codec2
>
> This forces all end-users to edit their source and recompile.
>
> I think that should be avoided unless the API is also being changed in
> an incompatible way, and then only if it really is impossible to
> maintain backwards compatibility.
>
Ok, sounds good.
Gary
> > - Use Java 5
>
> +1 - may perhaps affect some end-users, but 1.5 offers lots of benefits
>
> > - Use JUnit 4
>
> +1 - does not affect end-user
>
> > What else? Thoughts?
> >
> > Thank you,
> > Gary
> > --
> > http://garygregory.wordpress.com/
> > http://garygregory.com/
> > http://people.apache.org/~ggregory/
> > http://twitter.com/GaryGregory
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
Re: [codec] Moving on to codec 2.0
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Sun, Apr 3, 2011 at 9:35 PM, Gary Gregory <ga...@gmail.com> wrote:
> What about dropping deprecated items? That should be OK in a 2.0. I was
> planning on doing that today.
>
> That does not preserve drop-in reverse compatibility but we do it in major
> releases.
First step to binary incompatibility, which I suggested. :-)
--
I Am What I Am And That's All What I Yam (Popeye)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] Moving on to codec 2.0
Posted by sebb <se...@gmail.com>.
On 3 April 2011 20:35, Gary Gregory <ga...@gmail.com> wrote:
> On Fri, Apr 1, 2011 at 2:50 AM, Jörg Schaible
> <jo...@scalaris.com>wrote:
>
>> Julius Davies wrote:
>>
>> >>> >> Nothing of this (including minimum requirement of Java 5) requires
>> >>> >> automatically 2.x. As long as the API is *upward* binary compatible,
>> >>> >> you can
>> >>> >> improve the implementation using this features, adding new methods
>> or
>> >>> new
>> >>> >> classes. Even generics can be added to some extend in a binary
>> >>> compatible
>> >>> >> way. This has been done for dbcp and there we deliver due to JDBC
>> 3/4
>> >>> even
>> >>> >> two versions.
>> >>> >>
>> >>> >
>> >>> > I feels like jumping to Java 5 is important enough to go to calling
>> it
>> >>> 2.0.
>> >>>
>> >>> +1 agreed; it's a non-trivial change to introduce generics.
>> >>>
>> >>> > We could keep it 1.6 until something breaks...
>> >>>
>> >>> Dunno what you mean by that.
>> >>>
>> >>
>> >> I thought that we could call it 1.6 until a break in API would justify
>> >> 2.0.
>> >>
>> >> But, nevermind, because I think we all agree on calling it 2.0 with Java
>> >> 5.
>> >>
>> >> Gary
>> >>
>> >>
>> >
>> > Or let's use Sun style versioning, and call the next version 6.0 !!!
>> > (while still calling it 1.6 in the tag...)
>> >
>> > ;-) ;-) ;-)
>> >
>> > ps. Just to avoid confusion with my silly joke, I am +1 to Java5 and
>> > calling it 2.0 and trying our utmost to preserve drop-in reverse
>> > compatibility.
>>
>> fine, just don't drop this last requirement light-heartedly ;-)
>>
>
> What about dropping deprecated items? That should be OK in a 2.0. I was
> planning on doing that today.
>
> That does not preserve drop-in reverse compatibility but we do it in major
> releases.
AFAIK, this means changing Maven id and package name.
>
> Gary
>
>
>> - Jörg
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> Thank you,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] Moving on to codec 2.0
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Apr 1, 2011 at 2:50 AM, Jörg Schaible
<jo...@scalaris.com>wrote:
> Julius Davies wrote:
>
> >>> >> Nothing of this (including minimum requirement of Java 5) requires
> >>> >> automatically 2.x. As long as the API is *upward* binary compatible,
> >>> >> you can
> >>> >> improve the implementation using this features, adding new methods
> or
> >>> new
> >>> >> classes. Even generics can be added to some extend in a binary
> >>> compatible
> >>> >> way. This has been done for dbcp and there we deliver due to JDBC
> 3/4
> >>> even
> >>> >> two versions.
> >>> >>
> >>> >
> >>> > I feels like jumping to Java 5 is important enough to go to calling
> it
> >>> 2.0.
> >>>
> >>> +1 agreed; it's a non-trivial change to introduce generics.
> >>>
> >>> > We could keep it 1.6 until something breaks...
> >>>
> >>> Dunno what you mean by that.
> >>>
> >>
> >> I thought that we could call it 1.6 until a break in API would justify
> >> 2.0.
> >>
> >> But, nevermind, because I think we all agree on calling it 2.0 with Java
> >> 5.
> >>
> >> Gary
> >>
> >>
> >
> > Or let's use Sun style versioning, and call the next version 6.0 !!!
> > (while still calling it 1.6 in the tag...)
> >
> > ;-) ;-) ;-)
> >
> > ps. Just to avoid confusion with my silly joke, I am +1 to Java5 and
> > calling it 2.0 and trying our utmost to preserve drop-in reverse
> > compatibility.
>
> fine, just don't drop this last requirement light-heartedly ;-)
>
What about dropping deprecated items? That should be OK in a 2.0. I was
planning on doing that today.
That does not preserve drop-in reverse compatibility but we do it in major
releases.
Gary
> - Jörg
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
Re: [codec] Moving on to codec 2.0
Posted by Jörg Schaible <jo...@scalaris.com>.
Julius Davies wrote:
>>> >> Nothing of this (including minimum requirement of Java 5) requires
>>> >> automatically 2.x. As long as the API is *upward* binary compatible,
>>> >> you can
>>> >> improve the implementation using this features, adding new methods or
>>> new
>>> >> classes. Even generics can be added to some extend in a binary
>>> compatible
>>> >> way. This has been done for dbcp and there we deliver due to JDBC 3/4
>>> even
>>> >> two versions.
>>> >>
>>> >
>>> > I feels like jumping to Java 5 is important enough to go to calling it
>>> 2.0.
>>>
>>> +1 agreed; it's a non-trivial change to introduce generics.
>>>
>>> > We could keep it 1.6 until something breaks...
>>>
>>> Dunno what you mean by that.
>>>
>>
>> I thought that we could call it 1.6 until a break in API would justify
>> 2.0.
>>
>> But, nevermind, because I think we all agree on calling it 2.0 with Java
>> 5.
>>
>> Gary
>>
>>
>
> Or let's use Sun style versioning, and call the next version 6.0 !!!
> (while still calling it 1.6 in the tag...)
>
> ;-) ;-) ;-)
>
> ps. Just to avoid confusion with my silly joke, I am +1 to Java5 and
> calling it 2.0 and trying our utmost to preserve drop-in reverse
> compatibility.
fine, just don't drop this last requirement light-heartedly ;-)
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] Moving on to codec 2.0
Posted by Julius Davies <ju...@gmail.com>.
>> >> Nothing of this (including minimum requirement of Java 5) requires
>> >> automatically 2.x. As long as the API is *upward* binary compatible, you
>> >> can
>> >> improve the implementation using this features, adding new methods or
>> new
>> >> classes. Even generics can be added to some extend in a binary
>> compatible
>> >> way. This has been done for dbcp and there we deliver due to JDBC 3/4
>> even
>> >> two versions.
>> >>
>> >
>> > I feels like jumping to Java 5 is important enough to go to calling it
>> 2.0.
>>
>> +1 agreed; it's a non-trivial change to introduce generics.
>>
>> > We could keep it 1.6 until something breaks...
>>
>> Dunno what you mean by that.
>>
>
> I thought that we could call it 1.6 until a break in API would justify 2.0.
>
> But, nevermind, because I think we all agree on calling it 2.0 with Java 5.
>
> Gary
>
>
Or let's use Sun style versioning, and call the next version 6.0 !!!
(while still calling it 1.6 in the tag...)
;-) ;-) ;-)
ps. Just to avoid confusion with my silly joke, I am +1 to Java5 and
calling it 2.0 and trying our utmost to preserve drop-in reverse
compatibility.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] Moving on to codec 2.0
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Mar 31, 2011 at 9:36 PM, sebb <se...@gmail.com> wrote:
> On 1 April 2011 01:40, Gary Gregory <ga...@gmail.com> wrote:
> > On Thu, Mar 31, 2011 at 5:12 PM, Jörg Schaible <joerg.schaible@gmx.de
> >wrote:
> >
> >> Hi Jochen,
> >>
> >> Jochen Wiedmann wrote:
> >>
> >> > On Thu, Mar 31, 2011 at 9:23 PM, Julius Davies <
> juliusdavies@gmail.com>
> >> > wrote:
> >> >
> >> >> I'm confused. We support streaming for Base64 since codec-1.4 (and
> >> >> now Base32 since codec-1.5). You committed the Base64InputStream
> >> >> patch, Jochen!
> >> >>
> >> >> https://issues.apache.org/jira/browse/CODEC-69
> >> >>
> >> >> Is there other streaming you would like to see in commons-codec?
> >> >
> >> >
> >> > Sure, you still dropped a lot of functionality when copying the stuff
> >> > from ws-commons. The Encoder and Decoder classes from ws-commons are
> >> > way more abstract and generic than the current codec stuff is and the
> >> > SAXEncoder is just one example where this is actually useful. Not to
> >> > mention StAX, NIO, and a lot of other places where streaming codecs
> >> > might be useful.
> >>
> >> Nothing of this (including minimum requirement of Java 5) requires
> >> automatically 2.x. As long as the API is *upward* binary compatible, you
> >> can
> >> improve the implementation using this features, adding new methods or
> new
> >> classes. Even generics can be added to some extend in a binary
> compatible
> >> way. This has been done for dbcp and there we deliver due to JDBC 3/4
> even
> >> two versions.
> >>
> >
> > I feels like jumping to Java 5 is important enough to go to calling it
> 2.0.
>
> +1 agreed; it's a non-trivial change to introduce generics.
>
> > We could keep it 1.6 until something breaks...
>
> Dunno what you mean by that.
>
I thought that we could call it 1.6 until a break in API would justify 2.0.
But, nevermind, because I think we all agree on calling it 2.0 with Java 5.
Gary
> > Gary
> >
> >
> >> Therefore is the question of Sebb not so limiting as you seem to imply.
> >>
> >> - Jörg
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> > --
> > Thank you,
> > Gary
> >
> > http://garygregory.wordpress.com/
> > http://garygregory.com/
> > http://people.apache.org/~ggregory/
> > http://twitter.com/GaryGregory
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
Re: [codec] Moving on to codec 2.0
Posted by sebb <se...@gmail.com>.
On 1 April 2011 01:40, Gary Gregory <ga...@gmail.com> wrote:
> On Thu, Mar 31, 2011 at 5:12 PM, Jörg Schaible <jo...@gmx.de>wrote:
>
>> Hi Jochen,
>>
>> Jochen Wiedmann wrote:
>>
>> > On Thu, Mar 31, 2011 at 9:23 PM, Julius Davies <ju...@gmail.com>
>> > wrote:
>> >
>> >> I'm confused. We support streaming for Base64 since codec-1.4 (and
>> >> now Base32 since codec-1.5). You committed the Base64InputStream
>> >> patch, Jochen!
>> >>
>> >> https://issues.apache.org/jira/browse/CODEC-69
>> >>
>> >> Is there other streaming you would like to see in commons-codec?
>> >
>> >
>> > Sure, you still dropped a lot of functionality when copying the stuff
>> > from ws-commons. The Encoder and Decoder classes from ws-commons are
>> > way more abstract and generic than the current codec stuff is and the
>> > SAXEncoder is just one example where this is actually useful. Not to
>> > mention StAX, NIO, and a lot of other places where streaming codecs
>> > might be useful.
>>
>> Nothing of this (including minimum requirement of Java 5) requires
>> automatically 2.x. As long as the API is *upward* binary compatible, you
>> can
>> improve the implementation using this features, adding new methods or new
>> classes. Even generics can be added to some extend in a binary compatible
>> way. This has been done for dbcp and there we deliver due to JDBC 3/4 even
>> two versions.
>>
>
> I feels like jumping to Java 5 is important enough to go to calling it 2.0.
+1 agreed; it's a non-trivial change to introduce generics.
> We could keep it 1.6 until something breaks...
Dunno what you mean by that.
> Gary
>
>
>> Therefore is the question of Sebb not so limiting as you seem to imply.
>>
>> - Jörg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> Thank you,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] Moving on to codec 2.0
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Mar 31, 2011 at 5:12 PM, Jörg Schaible <jo...@gmx.de>wrote:
> Hi Jochen,
>
> Jochen Wiedmann wrote:
>
> > On Thu, Mar 31, 2011 at 9:23 PM, Julius Davies <ju...@gmail.com>
> > wrote:
> >
> >> I'm confused. We support streaming for Base64 since codec-1.4 (and
> >> now Base32 since codec-1.5). You committed the Base64InputStream
> >> patch, Jochen!
> >>
> >> https://issues.apache.org/jira/browse/CODEC-69
> >>
> >> Is there other streaming you would like to see in commons-codec?
> >
> >
> > Sure, you still dropped a lot of functionality when copying the stuff
> > from ws-commons. The Encoder and Decoder classes from ws-commons are
> > way more abstract and generic than the current codec stuff is and the
> > SAXEncoder is just one example where this is actually useful. Not to
> > mention StAX, NIO, and a lot of other places where streaming codecs
> > might be useful.
>
> Nothing of this (including minimum requirement of Java 5) requires
> automatically 2.x. As long as the API is *upward* binary compatible, you
> can
> improve the implementation using this features, adding new methods or new
> classes. Even generics can be added to some extend in a binary compatible
> way. This has been done for dbcp and there we deliver due to JDBC 3/4 even
> two versions.
>
I feels like jumping to Java 5 is important enough to go to calling it 2.0.
We could keep it 1.6 until something breaks...
Gary
> Therefore is the question of Sebb not so limiting as you seem to imply.
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
Re: [codec] Moving on to codec 2.0
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Jochen,
Jochen Wiedmann wrote:
> On Thu, Mar 31, 2011 at 9:23 PM, Julius Davies <ju...@gmail.com>
> wrote:
>
>> I'm confused. We support streaming for Base64 since codec-1.4 (and
>> now Base32 since codec-1.5). You committed the Base64InputStream
>> patch, Jochen!
>>
>> https://issues.apache.org/jira/browse/CODEC-69
>>
>> Is there other streaming you would like to see in commons-codec?
>
>
> Sure, you still dropped a lot of functionality when copying the stuff
> from ws-commons. The Encoder and Decoder classes from ws-commons are
> way more abstract and generic than the current codec stuff is and the
> SAXEncoder is just one example where this is actually useful. Not to
> mention StAX, NIO, and a lot of other places where streaming codecs
> might be useful.
Nothing of this (including minimum requirement of Java 5) requires
automatically 2.x. As long as the API is *upward* binary compatible, you can
improve the implementation using this features, adding new methods or new
classes. Even generics can be added to some extend in a binary compatible
way. This has been done for dbcp and there we deliver due to JDBC 3/4 even
two versions.
Therefore is the question of Sebb not so limiting as you seem to imply.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] Moving on to codec 2.0
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Thu, Mar 31, 2011 at 9:23 PM, Julius Davies <ju...@gmail.com> wrote:
> I'm confused. We support streaming for Base64 since codec-1.4 (and
> now Base32 since codec-1.5). You committed the Base64InputStream
> patch, Jochen!
>
> https://issues.apache.org/jira/browse/CODEC-69
>
> Is there other streaming you would like to see in commons-codec?
Sure, you still dropped a lot of functionality when copying the stuff
from ws-commons. The Encoder and Decoder classes from ws-commons are
way more abstract and generic than the current codec stuff is and the
SAXEncoder is just one example where this is actually useful. Not to
mention StAX, NIO, and a lot of other places where streaming codecs
might be useful.
Jochen
--
I Am What I Am And That's All What I Yam (Popeye)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] Moving on to codec 2.0
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Mar 31, 2011 at 3:23 PM, Julius Davies <ju...@gmail.com>wrote:
> On Wed, Mar 30, 2011 at 4:28 PM, sebb <se...@gmail.com> wrote:
> > On 31 March 2011 00:17, Jochen Wiedmann <jo...@gmail.com>
> wrote:
> >> On Wed, Mar 30, 2011 at 7:04 PM, sebb <se...@gmail.com> wrote:
> >>
> >>> But does the API have to change, or could these additional features be
> >>> supported by adding new methods and classes?
> >>
> >> Not necessarily. But my point is that codec is in a state where
> >> breaking the API will make work just easier. So why not take the
> >> opportunity?
> >
> > Because making work easier for a few developers has to be balanced
> > against making more work for lots of users.
> >
>
>
> I'm confused. We support streaming for Base64 since codec-1.4 (and
> now Base32 since codec-1.5). You committed the Base64InputStream
> patch, Jochen!
>
> https://issues.apache.org/jira/browse/CODEC-69
>
> Is there other streaming you would like to see in commons-codec?
>
> As for a 2.0 branch, even though the numbering (2.0) implies a break
> with reverse-compatibility, I still urge us to hesitate before
> breaking drop in reverse-compatibility. I agree with Sebb in this
> case. I think strong drop in reverse-compatibility is particularly
> welcome in cases like commons-codec: small, foundational,
> zero-dependency libraries, that are used everywhere!
>
> As for Java 5.0, sure go for it. Doesn't really benefit commons-codec
> that much, but doesn't hurt, either.
>
> As for JUnit 4.0, yes! Doesn't hurt any end users.
>
And JUnit 4 requires Java 5.
Gary
>
>
>
> --
> yours,
>
> Julius Davies
> 250-592-2284 (Home)
>
> $ sudo apt-get install cowsay
> $ echo "Moo." | cowsay | cowsay -n | cowsay -n
> http://juliusdavies.ca/cowsay/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
Re: [codec] Moving on to codec 2.0
Posted by Julius Davies <ju...@gmail.com>.
On Wed, Mar 30, 2011 at 4:28 PM, sebb <se...@gmail.com> wrote:
> On 31 March 2011 00:17, Jochen Wiedmann <jo...@gmail.com> wrote:
>> On Wed, Mar 30, 2011 at 7:04 PM, sebb <se...@gmail.com> wrote:
>>
>>> But does the API have to change, or could these additional features be
>>> supported by adding new methods and classes?
>>
>> Not necessarily. But my point is that codec is in a state where
>> breaking the API will make work just easier. So why not take the
>> opportunity?
>
> Because making work easier for a few developers has to be balanced
> against making more work for lots of users.
>
I'm confused. We support streaming for Base64 since codec-1.4 (and
now Base32 since codec-1.5). You committed the Base64InputStream
patch, Jochen!
https://issues.apache.org/jira/browse/CODEC-69
Is there other streaming you would like to see in commons-codec?
As for a 2.0 branch, even though the numbering (2.0) implies a break
with reverse-compatibility, I still urge us to hesitate before
breaking drop in reverse-compatibility. I agree with Sebb in this
case. I think strong drop in reverse-compatibility is particularly
welcome in cases like commons-codec: small, foundational,
zero-dependency libraries, that are used everywhere!
As for Java 5.0, sure go for it. Doesn't really benefit commons-codec
that much, but doesn't hurt, either.
As for JUnit 4.0, yes! Doesn't hurt any end users.
--
yours,
Julius Davies
250-592-2284 (Home)
$ sudo apt-get install cowsay
$ echo "Moo." | cowsay | cowsay -n | cowsay -n
http://juliusdavies.ca/cowsay/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] Moving on to codec 2.0
Posted by sebb <se...@gmail.com>.
On 31 March 2011 00:17, Jochen Wiedmann <jo...@gmail.com> wrote:
> On Wed, Mar 30, 2011 at 7:04 PM, sebb <se...@gmail.com> wrote:
>
>> But does the API have to change, or could these additional features be
>> supported by adding new methods and classes?
>
> Not necessarily. But my point is that codec is in a state where
> breaking the API will make work just easier. So why not take the
> opportunity?
Because making work easier for a few developers has to be balanced
against making more work for lots of users.
>
> --
> I Am What I Am And That's All What I Yam (Popeye)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] Moving on to codec 2.0
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Wed, Mar 30, 2011 at 7:04 PM, sebb <se...@gmail.com> wrote:
> But does the API have to change, or could these additional features be
> supported by adding new methods and classes?
Not necessarily. But my point is that codec is in a state where
breaking the API will make work just easier. So why not take the
opportunity?
--
I Am What I Am And That's All What I Yam (Popeye)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] Moving on to codec 2.0
Posted by sebb <se...@gmail.com>.
On 30 March 2011 16:19, Jochen Wiedmann <jo...@gmail.com> wrote:
> On Tue, Mar 29, 2011 at 8:52 PM, sebb <se...@gmail.com> wrote:
>
>> I think that should be avoided unless the API is also being changed in
>> an incompatible way, and then only if it really is impossible to
>> maintain backwards compatibility.
>
> I think there are excellent reasons to change the API in codec.
> Reasons include lack of support for streaming in most cases, lack of
> support for integration in SAX or StAX streams and the like, which
> could be relatively easy with standard interfaces. Take, for example,
>
> http://www.jarvana.com/jarvana/view/org/apache/ws/commons/util/ws-commons-util/1.0.2/ws-commons-util-1.0.2-javadoc.jar!/org/apache/ws/commons/util/Base64.html
>
But does the API have to change, or could these additional features be
supported by adding new methods and classes?
For example, I originally thought that the fixes to Net NNTP to
support long article Ids would require a compatibilty break, as ints
were used throughout, but having done the work it turned out that
compatibility could be maintained by adding one or two new classes,
and some new methods. Users wanting to use the new methods will of
course have to edit and recompile, but other Net users won't be
affected.
>
> --
> I Am What I Am And That's All What I Yam (Popeye)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] Moving on to codec 2.0
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Tue, Mar 29, 2011 at 8:52 PM, sebb <se...@gmail.com> wrote:
> I think that should be avoided unless the API is also being changed in
> an incompatible way, and then only if it really is impossible to
> maintain backwards compatibility.
I think there are excellent reasons to change the API in codec.
Reasons include lack of support for streaming in most cases, lack of
support for integration in SAX or StAX streams and the like, which
could be relatively easy with standard interfaces. Take, for example,
http://www.jarvana.com/jarvana/view/org/apache/ws/commons/util/ws-commons-util/1.0.2/ws-commons-util-1.0.2-javadoc.jar!/org/apache/ws/commons/util/Base64.html
--
I Am What I Am And That's All What I Yam (Popeye)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] Moving on to codec 2.0
Posted by sebb <se...@gmail.com>.
On 29 March 2011 18:44, Gary Gregory <ga...@gmail.com> wrote:
> Hi All,
>
> Now that codec 1.5 is out, I would like thoughts on this plan for codec 2.0:
>
> - Create a SVN branch for 1.x
>
> Then in trunk:
> - Correct Maven group id, which implies:
-1, see below.
> - Repackage to o.a.c.codec2
This forces all end-users to edit their source and recompile.
I think that should be avoided unless the API is also being changed in
an incompatible way, and then only if it really is impossible to
maintain backwards compatibility.
> - Use Java 5
+1 - may perhaps affect some end-users, but 1.5 offers lots of benefits
> - Use JUnit 4
+1 - does not affect end-user
> What else? Thoughts?
>
> Thank you,
> Gary
> --
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] Moving on to codec 2.0
Posted by Henri Yandell <fl...@gmail.com>.
+1 to all of the below.
The lesson from Lang imo is to charge in and just do it. It'll
generate ideas once people are free to consider backwards incompatible
changes. Rolling back is always possible if we decide we didn't really
justify a 2.0.
Look at what else is out there. Is the scope of Codec correct, are
there things that should be added to the scope. Is there other useful
code that can be included.
Hen
On Tue, Mar 29, 2011 at 10:44 AM, Gary Gregory <ga...@gmail.com> wrote:
> Hi All,
>
> Now that codec 1.5 is out, I would like thoughts on this plan for codec 2.0:
>
> - Create a SVN branch for 1.x
>
> Then in trunk:
> - Correct Maven group id, which implies:
> - Repackage to o.a.c.codec2
> - Use Java 5
> - Use JUnit 4
>
> What else? Thoughts?
>
> Thank you,
> Gary
> --
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org