I think you guys missed what the suggestion was. If it is possible we could just add a subproject to vfs2 that provides the needed glue between the existing providers and the Java 7 api. I would imagine this subproject would only be included when compiling with a java 7 compiler, otherwise it would be skipped.
Ralph On Dec 8, 2011, at 6:46 AM, sebb wrote: > On 8 December 2011 13:35, Jörg Schaible <joerg.schai...@scalaris.com> wrote: >> sebb wrote: >> >>> On 8 December 2011 11:01, Jörg Schaible <joerg.schai...@scalaris.com> >>> wrote: >>>> sebb wrote: >>>> >>>>> On 8 December 2011 07:11, Jörg Schaible <joerg.schai...@scalaris.com> >>>>> wrote: >>>>>> Hi, >>>>>> >>>>>> Gary Gregory wrote: >>>>>> >>>>>>> I am thinking of a different package name, not just version for VFS on >>>>>>> Java 7 because we might want to release more VFS2-based versions that >>>>>>> do break binary compatibility. >>>>>>> >>>>>>> We can retain the VFS name and brand for the project, but I'd prefer >>>>>>> o.a.c.vfs<n> to be for VFS2 based work and to create o.a.c.filesystem >>>>>>> (or fs) for Java 7 FileSystem-based work. >>>>>>> >>>>>>> Thoughts? >>>>>> >>>>>> Until now we had the policy to add the major number to the package name >>>>>> i.e. this is org.apache.commons.vfs3 here. >>>>> >>>>> As I already mentioned earlier in this thread, that may clash with >>>>> updates to VFS 2.x that need a new package name. >>>> >>>> And how long do you expect that both branches are actively developed? It >>>> took years from 1.x to 2.x. And why should someone start active >>>> development with vfs2 if there's already vfs3 around? >>> >>> Because AIUI VFS3 targets Java 1.7 up; it won't work on Java 1.5 or 1.6. >>> >>> I hope no-one is suggesting that VFS no longer be developed for Java >>> 1.6 just yet. >> >> I did not say that, but I don't expect major refactorings and an API >> redesign for VFS2 if there's already a successor (and this time with an API >> defined by the JDK). We should be interested ourselves to stay API- >> compatible in the VFS2 series. > > Of course, but it may not be possible to maintain binary compatibility. > Are we sure that new API is perfect? Or at least fixable without > breaking compat? > > I suppose we could use vfs2a, vfs2b etc. > > However, given that VFS3 is going to be a different API altogether, I > think it would be better to use a package name that is more > distinctive. > >> - Jörg >> >> >> --------------------------------------------------------------------- >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
