[OT] Slack channel created

[Gary Gregory]

Hi All and FYI,

I created a Slack channel called #commons for the team the-asf.slack.com

Gary

[GitHub] commons-text pull request #54: TEXT-93: RandomStringGenerator accepts a list...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/commons-text/pull/54


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: Commons sub project for parallel method execution

[Arun Mohan]

Hi All,

I found some time recently to work on the suggestions and ideas that came
up while discussing this.

Specifically, I reworked two major points that were called out -

1. Removed usage of Reflection API.
Replaced reflection with MethodHandles introduced in Java 7 which provide
 typed, directly executable reference to an underlying method on an object.

2. Annotation based code generation for providing the clients type safety
while building the method signatures to be parallelized. No more hardcoded
method strings.

https://github.com/striderarun/parallel-execution-engine



On Wed, Jun 14, 2017 at 12:41 PM, Arun Mohan 
wrote:

> Thanks for the tip Gary. Will give it a try.
>
> On Wed, Jun 14, 2017 at 12:13 PM, Gary Gregory 
> wrote:
>
>> Briefly: If you are considering code generation, then you can do away with
>> using reflection.
>>
>> G
>>
>> On Wed, Jun 14, 2017 at 12:04 PM, Arun Mohan 
>> wrote:
>>
>> > I was exploring ways on how to substitute the typing of method names in
>> the
>> > api with something thats more clean and maintainable.
>> > Using annotations, how can I provide clients the ability to specify
>> which
>> > method needs to be specified? Any ideas? Sort of stuck on this now.
>> >
>> > Right now I am thinking of something similar to HibernateJpa Metamodel
>> > generator, where a new class will be generated via byte code
>> manipulation
>> >  which will contain static string variables corresponding to all
>> annotated
>> > method names. Then the client can refer to the String variables in the
>> > generated class instead of typing the method names.
>> >
>> > Also, I don't have much experience playing with ASM or java assist. As
>> it
>> > currently stands, is this project a good fit for further exploration in
>> the
>> > Sandbox? I would like to see if there are interested folks with
>> experience
>> > in byte code manipulation who can contribute to this.
>> >
>> > On Wed, Jun 14, 2017 at 12:04 PM, Arun Mohan 
>> > wrote:
>> >
>> > > I was checking out how the library would plug into Spring and other
>> > > frameworks. I created a sample Spring project with a couple of auto
>> wired
>> > > service classes. To fetch and combine data from multiple service
>> classes
>> > in
>> > > parallel, the Spring injected service dependencies are passed to the
>> > > library.
>> > >
>> > > Since the library is framework agnostic, it deals with the spring
>> > injected
>> > > dependency as a normal object.
>> > >
>> > > You can see it here : https://github.com/striderarun/spring-app-
>> > > parallel-execution/blob/master/src/main/java/com/dashboard/
>> service/impl/
>> > > DashboardServiceImpl.java
>> > >
>> > > I think the idea here is that clients can parallelize method calls
>> > > irrespective of whether they are part of Spring beans or implemented
>> as
>> > > part of any other framework. Clients don't have to modify or wrap
>> their
>> > > methods into an ExecutorService, Runnable or any other low level apis
>> to
>> > do
>> > > so. Methods can be submitted as-is to the library.
>> > >
>> > > The library can serve as a higher level abstraction that completely
>> hides
>> > > concurrency apis from the client.
>> > >
>> > >
>> > > On Mon, Jun 12, 2017 at 7:38 PM, Matt Sicker 
>> wrote:
>> > >
>> > >> There's also some interesting execution APIs available in the Scala
>> > >> standard library. Those are built on top of ForkJoinPool and such
>> > >> nowadays,
>> > >> but the idea is there for a nicer API on top of ExecutorService and
>> > other
>> > >> low level details.
>> > >>
>> > >> In the interests of concurrency, there are other thread-like models
>> that
>> > >> can be explored. For example: http://docs.paralleluniverse.c
>> o/quasar/
>> > >>
>> > >> On 12 June 2017 at 21:22, Bruno P. Kinoshita <
>> > >> brunodepau...@yahoo.com.br.invalid> wrote:
>> > >>
>> > >> > Interesting idea. And great discussion. Can't really say I'd have a
>> > use
>> > >> > case for that right now, so abstaining from the discussion around
>> the
>> > >> > implementation.
>> > >> >
>> > >> > I believe if we decide to explore this idea in Commons, we will
>> > probably
>> > >> > move it to sandbox? Even if we do not move that to Commons or to
>> > >> sandbox, I
>> > >> > intend to find some time in the next days to try Apache Commons
>> > Javaflow
>> > >> > with this library.
>> > >> >
>> > >> > Jenkins implemented pipelines + continuations with code that when
>> > >> started
>> > >> > it looked a lot like Javaflow. The execution in parallel is taken
>> care
>> > >> in
>> > >> > some internal modules in Jenkins, but I would like to see how if
>> > simpler
>> > >> > implementation like this one would work.
>> > >> >
>> > >> > Ideally, this utility would execute in parallel, say, 20 tasks each
>> > >> taking
>> > >> > 5 minutes (haven't looked if it supports fork/join). Then I would
>> be
>> > >> 

Re: Things in a POM file that are not probably incorrect

[Ralph Goers]

It seems so, although it sounds like there is a solution to do it with Java 7 
and 8 as well.

http://events.linuxfoundation.org/sites/events/files/slides/Java9%20and%20the%20impact%20on%20Maven%20projects.pdf
 


Ralph

> On Jun 28, 2017, at 10:05 AM, Gary Gregory  wrote:
> 
> It sounds like building on Java 9 renders the animal sniffer Maven plugin
> obsolete.
> 
> Gary
> 
> On Jun 26, 2017 15:02, "Simon Spero"  wrote:
> 
>>1.5
>>1.5
>>org.apache.commons.functor
>> 
>> JDK 9 cannot generate or parse class files compiled with -target 1.5  [1].
>> 
>> Per the JPMS Armistice talks,   "Automatic-Module-Name" header should only
>> be added to jars that have been tested under JDK 9 [2].
>> 
>> Also, javac now supports the new "--release" argument as an alternative to
>> source + target.
>> Roughly speaking, this option combines -source & -target with a little bit
>> of animal sniffing.  JDK 9 includes  signatures for JDK 6,7,8, and 9 (i.e.
>> all the releases which jdk9 can compile for).
>> This option is supported by maven-compiler-plugin [4] via a 
>> element in the plugin  configuration, or by settting the property
>> *maven.compiler.release* .
>> 
>> Simon
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8011044
>> [2]
>> http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05-18#
>> AutomaticModuleNames--ModuleNameInManifest
>> [3] http://openjdk.java.net/jeps/247
>> [4]
>> https://maven.apache.org/plugins/maven-compiler-plugin/
>> compile-mojo.html#release
>> 

Re: Things in a POM file that are not probably incorrect

[Gary Gregory]

It sounds like building on Java 9 renders the animal sniffer Maven plugin
obsolete.

Gary

On Jun 26, 2017 15:02, "Simon Spero"  wrote:

> 1.5
> 1.5
> org.apache.commons.functor
>
> JDK 9 cannot generate or parse class files compiled with -target 1.5  [1].
>
> Per the JPMS Armistice talks,   "Automatic-Module-Name" header should only
> be added to jars that have been tested under JDK 9 [2].
>
> Also, javac now supports the new "--release" argument as an alternative to
> source + target.
> Roughly speaking, this option combines -source & -target with a little bit
> of animal sniffing.  JDK 9 includes  signatures for JDK 6,7,8, and 9 (i.e.
> all the releases which jdk9 can compile for).
> This option is supported by maven-compiler-plugin [4] via a 
> element in the plugin  configuration, or by settting the property
> *maven.compiler.release* .
>
> Simon
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8011044
> [2]
> http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05-18#
> AutomaticModuleNames--ModuleNameInManifest
> [3] http://openjdk.java.net/jeps/247
> [4]
> https://maven.apache.org/plugins/maven-compiler-plugin/
> compile-mojo.html#release
>

Re: [DISCUSS] Do we need a vote for moving components to git?

[Gary Gregory]

I am OK with keeping the lazy vote since it is pretty frictionless, and
gives people the opportunity to officially raise their hand and show why
this is a problem for them. In practice though, moving everything to Git is
just a matter of time. I can imagine that we would just move components to
the attic that eventually do not get moved to Git. IOW, eventually move to
Git or move to the attic.

Gary

On Jun 28, 2017 00:21, "Benedikt Ritter"  wrote:

> Hi,
>
> do we still need a vote for moving components to git? We have done this so
> often that I think we could change the process to a simply mail announcing
> intents to move a component.
>
> Thoughts?
> Benedikt
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Things in a POM file that are not probably incorrect

[Matt Sicker]

Java 9 can still run old bytecode, but they're removing compiler support
for outputting that bytecode apparently (either that or syntax support).

On 27 June 2017 at 18:45, Emmanuel Bourg  wrote:

> Le 27/06/2017 à 00:02, Simon Spero a écrit :
>
> > JDK 9 cannot generate or parse class files compiled with -target 1.5
> [1].
>
> AFAIK Java 9 can still parse 1.5 (and lower) class files.
>
> Emmanuel Bourg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Matt Sicker 

Re: [DISCUSS] Do we need a vote for moving components to git?

[Matt Sicker]

The only objection I've seen to switching on any project so far was other
projects using svn:external to sync up a commons project, but there are
workarounds for that (e.g., the GitHub svn mirror).

On 28 June 2017 at 03:45, Amey Jadiye  wrote:

> unless there is strong reason to stick with svn we should move on git(as
> many other already moved). I agree that in few cases svn is preferred and
> that may open huge discussion but atleast for Commons I don't see much
> advantages to use svn. people who are using svn from long time usually
> comes in comfort zone since svn is really really easy to use. :)
>
> Regards,
> Amey
>
> On Wed, Jun 28, 2017, 1:00 PM Stefan Bodewig  wrote:
>
> > On 2017-06-28, Amey Jadiye wrote:
> >
> > > I think just announcing with intention is enough as git is always
> better
> > > than svn and at some point everyone will wish to move on git.
> >
> > There certainly are people who disagree with your (I'm not one of them)
> ;-)
> >
> > Stefan
> >
>



-- 
Matt Sicker 

Re: [DISCUSS] Do we need a vote for moving components to git?

[Amey Jadiye]

unless there is strong reason to stick with svn we should move on git(as
many other already moved). I agree that in few cases svn is preferred and
that may open huge discussion but atleast for Commons I don't see much
advantages to use svn. people who are using svn from long time usually
comes in comfort zone since svn is really really easy to use. :)

Regards,
Amey

On Wed, Jun 28, 2017, 1:00 PM Stefan Bodewig  wrote:

> On 2017-06-28, Amey Jadiye wrote:
>
> > I think just announcing with intention is enough as git is always better
> > than svn and at some point everyone will wish to move on git.
>
> There certainly are people who disagree with your (I'm not one of them) ;-)
>
> Stefan
>

Re: [DISCUSS] Do we need a vote for moving components to git?

[Stefan Bodewig]

On 2017-06-28, Amey Jadiye wrote:

> I think just announcing with intention is enough as git is always better
> than svn and at some point everyone will wish to move on git.

There certainly are people who disagree with your (I'm not one of them) ;-)

Stefan

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

Re: [DISCUSS] Do we need a vote for moving components to git?

[Stefan Bodewig]

On 2017-06-28, Benedikt Ritter wrote:

> do we still need a vote for moving components to git? We have done
> this so often that I think we could change the process to a simply
> mail announcing intents to move a component.

Hmm, what if one of the active developers of the component then says
she/he would prefer to stick with svn? We've had such cases in the past.

If you then reconsider or at least start to discuss I don't really see
the difference between a lazy vote and the announcement.

Stefan

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

Re: [DISCUSS] Do we need a vote for moving components to git?

[Amey Jadiye]

I think just announcing with intention is enough as git is always better
than svn and at some point everyone will wish to move on git.

so +1 to just announce it.

Regards,
Amey

On Wed, Jun 28, 2017, 12:51 PM Benedikt Ritter  wrote:

> Hi,
>
> do we still need a vote for moving components to git? We have done this so
> often that I think we could change the process to a simply mail announcing
> intents to move a component.
>
> Thoughts?
> Benedikt
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[DISCUSS] Do we need a vote for moving components to git?

[Benedikt Ritter]

Hi,

do we still need a vote for moving components to git? We have done this so 
often that I think we could change the process to a simply mail announcing 
intents to move a component.

Thoughts?
Benedikt


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

Re: Git/Github Access

[Benedikt Ritter]

Hi Carl,

> Am 28.06.2017 um 05:48 schrieb Carl Hall :
> 
> Hi friends,
> 
> I'd like to move commons-dbutils to git rather than continuing to deal with
> git-svn.  Could someone point me in the right direction for requesting this
> or point me to the right person/group to pose my request?

The process is described here [1]. In short: start a vote by lazy consensus, 
use the infra self service for requesting a repository, move the code to that 
repository, move the SVN code base to the archive.

Cheers,
Benedikt

[1] https://wiki.apache.org/commons/MovingToGit 

> 
> Thanks,
> Carl

[Commons Wiki] Update of "MovingToGit" by BenediktRitter

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Commons Wiki" for 
change notification.

The "MovingToGit" page has been changed by BenediktRitter:
https://wiki.apache.org/commons/MovingToGit?action=diff=7=8

Comment:
Add requirement to start a vote before migration

  Notes on things to look out for if a component moves from SVN to Git.
  
   * This is a work in progress *
+ 
+ == Start a vote ==
+ 
+ To migrate a component to git, start a VOTE by LAZY CONSENSUS on the dev ML. 
If the vote passes, proceed with the following steps.
  
  == Request a new Git repository ==
  

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