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" <els...@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<seb...@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<garydgreg...@gmail.com> wrote: >>> >>>> On Fri, May 6, 2016 at 10:20 PM, Ralph Goers<ralph.go...@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<boa...@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<garydgreg...@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<seb...@gmail.com> wrote: >>>>>>> >>>>>>> On 6 May 2016 at 22:40, Gary Gregory<garydgreg...@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: garydgreg...@gmail.com | ggreg...@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-unsubscr...@commons.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@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<boa...@gmail.com> >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>>>> >>>> -- >>>> E-Mail: garydgreg...@gmail.com | ggreg...@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-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >>> >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
