Re: [VFS] CI in POM?

On Wed, Jun 8, 2016 at 3:59 PM, wrote: > Thanks, had found it meanwhile. Should we add Jenkins to the parent POM or > a more specific section into the project pom? > > Can anybody with Jenkins Karma reconfigure the Jobs to use minimum Java 7, > the Jobs fail since that

Re: [VFS] CI in POM?

Thanks, had found it meanwhile. Should we add Jenkins to the parent POM or a more specific section into the project pom? Can anybody with Jenkins Karma reconfigure the Jobs to use minimum Java 7, the Jobs fail since that change:

Re: [Math] Commons Math (r)evolution

Hi. On Wed, 8 Jun 2016 23:50:00 +0300, Artem Barger wrote: On Wed, Jun 8, 2016 at 12:25 AM, Gilles wrote: According to JIRA, among 180 issues currently targeted for the next major release (v4.0), 139 have been resolved (75 of which were not in v3.6.1).

Re: [VFS] CI in POM?

Continuum has been retired: https://attic.apache.org/projects/continuum.html We need use switch Jenkins: https://builds.apache.org/view/Apache%20Commons/job/commons-vfs-trunk/ Gary On Wed, Jun 8, 2016 at 3:35 PM, Bernd Eckenfels wrote: > Hello, > >

[VFS] CI in POM?

Hello, continuum-ci.apache.org seems to be gone, or at least it is not responding right now. In the VFS POM we have a CI section (from the parent) poiting to this CI. Should this be replaced by some other integration server, if yes, where is the Job currently setup? (And I havent found the

[Math] About a new component based around "Complex" (Was: Commons Math (r)evolution)

Hi. On Wed, 8 Jun 2016 09:30:24 +0200, Eric Barnhill wrote: On Wed, Jun 8, 2016 at 12:08 AM, Gilles wrote: Which parts of Commons Math would be dependencies for this type of applications? Which algorithms of your applications would be generic enough to warrant

Re: Apache Code of Conduct

On Sun, Jun 5, 2016 at 12:56 AM, Gary Gregory wrote: > On Sat, Jun 4, 2016 at 4:53 PM, Niall Pemberton > > wrote: > > > Hi, > > > > Apache has a "Code of Conduct" here: > > http://www.apache.org/foundation/policies/conduct.html > > > > I

Re: [Math] Commons Math (r)evolution

On Wed, Jun 8, 2016 at 12:25 AM, Gilles wrote: > > According to JIRA, among 180 issues currently targeted for the >>> next major release (v4.0), 139 have been resolved (75 of which >>> were not in v3.6.1). >>> >>> >> ​Huh, it's above of 75% completion :)​ >> > >

Re: [BCEL] 5.3 is going to be messy

> > > So? What's your point there? > > Commons libraries are generally very low level, and are often embedded > deep within software stacks. > > So changes which require downstream changes are expensive when > considered as a whole. > > This is very different from many other ASF projects which can

Re: [BCEL6] StackMapTable / StackMapTableEntry gone

On 8 June 2016 at 13:24, Mark Roberts wrote: > There were duplicate versions of these methods with slightly different names. > We picked the set that seemed to have a better implementation and deleted > the other two. This was done as part of the last two pushes to

RE: [BCEL6] StackMapTable / StackMapTableEntry gone

There were duplicate versions of these methods with slightly different names. We picked the set that seemed to have a better implementation and deleted the other two. This was done as part of the last two pushes to 6.0 (approx. Feb 2015 and Aug 2015). A lot of these changes were porting

Re: [BCEL6] StackMapTable / StackMapTableEntry gone

I think I've found a way to fix the compile problems without introducing back StackMapTable / StackMapTableEntry classes to BCEL6, see https://github.com/findbugsproject/findbugs/commit/2e1807e82c18ce646e0298b8d0597e5eeb49c0af FindBugs is now compilable on BCEL6 latest greatest head, but our

Re: [BCEL6] StackMapTable / StackMapTableEntry gone

Let's be clear here. We are proposing changing the code because someone used a SNAPSHOT version and released their code which uses it? That code was never released and I don't know that it's right to bind us to a work-in-progress. It's bad enough we have to be saddled forever with the burden of

Re: [crypto] Logging dependency

On Mon, Jun 6, 2016 at 10:01 PM Gary Gregory wrote: > Hi All: > > IMO. if [crypto] is to have a dependency on a logging framework, it should > be Log4j 2, not Commons Logging. Log4j 2 has an API module, which you can > pair with any number of implementations: Log4j's own

[GitHub] commons-bcel pull request #5: BCEL6 compatibility to 5.2 snapshots

Github user asfgit closed the pull request at: https://github.com/apache/commons-bcel/pull/5 --- 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

Re: [BCEL] Latest Clirr report

On 8 June 2016 at 10:46, Benedikt Ritter wrote: > Hello sebb, > > sebb schrieb am Mi., 8. Juni 2016 um 11:21 Uhr: > >> Was that the full report, or the 'quietened' one? >> There's a Clirr suppression file which removes some diffs that are >> considered

Re: [BCEL] Latest Clirr report

Hello sebb, sebb schrieb am Mi., 8. Juni 2016 um 11:21 Uhr: > Was that the full report, or the 'quietened' one? > There's a Clirr suppression file which removes some diffs that are > considered non-breaking (as per the changes description) > (otherwise the report is rather

Re: [BCEL6] StackMapTable / StackMapTableEntry gone

On 8 June 2016 at 10:34, Andrey Loskutov wrote: > On Wednesday 08 June 2016 10:17 sebb wrote: >> OK, so what options are there? >> >> A) add the classes back in, but deprecate the class(es) and defer to >> the new implementation if possible >> B) Update Findbugs to use the new

Re: [BCEL6] StackMapTable / StackMapTableEntry gone

On Wednesday 08 June 2016 10:17 sebb wrote: > OK, so what options are there? > > A) add the classes back in, but deprecate the class(es) and defer to > the new implementation if possible > B) Update Findbugs to use the new design > > Anything else? > > == > > If the choice is between A and B,

Re: [BCEL] 5.3 is going to be messy

On 8 June 2016 at 00:56, Torsten Curdt wrote: >> >> >> 1) I don't believe we should force users to migrate their code in >> >> order to support java 7/8. >> >> >> > >> > ...and that line of thinking is why it feels like commons projects are >> > effectively stuck in the past. >>

[GitHub] commons-bcel pull request #5: BCEL6 compatibility to 5.2 snapshots

GitHub user iloveeclipse opened a pull request: https://github.com/apache/commons-bcel/pull/5 BCEL6 compatibility to 5.2 snapshots First commit: added Git ignore file Second commit: follow up on the BCEL6 compatibility discussion. Attempt to fix the StackMapTable

Re: [BCEL] Latest Clirr report

Was that the full report, or the 'quietened' one? There's a Clirr suppression file which removes some diffs that are considered non-breaking (as per the changes description) (otherwise the report is rather difficult to read) To show all the errors, use -P!quieten-clirr or -Dclirr.allDifferences

Re: [BCEL6] StackMapTable / StackMapTableEntry gone

On 8 June 2016 at 10:01, Andrey Loskutov wrote: > On Wednesday 08 June 2016 08:37 Benedikt Ritter wrote: >> Hallo Andrey, >> >> Andrey Loskutov schrieb am Mi., 8. Juni 2016 um 09:36 Uhr: >> >> > Hi, >> > >> > I'm following the package rename and trying to fix

Re: BCEL 6 API breakage

On 8 June 2016 at 02:32, dbrosIus wrote: > I have almost certainly the largest FindBugs plug in. I expect it will take > less than 15 minutes to update it to use a breaking package/api version of > BCEL if it ever was to go out. > I've got this fancy thing called a

Re: [BCEL6] StackMapTable / StackMapTableEntry gone

On Wednesday 08 June 2016 08:37 Benedikt Ritter wrote: > Hallo Andrey, > > Andrey Loskutov schrieb am Mi., 8. Juni 2016 um 09:36 Uhr: > > > Hi, > > > > I'm following the package rename and trying to fix compile issues with > > BCEL6 in FindBugs. > > > > Before 6.0 we had both

Re: [BCEL6] StackMapTable / StackMapTableEntry gone

Hallo Andrey, Andrey Loskutov schrieb am Mi., 8. Juni 2016 um 09:36 Uhr: > Hi, > > I'm following the package rename and trying to fix compile issues with > BCEL6 in FindBugs. > > Before 6.0 we had both StackMap and StackMapTable classes (with > StackMapEntry /

[BCEL] Latest Clirr report

Hi all, I've published the BCEL website after reverting the package rename. Here [1] is the Clirr report of the current code base. Benedikt [1] http://commons.apache.org/proper/commons-bcel/clirr-report.html

[BCEL6] StackMapTable / StackMapTableEntry gone

Hi, I'm following the package rename and trying to fix compile issues with BCEL6 in FindBugs. Before 6.0 we had both StackMap and StackMapTable classes (with StackMapEntry / StackMapTableEntry elements). This was added via https://issues.apache.org/jira/browse/BCEL-92 to support Java 6. Now

Re: [Math] Commons Math (r)evolution

On Wed, Jun 8, 2016 at 12:08 AM, Gilles wrote: > Which parts of Commons Math would be dependencies for this type > of applications? > Which algorithms of your applications would be generic enough to > warrant becoming part of a toolbox based on the "Complex" class?