Re: Anyone interested in regular expressions, again?

[Bruno P. Kinoshita]

Someone posted to Hacker News too. Here's the link to the comments there 
https://news.ycombinator.com/item?id=9070593

CheersBruno

 
  From: Benson Margulies 
 To: Commons Developers List ; Bruno P. Kinoshita 
 
 Sent: Tuesday, February 17, 2015 11:53 PM
 Subject: Re: Anyone interested in regular expressions, again?
   
Thanks! I look forward to retiring mine!

On Tue, Feb 17, 2015 at 8:48 PM, Bruno P. Kinoshita
 wrote:
> That's great news! Thanks James!
> Bruno
>
>      From: James Ring 
>  To: Commons Developers List 
>  Sent: Tuesday, February 17, 2015 11:31 PM
>  Subject: Re: Anyone interested in regular expressions, again?
>
> Hey Benson,
>
> Just wanted to let you and the rest of the commons dev list that re2j
> is now in the open: please see https://github.com/google/re2j. Please
> take a look!
>
> Regards,
> James
>
> On Mon, Feb 9, 2015 at 12:16 PM, Benson Margulies  
> wrote:
>> On Mon, Feb 9, 2015 at 1:36 PM, James Ring  wrote:
>>> I'm working to bring re2j into the open, it will take some time
>>> because Google's internal procedures for this kind of thing are pretty
>>> lengthy. I'm hopeful it could be done in the next month or so.
>>
>> That is lovely news. Thanks!
>>
>>>
>>> On Tue, Feb 3, 2015 at 12:14 PM, Benson Margulies  
>>> wrote:
 On Tue, Feb 3, 2015 at 2:39 AM, Thomas Neidhart
  wrote:
> On 02/03/2015 01:46 AM, Benson Margulies wrote:
>> The irony here is that the Java HSRE port happened because it seemed
>> easier than an RE2 port. Note the same statements about API's pretty
>> much apply.
>
> I am sorry, my response was not very sensible wrt your original proposal.

 It seems very sensible to me. A team at Google producing re2j is
 likely to have produced a far superior comestible to what I did. If
 there's any possibility that it will emerge in, oh, a month or two, I
 don't think it makes sense to go to the trouble to pull the HSRE code
 into Apache.

>
> If we have another implementation that works fine and has a sufficiently
> large enough community then I do not see a problem to include it in the
> commons project, I would certainly be interested.
>
> Thomas
>
>> On Mon, Feb 2, 2015 at 6:21 PM, Thomas Neidhart
>>  wrote:
>>> On 02/02/2015 11:20 PM, James Ring wrote:
 I spoke to one of the authors of re2j, a Google-internal port of the 
 C++
 re2 library. The intention was to open source it but they just haven't 
 got
 around to it.

 I may try and get Google to put re2j up on GitHub so you all can take a
 look. AFAIK it is heavily used in Google and it has an API that is 
 largely
 compatible with java.util.regex. I know from personal experience that 
 one
 can often benefit from re2j merely by replacing java.util.regex imports
 with the corresponding re2j imports.
>>>
>>> that would be super-cool.
>>>
>>> Thomas
>>>
>>>
>>> -
>>> 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
>

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



   

[VOTE][JCS] release [jcs] 2.0-beta-1 (take 4)

[Romain Manni-Bucau]

Hi

Another try, hopefully right this time (I speak about JCS in a JUG
next thursday so would be awesome to have a release ;))

- here is the maven repo:
https://repository.apache.org/content/repositories/orgapachecommons-1083/
- assemblies can be found here
https://repository.apache.org/content/repositories/orgapachecommons-1083/org/apache/commons/commons-jcs-dist/2.0-beta-1/
- tag is here: 
http://svn.apache.org/repos/asf/commons/proper/jcs/tags/commons-jcs-2.0-beta-1/
- Site staging is:
http://people.apache.org/~rmannibucau/commons-jcs-2.0-beta-1-site/
- rat report is here (I deleted zipcodes.txt and CDI SPI
(META-INF/services/...) from reports since it seems rat config with
append parameter is not well respected but that's really what we
want):
http://people.apache.org/~rmannibucau/commons-jcs-2.0-beta-1-site/rat-report.html

Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now or until we get
3 PMC votes.

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


Here is my +1


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau

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

Re: [VOTE] Release BCEL 6.0 based on RC3

[Ben McCann]

+mark

Mark, do any of your pending changes break binary compatibility? If so, do
you mind sharing which do and which don't. It could be nice to release a
6.0 now and then release a 6.1 with your changes and any bug fixes for
issues discovered in 6.0

Thanks,
Ben


On Wed, Feb 18, 2015 at 10:45 PM, Benedikt Ritter 
wrote:

> 2015-02-19 5:11 GMT+01:00 Gary Gregory :
>
> > On Wed, Feb 18, 2015 at 7:04 PM, Ben McCann  wrote:
> >
> > > Would it be possible to release 6.0 now and release Mark's patches as
> 6.1
> > > or 7.0? I'm concerned it may be quite a long time before his patches
> are
> > > committed since they are not actively being reviewed and there is no
> > > activity on them for the past couple weeks.
> > >
> > > There is little downside to frequent releases in my experience.
> > Infrequent
> > > releases on the other hand can be a source of frustration as it means
> it
> > > can be quite difficult to use the code that has been committed.
> >
> >
> > +1
> >
>
> If those changes don't imply breaking binary compatibility we can include
> them in 6.1.
>
>
> >
> > Gary
> >
> >
> > > This is the
> > > exact reason the node.js community was splintered and the io.js fork
> was
> > > created. While end users can easily build from source it can become
> > > extremely difficult when there are multiple transitive dependencies
> > relying
> > > on the library. Users end up having to maintain patched versions not
> only
> > > of BCEL but of the libraries that depend on BCEL which means there can
> be
> > > quite a bit of overhead. As the length of time between releases grows
> the
> > > number of custom patches each user has to separately maintain in each
> > > library depending on BCEL grows. Right now it has been nine years.
> > >
> > > Thanks,
> > > Ben
> > >  On Feb 10, 2015 1:53 AM, "Ben McCann"  wrote:
> > >
> > > > Great, thanks for the update!
> > > >
> > > > Btw, for those not familiar with which issues those are, here's a
> list
> > of
> > > > the ones Mark raised that are not yet resolved:
> > > > https://issues.apache.org/jira/browse/BCEL-79
> > > > https://issues.apache.org/jira/browse/BCEL-195
> > > > https://issues.apache.org/jira/browse/BCEL-196
> > > > https://issues.apache.org/jira/browse/BCEL-197
> > > > https://issues.apache.org/jira/browse/BCEL-198
> > > > https://issues.apache.org/jira/browse/BCEL-199
> > > > https://issues.apache.org/jira/browse/BCEL-200
> > > > https://issues.apache.org/jira/browse/BCEL-201
> > > > https://issues.apache.org/jira/browse/BCEL-202
> > > > https://issues.apache.org/jira/browse/BCEL-205
> > > > https://issues.apache.org/jira/browse/BCEL-206
> > > > https://issues.apache.org/jira/browse/BCEL-208
> > > > https://issues.apache.org/jira/browse/BCEL-209
> > > >
> > > > Thanks!
> > > > -Ben
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Sun, Feb 8, 2015 at 11:32 PM, Emmanuel Bourg 
> > > wrote:
> > > >
> > > >> Le 09/02/2015 06:29, chengas123 a écrit :
> > > >>
> > > >> > BCEL really needs the 6.0 release to be cut or it will no longer
> be
> > > >> > compatible with any supported version of Java. Would anyone be
> able
> > to
> > > >> cut a
> > > >> > new release?
> > > >>
> > > >> I will once the issues raised by Marks Roberts are addressed.
> > > >>
> > > >> Emmanuel Bourg
> > > >>
> > > >>
> > > >>
> -
> > > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > >> For additional commands, e-mail: dev-h...@commons.apache.org
> > > >>
> > > >>
> > > >
> > > >
> > > > --
> > > > about.me/benmccann
> > > >
> > >
> >
> >
> >
> > --
> > 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
> >
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>



-- 
about.me/benmccann

Re: [VOTE] Release BCEL 6.0 based on RC3

[Emmanuel Bourg]

Le 19/02/2015 14:59, Ben McCann a écrit :

> Mark, do any of your pending changes break binary compatibility? If so, do
> you mind sharing which do and which don't. It could be nice to release a
> 6.0 now and then release a 6.1 with your changes and any bug fixes for
> issues discovered in 6.0

There are breaking changes like BCEL-209 that must be addressed now.

Emmanuel Bourg


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

Re: [VOTE] Release BCEL 6.0 based on RC3

[Emmanuel Bourg]

Le 19/02/2015 04:04, Ben McCann a écrit :
> Would it be possible to release 6.0 now and release Mark's patches as 6.1
> or 7.0? I'm concerned it may be quite a long time before his patches are
> committed since they are not actively being reviewed and there is no
> activity on them for the past couple weeks.

Mark raised some important issues like BCEL-195, BCEL-200, BCEL-206,
BCEL-207, BCEL-208 and the reopening of BCEL-79. I think these issues
should be addressed for the next release and I invite anyone impatient
to see BCEL 6.0 released to review them, check the JVM spec and provide
test cases to ensure we fix them properly.

Emmanuel Bourg


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

Re: [VOTE] Release BCEL 6.0 based on RC3

[Ben McCann]

Perhaps if there are only a few breaking changes we could prioritize
reviewing those first and leave the rest for 6.1.  Alternatively, we could
release what's available now as 6.0 and release all the patches in a couple
months as 7.0.

On Thu, Feb 19, 2015 at 6:09 AM, Emmanuel Bourg  wrote:

> Le 19/02/2015 14:59, Ben McCann a écrit :
>
> > Mark, do any of your pending changes break binary compatibility? If so,
> do
> > you mind sharing which do and which don't. It could be nice to release a
> > 6.0 now and then release a 6.1 with your changes and any bug fixes for
> > issues discovered in 6.0
>
> There are breaking changes like BCEL-209 that must be addressed now.
>
> Emmanuel Bourg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
about.me/benmccann

Re: [VOTE][JCS] release [jcs] 2.0-beta-1 (take 4)

[Johannes Weberhofer]

Thank you, Romain!

Builds fine; no errors, no warnings - have not checked for other issues; so 
here's my non-binding +1;

I'm hardly waiting for a (beta) release, as I'd like to replace old JSC in an 
application of mine...

Johannes



mvn -version

Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 
14:51:28+0100)
Maven home: /home.local/java/apache-maven-3
Java version: 1.7.0_75, vendor: Oracle Corporation
Java home: /usr/lib64/jvm/java-1.7.0-openjdk-1.7.0/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "linux", version: "3.16.7-7-desktop", arch: "amd64", family: "unix"



[INFO] Reactor Summary:
[INFO]
[INFO] Apache Commons JCS  SUCCESS [44.610s]
[INFO] Apache Commons JCS :: Core  SUCCESS [6:28.749s]
[INFO] Apache Commons JCS :: JCache .. SUCCESS [10.373s]
[INFO] Apache Commons JCS :: JCache TCK .. SUCCESS [3.882s]
[INFO] Apache Commons JCS :: JCache Extras ... SUCCESS [9.457s]
[INFO] Apache Commons JCS :: JCache OpenJPA .. SUCCESS [9.784s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 7:48.950s
[INFO] Finished at: Thu Feb 19 15:14:54 CET 2015
[INFO] Final Memory: 39M/155M
[INFO] 


Am 19.02.2015 um 14:28 schrieb Romain Manni-Bucau:

Hi

Another try, hopefully right this time (I speak about JCS in a JUG
next thursday so would be awesome to have a release ;))

- here is the maven repo:
https://repository.apache.org/content/repositories/orgapachecommons-1083/
- assemblies can be found here
https://repository.apache.org/content/repositories/orgapachecommons-1083/org/apache/commons/commons-jcs-dist/2.0-beta-1/
- tag is here: 
http://svn.apache.org/repos/asf/commons/proper/jcs/tags/commons-jcs-2.0-beta-1/
- Site staging is:
http://people.apache.org/~rmannibucau/commons-jcs-2.0-beta-1-site/
- rat report is here (I deleted zipcodes.txt and CDI SPI
(META-INF/services/...) from reports since it seems rat config with
append parameter is not well respected but that's really what we
want):
http://people.apache.org/~rmannibucau/commons-jcs-2.0-beta-1-site/rat-report.html

Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now or until we get
3 PMC votes.

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


Here is my +1


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau

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



--
Johannes Weberhofer
Weberhofer GmbH, Austria, Vienna

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

Re: svn commit: r1659973 [1/3] - in /commons/sandbox/rdf/trunk: ./ api/src/main/java/org/apache/commons/rdf/ impl.sparql/ impl.sparql/src/ impl.sparql/src/main/ impl.sparql/src/main/java/ impl.sparql/

[Stian Soiland-Reyes]

I am not speaking for Reto, but I imagined that since Reto has joined
the CommonsRDF incubator proposal, then his sandbox-code would
eventually turn into pull requests and branches on the incubator
codebase so that we can evaluate each of the differences separately.


On 19 February 2015 at 06:54, Benedikt Ritter  wrote:
> 2015-02-17 7:04 GMT+01:00 Benedikt Ritter :
>
>>
>>
>> 2015-02-17 0:13 GMT+01:00 Peter Ansell :
>>
>>> Hi Bernard,
>>>
>>> The Commons RDF project is not planning on including any non-trivial
>>> implementations, to avoid bias towards any of the participating
>>> platforms. Stian has written a trivial implementation and submitted it
>>> to GitHub to provide a reference for our test harness, but it is never
>>> planned to be used by anyone for non-trivial purposes.
>>>
>>> Reto is moving this code here unilaterally from Clerezza at this point
>>> based on the ability of any Apache committer to send code into Apache
>>> Commons.
>>>
>>> The code that will be sent to the incubator is still planned to be the
>>> code that is in the GitHub repository at the time the incubator
>>> request goes through.
>>>
>>
>> This is still in the sandbox so I'm not too crazy about it. But creating a
>> separate code base in the commons-rdf git repository doesn't sound like a
>> good idea given the fact that github Commons RDF will eventually move to
>> Apache Commons after incubation. What should haben with the code that is in
>> the repository by that time?
>>
>> Reto, can you comment please?
>>
>
> Reto, I'm still waiting for your comment.
>
>
>>
>> Regards,
>> Benedikt
>>
>>
>>>
>>> Cheers,
>>>
>>> Peter
>>>
>>> On 16 February 2015 at 18:34, Benedikt Ritter  wrote:
>>> > Hello Reto,
>>> >
>>> > how does this relate to github Commons RDF? Is this part of the code
>>> base
>>> > proposed for incubation?
>>> >
>>> > Regards,
>>> > Benedikt
>>> >
>>> > 2015-02-15 19:41 GMT+01:00 :
>>> >
>>> >> Author: reto
>>> >> Date: Sun Feb 15 18:41:15 2015
>>> >> New Revision: 1659973
>>> >>
>>> >> URL: http://svn.apache.org/r1659973
>>> >> Log:
>>> >> Started SPARQL Backed Implementation
>>> >>
>>> >> Added:
>>> >> commons/sandbox/rdf/trunk/alerts.txt
>>> >> commons/sandbox/rdf/trunk/impl.sparql/   (with props)
>>> >> commons/sandbox/rdf/trunk/impl.sparql/pom.xml
>>> >> commons/sandbox/rdf/trunk/impl.sparql/src/
>>> >> commons/sandbox/rdf/trunk/impl.sparql/src/main/
>>> >> commons/sandbox/rdf/trunk/impl.sparql/src/main/java/
>>> >> commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/
>>> >> commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/apache/
>>> >>
>>>  commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/apache/commons/
>>> >>
>>> >>
>>> commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/apache/commons/rdf/
>>> >>
>>> >>
>>> commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/apache/commons/rdf/impl/
>>> >>
>>> >>
>>> commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/apache/commons/rdf/impl/sparql/
>>> >>
>>> >>
>>> commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/apache/commons/rdf/impl/sparql/SparqlClient.java
>>> >>
>>> >>
>>> commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/apache/commons/rdf/impl/sparql/SparqlGraph.java
>>> >> commons/sandbox/rdf/trunk/impl.sparql/src/main/resources/
>>> >> commons/sandbox/rdf/trunk/impl.sparql/src/test/
>>> >> commons/sandbox/rdf/trunk/impl.sparql/src/test/java/
>>> >> commons/sandbox/rdf/trunk/impl.sparql/src/test/java/org/
>>> >> commons/sandbox/rdf/trunk/impl.sparql/src/test/java/org/apache/
>>> >>
>>>  commons/sandbox/rdf/trunk/impl.sparql/src/test/java/org/apache/commons/
>>> >>
>>> >>
>>> commons/sandbox/rdf/trunk/impl.sparql/src/test/java/org/apache/commons/rdf/
>>> >>
>>> >>
>>> commons/sandbox/rdf/trunk/impl.sparql/src/test/java/org/apache/commons/rdf/impl/
>>> >>
>>> >>
>>> commons/sandbox/rdf/trunk/impl.sparql/src/test/java/org/apache/commons/rdf/impl/sparql/
>>> >>
>>> >>
>>> commons/sandbox/rdf/trunk/impl.sparql/src/test/java/org/apache/commons/rdf/impl/sparql/SparqlGraphTest.java
>>> >> commons/sandbox/rdf/trunk/impl.sparql/src/test/resources/
>>> >> commons/sandbox/rdf/trunk/impl.sparql/src/test/resources/org/
>>> >>
>>>  commons/sandbox/rdf/trunk/impl.sparql/src/test/resources/org/apache/
>>> >>
>>> >>
>>> commons/sandbox/rdf/trunk/impl.sparql/src/test/resources/org/apache/commons/
>>> >>
>>> >>
>>> commons/sandbox/rdf/trunk/impl.sparql/src/test/resources/org/apache/commons/rdf/
>>> >>
>>> >>
>>> commons/sandbox/rdf/trunk/impl.sparql/src/test/resources/org/apache/commons/rdf/impl/
>>> >>
>>> >>
>>> commons/sandbox/rdf/trunk/impl.sparql/src/test/resources/org/apache/commons/rdf/impl/sparql/
>>> >>
>>> >>
>>> commons/sandbox/rdf/trunk/impl.sparql/src/test/resources/org/apache/commons/rdf/impl/sparql/grounded.ttl
>>> >> commons/sandbox/rdf/trunk/impl.utils/   (with props)
>>> >> commons/sandbox/rdf/trunk/impl.utils/pom.xml
>>> >>   - copied, changed

Re: [VOTE] Release BCEL 6.0 based on RC3

[Emmanuel Bourg]

Le 19/02/2015 15:17, Ben McCann a écrit :
> Perhaps if there are only a few breaking changes we could prioritize
> reviewing those first and leave the rest for 6.1.  Alternatively, we could
> release what's available now as 6.0 and release all the patches in a couple
> months as 7.0.

I wouldn't force our users to rename all their import statements in a
couple of month as we release BCEL 7.0 with breaking changes because we
didn't want to handle a known issue for BCEL 6.0.

Let's settle this now.

Emmanuel Bourg


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

Re: [VOTE] Release BCEL 6.0 based on RC3

[Benedikt Ritter]

2015-02-19 16:06 GMT+01:00 Emmanuel Bourg :

> Le 19/02/2015 15:17, Ben McCann a écrit :
> > Perhaps if there are only a few breaking changes we could prioritize
> > reviewing those first and leave the rest for 6.1.  Alternatively, we
> could
> > release what's available now as 6.0 and release all the patches in a
> couple
> > months as 7.0.
>
> I wouldn't force our users to rename all their import statements in a
> couple of month as we release BCEL 7.0 with breaking changes because we
> didn't want to handle a known issue for BCEL 6.0.
>
> Let's settle this now.
>

+1


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


-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [VOTE] Release BCEL 6.0 based on RC3

[Ben McCann]

Why do you say users would have to rename all their import statements? Is
there a patch pending that we're consider which would change the package
name? I don't think there'd be any changes that be hard for end users to
deal with that I'm aware of.

On Thu, Feb 19, 2015 at 7:07 AM, Benedikt Ritter  wrote:

> 2015-02-19 16:06 GMT+01:00 Emmanuel Bourg :
>
> > Le 19/02/2015 15:17, Ben McCann a écrit :
> > > Perhaps if there are only a few breaking changes we could prioritize
> > > reviewing those first and leave the rest for 6.1.  Alternatively, we
> > could
> > > release what's available now as 6.0 and release all the patches in a
> > couple
> > > months as 7.0.
> >
> > I wouldn't force our users to rename all their import statements in a
> > couple of month as we release BCEL 7.0 with breaking changes because we
> > didn't want to handle a known issue for BCEL 6.0.
> >
> > Let's settle this now.
> >
>
> +1
>
>
> >
> > Emmanuel Bourg
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>



-- 
about.me/benmccann

Re: [VOTE] Release BCEL 6.0 based on RC3

[Benedikt Ritter]

2015-02-19 16:14 GMT+01:00 Ben McCann :

> Why do you say users would have to rename all their import statements? Is
> there a patch pending that we're consider which would change the package
> name? I don't think there'd be any changes that be hard for end users to
> deal with that I'm aware of.
>

Changing the major version number for a commons component always implies
changing maven coords and the package name. We do this, so that several
versions of the same commons component can be in the same classpath.

Benedikt


>
> On Thu, Feb 19, 2015 at 7:07 AM, Benedikt Ritter 
> wrote:
>
> > 2015-02-19 16:06 GMT+01:00 Emmanuel Bourg :
> >
> > > Le 19/02/2015 15:17, Ben McCann a écrit :
> > > > Perhaps if there are only a few breaking changes we could prioritize
> > > > reviewing those first and leave the rest for 6.1.  Alternatively, we
> > > could
> > > > release what's available now as 6.0 and release all the patches in a
> > > couple
> > > > months as 7.0.
> > >
> > > I wouldn't force our users to rename all their import statements in a
> > > couple of month as we release BCEL 7.0 with breaking changes because we
> > > didn't want to handle a known issue for BCEL 6.0.
> > >
> > > Let's settle this now.
> > >
> >
> > +1
> >
> >
> > >
> > > Emmanuel Bourg
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
> >
> > --
> > http://people.apache.org/~britter/
> > http://www.systemoutprintln.de/
> > http://twitter.com/BenediktRitter
> > http://github.com/britter
> >
>
>
>
> --
> about.me/benmccann
>



-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [VOTE] Release BCEL 6.0 based on RC3

[sebb]

On 19 February 2015 at 15:19, Benedikt Ritter  wrote:
> 2015-02-19 16:14 GMT+01:00 Ben McCann :
>
>> Why do you say users would have to rename all their import statements? Is
>> there a patch pending that we're consider which would change the package
>> name? I don't think there'd be any changes that be hard for end users to
>> deal with that I'm aware of.
>>
>
> Changing the major version number for a commons component always implies
> changing maven coords and the package name. We do this, so that several
> versions of the same commons component can be in the same classpath.

That's cart before horse.

The major version number change is not the driver here.

If a release breaks binary compatibility then the major version must
change and so must the package/Maven coords.

It's perfectly possible to bump the major version number and not
change package name / Maven coords provided that the release is still
binary compatible.

However, according to SemVer one should bump major version if and only
if breaking compat.
It's only recently that Commons has started discussing whether to use
strict SemVer or not; I don't think it has been agreed for all
components.

For example, one might want to have a major version bump if the Java
version requirements changed from say 1.4 to 1.8, even though it was
still binary compat.


> Benedikt
>
>
>>
>> On Thu, Feb 19, 2015 at 7:07 AM, Benedikt Ritter 
>> wrote:
>>
>> > 2015-02-19 16:06 GMT+01:00 Emmanuel Bourg :
>> >
>> > > Le 19/02/2015 15:17, Ben McCann a écrit :
>> > > > Perhaps if there are only a few breaking changes we could prioritize
>> > > > reviewing those first and leave the rest for 6.1.  Alternatively, we
>> > > could
>> > > > release what's available now as 6.0 and release all the patches in a
>> > > couple
>> > > > months as 7.0.
>> > >
>> > > I wouldn't force our users to rename all their import statements in a
>> > > couple of month as we release BCEL 7.0 with breaking changes because we
>> > > didn't want to handle a known issue for BCEL 6.0.
>> > >
>> > > Let's settle this now.
>> > >
>> >
>> > +1
>> >
>> >
>> > >
>> > > Emmanuel Bourg
>> > >
>> > >
>> > > -
>> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > > For additional commands, e-mail: dev-h...@commons.apache.org
>> > >
>> > >
>> >
>> >
>> > --
>> > http://people.apache.org/~britter/
>> > http://www.systemoutprintln.de/
>> > http://twitter.com/BenediktRitter
>> > http://github.com/britter
>> >
>>
>>
>>
>> --
>> about.me/benmccann
>>
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter

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

Re: [VOTE] Release BCEL 6.0 based on RC3

[Emmanuel Bourg]

Le 19/02/2015 16:29, sebb a écrit :

> However, according to SemVer one should bump major version if and only
> if breaking compat.
> It's only recently that Commons has started discussing whether to use
> strict SemVer or not; I don't think it has been agreed for all
> components.

SemVer provides sane guidelines but I wouldn't follow it religiously. In
my opinion a major version bump is ok even if the compatibility is
preserved, it can denote major improvements like the ones staged for
BCEL 6.0.

Emmanuel Bourg


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

Re: svn commit: r1659973 [1/3] - in /commons/sandbox/rdf/trunk: ./ api/src/main/java/org/apache/commons/rdf/ impl.sparql/ impl.sparql/src/ impl.sparql/src/main/ impl.sparql/src/main/java/ impl.sparql/

[Reto Gmür]

Hi all,

Sorry that I couldn't reply earlier.

Stian is right, this is code that might become part of the incubating
project.

It is not about having a non-trivial implementation but about a proof
of-concept implementation against a SPARQL Backend as a mean to evaluate
design decisions in the API.

Cheers,
Reto

On Thu, Feb 19, 2015 at 4:01 PM, Stian Soiland-Reyes 
wrote:

> I am not speaking for Reto, but I imagined that since Reto has joined
> the CommonsRDF incubator proposal, then his sandbox-code would
> eventually turn into pull requests and branches on the incubator
> codebase so that we can evaluate each of the differences separately.
>
>
> On 19 February 2015 at 06:54, Benedikt Ritter  wrote:
> > 2015-02-17 7:04 GMT+01:00 Benedikt Ritter :
> >
> >>
> >>
> >> 2015-02-17 0:13 GMT+01:00 Peter Ansell :
> >>
> >>> Hi Bernard,
> >>>
> >>> The Commons RDF project is not planning on including any non-trivial
> >>> implementations, to avoid bias towards any of the participating
> >>> platforms. Stian has written a trivial implementation and submitted it
> >>> to GitHub to provide a reference for our test harness, but it is never
> >>> planned to be used by anyone for non-trivial purposes.
> >>>
> >>> Reto is moving this code here unilaterally from Clerezza at this point
> >>> based on the ability of any Apache committer to send code into Apache
> >>> Commons.
> >>>
> >>> The code that will be sent to the incubator is still planned to be the
> >>> code that is in the GitHub repository at the time the incubator
> >>> request goes through.
> >>>
> >>
> >> This is still in the sandbox so I'm not too crazy about it. But
> creating a
> >> separate code base in the commons-rdf git repository doesn't sound like
> a
> >> good idea given the fact that github Commons RDF will eventually move to
> >> Apache Commons after incubation. What should haben with the code that
> is in
> >> the repository by that time?
> >>
> >> Reto, can you comment please?
> >>
> >
> > Reto, I'm still waiting for your comment.
> >
> >
> >>
> >> Regards,
> >> Benedikt
> >>
> >>
> >>>
> >>> Cheers,
> >>>
> >>> Peter
> >>>
> >>> On 16 February 2015 at 18:34, Benedikt Ritter 
> wrote:
> >>> > Hello Reto,
> >>> >
> >>> > how does this relate to github Commons RDF? Is this part of the code
> >>> base
> >>> > proposed for incubation?
> >>> >
> >>> > Regards,
> >>> > Benedikt
> >>> >
> >>> > 2015-02-15 19:41 GMT+01:00 :
> >>> >
> >>> >> Author: reto
> >>> >> Date: Sun Feb 15 18:41:15 2015
> >>> >> New Revision: 1659973
> >>> >>
> >>> >> URL: http://svn.apache.org/r1659973
> >>> >> Log:
> >>> >> Started SPARQL Backed Implementation
> >>> >>
> >>> >> Added:
> >>> >> commons/sandbox/rdf/trunk/alerts.txt
> >>> >> commons/sandbox/rdf/trunk/impl.sparql/   (with props)
> >>> >> commons/sandbox/rdf/trunk/impl.sparql/pom.xml
> >>> >> commons/sandbox/rdf/trunk/impl.sparql/src/
> >>> >> commons/sandbox/rdf/trunk/impl.sparql/src/main/
> >>> >> commons/sandbox/rdf/trunk/impl.sparql/src/main/java/
> >>> >> commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/
> >>> >> commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/apache/
> >>> >>
> >>>
> commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/apache/commons/
> >>> >>
> >>> >>
> >>>
> commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/apache/commons/rdf/
> >>> >>
> >>> >>
> >>>
> commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/apache/commons/rdf/impl/
> >>> >>
> >>> >>
> >>>
> commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/apache/commons/rdf/impl/sparql/
> >>> >>
> >>> >>
> >>>
> commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/apache/commons/rdf/impl/sparql/SparqlClient.java
> >>> >>
> >>> >>
> >>>
> commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/apache/commons/rdf/impl/sparql/SparqlGraph.java
> >>> >> commons/sandbox/rdf/trunk/impl.sparql/src/main/resources/
> >>> >> commons/sandbox/rdf/trunk/impl.sparql/src/test/
> >>> >> commons/sandbox/rdf/trunk/impl.sparql/src/test/java/
> >>> >> commons/sandbox/rdf/trunk/impl.sparql/src/test/java/org/
> >>> >> commons/sandbox/rdf/trunk/impl.sparql/src/test/java/org/apache/
> >>> >>
> >>>
> commons/sandbox/rdf/trunk/impl.sparql/src/test/java/org/apache/commons/
> >>> >>
> >>> >>
> >>>
> commons/sandbox/rdf/trunk/impl.sparql/src/test/java/org/apache/commons/rdf/
> >>> >>
> >>> >>
> >>>
> commons/sandbox/rdf/trunk/impl.sparql/src/test/java/org/apache/commons/rdf/impl/
> >>> >>
> >>> >>
> >>>
> commons/sandbox/rdf/trunk/impl.sparql/src/test/java/org/apache/commons/rdf/impl/sparql/
> >>> >>
> >>> >>
> >>>
> commons/sandbox/rdf/trunk/impl.sparql/src/test/java/org/apache/commons/rdf/impl/sparql/SparqlGraphTest.java
> >>> >> commons/sandbox/rdf/trunk/impl.sparql/src/test/resources/
> >>> >> commons/sandbox/rdf/trunk/impl.sparql/src/test/resources/org/
> >>> >>
> >>>  commons/sandbox/rdf/trunk/impl.sparql/src/test/resources/org/apache/
> >>> >>
> >>> >>
> >>>
> commons/sand

Re: svn commit: r1659973 [1/3] - in /commons/sandbox/rdf/trunk: ./ api/src/main/java/org/apache/commons/rdf/ impl.sparql/ impl.sparql/src/ impl.sparql/src/main/ impl.sparql/src/main/java/ impl.sparql/

[Stian Soiland-Reyes]

Great we are on the same page :)

I also think a SPARQL backend will be a reasonable way to push the API
boundaries, so we can evaluate aspects relating to streaming, blank
node identifiers, etc. for an implementation that has less direct
control of its triples.

It could also eventually serve as a useful last-resort bridge to
connect non-JVM stores to the Commons RDF API - I guess if we get to
that point it could be decided then if that actually outgrows the API
and should become its own project.

I would want to develop a couple of "application" scenarios to test
the API from the client side (e.g. a simple N-triples parser and
writer) - and they would also be on the edge of what is in scope of
Commons RDF.

Perhaps we need our own 'sandbox' playground within the Commons RDF
incubator.. otherwise I would just do it as a bunch of personal GitHub
projects, but that's not quite the Apache Way.

On 19 February 2015 at 15:56, Reto Gmür  wrote:
> Hi all,
>
> Sorry that I couldn't reply earlier.
>
> Stian is right, this is code that might become part of the incubating
> project.
>
> It is not about having a non-trivial implementation but about a proof
> of-concept implementation against a SPARQL Backend as a mean to evaluate
> design decisions in the API.
>
> Cheers,
> Reto
>
> On Thu, Feb 19, 2015 at 4:01 PM, Stian Soiland-Reyes 
> wrote:
>
>> I am not speaking for Reto, but I imagined that since Reto has joined
>> the CommonsRDF incubator proposal, then his sandbox-code would
>> eventually turn into pull requests and branches on the incubator
>> codebase so that we can evaluate each of the differences separately.
>>
>>
>> On 19 February 2015 at 06:54, Benedikt Ritter  wrote:
>> > 2015-02-17 7:04 GMT+01:00 Benedikt Ritter :
>> >
>> >>
>> >>
>> >> 2015-02-17 0:13 GMT+01:00 Peter Ansell :
>> >>
>> >>> Hi Bernard,
>> >>>
>> >>> The Commons RDF project is not planning on including any non-trivial
>> >>> implementations, to avoid bias towards any of the participating
>> >>> platforms. Stian has written a trivial implementation and submitted it
>> >>> to GitHub to provide a reference for our test harness, but it is never
>> >>> planned to be used by anyone for non-trivial purposes.
>> >>>
>> >>> Reto is moving this code here unilaterally from Clerezza at this point
>> >>> based on the ability of any Apache committer to send code into Apache
>> >>> Commons.
>> >>>
>> >>> The code that will be sent to the incubator is still planned to be the
>> >>> code that is in the GitHub repository at the time the incubator
>> >>> request goes through.
>> >>>
>> >>
>> >> This is still in the sandbox so I'm not too crazy about it. But
>> creating a
>> >> separate code base in the commons-rdf git repository doesn't sound like
>> a
>> >> good idea given the fact that github Commons RDF will eventually move to
>> >> Apache Commons after incubation. What should haben with the code that
>> is in
>> >> the repository by that time?
>> >>
>> >> Reto, can you comment please?
>> >>
>> >
>> > Reto, I'm still waiting for your comment.
>> >
>> >
>> >>
>> >> Regards,
>> >> Benedikt
>> >>
>> >>
>> >>>
>> >>> Cheers,
>> >>>
>> >>> Peter
>> >>>
>> >>> On 16 February 2015 at 18:34, Benedikt Ritter 
>> wrote:
>> >>> > Hello Reto,
>> >>> >
>> >>> > how does this relate to github Commons RDF? Is this part of the code
>> >>> base
>> >>> > proposed for incubation?
>> >>> >
>> >>> > Regards,
>> >>> > Benedikt
>> >>> >
>> >>> > 2015-02-15 19:41 GMT+01:00 :
>> >>> >
>> >>> >> Author: reto
>> >>> >> Date: Sun Feb 15 18:41:15 2015
>> >>> >> New Revision: 1659973
>> >>> >>
>> >>> >> URL: http://svn.apache.org/r1659973
>> >>> >> Log:
>> >>> >> Started SPARQL Backed Implementation
>> >>> >>
>> >>> >> Added:
>> >>> >> commons/sandbox/rdf/trunk/alerts.txt
>> >>> >> commons/sandbox/rdf/trunk/impl.sparql/   (with props)
>> >>> >> commons/sandbox/rdf/trunk/impl.sparql/pom.xml
>> >>> >> commons/sandbox/rdf/trunk/impl.sparql/src/
>> >>> >> commons/sandbox/rdf/trunk/impl.sparql/src/main/
>> >>> >> commons/sandbox/rdf/trunk/impl.sparql/src/main/java/
>> >>> >> commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/
>> >>> >> commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/apache/
>> >>> >>
>> >>>
>> commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/apache/commons/
>> >>> >>
>> >>> >>
>> >>>
>> commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/apache/commons/rdf/
>> >>> >>
>> >>> >>
>> >>>
>> commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/apache/commons/rdf/impl/
>> >>> >>
>> >>> >>
>> >>>
>> commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/apache/commons/rdf/impl/sparql/
>> >>> >>
>> >>> >>
>> >>>
>> commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/apache/commons/rdf/impl/sparql/SparqlClient.java
>> >>> >>
>> >>> >>
>> >>>
>> commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/apache/commons/rdf/impl/sparql/SparqlGraph.java
>> >>> >> commons/sandbox/rdf/trunk/impl.sparql/src/main/resources

Re: svn commit: r1659973 [1/3] - in /commons/sandbox/rdf/trunk: ./ api/src/main/java/org/apache/commons/rdf/ impl.sparql/ impl.sparql/src/ impl.sparql/src/main/ impl.sparql/src/main/java/ impl.sparql/

[Andy Seaborne]

On 19/02/15 16:05, Stian Soiland-Reyes wrote:

Great we are on the same page :)

I also think a SPARQL backend will be a reasonable way to push the API
boundaries, so we can evaluate aspects relating to streaming, blank
node identifiers, etc. for an implementation that has less direct
control of its triples.

It could also eventually serve as a useful last-resort bridge to
connect non-JVM stores to the Commons RDF API - I guess if we get to
that point it could be decided then if that actually outgrows the API
and should become its own project.

I would want to develop a couple of "application" scenarios to test
the API from the client side (e.g. a simple N-triples parser and
writer) - and they would also be on the edge of what is in scope of
Commons RDF.

Perhaps we need our own 'sandbox' playground within the Commons RDF
incubator.. otherwise I would just do it as a bunch of personal GitHub
projects, but that's not quite the Apache Way.


Experimentation is important and not limited to people "inside". 
Contributions can come from anyone.


Andy



On 19 February 2015 at 15:56, Reto Gmür  wrote:

Hi all,

Sorry that I couldn't reply earlier.

Stian is right, this is code that might become part of the incubating
project.

It is not about having a non-trivial implementation but about a proof
of-concept implementation against a SPARQL Backend as a mean to evaluate
design decisions in the API.

Cheers,
Reto

On Thu, Feb 19, 2015 at 4:01 PM, Stian Soiland-Reyes 
wrote:


I am not speaking for Reto, but I imagined that since Reto has joined
the CommonsRDF incubator proposal, then his sandbox-code would
eventually turn into pull requests and branches on the incubator
codebase so that we can evaluate each of the differences separately.


On 19 February 2015 at 06:54, Benedikt Ritter  wrote:

2015-02-17 7:04 GMT+01:00 Benedikt Ritter :




2015-02-17 0:13 GMT+01:00 Peter Ansell :


Hi Bernard,

The Commons RDF project is not planning on including any non-trivial
implementations, to avoid bias towards any of the participating
platforms. Stian has written a trivial implementation and submitted it
to GitHub to provide a reference for our test harness, but it is never
planned to be used by anyone for non-trivial purposes.

Reto is moving this code here unilaterally from Clerezza at this point
based on the ability of any Apache committer to send code into Apache
Commons.

The code that will be sent to the incubator is still planned to be the
code that is in the GitHub repository at the time the incubator
request goes through.



This is still in the sandbox so I'm not too crazy about it. But

creating a

separate code base in the commons-rdf git repository doesn't sound like

a

good idea given the fact that github Commons RDF will eventually move to
Apache Commons after incubation. What should haben with the code that

is in

the repository by that time?

Reto, can you comment please?



Reto, I'm still waiting for your comment.




Regards,
Benedikt




Cheers,

Peter

On 16 February 2015 at 18:34, Benedikt Ritter 

wrote:

Hello Reto,

how does this relate to github Commons RDF? Is this part of the code

base

proposed for incubation?

Regards,
Benedikt

2015-02-15 19:41 GMT+01:00 :


Author: reto
Date: Sun Feb 15 18:41:15 2015
New Revision: 1659973

URL: http://svn.apache.org/r1659973
Log:
Started SPARQL Backed Implementation

Added:
 commons/sandbox/rdf/trunk/alerts.txt
 commons/sandbox/rdf/trunk/impl.sparql/   (with props)
 commons/sandbox/rdf/trunk/impl.sparql/pom.xml
 commons/sandbox/rdf/trunk/impl.sparql/src/
 commons/sandbox/rdf/trunk/impl.sparql/src/main/
 commons/sandbox/rdf/trunk/impl.sparql/src/main/java/
 commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/
 commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/apache/




commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/apache/commons/






commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/apache/commons/rdf/






commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/apache/commons/rdf/impl/






commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/apache/commons/rdf/impl/sparql/






commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/apache/commons/rdf/impl/sparql/SparqlClient.java






commons/sandbox/rdf/trunk/impl.sparql/src/main/java/org/apache/commons/rdf/impl/sparql/SparqlGraph.java

 commons/sandbox/rdf/trunk/impl.sparql/src/main/resources/
 commons/sandbox/rdf/trunk/impl.sparql/src/test/
 commons/sandbox/rdf/trunk/impl.sparql/src/test/java/
 commons/sandbox/rdf/trunk/impl.sparql/src/test/java/org/
 commons/sandbox/rdf/trunk/impl.sparql/src/test/java/org/apache/




commons/sandbox/rdf/trunk/impl.sparql/src/test/java/org/apache/commons/






commons/sandbox/rdf/trunk/impl.sparql/src/test/java/org/apache/commons/rdf/






commons/sandbox/rdf/trunk/impl.sparql/src/test/java/org/apache/commons/rdf/impl/






commons/sandbox/rdf/trunk/impl.sparql/src/te

RE: [bcel] PLSE changes to BCEL

[Mark Roberts]

I am going to try to spend most of today working on BCEL; I am currently 
looking at 195, 200,203,208 and 210.

Mark



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

Re: [VOTE] Release BCEL 6.0 based on RC3

[Stian Soiland-Reyes]

That sounds more like a political release number, I would hope we were
not too political here (except about Apache values :) )

Changing the major version number should cause Maven/OSGi to moan if
project A needs say bcel 5.1 and another tries to pull in 6.0 - that
would be the purpose of the major version number change.

If there is no binary incompatibility introduced, then it seems
pointless to enforce such warnings with a new major version in pom.xml
and friends.

The nature of the project matters - say an application which is not
dependended on as a library would be more natural to bump the major
version when there are significant UI or feature changes.


(This is a very relevant discussion as another thread was just talking
about updating https://commons.apache.org/releases/versioning.html to
relate to SemVer)


On 19 February 2015 at 15:38, Emmanuel Bourg  wrote:
> Le 19/02/2015 16:29, sebb a écrit :
>
>> However, according to SemVer one should bump major version if and only
>> if breaking compat.
>> It's only recently that Commons has started discussing whether to use
>> strict SemVer or not; I don't think it has been agreed for all
>> components.
>
> SemVer provides sane guidelines but I wouldn't follow it religiously. In
> my opinion a major version bump is ok even if the compatibility is
> preserved, it can denote major improvements like the ones staged for
> BCEL 6.0.
>
> Emmanuel Bourg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/-0001-9842-9718

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

[GitHub] commons-lang pull request: Remove busy wait

[artnaseef]

GitHub user artnaseef opened a pull request:

https://github.com/apache/commons-lang/pull/46

Remove busy wait

Remove the busy wait from AtomicSafeInitializer.get().

Also ensure waiting threads do not wait indefinitely after initialize() 
throws an exception, instead throwing the same exception, re-wrapped, for each 
requester.

Brought the unit tests up to 100% coverage on AtomicSafeInitializer.  
Eliminated race condition on verifying at least one thread waiting for 
initialize() to complete in another thread.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/artnaseef/commons-lang removeBusyWait

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/46.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #46


commit 2636258c9304e3a346a3a215bf923c462ffb05e0
Author: artnaseef 
Date:   2015-02-19T16:58:21Z

- Remove the busy waits in AtomicSafeInitializer
- Avoid stranded callers when initialize throws an exception
- Add tests for exception handling
- Add a more reliable test for concurrent threads with one thread waiting 
on another to finish the initialize call

commit 970498309a6ff3afee1a6749bbb951d00bcdd5bc
Author: artnaseef 
Date:   2015-02-19T18:24:18Z

- Add a useful message on throwing the wrapped InterruptedException
- Restore the old import style for static imports




---
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: [VOTE] Release BCEL 6.0 based on RC3

[sebb]

On 19 February 2015 at 17:13, Stian Soiland-Reyes  wrote:
> That sounds more like a political release number, I would hope we were
> not too political here (except about Apache values :) )

Not necessarily, my example was about requiring a major bump in JVM version.
Still binary compatible, but might require users to upgrade their host JVM.
Therefore it may be worth flagging the change to end-users via the
version number.

> Changing the major version number should cause Maven/OSGi t
o moan if
> project A needs say bcel 5.1 and another tries to pull in 6.0 - that
> would be the purpose of the major version number change.

AFAIK Maven does not do that.

OSGi may do so; I don't know.

> If there is no binary incompatibility introduced, then it seems
> pointless to enforce such warnings with a new major version in pom.xml
> and friends.

What is the evidence that a major bump causes warnings?

> The nature of the project matters - say an application which is not
> dependended on as a library would be more natural to bump the major
> version when there are significant UI or feature changes.

Yes, and such projects don't really need to pay much attention to
binary compatibility either.

>
> (This is a very relevant discussion as another thread was just talking
> about updating https://commons.apache.org/releases/versioning.html to
> relate to SemVer)
>
>
> On 19 February 2015 at 15:38, Emmanuel Bourg  wrote:
>> Le 19/02/2015 16:29, sebb a écrit :
>>
>>> However, according to SemVer one should bump major version if and only
>>> if breaking compat.
>>> It's only recently that Commons has started discussing whether to use
>>> strict SemVer or not; I don't think it has been agreed for all
>>> components.
>>
>> SemVer provides sane guidelines but I wouldn't follow it religiously. In
>> my opinion a major version bump is ok even if the compatibility is
>> preserved, it can denote major improvements like the ones staged for
>> BCEL 6.0.

+1

>>
>> Emmanuel Bourg
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating)
> http://orcid.org/-0001-9842-9718
>
> -
> 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: [VOTE] Release BCEL 6.0 based on RC3

[Gary Gregory]

On Thu, Feb 19, 2015 at 7:19 AM, Benedikt Ritter  wrote:

> 2015-02-19 16:14 GMT+01:00 Ben McCann :
>
> > Why do you say users would have to rename all their import statements? Is
> > there a patch pending that we're consider which would change the package
> > name? I don't think there'd be any changes that be hard for end users to
> > deal with that I'm aware of.
> >
>
> Changing the major version number for a commons component always implies
> changing maven coords and the package name.


No, it does not. We can release a new major version without a new package
name and new maven coords IFF the new version is binary compatible.

Gary



> We do this, so that several
> versions of the same commons component can be in the same classpath.
>
> Benedikt
>
>
> >
> > On Thu, Feb 19, 2015 at 7:07 AM, Benedikt Ritter 
> > wrote:
> >
> > > 2015-02-19 16:06 GMT+01:00 Emmanuel Bourg :
> > >
> > > > Le 19/02/2015 15:17, Ben McCann a écrit :
> > > > > Perhaps if there are only a few breaking changes we could
> prioritize
> > > > > reviewing those first and leave the rest for 6.1.  Alternatively,
> we
> > > > could
> > > > > release what's available now as 6.0 and release all the patches in
> a
> > > > couple
> > > > > months as 7.0.
> > > >
> > > > I wouldn't force our users to rename all their import statements in a
> > > > couple of month as we release BCEL 7.0 with breaking changes because
> we
> > > > didn't want to handle a known issue for BCEL 6.0.
> > > >
> > > > Let's settle this now.
> > > >
> > >
> > > +1
> > >
> > >
> > > >
> > > > Emmanuel Bourg
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > http://people.apache.org/~britter/
> > > http://www.systemoutprintln.de/
> > > http://twitter.com/BenediktRitter
> > > http://github.com/britter
> > >
> >
> >
> >
> > --
> > about.me/benmccann
> >
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>



-- 
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][JCS] release [jcs] 2.0-beta-1 (take 4)

[Oliver Heger]

Hi,

maybe the problem is on my side (it has been a long day), but I am not
able to verify the signature of the distributions:

$ gpg --verify commons-jcs-dist-2.0-beta-1-src.zip.asc
gpg: Signature made 02/19/15 11:51:21 using RSA key ID DDB37997
gpg: Can't check signature: public key not found

I imported the most recent keys from
http://www.apache.org/dist/commons/KEYS

but here your key has the ID B863A7C1.

Oliver

Am 19.02.2015 um 14:28 schrieb Romain Manni-Bucau:
> Hi
> 
> Another try, hopefully right this time (I speak about JCS in a JUG
> next thursday so would be awesome to have a release ;))
> 
> - here is the maven repo:
> https://repository.apache.org/content/repositories/orgapachecommons-1083/
> - assemblies can be found here
> https://repository.apache.org/content/repositories/orgapachecommons-1083/org/apache/commons/commons-jcs-dist/2.0-beta-1/
> - tag is here: 
> http://svn.apache.org/repos/asf/commons/proper/jcs/tags/commons-jcs-2.0-beta-1/
> - Site staging is:
> http://people.apache.org/~rmannibucau/commons-jcs-2.0-beta-1-site/
> - rat report is here (I deleted zipcodes.txt and CDI SPI
> (META-INF/services/...) from reports since it seems rat config with
> append parameter is not well respected but that's really what we
> want):
> http://people.apache.org/~rmannibucau/commons-jcs-2.0-beta-1-site/rat-report.html
> 
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now or until we get
> 3 PMC votes.
> 
> [ ] +1 Release these artifacts
> [ ] +-0 OK, but...
> [ ] -1 I oppose this release because...
> 
> 
> Here is my +1
> 
> 
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
> 
> -
> 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: [DISCUSS] Commons RDF to join the Apache Incubator

[Gary Gregory]

On Sun, Feb 15, 2015 at 2:29 AM, Benedikt Ritter  wrote:

> Hi all,
>
> at first sorry for the delay. I've been on vacation the last 10 days with
> no access to my emails.
>

Same for me.

Gary


>
> 2015-02-10 21:31 GMT+01:00 Marvin Humphrey :
>
> > On Tue, Feb 10, 2015 at 7:21 AM, Stian Soiland-Reyes 
> > wrote:
> >
> > > The natural path to Apache Commons Sandbox has been studied, but we
> > > think that in this phase of the project, which focuses on the API
> > > design and actively involves the developers of existing toolkits, it
> > > is better to have a more focused community and infrastructure. Rather
> > > than a new Top-Level Project, the goal is still to graduate as part of
> > > Apache Commons, that is when API has achieve the required maturity and
> > > the project goes into maintenance mode.
> >
> > If Commons is OK with this, I imagine this is a fine plan -- good enough
> > for
> > entering incubation.
> >
>
> Short answer: The Apache Commons community is fine with this.
>
> Long answer: There has been some confusion (and misunderstanding?) about
> the way the Apache Commons project works. The Commons RDF community wanted
> to use either github or a separate mailing list for shaping out the initial
> API. The first in our opinion doesn't work since Apache projects have to
> use Apache infrastructure. The latter wasn't possible since we don't what
> to create sub communities inside commons [1]. This is a lesson learned from
> Jakarta (note that I've not been around by the time Jakarta shout down, so
> I'm just writing down, what I've learned from others). This eventually led
> to the suggestion to go though the incubator. [2]
>
> We like to underline, that we have no experience with the RDF
> specification. From a technical point of view we can help to develop the
> proposed API (according to our design guide lines [3]). But we need the
> people the the RDF space to review contributions from a semantic PoV. So
> this should not end up like developing the RDF library at the incubator and
> then hand it of for maintenance to the Commons community. I think all
> people involved here have pointed out, that they are willing to work on the
> project even after it's initial release. Note, that we have recently
> granted write access to all ASF committers [4]. So if Commons RDF
> eventually moves to Apache Commons, anybody from the Jena/Sesame/Clerezza
> projects may join the development.
>
>
> >
> > I also think it would be OK for the project to decide it wants to become
> a
> > TLP.  Whether the project joins Commons or becomes its own TLP won't
> impact
> > the number of people qualified to work on it.  Some Apache TLPs are
> > effectively in maintenance mode and have very low activity, but still
> have
> > PMC
> > members willing to answer user questions, make security releases and file
> > "still here" quarterly reports.  That seems like a legitimate aspiration
> > for
> > this project.
> >
>
> In the case of Commons RDF going TLP we would like to ask the project to
> choose a different name to avoid confusion. But I think this has already
> been discussed in this thread.
>
> Regards,
> Benedikt
>
> [1] http://markmail.org/message/mnlh64qod7cuuj56
> [2] http://markmail.org/message/wl6hpkb4nhsroro5
> [3] http://commons.apache.org/releases/versioning.html
> [4] http://markmail.org/message/ylmw7qzx23br4ver
>
>
> >
> > A potential Jena destination also seems as though it would have certain
> > advantages, though my naive speculation is that it might be sub-optimal
> in
> > terms of providing neutral territory for negotiating a common API for
> Jena
> > and
> > Sesame.
> >
> > In any case it seems likely that if the project achieves its design goal,
> > there will be people willing to work on it as long as both Jena and
> Sesame
> > remain viable.  That makes it different from other potential "maintenance
> > mode" TLPs which are in danger of stagnation because they cannot renew
> > their
> > communities.
> >
> > Is that take roughly accurate, Sergio et al?
>
>
> > > === Mailing lists ===
> > >
> > >  * commons-rdf-dev
> > >  * commons-rdf-commits
> >
> > Those sound like final mailing lists rather than Incubator ones.  I might
> > have
> > expected these instead:
> >
> > d...@commons-rdf.incubator.apache.org
> > comm...@commons-rdf.incubator.apache.org
> >
> > Do you expect to keep separate mailing lists after graduation, or will
> > traffic
> > be shunted onto existing Commons mailing list like
> dev@commons.apache.org
> > and
> > comm...@commons.apache.org?
> >
> > >  * Sergio Fernández (wikier dot apache dot org)
> > >  * Andy Seaborne (andy dot apache dot org)
> > >  * Peter Ansell (ansell dot apache dot org)
> > >  * Stian Soiland-Reyes (stain at apache dot org)
> > >  * Reto Gmür (reto at apache dot org)
> >
> > Lots of Apache experience in this group.  Four are PMC members of at
> least
> > one
> > Apache project.  Andy and Reto are ASF Members.  Andy and Sergio are both
> > IPMC
> > 

Re: [VOTE][JCS] release [jcs] 2.0-beta-1 (take 4)

[Romain Manni-Bucau]

Oops you are right, forgot I changed of key with my hard drive :s. My
key can be found in http://svn.apache.org/repos/asf/geronimo/KEYS.
I'll add it in commons tomorrow.

Sorry again


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-02-19 22:12 GMT+01:00 Oliver Heger :
> Hi,
>
> maybe the problem is on my side (it has been a long day), but I am not
> able to verify the signature of the distributions:
>
> $ gpg --verify commons-jcs-dist-2.0-beta-1-src.zip.asc
> gpg: Signature made 02/19/15 11:51:21 using RSA key ID DDB37997
> gpg: Can't check signature: public key not found
>
> I imported the most recent keys from
> http://www.apache.org/dist/commons/KEYS
>
> but here your key has the ID B863A7C1.
>
> Oliver
>
> Am 19.02.2015 um 14:28 schrieb Romain Manni-Bucau:
>> Hi
>>
>> Another try, hopefully right this time (I speak about JCS in a JUG
>> next thursday so would be awesome to have a release ;))
>>
>> - here is the maven repo:
>> https://repository.apache.org/content/repositories/orgapachecommons-1083/
>> - assemblies can be found here
>> https://repository.apache.org/content/repositories/orgapachecommons-1083/org/apache/commons/commons-jcs-dist/2.0-beta-1/
>> - tag is here: 
>> http://svn.apache.org/repos/asf/commons/proper/jcs/tags/commons-jcs-2.0-beta-1/
>> - Site staging is:
>> http://people.apache.org/~rmannibucau/commons-jcs-2.0-beta-1-site/
>> - rat report is here (I deleted zipcodes.txt and CDI SPI
>> (META-INF/services/...) from reports since it seems rat config with
>> append parameter is not well respected but that's really what we
>> want):
>> http://people.apache.org/~rmannibucau/commons-jcs-2.0-beta-1-site/rat-report.html
>>
>> Please review the release candidate and vote.
>> This vote will close no sooner that 72 hours from now or until we get
>> 3 PMC votes.
>>
>> [ ] +1 Release these artifacts
>> [ ] +-0 OK, but...
>> [ ] -1 I oppose this release because...
>>
>>
>> Here is my +1
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>> -
>> 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: [VOTE] Release BCEL 6.0 based on RC3

[Ben McCann]

Is BCEL-209 the only pending issue that would break binary compatibility?
Perhaps we could prioritize the issues that would break compatibility.
On Thu, Feb 19, 2015 at 7:19 AM, Benedikt Ritter  wrote:

> 2015-02-19 16:14 GMT+01:00 Ben McCann :
>
> > Why do you say users would have to rename all their import statements?
Is
> > there a patch pending that we're consider which would change the package
> > name? I don't think there'd be any changes that be hard for end users to
> > deal with that I'm aware of.
> >
>
> Changing the major version number for a commons component always implies
> changing maven coords and the package name.


No, it does not. We can release a new major version without a new package
name and new maven coords IFF the new version is binary compatible.

Gary



> We do this, so that several
> versions of the same commons component can be in the same classpath.
>
> Benedikt
>
>
> >
> > On Thu, Feb 19, 2015 at 7:07 AM, Benedikt Ritter 
> > wrote:
> >
> > > 2015-02-19 16:06 GMT+01:00 Emmanuel Bourg :
> > >
> > > > Le 19/02/2015 15:17, Ben McCann a écrit :
> > > > > Perhaps if there are only a few breaking changes we could
> prioritize
> > > > > reviewing those first and leave the rest for 6.1.  Alternatively,
> we
> > > > could
> > > > > release what's available now as 6.0 and release all the patches in
> a
> > > > couple
> > > > > months as 7.0.
> > > >
> > > > I wouldn't force our users to rename all their import statements in
a
> > > > couple of month as we release BCEL 7.0 with breaking changes because
> we
> > > > didn't want to handle a known issue for BCEL 6.0.
> > > >
> > > > Let's settle this now.
> > > >
> > >
> > > +1
> > >
> > >
> > > >
> > > > Emmanuel Bourg
> > > >
> > > >
> > > >
-
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > http://people.apache.org/~britter/
> > > http://www.systemoutprintln.de/
> > > http://twitter.com/BenediktRitter
> > > http://github.com/britter
> > >
> >
> >
> >
> > --
> > about.me/benmccann
> >
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>



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

Semantic versioning (was: [VOTE] Release BCEL 6.0 based on RC3)

[Stian Soiland-Reyes]

On 19 February 2015 at 18:47, sebb  wrote:
> Not necessarily, my example was about requiring a major bump in JVM version.
> Still binary compatible, but might require users to upgrade their host JVM.
> Therefore it may be worth flagging the change to end-users via the
> version number.

Agreed that in Commons could be a good example for bumping major
without changing the package name, although generally speaking "change
of dependency requirements" would be a minor change.


> AFAIK Maven does not do that.

No (but perhaps it should).

Maven's understanding of "1.5" without any ranges will also cover
"2.1" - which by SemVer is risky business (perhaps your favourite
public method has been deleted), although with the Commons versioning
practice, it should still generally "just work" if a Commons module
changed major without binary incompatibility (e.g. for JVM example)
and thus didn't rename.


Maven 3 will honour a range like [1.3,2.0) (which should be the
SemVer-safe way to depend on 1.3.x but avoiding 2.0.0 and above).

If a dependency with such a range is combined with another dependency
that pulls in a at first look conflicting version, say "2.1", then as
"2.1" is a not a range, it is a "soft requirement" with no min or max,
thus say 1.5  would satisfy both dependencies.

http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges


Depending on the change and usage this might or might not work at
compile and/or runtime. For instance, if you have a Java interface
that renames a method, that is clearly a new major version (and new
artifact within Commons) - yet (without such ranges) Maven will
happily let you use an older implementation that does not implement
the method that you are calling - the error is not apparent until
runtime.


If you have two incompatible ranges, say "2.1" is changed to [2.1,) -
then you get error from Maven 3:

[ERROR] Failed to execute goal on project user: Could not resolve
dependencies for project org.example.user:user:jar:0.0.1-SNAPSHOT:
Failed to collect dependencies for
org.example.user:user:jar:0.0.1-SNAPSHOT: Could not resolve version
conflict among [com.example.api:example-api:jar:[2.0.0,),
com.example.impl:example-impl:jar:2.3.0 ->
com.example.api:example-api:jar:[1.0,2.0)] -> [Help 1]






> What is the evidence that a major bump causes warnings?

See above.

Note that a quick grep in my big .m2/repository didn't reveal any
dependencies on commons* that used ranges - probably because of
Commons being good in not breaking stuff. :)





-- 
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/-0001-9842-9718

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

[VOTE] Release DBCP 2.1 RC2 as 2.1

[Phil Steitz]

Quite a few bugs have been fixed since DBCP 2.0.1 and a few new
features have been added.  It is time for a 2.1 release.

Changes since RC1:
* Changed awkward boolean property getter names added in 2.1
* Made POM and javadoc changes to enable Java 8 build.
* Made project URL more compact

Thanks to all who reviewed RC1 and helped make these changes.

The release is available for review here:
https://dist.apache.org/repos/dist/dev/commons/dbcp (R8063)

The release was built from this tag:
http://svn.apache.org/viewvc/commons/proper/dbcp/tags/DBCP_2_1_RC2
(r1661059)

Release notes:
https://dist.apache.org/repos/dist/dev/commons/dbcp/RELEASE-NOTES.txt

Maven artifacts:
https://repository.apache.org/content/repositories/orgapachecommons-1084

Site:
http://people.apache.org/~psteitz/dbcp/dbcp-2.1-RC2-site/

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

Votes, please.

This vote will close no sooner than 72 hours from now.

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

Thanks!

Phil



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

[Releases] Jitpack

[Ole Ersoy]

Just came across this on the Maven users list:

https://jitpack.io/

Seems like it would be a great tool for managing releases.

Cheers,
- Ole


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

Re: [Releases] Jitpack

[James Ring]

Neat! Thanks for sharing.

On Thu, Feb 19, 2015 at 7:32 PM, Ole Ersoy  wrote:
> Just came across this on the Maven users list:
>
> https://jitpack.io/
>
> Seems like it would be a great tool for managing releases.
>
> Cheers,
> - Ole
>
>
> -
> 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

AW: [Releases] Jitpack

[jhm]

Not sure how you would 'manage' releases.
But it provides a quick access to public available projects on Github, even if 
they are not build/released yet.

Jan

> -Ursprüngliche Nachricht-
> Von: Ole Ersoy [mailto:ole.er...@gmail.com]
> Gesendet: Freitag, 20. Februar 2015 06:32
> An: Commons Developers List
> Betreff: [Releases] Jitpack
> 
> Just came across this on the Maven users list:
> 
> https://jitpack.io/
> 
> Seems like it would be a great tool for managing releases.
> 
> Cheers,
> - Ole
> 
> 
> -
> 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: [Releases] Jitpack

[Benedikt Ritter]

2015-02-20 7:18 GMT+01:00 Jan Matèrne (jhm) :

> Not sure how you would 'manage' releases.
> But it provides a quick access to public available projects on Github,
> even if they are not build/released yet.
>

Depends on the definition of a release. If a release is just a specific
state of the source code (e.g. a VCS tag), then gives you easy integration
of such releases into your maven/gradle/whatever based build.

Benedikt


>
> Jan
>
> > -Ursprüngliche Nachricht-
> > Von: Ole Ersoy [mailto:ole.er...@gmail.com]
> > Gesendet: Freitag, 20. Februar 2015 06:32
> > An: Commons Developers List
> > Betreff: [Releases] Jitpack
> >
> > Just came across this on the Maven users list:
> >
> > https://jitpack.io/
> >
> > Seems like it would be a great tool for managing releases.
> >
> > Cheers,
> > - Ole
> >
> >
> > -
> > 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
>
>


-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter