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 sour
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: Common
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
>
>
> ---
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,
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
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
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 th
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/rmann
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-R
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
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 cha
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 mig
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
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
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.
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 i
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
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.
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
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 th
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.
>
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
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
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 fo
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,
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 (r01de14724cdef164cd33c7c8
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 1
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 cou
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
The
+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,
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/re
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 reg
32 matches
Mail list logo
