[VOTE][VFS][LAZY] Migrate VFS to Git

[Matt Sicker]

Before starting work on a VFS 3 branch, I'd like to migrate from Subversion
to Git. As with other repo migrations, this is a lazy majority vote that
will be open for 72 hours. If there are no objections, I'll import the svn
repo into git, and with the help of a PMC or two, create a new git repo on
apache.org to host it, and then move the old svn repo into the
_moved_to_git archives.

-- 
Matt Sicker 

[Pool] Need PMC assistance to finish git migration

[Matt Sicker]

I imported the svn repo for commons-pool and uploaded it to the newly
created git repo here:

https://git-wip-us.apache.org/repos/asf/commons-pool.git

I need a PMC to help finish this migration. Instructions are here:

https://wiki.apache.org/commons/MovingToGit

When that is complete, we can update Jenkins. I already updated the pom
metadata to point to the new repo. After migration is complete, I can work
on a release candidate.

-- 
Matt Sicker 

Re: [VFS] Interest in starting a Java 7 FileSystem-based version?

[Matt Sicker]

Based on experience with ByteBuffers in the past, I have a feeling VFS3 may
want to provide some sort of abstraction over it like how Netty does.
Otherwise, managing ByteBuffers can become painful.

On 16 March 2017 at 10:31, Matt Sicker  wrote:

> Commons VFS is still in Subversion. We're going to need a new Git repo
> regardless. I can do an import for that repo like I did for Pool, but I
> need PMC help to complete the transition.
>
> Also, I was thinking about which Java version to support. Java 7 is
> obviously the minimum due to the API being added there, and it doesn't look
> like there was anything new added in Java 8 for NIO (other than an improved
> SelectorProvider implementation on Solaris, but that's not a public API). I
> don't see any additions in Java 9, either. Now I prefer using Java 8 for
> development, but as there appears to be no specific reason to use Java 8
> for this version, we could really go either way. Using Java 7 makes more
> sense for creating FileSystemProvider implementations, though depending on
> any additional APIs added, I don't know if it'll turn out that supporting
> Java 8 APIs will be all that useful.
>
> On 16 March 2017 at 02:39, Benedikt Ritter  wrote:
>
>> Why not a new branch in the existing repo?
>>
>> Benedikt
>>
>> Ralph Goers  schrieb am Do. 16. März 2017 um
>> 06:54:
>>
>> > Yes, and here we are with Java 9 at our doorstep.  Time flies.
>> >
>> > I would recommend that you create a commons-vfs3 git repo for this as
>> you
>> > will only be able to borrow some code. A lot will be different.
>> >
>> > Ralph
>> >
>> > > On Mar 15, 2017, at 8:12 PM, Matt Sicker  wrote:
>> > >
>> > > Ralph has mentioned in the past an idea about rewriting commons-vfs
>> using
>> > > java.nio.file from Java 7. I was playing with this API today
>> attempting
>> > to
>> > > abstract some S3 file operations using <
>> > > https://github.com/Upplication/Amazon-S3-FileSystem-NIO2> and found
>> that
>> > > the API is pretty nice. OpenJDK already contains implementations for
>> the
>> > > normal file system and zip files if I recall correctly (so probably
>> also
>> > > jar files).
>> > >
>> > > Anyways, if we were to go forward with starting work on this, should
>> we
>> > > just make a commons-vfs3 branch in the vfs repo? Or does this belong
>> in
>> > the
>> > > sandbox?
>> > >
>> > > --
>> > > Matt Sicker 
>> >
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >
>> >
>>
>
>
>
> --
> Matt Sicker 
>



-- 
Matt Sicker 

Re: [VFS] Interest in starting a Java 7 FileSystem-based version?

[Matt Sicker]

Commons VFS is still in Subversion. We're going to need a new Git repo
regardless. I can do an import for that repo like I did for Pool, but I
need PMC help to complete the transition.

Also, I was thinking about which Java version to support. Java 7 is
obviously the minimum due to the API being added there, and it doesn't look
like there was anything new added in Java 8 for NIO (other than an improved
SelectorProvider implementation on Solaris, but that's not a public API). I
don't see any additions in Java 9, either. Now I prefer using Java 8 for
development, but as there appears to be no specific reason to use Java 8
for this version, we could really go either way. Using Java 7 makes more
sense for creating FileSystemProvider implementations, though depending on
any additional APIs added, I don't know if it'll turn out that supporting
Java 8 APIs will be all that useful.

On 16 March 2017 at 02:39, Benedikt Ritter  wrote:

> Why not a new branch in the existing repo?
>
> Benedikt
>
> Ralph Goers  schrieb am Do. 16. März 2017 um
> 06:54:
>
> > Yes, and here we are with Java 9 at our doorstep.  Time flies.
> >
> > I would recommend that you create a commons-vfs3 git repo for this as you
> > will only be able to borrow some code. A lot will be different.
> >
> > Ralph
> >
> > > On Mar 15, 2017, at 8:12 PM, Matt Sicker  wrote:
> > >
> > > Ralph has mentioned in the past an idea about rewriting commons-vfs
> using
> > > java.nio.file from Java 7. I was playing with this API today attempting
> > to
> > > abstract some S3 file operations using <
> > > https://github.com/Upplication/Amazon-S3-FileSystem-NIO2> and found
> that
> > > the API is pretty nice. OpenJDK already contains implementations for
> the
> > > normal file system and zip files if I recall correctly (so probably
> also
> > > jar files).
> > >
> > > Anyways, if we were to go forward with starting work on this, should we
> > > just make a commons-vfs3 branch in the vfs repo? Or does this belong in
> > the
> > > sandbox?
> > >
> > > --
> > > Matt Sicker 
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>



-- 
Matt Sicker 

Re: [LANG] Next release

[Benedikt Ritter]

Hi,

> Am 13.03.2017 um 10:22 schrieb Benedikt Ritter :
> 
> Hello,
> 
> I’m going to start work on the next [lang] release tonight. If there is 
> anything you would like to add, please do it now. If you want to help me with 
> the release process, please review the various project reports and make sure 
> they look good. Most importantly make sure RAT is clean and Clirr does not 
> show breaking changes.

Sorry, I got caught up in other things this week. Hope to find some time soon 
to prepare an RC.

Benedikt

> 
> Thank you!
> 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

[RESULT][VOTE][LAZY] Move Apache Commons Modeler to dormant

[Benedikt Ritter]

Hello,

> Am 13.03.2017 um 11:58 schrieb Benedikt Ritter :
> 
> Hi,
> 
> The Apache Commons Modeler component provides mechanisms to create Model 
> MBeans compatible with JMX specification.
> 
> The last release dates back to 2007 and there hasn’t been any development 
> activity since. Further more there has not been any discussion on our mailing 
> lists about Modeler.
> 
> I think it is okay to assume that the component is not needed anymore and can 
> therefor be moved to dormant.
> 
> So I’m calling a vote by lazy consensus for moving the Apache Commons Modeler 
> component to dormant. This vote will close no sooner that 72 hours from now, 
> i.e. sometime after 11:00 UTC 16-March 2017. This vote by lazy consensus will 
> pass if nobody raises objections - no explicit +1 votes are required.

This vote passes, since nobody objected within 72h. I’m going to move the 
Modeler to dormant as soon as I find the time for it :-)

Regards,
Benedikt

> 
> Regards,
> 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

Jenkins build is back to stable : commons-email #9

[Apache Jenkins Server]

See 



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

Jenkins build is back to stable : commons-email » Apache Commons Email #9

[Apache Jenkins Server]

See 



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

Re: [VFS] Interest in starting a Java 7 FileSystem-based version?

[Benedikt Ritter]

Why not a new branch in the existing repo?

Benedikt

Ralph Goers  schrieb am Do. 16. März 2017 um
06:54:

> Yes, and here we are with Java 9 at our doorstep.  Time flies.
>
> I would recommend that you create a commons-vfs3 git repo for this as you
> will only be able to borrow some code. A lot will be different.
>
> Ralph
>
> > On Mar 15, 2017, at 8:12 PM, Matt Sicker  wrote:
> >
> > Ralph has mentioned in the past an idea about rewriting commons-vfs using
> > java.nio.file from Java 7. I was playing with this API today attempting
> to
> > abstract some S3 file operations using <
> > https://github.com/Upplication/Amazon-S3-FileSystem-NIO2> and found that
> > the API is pretty nice. OpenJDK already contains implementations for the
> > normal file system and zip files if I recall correctly (so probably also
> > jar files).
> >
> > Anyways, if we were to go forward with starting work on this, should we
> > just make a commons-vfs3 branch in the vfs repo? Or does this belong in
> the
> > sandbox?
> >
> > --
> > Matt Sicker 
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VFS] Interest in starting a Java 7 FileSystem-based version?

[Gary Gregory]

Great idea Matt. This is a long time coming. A porting guide will be key. I
have a lot of code depending on vfs2.

Gary

On Mar 16, 2017 6:54 AM, "Ralph Goers"  wrote:

> Yes, and here we are with Java 9 at our doorstep.  Time flies.
>
> I would recommend that you create a commons-vfs3 git repo for this as you
> will only be able to borrow some code. A lot will be different.
>
> Ralph
>
> > On Mar 15, 2017, at 8:12 PM, Matt Sicker  wrote:
> >
> > Ralph has mentioned in the past an idea about rewriting commons-vfs using
> > java.nio.file from Java 7. I was playing with this API today attempting
> to
> > abstract some S3 file operations using <
> > https://github.com/Upplication/Amazon-S3-FileSystem-NIO2> and found that
> > the API is pretty nice. OpenJDK already contains implementations for the
> > normal file system and zip files if I recall correctly (so probably also
> > jar files).
> >
> > Anyways, if we were to go forward with starting work on this, should we
> > just make a commons-vfs3 branch in the vfs repo? Or does this belong in
> the
> > sandbox?
> >
> > --
> > Matt Sicker 
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Help with task: Random number generators

[Bernd Eckenfels]

Please do: you can do that post-release as well. We had quite some offers on 
that task but no follow up. Get the released version and javadoc from the 
project home and let us know if that was enough to get started. please specify 
in what context you would use the classes.

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

Gruss
Bernd
--
http://bernd.eckenfels.net

_
From: Prashanth.R >
Sent: Donnerstag, März 16, 2017 1:23 AM
Subject: Help with task: Random number generators
To: >


I would like to help out with the task listed at
https://helpwanted.apache.org/task.html?532e1a73


--
Regards,
Prashanth. R