+1 to go forward with nio-vfs binding.
I have some experience writing a NIO2 FileSystemProvider myself (which
wraps the nio zip support), so I would be willing to join the effort.
As each filesystem provider in nio2 only does one URI scheme we would
probably need nested URIs or multiple providers
On 2 June 2016 at 07:56, Benedikt Ritter wrote:
> Gary Gregory schrieb am Do., 2. Juni 2016 um
> 08:00 Uhr:
>
>> So trunk packages would be renamed _back_ from bcel6 to the 5.2 packages?
>>
>
> That's what I understood from sebb's last message.
Yes, that would need to happen to support BC.
>
>>
This is the problem with Commons.
Original message
From: sebb
Date: 06/02/2016 5:15 AM (GMT-05:00)
To: Commons Developers List
Subject: Re: [bcel] Deprecated InstructionConstants
On 2 June 2016 at 07:56, Benedikt Ritter wrote:
> Gary Gregory schrieb am Do., 2. Juni 2
No, it's a consequence of the way the Java classpath and Maven work.
If Commons wishes to release a compatible version of BCEL, it must use
the same Java package and Maven coordinates.
(as well as ensure that any changes to the public API are at least
binary-compatible)
If Commons is happy to ign
Commons should be happy to ignore compatibility, update to 1.8, change
package and maven coordinates, change interfaces to take advantage of
generics, become a modern code base. Staying in the 1.5 world, BCEL,
which is already dying, will die. No competent developer coming in from
the outside w
On 02/06/2016 08:45, Stian Soiland-Reyes wrote:
As each filesystem provider in nio2 only does one URI scheme we would
probably need nested URIs or multiple providers.
I would like to see how that one will get solved. It is definitely one
of the joys of VFS.
--
Schalk W. Cronjé
Twitter / E
On 2 June 2016 at 11:20, Dave Brosius wrote:
> Commons should be happy to ignore compatibility, update to 1.8, change
> package and maven coordinates, change interfaces to take advantage of
> generics, become a modern code base. Staying in the 1.5 world, BCEL, which
> is already dying, will die. N
Hi,
sebb wrote:
> Hang on please.
>
> There were plans to produce a new incompatible release with new Maven
> coords and new package names.
> However as I recall there was some pushback from users who wished to
> have a drop-in release.
> That is not possible unless the release is binary compati
On 2 June 2016 at 12:35, Jörg Schaible wrote:
> Hi,
>
> sebb wrote:
>
>> Hang on please.
>>
>> There were plans to produce a new incompatible release with new Maven
>> coords and new package names.
>> However as I recall there was some pushback from users who wished to
>> have a drop-in release.
>
Thanks! It's already on https://www.apache.org/licenses/exports/
I've added to the Commons Crypto README:
https://github.com/apache/commons-crypto#export-restrictions
(if changing, modify this text in pom.xml and regenerate
README.md)
Shall I add VFS2 as well? Then Gary can send a joint notif
My intention since I first saw the NIO stuff before it came out was to replace
Commons VFS file system stuff with Java’s but to try to minimize the changes to
the existing providers as much as possible. That said, this is surely going to
break backward compatibility but that has never been a con
If you know how so get this right for VFS, go for it!
Stian Soiland-Reyes schrieb am Do., 2. Juni 2016 um
16:35:
> Thanks! It's already on https://www.apache.org/licenses/exports/
>
> I've added to the Commons Crypto README:
>
> https://github.com/apache/commons-crypto#export-restrictions
>
> (i
Am 01.06.2016 um 22:09 schrieb Gary Gregory:
> On Wed, Jun 1, 2016 at 12:46 PM, Oliver Heger
> wrote:
>
>>
>>
>> Am 31.05.2016 um 23:31 schrieb Gary Gregory:
>>> While there is not much new for 1.9.3, just two fixes, I would not mind
>>> pushing out a release, just to get the refreshed dependen
Okay, so were are we now?
- people are waiting for a new release
- package coords have changed - BC is broken
- sebb has put effort into making all changes compatible
- two interface changes remain
Is that correct? Then let's just get over with this two interfaces mach
make the API redesign after
On Thu, Jun 2, 2016 at 1:03 PM, Oliver Heger
wrote:
>
>
> Am 01.06.2016 um 22:09 schrieb Gary Gregory:
> > On Wed, Jun 1, 2016 at 12:46 PM, Oliver Heger <
> oliver.he...@oliver-heger.de>
> > wrote:
> >
> >>
> >>
> >> Am 31.05.2016 um 23:31 schrieb Gary Gregory:
> >>> While there is not much new f
On Thu, Jun 2, 2016 at 1:22 PM, Benedikt Ritter wrote:
> Okay, so were are we now?
>
> - people are waiting for a new release
> - package coords have changed - BC is broken
> - sebb has put effort into making all changes compatible
> - two interface changes remain
>
> Is that correct? Then let's
It is still not functionally compatible. People parsing UNKNOWN annotations
looking for generics (as was the right way before) will now fail. Better rip
the generic support out too.
Original message
From: Benedikt Ritter
Date: 06/02/2016 4:22 PM (GMT-05:00)
To: Common
dbrosIus schrieb am Do., 2. Juni 2016 um
22:32 Uhr:
> It is still not functionally compatible. People parsing UNKNOWN
> annotations looking for generics (as was the right way before) will now
> fail. Better rip the generic support out too.
>
Okay, if this is the case I haven't understood the
On Thu, Jun 2, 2016 at 1:34 PM, Benedikt Ritter
wrote:
> dbrosIus schrieb am Do., 2. Juni 2016 um
> 22:32 Uhr:
>
> > It is still not functionally compatible. People parsing UNKNOWN
> > annotations looking for generics (as was the right way before) will now
> > fail. Better rip the generic su
On Thu, Jun 2, 2016 at 1:40 PM, Gary Gregory wrote:
> On Thu, Jun 2, 2016 at 1:34 PM, Benedikt Ritter
> wrote:
>
>> dbrosIus schrieb am Do., 2. Juni 2016 um
>> 22:32 Uhr:
>>
>> > It is still not functionally compatible. People parsing UNKNOWN
>> > annotations looking for generics (as was the r
Hi,
we do seem to have different opinions when it comes to binary compatibility
and how it should be handled. Usually we would say "this should be decided
on a component basis". However this discussion is coming up again and again
and I think we should try the impossible and agree on something tha
Gary Gregory schrieb am Do., 2. Juni 2016 um
22:40 Uhr:
> On Thu, Jun 2, 2016 at 1:40 PM, Gary Gregory
> wrote:
>
> > On Thu, Jun 2, 2016 at 1:34 PM, Benedikt Ritter
> > wrote:
> >
> >> dbrosIus schrieb am Do., 2. Juni 2016 um
> >> 22:32 Uhr:
> >>
> >> > It is still not functionally compatible
Hello Pascal,
you have been working through the issues of [LANG] recently. Would you like
to do RM for 3.5? I can help you with that. I've done it several times in
the past.
Benedikt
Hello,
Unhappy with it but agreeing that your definition sounds like it should apply.
I would vote for always bumping at least the minor version when requiring newer
dependencies (including Java Version). Strictly speaking semver would require a
major version but with our policy of using new pa
On Thu, Jun 2, 2016 at 1:44 PM, Benedikt Ritter wrote:
> Gary Gregory schrieb am Do., 2. Juni 2016 um
> 22:40 Uhr:
>
> > On Thu, Jun 2, 2016 at 1:40 PM, Gary Gregory
> > wrote:
> >
> > > On Thu, Jun 2, 2016 at 1:34 PM, Benedikt Ritter
> > > wrote:
> > >
> > >> dbrosIus schrieb am Do., 2. Juni
On Thu, Jun 2, 2016 at 1:48 PM, Benedikt Ritter wrote:
> Hello Pascal,
>
> you have been working through the issues of [LANG] recently. Would you like
> to do RM for 3.5? I can help you with that. I've done it several times in
> the past.
>
+1 for RERO. No need to rush more stuff in a release.
On Thu, Jun 2, 2016 at 2:01 PM, Gary Gregory wrote:
> On Thu, Jun 2, 2016 at 1:48 PM, Benedikt Ritter
> wrote:
>
>> Hello Pascal,
>>
>> you have been working through the issues of [LANG] recently. Would you
>> like
>> to do RM for 3.5? I can help you with that. I've done it several times in
>> t
On Thu, Jun 2, 2016 at 1:42 PM, Benedikt Ritter wrote:
> Hi,
>
> we do seem to have different opinions when it comes to binary compatibility
> and how it should be handled. Usually we would say "this should be decided
> on a component basis". However this discussion is coming up again and again
>
Hello Benedikt
guess a 3.5 is overdue as 3.4 was released over a year ago. There are 88
fixed jira issues:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20LANG%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%203.5%20ORDER%20BY%20priority%20DESC
With your h
should be "If somebody else would like to RM, I'm also very happy with
that."
Sorry,
Pascal
Am 02.06.2016 um 23:14 schrieb Pascal Schumacher:
Hello Benedikt
guess a 3.5 is overdue as 3.4 was released over a year ago. There are
88 fixed jira issues:
https://issues.apache.org/jira/issues/?jq
Gary Gregory wrote:
> On Thu, Jun 2, 2016 at 1:34 PM, Benedikt Ritter
> wrote:
>
>> dbrosIus schrieb am Do., 2. Juni 2016 um
>> 22:32 Uhr:
>>
>> > It is still not functionally compatible. People parsing UNKNOWN
>> > annotations looking for generics (as was the right way before) will
>> > now
Hi Benedikt,
Benedikt Ritter wrote:
> Hi,
>
> we do seem to have different opinions when it comes to binary
> compatibility and how it should be handled. Usually we would say "this
> should be decided on a component basis". However this discussion is coming
> up again and again and I think we sh
Le 2/06/2016 à 22:42, Benedikt Ritter a écrit :
> - since our components are depended upon by a lot of projects, we need to
> take special care regarding compatibility.
+1, thanks God Apache Commons isn't like Guava or BouncyCastle.
> - we must not break BC in a release that could collide with
Emmanuel Bourg schrieb am Do., 2. Juni 2016 um
23:26 Uhr:
> Le 2/06/2016 à 22:42, Benedikt Ritter a écrit :
>
> > - since our components are depended upon by a lot of projects, we need to
> > take special care regarding compatibility.
>
> +1, thanks God Apache Commons isn't like Guava or BouncyCa
I don't understand what's wrong with semantic versioning and keeping
the same maven coordinates. No sane person should be using RELEASE or
LATEST.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional command
Hi all,
A part of the release process is to update the web site. I wonder if
this could be simplified with a Jenkins job watching for the release
tags and building/uploading the new site automatically. That would make
one less thing to think about when releasing new versions. I suspect the
most di
Emmanuel Bourg schrieb am Do., 2. Juni 2016 um
23:39 Uhr:
> Hi all,
>
> A part of the release process is to update the web site. I wonder if
> this could be simplified with a Jenkins job watching for the release
> tags and building/uploading the new site automatically. That would make
> one less
Hello Benson,
Benson Margulies schrieb am Do., 2. Juni 2016 um
23:36 Uhr:
> I don't understand what's wrong with semantic versioning and keeping
> the same maven coordinates. No sane person should be using RELEASE or
> LATEST.
>
The problem are transitive dependencies. Consider this example:
M
Dependency management cures this; if you don't want to pick up newer
versions, you can prevent it. Since dep management doesn't know about
ranges or semantic versioning, you need to then pay attention if you
want a compatible version that comes along.
I guess it's a question of which poison you pr
You've been in karaf land for too long! ;)
On Thu, Jun 2, 2016 at 5:36 PM Benson Margulies
wrote:
> I don't understand what's wrong with semantic versioning and keeping
> the same maven coordinates. No sane person should be using RELEASE or
> LATEST.
>
> -
On Thu, Jun 2, 2016 at 6:04 PM, James Carman wrote:
> You've been in karaf land for too long! ;)
I took my team into OSGi to get away from these messes. Of course, we
got some other messes in their places.
>
> On Thu, Jun 2, 2016 at 5:36 PM Benson Margulies
> wrote:
>
>> I don't understand what
On Thu, Jun 2, 2016 at 2:15 PM, Jörg Schaible wrote:
> Gary Gregory wrote:
>
> > On Thu, Jun 2, 2016 at 1:34 PM, Benedikt Ritter
> > wrote:
> >
> >> dbrosIus schrieb am Do., 2. Juni 2016 um
> >> 22:32 Uhr:
> >>
> >> > It is still not functionally compatible. People parsing UNKNOWN
> >> > annot
Yep, those pesky duplicate chains.
On Thu, Jun 2, 2016 at 6:05 PM Benson Margulies
wrote:
> On Thu, Jun 2, 2016 at 6:04 PM, James Carman
> wrote:
> > You've been in karaf land for too long! ;)
>
> I took my team into OSGi to get away from these messes. Of course, we
> got some other messes in th
Gary Gregory schrieb am Fr., 3. Juni 2016 um
00:06 Uhr:
> On Thu, Jun 2, 2016 at 2:15 PM, Jörg Schaible
> wrote:
>
> > Gary Gregory wrote:
> >
> > > On Thu, Jun 2, 2016 at 1:34 PM, Benedikt Ritter
> > > wrote:
> > >
> > >> dbrosIus schrieb am Do., 2. Juni 2016 um
> > >> 22:32 Uhr:
> > >>
> > >
On Thu, Jun 2, 2016 at 2:26 PM, Emmanuel Bourg wrote:
> Le 2/06/2016 à 22:42, Benedikt Ritter a écrit :
>
> > - since our components are depended upon by a lot of projects, we need to
> > take special care regarding compatibility.
>
> +1, thanks God Apache Commons isn't like Guava or BouncyCastle
On Thu, Jun 2, 2016 at 3:01 PM, Benedikt Ritter wrote:
> Hello Benson,
>
> Benson Margulies schrieb am Do., 2. Juni 2016 um
> 23:36 Uhr:
>
> > I don't understand what's wrong with semantic versioning and keeping
> > the same maven coordinates. No sane person should be using RELEASE or
> > LATEST
Dependency management does not cure this if C 1.2 and C 2.0 are not binary
compatible. Code compiled with the 1.2 version will fail if those methods and
classes are not in 2.0.
Ralph
> On Jun 2, 2016, at 3:03 PM, Benson Margulies wrote:
>
> Dependency management cures this; if you don't want
James Carman schrieb am Fr., 3. Juni 2016 um
00:04 Uhr:
> You've been in karaf land for too long! ;)
>
It's probably a different story when you're working on a framework. It
pretty unlikely to end up with two version of Spring or Hibernate in your
app. But for a library as wildly used as commons
On Thu, Jun 2, 2016 at 2:57 PM, Benedikt Ritter wrote:
> Emmanuel Bourg schrieb am Do., 2. Juni 2016 um
> 23:39 Uhr:
>
> > Hi all,
> >
> > A part of the release process is to update the web site. I wonder if
> > this could be simplified with a Jenkins job watching for the release
> > tags and bu
One big pain is releasing IMO is having to manage BOTH Nexus (with the
extra checksum mess) AND SVN dist/dev + dist/release.
It would be nice if Nexus had a menu option as part of Closing a repo to
"remove extra checksum"...
Gary
On Thu, Jun 2, 2016 at 2:39 PM, Emmanuel Bourg wrote:
> Hi all,
I don't think it has anything to do necessarily with framework or not. The
class loading model is just much easier to deal with these situations. As
Benson said, however, there are definitely other issues to contend with.
On Thu, Jun 2, 2016 at 6:14 PM Benedikt Ritter wrote:
> James Carman schri
On Thu, Jun 2, 2016 at 3:11 PM, Ralph Goers
wrote:
> Dependency management does not cure this if C 1.2 and C 2.0 are not binary
> compatible. Code compiled with the 1.2 version will fail if those methods
> and classes are not in 2.0.
>
Indeed, hence the BC break -> Maven Coord change requirement
FYI, a heads up to avoid wasting an RC with JRE version discussions: Update
Java requirement from Java 5 to 6.
--
The Apache Commons BeanUtils team is pleased to announce the
commons-beanutils-1.9.3-SNAPSHOT release!
Apache Commons BeanUtils provides an easy-to-use but flexible wrapper
around re
Just to cite a fact:
If you write:
...
x
...
You will get x. Even if transitive dependencies ask for x+10. I only
learned this recently.
On Thu, Jun 2, 2016 at 6:20 PM, Gary Gregory wrote:
> On Thu, Jun 2, 2016 at 3:11 PM, Ralph Goers
> wrote:
>
>> Dependency
Le 3/06/2016 à 00:09, Gary Gregory a écrit :
> -1
>
> Timing is irrelevant. You cannot control what will end up in an app stack.
> Once released, that's it unfortunately, otherwise, the door to jar hell is
> open.
Timing is relevant because the probability of jar hell increases with
time. If the
Hello,
Does anyone have a few spare cycles to do a release from the Commons
Jexl 2.0 branch (v 2.1.2)? 2.1.1 release is from Dec 2011, and there
have been quite a few fixes on that branch since.
Also, I tried to look in JIRA for issues tagged to version 2.1.2; and
even though the version page exi
Benson Margulies schrieb am Fr., 3. Juni 2016 um
00:43 Uhr:
> Just to cite a fact:
>
> If you write:
>
>
>
>
> ...
> x
> ...
>
> You will get x. Even if transitive dependencies ask for x+10. I only
> learned this recently.
>
Yes thats true. Coming back to our exam
I think you best bet is to migrate to JEXL 3.0.
Gary
On Thu, Jun 2, 2016 at 3:57 PM, Bhowmik, Bindul
wrote:
> Hello,
>
> Does anyone have a few spare cycles to do a release from the Commons
> Jexl 2.0 branch (v 2.1.2)? 2.1.1 release is from Dec 2011, and there
> have been quite a few fixes on t
On Thu, Jun 2, 2016 at 3:42 PM, Benedikt Ritter wrote:
> Hi,
>
> we do seem to have different opinions when it comes to binary compatibility
> and how it should be handled. Usually we would say "this should be decided
> on a component basis". However this discussion is coming up again and again
>
The other tags are all upper case with underscore.
schrieb am Fr., 3. Juni 2016 um 01:07:
> Author: ggregory
> Date: Thu Jun 2 23:07:29 2016
> New Revision: 1746655
>
> URL: http://svn.apache.org/viewvc?rev=1746655&view=rev
> Log:
> Creating beanutils-1.9.3-RC1 tag
>
> Added:
> commons/prope
bleharch! Or ack! (Like the cat in Bloom County).
I am reducing my headache factor by following
https://commons.apache.org/releases/prepare.html
Gary
On Thu, Jun 2, 2016 at 4:10 PM, Benedikt Ritter
wrote:
> The other tags are all upper case with underscore.
> schrieb am Fr., 3. Juni 2016 um 0
Github user zhanhb closed the pull request at:
https://github.com/apache/commons-io/pull/12
---
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 e
Apache Commons BeanUtils 1.9.3 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/beanutils/
(revision 13874)
commons-beanutils-1.9.3-bin.tar.gz
(SHA1: 5c66783bb2bce21992cc3515a7b78f36f17c8709)
commons-beanutils-1.9.3-bin.zip
(SHA1: 3508ced3e244bc1583f6f4be119f50fe4f
Thanks Stian, Dapeng and folks!
For Commons Crypto, do we still have to wait for other process to finish or we
now can go forward with the first release process?
Regards,
Haifeng
-Original Message-
From: Stian Soiland-Reyes [mailto:st...@apache.org]
Sent: Thursday, June 2, 2016 10:36 P
> > A part of the release process is to update the web site. I wonder if
> > this could be simplified with a Jenkins job watching for the release
> > tags and building/uploading the new site automatically. That would
> > make one less thing to think about when releasing new versions. I
> > suspect
65 matches
Mail list logo
