commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [VFS] BC breaks in VFS 2.1 RC1
Date Sun, 08 May 2016 19:38:45 GMT
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
>
>

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