Re: Build failed in Jenkins: commons-fileupload #9

[Gary Gregory]

On Sun, Jun 12, 2016 at 11:43 PM, Benedikt Ritter 
wrote:

> Hi,
>
> I've created INFRA-12098 [1] for this.
>

Thank you Benedikt; I voted for the issue.

Gary


>
> Benedikt
>
> [1]
> https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-12098
>
> Benedikt Ritter  schrieb am So., 12. Juni 2016 um
> 21:12 Uhr:
>
> > The validator build has the same problem.
> >
> > Jochen Wiedmann  schrieb am So., 12. Juni
> 2016
> > um 19:40:
> >
> >> On Sun, Jun 12, 2016 at 4:33 PM, Benedikt Ritter 
> >> wrote:
> >> > No idea what caused this failure...
> >>
> >> Neither do I. According to the error message, there's a problem with
> >> the POM file, but I've been checking that file in the Jenikins
> >> workspace, and it looks perfect to me.
> >>
> >> Jochen
> >>
> >>
> >> --
> >> The next time you hear: "Don't reinvent the wheel!"
> >>
> >>
> >>
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
>



-- 
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: svn commit: r1748095 - /commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java

[Gary Gregory]

On Sun, Jun 12, 2016 at 11:59 PM, Benedikt Ritter 
wrote:

> Can we drop the dependency to lang3 now?
>

Nope, it's still used by the benchmarks. It's a test-only dependency, no
big deal IMO.

Gary


> Benedikt
>
>  schrieb am Mo., 13. Juni 2016 um 08:57:
>
> > Author: ggregory
> > Date: Mon Jun 13 06:57:56 2016
> > New Revision: 1748095
> >
> > URL: http://svn.apache.org/viewvc?rev=1748095&view=rev
> > Log:
> > Use Java 7 method instead of Apache Commons Lang 3.
> >
> > Modified:
> >
> >
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
> >
> > Modified:
> >
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
> > URL:
> >
> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java?rev=1748095&r1=1748094&r2=1748095&view=diff
> >
> >
> ==
> > ---
> >
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
> > (original)
> > +++
> >
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
> > Mon Jun 13 06:57:56 2016
> > @@ -35,9 +35,9 @@ import java.util.Date;
> >  import java.util.Iterator;
> >  import java.util.LinkedList;
> >  import java.util.List;
> > +import java.util.Objects;
> >  import java.util.Random;
> >
> > -import org.apache.commons.lang3.ObjectUtils;
> >  import org.junit.Assert;
> >  import org.junit.Ignore;
> >  import org.junit.Test;
> > @@ -111,7 +111,7 @@ public class CSVPrinterTest {
> >  private  T[] expectNulls(final T[] original, final CSVFormat
> > csvFormat) {
> >  final T[] fixed = original.clone();
> >  for (int i = 0; i < fixed.length; i++) {
> > -if (ObjectUtils.equals(csvFormat.getNullString(),
> fixed[i])) {
> > +if (Objects.equals(csvFormat.getNullString(), fixed[i])) {
> >  fixed[i] = null;
> >  }
> >  }
> >
> >
> >
>



-- 
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] Move Commons Math to TLP (again)...

[sebb]

On 13 June 2016 at 03:06, Rob Tompkins  wrote:
> With all of that said, then I'm a: +1 (binding).

AIUI this is a Common vote, as such only PMC member votes are
considered binding.
However you don't appear to be listed as a PMC member?

> -Rob
>
>> On Jun 12, 2016, at 9:27 PM, Niall Pemberton  
>> wrote:
>>
>> On Mon, Jun 13, 2016 at 2:10 AM, Benson Margulies 
>> wrote:
>>
>>> Procedurally speaking, I see no reason for this community to hold any
>>> vote at all.
>>>
>>> If a small group of people, including a foundation member or two,
>>> wants to ask the board to establish a TLP, they may, by writing a
>>> coherent proposal to the board explaining the situation. The board
>>> might ask for a filled-in incubator proposal as input to their
>>> deliberations.
>>>
>>> Or, of they wish to go into the incubator to try to build a viable
>>> community that will get TLP status in time, they can write an
>>> incubator proposal.
>>>
>>> The board or IPMC might wonder about the state of affairs here when
>>> they receive one of these proposals, but it's hardly a matter that
>>> calls for a formal vote here.
>>
>> Yes, I agree, but the discussion to gather those people together needs to
>> take place somewhere and since here its been framed as a vote, then it
>> would be good if those people who want to participate in a TLP effort would
>> do so in this thread.
>>
>> Niall
>>
>>
>> On Sun, Jun 12, 2016 at 8:30 PM, Niall Pemberton
>>  wrote:
>>> On Sun, Jun 12, 2016 at 11:08 PM, Gilles 
>>> wrote:
>>>
> On Sun, 12 Jun 2016 14:33:58 -0700, Dennis E. Hamilton wrote:
>
> -1 (non-binding)
>
> Reason for objection:
>
> I think the framing of this vote is confusing.
>
> 1. There appears to be less ability to go to TLP than there was at
> the time the previous motion passed.
>
> 2. The discussion (but not the [VOTE]) speaks of going to TLP via
> the incubator.  It has to be one or the other.  Propose a podling to
> Incubator or propose a TLP to the Board.  There is no assurance that a
> podling will graduate and it doesn't fit to make that a condition.
> One could raise the special circumstances at general-incubator, but I
> think that works best with something specific (but malleable) in hand.
>
> 3. The Incubator is reluctant to start podlings from scratch, as
> Niall observes.

 Could you please expand on how 3 Commons PMC members and 3 would-be
 contributors are assimilated to "scratch"?
>>>
>>> It would be good if all those wanting to be part of a Math TLP could
>>> indicate that here and cast a vote for a Math TLP. Including yourself
>>> Gilles, since so far I don't remember seeing whether you that you were in
>>> favour of this.
>>>
>>> Niall
>>>
>>>
>>>

 Thanks,
 Gilles


 4. It seems to me that the best first-step on whether incubation is
> feasible is to do the work to create an incubation proposal.  This
> will require certain key factors to be addressed.  Not the least is
> how the code base will be imported and, because it is from an Apache
> Project, how it will be left behind too.  That definition can start
> here and then be refined on the general-incubator list where one will
> need to find a champion (perhaps), mentors, and a sufficient body of
> initial committers.  It is important for those who would form the
> initial core for a podling to learn enough about how incubation works.
>
> - Dennis
>
> Disclosure:
>
> I have no idea how this might go.  I am not a Commons Math
> subject-matter expert, even though computational mathematics has some
> appeal for me.  I still have my bound "Collect Algorithms from ACM,
> Volume 1: Algorithms 1-220."  I did not hold onto the microfiche of
> later algorithms that were published in conjunction with the ACM
> Transactions on Mathematical Software (TOMS). The latest (Algorithm
> 959) is interesting although I have no idea where to find the code and
> am dismayed that it is a library under the GPL.
>
> -Original Message-
>> From: Niall Pemberton [mailto:niall.pember...@gmail.com]
>> Sent: Sunday, June 12, 2016 11:56
>> To: Commons Developers List 
>> Subject: Re: [VOTE] Move Commons Math to TLP (again)...
>>
>> On Sat, Jun 11, 2016 at 10:39 AM, James Carman
>> 
>> wrote:
>>
>>> We would take math through the incubator in order to build community
>> around
>>> it first. If we fail to do so, then we can decide its fate at that
>> time. We
>>> haven't done a good job attracting new people to math here at all. It
>> has
>>> always been maintained primarily by a select few.
>>
>> It made sense to me when there were 6 committers working on Math, but I
>> think given the exodus of most of those people to hipparchus then it
>> would
>> be better to wait a while for the dust to settle

[compress] change behavior of bzip-output finalize?

[Stefan Bodewig]

Hi all

I'm trying to bring a discussion from COMPRESS-357 over to the list.

The bzip2 output stream has a finish method that is used to ensure all
data has been written to the stream and a separate close method that
invokes finish. And it overrides finalize to invoke finish in case
people have forgotten to close the stream - this behavior has been
present in the very first release of [compress].

The discussion in COMPRESS-357 shows that we'd need to synchronize - or
make volatile - quite a bit of code inside of
BZip2CompressorOutputStream for finalize to work properly. The
alternative is to simply no longer invoke finish from finalize (but log
an error if an unclosed stream is detected). This is a change that
breaks backwards compatibility but most likely only for people who are
doing something wrong. It may be OK to change it if the change is
advertized properly as it shouldn't affect too many people anyway.

There is one other instance of finalize doing the same - ZipFile. Here I
remember why it is the case, Ant uses its version of ZipFile inside of
its classloader and keeps the ZipFile instances open until the
classloader is disposed of - it might be possible to invoke close on the
ZipFile instances in the classloader's finalize but back then it looked
easier that way.

In the case of ZipFile I'd argue the only field that needs to be
published safely apart fromt the volatile closed flag is "archive" which
is final, so we should be safe.

Cheers

Stefan

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

Jenkins build is still unstable: commons-net » Apache Commons Net #3

[Apache Jenkins Server]

See 


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

Jenkins build is still unstable: commons-net #3

[Apache Jenkins Server]

See 


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

Jenkins build is still unstable: commons-net #4

[Apache Jenkins Server]

See 


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

Jenkins build is still unstable: commons-net » Apache Commons Net #4

[Apache Jenkins Server]

See 


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

Re: [compress] change behavior of bzip-output finalize?

[sebb]

On 13 June 2016 at 10:19, Stefan Bodewig  wrote:
> Hi all
>
> I'm trying to bring a discussion from COMPRESS-357 over to the list.
>
> The bzip2 output stream has a finish method that is used to ensure all
> data has been written to the stream and a separate close method that
> invokes finish. And it overrides finalize to invoke finish in case
> people have forgotten to close the stream - this behavior has been
> present in the very first release of [compress].
>
> The discussion in COMPRESS-357 shows that we'd need to synchronize - or
> make volatile - quite a bit of code inside of
> BZip2CompressorOutputStream for finalize to work properly. The
> alternative is to simply no longer invoke finish from finalize (but log
> an error if an unclosed stream is detected). This is a change that
> breaks backwards compatibility but most likely only for people who are
> doing something wrong. It may be OK to change it if the change is
> advertized properly as it shouldn't affect too many people anyway.
>
> There is one other instance of finalize doing the same - ZipFile. Here I
> remember why it is the case, Ant uses its version of ZipFile inside of
> its classloader and keeps the ZipFile instances open until the
> classloader is disposed of - it might be possible to invoke close on the
> ZipFile instances in the classloader's finalize but back then it looked
> easier that way.
>
> In the case of ZipFile I'd argue the only field that needs to be
> published safely apart fromt the volatile closed flag is "archive" which
> is final, so we should be safe.

AIUI finalize() is not guaranteed to be called, so any code that
relies on it is liable to be disappointed from time to time.

IMO at best one can use finalize() - *if* indeed it gets called - to
warn users that they have not closed a resource.

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

Jenkins build is still unstable: commons-net » Apache Commons Net #5

[Apache Jenkins Server]

See 


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

Jenkins build is still unstable: commons-net #5

[Apache Jenkins Server]

See 


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

Re: [compress] change behavior of bzip-output finalize?

[Torsten Curdt]

>
> AIUI finalize() is not guaranteed to be called, so any code that
> relies on it is liable to be disappointed from time to time.
>
> IMO at best one can use finalize() - *if* indeed it gets called - to
> warn users that they have not closed a resource.
>

+1

Jenkins build is back to stable : commons-net #6

[Apache Jenkins Server]

See 


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

Jenkins build is back to stable : commons-net » Apache Commons Net #6

[Apache Jenkins Server]

See 


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

[ALL] beware of URLs that represent file system locations

[sebb]

A Commons NET test was failing on Jenkins, but worked fine locally.
And previously had been working on Continuum.

Turns out this was because Jenkins uses path names of the form
.../commons-net@n/.

The test code was using the following to get the source location:

java.security.CodeSource.getLocation().getFile()

The embedded '@' was returned encoded as %40.

When used as a File parameter of course it did not work, so the test failed.

Using java.net.URLDecoder.decode() on the file-part of the URL fixed this.

There are no doubt other methods that return URLs that represent local
file paths.
Beware!

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

Re: [ALL] beware of URLs that represent file system locations

[Benedikt Ritter]

Thank you for bringing this up and for fixing the Problem!

sebb  schrieb am Mo., 13. Juni 2016 um 12:32:

> A Commons NET test was failing on Jenkins, but worked fine locally.
> And previously had been working on Continuum.
>
> Turns out this was because Jenkins uses path names of the form
> .../commons-net@n/.
>
> The test code was using the following to get the source location:
>
> java.security.CodeSource.getLocation().getFile()
>
> The embedded '@' was returned encoded as %40.
>
> When used as a File parameter of course it did not work, so the test
> failed.
>
> Using java.net.URLDecoder.decode() on the file-part of the URL fixed this.
>
> There are no doubt other methods that return URLs that represent local
> file paths.
> Beware!
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[GitHub] commons-bcel pull request #6: Fix for BCEL-273

[iloveeclipse]

Github user iloveeclipse closed the pull request at:

https://github.com/apache/commons-bcel/pull/6


---
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: Re: [BCEL] Latest Clirr report

[Andrey Loskutov]

Hi,

from FindBugs point of view, the biggest issue was the removal of 
"intermediate" org.apache.bcel.classfile.StackMapTable / 
org.apache.bcel.classfile.StackMapTableEntry classes. The removal of 
Serializable is not important for us at all, so I don't care.

We had a discussion here on the list regarding StackMapTable* and as far as I 
understood, there is no plan to restore those two types.

Therefore I've adopted FB code now (not on master, but soon) and included 
replacements for the missing classes to the binary distribution, so that the 
downstream plugins provider will at least do not crash due the missing classes. 
However, the behavior is changed and without source code adaptation code relied 
on those two classes will not work.

I'va also tried (smoke tests) the biggest known (to me) plugin "fb-contrib" 
from Dave and found only one BC issue left - 
https://github.com/mebigfatguy/fb-contrib/issues/116.

This was also caused by some refactorings in not released code 
(ParameterAnnotationEntry).

So from my limited FindBugs point of view we can release BCEL6 as it is today 
on trunk.

BTW, if you will, you can compare current BCEL 6 jar from trunk with the latest 
"FB BCEL patch" jar here: 
https://github.com/findbugsproject/findbugs/blob/master/findbugs/lib/bcel-6.0-SNAPSHOT.jar.
 I think Clirr should be able to do a diff here. Don't ask me from which 
revision this patched jar was created, I have no clue.

This is the BCEL API state we "exported" to downstream since 3 years :-(

Kind regards,
Andrey Loskutov

http://google.com/+AndreyLoskutov


> Gesendet: Sonntag, 12. Juni 2016 um 14:12 Uhr
> Von: sebb 
> An: "Commons Developers List" 
> Betreff: Re: [BCEL] Latest Clirr report
>
> On 12 June 2016 at 12:43, Benedikt Ritter  wrote:
> > sebb  schrieb am So., 12. Juni 2016 um 13:38 Uhr:
> >
> >> On 12 June 2016 at 12:00, Benedikt Ritter  wrote:
> >> > Hi,
> >> >
> >> > I've uploaded the verbose Clirr report to my space at home.apache.org
> >> [1].
> >> > Do we have to fix all of this in order to release 6.0?
> >>
> >> No, most of the changes don't break strict BC.
> >>
> >> The main changes to the interfaces don't break BC and are highly
> >> unlikely to affect source because there are abstract implementation
> >> classes.
> >>
> >> See the changes.xml file and release notes for some details.
> >>
> >
> > Thank you, I will have a look. Can we compile a list of things we need to
> > fix for 6.0?
> 
> Unfortunately the lack of updates has caused downstream users to rely
> on non-released code.
> I think we should try and ensure that we don't make things worse.
> 
> Therefore I don't think we can compile a full list without assistance
> from FindBugs and other consumers of the code.
> 
> I suspect this will be an iterative process to try and find the best
> compromise that suits these users as well as users who have only used
> formal releases.
> 
> > Benedikt
> >
> >
> >>
> >> > Benedikt
> >> >
> >> > [1]
> >> >
> >> http://home.apache.org/~britter/commons/bcel/6.0-SNAPSHOT/clirr-report.html
> >> >
> >> > sebb  schrieb am Mi., 8. Juni 2016 um 11:54 Uhr:
> >> >
> >> >> 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 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
> >> >> >>
> >> >> >
> >> >> > The report is the result of running mvn clean site. So if
> >> quiten-clirr is
> >> >> > activated by default it's the 'quitened' one (sorry I currently don't
> >> >> have
> >> >> > time to look into the pom).
> >> >>
> >> >> Yes, it is the default.
> >> >>
> >> >> > I can upload the "real" report to home.apache.org tonight when I'm at
> >> >> home.
> >> >>
> >> >> OK, thanks.
> >> >>
> >> >> > Benedikt
> >> >> >
> >> >> >
> >> >> >>
> >> >> >> On 8 June 2016 at 09:35, Benedikt Ritter  wrote:
> >> >> >> > 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
> >> >> >>
> >> >> >> -
> >> >> >> 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] Move Commons Math to TLP (again)...

[Rob Tompkins]

> On Jun 13, 2016, at 4:29 AM, sebb  wrote:
> 
> On 13 June 2016 at 03:06, Rob Tompkins  wrote:
>> With all of that said, then I'm a: +1 (binding).
> 
> AIUI this is a Common vote, as such only PMC member votes are
> considered binding.
> However you don't appear to be listed as a PMC member?

Agreed, I am not a PMC member, so you will have to pardon my naivety there with 
my attempt to vote. That said, I am willing to stand behind the project with 
Gilles in whatever stead is needed. 

All the best,
-Rob

> 
>> -Rob
>> 
>>> On Jun 12, 2016, at 9:27 PM, Niall Pemberton  
>>> wrote:
>>> 
>>> On Mon, Jun 13, 2016 at 2:10 AM, Benson Margulies 
>>> wrote:
>>> 
 Procedurally speaking, I see no reason for this community to hold any
 vote at all.
 
 If a small group of people, including a foundation member or two,
 wants to ask the board to establish a TLP, they may, by writing a
 coherent proposal to the board explaining the situation. The board
 might ask for a filled-in incubator proposal as input to their
 deliberations.
 
 Or, of they wish to go into the incubator to try to build a viable
 community that will get TLP status in time, they can write an
 incubator proposal.
 
 The board or IPMC might wonder about the state of affairs here when
 they receive one of these proposals, but it's hardly a matter that
 calls for a formal vote here.
>>> 
>>> Yes, I agree, but the discussion to gather those people together needs to
>>> take place somewhere and since here its been framed as a vote, then it
>>> would be good if those people who want to participate in a TLP effort would
>>> do so in this thread.
>>> 
>>> Niall
>>> 
>>> 
>>> On Sun, Jun 12, 2016 at 8:30 PM, Niall Pemberton
>>>  wrote:
 On Sun, Jun 12, 2016 at 11:08 PM, Gilles 
 wrote:
 
>> On Sun, 12 Jun 2016 14:33:58 -0700, Dennis E. Hamilton wrote:
>> 
>> -1 (non-binding)
>> 
>> Reason for objection:
>> 
>> I think the framing of this vote is confusing.
>> 
>> 1. There appears to be less ability to go to TLP than there was at
>> the time the previous motion passed.
>> 
>> 2. The discussion (but not the [VOTE]) speaks of going to TLP via
>> the incubator.  It has to be one or the other.  Propose a podling to
>> Incubator or propose a TLP to the Board.  There is no assurance that a
>> podling will graduate and it doesn't fit to make that a condition.
>> One could raise the special circumstances at general-incubator, but I
>> think that works best with something specific (but malleable) in hand.
>> 
>> 3. The Incubator is reluctant to start podlings from scratch, as
>> Niall observes.
> 
> Could you please expand on how 3 Commons PMC members and 3 would-be
> contributors are assimilated to "scratch"?
 
 It would be good if all those wanting to be part of a Math TLP could
 indicate that here and cast a vote for a Math TLP. Including yourself
 Gilles, since so far I don't remember seeing whether you that you were in
 favour of this.
 
 Niall
 
 
 
> 
> Thanks,
> Gilles
> 
> 
> 4. It seems to me that the best first-step on whether incubation is
>> feasible is to do the work to create an incubation proposal.  This
>> will require certain key factors to be addressed.  Not the least is
>> how the code base will be imported and, because it is from an Apache
>> Project, how it will be left behind too.  That definition can start
>> here and then be refined on the general-incubator list where one will
>> need to find a champion (perhaps), mentors, and a sufficient body of
>> initial committers.  It is important for those who would form the
>> initial core for a podling to learn enough about how incubation works.
>> 
>> - Dennis
>> 
>> Disclosure:
>> 
>> I have no idea how this might go.  I am not a Commons Math
>> subject-matter expert, even though computational mathematics has some
>> appeal for me.  I still have my bound "Collect Algorithms from ACM,
>> Volume 1: Algorithms 1-220."  I did not hold onto the microfiche of
>> later algorithms that were published in conjunction with the ACM
>> Transactions on Mathematical Software (TOMS). The latest (Algorithm
>> 959) is interesting although I have no idea where to find the code and
>> am dismayed that it is a library under the GPL.
>> 
>> -Original Message-
>>> From: Niall Pemberton [mailto:niall.pember...@gmail.com]
>>> Sent: Sunday, June 12, 2016 11:56
>>> To: Commons Developers List 
>>> Subject: Re: [VOTE] Move Commons Math to TLP (again)...
>>> 
>>> On Sat, Jun 11, 2016 at 10:39 AM, James Carman
>>> 
>>> wrote:
>>> 
 We would take math through the incubator in order to build community
>>> around
 it first. If we fail to do so, then w

Re: [VOTE] Move Apache Commons Primitives to dormant

[Matt Sicker]

Yes, but non-binding.

On 13 June 2016 at 01:29, Benedikt Ritter  wrote:

> Matt Sicker  schrieb am So., 12. Juni 2016 um 19:56 Uhr:
>
> > Chances are that this library may be obsoleted in Java 10 with value
> types
> > anyways, but that is years from now.
> >
>
> So that's a +1 from your side?
>
>
> >
> > On 12 June 2016 at 11:39, Stian Soiland-Reyes  wrote:
> >
> > > +1
> > > On 12 Jun 2016 4:18 p.m., "Benedikt Ritter" 
> wrote:
> > >
> > > > Hi,
> > > >
> > > > there hasn't been any activity in the primitives component for a long
> > > > while:
> > > >
> > > > - last release dates back to 2003-11-05
> > > > - using svn log -l 50
> > > > http://svn.apache.org/repos/asf/commons/proper/primitives/trunk I
> did
> > > not
> > > > find a single commit that changed any of the code
> > > > - no activity on dev@ and user@
> > > >
> > > > I think we can conclude that there is no more interest in this
> > component.
> > > > For this reason I'm calling a vote for moving the Apache Commons
> > > Primitives
> > > > component to dormant. This vote will close no sooner that 72 hours
> from
> > > > now, i.e. sometime after 17:30 CEST 12-June 2016.
> > > >
> > > > [ ] +1, yes move Primitives to dormant
> > > > [ ] +/- 0, I'm not sure...
> > > > [ ] -1, no, do NOT move Primitives to dormant, because...
> > > >
> > > > Thank you,
> > > > Benedikt
> > > >
> > >
> >
> >
> >
> > --
> > Matt Sicker 
> >
>



-- 
Matt Sicker 

Re: [ALL] beware of URLs that represent file system locations

[sebb]

On 13 June 2016 at 12:43, Benedikt Ritter  wrote:
> Thank you for bringing this up and for fixing the Problem!

I probably caused it ...

> sebb  schrieb am Mo., 13. Juni 2016 um 12:32:
>
>> A Commons NET test was failing on Jenkins, but worked fine locally.
>> And previously had been working on Continuum.
>>
>> Turns out this was because Jenkins uses path names of the form
>> .../commons-net@n/.
>>
>> The test code was using the following to get the source location:
>>
>> java.security.CodeSource.getLocation().getFile()
>>
>> The embedded '@' was returned encoded as %40.
>>
>> When used as a File parameter of course it did not work, so the test
>> failed.
>>
>> Using java.net.URLDecoder.decode() on the file-part of the URL fixed this.
>>
>> There are no doubt other methods that return URLs that represent local
>> file paths.
>> Beware!
>>
>> -
>> 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] Move Apache Commons Primitives to dormant

[Kristian Rosenvold]

+1
12. jun. 2016 5.18 p.m. skrev "Benedikt Ritter" :

> Hi,
>
> there hasn't been any activity in the primitives component for a long
> while:
>
> - last release dates back to 2003-11-05
> - using svn log -l 50
> http://svn.apache.org/repos/asf/commons/proper/primitives/trunk I did not
> find a single commit that changed any of the code
> - no activity on dev@ and user@
>
> I think we can conclude that there is no more interest in this component.
> For this reason I'm calling a vote for moving the Apache Commons Primitives
> component to dormant. This vote will close no sooner that 72 hours from
> now, i.e. sometime after 17:30 CEST 12-June 2016.
>
> [ ] +1, yes move Primitives to dormant
> [ ] +/- 0, I'm not sure...
> [ ] -1, no, do NOT move Primitives to dormant, because...
>
> Thank you,
> Benedikt
>

Re: [VOTE] Move Commons Math to TLP (again)...

[Jochen Wiedmann]

IMO, the primary advantagae of the incubator would be, that the
project could have its own mailing list, etc.

Thus, it would be independent from the happenings at dev@commons, etc.
Which is, (IMO) exactly, what is required right now.

Jochen


On Sun, Jun 12, 2016 at 11:27 PM, Ralph Goers
 wrote:
> If this moves to Incubator you would become part of the Podling PMC and get a 
> write to vote and get commit rights.  That is one of the advantages of moving 
> this to the incubator.
>
> Ralph
>
>> On Jun 12, 2016, at 11:23 AM, Rob Tompkins  wrote:
>>
>> I'm willing to help, but I'm not sure that I have voting privileges here 
>> since I don't have commit rights.
>>
>> -Rob
>>
>>> On Jun 12, 2016, at 1:43 PM, Jochen Wiedmann  
>>> wrote:
>>>
>>> +1 (I think, we could have that: Gilles, myself, and I am certain,
>>> that a third person would step forward.
>>>
 On Sat, Jun 11, 2016 at 7:35 AM, Ralph Goers  
 wrote:
 -1 (binding)

 At least until there are enough people to have a viable PMC.
>>>
>>> Jochen
>>>
>>> -
>>> 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
>



-- 
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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

Re: [BCEL] Latest Clirr report

[Jochen Wiedmann]

On Mon, Jun 13, 2016 at 12:03 AM, sebb  wrote:

>> I'd suggest to leave the java.io.Serializable stuff, as it is. In
>> practice, this will only be noticed, if anyone is actually
>> serializing/deserializing these items, and I assume that the interface
>> has been removed for a reason. (Meaning: Although the interface
>> declaration is present, they most likely aren't actually
>> serializable.)
>
> I don't follow what you are suggesting.
> Serializable has been removed from everything, as it does not make
> sense to serialise BCEl and anyway was not supported properly.
> Are you suggesting implements Serializable should be restored?


No, I propose to leave it, as it is now, and ignore this in the clirr report.
Although removing the interface java.io.Serializable does formally constitute
a binary incompatibiliy, this is unlikely to constitute a problem. And
those, who
will notice, will typically notice at runtime anyways, because these
classes are declared Serializable, although they aren't really.

Jochen


-- 
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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

Re: [csv] Update to Java 8

[Stian Soiland-Reyes]

7 (email) or 8 (subject)?

I'm +1 for either - but I'm not sure if CSV would benefit much from
Java 8 features, or are you thinking Java 8 Streams for CSV? (That
would be really cool!)



On 13 June 2016 at 03:18, Gary Gregory  wrote:
> Now that we pushed out 1.4, I plan on updating the platform requirement to
> Java 7.
>
> Gary
>
> --
> 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



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
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

Re: [csv] Update to Java 8

[Gary Gregory]

Java 7. Right now I'm thinking of adding convenience APIs for NIO Path, and
old school File.

Java 8 streams would be interesting for sure. Later for me...

Gary

On Mon, Jun 13, 2016 at 10:10 AM, Stian Soiland-Reyes 
wrote:

> 7 (email) or 8 (subject)?
>
> I'm +1 for either - but I'm not sure if CSV would benefit much from
> Java 8 features, or are you thinking Java 8 Streams for CSV? (That
> would be really cool!)
>
>
>
> On 13 June 2016 at 03:18, Gary Gregory  wrote:
> > Now that we pushed out 1.4, I plan on updating the platform requirement
> to
> > Java 7.
> >
> > Gary
> >
> > --
> > 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
>
>
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating), Apache Commons
> 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
>
>


-- 
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] Move Commons Math to TLP (again)...

[Stian Soiland-Reyes]

+1 for a move to Incubator, rather than a TLP, as Math now needs to
find its new ground and direction, and in particular grow its active
developer base.


The incubator is great for reducing the distance for moving from
contributor to committer, and for letting everyone get a say in what
direction you are moving. The role of the incubator mentors is to help
you build the community, and while it's not always fun to get reminded
about what is missing here, the process of the incubator forces the
community focus (who are we) and not just code focus (what does it
do).

Obviously you can do that straight as a TLP as well, but I think given
the fork happened, Math needs to grow more slowly back into shape, and
the Incubator should be good for that.

I agree on trying to write an Incubator proposal and start discussing
it on general@incubator.


On 13 June 2016 at 17:43, Jochen Wiedmann  wrote:
> IMO, the primary advantagae of the incubator would be, that the
> project could have its own mailing list, etc.
>
> Thus, it would be independent from the happenings at dev@commons, etc.
> Which is, (IMO) exactly, what is required right now.
>
> Jochen
>
>
> On Sun, Jun 12, 2016 at 11:27 PM, Ralph Goers
>  wrote:
>> If this moves to Incubator you would become part of the Podling PMC and get 
>> a write to vote and get commit rights.  That is one of the advantages of 
>> moving this to the incubator.
>>
>> Ralph
>>
>>> On Jun 12, 2016, at 11:23 AM, Rob Tompkins  wrote:
>>>
>>> I'm willing to help, but I'm not sure that I have voting privileges here 
>>> since I don't have commit rights.
>>>
>>> -Rob
>>>
 On Jun 12, 2016, at 1:43 PM, Jochen Wiedmann  
 wrote:

 +1 (I think, we could have that: Gilles, myself, and I am certain,
 that a third person would step forward.

> On Sat, Jun 11, 2016 at 7:35 AM, Ralph Goers  
> wrote:
> -1 (binding)
>
> At least until there are enough people to have a viable PMC.

 Jochen

 -
 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
>>
>
>
>
> --
> The next time you hear: "Don't reinvent the wheel!"
>
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>
> -
> 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), Apache Commons
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

Re: [csv] Update to Java 8

[Stian Soiland-Reyes]

NIO Path and AutoClosable try blocks are good enough reasons for me!   :)




On 13 June 2016 at 18:13, Gary Gregory  wrote:
> Java 7. Right now I'm thinking of adding convenience APIs for NIO Path, and
> old school File.
>
> Java 8 streams would be interesting for sure. Later for me...
>
> Gary
>
> On Mon, Jun 13, 2016 at 10:10 AM, Stian Soiland-Reyes 
> wrote:
>
>> 7 (email) or 8 (subject)?
>>
>> I'm +1 for either - but I'm not sure if CSV would benefit much from
>> Java 8 features, or are you thinking Java 8 Streams for CSV? (That
>> would be really cool!)
>>
>>
>>
>> On 13 June 2016 at 03:18, Gary Gregory  wrote:
>> > Now that we pushed out 1.4, I plan on updating the platform requirement
>> to
>> > Java 7.
>> >
>> > Gary
>> >
>> > --
>> > 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
>>
>>
>>
>> --
>> Stian Soiland-Reyes
>> Apache Taverna (incubating), Apache Commons
>> 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
>>
>>
>
>
> --
> 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



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
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

Re: [ALL] About binary compatibility

[Thomas Vandahl]

On 05.06.16 20:33, James Carman wrote:
> Not quite. OSGi is a special case. It's much more restrictive than simple
> J2SE, because it can be. In the general case, the public API for OSGi is
> different from the public API for J2SE. Let's not confuse the two.

My intention was to use the OSGi meta data to define something that we
consider a public API. I agree to Sebastian that this might be difficult
for some components as they were not designed with a separation of
public and private API in mind. That's why I believe that suing
something a little more restrictive may help us to move forward and
improve the situation.

Bye, Thomas.


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

Re: [ALL] About binary compatibility

[Jochen Wiedmann]

On Mon, Jun 13, 2016 at 8:49 PM, Thomas Vandahl  wrote:
> On 05.06.16 20:33, James Carman wrote:
>> Not quite. OSGi is a special case. It's much more restrictive than simple
>> J2SE, because it can be. In the general case, the public API for OSGi is
>> different from the public API for J2SE. Let's not confuse the two.
>
> My intention was to use the OSGi meta data to define something that we
> consider a public API. I agree to Sebastian that this might be difficult
> for some components as they were not designed with a separation of
> public and private API in mind. That's why I believe that suing
> something a little more restrictive may help us to move forward and
> improve the situation.

IMO, we are only complicating the situation, because that would only
make the situation less clear. Right now, we suggest that the project
retains binary compatibility, unless explicitly documented (via
package name, and Maven coordinates). Give

-- 
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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

Re: [ALL] About binary compatibility

[James Carman]

I'd rather not make it (the OSGi metadata) the "source of truth".

On Mon, Jun 13, 2016 at 2:49 PM Thomas Vandahl  wrote:

> On 05.06.16 20:33, James Carman wrote:
> > Not quite. OSGi is a special case. It's much more restrictive than simple
> > J2SE, because it can be. In the general case, the public API for OSGi is
> > different from the public API for J2SE. Let's not confuse the two.
>
> My intention was to use the OSGi meta data to define something that we
> consider a public API. I agree to Sebastian that this might be difficult
> for some components as they were not designed with a separation of
> public and private API in mind. That's why I believe that suing
> something a little more restrictive may help us to move forward and
> improve the situation.
>
> Bye, Thomas.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [ALL] About binary compatibility

[Thomas Vandahl]

On 13.06.16 20:54, Jochen Wiedmann wrote:
> On Mon, Jun 13, 2016 at 8:49 PM, Thomas Vandahl  wrote:
>> On 05.06.16 20:33, James Carman wrote:
>>> Not quite. OSGi is a special case. It's much more restrictive than simple
>>> J2SE, because it can be. In the general case, the public API for OSGi is
>>> different from the public API for J2SE. Let's not confuse the two.
>>
>> My intention was to use the OSGi meta data to define something that we
>> consider a public API. I agree to Sebastian that this might be difficult
>> for some components as they were not designed with a separation of
>> public and private API in mind. That's why I believe that suing
>> something a little more restrictive may help us to move forward and
>> improve the situation.
> 
> IMO, we are only complicating the situation, because that would only
> make the situation less clear. Right now, we suggest that the project
> retains binary compatibility, unless explicitly documented (via
> package name, and Maven coordinates). Give
> 
But we gain flexibility. Take JCS. The "public API" is basically just
what CacheAccess and friends define. Everything else is
implementation-specific. So the public API could be stable for a long
time while everything under the hood can be redesigned. I have quite
some experience with this approach and would prefer it over the current
commons policy any time.

Bye, Thomas

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

Re: [ALL] About binary compatibility

[Thomas Vandahl]

On 13.06.16 20:57, James Carman wrote:
> I'd rather not make it (the OSGi metadata) the "source of truth".

I'm not insisting on OSGi meta data but I strongly believe that one
(single) source of truth is required. Suggest something else.

Bye, Thomas.


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

Re: [ALL] About binary compatibility

[James Carman]

Agree we should have a "source of truth". Is there something wrong with
using an "internal" or "impl" package name? The bundle plugin for OSGi
doesn't export these by default, which would be a nice side effect! :).

On Mon, Jun 13, 2016 at 3:05 PM Thomas Vandahl  wrote:

> On 13.06.16 20:57, James Carman wrote:
> > I'd rather not make it (the OSGi metadata) the "source of truth".
>
> I'm not insisting on OSGi meta data but I strongly believe that one
> (single) source of truth is required. Suggest something else.
>
> Bye, Thomas.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [ALL] About binary compatibility

[Mark Thomas]

Tomcat does this with a simple text file in the root of the
distribution. Compare Tomcat 9 [1] (currently in development) with
Tomcat 8 [2] (stable release).

We actually don't guarantee very much but Tomcat is a very different
type of project. The idea, however, could be re-used.

Mark

[1]
http://svn.apache.org/viewvc/tomcat/trunk/RELEASE-NOTES?view=annotate#l44

[2]
http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/RELEASE-NOTES?view=annotate#l44

On 13/06/2016 19:57, James Carman wrote:
> I'd rather not make it (the OSGi metadata) the "source of truth".
> 
> On Mon, Jun 13, 2016 at 2:49 PM Thomas Vandahl  wrote:
> 
>> On 05.06.16 20:33, James Carman wrote:
>>> Not quite. OSGi is a special case. It's much more restrictive than simple
>>> J2SE, because it can be. In the general case, the public API for OSGi is
>>> different from the public API for J2SE. Let's not confuse the two.
>>
>> My intention was to use the OSGi meta data to define something that we
>> consider a public API. I agree to Sebastian that this might be difficult
>> for some components as they were not designed with a separation of
>> public and private API in mind. That's why I believe that suing
>> something a little more restrictive may help us to move forward and
>> improve the situation.
>>
>> Bye, 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

Re: [VOTE] Move Apache Commons Primitives to dormant

[Bernd Eckenfels]

+1 (binding)

> [X] +1, yes move Primitives to dormant

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

Re: [VOTE] Move Commons Math to TLP (again)...

[Gilles]

Hi.

On Mon, 13 Jun 2016 01:30:20 +0100, Niall Pemberton wrote:
On Sun, Jun 12, 2016 at 11:08 PM, Gilles 


wrote:


On Sun, 12 Jun 2016 14:33:58 -0700, Dennis E. Hamilton wrote:


-1 (non-binding)

Reason for objection:

 I think the framing of this vote is confusing.

 1. There appears to be less ability to go to TLP than there was at
the time the previous motion passed.

 2. The discussion (but not the [VOTE]) speaks of going to TLP via
the incubator.  It has to be one or the other.  Propose a podling 
to
Incubator or propose a TLP to the Board.  There is no assurance 
that a

podling will graduate and it doesn't fit to make that a condition.
One could raise the special circumstances at general-incubator, but 
I
think that works best with something specific (but malleable) in 
hand.


 3. The Incubator is reluctant to start podlings from scratch, as
Niall observes.



Could you please expand on how 3 Commons PMC members and 3 would-be
contributors are assimilated to "scratch"?



It would be good if all those wanting to be part of a Math TLP could
indicate that here and cast a vote for a Math TLP. Including yourself
Gilles, since so far I don't remember seeing whether you that you 
were in

favour of this.


In another thread, I indicated what was my preferred way to get
back on track after the fork announcement.

I know that I repeat myself but I am *totally* convinced that some
part of what was CM can become one or a few bona fide components.

Getting after this "low-hanging fruit" (meaning: release *early*)
can have a positive effect.
At the opposite, letting code that could be released rot until we
can fix all the issues in CM, is depressing.

And this is mostly independent of a larger-scale effort aimed at
creating a TLP.

It's a pity that the only way to make any decision about the CM
codebase, that does not amount to not deciding anything, seems
to depend on taking this code elsewhere.

Whether here at Commons, in a new TLP, or in the incubator, my
proposal would be the same: rebuild a project around the competences
available *now*.
Personally, I'll not participate in a project based on the messianic
belief that subject matter experts (a.k.a. "Mathematicians") will
suddenly figure out that they want to contribute to Commons Math.
[For better or worse, CM never worked that way.]

The question is: Why do some non-contributors try to force
contributors to continue releasing all the abandoned codebase?

I understand that some people in the Commons PMC might want to
evaluate the usefulness of each new component.
But why not discuss each one proposed, specifically?


Regards,
Gilles


Niall





Thanks,
Gilles


 4. It seems to me that the best first-step on whether incubation is

feasible is to do the work to create an incubation proposal.  This
will require certain key factors to be addressed.  Not the least is
how the code base will be imported and, because it is from an 
Apache

Project, how it will be left behind too.  That definition can start
here and then be refined on the general-incubator list where one 
will
need to find a champion (perhaps), mentors, and a sufficient body 
of

initial committers.  It is important for those who would form the
initial core for a podling to learn enough about how incubation 
works.


 - Dennis

Disclosure:

 I have no idea how this might go.  I am not a Commons Math
subject-matter expert, even though computational mathematics has 
some

appeal for me.  I still have my bound "Collect Algorithms from ACM,
Volume 1: Algorithms 1-220."  I did not hold onto the microfiche of
later algorithms that were published in conjunction with the ACM
Transactions on Mathematical Software (TOMS). The latest (Algorithm
959) is interesting although I have no idea where to find the code 
and

am dismayed that it is a library under the GPL.

-Original Message-

From: Niall Pemberton [mailto:niall.pember...@gmail.com]
Sent: Sunday, June 12, 2016 11:56
To: Commons Developers List 
Subject: Re: [VOTE] Move Commons Math to TLP (again)...

On Sat, Jun 11, 2016 at 10:39 AM, James Carman

wrote:

> We would take math through the incubator in order to build 
community

around
> it first. If we fail to do so, then we can decide its fate at 
that

time. We
> haven't done a good job attracting new people to math here at 
all. It

has
> always been maintained primarily by a select few.
>

It made sense to me when there were 6 committers working on Math, 
but I
think given the exodus of most of those people to hipparchus then 
it

would
be better to wait a while for the dust to settle to see what 
happens

with
Math.

I also don't think the incubator is a good place for starting a
community
from scratch (i.e. one or two man projects) - if you have a 
nucleus of

at
least a few people, then it has much better chance of success.

So for me, I'm -1 unless there are enough Mathematicians who want 
to

work
on the code to give it a chance as an incubator project.

Niall


>
> On Sat, Jun 11

Re: [csv] Update to Java 8

[Peter Ansell]

The ability to push Lambda's into a CSV processing library, to avoid
users having to implement a "while(hasNext())" loop
correctly/efficiently each time shouldn't underestimated. I have
written a utility method myself to do this for my projects. It uses
Jackson CSV right now but the pattern should be similar.

https://github.com/ansell/csvsum/blob/master/src/main/java/com/github/ansell/csv/util/CSVUtil.java#L98

Cheers,

Peter

On 14 June 2016 at 03:10, Stian Soiland-Reyes  wrote:
> 7 (email) or 8 (subject)?
>
> I'm +1 for either - but I'm not sure if CSV would benefit much from
> Java 8 features, or are you thinking Java 8 Streams for CSV? (That
> would be really cool!)
>
>
>
> On 13 June 2016 at 03:18, Gary Gregory  wrote:
>> Now that we pushed out 1.4, I plan on updating the platform requirement to
>> Java 7.
>>
>> Gary
>>
>> --
>> 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
>
>
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating), Apache Commons
> 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

[lang] replace clirr with japicmp

[Charles Honton]

Now that lang is compiled with java6, clirr is broken.  Do we want to update to 
a more modern report like japicmp ?

The pom change is something like 

  
   com.github.siom79.japicmp
   japicmp-maven-plugin
   0.8.0
   

 true
 
true

   
   

 verify
 
  cmp
 

   
  

regards,
chas

Re: [lang] replace clirr with japicmp

[Benedikt Ritter]

Hello Charles,

Charles Honton  schrieb am Di., 14. Juni 2016 um 07:29 Uhr:

> Now that lang is compiled with java6, clirr is broken.  Do we want to
> update to a more modern report like japicmp <
> https://siom79.github.io/japicmp/>?
>

The site build is only broken when build with Java 8. It should be working
with Java 6 and Java 7.

Benedikt


>
> The pom change is something like
>
>   
>com.github.siom79.japicmp
>japicmp-maven-plugin
>0.8.0
>
> 
>  true
>
>  
> true
> 
>
>
> 
>  verify
>  
>   cmp
>  
> 
>
>   
>
> regards,
> chas

Re: svn commit: r1748347 - in /commons/proper/csv/trunk/src: changes/changes.xml main/java/org/apache/commons/csv/CSVFormat.java test/java/org/apache/commons/csv/CSVPrinterTest.java

[Benedikt Ritter]

I don't like how we're evolving CSVFormat. It is becoming a dumping ground
for anything that may be useful or convenient. The more methods we add, the
harder it becomes for users to find the right method for their use case.

Benedikt

 schrieb am Di., 14. Juni 2016 um 07:53 Uhr:

> Author: ggregory
> Date: Tue Jun 14 05:53:32 2016
> New Revision: 1748347
>
> URL: http://svn.apache.org/viewvc?rev=1748347&view=rev
> Log:
> Add convenience API CSVFormat.print(File, Charset) (JIRA is down ATM).
>
> Modified:
> commons/proper/csv/trunk/src/changes/changes.xml
>
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
>
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
>
> Modified: commons/proper/csv/trunk/src/changes/changes.xml
> URL:
> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/changes/changes.xml?rev=1748347&r1=1748346&r2=1748347&view=diff
>
> ==
> --- commons/proper/csv/trunk/src/changes/changes.xml (original)
> +++ commons/proper/csv/trunk/src/changes/changes.xml Tue Jun 14 05:53:32
> 2016
> @@ -40,6 +40,7 @@
>
>  
>Update platform requirement from Java 6 to 7.
> +  Add convenience API CSVFormat.print(File, Charset)
>  
>  
>Make CSVPrinter.print(Object) GC-free.
>
> Modified:
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> URL:
> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java?rev=1748347&r1=1748346&r2=1748347&view=diff
>
> ==
> ---
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> (original)
> +++
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> Tue Jun 14 05:53:32 2016
> @@ -28,10 +28,14 @@ import static org.apache.commons.csv.Con
>  import static org.apache.commons.csv.Constants.SP;
>  import static org.apache.commons.csv.Constants.TAB;
>
> +import java.io.File;
> +import java.io.FileOutputStream;
>  import java.io.IOException;
> +import java.io.OutputStreamWriter;
>  import java.io.Reader;
>  import java.io.Serializable;
>  import java.io.StringWriter;
> +import java.nio.charset.Charset;
>  import java.sql.ResultSet;
>  import java.sql.ResultSetMetaData;
>  import java.sql.SQLException;
> @@ -864,6 +868,27 @@ public final class CSVFormat implements
>  }
>
>  /**
> + * Prints to the specified output.
> + *
> + * 
> + * See also {@link CSVPrinter}.
> + * 
> + *
> + * @param out
> + *the output
> + * @param charset
> + *A charset
> + * @return a printer to an output
> + * @throws IOException
> + * thrown if the optional header cannot be printed.
> + * @since 1.5
> + */
> +public CSVPrinter print(final File out, Charset charset) throws
> IOException {
> +// The FileWriter will be closed when close() is called.
> +return new CSVPrinter(new OutputStreamWriter(new
> FileOutputStream(out), charset), this);
> +}
> +
> +/**
>   * Prints the {@code value} as the next value on the line to {@code
> out}. The value will be escaped or encapsulated
>   * as needed. Useful when one wants to avoid creating CSVPrinters.
>   *
>
> Modified:
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
> URL:
> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java?rev=1748347&r1=1748346&r2=1748347&view=diff
>
> ==
> ---
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
> (original)
> +++
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
> Tue Jun 14 05:53:32 2016
> @@ -22,9 +22,12 @@ import static org.junit.Assert.assertArr
>  import static org.junit.Assert.assertEquals;
>  import static org.junit.Assert.assertFalse;
>
> +import java.io.File;
>  import java.io.IOException;
>  import java.io.StringReader;
>  import java.io.StringWriter;
> +import java.nio.charset.Charset;
> +import java.nio.charset.StandardCharsets;
>  import java.sql.Connection;
>  import java.sql.DriverManager;
>  import java.sql.ResultSet;
> @@ -38,6 +41,7 @@ import java.util.List;
>  import java.util.Objects;
>  import java.util.Random;
>
> +import org.apache.commons.io.FileUtils;
>  import org.junit.Assert;
>  import org.junit.Ignore;
>  import org.junit.Test;
> @@ -728,6 +732,24 @@ public class CSVPrinterTest {
>  }
>
>  @Test
> +public void testPrintToFileWithDefaultCharset() throws IOException {
> +File file = File.createTempFile(getClass().getName(), ".csv");
> +try (final CSVPrinter printer = CSVFormat.DEFAULT.print(file,
> Charset.defaultCharset())

Re: [lang] replace clirr with japicmp

[Jochen Wiedmann]

On Tue, Jun 14, 2016 at 8:11 AM, Benedikt Ritter  wrote:

> Charles Honton  schrieb am Di., 14. Juni 2016 um 07:29 Uhr:
>
>> Now that lang is compiled with java6, clirr is broken.  Do we want to
>> update to a more modern report like japicmp <
>> https://siom79.github.io/japicmp/>?
>>
>
> The site build is only broken when build with Java 8. It should be working
> with Java 6 and Java 7.

Lets give the new kid on the block a try. (But don't forget, to
report, what the experiences are.)

Clirr is basically unmaintained, since years. A replacement would
definitely be valuable.

Jochen

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

Re: [VOTE] Move Apache Commons Primitives to dormant

[Benedikt Ritter]

My +1

Benedikt Ritter  schrieb am So., 12. Juni 2016 um
17:17 Uhr:

> Hi,
>
> there hasn't been any activity in the primitives component for a long
> while:
>
> - last release dates back to 2003-11-05
> - using svn log -l 50
> http://svn.apache.org/repos/asf/commons/proper/primitives/trunk I did not
> find a single commit that changed any of the code
> - no activity on dev@ and user@
>
> I think we can conclude that there is no more interest in this component.
> For this reason I'm calling a vote for moving the Apache Commons Primitives
> component to dormant. This vote will close no sooner that 72 hours from
> now, i.e. sometime after 17:30 CEST 12-June 2016.
>
> [ ] +1, yes move Primitives to dormant
> [ ] +/- 0, I'm not sure...
> [ ] -1, no, do NOT move Primitives to dormant, because...
>
> Thank you,
> Benedikt
>

Re: [lang] replace clirr with japicmp

[Gary Gregory]

On Mon, Jun 13, 2016 at 11:11 PM, Benedikt Ritter 
wrote:

> Hello Charles,
>
> Charles Honton  schrieb am Di., 14. Juni 2016 um 07:29
> Uhr:
>
> > Now that lang is compiled with java6, clirr is broken.  Do we want to
> > update to a more modern report like japicmp <
> > https://siom79.github.io/japicmp/>?
> >
>
> The site build is only broken when build with Java 8. It should be working
> with Java 6 and Java 7.
>

+1, Java 6 and 7 are fine. One issue with Java 8 working for our builds is
getting BCEL out the door.

Gary


>
> Benedikt
>
>
> >
> > The pom change is something like
> >
> >   
> >com.github.siom79.japicmp
> >japicmp-maven-plugin
> >0.8.0
> >
> > 
> >  true
> >
> >
> true
> > 
> >
> >
> > 
> >  verify
> >  
> >   cmp
> >  
> > 
> >
> >   
> >
> > regards,
> > chas
>



-- 
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: svn commit: r1748347 - in /commons/proper/csv/trunk/src: changes/changes.xml main/java/org/apache/commons/csv/CSVFormat.java test/java/org/apache/commons/csv/CSVPrinterTest.java

[Gary Gregory]

On Mon, Jun 13, 2016 at 11:13 PM, Benedikt Ritter 
wrote:

> I don't like how we're evolving CSVFormat. It is becoming a dumping ground
> for anything that may be useful or convenient. The more methods we add, the
> harder it becomes for users to find the right method for their use case.
>

Small is nice, I get that. But how would you do it differently so that I
can easily use Paths, Files, URI, and URLs...

Gary


>
> Benedikt
>
>  schrieb am Di., 14. Juni 2016 um 07:53 Uhr:
>
> > Author: ggregory
> > Date: Tue Jun 14 05:53:32 2016
> > New Revision: 1748347
> >
> > URL: http://svn.apache.org/viewvc?rev=1748347&view=rev
> > Log:
> > Add convenience API CSVFormat.print(File, Charset) (JIRA is down ATM).
> >
> > Modified:
> > commons/proper/csv/trunk/src/changes/changes.xml
> >
> >
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> >
> >
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
> >
> > Modified: commons/proper/csv/trunk/src/changes/changes.xml
> > URL:
> >
> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/changes/changes.xml?rev=1748347&r1=1748346&r2=1748347&view=diff
> >
> >
> ==
> > --- commons/proper/csv/trunk/src/changes/changes.xml (original)
> > +++ commons/proper/csv/trunk/src/changes/changes.xml Tue Jun 14 05:53:32
> > 2016
> > @@ -40,6 +40,7 @@
> >
> >  
> >Update platform requirement from Java 6 to 7.
> > +  Add convenience API CSVFormat.print(File, Charset)
> >  
> >  
> >Make CSVPrinter.print(Object) GC-free.
> >
> > Modified:
> >
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> > URL:
> >
> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java?rev=1748347&r1=1748346&r2=1748347&view=diff
> >
> >
> ==
> > ---
> >
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> > (original)
> > +++
> >
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> > Tue Jun 14 05:53:32 2016
> > @@ -28,10 +28,14 @@ import static org.apache.commons.csv.Con
> >  import static org.apache.commons.csv.Constants.SP;
> >  import static org.apache.commons.csv.Constants.TAB;
> >
> > +import java.io.File;
> > +import java.io.FileOutputStream;
> >  import java.io.IOException;
> > +import java.io.OutputStreamWriter;
> >  import java.io.Reader;
> >  import java.io.Serializable;
> >  import java.io.StringWriter;
> > +import java.nio.charset.Charset;
> >  import java.sql.ResultSet;
> >  import java.sql.ResultSetMetaData;
> >  import java.sql.SQLException;
> > @@ -864,6 +868,27 @@ public final class CSVFormat implements
> >  }
> >
> >  /**
> > + * Prints to the specified output.
> > + *
> > + * 
> > + * See also {@link CSVPrinter}.
> > + * 
> > + *
> > + * @param out
> > + *the output
> > + * @param charset
> > + *A charset
> > + * @return a printer to an output
> > + * @throws IOException
> > + * thrown if the optional header cannot be printed.
> > + * @since 1.5
> > + */
> > +public CSVPrinter print(final File out, Charset charset) throws
> > IOException {
> > +// The FileWriter will be closed when close() is called.
> > +return new CSVPrinter(new OutputStreamWriter(new
> > FileOutputStream(out), charset), this);
> > +}
> > +
> > +/**
> >   * Prints the {@code value} as the next value on the line to {@code
> > out}. The value will be escaped or encapsulated
> >   * as needed. Useful when one wants to avoid creating CSVPrinters.
> >   *
> >
> > Modified:
> >
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
> > URL:
> >
> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java?rev=1748347&r1=1748346&r2=1748347&view=diff
> >
> >
> ==
> > ---
> >
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
> > (original)
> > +++
> >
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
> > Tue Jun 14 05:53:32 2016
> > @@ -22,9 +22,12 @@ import static org.junit.Assert.assertArr
> >  import static org.junit.Assert.assertEquals;
> >  import static org.junit.Assert.assertFalse;
> >
> > +import java.io.File;
> >  import java.io.IOException;
> >  import java.io.StringReader;
> >  import java.io.StringWriter;
> > +import java.nio.charset.Charset;
> > +import java.nio.charset.StandardCharsets;
> >  import java.sql.Connection;
> >  import java.sql.DriverManager;
> >  import java.sql.ResultSet;
> > @@ -38,6 +41,7 @@ import java.util.List;
> >  import java.util.Objects;
> >  import java

Re: [lang] replace clirr with japicmp

[Benedikt Ritter]

Jochen Wiedmann  schrieb am Di., 14. Juni 2016
um 08:14 Uhr:

> On Tue, Jun 14, 2016 at 8:11 AM, Benedikt Ritter 
> wrote:
>
> > Charles Honton  schrieb am Di., 14. Juni 2016 um 07:29
> Uhr:
> >
> >> Now that lang is compiled with java6, clirr is broken.  Do we want to
> >> update to a more modern report like japicmp <
> >> https://siom79.github.io/japicmp/>?
> >>
> >
> > The site build is only broken when build with Java 8. It should be
> working
> > with Java 6 and Java 7.
>
> Lets give the new kid on the block a try. (But don't forget, to
> report, what the experiences are.)
>

okay


>
> Clirr is basically unmaintained, since years. A replacement would
> definitely be valuable.
>

Could happen to japicmp sooner or later, since it seems to be maintained by
a single person at the moment. I don't like pulling in dependencies like
this. But you're right if Clirr is unmaintained.

Benedikt


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

[DISCUSS] Brining clirr to the ASF?

[Benedikt Ritter]

Hi,

as Jochen has pointed out, Clirr seems to be unmaintained. However we build
a good part of our release strategy upon clirr. So I wonder whether we
should foster bringing clirr to the ASF (for example by going through
incubation). We're probably not the only ASF project using Clirr.

Benedikt

Re: [lang] replace clirr with japicmp

[Gary Gregory]

On Mon, Jun 13, 2016 at 11:18 PM, Benedikt Ritter 
wrote:

> Jochen Wiedmann  schrieb am Di., 14. Juni 2016
> um 08:14 Uhr:
>
> > On Tue, Jun 14, 2016 at 8:11 AM, Benedikt Ritter 
> > wrote:
> >
> > > Charles Honton  schrieb am Di., 14. Juni 2016 um
> 07:29
> > Uhr:
> > >
> > >> Now that lang is compiled with java6, clirr is broken.  Do we want to
> > >> update to a more modern report like japicmp <
> > >> https://siom79.github.io/japicmp/>?
> > >>
> > >
> > > The site build is only broken when build with Java 8. It should be
> > working
> > > with Java 6 and Java 7.
> >
> > Lets give the new kid on the block a try. (But don't forget, to
> > report, what the experiences are.)
> >
>
> okay
>
>
> >
> > Clirr is basically unmaintained, since years. A replacement would
> > definitely be valuable.
> >
>
> Could happen to japicmp sooner or later, since it seems to be maintained by
> a single person at the moment. I don't like pulling in dependencies like
> this. But you're right if Clirr is unmaintained.
>

The Clirr Maven plugin is maintained though and there has been talk of it's
dependency on BCEL being updated.

I've not looked under the plugin's hood but if the plugin is fiddling with
BCEL then perhaps it is doing in more than just wrapping Clirr?

Gary


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



-- 
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: [DISCUSS] Brining clirr to the ASF?

[Gary Gregory]

On Mon, Jun 13, 2016 at 11:19 PM, Benedikt Ritter 
wrote:

> Hi,
>
> as Jochen has pointed out, Clirr seems to be unmaintained. However we build
> a good part of our release strategy upon clirr. So I wonder whether we
> should foster bringing clirr to the ASF (for example by going through
> incubation). We're probably not the only ASF project using Clirr.
>

+1. Can we bring in code that's under GNU Lesser General Public and make it
ASL 2?

Could fit under a new Commons Build or Clirr component since it is a
"common" build requirement.

Gary


> Benedikt
>



-- 
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: Re: [BCEL] Latest Clirr report

[Benedikt Ritter]

Andrey Loskutov  schrieb am Mo., 13. Juni 2016 um
14:15 Uhr:

> Hi,
>
> from FindBugs point of view, the biggest issue was the removal of
> "intermediate" org.apache.bcel.classfile.StackMapTable /
> org.apache.bcel.classfile.StackMapTableEntry classes. The removal of
> Serializable is not important for us at all, so I don't care.
>
> We had a discussion here on the list regarding StackMapTable* and as far
> as I understood, there is no plan to restore those two types.
>
> Therefore I've adopted FB code now (not on master, but soon) and included
> replacements for the missing classes to the binary distribution, so that
> the downstream plugins provider will at least do not crash due the missing
> classes. However, the behavior is changed and without source code
> adaptation code relied on those two classes will not work.
>
> I'va also tried (smoke tests) the biggest known (to me) plugin
> "fb-contrib" from Dave and found only one BC issue left -
> https://github.com/mebigfatguy/fb-contrib/issues/116.
>
> This was also caused by some refactorings in not released code
> (ParameterAnnotationEntry).
>
> So from my limited FindBugs point of view we can release BCEL6 as it is
> today on trunk.
>

Okay, so you would like to see an RC with the current state of trunk?!

Benedikt


>
> BTW, if you will, you can compare current BCEL 6 jar from trunk with the
> latest "FB BCEL patch" jar here:
> https://github.com/findbugsproject/findbugs/blob/master/findbugs/lib/bcel-6.0-SNAPSHOT.jar.
> I think Clirr should be able to do a diff here. Don't ask me from which
> revision this patched jar was created, I have no clue.
>
> This is the BCEL API state we "exported" to downstream since 3 years :-(
>
> Kind regards,
> Andrey Loskutov
>
> http://google.com/+AndreyLoskutov
>
>
> > Gesendet: Sonntag, 12. Juni 2016 um 14:12 Uhr
> > Von: sebb 
> > An: "Commons Developers List" 
> > Betreff: Re: [BCEL] Latest Clirr report
> >
> > On 12 June 2016 at 12:43, Benedikt Ritter  wrote:
> > > sebb  schrieb am So., 12. Juni 2016 um 13:38 Uhr:
> > >
> > >> On 12 June 2016 at 12:00, Benedikt Ritter  wrote:
> > >> > Hi,
> > >> >
> > >> > I've uploaded the verbose Clirr report to my space at
> home.apache.org
> > >> [1].
> > >> > Do we have to fix all of this in order to release 6.0?
> > >>
> > >> No, most of the changes don't break strict BC.
> > >>
> > >> The main changes to the interfaces don't break BC and are highly
> > >> unlikely to affect source because there are abstract implementation
> > >> classes.
> > >>
> > >> See the changes.xml file and release notes for some details.
> > >>
> > >
> > > Thank you, I will have a look. Can we compile a list of things we need
> to
> > > fix for 6.0?
> >
> > Unfortunately the lack of updates has caused downstream users to rely
> > on non-released code.
> > I think we should try and ensure that we don't make things worse.
> >
> > Therefore I don't think we can compile a full list without assistance
> > from FindBugs and other consumers of the code.
> >
> > I suspect this will be an iterative process to try and find the best
> > compromise that suits these users as well as users who have only used
> > formal releases.
> >
> > > Benedikt
> > >
> > >
> > >>
> > >> > Benedikt
> > >> >
> > >> > [1]
> > >> >
> > >>
> http://home.apache.org/~britter/commons/bcel/6.0-SNAPSHOT/clirr-report.html
> > >> >
> > >> > sebb  schrieb am Mi., 8. Juni 2016 um 11:54 Uhr:
> > >> >
> > >> >> 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 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
> > >> >> >>
> > >> >> >
> > >> >> > The report is the result of running mvn clean site. So if
> > >> quiten-clirr is
> > >> >> > activated by default it's the 'quitened' one (sorry I currently
> don't
> > >> >> have
> > >> >> > time to look into the pom).
> > >> >>
> > >> >> Yes, it is the default.
> > >> >>
> > >> >> > I can upload the "real" report to home.apache.org tonight when
> I'm at
> > >> >> home.
> > >> >>
> > >> >> OK, thanks.
> > >> >>
> > >> >> > Benedikt
> > >> >> >
> > >> >> >
> > >> >> >>
> > >> >> >> On 8 June 2016 at 09:35, Benedikt Ritter 
> wrote:
> > >> >> >> > 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
> > >> >> >>
> > >> >> >>
> ---

Re: [ALL] beware of URLs that represent file system locations

[Benedikt Ritter]

Well, I created the Jenkins Job, so we both hat our share ;-)

sebb  schrieb am Mo., 13. Juni 2016 um 16:03 Uhr:

> On 13 June 2016 at 12:43, Benedikt Ritter  wrote:
> > Thank you for bringing this up and for fixing the Problem!
>
> I probably caused it ...
>
> > sebb  schrieb am Mo., 13. Juni 2016 um 12:32:
> >
> >> A Commons NET test was failing on Jenkins, but worked fine locally.
> >> And previously had been working on Continuum.
> >>
> >> Turns out this was because Jenkins uses path names of the form
> >> .../commons-net@n/.
> >>
> >> The test code was using the following to get the source location:
> >>
> >> java.security.CodeSource.getLocation().getFile()
> >>
> >> The embedded '@' was returned encoded as %40.
> >>
> >> When used as a File parameter of course it did not work, so the test
> >> failed.
> >>
> >> Using java.net.URLDecoder.decode() on the file-part of the URL fixed
> this.
> >>
> >> There are no doubt other methods that return URLs that represent local
> >> file paths.
> >> Beware!
> >>
> >> -
> >> 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] Brining clirr to the ASF?

[Benedikt Ritter]

Gary Gregory  schrieb am Di., 14. Juni 2016 um
08:23 Uhr:

> On Mon, Jun 13, 2016 at 11:19 PM, Benedikt Ritter 
> wrote:
>
> > Hi,
> >
> > as Jochen has pointed out, Clirr seems to be unmaintained. However we
> build
> > a good part of our release strategy upon clirr. So I wonder whether we
> > should foster bringing clirr to the ASF (for example by going through
> > incubation). We're probably not the only ASF project using Clirr.
> >
>
> +1. Can we bring in code that's under GNU Lesser General Public and make it
> ASL 2?
>

That would be a task for incubation


>
> Could fit under a new Commons Build or Clirr component since it is a
> "common" build requirement.
>

Given the size of Clirr (base library + build tool plugins), I'd rather try
to instantiate a new TLP by going through incubation.


>
> Gary
>
>
> > Benedikt
> >
>
>
>
> --
> 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: [DISCUSS] Brining clirr to the ASF?

[Jochen Wiedmann]

On Tue, Jun 14, 2016 at 8:23 AM, Gary Gregory  wrote:

>> as Jochen has pointed out, Clirr seems to be unmaintained. However we build
>> a good part of our release strategy upon clirr. So I wonder whether we
>> should foster bringing clirr to the ASF (for example by going through
>> incubation). We're probably not the only ASF project using Clirr.
>>
>
> +1. Can we bring in code that's under GNU Lesser General Public and make it
> ASL 2?
>
> Could fit under a new Commons Build or Clirr component since it is a
> "common" build requirement.

As Clirr is internally based on BCEL, I'd rather see us build a new
tool on top of ASM, which is very well maintained. Besides, that would
solve the license problem.

Jochen


-- 
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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

Re: Re: [BCEL] Latest Clirr report

[Jochen Wiedmann]

On Tue, Jun 14, 2016 at 8:24 AM, Benedikt Ritter  wrote:
> Andrey Loskutov  schrieb am Mo., 13. Juni 2016 um
> 14:15 Uhr:

> Okay, so you would like to see an RC with the current state of trunk?!

+1

Jochen



-- 
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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

Re: Re: Re: [BCEL] Latest Clirr report

[Andrey Loskutov]

> From: "Benedikt Ritter" 
> To: "Commons Developers List" 
> Subject: Re: Re: [BCEL] Latest Clirr report
> > So from my limited FindBugs point of view we can release BCEL6 as it is
> > today on trunk.
> >
> 
> Okay, so you would like to see an RC with the current state of trunk?!

Sure. Sooner is better, just to finish this impossible "10 years without 
release" state.
I hope to get some time to verify if FindBugs run with with RC over the 
weekend. 

Regards,
Andrey

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

[BCEL] Release Candidate on Thursday

[Benedikt Ritter]

Hi,

I'm going to try to create an RC for BCEL 6.0 on friday. Please have a look
at the current state of the code base and report any issues you see.

Thank you!
Benedikt

Re: [DISCUSS] Brining clirr to the ASF?

[Benedikt Ritter]

Jochen Wiedmann  schrieb am Di., 14. Juni 2016
um 08:40 Uhr:

> On Tue, Jun 14, 2016 at 8:23 AM, Gary Gregory 
> wrote:
>
> >> as Jochen has pointed out, Clirr seems to be unmaintained. However we
> build
> >> a good part of our release strategy upon clirr. So I wonder whether we
> >> should foster bringing clirr to the ASF (for example by going through
> >> incubation). We're probably not the only ASF project using Clirr.
> >>
> >
> > +1. Can we bring in code that's under GNU Lesser General Public and make
> it
> > ASL 2?
> >
> > Could fit under a new Commons Build or Clirr component since it is a
> > "common" build requirement.
>
> As Clirr is internally based on BCEL, I'd rather see us build a new
> tool on top of ASM, which is very well maintained. Besides, that would
> solve the license problem.
>

Sounds like a massive endeavor. Are you sure we could build that in a
reasonable amount of time?


>
> Jochen
>
>
> --
> The next time you hear: "Don't reinvent the wheel!"
>
>
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [DISCUSS] Brining clirr to the ASF?

[Jochen Wiedmann]

On Tue, Jun 14, 2016 at 8:50 AM, Benedikt Ritter  wrote:
> Jochen Wiedmann  schrieb am Di., 14. Juni 2016

>> As Clirr is internally based on BCEL, I'd rather see us build a new
>> tool on top of ASM, which is very well maintained. Besides, that would
>> solve the license problem.
>>
>
> Sounds like a massive endeavor. Are you sure we could build that in a
> reasonable amount of time?

No. But I am quite certain, that we could maintain that, rather than
having digged a new grave for the same corpse.

Jochen


-- 
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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

Re: [VOTE] Move Commons Math to TLP (again)...

[Jörg Schaible]

Stian Soiland-Reyes wrote:

> +1 for a move to Incubator, rather than a TLP, as Math now needs to
> find its new ground and direction, and in particular grow its active
> developer base.
> 
> 
> The incubator is great for reducing the distance for moving from
> contributor to committer, and for letting everyone get a say in what
> direction you are moving. The role of the incubator mentors is to help
> you build the community, and while it's not always fun to get reminded
> about what is missing here, the process of the incubator forces the
> community focus (who are we) and not just code focus (what does it
> do).
> 
> Obviously you can do that straight as a TLP as well, but I think given
> the fork happened, Math needs to grow more slowly back into shape, and
> the Incubator should be good for that.
> 
> I agree on trying to write an Incubator proposal and start discussing
> it on general@incubator.

+1 (binding)

for the same reasons.

- Jörg


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