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 2016/05/06 21:40:14 UTC
[VFS] BC breaks in VFS 2.1 RC1
I'm creating a new thread here instead of hijacking the VOTE thread.
First, let me express my gratitude to Stian Soiland-Reyes for RM'ing a
release, I'm sure he did not know what he was getting himself into! ;-)
Part of me writing this here is flushing out for myself, voters, and casual
observers what it is we are doing ;-)
We have BC breakage in VFS 2.1 RC1 in two areas:
- Adding methods to public interfaces
- Other stuff like removing fields, changing fields from protected to
private, changing method arg types.
Details:
https://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html
I see three areas that need consideration:
(0) For simple clients that only use the higher-level interfaces and
methods, there are no problems. So this is a non-issue marker I suppose.
(1) For advanced clients that get their fingers in deep into VFS, they
break. Example:
- org.apache.commons.vfs2.provider.tar.TarFileObject: Accessibility of
field entry has been weakened from protected to private.
- org.apache.commons.vfs2.provider.webdav.WebdavFileProvider: Removed field
AUTHENTICATOR_TYPES
- and so on.
Remedies for these kinds of breaks are simple and easy: Just change stuff
back and mark @deprecated in Javadoc and @Deprecated.
(2) For providers, they break unless they extend our root classes like
AbstractFileObject and DefaultFileSystemManager, and use our default
classes like DefaultFileContent.
For "simple" providers, there probably won't be any issue, but who knows?
Does anyone have a 2.0 provider?
For advanced providers that do more of their own thing instead of reusing
our base classes, then breakage.
It seems to me that we should pick the low-hanging fruits and fix the
simple stuff.
All of this is moot if we were to go to 3.0 now.
Thoughts?
Gary
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [VFS] BC breaks in VFS 2.1 RC1
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, May 6, 2016 at 3:00 PM, sebb <se...@gmail.com> wrote:
> On 6 May 2016 at 22:40, Gary Gregory <ga...@gmail.com> wrote:
> > I'm creating a new thread here instead of hijacking the VOTE thread.
> >
> > First, let me express my gratitude to Stian Soiland-Reyes for RM'ing a
> > release, I'm sure he did not know what he was getting himself into! ;-)
>
> Huh? ... that was/is Josh Elser.
> Who does (also) deserve many thanks.
>
Applogies Josh, I'm mixing me threads!
Gary
>
> > Part of me writing this here is flushing out for myself, voters, and
> casual
> > observers what it is we are doing ;-)
> >
> > We have BC breakage in VFS 2.1 RC1 in two areas:
> >
> > - Adding methods to public interfaces
>
> AFAIK that is only a SOURCE breakage.
>
> > - Other stuff like removing fields, changing fields from protected to
> > private, changing method arg types.
>
> That does break BC if the objects are part of the public API.
>
> > Details:
> >
> https://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html
> >
> > I see three areas that need consideration:
> >
> > (0) For simple clients that only use the higher-level interfaces and
> > methods, there are no problems. So this is a non-issue marker I suppose.
>
> Whether or not that affects simple clients depends on exactly which
> fields and method args have changed. Are they part of the public API?
> And if so, will simple clients use that part of the API?
>
> > (1) For advanced clients that get their fingers in deep into VFS, they
> > break. Example:
> >
> > - org.apache.commons.vfs2.provider.tar.TarFileObject: Accessibility of
> > field entry has been weakened from protected to private.
> > - org.apache.commons.vfs2.provider.webdav.WebdavFileProvider: Removed
> field
> > AUTHENTICATOR_TYPES
> > - and so on.
> >
> > Remedies for these kinds of breaks are simple and easy: Just change stuff
> > back and mark @deprecated in Javadoc and @Deprecated.
> >
> > (2) For providers, they break unless they extend our root classes like
> > AbstractFileObject and DefaultFileSystemManager, and use our default
> > classes like DefaultFileContent.
> > For "simple" providers, there probably won't be any issue, but who knows?
> > Does anyone have a 2.0 provider?
> > For advanced providers that do more of their own thing instead of reusing
> > our base classes, then breakage.
> >
> > It seems to me that we should pick the low-hanging fruits and fix the
> > simple stuff.
> >
> > All of this is moot if we were to go to 3.0 now.
>
> Which would not be source or binary compatible by design.
>
> > Thoughts?
>
> The easiest for Commons would obviously be to abandon 2.x and release 3.0.
> That would be a chance to fix APIs properly.
>
> However, given the work that Josh has already put into 2.1 that seems
> a waste of effort if we can either:
> - eliminate the BC breaks, OR
> - satisfy ourselves that the breaks will not affect (m)any users.
>
> > Gary
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > Java Persistence with Hibernate, Second Edition
> > <http://www.manning.com/bauer3/>
> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > Spring Batch in Action <http://www.manning.com/templier/>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [VFS] BC breaks in VFS 2.1 RC1
Posted by Jörg Schaible <jo...@gmx.de>.
sebb wrote:
> On 6 May 2016 at 22:40, Gary Gregory <ga...@gmail.com> wrote:
>> I'm creating a new thread here instead of hijacking the VOTE thread.
>>
>> First, let me express my gratitude to Stian Soiland-Reyes for RM'ing a
>> release, I'm sure he did not know what he was getting himself into! ;-)
>
> Huh? ... that was/is Josh Elser.
> Who does (also) deserve many thanks.
[snip]
> However, given the work that Josh has already put into 2.1 that seems
> a waste of effort if we can either:
> - eliminate the BC breaks, OR
> - satisfy ourselves that the breaks will not affect (m)any users.
In the case of vfs I can live with the latter.
- J�rg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VFS] BC breaks in VFS 2.1 RC1
Posted by Josh Elser <el...@apache.org>.
(catching up)
Thanks for writing this note, Sebb. It completely aligns with my
opinion. In the docs from Oracle which you earlier linked, method
additions *do not* break binary compatibility. I'm a little confused why
this is being brought up for at least a second time now (could have been
third).
sebb wrote:
> I have just looked again at the Clirr errors.
>
> Apart from the interface method additions, the changes are:
>
> *) Replacing org.apache.commons.vfs2.provider.tar.TarEntry by
> org.apache.commons.compress.archivers.tar.TarArchiveEntry in several
> places.
>
> TarEntry has been dropped, however the class was package-private so it
> was clearly not part of the public API.
> And likewise, methods using cannot have been part of the API.
>
> *) replacing org.apache.commons.vfs2.provider.tar.TarInputStream by
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream as the
> return type for a couple of methods
>
> Again, TarInputStream has been dropped, and it was also
> package-private. So again the public API must be OK.
>
> So I think we are OK as far as BC is concerned.
>
> Source will need to be updated if it uses any of the interfaces that
> have been updated:
> FileContent
> FileName
> FileObject
> FileSystemManager
> RandomAccessContent
>
> If there may be another 2.x release, we should make sure that the
> interfaces have suitable abstract class implementations that can be
> extended instead of implementing the interface.
> Then external source will only need to be updated once.
>
> Assuming others agree with my analysis, these findings need to be
> documented in the RN.
>
>
> On 7 May 2016 at 06:29, Gary Gregory<ga...@gmail.com> wrote:
>> On Fri, May 6, 2016 at 10:20 PM, Ralph Goers<ra...@dslextreme.com>
>> wrote:
>>
>>> That was me. I have had those thoughts and mentioned them a few times
>>> since Java 7 was released. But absolutely no effort has been expended to do
>>> it.
>>>
>>> My personal opinion is that I am comfortable with releasing 2.1 with the
>>> issues Gary mentions. There should have been 10 releases for VFS 2 by now.
>>>
>> Well, yeah, RERO would have been great but it was not on high enough on my
>> priority list too ;-) The issue we have now would have popped each time we
>> wanted to break BC, so we could have gotten a better feel for it with RERO
>> and 10 VFS 2.x releases under our belts! But we are stuck with a Big Bang
>> release now.
>>
>> I would request another RC from the RM, and let the community decide by
>> VOTE.
>>
>> Gary
>>
>>> Ralph
>>>
>>>> On May 6, 2016, at 8:40 PM, Matt Sicker<bo...@gmail.com> wrote:
>>>>
>>>> I thought there were talks about using Java 1.7 APIs in 3.0 that would
>>>> eliminate the need for some classes in commons-vfs, or am I confusing
>>> that
>>>> with another commons project?
>>>>
>>>> On 6 May 2016 at 17:46, Gary Gregory<ga...@gmail.com> wrote:
>>>>
>>>>> OK, I've gone through the Clirr report and fixed the low-hanging fruits
>>> in
>>>>> trunk. I think we need another RC. I've also update Apache Commons
>>> Compress
>>>>> and Net to their current versions.
>>>>>
>>>>> Then what we have to live with for 2.1 is BC breaks in two narrower
>>> areas:
>>>>> - Added methods to interfaces.
>>>>> - Changes in the Tar classes from our own Tar classes to Apache Commons
>>>>> Compress' Tar classes.
>>>>>
>>>>> That's how good it's going to get for now IMO.
>>>>>
>>>>> I would be perfectly OK with repackaging for 3.0 but then this would
>>> open
>>>>> the door to other changes that folks might want to make. I would be OK
>>> with
>>>>> saying this is 3.0 as is in this case.
>>>>>
>>>>> I'm still not 100% comfortable with the BC based on my experience with
>>>>> large projects with deep transitive dependencies.
>>>>>
>>>>> If the community VOTEs to release trunk (yes, another RC please) as 2.1
>>>>> then I'll live with it. Releasing as 3.0 (as is) would be safe and
>>>>> conservative.
>>>>>
>>>>> Gary
>>>>>
>>>>> On Fri, May 6, 2016 at 3:00 PM, sebb<se...@gmail.com> wrote:
>>>>>
>>>>>> On 6 May 2016 at 22:40, Gary Gregory<ga...@gmail.com> wrote:
>>>>>>> I'm creating a new thread here instead of hijacking the VOTE thread.
>>>>>>>
>>>>>>> First, let me express my gratitude to Stian Soiland-Reyes for RM'ing a
>>>>>>> release, I'm sure he did not know what he was getting himself into!
>>> ;-)
>>>>>> Huh? ... that was/is Josh Elser.
>>>>>> Who does (also) deserve many thanks.
>>>>>>
>>>>>>> Part of me writing this here is flushing out for myself, voters, and
>>>>>> casual
>>>>>>> observers what it is we are doing ;-)
>>>>>>>
>>>>>>> We have BC breakage in VFS 2.1 RC1 in two areas:
>>>>>>>
>>>>>>> - Adding methods to public interfaces
>>>>>> AFAIK that is only a SOURCE breakage.
>>>>>>
>>>>>>> - Other stuff like removing fields, changing fields from protected to
>>>>>>> private, changing method arg types.
>>>>>> That does break BC if the objects are part of the public API.
>>>>>>
>>>>>>> Details:
>>>>>>>
>>> https://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html
>>>>>>> I see three areas that need consideration:
>>>>>>>
>>>>>>> (0) For simple clients that only use the higher-level interfaces and
>>>>>>> methods, there are no problems. So this is a non-issue marker I
>>>>> suppose.
>>>>>> Whether or not that affects simple clients depends on exactly which
>>>>>> fields and method args have changed. Are they part of the public API?
>>>>>> And if so, will simple clients use that part of the API?
>>>>>>
>>>>>>> (1) For advanced clients that get their fingers in deep into VFS, they
>>>>>>> break. Example:
>>>>>>>
>>>>>>> - org.apache.commons.vfs2.provider.tar.TarFileObject: Accessibility of
>>>>>>> field entry has been weakened from protected to private.
>>>>>>> - org.apache.commons.vfs2.provider.webdav.WebdavFileProvider: Removed
>>>>>> field
>>>>>>> AUTHENTICATOR_TYPES
>>>>>>> - and so on.
>>>>>>>
>>>>>>> Remedies for these kinds of breaks are simple and easy: Just change
>>>>> stuff
>>>>>>> back and mark @deprecated in Javadoc and @Deprecated.
>>>>>>>
>>>>>>> (2) For providers, they break unless they extend our root classes like
>>>>>>> AbstractFileObject and DefaultFileSystemManager, and use our default
>>>>>>> classes like DefaultFileContent.
>>>>>>> For "simple" providers, there probably won't be any issue, but who
>>>>> knows?
>>>>>>> Does anyone have a 2.0 provider?
>>>>>>> For advanced providers that do more of their own thing instead of
>>>>> reusing
>>>>>>> our base classes, then breakage.
>>>>>>>
>>>>>>> It seems to me that we should pick the low-hanging fruits and fix the
>>>>>>> simple stuff.
>>>>>>>
>>>>>>> All of this is moot if we were to go to 3.0 now.
>>>>>> Which would not be source or binary compatible by design.
>>>>>>
>>>>>>> Thoughts?
>>>>>> The easiest for Commons would obviously be to abandon 2.x and release
>>>>> 3.0.
>>>>>> That would be a chance to fix APIs properly.
>>>>>>
>>>>>> However, given the work that Josh has already put into 2.1 that seems
>>>>>> a waste of effort if we can either:
>>>>>> - eliminate the BC breaks, OR
>>>>>> - satisfy ourselves that the breaks will not affect (m)any users.
>>>>>>
>>>>>>> Gary
>>>>>>> --
>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>> JUnit in Action, Second Edition<http://www.manning.com/tahchiev/>
>>>>>>> Spring Batch in Action<http://www.manning.com/templier/>
>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>> Home: http://garygregory.com/
>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> Java Persistence with Hibernate, Second Edition
>>>>> <http://www.manning.com/bauer3/>
>>>>> JUnit in Action, Second Edition<http://www.manning.com/tahchiev/>
>>>>> Spring Batch in Action<http://www.manning.com/templier/>
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker<bo...@gmail.com>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition<http://www.manning.com/tahchiev/>
>> Spring Batch in Action<http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> 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: [VFS] BC breaks in VFS 2.1 RC1
Posted by Josh Elser <el...@apache.org>.
Oh, you did? I thought I did an update before I sent my last email and
didn't see any changes from you. Perhaps I just missed it then :)
Gary Gregory wrote:
> Hi,
>
> I am sorry for not being clearer. I've already updated trunk with 'as good
> as it gets for now' code. These are the low-hanging fruit changes I wrote
> about plus updates to the latest Commons Net and IO IIRC (on my phone now).
>
> I would like a new RC to pick up these changes, see my other email(s).
>
> Gary
> On May 8, 2016 11:50 AM, "Josh Elser"<el...@apache.org> wrote:
>
>> Gary -- how quickly can you turn around a patch to fix this? Without a
>> patch, I am still in favor of 2.1 being released as is. 2.1.1 can be
>> released with these fixes at your earliest convenience.
>>
>> Gary Gregory wrote:
>>
>>> Just for completeness, I'm advocating we do this now, but new methods to
>>> interfaces could be added as subinterfaces as in FileContent2 extends
>>> FileContent.
>>>
>>> Gary
>>>
>>> On Sat, May 7, 2016 at 2:52 AM, sebb<se...@gmail.com> wrote:
>>>
>>> I have just looked again at the Clirr errors.
>>>> Apart from the interface method additions, the changes are:
>>>>
>>>> *) Replacing org.apache.commons.vfs2.provider.tar.TarEntry by
>>>> org.apache.commons.compress.archivers.tar.TarArchiveEntry in several
>>>> places.
>>>>
>>>> TarEntry has been dropped, however the class was package-private so it
>>>> was clearly not part of the public API.
>>>> And likewise, methods using cannot have been part of the API.
>>>>
>>>> *) replacing org.apache.commons.vfs2.provider.tar.TarInputStream by
>>>> org.apache.commons.compress.archivers.tar.TarArchiveInputStream as the
>>>> return type for a couple of methods
>>>>
>>>> Again, TarInputStream has been dropped, and it was also
>>>> package-private. So again the public API must be OK.
>>>>
>>>> So I think we are OK as far as BC is concerned.
>>>>
>>>> Source will need to be updated if it uses any of the interfaces that
>>>> have been updated:
>>>> FileContent
>>>> FileName
>>>> FileObject
>>>> FileSystemManager
>>>> RandomAccessContent
>>>>
>>>> If there may be another 2.x release, we should make sure that the
>>>> interfaces have suitable abstract class implementations that can be
>>>> extended instead of implementing the interface.
>>>> Then external source will only need to be updated once.
>>>>
>>>> Assuming others agree with my analysis, these findings need to be
>>>> documented in the RN.
>>>>
>>>>
>>>> On 7 May 2016 at 06:29, Gary Gregory<ga...@gmail.com> wrote:
>>>>
>>>>> On Fri, May 6, 2016 at 10:20 PM, Ralph Goers<ralph.goers@dslextreme.com
>>>>>
>>>>> wrote:
>>>>>
>>>>> That was me. I have had those thoughts and mentioned them a few times
>>>>>> since Java 7 was released. But absolutely no effort has been expended
>>>>>>
>>>>> to do
>>>>> it.
>>>>>> My personal opinion is that I am comfortable with releasing 2.1 with
>>>>>> the
>>>>>> issues Gary mentions. There should have been 10 releases for VFS 2 by
>>>>>>
>>>>> now.
>>>>> Well, yeah, RERO would have been great but it was not on high enough on
>>>>>
>>>> my
>>>>
>>>>> priority list too ;-) The issue we have now would have popped each time
>>>>>
>>>> we
>>>>
>>>>> wanted to break BC, so we could have gotten a better feel for it with
>>>>>
>>>> RERO
>>>>
>>>>> and 10 VFS 2.x releases under our belts! But we are stuck with a Big
>>>>> Bang
>>>>> release now.
>>>>>
>>>>> I would request another RC from the RM, and let the community decide by
>>>>> VOTE.
>>>>>
>>>>> Gary
>>>>>
>>>>> Ralph
>>>>>> On May 6, 2016, at 8:40 PM, Matt Sicker<bo...@gmail.com> wrote:
>>>>>>> I thought there were talks about using Java 1.7 APIs in 3.0 that would
>>>>>>> eliminate the need for some classes in commons-vfs, or am I confusing
>>>>>>>
>>>>>> that
>>>>>>
>>>>>>> with another commons project?
>>>>>>>
>>>>>>> On 6 May 2016 at 17:46, Gary Gregory<ga...@gmail.com> wrote:
>>>>>>>
>>>>>>> OK, I've gone through the Clirr report and fixed the low-hanging
>>>>>>> fruits
>>>>> in
>>>>>>> trunk. I think we need another RC. I've also update Apache Commons
>>>>>>> Compress
>>>>>>> and Net to their current versions.
>>>>>>>> Then what we have to live with for 2.1 is BC breaks in two narrower
>>>>>>>>
>>>>>>> areas:
>>>>>>> - Added methods to interfaces.
>>>>>>>> - Changes in the Tar classes from our own Tar classes to Apache
>>>>>>>>
>>>>>>> Commons
>>>>> Compress' Tar classes.
>>>>>>>> That's how good it's going to get for now IMO.
>>>>>>>>
>>>>>>>> I would be perfectly OK with repackaging for 3.0 but then this would
>>>>>>>>
>>>>>>> open
>>>>>>> the door to other changes that folks might want to make. I would be
>>>>>>> OK
>>>>> with
>>>>>>> saying this is 3.0 as is in this case.
>>>>>>>> I'm still not 100% comfortable with the BC based on my experience
>>>>>>>>
>>>>>>> with
>>>>> large projects with deep transitive dependencies.
>>>>>>>> If the community VOTEs to release trunk (yes, another RC please) as
>>>>>>>>
>>>>>>> 2.1
>>>>> then I'll live with it. Releasing as 3.0 (as is) would be safe and
>>>>>>>> conservative.
>>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>> On Fri, May 6, 2016 at 3:00 PM, sebb<se...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> On 6 May 2016 at 22:40, Gary Gregory<ga...@gmail.com>
>>>>>>>> wrote:
>>>>> I'm creating a new thread here instead of hijacking the VOTE
>>>>>>>>> thread.
>>>>> First, let me express my gratitude to Stian Soiland-Reyes for
>>>>>>>>> RM'ing a
>>>>> release, I'm sure he did not know what he was getting himself into!
>>>>>>>>> ;-)
>>>>>>> Huh? ... that was/is Josh Elser.
>>>>>>>>> Who does (also) deserve many thanks.
>>>>>>>>>
>>>>>>>>> Part of me writing this here is flushing out for myself, voters,
>>>>>>>>> and
>>>>> casual
>>>>>>>>>> observers what it is we are doing ;-)
>>>>>>>>>>
>>>>>>>>>> We have BC breakage in VFS 2.1 RC1 in two areas:
>>>>>>>>>>
>>>>>>>>>> - Adding methods to public interfaces
>>>>>>>>>>
>>>>>>>>> AFAIK that is only a SOURCE breakage.
>>>>>>>>>
>>>>>>>>> - Other stuff like removing fields, changing fields from protected
>>>>>>>>> to
>>>>> private, changing method arg types.
>>>>>>>>> That does break BC if the objects are part of the public API.
>>>>>>>>>
>>>>>>>>> Details:
>>>>>>>>>>
>>>> https://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html
>>>>
>>>>> I see three areas that need consideration:
>>>>>>>>>> (0) For simple clients that only use the higher-level interfaces
>>>>>>>>>>
>>>>>>>>> and
>>>>> methods, there are no problems. So this is a non-issue marker I
>>>>>>>>> suppose.
>>>>>>>>> Whether or not that affects simple clients depends on exactly which
>>>>>>>>> fields and method args have changed. Are they part of the public
>>>>>>>>>
>>>>>>>> API?
>>>>> And if so, will simple clients use that part of the API?
>>>>>>>>> (1) For advanced clients that get their fingers in deep into VFS,
>>>>>>>>> they
>>>>> break. Example:
>>>>>>>>>> - org.apache.commons.vfs2.provider.tar.TarFileObject:
>>>>>>>>>>
>>>>>>>>> Accessibility of
>>>>> field entry has been weakened from protected to private.
>>>>>>>>>> - org.apache.commons.vfs2.provider.webdav.WebdavFileProvider:
>>>>>>>>>>
>>>>>>>>> Removed
>>>>> field
>>>>>>>>>> AUTHENTICATOR_TYPES
>>>>>>>>>> - and so on.
>>>>>>>>>>
>>>>>>>>>> Remedies for these kinds of breaks are simple and easy: Just change
>>>>>>>>>>
>>>>>>>>> stuff
>>>>>>>>> back and mark @deprecated in Javadoc and @Deprecated.
>>>>>>>>>> (2) For providers, they break unless they extend our root classes
>>>>>>>>>>
>>>>>>>>> like
>>>>> AbstractFileObject and DefaultFileSystemManager, and use our
>>>>>>>>> default
>>>>> classes like DefaultFileContent.
>>>>>>>>>> For "simple" providers, there probably won't be any issue, but who
>>>>>>>>>>
>>>>>>>>> knows?
>>>>>>>>> Does anyone have a 2.0 provider?
>>>>>>>>>> For advanced providers that do more of their own thing instead of
>>>>>>>>>>
>>>>>>>>> reusing
>>>>>>>>> our base classes, then breakage.
>>>>>>>>>> It seems to me that we should pick the low-hanging fruits and fix
>>>>>>>>>>
>>>>>>>>> the
>>>>> simple stuff.
>>>>>>>>>> All of this is moot if we were to go to 3.0 now.
>>>>>>>>>>
>>>>>>>>> Which would not be source or binary compatible by design.
>>>>>>>>>
>>>>>>>>> Thoughts?
>>>>>>>>> The easiest for Commons would obviously be to abandon 2.x and
>>>>>>>>>
>>>>>>>> release
>>>>> 3.0.
>>>>>>>>> That would be a chance to fix APIs properly.
>>>>>>>>>
>>>>>>>>> However, given the work that Josh has already put into 2.1 that
>>>>>>>>>
>>>>>>>> seems
>>>>> a waste of effort if we can either:
>>>>>>>>> - eliminate the BC breaks, OR
>>>>>>>>> - satisfy ourselves that the breaks will not affect (m)any users.
>>>>>>>>>
>>>>>>>>> Gary
>>>>>>>>>> --
>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>>>> JUnit in Action, Second Edition<http://www.manning.com/tahchiev/>
>>>>>>>>>> Spring Batch in Action<http://www.manning.com/templier/>
>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>
>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> --
>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>> JUnit in Action, Second Edition<http://www.manning.com/tahchiev/>
>>>>>>>> Spring Batch in Action<http://www.manning.com/templier/>
>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>> Home: http://garygregory.com/
>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker<bo...@gmail.com>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> Java Persistence with Hibernate, Second Edition
>>>>> <http://www.manning.com/bauer3/>
>>>>> JUnit in Action, Second Edition<http://www.manning.com/tahchiev/>
>>>>> Spring Batch in Action<http://www.manning.com/templier/>
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VFS] BC breaks in VFS 2.1 RC1
Posted by Gary Gregory <ga...@gmail.com>.
Hi,
I am sorry for not being clearer. I've already updated trunk with 'as good
as it gets for now' code. These are the low-hanging fruit changes I wrote
about plus updates to the latest Commons Net and IO IIRC (on my phone now).
I would like a new RC to pick up these changes, see my other email(s).
Gary
On May 8, 2016 11:50 AM, "Josh Elser" <el...@apache.org> wrote:
> Gary -- how quickly can you turn around a patch to fix this? Without a
> patch, I am still in favor of 2.1 being released as is. 2.1.1 can be
> released with these fixes at your earliest convenience.
>
> Gary Gregory wrote:
>
>> Just for completeness, I'm advocating we do this now, but new methods to
>> interfaces could be added as subinterfaces as in FileContent2 extends
>> FileContent.
>>
>> Gary
>>
>> On Sat, May 7, 2016 at 2:52 AM, sebb<se...@gmail.com> wrote:
>>
>> I have just looked again at the Clirr errors.
>>>
>>> Apart from the interface method additions, the changes are:
>>>
>>> *) Replacing org.apache.commons.vfs2.provider.tar.TarEntry by
>>> org.apache.commons.compress.archivers.tar.TarArchiveEntry in several
>>> places.
>>>
>>> TarEntry has been dropped, however the class was package-private so it
>>> was clearly not part of the public API.
>>> And likewise, methods using cannot have been part of the API.
>>>
>>> *) replacing org.apache.commons.vfs2.provider.tar.TarInputStream by
>>> org.apache.commons.compress.archivers.tar.TarArchiveInputStream as the
>>> return type for a couple of methods
>>>
>>> Again, TarInputStream has been dropped, and it was also
>>> package-private. So again the public API must be OK.
>>>
>>> So I think we are OK as far as BC is concerned.
>>>
>>> Source will need to be updated if it uses any of the interfaces that
>>> have been updated:
>>> FileContent
>>> FileName
>>> FileObject
>>> FileSystemManager
>>> RandomAccessContent
>>>
>>> If there may be another 2.x release, we should make sure that the
>>> interfaces have suitable abstract class implementations that can be
>>> extended instead of implementing the interface.
>>> Then external source will only need to be updated once.
>>>
>>> Assuming others agree with my analysis, these findings need to be
>>> documented in the RN.
>>>
>>>
>>> On 7 May 2016 at 06:29, Gary Gregory<ga...@gmail.com> wrote:
>>>
>>>> On Fri, May 6, 2016 at 10:20 PM, Ralph Goers<ralph.goers@dslextreme.com
>>>>
>>>> wrote:
>>>>
>>>> That was me. I have had those thoughts and mentioned them a few times
>>>>> since Java 7 was released. But absolutely no effort has been expended
>>>>>
>>>> to do
>>>
>>>> it.
>>>>>
>>>>> My personal opinion is that I am comfortable with releasing 2.1 with
>>>>> the
>>>>> issues Gary mentions. There should have been 10 releases for VFS 2 by
>>>>>
>>>> now.
>>>
>>>> Well, yeah, RERO would have been great but it was not on high enough on
>>>>
>>> my
>>>
>>>> priority list too ;-) The issue we have now would have popped each time
>>>>
>>> we
>>>
>>>> wanted to break BC, so we could have gotten a better feel for it with
>>>>
>>> RERO
>>>
>>>> and 10 VFS 2.x releases under our belts! But we are stuck with a Big
>>>> Bang
>>>> release now.
>>>>
>>>> I would request another RC from the RM, and let the community decide by
>>>> VOTE.
>>>>
>>>> Gary
>>>>
>>>> Ralph
>>>>>
>>>>> On May 6, 2016, at 8:40 PM, Matt Sicker<bo...@gmail.com> wrote:
>>>>>>
>>>>>> I thought there were talks about using Java 1.7 APIs in 3.0 that would
>>>>>> eliminate the need for some classes in commons-vfs, or am I confusing
>>>>>>
>>>>> that
>>>>>
>>>>>> with another commons project?
>>>>>>
>>>>>> On 6 May 2016 at 17:46, Gary Gregory<ga...@gmail.com> wrote:
>>>>>>
>>>>>> OK, I've gone through the Clirr report and fixed the low-hanging
>>>>>>>
>>>>>> fruits
>>>
>>>> in
>>>>>
>>>>>> trunk. I think we need another RC. I've also update Apache Commons
>>>>>>>
>>>>>> Compress
>>>>>
>>>>>> and Net to their current versions.
>>>>>>>
>>>>>>> Then what we have to live with for 2.1 is BC breaks in two narrower
>>>>>>>
>>>>>> areas:
>>>>>
>>>>>> - Added methods to interfaces.
>>>>>>> - Changes in the Tar classes from our own Tar classes to Apache
>>>>>>>
>>>>>> Commons
>>>
>>>> Compress' Tar classes.
>>>>>>>
>>>>>>> That's how good it's going to get for now IMO.
>>>>>>>
>>>>>>> I would be perfectly OK with repackaging for 3.0 but then this would
>>>>>>>
>>>>>> open
>>>>>
>>>>>> the door to other changes that folks might want to make. I would be
>>>>>>>
>>>>>> OK
>>>
>>>> with
>>>>>
>>>>>> saying this is 3.0 as is in this case.
>>>>>>>
>>>>>>> I'm still not 100% comfortable with the BC based on my experience
>>>>>>>
>>>>>> with
>>>
>>>> large projects with deep transitive dependencies.
>>>>>>>
>>>>>>> If the community VOTEs to release trunk (yes, another RC please) as
>>>>>>>
>>>>>> 2.1
>>>
>>>> then I'll live with it. Releasing as 3.0 (as is) would be safe and
>>>>>>> conservative.
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>> On Fri, May 6, 2016 at 3:00 PM, sebb<se...@gmail.com> wrote:
>>>>>>>
>>>>>>> On 6 May 2016 at 22:40, Gary Gregory<ga...@gmail.com>
>>>>>>>>
>>>>>>> wrote:
>>>
>>>> I'm creating a new thread here instead of hijacking the VOTE
>>>>>>>>>
>>>>>>>> thread.
>>>
>>>> First, let me express my gratitude to Stian Soiland-Reyes for
>>>>>>>>>
>>>>>>>> RM'ing a
>>>
>>>> release, I'm sure he did not know what he was getting himself into!
>>>>>>>>>
>>>>>>>> ;-)
>>>>>
>>>>>> Huh? ... that was/is Josh Elser.
>>>>>>>> Who does (also) deserve many thanks.
>>>>>>>>
>>>>>>>> Part of me writing this here is flushing out for myself, voters,
>>>>>>>>>
>>>>>>>> and
>>>
>>>> casual
>>>>>>>>
>>>>>>>>> observers what it is we are doing ;-)
>>>>>>>>>
>>>>>>>>> We have BC breakage in VFS 2.1 RC1 in two areas:
>>>>>>>>>
>>>>>>>>> - Adding methods to public interfaces
>>>>>>>>>
>>>>>>>> AFAIK that is only a SOURCE breakage.
>>>>>>>>
>>>>>>>> - Other stuff like removing fields, changing fields from protected
>>>>>>>>>
>>>>>>>> to
>>>
>>>> private, changing method arg types.
>>>>>>>>>
>>>>>>>> That does break BC if the objects are part of the public API.
>>>>>>>>
>>>>>>>> Details:
>>>>>>>>>
>>>>>>>>>
>>> https://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html
>>>
>>>> I see three areas that need consideration:
>>>>>>>>>
>>>>>>>>> (0) For simple clients that only use the higher-level interfaces
>>>>>>>>>
>>>>>>>> and
>>>
>>>> methods, there are no problems. So this is a non-issue marker I
>>>>>>>>>
>>>>>>>> suppose.
>>>>>>>
>>>>>>>> Whether or not that affects simple clients depends on exactly which
>>>>>>>> fields and method args have changed. Are they part of the public
>>>>>>>>
>>>>>>> API?
>>>
>>>> And if so, will simple clients use that part of the API?
>>>>>>>>
>>>>>>>> (1) For advanced clients that get their fingers in deep into VFS,
>>>>>>>>>
>>>>>>>> they
>>>
>>>> break. Example:
>>>>>>>>>
>>>>>>>>> - org.apache.commons.vfs2.provider.tar.TarFileObject:
>>>>>>>>>
>>>>>>>> Accessibility of
>>>
>>>> field entry has been weakened from protected to private.
>>>>>>>>> - org.apache.commons.vfs2.provider.webdav.WebdavFileProvider:
>>>>>>>>>
>>>>>>>> Removed
>>>
>>>> field
>>>>>>>>
>>>>>>>>> AUTHENTICATOR_TYPES
>>>>>>>>> - and so on.
>>>>>>>>>
>>>>>>>>> Remedies for these kinds of breaks are simple and easy: Just change
>>>>>>>>>
>>>>>>>> stuff
>>>>>>>
>>>>>>>> back and mark @deprecated in Javadoc and @Deprecated.
>>>>>>>>>
>>>>>>>>> (2) For providers, they break unless they extend our root classes
>>>>>>>>>
>>>>>>>> like
>>>
>>>> AbstractFileObject and DefaultFileSystemManager, and use our
>>>>>>>>>
>>>>>>>> default
>>>
>>>> classes like DefaultFileContent.
>>>>>>>>> For "simple" providers, there probably won't be any issue, but who
>>>>>>>>>
>>>>>>>> knows?
>>>>>>>
>>>>>>>> Does anyone have a 2.0 provider?
>>>>>>>>> For advanced providers that do more of their own thing instead of
>>>>>>>>>
>>>>>>>> reusing
>>>>>>>
>>>>>>>> our base classes, then breakage.
>>>>>>>>>
>>>>>>>>> It seems to me that we should pick the low-hanging fruits and fix
>>>>>>>>>
>>>>>>>> the
>>>
>>>> simple stuff.
>>>>>>>>>
>>>>>>>>> All of this is moot if we were to go to 3.0 now.
>>>>>>>>>
>>>>>>>> Which would not be source or binary compatible by design.
>>>>>>>>
>>>>>>>> Thoughts?
>>>>>>>>>
>>>>>>>> The easiest for Commons would obviously be to abandon 2.x and
>>>>>>>>
>>>>>>> release
>>>
>>>> 3.0.
>>>>>>>
>>>>>>>> That would be a chance to fix APIs properly.
>>>>>>>>
>>>>>>>> However, given the work that Josh has already put into 2.1 that
>>>>>>>>
>>>>>>> seems
>>>
>>>> a waste of effort if we can either:
>>>>>>>> - eliminate the BC breaks, OR
>>>>>>>> - satisfy ourselves that the breaks will not affect (m)any users.
>>>>>>>>
>>>>>>>> Gary
>>>>>>>>> --
>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>>> JUnit in Action, Second Edition<http://www.manning.com/tahchiev/>
>>>>>>>>> Spring Batch in Action<http://www.manning.com/templier/>
>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>> ---------------------------------------------------------------------
>>>
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>> JUnit in Action, Second Edition<http://www.manning.com/tahchiev/>
>>>>>>> Spring Batch in Action<http://www.manning.com/templier/>
>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>> Home: http://garygregory.com/
>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker<bo...@gmail.com>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> Java Persistence with Hibernate, Second Edition
>>>> <http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition<http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action<http://www.manning.com/templier/>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>> ---------------------------------------------------------------------
>>> 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: [VFS] BC breaks in VFS 2.1 RC1
Posted by Josh Elser <el...@apache.org>.
Gary -- how quickly can you turn around a patch to fix this? Without a
patch, I am still in favor of 2.1 being released as is. 2.1.1 can be
released with these fixes at your earliest convenience.
Gary Gregory wrote:
> Just for completeness, I'm advocating we do this now, but new methods to
> interfaces could be added as subinterfaces as in FileContent2 extends
> FileContent.
>
> Gary
>
> On Sat, May 7, 2016 at 2:52 AM, sebb<se...@gmail.com> wrote:
>
>> I have just looked again at the Clirr errors.
>>
>> Apart from the interface method additions, the changes are:
>>
>> *) Replacing org.apache.commons.vfs2.provider.tar.TarEntry by
>> org.apache.commons.compress.archivers.tar.TarArchiveEntry in several
>> places.
>>
>> TarEntry has been dropped, however the class was package-private so it
>> was clearly not part of the public API.
>> And likewise, methods using cannot have been part of the API.
>>
>> *) replacing org.apache.commons.vfs2.provider.tar.TarInputStream by
>> org.apache.commons.compress.archivers.tar.TarArchiveInputStream as the
>> return type for a couple of methods
>>
>> Again, TarInputStream has been dropped, and it was also
>> package-private. So again the public API must be OK.
>>
>> So I think we are OK as far as BC is concerned.
>>
>> Source will need to be updated if it uses any of the interfaces that
>> have been updated:
>> FileContent
>> FileName
>> FileObject
>> FileSystemManager
>> RandomAccessContent
>>
>> If there may be another 2.x release, we should make sure that the
>> interfaces have suitable abstract class implementations that can be
>> extended instead of implementing the interface.
>> Then external source will only need to be updated once.
>>
>> Assuming others agree with my analysis, these findings need to be
>> documented in the RN.
>>
>>
>> On 7 May 2016 at 06:29, Gary Gregory<ga...@gmail.com> wrote:
>>> On Fri, May 6, 2016 at 10:20 PM, Ralph Goers<ralph.goers@dslextreme.com
>>>
>>> wrote:
>>>
>>>> That was me. I have had those thoughts and mentioned them a few times
>>>> since Java 7 was released. But absolutely no effort has been expended
>> to do
>>>> it.
>>>>
>>>> My personal opinion is that I am comfortable with releasing 2.1 with the
>>>> issues Gary mentions. There should have been 10 releases for VFS 2 by
>> now.
>>> Well, yeah, RERO would have been great but it was not on high enough on
>> my
>>> priority list too ;-) The issue we have now would have popped each time
>> we
>>> wanted to break BC, so we could have gotten a better feel for it with
>> RERO
>>> and 10 VFS 2.x releases under our belts! But we are stuck with a Big Bang
>>> release now.
>>>
>>> I would request another RC from the RM, and let the community decide by
>>> VOTE.
>>>
>>> Gary
>>>
>>>> Ralph
>>>>
>>>>> On May 6, 2016, at 8:40 PM, Matt Sicker<bo...@gmail.com> wrote:
>>>>>
>>>>> I thought there were talks about using Java 1.7 APIs in 3.0 that would
>>>>> eliminate the need for some classes in commons-vfs, or am I confusing
>>>> that
>>>>> with another commons project?
>>>>>
>>>>> On 6 May 2016 at 17:46, Gary Gregory<ga...@gmail.com> wrote:
>>>>>
>>>>>> OK, I've gone through the Clirr report and fixed the low-hanging
>> fruits
>>>> in
>>>>>> trunk. I think we need another RC. I've also update Apache Commons
>>>> Compress
>>>>>> and Net to their current versions.
>>>>>>
>>>>>> Then what we have to live with for 2.1 is BC breaks in two narrower
>>>> areas:
>>>>>> - Added methods to interfaces.
>>>>>> - Changes in the Tar classes from our own Tar classes to Apache
>> Commons
>>>>>> Compress' Tar classes.
>>>>>>
>>>>>> That's how good it's going to get for now IMO.
>>>>>>
>>>>>> I would be perfectly OK with repackaging for 3.0 but then this would
>>>> open
>>>>>> the door to other changes that folks might want to make. I would be
>> OK
>>>> with
>>>>>> saying this is 3.0 as is in this case.
>>>>>>
>>>>>> I'm still not 100% comfortable with the BC based on my experience
>> with
>>>>>> large projects with deep transitive dependencies.
>>>>>>
>>>>>> If the community VOTEs to release trunk (yes, another RC please) as
>> 2.1
>>>>>> then I'll live with it. Releasing as 3.0 (as is) would be safe and
>>>>>> conservative.
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>> On Fri, May 6, 2016 at 3:00 PM, sebb<se...@gmail.com> wrote:
>>>>>>
>>>>>>> On 6 May 2016 at 22:40, Gary Gregory<ga...@gmail.com>
>> wrote:
>>>>>>>> I'm creating a new thread here instead of hijacking the VOTE
>> thread.
>>>>>>>> First, let me express my gratitude to Stian Soiland-Reyes for
>> RM'ing a
>>>>>>>> release, I'm sure he did not know what he was getting himself into!
>>>> ;-)
>>>>>>> Huh? ... that was/is Josh Elser.
>>>>>>> Who does (also) deserve many thanks.
>>>>>>>
>>>>>>>> Part of me writing this here is flushing out for myself, voters,
>> and
>>>>>>> casual
>>>>>>>> observers what it is we are doing ;-)
>>>>>>>>
>>>>>>>> We have BC breakage in VFS 2.1 RC1 in two areas:
>>>>>>>>
>>>>>>>> - Adding methods to public interfaces
>>>>>>> AFAIK that is only a SOURCE breakage.
>>>>>>>
>>>>>>>> - Other stuff like removing fields, changing fields from protected
>> to
>>>>>>>> private, changing method arg types.
>>>>>>> That does break BC if the objects are part of the public API.
>>>>>>>
>>>>>>>> Details:
>>>>>>>>
>> https://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html
>>>>>>>> I see three areas that need consideration:
>>>>>>>>
>>>>>>>> (0) For simple clients that only use the higher-level interfaces
>> and
>>>>>>>> methods, there are no problems. So this is a non-issue marker I
>>>>>> suppose.
>>>>>>> Whether or not that affects simple clients depends on exactly which
>>>>>>> fields and method args have changed. Are they part of the public
>> API?
>>>>>>> And if so, will simple clients use that part of the API?
>>>>>>>
>>>>>>>> (1) For advanced clients that get their fingers in deep into VFS,
>> they
>>>>>>>> break. Example:
>>>>>>>>
>>>>>>>> - org.apache.commons.vfs2.provider.tar.TarFileObject:
>> Accessibility of
>>>>>>>> field entry has been weakened from protected to private.
>>>>>>>> - org.apache.commons.vfs2.provider.webdav.WebdavFileProvider:
>> Removed
>>>>>>> field
>>>>>>>> AUTHENTICATOR_TYPES
>>>>>>>> - and so on.
>>>>>>>>
>>>>>>>> Remedies for these kinds of breaks are simple and easy: Just change
>>>>>> stuff
>>>>>>>> back and mark @deprecated in Javadoc and @Deprecated.
>>>>>>>>
>>>>>>>> (2) For providers, they break unless they extend our root classes
>> like
>>>>>>>> AbstractFileObject and DefaultFileSystemManager, and use our
>> default
>>>>>>>> classes like DefaultFileContent.
>>>>>>>> For "simple" providers, there probably won't be any issue, but who
>>>>>> knows?
>>>>>>>> Does anyone have a 2.0 provider?
>>>>>>>> For advanced providers that do more of their own thing instead of
>>>>>> reusing
>>>>>>>> our base classes, then breakage.
>>>>>>>>
>>>>>>>> It seems to me that we should pick the low-hanging fruits and fix
>> the
>>>>>>>> simple stuff.
>>>>>>>>
>>>>>>>> All of this is moot if we were to go to 3.0 now.
>>>>>>> Which would not be source or binary compatible by design.
>>>>>>>
>>>>>>>> Thoughts?
>>>>>>> The easiest for Commons would obviously be to abandon 2.x and
>> release
>>>>>> 3.0.
>>>>>>> That would be a chance to fix APIs properly.
>>>>>>>
>>>>>>> However, given the work that Josh has already put into 2.1 that
>> seems
>>>>>>> a waste of effort if we can either:
>>>>>>> - eliminate the BC breaks, OR
>>>>>>> - satisfy ourselves that the breaks will not affect (m)any users.
>>>>>>>
>>>>>>>> Gary
>>>>>>>> --
>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>> JUnit in Action, Second Edition<http://www.manning.com/tahchiev/>
>>>>>>>> Spring Batch in Action<http://www.manning.com/templier/>
>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>> Home: http://garygregory.com/
>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>> <http://www.manning.com/bauer3/>
>>>>>> JUnit in Action, Second Edition<http://www.manning.com/tahchiev/>
>>>>>> Spring Batch in Action<http://www.manning.com/templier/>
>>>>>> Blog: http://garygregory.wordpress.com
>>>>>> Home: http://garygregory.com/
>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker<bo...@gmail.com>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> <http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition<http://www.manning.com/tahchiev/>
>>> Spring Batch in Action<http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>> ---------------------------------------------------------------------
>> 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: [VFS] BC breaks in VFS 2.1 RC1
Posted by Gary Gregory <ga...@gmail.com>.
Just for completeness, I'm advocating we do this now, but new methods to
interfaces could be added as subinterfaces as in FileContent2 extends
FileContent.
Gary
On Sat, May 7, 2016 at 2:52 AM, sebb <se...@gmail.com> wrote:
> I have just looked again at the Clirr errors.
>
> Apart from the interface method additions, the changes are:
>
> *) Replacing org.apache.commons.vfs2.provider.tar.TarEntry by
> org.apache.commons.compress.archivers.tar.TarArchiveEntry in several
> places.
>
> TarEntry has been dropped, however the class was package-private so it
> was clearly not part of the public API.
> And likewise, methods using cannot have been part of the API.
>
> *) replacing org.apache.commons.vfs2.provider.tar.TarInputStream by
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream as the
> return type for a couple of methods
>
> Again, TarInputStream has been dropped, and it was also
> package-private. So again the public API must be OK.
>
> So I think we are OK as far as BC is concerned.
>
> Source will need to be updated if it uses any of the interfaces that
> have been updated:
> FileContent
> FileName
> FileObject
> FileSystemManager
> RandomAccessContent
>
> If there may be another 2.x release, we should make sure that the
> interfaces have suitable abstract class implementations that can be
> extended instead of implementing the interface.
> Then external source will only need to be updated once.
>
> Assuming others agree with my analysis, these findings need to be
> documented in the RN.
>
>
> On 7 May 2016 at 06:29, Gary Gregory <ga...@gmail.com> wrote:
> > On Fri, May 6, 2016 at 10:20 PM, Ralph Goers <ralph.goers@dslextreme.com
> >
> > wrote:
> >
> >> That was me. I have had those thoughts and mentioned them a few times
> >> since Java 7 was released. But absolutely no effort has been expended
> to do
> >> it.
> >>
> >> My personal opinion is that I am comfortable with releasing 2.1 with the
> >> issues Gary mentions. There should have been 10 releases for VFS 2 by
> now.
> >>
> >
> > Well, yeah, RERO would have been great but it was not on high enough on
> my
> > priority list too ;-) The issue we have now would have popped each time
> we
> > wanted to break BC, so we could have gotten a better feel for it with
> RERO
> > and 10 VFS 2.x releases under our belts! But we are stuck with a Big Bang
> > release now.
> >
> > I would request another RC from the RM, and let the community decide by
> > VOTE.
> >
> > Gary
> >
> >>
> >> Ralph
> >>
> >> > On May 6, 2016, at 8:40 PM, Matt Sicker <bo...@gmail.com> wrote:
> >> >
> >> > I thought there were talks about using Java 1.7 APIs in 3.0 that would
> >> > eliminate the need for some classes in commons-vfs, or am I confusing
> >> that
> >> > with another commons project?
> >> >
> >> > On 6 May 2016 at 17:46, Gary Gregory <ga...@gmail.com> wrote:
> >> >
> >> >> OK, I've gone through the Clirr report and fixed the low-hanging
> fruits
> >> in
> >> >> trunk. I think we need another RC. I've also update Apache Commons
> >> Compress
> >> >> and Net to their current versions.
> >> >>
> >> >> Then what we have to live with for 2.1 is BC breaks in two narrower
> >> areas:
> >> >>
> >> >> - Added methods to interfaces.
> >> >> - Changes in the Tar classes from our own Tar classes to Apache
> Commons
> >> >> Compress' Tar classes.
> >> >>
> >> >> That's how good it's going to get for now IMO.
> >> >>
> >> >> I would be perfectly OK with repackaging for 3.0 but then this would
> >> open
> >> >> the door to other changes that folks might want to make. I would be
> OK
> >> with
> >> >> saying this is 3.0 as is in this case.
> >> >>
> >> >> I'm still not 100% comfortable with the BC based on my experience
> with
> >> >> large projects with deep transitive dependencies.
> >> >>
> >> >> If the community VOTEs to release trunk (yes, another RC please) as
> 2.1
> >> >> then I'll live with it. Releasing as 3.0 (as is) would be safe and
> >> >> conservative.
> >> >>
> >> >> Gary
> >> >>
> >> >> On Fri, May 6, 2016 at 3:00 PM, sebb <se...@gmail.com> wrote:
> >> >>
> >> >>> On 6 May 2016 at 22:40, Gary Gregory <ga...@gmail.com>
> wrote:
> >> >>>> I'm creating a new thread here instead of hijacking the VOTE
> thread.
> >> >>>>
> >> >>>> First, let me express my gratitude to Stian Soiland-Reyes for
> RM'ing a
> >> >>>> release, I'm sure he did not know what he was getting himself into!
> >> ;-)
> >> >>>
> >> >>> Huh? ... that was/is Josh Elser.
> >> >>> Who does (also) deserve many thanks.
> >> >>>
> >> >>>> Part of me writing this here is flushing out for myself, voters,
> and
> >> >>> casual
> >> >>>> observers what it is we are doing ;-)
> >> >>>>
> >> >>>> We have BC breakage in VFS 2.1 RC1 in two areas:
> >> >>>>
> >> >>>> - Adding methods to public interfaces
> >> >>>
> >> >>> AFAIK that is only a SOURCE breakage.
> >> >>>
> >> >>>> - Other stuff like removing fields, changing fields from protected
> to
> >> >>>> private, changing method arg types.
> >> >>>
> >> >>> That does break BC if the objects are part of the public API.
> >> >>>
> >> >>>> Details:
> >> >>>>
> >> >>>
> >> >>
> >>
> https://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html
> >> >>>>
> >> >>>> I see three areas that need consideration:
> >> >>>>
> >> >>>> (0) For simple clients that only use the higher-level interfaces
> and
> >> >>>> methods, there are no problems. So this is a non-issue marker I
> >> >> suppose.
> >> >>>
> >> >>> Whether or not that affects simple clients depends on exactly which
> >> >>> fields and method args have changed. Are they part of the public
> API?
> >> >>> And if so, will simple clients use that part of the API?
> >> >>>
> >> >>>> (1) For advanced clients that get their fingers in deep into VFS,
> they
> >> >>>> break. Example:
> >> >>>>
> >> >>>> - org.apache.commons.vfs2.provider.tar.TarFileObject:
> Accessibility of
> >> >>>> field entry has been weakened from protected to private.
> >> >>>> - org.apache.commons.vfs2.provider.webdav.WebdavFileProvider:
> Removed
> >> >>> field
> >> >>>> AUTHENTICATOR_TYPES
> >> >>>> - and so on.
> >> >>>>
> >> >>>> Remedies for these kinds of breaks are simple and easy: Just change
> >> >> stuff
> >> >>>> back and mark @deprecated in Javadoc and @Deprecated.
> >> >>>>
> >> >>>> (2) For providers, they break unless they extend our root classes
> like
> >> >>>> AbstractFileObject and DefaultFileSystemManager, and use our
> default
> >> >>>> classes like DefaultFileContent.
> >> >>>> For "simple" providers, there probably won't be any issue, but who
> >> >> knows?
> >> >>>> Does anyone have a 2.0 provider?
> >> >>>> For advanced providers that do more of their own thing instead of
> >> >> reusing
> >> >>>> our base classes, then breakage.
> >> >>>>
> >> >>>> It seems to me that we should pick the low-hanging fruits and fix
> the
> >> >>>> simple stuff.
> >> >>>>
> >> >>>> All of this is moot if we were to go to 3.0 now.
> >> >>>
> >> >>> Which would not be source or binary compatible by design.
> >> >>>
> >> >>>> Thoughts?
> >> >>>
> >> >>> The easiest for Commons would obviously be to abandon 2.x and
> release
> >> >> 3.0.
> >> >>> That would be a chance to fix APIs properly.
> >> >>>
> >> >>> However, given the work that Josh has already put into 2.1 that
> seems
> >> >>> a waste of effort if we can either:
> >> >>> - eliminate the BC breaks, OR
> >> >>> - satisfy ourselves that the breaks will not affect (m)any users.
> >> >>>
> >> >>>> Gary
> >> >>>> --
> >> >>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> >>>> Java Persistence with Hibernate, Second Edition
> >> >>>> <http://www.manning.com/bauer3/>
> >> >>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> >> >>>> Spring Batch in Action <http://www.manning.com/templier/>
> >> >>>> Blog: http://garygregory.wordpress.com
> >> >>>> Home: http://garygregory.com/
> >> >>>> Tweet! http://twitter.com/GaryGregory
> >> >>>
> >> >>>
> ---------------------------------------------------------------------
> >> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >> --
> >> >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> >> Java Persistence with Hibernate, Second Edition
> >> >> <http://www.manning.com/bauer3/>
> >> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> >> >> Spring Batch in Action <http://www.manning.com/templier/>
> >> >> Blog: http://garygregory.wordpress.com
> >> >> Home: http://garygregory.com/
> >> >> Tweet! http://twitter.com/GaryGregory
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Matt Sicker <bo...@gmail.com>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > Java Persistence with Hibernate, Second Edition
> > <http://www.manning.com/bauer3/>
> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > Spring Batch in Action <http://www.manning.com/templier/>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [VFS] BC breaks in VFS 2.1 RC1
Posted by sebb <se...@gmail.com>.
I have just looked again at the Clirr errors.
Apart from the interface method additions, the changes are:
*) Replacing org.apache.commons.vfs2.provider.tar.TarEntry by
org.apache.commons.compress.archivers.tar.TarArchiveEntry in several
places.
TarEntry has been dropped, however the class was package-private so it
was clearly not part of the public API.
And likewise, methods using cannot have been part of the API.
*) replacing org.apache.commons.vfs2.provider.tar.TarInputStream by
org.apache.commons.compress.archivers.tar.TarArchiveInputStream as the
return type for a couple of methods
Again, TarInputStream has been dropped, and it was also
package-private. So again the public API must be OK.
So I think we are OK as far as BC is concerned.
Source will need to be updated if it uses any of the interfaces that
have been updated:
FileContent
FileName
FileObject
FileSystemManager
RandomAccessContent
If there may be another 2.x release, we should make sure that the
interfaces have suitable abstract class implementations that can be
extended instead of implementing the interface.
Then external source will only need to be updated once.
Assuming others agree with my analysis, these findings need to be
documented in the RN.
On 7 May 2016 at 06:29, Gary Gregory <ga...@gmail.com> wrote:
> On Fri, May 6, 2016 at 10:20 PM, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> That was me. I have had those thoughts and mentioned them a few times
>> since Java 7 was released. But absolutely no effort has been expended to do
>> it.
>>
>> My personal opinion is that I am comfortable with releasing 2.1 with the
>> issues Gary mentions. There should have been 10 releases for VFS 2 by now.
>>
>
> Well, yeah, RERO would have been great but it was not on high enough on my
> priority list too ;-) The issue we have now would have popped each time we
> wanted to break BC, so we could have gotten a better feel for it with RERO
> and 10 VFS 2.x releases under our belts! But we are stuck with a Big Bang
> release now.
>
> I would request another RC from the RM, and let the community decide by
> VOTE.
>
> Gary
>
>>
>> Ralph
>>
>> > On May 6, 2016, at 8:40 PM, Matt Sicker <bo...@gmail.com> wrote:
>> >
>> > I thought there were talks about using Java 1.7 APIs in 3.0 that would
>> > eliminate the need for some classes in commons-vfs, or am I confusing
>> that
>> > with another commons project?
>> >
>> > On 6 May 2016 at 17:46, Gary Gregory <ga...@gmail.com> wrote:
>> >
>> >> OK, I've gone through the Clirr report and fixed the low-hanging fruits
>> in
>> >> trunk. I think we need another RC. I've also update Apache Commons
>> Compress
>> >> and Net to their current versions.
>> >>
>> >> Then what we have to live with for 2.1 is BC breaks in two narrower
>> areas:
>> >>
>> >> - Added methods to interfaces.
>> >> - Changes in the Tar classes from our own Tar classes to Apache Commons
>> >> Compress' Tar classes.
>> >>
>> >> That's how good it's going to get for now IMO.
>> >>
>> >> I would be perfectly OK with repackaging for 3.0 but then this would
>> open
>> >> the door to other changes that folks might want to make. I would be OK
>> with
>> >> saying this is 3.0 as is in this case.
>> >>
>> >> I'm still not 100% comfortable with the BC based on my experience with
>> >> large projects with deep transitive dependencies.
>> >>
>> >> If the community VOTEs to release trunk (yes, another RC please) as 2.1
>> >> then I'll live with it. Releasing as 3.0 (as is) would be safe and
>> >> conservative.
>> >>
>> >> Gary
>> >>
>> >> On Fri, May 6, 2016 at 3:00 PM, sebb <se...@gmail.com> wrote:
>> >>
>> >>> On 6 May 2016 at 22:40, Gary Gregory <ga...@gmail.com> wrote:
>> >>>> I'm creating a new thread here instead of hijacking the VOTE thread.
>> >>>>
>> >>>> First, let me express my gratitude to Stian Soiland-Reyes for RM'ing a
>> >>>> release, I'm sure he did not know what he was getting himself into!
>> ;-)
>> >>>
>> >>> Huh? ... that was/is Josh Elser.
>> >>> Who does (also) deserve many thanks.
>> >>>
>> >>>> Part of me writing this here is flushing out for myself, voters, and
>> >>> casual
>> >>>> observers what it is we are doing ;-)
>> >>>>
>> >>>> We have BC breakage in VFS 2.1 RC1 in two areas:
>> >>>>
>> >>>> - Adding methods to public interfaces
>> >>>
>> >>> AFAIK that is only a SOURCE breakage.
>> >>>
>> >>>> - Other stuff like removing fields, changing fields from protected to
>> >>>> private, changing method arg types.
>> >>>
>> >>> That does break BC if the objects are part of the public API.
>> >>>
>> >>>> Details:
>> >>>>
>> >>>
>> >>
>> https://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html
>> >>>>
>> >>>> I see three areas that need consideration:
>> >>>>
>> >>>> (0) For simple clients that only use the higher-level interfaces and
>> >>>> methods, there are no problems. So this is a non-issue marker I
>> >> suppose.
>> >>>
>> >>> Whether or not that affects simple clients depends on exactly which
>> >>> fields and method args have changed. Are they part of the public API?
>> >>> And if so, will simple clients use that part of the API?
>> >>>
>> >>>> (1) For advanced clients that get their fingers in deep into VFS, they
>> >>>> break. Example:
>> >>>>
>> >>>> - org.apache.commons.vfs2.provider.tar.TarFileObject: Accessibility of
>> >>>> field entry has been weakened from protected to private.
>> >>>> - org.apache.commons.vfs2.provider.webdav.WebdavFileProvider: Removed
>> >>> field
>> >>>> AUTHENTICATOR_TYPES
>> >>>> - and so on.
>> >>>>
>> >>>> Remedies for these kinds of breaks are simple and easy: Just change
>> >> stuff
>> >>>> back and mark @deprecated in Javadoc and @Deprecated.
>> >>>>
>> >>>> (2) For providers, they break unless they extend our root classes like
>> >>>> AbstractFileObject and DefaultFileSystemManager, and use our default
>> >>>> classes like DefaultFileContent.
>> >>>> For "simple" providers, there probably won't be any issue, but who
>> >> knows?
>> >>>> Does anyone have a 2.0 provider?
>> >>>> For advanced providers that do more of their own thing instead of
>> >> reusing
>> >>>> our base classes, then breakage.
>> >>>>
>> >>>> It seems to me that we should pick the low-hanging fruits and fix the
>> >>>> simple stuff.
>> >>>>
>> >>>> All of this is moot if we were to go to 3.0 now.
>> >>>
>> >>> Which would not be source or binary compatible by design.
>> >>>
>> >>>> Thoughts?
>> >>>
>> >>> The easiest for Commons would obviously be to abandon 2.x and release
>> >> 3.0.
>> >>> That would be a chance to fix APIs properly.
>> >>>
>> >>> However, given the work that Josh has already put into 2.1 that seems
>> >>> a waste of effort if we can either:
>> >>> - eliminate the BC breaks, OR
>> >>> - satisfy ourselves that the breaks will not affect (m)any users.
>> >>>
>> >>>> Gary
>> >>>> --
>> >>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> >>>> Java Persistence with Hibernate, Second Edition
>> >>>> <http://www.manning.com/bauer3/>
>> >>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> >>>> Spring Batch in Action <http://www.manning.com/templier/>
>> >>>> Blog: http://garygregory.wordpress.com
>> >>>> Home: http://garygregory.com/
>> >>>> Tweet! http://twitter.com/GaryGregory
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> >> Java Persistence with Hibernate, Second Edition
>> >> <http://www.manning.com/bauer3/>
>> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> >> Spring Batch in Action <http://www.manning.com/templier/>
>> >> Blog: http://garygregory.wordpress.com
>> >> Home: http://garygregory.com/
>> >> Tweet! http://twitter.com/GaryGregory
>> >>
>> >
>> >
>> >
>> > --
>> > Matt Sicker <bo...@gmail.com>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VFS] BC breaks in VFS 2.1 RC1
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, May 6, 2016 at 10:20 PM, Ralph Goers <ra...@dslextreme.com>
wrote:
> That was me. I have had those thoughts and mentioned them a few times
> since Java 7 was released. But absolutely no effort has been expended to do
> it.
>
> My personal opinion is that I am comfortable with releasing 2.1 with the
> issues Gary mentions. There should have been 10 releases for VFS 2 by now.
>
Well, yeah, RERO would have been great but it was not on high enough on my
priority list too ;-) The issue we have now would have popped each time we
wanted to break BC, so we could have gotten a better feel for it with RERO
and 10 VFS 2.x releases under our belts! But we are stuck with a Big Bang
release now.
I would request another RC from the RM, and let the community decide by
VOTE.
Gary
>
> Ralph
>
> > On May 6, 2016, at 8:40 PM, Matt Sicker <bo...@gmail.com> wrote:
> >
> > I thought there were talks about using Java 1.7 APIs in 3.0 that would
> > eliminate the need for some classes in commons-vfs, or am I confusing
> that
> > with another commons project?
> >
> > On 6 May 2016 at 17:46, Gary Gregory <ga...@gmail.com> wrote:
> >
> >> OK, I've gone through the Clirr report and fixed the low-hanging fruits
> in
> >> trunk. I think we need another RC. I've also update Apache Commons
> Compress
> >> and Net to their current versions.
> >>
> >> Then what we have to live with for 2.1 is BC breaks in two narrower
> areas:
> >>
> >> - Added methods to interfaces.
> >> - Changes in the Tar classes from our own Tar classes to Apache Commons
> >> Compress' Tar classes.
> >>
> >> That's how good it's going to get for now IMO.
> >>
> >> I would be perfectly OK with repackaging for 3.0 but then this would
> open
> >> the door to other changes that folks might want to make. I would be OK
> with
> >> saying this is 3.0 as is in this case.
> >>
> >> I'm still not 100% comfortable with the BC based on my experience with
> >> large projects with deep transitive dependencies.
> >>
> >> If the community VOTEs to release trunk (yes, another RC please) as 2.1
> >> then I'll live with it. Releasing as 3.0 (as is) would be safe and
> >> conservative.
> >>
> >> Gary
> >>
> >> On Fri, May 6, 2016 at 3:00 PM, sebb <se...@gmail.com> wrote:
> >>
> >>> On 6 May 2016 at 22:40, Gary Gregory <ga...@gmail.com> wrote:
> >>>> I'm creating a new thread here instead of hijacking the VOTE thread.
> >>>>
> >>>> First, let me express my gratitude to Stian Soiland-Reyes for RM'ing a
> >>>> release, I'm sure he did not know what he was getting himself into!
> ;-)
> >>>
> >>> Huh? ... that was/is Josh Elser.
> >>> Who does (also) deserve many thanks.
> >>>
> >>>> Part of me writing this here is flushing out for myself, voters, and
> >>> casual
> >>>> observers what it is we are doing ;-)
> >>>>
> >>>> We have BC breakage in VFS 2.1 RC1 in two areas:
> >>>>
> >>>> - Adding methods to public interfaces
> >>>
> >>> AFAIK that is only a SOURCE breakage.
> >>>
> >>>> - Other stuff like removing fields, changing fields from protected to
> >>>> private, changing method arg types.
> >>>
> >>> That does break BC if the objects are part of the public API.
> >>>
> >>>> Details:
> >>>>
> >>>
> >>
> https://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html
> >>>>
> >>>> I see three areas that need consideration:
> >>>>
> >>>> (0) For simple clients that only use the higher-level interfaces and
> >>>> methods, there are no problems. So this is a non-issue marker I
> >> suppose.
> >>>
> >>> Whether or not that affects simple clients depends on exactly which
> >>> fields and method args have changed. Are they part of the public API?
> >>> And if so, will simple clients use that part of the API?
> >>>
> >>>> (1) For advanced clients that get their fingers in deep into VFS, they
> >>>> break. Example:
> >>>>
> >>>> - org.apache.commons.vfs2.provider.tar.TarFileObject: Accessibility of
> >>>> field entry has been weakened from protected to private.
> >>>> - org.apache.commons.vfs2.provider.webdav.WebdavFileProvider: Removed
> >>> field
> >>>> AUTHENTICATOR_TYPES
> >>>> - and so on.
> >>>>
> >>>> Remedies for these kinds of breaks are simple and easy: Just change
> >> stuff
> >>>> back and mark @deprecated in Javadoc and @Deprecated.
> >>>>
> >>>> (2) For providers, they break unless they extend our root classes like
> >>>> AbstractFileObject and DefaultFileSystemManager, and use our default
> >>>> classes like DefaultFileContent.
> >>>> For "simple" providers, there probably won't be any issue, but who
> >> knows?
> >>>> Does anyone have a 2.0 provider?
> >>>> For advanced providers that do more of their own thing instead of
> >> reusing
> >>>> our base classes, then breakage.
> >>>>
> >>>> It seems to me that we should pick the low-hanging fruits and fix the
> >>>> simple stuff.
> >>>>
> >>>> All of this is moot if we were to go to 3.0 now.
> >>>
> >>> Which would not be source or binary compatible by design.
> >>>
> >>>> Thoughts?
> >>>
> >>> The easiest for Commons would obviously be to abandon 2.x and release
> >> 3.0.
> >>> That would be a chance to fix APIs properly.
> >>>
> >>> However, given the work that Josh has already put into 2.1 that seems
> >>> a waste of effort if we can either:
> >>> - eliminate the BC breaks, OR
> >>> - satisfy ourselves that the breaks will not affect (m)any users.
> >>>
> >>>> Gary
> >>>> --
> >>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >>>> Java Persistence with Hibernate, Second Edition
> >>>> <http://www.manning.com/bauer3/>
> >>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> >>>> Spring Batch in Action <http://www.manning.com/templier/>
> >>>> Blog: http://garygregory.wordpress.com
> >>>> Home: http://garygregory.com/
> >>>> Tweet! http://twitter.com/GaryGregory
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> Java Persistence with Hibernate, Second Edition
> >> <http://www.manning.com/bauer3/>
> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> >> Spring Batch in Action <http://www.manning.com/templier/>
> >> Blog: http://garygregory.wordpress.com
> >> Home: http://garygregory.com/
> >> Tweet! http://twitter.com/GaryGregory
> >>
> >
> >
> >
> > --
> > Matt Sicker <bo...@gmail.com>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [VFS] BC breaks in VFS 2.1 RC1
Posted by Ralph Goers <ra...@dslextreme.com>.
That was me. I have had those thoughts and mentioned them a few times since Java 7 was released. But absolutely no effort has been expended to do it.
My personal opinion is that I am comfortable with releasing 2.1 with the issues Gary mentions. There should have been 10 releases for VFS 2 by now.
Ralph
> On May 6, 2016, at 8:40 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> I thought there were talks about using Java 1.7 APIs in 3.0 that would
> eliminate the need for some classes in commons-vfs, or am I confusing that
> with another commons project?
>
> On 6 May 2016 at 17:46, Gary Gregory <ga...@gmail.com> wrote:
>
>> OK, I've gone through the Clirr report and fixed the low-hanging fruits in
>> trunk. I think we need another RC. I've also update Apache Commons Compress
>> and Net to their current versions.
>>
>> Then what we have to live with for 2.1 is BC breaks in two narrower areas:
>>
>> - Added methods to interfaces.
>> - Changes in the Tar classes from our own Tar classes to Apache Commons
>> Compress' Tar classes.
>>
>> That's how good it's going to get for now IMO.
>>
>> I would be perfectly OK with repackaging for 3.0 but then this would open
>> the door to other changes that folks might want to make. I would be OK with
>> saying this is 3.0 as is in this case.
>>
>> I'm still not 100% comfortable with the BC based on my experience with
>> large projects with deep transitive dependencies.
>>
>> If the community VOTEs to release trunk (yes, another RC please) as 2.1
>> then I'll live with it. Releasing as 3.0 (as is) would be safe and
>> conservative.
>>
>> Gary
>>
>> On Fri, May 6, 2016 at 3:00 PM, sebb <se...@gmail.com> wrote:
>>
>>> On 6 May 2016 at 22:40, Gary Gregory <ga...@gmail.com> wrote:
>>>> I'm creating a new thread here instead of hijacking the VOTE thread.
>>>>
>>>> First, let me express my gratitude to Stian Soiland-Reyes for RM'ing a
>>>> release, I'm sure he did not know what he was getting himself into! ;-)
>>>
>>> Huh? ... that was/is Josh Elser.
>>> Who does (also) deserve many thanks.
>>>
>>>> Part of me writing this here is flushing out for myself, voters, and
>>> casual
>>>> observers what it is we are doing ;-)
>>>>
>>>> We have BC breakage in VFS 2.1 RC1 in two areas:
>>>>
>>>> - Adding methods to public interfaces
>>>
>>> AFAIK that is only a SOURCE breakage.
>>>
>>>> - Other stuff like removing fields, changing fields from protected to
>>>> private, changing method arg types.
>>>
>>> That does break BC if the objects are part of the public API.
>>>
>>>> Details:
>>>>
>>>
>> https://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html
>>>>
>>>> I see three areas that need consideration:
>>>>
>>>> (0) For simple clients that only use the higher-level interfaces and
>>>> methods, there are no problems. So this is a non-issue marker I
>> suppose.
>>>
>>> Whether or not that affects simple clients depends on exactly which
>>> fields and method args have changed. Are they part of the public API?
>>> And if so, will simple clients use that part of the API?
>>>
>>>> (1) For advanced clients that get their fingers in deep into VFS, they
>>>> break. Example:
>>>>
>>>> - org.apache.commons.vfs2.provider.tar.TarFileObject: Accessibility of
>>>> field entry has been weakened from protected to private.
>>>> - org.apache.commons.vfs2.provider.webdav.WebdavFileProvider: Removed
>>> field
>>>> AUTHENTICATOR_TYPES
>>>> - and so on.
>>>>
>>>> Remedies for these kinds of breaks are simple and easy: Just change
>> stuff
>>>> back and mark @deprecated in Javadoc and @Deprecated.
>>>>
>>>> (2) For providers, they break unless they extend our root classes like
>>>> AbstractFileObject and DefaultFileSystemManager, and use our default
>>>> classes like DefaultFileContent.
>>>> For "simple" providers, there probably won't be any issue, but who
>> knows?
>>>> Does anyone have a 2.0 provider?
>>>> For advanced providers that do more of their own thing instead of
>> reusing
>>>> our base classes, then breakage.
>>>>
>>>> It seems to me that we should pick the low-hanging fruits and fix the
>>>> simple stuff.
>>>>
>>>> All of this is moot if we were to go to 3.0 now.
>>>
>>> Which would not be source or binary compatible by design.
>>>
>>>> Thoughts?
>>>
>>> The easiest for Commons would obviously be to abandon 2.x and release
>> 3.0.
>>> That would be a chance to fix APIs properly.
>>>
>>> However, given the work that Josh has already put into 2.1 that seems
>>> a waste of effort if we can either:
>>> - eliminate the BC breaks, OR
>>> - satisfy ourselves that the breaks will not affect (m)any users.
>>>
>>>> Gary
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> Java Persistence with Hibernate, Second Edition
>>>> <http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VFS] BC breaks in VFS 2.1 RC1
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, May 6, 2016 at 8:40 PM, Matt Sicker <bo...@gmail.com> wrote:
> I thought there were talks about using Java 1.7 APIs in 3.0 that would
> eliminate the need for some classes in commons-vfs, or am I confusing that
> with another commons project?
>
You are correct, but this is a big job worthy of a major release, whether
it's 3.0 or 4.0 is a different story. I am talking about the possibility of
calling what we have now as 2.1 RC1 to be 3.0. The Java 7 FS would then be
4.0 unless it could be binary compatible in 3.x.
This discussion is really how likely we are to create jar hell with 2.1.
I'm just worried that there are 2.0 providers out there that will be broken
as soon as 2.1 is inserted into a stack. The jar hell happens if a 2.1 call
site uses 2.1 methods and a 2.0 provider is also in the software stack,
then we have jar hell. How likely is that?
Gary
> On 6 May 2016 at 17:46, Gary Gregory <ga...@gmail.com> wrote:
>
> > OK, I've gone through the Clirr report and fixed the low-hanging fruits
> in
> > trunk. I think we need another RC. I've also update Apache Commons
> Compress
> > and Net to their current versions.
> >
> > Then what we have to live with for 2.1 is BC breaks in two narrower
> areas:
> >
> > - Added methods to interfaces.
> > - Changes in the Tar classes from our own Tar classes to Apache Commons
> > Compress' Tar classes.
> >
> > That's how good it's going to get for now IMO.
> >
> > I would be perfectly OK with repackaging for 3.0 but then this would open
> > the door to other changes that folks might want to make. I would be OK
> with
> > saying this is 3.0 as is in this case.
> >
> > I'm still not 100% comfortable with the BC based on my experience with
> > large projects with deep transitive dependencies.
> >
> > If the community VOTEs to release trunk (yes, another RC please) as 2.1
> > then I'll live with it. Releasing as 3.0 (as is) would be safe and
> > conservative.
> >
> > Gary
> >
> > On Fri, May 6, 2016 at 3:00 PM, sebb <se...@gmail.com> wrote:
> >
> > > On 6 May 2016 at 22:40, Gary Gregory <ga...@gmail.com> wrote:
> > > > I'm creating a new thread here instead of hijacking the VOTE thread.
> > > >
> > > > First, let me express my gratitude to Stian Soiland-Reyes for RM'ing
> a
> > > > release, I'm sure he did not know what he was getting himself into!
> ;-)
> > >
> > > Huh? ... that was/is Josh Elser.
> > > Who does (also) deserve many thanks.
> > >
> > > > Part of me writing this here is flushing out for myself, voters, and
> > > casual
> > > > observers what it is we are doing ;-)
> > > >
> > > > We have BC breakage in VFS 2.1 RC1 in two areas:
> > > >
> > > > - Adding methods to public interfaces
> > >
> > > AFAIK that is only a SOURCE breakage.
> > >
> > > > - Other stuff like removing fields, changing fields from protected to
> > > > private, changing method arg types.
> > >
> > > That does break BC if the objects are part of the public API.
> > >
> > > > Details:
> > > >
> > >
> >
> https://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html
> > > >
> > > > I see three areas that need consideration:
> > > >
> > > > (0) For simple clients that only use the higher-level interfaces and
> > > > methods, there are no problems. So this is a non-issue marker I
> > suppose.
> > >
> > > Whether or not that affects simple clients depends on exactly which
> > > fields and method args have changed. Are they part of the public API?
> > > And if so, will simple clients use that part of the API?
> > >
> > > > (1) For advanced clients that get their fingers in deep into VFS,
> they
> > > > break. Example:
> > > >
> > > > - org.apache.commons.vfs2.provider.tar.TarFileObject: Accessibility
> of
> > > > field entry has been weakened from protected to private.
> > > > - org.apache.commons.vfs2.provider.webdav.WebdavFileProvider: Removed
> > > field
> > > > AUTHENTICATOR_TYPES
> > > > - and so on.
> > > >
> > > > Remedies for these kinds of breaks are simple and easy: Just change
> > stuff
> > > > back and mark @deprecated in Javadoc and @Deprecated.
> > > >
> > > > (2) For providers, they break unless they extend our root classes
> like
> > > > AbstractFileObject and DefaultFileSystemManager, and use our default
> > > > classes like DefaultFileContent.
> > > > For "simple" providers, there probably won't be any issue, but who
> > knows?
> > > > Does anyone have a 2.0 provider?
> > > > For advanced providers that do more of their own thing instead of
> > reusing
> > > > our base classes, then breakage.
> > > >
> > > > It seems to me that we should pick the low-hanging fruits and fix the
> > > > simple stuff.
> > > >
> > > > All of this is moot if we were to go to 3.0 now.
> > >
> > > Which would not be source or binary compatible by design.
> > >
> > > > Thoughts?
> > >
> > > The easiest for Commons would obviously be to abandon 2.x and release
> > 3.0.
> > > That would be a chance to fix APIs properly.
> > >
> > > However, given the work that Josh has already put into 2.1 that seems
> > > a waste of effort if we can either:
> > > - eliminate the BC breaks, OR
> > > - satisfy ourselves that the breaks will not affect (m)any users.
> > >
> > > > Gary
> > > > --
> > > > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > > > Java Persistence with Hibernate, Second Edition
> > > > <http://www.manning.com/bauer3/>
> > > > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > > > Spring Batch in Action <http://www.manning.com/templier/>
> > > > Blog: http://garygregory.wordpress.com
> > > > Home: http://garygregory.com/
> > > > Tweet! http://twitter.com/GaryGregory
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > Java Persistence with Hibernate, Second Edition
> > <http://www.manning.com/bauer3/>
> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > Spring Batch in Action <http://www.manning.com/templier/>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
> >
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [VFS] BC breaks in VFS 2.1 RC1
Posted by Matt Sicker <bo...@gmail.com>.
I thought there were talks about using Java 1.7 APIs in 3.0 that would
eliminate the need for some classes in commons-vfs, or am I confusing that
with another commons project?
On 6 May 2016 at 17:46, Gary Gregory <ga...@gmail.com> wrote:
> OK, I've gone through the Clirr report and fixed the low-hanging fruits in
> trunk. I think we need another RC. I've also update Apache Commons Compress
> and Net to their current versions.
>
> Then what we have to live with for 2.1 is BC breaks in two narrower areas:
>
> - Added methods to interfaces.
> - Changes in the Tar classes from our own Tar classes to Apache Commons
> Compress' Tar classes.
>
> That's how good it's going to get for now IMO.
>
> I would be perfectly OK with repackaging for 3.0 but then this would open
> the door to other changes that folks might want to make. I would be OK with
> saying this is 3.0 as is in this case.
>
> I'm still not 100% comfortable with the BC based on my experience with
> large projects with deep transitive dependencies.
>
> If the community VOTEs to release trunk (yes, another RC please) as 2.1
> then I'll live with it. Releasing as 3.0 (as is) would be safe and
> conservative.
>
> Gary
>
> On Fri, May 6, 2016 at 3:00 PM, sebb <se...@gmail.com> wrote:
>
> > On 6 May 2016 at 22:40, Gary Gregory <ga...@gmail.com> wrote:
> > > I'm creating a new thread here instead of hijacking the VOTE thread.
> > >
> > > First, let me express my gratitude to Stian Soiland-Reyes for RM'ing a
> > > release, I'm sure he did not know what he was getting himself into! ;-)
> >
> > Huh? ... that was/is Josh Elser.
> > Who does (also) deserve many thanks.
> >
> > > Part of me writing this here is flushing out for myself, voters, and
> > casual
> > > observers what it is we are doing ;-)
> > >
> > > We have BC breakage in VFS 2.1 RC1 in two areas:
> > >
> > > - Adding methods to public interfaces
> >
> > AFAIK that is only a SOURCE breakage.
> >
> > > - Other stuff like removing fields, changing fields from protected to
> > > private, changing method arg types.
> >
> > That does break BC if the objects are part of the public API.
> >
> > > Details:
> > >
> >
> https://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html
> > >
> > > I see three areas that need consideration:
> > >
> > > (0) For simple clients that only use the higher-level interfaces and
> > > methods, there are no problems. So this is a non-issue marker I
> suppose.
> >
> > Whether or not that affects simple clients depends on exactly which
> > fields and method args have changed. Are they part of the public API?
> > And if so, will simple clients use that part of the API?
> >
> > > (1) For advanced clients that get their fingers in deep into VFS, they
> > > break. Example:
> > >
> > > - org.apache.commons.vfs2.provider.tar.TarFileObject: Accessibility of
> > > field entry has been weakened from protected to private.
> > > - org.apache.commons.vfs2.provider.webdav.WebdavFileProvider: Removed
> > field
> > > AUTHENTICATOR_TYPES
> > > - and so on.
> > >
> > > Remedies for these kinds of breaks are simple and easy: Just change
> stuff
> > > back and mark @deprecated in Javadoc and @Deprecated.
> > >
> > > (2) For providers, they break unless they extend our root classes like
> > > AbstractFileObject and DefaultFileSystemManager, and use our default
> > > classes like DefaultFileContent.
> > > For "simple" providers, there probably won't be any issue, but who
> knows?
> > > Does anyone have a 2.0 provider?
> > > For advanced providers that do more of their own thing instead of
> reusing
> > > our base classes, then breakage.
> > >
> > > It seems to me that we should pick the low-hanging fruits and fix the
> > > simple stuff.
> > >
> > > All of this is moot if we were to go to 3.0 now.
> >
> > Which would not be source or binary compatible by design.
> >
> > > Thoughts?
> >
> > The easiest for Commons would obviously be to abandon 2.x and release
> 3.0.
> > That would be a chance to fix APIs properly.
> >
> > However, given the work that Josh has already put into 2.1 that seems
> > a waste of effort if we can either:
> > - eliminate the BC breaks, OR
> > - satisfy ourselves that the breaks will not affect (m)any users.
> >
> > > Gary
> > > --
> > > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > > Java Persistence with Hibernate, Second Edition
> > > <http://www.manning.com/bauer3/>
> > > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > > Spring Batch in Action <http://www.manning.com/templier/>
> > > Blog: http://garygregory.wordpress.com
> > > Home: http://garygregory.com/
> > > Tweet! http://twitter.com/GaryGregory
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
Matt Sicker <bo...@gmail.com>
Re: [VFS] BC breaks in VFS 2.1 RC1
Posted by Gary Gregory <ga...@gmail.com>.
OK, I've gone through the Clirr report and fixed the low-hanging fruits in
trunk. I think we need another RC. I've also update Apache Commons Compress
and Net to their current versions.
Then what we have to live with for 2.1 is BC breaks in two narrower areas:
- Added methods to interfaces.
- Changes in the Tar classes from our own Tar classes to Apache Commons
Compress' Tar classes.
That's how good it's going to get for now IMO.
I would be perfectly OK with repackaging for 3.0 but then this would open
the door to other changes that folks might want to make. I would be OK with
saying this is 3.0 as is in this case.
I'm still not 100% comfortable with the BC based on my experience with
large projects with deep transitive dependencies.
If the community VOTEs to release trunk (yes, another RC please) as 2.1
then I'll live with it. Releasing as 3.0 (as is) would be safe and
conservative.
Gary
On Fri, May 6, 2016 at 3:00 PM, sebb <se...@gmail.com> wrote:
> On 6 May 2016 at 22:40, Gary Gregory <ga...@gmail.com> wrote:
> > I'm creating a new thread here instead of hijacking the VOTE thread.
> >
> > First, let me express my gratitude to Stian Soiland-Reyes for RM'ing a
> > release, I'm sure he did not know what he was getting himself into! ;-)
>
> Huh? ... that was/is Josh Elser.
> Who does (also) deserve many thanks.
>
> > Part of me writing this here is flushing out for myself, voters, and
> casual
> > observers what it is we are doing ;-)
> >
> > We have BC breakage in VFS 2.1 RC1 in two areas:
> >
> > - Adding methods to public interfaces
>
> AFAIK that is only a SOURCE breakage.
>
> > - Other stuff like removing fields, changing fields from protected to
> > private, changing method arg types.
>
> That does break BC if the objects are part of the public API.
>
> > Details:
> >
> https://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html
> >
> > I see three areas that need consideration:
> >
> > (0) For simple clients that only use the higher-level interfaces and
> > methods, there are no problems. So this is a non-issue marker I suppose.
>
> Whether or not that affects simple clients depends on exactly which
> fields and method args have changed. Are they part of the public API?
> And if so, will simple clients use that part of the API?
>
> > (1) For advanced clients that get their fingers in deep into VFS, they
> > break. Example:
> >
> > - org.apache.commons.vfs2.provider.tar.TarFileObject: Accessibility of
> > field entry has been weakened from protected to private.
> > - org.apache.commons.vfs2.provider.webdav.WebdavFileProvider: Removed
> field
> > AUTHENTICATOR_TYPES
> > - and so on.
> >
> > Remedies for these kinds of breaks are simple and easy: Just change stuff
> > back and mark @deprecated in Javadoc and @Deprecated.
> >
> > (2) For providers, they break unless they extend our root classes like
> > AbstractFileObject and DefaultFileSystemManager, and use our default
> > classes like DefaultFileContent.
> > For "simple" providers, there probably won't be any issue, but who knows?
> > Does anyone have a 2.0 provider?
> > For advanced providers that do more of their own thing instead of reusing
> > our base classes, then breakage.
> >
> > It seems to me that we should pick the low-hanging fruits and fix the
> > simple stuff.
> >
> > All of this is moot if we were to go to 3.0 now.
>
> Which would not be source or binary compatible by design.
>
> > Thoughts?
>
> The easiest for Commons would obviously be to abandon 2.x and release 3.0.
> That would be a chance to fix APIs properly.
>
> However, given the work that Josh has already put into 2.1 that seems
> a waste of effort if we can either:
> - eliminate the BC breaks, OR
> - satisfy ourselves that the breaks will not affect (m)any users.
>
> > Gary
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > Java Persistence with Hibernate, Second Edition
> > <http://www.manning.com/bauer3/>
> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > Spring Batch in Action <http://www.manning.com/templier/>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [VFS] BC breaks in VFS 2.1 RC1
Posted by sebb <se...@gmail.com>.
On 6 May 2016 at 22:40, Gary Gregory <ga...@gmail.com> wrote:
> I'm creating a new thread here instead of hijacking the VOTE thread.
>
> First, let me express my gratitude to Stian Soiland-Reyes for RM'ing a
> release, I'm sure he did not know what he was getting himself into! ;-)
Huh? ... that was/is Josh Elser.
Who does (also) deserve many thanks.
> Part of me writing this here is flushing out for myself, voters, and casual
> observers what it is we are doing ;-)
>
> We have BC breakage in VFS 2.1 RC1 in two areas:
>
> - Adding methods to public interfaces
AFAIK that is only a SOURCE breakage.
> - Other stuff like removing fields, changing fields from protected to
> private, changing method arg types.
That does break BC if the objects are part of the public API.
> Details:
> https://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html
>
> I see three areas that need consideration:
>
> (0) For simple clients that only use the higher-level interfaces and
> methods, there are no problems. So this is a non-issue marker I suppose.
Whether or not that affects simple clients depends on exactly which
fields and method args have changed. Are they part of the public API?
And if so, will simple clients use that part of the API?
> (1) For advanced clients that get their fingers in deep into VFS, they
> break. Example:
>
> - org.apache.commons.vfs2.provider.tar.TarFileObject: Accessibility of
> field entry has been weakened from protected to private.
> - org.apache.commons.vfs2.provider.webdav.WebdavFileProvider: Removed field
> AUTHENTICATOR_TYPES
> - and so on.
>
> Remedies for these kinds of breaks are simple and easy: Just change stuff
> back and mark @deprecated in Javadoc and @Deprecated.
>
> (2) For providers, they break unless they extend our root classes like
> AbstractFileObject and DefaultFileSystemManager, and use our default
> classes like DefaultFileContent.
> For "simple" providers, there probably won't be any issue, but who knows?
> Does anyone have a 2.0 provider?
> For advanced providers that do more of their own thing instead of reusing
> our base classes, then breakage.
>
> It seems to me that we should pick the low-hanging fruits and fix the
> simple stuff.
>
> All of this is moot if we were to go to 3.0 now.
Which would not be source or binary compatible by design.
> Thoughts?
The easiest for Commons would obviously be to abandon 2.x and release 3.0.
That would be a chance to fix APIs properly.
However, given the work that Josh has already put into 2.1 that seems
a waste of effort if we can either:
- eliminate the BC breaks, OR
- satisfy ourselves that the breaks will not affect (m)any users.
> Gary
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org