commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <els...@apache.org>
Subject Re: [VFS] BC breaks in VFS 2.1 RC1
Date Mon, 09 May 2016 00:19:34 GMT
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"<elserj@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<sebbaz@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<garydgregory@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<boards@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<garydgregory@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<sebbaz@gmail.com>
  wrote:
>>>>>>>>
>>>>>>>> On 6 May 2016 at 22:40, Gary Gregory<garydgregory@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<boards@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


Mime
View raw message