Re: [VFS] BC breaks in VFS 2.1 RC1

[Gary Gregory]

On Fri, May 6, 2016 at 10:20 PM, Ralph Goers 
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  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  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  wrote:
> >>
> >>> On 6 May 2016 at 22:40, Gary Gregory  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.
> >>>
>  

Re: [VFS] BC breaks in VFS 2.1 RC1

[Ralph Goers]

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  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  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  wrote:
>> 
>>> On 6 May 2016 at 22:40, Gary Gregory  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
 
 JUnit in Action, Second Edition 
 Spring Batch in Action 
 Blog: 

Re: [VFS] BC breaks in VFS 2.1 RC1

[Gary Gregory]

On Fri, May 6, 2016 at 8:40 PM, Matt Sicker  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  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  wrote:
> >
> > > On 6 May 2016 at 22:40, Gary Gregory  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 

Re: [VFS] BC breaks in VFS 2.1 RC1

[Matt Sicker]

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  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  wrote:
>
> > On 6 May 2016 at 22:40, Gary Gregory  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
> > > 
> > > JUnit in Action, Second Edition 
> > > Spring Batch in Action 
> > > 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 

Re: [VFS] BC breaks in VFS 2.1 RC1

[Gary Gregory]

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  wrote:

> On 6 May 2016 at 22:40, Gary Gregory  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
> > 
> > JUnit in Action, Second Edition 
> > Spring Batch in Action 
> > 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

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VFS] BC breaks in VFS 2.1 RC1

[Jörg Schaible]

sebb wrote:

> On 6 May 2016 at 22:40, Gary Gregory  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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VFS] BC breaks in VFS 2.1 RC1

[Gary Gregory]

On Fri, May 6, 2016 at 3:00 PM, sebb  wrote:

> On 6 May 2016 at 22:40, Gary Gregory  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: garydgreg...@gmail.com | ggreg...@apache.org
> > Java Persistence with Hibernate, Second Edition
> > 
> > JUnit in Action, Second Edition 
> > Spring Batch in Action 
> > 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

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VFS] BC breaks in VFS 2.1 RC1

[sebb]

On 6 May 2016 at 22:40, Gary Gregory  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
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> 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

[VFS] BC breaks in VFS 2.1 RC1

[Gary Gregory]

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: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Josh Elser]

Gary Gregory wrote:

Some of the versions of jars in this page are out of date.

Why not refer to the generated page:
https://home.apache.org/~elserj/commons/commons-vfs-2.1/dependency-management.html
from the "About" page and other places if any?


+1

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons CSV 1.3 based on RC1

[Gary Gregory]

Hit 'Send' too soon:

+1

Building from src zip, MD5, SHA1, ASC OK.

Builds OK with 'mvn clean site' using (aside from the usual slf4j BC mess
failures):

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T08:41:47-08:00)
Maven home: E:\Java\apache-maven-3.3.9\bin\..
Java version: 1.8.0_91, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_91\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"

and cleanly with:

Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19
05:51:28-0800)
Maven home: E:\Java\apache-maven-3.0.5
Java version: 1.7.0_79, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_79\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"

Gary


On Fri, May 6, 2016 at 1:47 PM, Gary Gregory  wrote:

> +1
>
> Building from src zip, MD5, SHA1, ASC OK.
>
> Builds OK with 'mvn clean site' using:
>
>
> On Fri, May 6, 2016 at 1:12 AM, Benedikt Ritter 
> wrote:
>
>> Hi,
>>
>> we have fixed some bugs and added some nice new features since we released
>> Apache Commons CSV 1.2. So I'd like to release Apache Commons CSV 1.3
>> based
>> on RC 1.
>>
>> Apache Commons CSV 1.3 RC1 is available for review here:
>>   https://dist.apache.org/repos/dist/dev/commons/csv/csv-1.3-RC1
>> (revision
>> 13550)
>>
>> Maven artifacty are here:
>>
>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1165/org/apache/commons/commons-csv/1.3/
>>
>> These are the Maven artifacts and their hashes:
>>
>> commons-csv-1.3-javadoc.jar
>> (SHA1: dfeed187293d2d5ed3f8b26e096474ff8350a254)
>> commons-csv-1.3-sources.jar
>> (SHA1: 7841722762e93d6bd4419f91e140b6a16e167fe1)
>> commons-csv-1.3-test-sources.jar
>> (SHA1: c6c90708e686e1a17441632e417ccf91d78d87f2)
>> commons-csv-1.3-tests.jar
>> (SHA1: fdf822005dca524c329c3fd2f0abc149a885b52a)
>> commons-csv-1.3.jar
>> (SHA1: aeed8320e1b86b27e0b477a898eb7dd049526963)
>> commons-csv-1.3.pom
>> (SHA1: 8916753d403a30d53b9a105372eee620cd53b802)
>>
>> Details of changes since 1.2 are in the release notes:
>>
>>
>> https://dist.apache.org/repos/dist/dev/commons/csv/csv-1.3-RC1/RELEASE-NOTES.txt
>>   http://home.apache.org/~britter/commons/csv-1.3-RC1/changes-report.html
>>
>> I have tested this on Mac OS 10.11.4 with:
>>   JDK 1.6 & Maven 3.2.5
>>   JDK 7 & Maven 3.3.9
>>   JDK 8 & Maven 3.3.9
>>
>> The tag is here:
>>   https://svn.apache.org/repos/asf/commons/proper/csv/tags/csv-1.3-RC1
>>  (revision 1742508)
>>
>> Site:
>>http://home.apache.org/~britter/commons/csv-1.3-RC1
>> (note some *relative links are broken and the 1.3 directories are not yet
>> created - these will be ok once the site is deployed)
>> (also note the site navigation has a minor error. There are two entires
>> for
>> JavaDoc 1.2 and Site Archive 1.2. I will correct that once the site is
>> deployed)
>>
>> Clirr Report (compared to 1.2):
>>   http://home.apache.org/~britter/commons/csv-1.3-RC1/clirr-report.html
>>
>> RAT Report:
>>http://home.apache.org/~britter/commons/csv-1.3-RC1/rat-report.html
>>
>> KEYS:
>>   https://www.apache.org/dist/commons/KEYS
>>
>> Please review the release candidate and vote. This vote will close no
>> sooner that 72 hours from now, i.e. sometime after 10:30 CEST (UTC+2)
>> 09-May 2016
>>
>> [ ] +1 Release these artifacts
>> [ ] +0 OK, but...
>> [ ] -0 OK, but really should fix...
>> [ ] -1 I oppose this release because...
>>
>>  Thanks!
>> Benedikt
>>
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VOTE] Release Apache Commons CSV 1.3 based on RC1

[Gary Gregory]

+1

Building from src zip, MD5, SHA1, ASC OK.

Builds OK with 'mvn clean site' using:


On Fri, May 6, 2016 at 1:12 AM, Benedikt Ritter  wrote:

> Hi,
>
> we have fixed some bugs and added some nice new features since we released
> Apache Commons CSV 1.2. So I'd like to release Apache Commons CSV 1.3 based
> on RC 1.
>
> Apache Commons CSV 1.3 RC1 is available for review here:
>   https://dist.apache.org/repos/dist/dev/commons/csv/csv-1.3-RC1 (revision
> 13550)
>
> Maven artifacty are here:
>
>
> https://repository.apache.org/content/repositories/orgapachecommons-1165/org/apache/commons/commons-csv/1.3/
>
> These are the Maven artifacts and their hashes:
>
> commons-csv-1.3-javadoc.jar
> (SHA1: dfeed187293d2d5ed3f8b26e096474ff8350a254)
> commons-csv-1.3-sources.jar
> (SHA1: 7841722762e93d6bd4419f91e140b6a16e167fe1)
> commons-csv-1.3-test-sources.jar
> (SHA1: c6c90708e686e1a17441632e417ccf91d78d87f2)
> commons-csv-1.3-tests.jar
> (SHA1: fdf822005dca524c329c3fd2f0abc149a885b52a)
> commons-csv-1.3.jar
> (SHA1: aeed8320e1b86b27e0b477a898eb7dd049526963)
> commons-csv-1.3.pom
> (SHA1: 8916753d403a30d53b9a105372eee620cd53b802)
>
> Details of changes since 1.2 are in the release notes:
>
>
> https://dist.apache.org/repos/dist/dev/commons/csv/csv-1.3-RC1/RELEASE-NOTES.txt
>   http://home.apache.org/~britter/commons/csv-1.3-RC1/changes-report.html
>
> I have tested this on Mac OS 10.11.4 with:
>   JDK 1.6 & Maven 3.2.5
>   JDK 7 & Maven 3.3.9
>   JDK 8 & Maven 3.3.9
>
> The tag is here:
>   https://svn.apache.org/repos/asf/commons/proper/csv/tags/csv-1.3-RC1
>  (revision 1742508)
>
> Site:
>http://home.apache.org/~britter/commons/csv-1.3-RC1
> (note some *relative links are broken and the 1.3 directories are not yet
> created - these will be ok once the site is deployed)
> (also note the site navigation has a minor error. There are two entires for
> JavaDoc 1.2 and Site Archive 1.2. I will correct that once the site is
> deployed)
>
> Clirr Report (compared to 1.2):
>   http://home.apache.org/~britter/commons/csv-1.3-RC1/clirr-report.html
>
> RAT Report:
>http://home.apache.org/~britter/commons/csv-1.3-RC1/rat-report.html
>
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote. This vote will close no
> sooner that 72 hours from now, i.e. sometime after 10:30 CEST (UTC+2)
> 09-May 2016
>
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
>
>  Thanks!
> Benedikt
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Gary Gregory]

I am recording here what I've found and tested (no VOTE yet):

Minor:

[INFO] --- maven-bundle-plugin:3.0.1:manifest (bundle-manifest) @
commons-vfs2-project ---
[WARN] Ignoring project type pom - supportedProjectTypes = [jar, bundle]

Plain wrong but not a blocker IMO (could be hacked post release):

https://home.apache.org/~elserj/commons/commons-vfs-2.1/download.html

Some of the versions of jars in this page are out of date.

Why not refer to the generated page:
https://home.apache.org/~elserj/commons/commons-vfs-2.1/dependency-management.html
from the "About" page and other places if any?

Based on the src distribution zip file:

MD5, SHA1, ASC, reports OK (Clirr is a separate topic).

Builds OK running: 'mvn clean test' and then 'mvn package -DskipTests' with:

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T08:41:47-08:00)
Maven home: E:\Java\apache-maven-3.3.9\bin\..
Java version: 1.8.0_91, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_91\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"

Gary

On Tue, May 3, 2016 at 8:43 PM, Josh Elser  wrote:

> All,
>
> Please consider the following for Apache Commons VFS2 version 2.1 (rc1).
>
> Maven repository:
> https://repository.apache.org/content/repositories/orgapachecommons-1163
> Artifacts: https://dist.apache.org/repos/dist/dev/commons/vfs/ r13511
>
> MD5  commons-vfs-distribution-2.1-bin.tar.gz
> 1192914d1ba6f8ca3a2a688feeff602c
> SHA1 commons-vfs-distribution-2.1-bin.tar.gz
> 285097f1db6cbc9d76ae5bb3adf66a315344a864
> MD5  commons-vfs-distribution-2.1-src.tar.gz
> 0646187562302a7dcfbddb93204fc9eb
> SHA1 commons-vfs-distribution-2.1-src.tar.gz
> 24bab87fd4049b9389acd1b6e272f405630aeb25
> MD5  commons-vfs-distribution-2.1-bin.zip 3785874aa0cda64d68acbb8fb7db8bea
> SHA1 commons-vfs-distribution-2.1-bin.zip
> 942a23fb202b89b1a8432beeb0a66469959e661d
> MD5  commons-vfs-distribution-2.1-src.zip c8ef43d308bed1b3ffcb363c15285176
> SHA1 commons-vfs-distribution-2.1-src.zip
> 1ddf0d218f659766f136894eab0beca504ab9f8c
>
> Signed with 4677D66C from
> https://dist.apache.org/repos/dist/release/commons/KEYS
>
> SVN tag is available at
> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.1-RC1/
> r1742212
>
> Staged Maven website:
> http://home.apache.org/~elserj/commons/commons-vfs-2.1/
>
> All reports are available in the provided staged Maven site (see "Project
> Reports" at the root-level as well as under each sub-module).
> JIRA-generated release notes are available in the dist.a.o "Artifacts"
> repository. Unit tests pass and the RC was built util JDK6.
>
> (For Sebb) A direct Clirr link
> http://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html
>
> Changes since rc0:
>
> * Improved release notes and website for compatibility
> * Fixes to pom.xml for building website
>
> This vote will be open for 72-hours, 2016/05/06 0400 UTC.
>
>   [ ] +1 Release these artifacts as version 2.1
>   [ ] 0  OK, but...
>   [ ] -1 I oppose these artifacts as version 2.1 because..
>
> - Josh
>
> -
> 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

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Josh Elser]

Thanks Gary! Will keep an eye out.

Gary Gregory wrote:

Sorry, quite busy this week, I'll try to take a look later today or this
weekend.

Gary
On May 6, 2016 7:24 AM, "Josh Elser"  wrote:


Well, we've already passed the 3day vote window and have no binding votes.
**PMC, please vote.**

(Thanks to Stian for the nonbinding vote)

Consider the vote extended another 48hrs.
On May 3, 2016 11:43 PM, "Josh Elser"  wrote:


All,

Please consider the following for Apache Commons VFS2 version 2.1 (rc1).

Maven repository:
https://repository.apache.org/content/repositories/orgapachecommons-1163
Artifacts: https://dist.apache.org/repos/dist/dev/commons/vfs/ r13511

MD5  commons-vfs-distribution-2.1-bin.tar.gz
1192914d1ba6f8ca3a2a688feeff602c
SHA1 commons-vfs-distribution-2.1-bin.tar.gz
285097f1db6cbc9d76ae5bb3adf66a315344a864
MD5  commons-vfs-distribution-2.1-src.tar.gz
0646187562302a7dcfbddb93204fc9eb
SHA1 commons-vfs-distribution-2.1-src.tar.gz
24bab87fd4049b9389acd1b6e272f405630aeb25
MD5  commons-vfs-distribution-2.1-bin.zip

3785874aa0cda64d68acbb8fb7db8bea

SHA1 commons-vfs-distribution-2.1-bin.zip
942a23fb202b89b1a8432beeb0a66469959e661d
MD5  commons-vfs-distribution-2.1-src.zip

c8ef43d308bed1b3ffcb363c15285176

SHA1 commons-vfs-distribution-2.1-src.zip
1ddf0d218f659766f136894eab0beca504ab9f8c

Signed with 4677D66C from
https://dist.apache.org/repos/dist/release/commons/KEYS

SVN tag is available at


https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.1-RC1/

r1742212

Staged Maven website:
http://home.apache.org/~elserj/commons/commons-vfs-2.1/

All reports are available in the provided staged Maven site (see "Project
Reports" at the root-level as well as under each sub-module).
JIRA-generated release notes are available in the dist.a.o "Artifacts"
repository. Unit tests pass and the RC was built util JDK6.

(For Sebb) A direct Clirr link


http://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html

Changes since rc0:

* Improved release notes and website for compatibility
* Fixes to pom.xml for building website

This vote will be open for 72-hours, 2016/05/06 0400 UTC.

   [ ] +1 Release these artifacts as version 2.1
   [ ] 0  OK, but...
   [ ] -1 I oppose these artifacts as version 2.1 because..

- Josh





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Gary Gregory]

Sorry, quite busy this week, I'll try to take a look later today or this
weekend.

Gary
On May 6, 2016 7:24 AM, "Josh Elser"  wrote:

> Well, we've already passed the 3day vote window and have no binding votes.
> **PMC, please vote.**
>
> (Thanks to Stian for the nonbinding vote)
>
> Consider the vote extended another 48hrs.
> On May 3, 2016 11:43 PM, "Josh Elser"  wrote:
>
> > All,
> >
> > Please consider the following for Apache Commons VFS2 version 2.1 (rc1).
> >
> > Maven repository:
> > https://repository.apache.org/content/repositories/orgapachecommons-1163
> > Artifacts: https://dist.apache.org/repos/dist/dev/commons/vfs/ r13511
> >
> > MD5  commons-vfs-distribution-2.1-bin.tar.gz
> > 1192914d1ba6f8ca3a2a688feeff602c
> > SHA1 commons-vfs-distribution-2.1-bin.tar.gz
> > 285097f1db6cbc9d76ae5bb3adf66a315344a864
> > MD5  commons-vfs-distribution-2.1-src.tar.gz
> > 0646187562302a7dcfbddb93204fc9eb
> > SHA1 commons-vfs-distribution-2.1-src.tar.gz
> > 24bab87fd4049b9389acd1b6e272f405630aeb25
> > MD5  commons-vfs-distribution-2.1-bin.zip
> 3785874aa0cda64d68acbb8fb7db8bea
> > SHA1 commons-vfs-distribution-2.1-bin.zip
> > 942a23fb202b89b1a8432beeb0a66469959e661d
> > MD5  commons-vfs-distribution-2.1-src.zip
> c8ef43d308bed1b3ffcb363c15285176
> > SHA1 commons-vfs-distribution-2.1-src.zip
> > 1ddf0d218f659766f136894eab0beca504ab9f8c
> >
> > Signed with 4677D66C from
> > https://dist.apache.org/repos/dist/release/commons/KEYS
> >
> > SVN tag is available at
> >
> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.1-RC1/
> > r1742212
> >
> > Staged Maven website:
> > http://home.apache.org/~elserj/commons/commons-vfs-2.1/
> >
> > All reports are available in the provided staged Maven site (see "Project
> > Reports" at the root-level as well as under each sub-module).
> > JIRA-generated release notes are available in the dist.a.o "Artifacts"
> > repository. Unit tests pass and the RC was built util JDK6.
> >
> > (For Sebb) A direct Clirr link
> >
> http://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html
> >
> > Changes since rc0:
> >
> > * Improved release notes and website for compatibility
> > * Fixes to pom.xml for building website
> >
> > This vote will be open for 72-hours, 2016/05/06 0400 UTC.
> >
> >   [ ] +1 Release these artifacts as version 2.1
> >   [ ] 0  OK, but...
> >   [ ] -1 I oppose these artifacts as version 2.1 because..
> >
> > - Josh
> >
>

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Josh Elser]

Well, we've already passed the 3day vote window and have no binding votes.
**PMC, please vote.**

(Thanks to Stian for the nonbinding vote)

Consider the vote extended another 48hrs.
On May 3, 2016 11:43 PM, "Josh Elser"  wrote:

> All,
>
> Please consider the following for Apache Commons VFS2 version 2.1 (rc1).
>
> Maven repository:
> https://repository.apache.org/content/repositories/orgapachecommons-1163
> Artifacts: https://dist.apache.org/repos/dist/dev/commons/vfs/ r13511
>
> MD5  commons-vfs-distribution-2.1-bin.tar.gz
> 1192914d1ba6f8ca3a2a688feeff602c
> SHA1 commons-vfs-distribution-2.1-bin.tar.gz
> 285097f1db6cbc9d76ae5bb3adf66a315344a864
> MD5  commons-vfs-distribution-2.1-src.tar.gz
> 0646187562302a7dcfbddb93204fc9eb
> SHA1 commons-vfs-distribution-2.1-src.tar.gz
> 24bab87fd4049b9389acd1b6e272f405630aeb25
> MD5  commons-vfs-distribution-2.1-bin.zip 3785874aa0cda64d68acbb8fb7db8bea
> SHA1 commons-vfs-distribution-2.1-bin.zip
> 942a23fb202b89b1a8432beeb0a66469959e661d
> MD5  commons-vfs-distribution-2.1-src.zip c8ef43d308bed1b3ffcb363c15285176
> SHA1 commons-vfs-distribution-2.1-src.zip
> 1ddf0d218f659766f136894eab0beca504ab9f8c
>
> Signed with 4677D66C from
> https://dist.apache.org/repos/dist/release/commons/KEYS
>
> SVN tag is available at
> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.1-RC1/
> r1742212
>
> Staged Maven website:
> http://home.apache.org/~elserj/commons/commons-vfs-2.1/
>
> All reports are available in the provided staged Maven site (see "Project
> Reports" at the root-level as well as under each sub-module).
> JIRA-generated release notes are available in the dist.a.o "Artifacts"
> repository. Unit tests pass and the RC was built util JDK6.
>
> (For Sebb) A direct Clirr link
> http://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html
>
> Changes since rc0:
>
> * Improved release notes and website for compatibility
> * Fixes to pom.xml for building website
>
> This vote will be open for 72-hours, 2016/05/06 0400 UTC.
>
>   [ ] +1 Release these artifacts as version 2.1
>   [ ] 0  OK, but...
>   [ ] -1 I oppose these artifacts as version 2.1 because..
>
> - Josh
>

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Josh Elser]

On May 6, 2016 2:45 AM, "Jörg Schaible"  wrote:
>
> Hi Josh,
>
> Josh Elser wrote:
>
> > Jörg Schaible wrote:
> >> Jörg Schaible wrote:
> >>
> >>> >  Hi Josh,
> >>> >
> >>> >  Josh Elser wrote:
> >>> >
>  >>  Oh, well then! No pressure:)
>  >>
>  >>  I'll have to find some time to re-read all of the conversation
>  >>  between Jörg and Stian, but my initial reaction is the same as
what
>  >>  you were implying: compatibility across more JVMs would be great,
>  >>  but shouldn't block this 2.1 release.
> >>
> >> Just an additional remark: Compatibility across more JVMs*is*  an
issue,
> >> since there are platforms where you have no other choice (IBM AIX, Mac,
> >> most Linux distributions use OpenJDK by default).
> >>
> >
> > Is 2.1's compatibility across JVMs worse than 2.0's was?
>
> It passed last time. We have now new JDKs though and don't support the
Java
> 5 ones anymore and have some new tests.
>
> > What are the
> > guarantees put forth by those involved with commons-vfs for
> > compatibility WRT JVMs?
>
> If issues are reported we already identified as problem with the JDK, we
can
> simply relax and give an appropriate pointer. This is e.g. the case for
> commons-io where the IBM JDKs fail with UTF-16LE.
>
> > I'm not nit-picking JVM support -- I'm nit-picking it's severity to
> > block v2.1 for being released.
>
> As said, I do not block it, but for *my* vote, I want to know, why some
JDKs
> fail.
>
> Cheers,
> Jörg

Great, thanks for clarifying. Let's deal with this at the earliest
convenience after 2.1.

Re: Fixing the commons-io javadoc

[Benson Margulies]

I think I've fixed it.


On Fri, May 6, 2016 at 9:35 AM, sebb  wrote:
> CMS does not apply to the component websites.
>
> It only applies to the parent site.
>
> On 6 May 2016 at 14:21, Benedikt Ritter  wrote:
>> Benedikt Ritter  schrieb am Fr., 6. Mai 2016 um
>> 15:20 Uhr:
>>
>>> Hello Benson,
>>>
>>> Benson Margulies  schrieb am Fr., 6. Mai 2016 um
>>> 14:29 Uhr:
>>>
 I'd like to.

 Problem 1:

 On this page, the 2.4 link points to a generic 'api-release' directory
 instead of to 2.4.

 http://commons.apache.org/proper/commons-io/

 I'd fix that, but when I use the CMS bookmarklet on this page, I'm not
 shown the content of this page, I'm shown the top of the entire
 commons tree.

 Problem 2:

 olamy left

  '1451336  olamy
 scm:svn:
 https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-i/
 '

 in the top level pom. I patched it to contain the missing 'o', but
 that's not right. It should end with api-release, and then the release
 process should include a manual step of renaming it, or it should have
 ${project.version} in it.

 So now the 2.5 content is all checked in, up one level from where it
 belongs.

 If someone can remind me about how to edit the links on the page, I'll
 sweep the 2.5 content into the api-2.5 directory and then patch up the
 links.

>>>
>>> You can modify the side sources below src/site and dann publish the site
>>> via mvn site-deploy.
>>>
>>
>> omg, that sentence was a complete fail :-) Second try:
>>
>> You can modify the site sources below src/site and then publish the site
>> via mvn site-deploy.
>>
>>
>>>
>>> If you can't fix the problems this way, you can checkout the site
>>> directory from
>>> https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-io
>>> and edit it directly. This can be necessary for the parts of the website
>>> that are not generated by the site build (for example JavaDoc archives from
>>> old releases).
>>>
>>> HTH,
>>> Benedikt
>>>
>>>

 -
 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

Re: Fixing the commons-io javadoc

[sebb]

CMS does not apply to the component websites.

It only applies to the parent site.

On 6 May 2016 at 14:21, Benedikt Ritter  wrote:
> Benedikt Ritter  schrieb am Fr., 6. Mai 2016 um
> 15:20 Uhr:
>
>> Hello Benson,
>>
>> Benson Margulies  schrieb am Fr., 6. Mai 2016 um
>> 14:29 Uhr:
>>
>>> I'd like to.
>>>
>>> Problem 1:
>>>
>>> On this page, the 2.4 link points to a generic 'api-release' directory
>>> instead of to 2.4.
>>>
>>> http://commons.apache.org/proper/commons-io/
>>>
>>> I'd fix that, but when I use the CMS bookmarklet on this page, I'm not
>>> shown the content of this page, I'm shown the top of the entire
>>> commons tree.
>>>
>>> Problem 2:
>>>
>>> olamy left
>>>
>>>  '1451336  olamy
>>> scm:svn:
>>> https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-i/
>>> '
>>>
>>> in the top level pom. I patched it to contain the missing 'o', but
>>> that's not right. It should end with api-release, and then the release
>>> process should include a manual step of renaming it, or it should have
>>> ${project.version} in it.
>>>
>>> So now the 2.5 content is all checked in, up one level from where it
>>> belongs.
>>>
>>> If someone can remind me about how to edit the links on the page, I'll
>>> sweep the 2.5 content into the api-2.5 directory and then patch up the
>>> links.
>>>
>>
>> You can modify the side sources below src/site and dann publish the site
>> via mvn site-deploy.
>>
>
> omg, that sentence was a complete fail :-) Second try:
>
> You can modify the site sources below src/site and then publish the site
> via mvn site-deploy.
>
>
>>
>> If you can't fix the problems this way, you can checkout the site
>> directory from
>> https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-io
>> and edit it directly. This can be necessary for the parts of the website
>> that are not generated by the site build (for example JavaDoc archives from
>> old releases).
>>
>> HTH,
>> Benedikt
>>
>>
>>>
>>> -
>>> 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

Re: Fixing the commons-io javadoc

[Benedikt Ritter]

Benedikt Ritter  schrieb am Fr., 6. Mai 2016 um
15:20 Uhr:

> Hello Benson,
>
> Benson Margulies  schrieb am Fr., 6. Mai 2016 um
> 14:29 Uhr:
>
>> I'd like to.
>>
>> Problem 1:
>>
>> On this page, the 2.4 link points to a generic 'api-release' directory
>> instead of to 2.4.
>>
>> http://commons.apache.org/proper/commons-io/
>>
>> I'd fix that, but when I use the CMS bookmarklet on this page, I'm not
>> shown the content of this page, I'm shown the top of the entire
>> commons tree.
>>
>> Problem 2:
>>
>> olamy left
>>
>>  '1451336  olamy
>> scm:svn:
>> https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-i/
>> '
>>
>> in the top level pom. I patched it to contain the missing 'o', but
>> that's not right. It should end with api-release, and then the release
>> process should include a manual step of renaming it, or it should have
>> ${project.version} in it.
>>
>> So now the 2.5 content is all checked in, up one level from where it
>> belongs.
>>
>> If someone can remind me about how to edit the links on the page, I'll
>> sweep the 2.5 content into the api-2.5 directory and then patch up the
>> links.
>>
>
> You can modify the side sources below src/site and dann publish the site
> via mvn site-deploy.
>

omg, that sentence was a complete fail :-) Second try:

You can modify the site sources below src/site and then publish the site
via mvn site-deploy.


>
> If you can't fix the problems this way, you can checkout the site
> directory from
> https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-io
> and edit it directly. This can be necessary for the parts of the website
> that are not generated by the site build (for example JavaDoc archives from
> old releases).
>
> HTH,
> Benedikt
>
>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>

Re: Fixing the commons-io javadoc

[Benedikt Ritter]

Hello Benson,

Benson Margulies  schrieb am Fr., 6. Mai 2016 um
14:29 Uhr:

> I'd like to.
>
> Problem 1:
>
> On this page, the 2.4 link points to a generic 'api-release' directory
> instead of to 2.4.
>
> http://commons.apache.org/proper/commons-io/
>
> I'd fix that, but when I use the CMS bookmarklet on this page, I'm not
> shown the content of this page, I'm shown the top of the entire
> commons tree.
>
> Problem 2:
>
> olamy left
>
>  '1451336  olamy
> scm:svn:
> https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-i/
> '
>
> in the top level pom. I patched it to contain the missing 'o', but
> that's not right. It should end with api-release, and then the release
> process should include a manual step of renaming it, or it should have
> ${project.version} in it.
>
> So now the 2.5 content is all checked in, up one level from where it
> belongs.
>
> If someone can remind me about how to edit the links on the page, I'll
> sweep the 2.5 content into the api-2.5 directory and then patch up the
> links.
>

You can modify the side sources below src/site and dann publish the site
via mvn site-deploy.

If you can't fix the problems this way, you can checkout the site directory
from
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-io
and edit it directly. This can be necessary for the parts of the website
that are not generated by the site build (for example JavaDoc archives from
old releases).

HTH,
Benedikt


>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Fixing the commons-io javadoc

[Benson Margulies]

I'd like to.

Problem 1:

On this page, the 2.4 link points to a generic 'api-release' directory
instead of to 2.4.

http://commons.apache.org/proper/commons-io/

I'd fix that, but when I use the CMS bookmarklet on this page, I'm not
shown the content of this page, I'm shown the top of the entire
commons tree.

Problem 2:

olamy left

 '1451336  olamy
scm:svn:https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-i/'

in the top level pom. I patched it to contain the missing 'o', but
that's not right. It should end with api-release, and then the release
process should include a manual step of renaming it, or it should have
${project.version} in it.

So now the 2.5 content is all checked in, up one level from where it belongs.

If someone can remind me about how to edit the links on the page, I'll
sweep the 2.5 content into the api-2.5 directory and then patch up the
links.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VALIDATOR] CheckDigit implementation for German identity cards?

[sebb]

On 5 May 2016 at 20:46, Benedikt Ritter  wrote:
> Benedikt Ritter  schrieb am Di., 3. Mai 2016 um
> 22:49 Uhr:
>
>> Hello,
>>
>> I have the need for a validator implementation that can check German
>> identity card numbers. It's pretty simple to implement something like this
>> using ModulusCheckDigit. Now I'm wondering whether this would be a good
>> addition for [validator]. It is specific to German identity cards, but
>> maybe we could start an idcard package which contains routine for different
>> country identity cards.
>>
>> If this doesn't belong into [validator] I'll probably publish it via my
>> github account :-)
>>
>
> A CheckDigit implementation for German identity card numbers would look
> like this: https://gist.github.com/britter/ff959c42cab142a828247ce0673f6215

Looks like some/most of the code could be used in other check digit
implementations.
In which case the routines should be pushed up into a superclass and
the German version could just be a constant instance.
As is done with the bank cards.

>
>>
>> Best regards,
>> Benedikt
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VALIDATOR] CheckDigit implementation for German identity cards?

[sebb]

On 5 May 2016 at 20:50, Gary Gregory  wrote:
> I wonder if we should have packages for various country codes like
> o.a.c.validator.de ? Then this class would go in there.

Seems excessive to have a separate package for a single class file.

> Gary
>
> On Thu, May 5, 2016 at 12:46 PM, Benedikt Ritter  wrote:
>
>> Benedikt Ritter  schrieb am Di., 3. Mai 2016 um
>> 22:49 Uhr:
>>
>> > Hello,
>> >
>> > I have the need for a validator implementation that can check German
>> > identity card numbers. It's pretty simple to implement something like
>> this
>> > using ModulusCheckDigit. Now I'm wondering whether this would be a good
>> > addition for [validator]. It is specific to German identity cards, but
>> > maybe we could start an idcard package which contains routine for
>> different
>> > country identity cards.
>> >
>> > If this doesn't belong into [validator] I'll probably publish it via my
>> > github account :-)
>> >
>>
>> A CheckDigit implementation for German identity card numbers would look
>> like this:
>> https://gist.github.com/britter/ff959c42cab142a828247ce0673f6215
>>
>>
>> >
>> > Best regards,
>> > Benedikt
>> >
>> >
>>
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> 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

[VOTE] Release Apache Commons CSV 1.3 based on RC1

[Benedikt Ritter]

Hi,

we have fixed some bugs and added some nice new features since we released
Apache Commons CSV 1.2. So I'd like to release Apache Commons CSV 1.3 based
on RC 1.

Apache Commons CSV 1.3 RC1 is available for review here:
  https://dist.apache.org/repos/dist/dev/commons/csv/csv-1.3-RC1 (revision
13550)

Maven artifacty are here:

https://repository.apache.org/content/repositories/orgapachecommons-1165/org/apache/commons/commons-csv/1.3/

These are the Maven artifacts and their hashes:

commons-csv-1.3-javadoc.jar
(SHA1: dfeed187293d2d5ed3f8b26e096474ff8350a254)
commons-csv-1.3-sources.jar
(SHA1: 7841722762e93d6bd4419f91e140b6a16e167fe1)
commons-csv-1.3-test-sources.jar
(SHA1: c6c90708e686e1a17441632e417ccf91d78d87f2)
commons-csv-1.3-tests.jar
(SHA1: fdf822005dca524c329c3fd2f0abc149a885b52a)
commons-csv-1.3.jar
(SHA1: aeed8320e1b86b27e0b477a898eb7dd049526963)
commons-csv-1.3.pom
(SHA1: 8916753d403a30d53b9a105372eee620cd53b802)

Details of changes since 1.2 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/csv/csv-1.3-RC1/RELEASE-NOTES.txt
  http://home.apache.org/~britter/commons/csv-1.3-RC1/changes-report.html

I have tested this on Mac OS 10.11.4 with:
  JDK 1.6 & Maven 3.2.5
  JDK 7 & Maven 3.3.9
  JDK 8 & Maven 3.3.9

The tag is here:
  https://svn.apache.org/repos/asf/commons/proper/csv/tags/csv-1.3-RC1
 (revision 1742508)

Site:
   http://home.apache.org/~britter/commons/csv-1.3-RC1
(note some *relative links are broken and the 1.3 directories are not yet
created - these will be ok once the site is deployed)
(also note the site navigation has a minor error. There are two entires for
JavaDoc 1.2 and Site Archive 1.2. I will correct that once the site is
deployed)

Clirr Report (compared to 1.2):
  http://home.apache.org/~britter/commons/csv-1.3-RC1/clirr-report.html

RAT Report:
   http://home.apache.org/~britter/commons/csv-1.3-RC1/rat-report.html

KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote. This vote will close no
sooner that 72 hours from now, i.e. sometime after 10:30 CEST (UTC+2)
09-May 2016

[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

 Thanks!
Benedikt

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Jörg Schaible]

Hi Josh,

Josh Elser wrote:

> Jörg Schaible wrote:
>> Jörg Schaible wrote:
>>
>>> >  Hi Josh,
>>> >
>>> >  Josh Elser wrote:
>>> >
 >>  Oh, well then! No pressure:)
 >>
 >>  I'll have to find some time to re-read all of the conversation
 >>  between Jörg and Stian, but my initial reaction is the same as what
 >>  you were implying: compatibility across more JVMs would be great,
 >>  but shouldn't block this 2.1 release.
>>
>> Just an additional remark: Compatibility across more JVMs*is*  an issue,
>> since there are platforms where you have no other choice (IBM AIX, Mac,
>> most Linux distributions use OpenJDK by default).
>>
> 
> Is 2.1's compatibility across JVMs worse than 2.0's was?

It passed last time. We have now new JDKs though and don't support the Java 
5 ones anymore and have some new tests.

> What are the
> guarantees put forth by those involved with commons-vfs for
> compatibility WRT JVMs?

If issues are reported we already identified as problem with the JDK, we can 
simply relax and give an appropriate pointer. This is e.g. the case for 
commons-io where the IBM JDKs fail with UTF-16LE.

> I'm not nit-picking JVM support -- I'm nit-picking it's severity to
> block v2.1 for being released.

As said, I do not block it, but for *my* vote, I want to know, why some JDKs 
fail.

Cheers,
Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VFS] WIP specific release instructions

[Ralph Goers]

We have never deleted a tag once a vote passed.  Now that tags are immutable we 
are using rcn tags and then creating a release tag when the vote passes. But we 
are still just using the release plugin.

Ralph

> On May 5, 2016, at 9:49 AM, sebb  wrote:
> 
> On 5 May 2016 at 17:08, Ralph Goers  > wrote:
>> I really don’t know why you are making such a big deal about this.
> 
> Because it's important that tags are immutable, and to to a lesser
> degree to avoid creating spurious snapshot builds.
> 
>> I’ve been using the maven release plugin to release Log4j 2 for several 
>> years. That build was created based on the VFS 2.0 release process that also 
>> used the maven release plugin.  As I have said several times, releasing VFS 
>> is a lot harder than the rest of Commons because almost all are single 
>> module projects. Log4j 2 has a ton of modules and doesn’t have any 
>> significant problems that can’t easily be dealt with.
> 
> However the Log4j tags have not been immutable.
> 
> Both 2.0.1 and 2.0.2 were updated after initial creation.
> 
> And the 2.0-beta8 tag was created and deleted several times.
> There are other instances of mutable tags.
> 
> This means it may be tricky to demonstrate that the final tag
> corresponds with what was actually voted on.
> 
> It also looks like 2.0 was created from trunk rather than either of the RCs.
> As it happens, that vote passed first time so there was no need to recreate 
> 2.0.
> What would you have done if that vote had failed?
> 
> 
>> The process Josh documented for the 2.release seems a bit more complicated 
>> than what I did for 2.0, but if it works for him, great.
>> 
>> Ralph
>> 
>> 
>>> On May 5, 2016, at 6:41 AM, sebb >> > wrote:
>>> 
>>> On 5 May 2016 at 13:29, Benedikt Ritter >>  >> >> wrote:
 sebb  schrieb am Do., 5. Mai 2016 um 13:55 Uhr:
 
> On 5 May 2016 at 12:22,   wrote:
>> Hello,
>> 
>> BTW: I would use "mvn verify" instead of "mvn package" (I am  not sure
> what has changed for CP40)
> 
> CP40 changed the assembly plugin to run in the verify phase so it can
> pick up any additional jars added to the package phase by component
> poms.
> [It's not possible to ensure the assembly plugin runs at the very end
> of the assembly phase - see COMMONSSITE-87]
> 
> Releases should be generated using
> 
> mvn deploy -Prelease
> 
> 'mvn package' should still work for generating jars.
> 
>> (And yes the release plugin and the commons procedure for releases is a
> match in hell ,)
> 
> Not just Commons.
> Any project which allows multiple RCs for the same release is affected.
> The plugin works best where failed releases are abandoned and the
> version bumped for the next RC.
> It does not play well with retries.
> 
 
 I wonder how the maven-release-plugin team does this. Don't they run into
 the same problems?
 
>>> 
>>> The problems I can remember are:
>>> - trunk is unconditionally updated to the next SNAPSHOT version.
>>> This causes problems for components using CI builds (which may not be
>>> the case for them).
>>> 
>>> - if an RC fails, trunk has to be reverted.
>>> Since RC failures are quite common,  the process should be designed 
>>> accordingly.
>>> Subsequent CI builds will use an earlier SNAPSHOT version, which is 
>>> confusing.
>>> 
>>> - does it create an immutable tag? I cannot work out from the docs
>>> whether it appends RCn to the tag or not.
>>> If not, then redoing a failed release as the next RC will require
>>> deleting and recreating the tag, or abandoning that release version
>>> and starting again with the next version number.
>>> If it does create an RC tag, what name does it use for the SCM URLs?
>>> 
>>> - the local trunk workspace contains status files which need to be
>>> preseved until the process is complete.
>>> 
>>> 
> 
> [1] https://issues.apache.org/jira/browse/COMMONSSITE-87
> 
>> Gruss
>> Bernd
>> --
>> http://bernd.eckenfels.net
>> 
>> -Original Message-
>> From: Josh Elser 
>> To: Commons Developers List 
>> Sent: Do., 05 Mai 2016 6:49
>> Subject: Re: [VFS] WIP specific release instructions
>> 
>> 
>> 
>> sebb wrote:
>>> Have a look at the scripts in
>>> 
>>> http://svn.apache.org/viewvc/commons/scripts/
>>> 
>>> I used those for VALIDATOR and NET.
>> 
>> Cool. Thanks for sharing. It would be good if the generic commons
>> release documents referenced these if they are expected to be re-used by
>> other commons projects' RMs.
>> 
>>> On 4 May 2016 

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Ralph Goers]

Wow, I have no recollection of that email. But I have read a lot of emails over 
the last 6 years.

Ralph

> On May 5, 2016, at 3:05 PM, Jörg Schaible  wrote:
> 
> Hi Ralph,
> 
> Ralph Goers wrote:
> 
>> Remember, as the release manager you get to decide whether any of this
>> stuff is a blocker to the release. I can tell you for sure that VFS 2.0
>> wasn’t verified against this many different Java implementations and
>> versions.
> 
> Well, you're wrong: 
> http://article.gmane.org/gmane.comp.jakarta.commons.devel/116497
> 
>> Of course, the more testing the better!
> 
> Of course, Java 8 and 9 did not exist, but we dropped support for JHDK 5 now 
> ;-)
> 
> Cheers,
> 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