Re: [VOTE] Release Apache Commons Daemon 1.2.0 RC2

[Stian Soiland-Reyes]

My vote: +1 (binding)

Verified:
  +1 sha512 sha256
  +1 asc / KEYS
  +1 src zip vs tar.gz
  +1 bin zip vs tar.gz vs jar
  +1 src vs git  (missing in src: README.md CONTRIBUTING.md; 
 whitespace differences in commons-daemon-1.2.0-native-src)
  +1 mvn repo vs dist
  +1 mvn apache-rat:check
  +1 No unexpected binaries in src (bmp, rtf, ico)
  +1 LICENSE NOTICE
  +0 GPL code in src/native/unix/support/config.*
 (permitted w/ autoconf exception)
  +1 mvn clean install
  -1 commons-daemon-1.2.0-native-src/unix/INSTALL.txt outdated
  +1 ./configure ; make  (tested just ./jsvc --help )


Tested with Ubuntu 18.04 TLS

$ mvn -v
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
2018-10-24T19:41:47+01:00)
Maven home: /home/stain/software/maven
Java version: 11.0.3, vendor: Oracle Corporation, runtime: 
/usr/lib/jvm/java-11-openjdk-amd64
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-52-generic", arch: "amd64", family: "unix"

I did not test building or running the Windows part.


commons-daemon-1.2.0-native-src/unix is outdated as it claims you only
need to run "sh support/buildconf.sh" if building from SVN. We are using
git, and I still had to run it when building from dist/sources




On Fri, 28 Jun 2019 15:20:56 +0100, Mark Thomas  wrote:
> It has been ~18 months since the last Commons Daemon release. After the
> recent flurry of activity and a couple of failed RCs, it is time for
> another release vote.
> 
> Notable changes since 1.1.0 include:
> - Improved JRE/JDK detection to support increased range of both JVM
>   versions and vendors.
> - Procrun. Minimum target platform for Windows binaries is now Windows 7
> - Procrun. Change the default service from LocalSystem to
>   'NT Authority\LocalService'
> 
> The full set of changes is in the changelog
> 
> 1.2.0 RC2 can be obtained from (r34680):
> https://dist.apache.org/repos/dist/dev/commons/daemon/
> 
> The git tag is:
> Tag: COMMONS_DAEMON_1_2_0_RC2
> URL:
> https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=d88fd9100c1110fa51b7c7a08e3e7efd0e58227b
> Hash:  d88fd9100c1110fa51b7c7a08e3e7efd0e58227b
> 
> The Maven Staging repo is:
> https://repository.apache.org/content/repositories/orgapachecommons-1443/
> 
> The Windows binaries have been signed by the Symantec code signing service.
> 
> Files signed with my preferred key:
> http://people.apache.org/~markt/
> KEYS file is standard Apache Commons keys file:
> http://www.apache.org/dist/commons/KEYS
> 
> 
> [ ] Approved - go ahead and release Commons Daemon 1.2.0 RC2 as 1.2.0
> [ ] Broken   - do not release because...
> 
> -
> 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: New Sub-project Proposal.

[Stian Soiland-Reyes]

On Wed, 11 Sep 2019 18:12:24 +0200, Gilles Sadowski  
wrote:
> > The long and short of this is that there is no good unencumbered open
> > source library available at the current time.  Myself and several others,
> > in conversation here at ApacheCon, have expressed interest in creating such
> > a library.  We have fairly mature code that we are willing to contribute
> > along with code that embodies new thinking in the bloom filter arena (like
> > proto-bloom filters).  We just need a space within the Apache family to
> > host it.  The code base seems to small to be a separate project and so we
> > come to Apache Commons seeking a home.
> 
> IMO, a pretty compelling rationale for hosting it at "Commons".
> If people think that [Collections] would be the best home, I'd suggest
> making that component modular; hence unnecessary dependencies
> would be a non-issue.

Thanks Claude for that brilliant explanation about bloom filter! 
(please blog it!)

At the moment Commons Collections have no runtime dependencies, and only
3 test-dependencies. 
<https://github.com/apache/commons-collections/blob/master/pom.xml#L443>

So unless the Bloom filter code comes with any new depdendencies seen to
"bloat" rest of Commons, it could fit well in there. 

It would be a new package "bloom" as it's something to use for building
collections rather than directly being a collection - but Collections
already have similar packages for balanced trees, etc.


Looking at the code which I suspect is 
<https://github.com/Claudenw/BloomFilter/tree/master/src/main/java/org/xenei/bloomfilter>
it looks pretty clean, independent and straight forward to read and understand. 

>From Claude's email I see it is it's *use* that needs explanation!

The only dependencies in that code seem to be within the 
org.xenei.bloomfilter.collections package which currently include use of
Jena's extended iterator classes.

This could probably be refactored, if this package is also to be
included? (those classes would also fit naturally into Collections)


-- 
Stian Soiland-Reyes
The University of Manchester 🐝
https://www.esciencelab.org.uk/
https://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: New Sub-project Proposal.

[Stian Soiland-Reyes]

I certainly got thinking about streams for those methods using the ancy
integrators yes. Commons Collection is already on JDK8, so if that is
sufficient, go for it!

We would need to do IP clearance to bring in the code formally to ASF. It
should be easy if it is just you who made it under Apache license.

On Wed, 11 Sep 2019, 18:44 Claude Warren,  wrote:

> @stain. You have correctly identified the code in my repository.  The code
> could be refactored to use streams or we could bring the jena iterator
> extensions into commons.  I had suggested that at one time but there were
> concerns about conflicts with existing code.  Duplication with of
> functionality was the main concern as I recall.
>
> Claude
>
> On Wed, Sep 11, 2019, 09:43 Stian Soiland-Reyes  wrote:
>
> > On Wed, 11 Sep 2019 18:12:24 +0200, Gilles Sadowski <
> gillese...@gmail.com>
> > wrote:
> > > > The long and short of this is that there is no good unencumbered open
> > > > source library available at the current time.  Myself and several
> > others,
> > > > in conversation here at ApacheCon, have expressed interest in
> creating
> > such
> > > > a library.  We have fairly mature code that we are willing to
> > contribute
> > > > along with code that embodies new thinking in the bloom filter arena
> > (like
> > > > proto-bloom filters).  We just need a space within the Apache family
> to
> > > > host it.  The code base seems to small to be a separate project and
> so
> > we
> > > > come to Apache Commons seeking a home.
> > >
> > > IMO, a pretty compelling rationale for hosting it at "Commons".
> > > If people think that [Collections] would be the best home, I'd suggest
> > > making that component modular; hence unnecessary dependencies
> > > would be a non-issue.
> >
> > Thanks Claude for that brilliant explanation about bloom filter!
> > (please blog it!)
> >
> > At the moment Commons Collections have no runtime dependencies, and only
> > 3 test-dependencies.
> > <https://github.com/apache/commons-collections/blob/master/pom.xml#L443>
> >
> > So unless the Bloom filter code comes with any new depdendencies seen to
> > "bloat" rest of Commons, it could fit well in there.
> >
> > It would be a new package "bloom" as it's something to use for building
> > collections rather than directly being a collection - but Collections
> > already have similar packages for balanced trees, etc.
> >
> >
> > Looking at the code which I suspect is
> > <
> >
> https://github.com/Claudenw/BloomFilter/tree/master/src/main/java/org/xenei/bloomfilter
> > >
> > it looks pretty clean, independent and straight forward to read and
> > understand.
> >
> > From Claude's email I see it is it's *use* that needs explanation!
> >
> > The only dependencies in that code seem to be within the
> > org.xenei.bloomfilter.collections package which currently include use of
> > Jena's extended iterator classes.
> >
> > This could probably be refactored, if this package is also to be
> > included? (those classes would also fit naturally into Collections)
> >
> >
> > --
> > Stian Soiland-Reyes
> > The University of Manchester 🐝
> > https://www.esciencelab.org.uk/
> > https://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: New Sub-project Proposal.

[Stian Soiland-Reyes]

On Thu, 12 Sep 2019 08:06:59 +0100, Claude Warren  wrote:
> Actually the code I was thinking of is the multi-filter branch.  It cleans
> up some names and simplifies a few things.  The collections and storage
> packages might be best added as examples rather than as mainline code.
> 
> In this case we just provide the bloom filter implementation,  If we want
> to provide the container implementation then I think it should probably be
> modified to accept any SortedSet or NavigatableSet in the constructor.
> 
> When I return home, next week, I'll take a swipe at moving the packages
> over to org.apache.commons.collections4.bloomfilter package (unless there
> is a better package name).  We can then look at the entire code donation
> and decide what changes need to be made before it is accepted.
> 
> Does this sound like a reasonable approach?

Sounds reasonable to me - then it's easy to see what will be the code
donation, they could be examples at first that we can link to from
documentation, several commons packages have such example codes.


Perhaps use packagename "commons.collections4.bloomfilter" without
org.apache before it's been IP-cleared? Alternatively add it on a fork
of https://github.com/apache/commons-collections/ so we don't confuse
anyone.


I see on your branch you are using some new dependencies like 
org.xenei.blockstorage and org.xenei.spanbuffer.SpanBuffer - would these
be needed as well if we include the container implementation or are they
more for disk-based collections?

-- 
Stian Soiland-Reyes
https://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: [VOTE] Release Apache Commons BCEL 6.4.0 based on RC2

[Stian Soiland-Reyes]

Gary, thanks for putting together an RC and the thorough description on
how to verify releases! (perhaps some got scared.. we don't need
everyone to test everything though!)

My vote is: +1 (binding)


Checked:

[+] checksums vs *.sha512 vs VOTE email vs maven repo
[+] git tag vs commit
[*] git vs source  (whitespace differences; README.md and CONTRIBUTING.md 
missing)
[+] .asc pgp signatures
[+] .zip vs .tar.gz
[+] mvn clean install
[+] built target vs binary (all *jar files built, same filenames content)
[+] binary vs maven repo
[+] *.class correct Java class data, version 52.0 (Java 1.8)
[+] source vs -sources.jar
[*] mvn apache-rat:rat  (autogenerated Mini.jj missing ASF header)
[+] LICENSE, NOTICE
[+] RELEASE-NOTES.txt
[+] site
[+] site reports: japicmp (correctly identifies minor version change)
[-] README

README is missing from download, so downstream won't easily know how to
build it with mvn, but I won't block the release over that; just
"mvn" kind of works with the defaultGoal (but needs JAVA_HOME?)

mvn site took quite a long time as it downloads the world (and I am on
hotel WiFi)

Not sure why maven-site-plugin can't invoke javadoc without JAVA_HOME as it's 
on the PATH

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.8.2:site (default-site) on
project bcel: Error generating maven-javadoc-plugin:3.1.1:javadoc
report: Unable to find javadoc command: The environment variable
JAVA_HOME is not correctly set. -> [Help 1]


(base) stain@biggie:/tmp/RC2/6.4.0-RC2/source/1/bcel-6.4.0-src$ javadoc 
--version
javadoc 11.0.4


export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64/
fixes the above


I however get this error from mvn site, which does not block build:

[INFO] Generating "JIRA Report" report   --- 
maven-changes-plugin:2.12.1:jira-report
[WARNING]
java.lang.NullPointerException
at org.apache.maven.plugin.jira.RestJiraDownloader.processPriority 
(RestJiraDownloader.java:392)




Tested with:

(base) stain@biggie:~$ mvn -v
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
2018-10-24T11:41:47-07:00)
Maven home: /home/stain/software/maven
Java version: 11.0.4, vendor: Ubuntu, runtime: 
/usr/lib/jvm/java-11-openjdk-amd64
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-64-generic", arch: "amd64", family: "unix"

(base) stain@biggie:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 18.04.3 LTS
Release:18.04
Codename:   bionic


On Fri, 20 Sep 2019 15:44:54 -0400, Gary Gregory  wrote:
> We have fixed quite a few bugs and added some enhancements since Apache
> Commons BCEL 6.3.1 was released, so I would like to release Apache Commons
> BCEL 6.4.0.
> 
> Apache Commons BCEL 6.4.0 RC2 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.4.0-RC2 (svn
> revision 35956)
> 
> The Git tag commons-bcel-6.4.0-RC2 commit for this RC is
> bbaf623d750f030d186ed026dc201995145c63ec which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-bcel.git;a=commit;h=bbaf623d750f030d186ed026dc201995145c63ec
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-bcel.git --branch
> commons-bcel-6.4.0-RC2 commons-bcel-6.4.0-RC2
> 
> Maven artifacts are here:
> https://repository.apache.org/content/repositories/orgapachecommons-1470
> 
> These are the artifacts and their hashes:
> 
> #Release SHA-512s
> #Fri Sep 20 15:18:20 EDT 2019
> bcel-6.4.0-bin.tar.gz=adb0907fb538a7c1a6eeb9cffde9769cdc49690e1d74f71b00a1bb59f15fe8ed724199cfb2c53c4416936f38bfb2b1c9b6b82662198449bba3dc66f1ea66bf89
> bcel-6.4.0-bin.zip=63e4ab394f517803a823945a9772933ce6e13edcbb4e1453e852b7f769f8dd0289926dc16678e7a2fe3f01f6141fbf1cc2bdd4372127a1ce5292e04347095201
> bcel-6.4.0-javadoc.jar=d34064830c51747dacc0ddc321da365e37fe754bb145fb9d00a309e9865c43318d427c0bdc775f125e3686531998666ba247b113a88148b05c634ca9e40a
> bcel-6.4.0-sources.jar=f9de34aa59768dcb0b4aaf7c0ffc833302e77e4e01db85816553530d4ba1a6f87778b02bcbc9097fa699069ce85c3d372ec860002dd4c39d9e7093dd31d7771b
> bcel-6.4.0-src.tar.gz=998c0b4669739b449d918c2c41d83bdd682375f98ca646fba982d53a4216badb67e4200e945cc4958fe481bcc9a48e1635c7e15a3cb6accd5c27d326289f8b22
> bcel-6.4.0-src.zip=7488601f243b1e31644002358ee50889c1dc1dfdc5c19c4c6cda04270cc47ac6b4495e733065bc451b40bcc3bae2130d56314d7bedb3b99fbb5b7b5658c48912
> bcel-6.4.0-test-sources.jar=2cfcca5c63986a46952d83df2544e510e6464991a2506d48c2797fdf183df0353fa18c81f25c0e97bf5ddd293a0bab663069e726f727157a9366bf08366f380b
> bcel-6.4.0-tests.jar=b2f8f00bd523f36227e2978218ebf8a6d9538288eaa7e9fbabb0609e444f133f2e39fb3d14c4ea7ad3ab09cd61784cea546455ec6b0c88928bff381fffb14fba
> 
> I have tested this with
> 
> mvn -V -Duser.name=%my_apache_id%
> -Dcommons.release-plugin.version=1.7-SNAPSHOT -Ddoclint=none -Prelease
> -Ptest-deploy clean package site deploy
> 
> using:
> 
> Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
> 201

Re: [ALL] Too much traffic on the "dev" ML

[Stian Soiland-Reyes]

While I am part of the [RDF] community - I would be careful about
sub-lists with "too few people" (e.g. <3).

As you said, voting on releases (and other PMC-level votes) should be
kept on the all-dev - formally then the sublist should not be a worry
- you wouldn't make a mailing list for two people anyway. Commits and
issues should definitely be on the sub-lists, if they exists - as they
would be part of the overall noise for everyone else.


It would be a relief to the [RDF] community, a separate mailing list
(e.g. r...@commons.apache.org) would make it much more accessible to
invite non-committer third-parties who are involved just with
Commons-RDF during its design phase.


There's a danger of small & fresh sandbox communities ending up in a
fragmenting "mini incubator" (without the usual checks and balances)
if they start straight off in separate mailing lists. I would assume
only established sub-communities would go straight to a sub-mailing
list.

Some older/stable commons-* things might not benefit have a dead
mailing list with 3 people - it's better emails from a user of
commons-semiabandoned get picked up in general list (hoping for a
volunteer) - so I guess this would be up for each sub-community to do
a [$project][VOTE] to see if they want their own sub-list. +3 should
be sufficient.


Perhaps forwarding this thread to the general@incubator list would be
appropriate - there we are currently discussing the possibility of
fresh projects bypassing the incubator process and become a
"probationary" TLP reporting directly to the board, and rather require
3 active mentors (with experience from "proper" PMCs) on the new PMC:

https://wiki.apache.org/incubator/IncubatorV2 (whenever the wiki is online)
http://mail-archives.apache.org/mod_mbox/incubator-general/201501.mbox/%3CCALhtWkcPptYsE%2BrpF42z75zNU%3DHKbcom7XC%3DU4LqmD_grWQg3Q%40mail.gmail.com%3E


Incoming Apache-majority communities like [RDF] and established,
active commons-* modules would probably fulfil that requirement
directly. The proposals have not mentioned what is the plan for
non-TLP podlings.

On 16 January 2015 at 00:47, Gilles  wrote:
> Hi.
>
> In the discussion that started about RDF, it seems that the
> traffic volume is a stumbling block.
> [For some time now, it has been a growing nuisance, and the
> usual dismissal about filters won't change the fact: Setting
> up a filter that will redirect stuff to /dev/null is a waste
> of bandwidth.]
>
> If different ML are created, people interested in everything
> can subscribe _once_, and nothing will change for them.
> For people who spend a lot of time just deleting dozens messages
> and notifications a day, it will be a relief.
>
> Maintaining community conversation is not a problem: just
> create an "all-...@commons.apache.org" ML for things that
> need input form a larger audience (like votes).
>
>
> Best regards,
> Gilles
>
>
> ---------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>



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

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

Re: [ALL][RDF] github Commons RDF vs. Apache Commons Sandbox RDF

[Stian Soiland-Reyes]

On 15 Jan 2015 11:06, "Sergio Fernández"  wrote:

> Therefore my proposal for Commons RDF is the following:
>
> * Commons RDF proposes an API that addresses portability issues. I'd
recommend to start form what we currently have at github which was actually
designed by committee and both Jena and Sesame already started to implement.
> * We evolve the current design in the context of Apache Commons Sandbox
> * We keep separated the API from the implementations:
> * We keep clear the point that the major established RDF Toolkits (Apache
Jena and OpenRDF Sesame) are the recommended implementations
> * We make an open call for contributing basic implementations to the
project. We can adopt the one provided by Stian, and also work with Reto to
move the Clerezza-based implementation (aka Apache Commons Sandbox RDF) to
that API (what seems to be what he is willing to do anyway). The feedback
from those implementations would be consider for evolving the API.

+1 to all the above.

>
> We can easily organize in different Maven artifacts if we all agree on
this setup.

+1 - I can have a first go at this if you want, including Reto's module.

> I just want to ask about the option of having a dedicated dev mailing
list, keeping the general style for announcements or things relevant for
the whole project

Just rdf@commons should do? Its both a topic and a component.

Re: [ALL][RDF] github Commons RDF vs. Apache Commons Sandbox RDF

[Stian Soiland-Reyes]

On 18 January 2015 at 12:07, Benedikt Ritter  wrote:
> There is a infra hook that can forward any comments on github issues to
> jira issues. I think this would be sufficient. Github mirrors are read
> only, so you will have to live with the manual merge approach...

Agreed - the infra-hook from github pull requests to mailing list
works fairly well for Apache Jena already to create focused and
tracked threads  - see examples at
https://github.com/apache/jena/pulls

.. if this can be extended with a Jira integration, just the better!


>> * Having it okay that the commons rdf api is a project that
>> principally aims to create a set of interfaces, and not host any of
>> the scalable implementations of the API. Stian Soiland-Reyes has
>> written a basic implementation, but in practice, any large dataset
>> will not load into that implementation and be queried efficiently, so
>> it is only going to be used for small in-memory tasks.
> This is something you guys have to figure out :-)

Yes, religious/academic discussions can have a better home on a new
mailing list and larger sub-community - I hope those on the
dev@commons list who just became interested would not mind joining a
new list - whatever its name might be.


> To sum this up: All that is blocking github commons rdf to join Apache
> Commons is the mailing list thing?

I believe that sums it up!

The IP Clearance should be a small formality.

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

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

Re: [DISCUSS][RDF] Separate mailing list for Commons RDF

[Stian Soiland-Reyes]

>> >>
>> >> I'm understanding that the Apache policy forbids something (fine,
>> >> that's not the point).
>> >> Yet "Commons" is an umbrella (not what Apache calls an umbrella,
>> >> OK, since by policy that umbrella connat exist...) that groups
>> >> unrelated bits of code.
>> >>
>> >>> That is why
>> >>> Jakarta was broken up.  That is also why Hadoop is not one great big
>> >>> umbrella.  When sub-things get large enough, they become separate
>> >>> projects.  HttpComponents is actually a good example.  That used to
>> >>> be part of Commons.
>> >>
>> >> Is "large enough" the only criterion?  What is "large enough"?
>> >
>> > If the people caring for one component think they are better off with an
>> own
>> > Apache community i.e. they make "their" component a TLP.
>> >
>> >>
>> >> Obviously, the policy forbidding some things (like a manageable
>> >> ML traffic) is causing problems to some would-be contributors.
>> >>
>> >> Rdf-commons would seem a "little" project (in terms of code, IIUC),
>> >> a fine fit for a place like "Commons"; yet they are forced out
>> >> because of a side issue.  A loss for them, and a loss for "Commons".
>> >> Does that make sense?
>> >
>> > Yes, the shared resources are part of the Apache Commons community. It
>> was
>> > especially built to increase the responsibility of all committers for all
>> > components. Jakarta had a long history of died subprojects, because
>> nobody
>> > even recognized the death of it. Vfs as separate project would have been
>> in
>> > the attic long ago. Not in commons because there are always some people
>> who
>> > care enough at least to maintain it. And suddenly such a component can
>> > gather new activity.
>> >
>> > What do you expect from a rdf component implementing the API only? You
>> will
>> > see for the first weeks some increased activity and then it decreases.
>> And
>> > that's obviously a good thing for a component that offers only a stable
>> > contract. The devs will concentrate on their individual implementation in
>> > the long run.
>>
>> Some initial discussion has been done on GitHub already but the rest
>> will be drawn out slightly by the implementation stages which will be
>> outside of commons.
>>
>> The two reasons that I recall for bringing the issue up are that
>> contributors who want to follow the progress of the discussion but not
>> contribute don't want to commit to filtering messages and going
>> through the unsubscribe/subscribe process if they want to leave the
>> discussion temporarily (yes, if you know how its quite easy but its a
>> big deal for some), and the other reason was that we don't want to
>> push our traffic onto everyone who isn't familiar with RDF and isn't
>> interested in the fine technical aspects of finalising the API. There
>> are some general computing issues to deal with as always, particularly
>> given that Java-8 is so new and patterns haven't been widely
>> understood yet, but the vast majority will be wrangling an API to sit
>> on top of our respective codebases and provide interoperability. The
>> only way we have found to do that so far has been to use the W3C
>> RDF-1.1 specification as the arbiter, which should be okay, but there
>> is a lot of back and forth discussion about it on fine grained issues.
>>
>
> We don't have a problem with the RDF traffic. That's just the way things
> work here. I understand your worries about potential contributors who might
> be put off by communication via mailing lists. To me mailing lists feel
> dated. That's why I brought up this discussion [1] on
> d...@community.apache.org. HyperKitty may be an alternative (see
> https://lists.stg.fedoraproject.org/archives/ for a demo) but it is not yet
> available.
>
>
>>
>> The tendency so far has been, since some of us are not paid
>> specifically to work on the relevant code, that once pull requests are
>> suggested, the discussion gets going for a few days and then falls
>> off. And eventually, once the API is stable it will fall off
>> altogether to almost zero. That last reason is the main reason for why
>> a TLP will not suit us, as TLP are encouraged to stay active and
>> develop new features for their libraries or get shutdown. It is also
>> why commons would be useful to us, but we are a little worried about
>> having to have users subscribe to a high-traffic mailing list to
>> discuss the API.
>>
>
>> All of those concerns are dealt with by the opt-in nature of
>> GitHub/etc. issues/pull requests, where you can specifically watch a
>> given discussion; watch an entire repository for as long as necessary;
>> or switch from watching to just star a repository for future
>> reference, but not watch it, and hence not get notifications about it.
>>
>> One option may be that if the process for having GitHub issues send
>> notifications to the mailing list is working fairly well could we have
>> the majority of our casual contributors watch a repository there to
>> interact with pull requests and the core contributors subscribe to
>> this mailing list. I gather that we would need to use Apache Jira for
>> issues instead of GitHub issues. Is it possible to watch an entire
>> project in Jira and get notifications about all discussion for a
>> period of time or is the Apache Jira setup to not send that level of
>> notifications (only infrequently administered Jira and I realise that
>> they are all setup differently so just clarifying that).
>>
>
> We already work this way with some of our github contributors. We have a
> standard template for README.md and CONTRIBUTING.md that should give github
> contributors all the necessary information they need. See for example the
> lang github mirror [2].
>
> Regards,
> Benedikt
>
> [1] http://markmail.org/message/exxaqmo4hsxa2d3x
> [2] http://github.com/apache/commons-lang
>
>
>>
>> Cheers,
>>
>> Peter
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter



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

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

Re: [DISCUSS][RDF] Separate mailing list for Commons RDF

[Stian Soiland-Reyes]

Agree that maybe the the Incubator with a projected path to the
Commons could be a workable middle ground while Commons-RDF is still
"incubating" code-wise (but not community or Apache Way-wise).

No earlier project has gone through this route
(https://incubator.apache.org/projects/ ) - this would reuse the
deprecated "Champion" project to be Apache Commons instead of
Incubator PMC in this case.

Such a proposal has some good features - I presume commons-rdf
releases would still be voted over (and thus involve) the Commons PMC
and dev@commons  (as they would after "graduating").

As an API, then Commons-RDF should not be considered stable while
being in 0.x.x-incubating anyway.



On 20 January 2015 at 13:58, Torsten Curdt  wrote:
>>  There are several ASF projects in the
>> RDF space.  They have been through the incubator.  Please do talk to those
>> projects if you have concerns.
>
> I am sorry - but how are those projects relevant in this case?
>
> And what's so bad about the incubator? You could (maybe) later on come
> to Commons.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

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

Re: [DISCUSS][RDF] Separate mailing list for Commons RDF

[Stian Soiland-Reyes]

It might be my fault for misrepresenting "The Commons-RDF community" -
personally I am fairly fresh to the Apache (Oct 2014). The other, core
committers involved in Commons-RDF are seasoned Apache folks. I've
just tried to be a mediator.. My fault.


I think the community around commons-rdf is already strong and diverse
- if small.

How to smoothly transition that community into dev@commons is the
challenge.  themselves with dev@commons.

I don't think the existing dev@commons community would have any
problem with the RDF activity - several have welcomed it and shown
interest in helping out.

But what about the other way around? It is the existing (partially
non-Apache) community that we need feedback from to shape the API -
but which several are worried would be scared about being thrown right
into dev@commons, which I hope you can see is a different, bigger
community than that of a "regular" TLP - given the small size of the
project.

I don't believe the "core committers" would have any problems with
dev@commons - the problem is the bigger community (the users@rdf in a
way) which we need to help shape what the API should and shouldn't do.


On 20 January 2015 at 14:17, Torsten Curdt  wrote:
>> Agree that maybe the the Incubator with a projected path to the
>> Commons could be a workable middle ground while Commons-RDF is still
>> "incubating" code-wise (but not community or Apache Way-wise).
>
> To me it comes across as if community/ASF wise is the more important
> part. This is really not meant as an offense, but if you re-read this
> thread you will see that the community part hasn't been going so well
> yet.
>
> cheers,
> Torsten
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>



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

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

Re: [RDF] Local Scope and BlankNode internalIdentifier (was: github Commons RDF vs. Apache Commons Sandbox RDF)

[Stian Soiland-Reyes]

gt; * In particular, the existence of two objects of type {@link BlankNode}  *
> with the same value returned from {@link #internalIdentifier()} are not  *
> equivalent unless they are known to have been created in the same local  *
> scope.
> It is however not so clear what such a local scope is. It says that such a
> local scope may be for example a JVM instance.  Can the scope also be
> narrower? To allow removing redundancies (as described in
> https://svn.apache.org/repos/asf/commons/sandbox/rdf/trunk/README.md) no
> promise should be made that a bnode with the same ID in the same JVM will
> denote the same node. On the other hand, how long is it guaranteed thath if
> I have a BNode objects I can add triples to a graph and this object will
> keep representing the same RDF Node? Does it make a difference if I keep
> the instance or is I create a new instance with the same internal
> identifier?
>
> Similarly: can I add bnodes I get form one graph form one implementation to
> another? If I get BNode :foo from G1 can I add the triple (:foo ex:p ex:o)
> it to G2? When later or I will add (:foo ex:q ex:r) to G2 will the two
> triples have the same subject?
>
> I think these are important questions to allow generic interoperable
> implementations. I'm not saying that questions like the one I answer in the
> Readme of my draft cannot be satisfactory answered when having such an
> internal identifier, but I think it might get more complicated and less
> intuitive for the user.
>
> Also, you're writing about "opening up" the labels. This make sense from a
> triple store perspective where the BNode have such an internal label.
> However I think this should not be the only usecase scenario. One can very
> well use the RDF API to expose some arbitrary java (data) objects as RDF.
> I've illustrated such a scenario here:
>
> http://mail-archives.apache.org/mod_mbox/stanbol-dev/201211.mbox/%3CCALvhUEUfOd-mLBh-=xkwblajhbcboe963hdxv6g0jhnpj6c...@mail.gmail.com%3E
>
> I'm not sure if with the github API one could say "the scope is the node
> instance" and return a fixed identifier for all BNode. If so the identifier
> is obviously pointless. If on the other hand one would have to assign
> identifier to all the objects the complexity of the implementation this
> would make implementations more complex both in terms of code as in terms
> of memory usage.
>
> Again, it seems to make things more complex while I see no clear advantage
> comparing with the toString() method the object has anyway.
>
> Cheers,
> Reto

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

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

Re: [ALL] [RDF] Commons RDF approach

[Stian Soiland-Reyes]

I hope you would still feel welcome to become an unofficial mentor
(teaching us the "Apache Commons way" perhaps) even if you haven't got the
right badges (yet). :)

Other incubator projects have also had unofficial mentors - it's a good way
into Incubator PMC.

On 29 Jan 2015 14:29, "Benedikt Ritter"  wrote:

> Hello Sergio,
>
> 2015-01-29 14:44 GMT+01:00 Sergio Fernández :
>
> > Hi Benedikt,
> >
> > On 29/01/15 13:01, Benedikt Ritter wrote:
> >
> >> 2015-01-28 17:22 GMT+01:00 Sergio Fernández :
> >>
> >>> I'd like to have a Champion who is also part of the Commons
> >>> PMC, any volunteer?
> >>>
> >>
> >> I've thought about getting involved in incubator several times. Sounds
> >> like
> >> this is my chance :-)
> >>
> >
> > Thanks for proposing yourself! :-)
> >
> > I guess for that we'd need someone who is both Incubator PMC member and
> > ASF member. The fist would be easy to get, if you are interested I can
> > nominate you. But the second role is a bit more difficult... You can fin
> > further details at:
> >
> > http://incubator.apache.org/incubation/Roles_and_
> > Responsibilities.html#Champion
>
>
> I've already looked into that. I'm neither member of the ASF, not member of
> the incubator PMC. I think that this section applies:
>
> "Where the Champion is not a Member of the Foundation (i.e. is an Officer
> only), the Champion shall be a member of the PMC of the Sponsor."
>
> Since the sponsor will be the incubator project, I would have to be at
> least member of the PMC of the incubator project to be a champion.
> Recalling the responsibilities of PMC members [1], I don't think that at
> this point I have any oversight over the incubator project. So I don't
> think I'm a good candidate for the incubator PMC.
> So maybe it's better if someone else steps up (we have people here who meet
> the necessary requirements), and I will just join the incubator commons rdf
> community and help you that way.
>
> Benedikt
>
> [1] http://www.apache.org/foundation/how-it-works.html#roles
>
>
> >
> >
> > Cheers,
> >
> > --
> > Sergio Fernández
> > Partner Technology Manager
> > Redlink GmbH
> > m: +43 660 2747 925
> > e: sergio.fernan...@redlink.co
> > w: http://redlink.co
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>

Re: [ALL] [RDF] Commons RDF incubation proposal

[Stian Soiland-Reyes]

For your convenience. the proposal text is:

= Apache Commons RDF incubation proposal =

<>

== Status ==

Draft

== Abstract ==

Commons RDF is a set of interfaces for the RDF 1.1 concepts that can
be used to expose common RDF-1.1 concepts using common Java
interfaces.

== Proposal ==

The main motivation behind this simple library is revise an historical
incompatibility issue. This library does not pretend to be a generic
api wrapping those libraries, but a set of interfaces for the RDF 1.1
concepts that can be used to expose common RDF-1.1 concepts using
common Java interfaces. In the initial phase commons-rdf is focused on
a subset of the core concepts defined by RDF-1.1 (URI/IRI, Blank Node,
Literal, Triple, and Graph). In particular, commons RDF aims to
provide a type-safe, non-general API that covers RDF 1.1. In a future
phase we may define interfaces for Datasets and Quads.

The goal is to provide a compact API that could be implemented by the
upcoming versions of the main Java toolkits (Apache Jena 3.0 and
OpenRDF Sesame 4.0) as well as for other libraries (OWLAPI) and other
JVM languages (Banana RDF and so on).


In addition, the project could provide some simple implementations
suitable for some basic scenarios. But the major and established Java
toolkits will always remain the recommend implementations to use.

== Background ==

In the Java world there has been historically an incompatibility issue
between the two major RDF toolkits: Apache Jena and OpenRDF Sesame.
Many libraries have tried to wrap them, but besides technical
considerations, they normally end up being unmaintained.

Together, we came up with the idea of Commons RDF for solving the
incompatibility problem. The community has been in healthy development
at Github, including participants from the major Java RDF toolkits.

The natural path to Apache Commons Sandbox has been studied, but we
think that in this phase of the project, which focuses on the API
design and actively involves the developers of existing toolkits, it
is better to have a more focused community and infrastructure. Rather
than a new Top-Level Project, the goal is still to graduate as part of
Apache Commons, that is when API has achieve the required maturity and
the project goes into maintenance mode.

Part of the motivation for doing the incubator process would therefore
be to bring together the existing Commons RDF community in the Apache
Way, mature the API, and then gradually prepare the Commons RDF
community for working within the larger Apache Commons community.

== Rationale ==

The library comes from the need for providing a generic and neutral
API for RDF 1.1 that everybody can transparently use without bounding
the design to concrete implementations. It is the result of
cooperation between contributors to the main Java toolkits, and will
try to be available in a timely manner to influence the major version
updates Jena 3.0 and Sesame 4.0.

== Initial Goals ==

 * Evolve the API towards a generalized and agreed shape
 * Bootstrap basic implementations
 * Support the implementation

== Current Status ==

The API is already quite agreed by all involved players, and it's been
started to be prototyped, both by the major toolkits and by simple
implementations.

=== Meritocracy ===

Commons RDF has been completely designed by committee using git
workflows, where every single feature has been discussed based on a
Pull Request. We plan to keep such methodology where the commons
understanding comes first than personal decisions.

=== Community ===

Commons RDF addresses the developers who are working with Semantic Web
technologies in the JVM. The initial committers are core contributors
to that community.

=== Core Developers ===

 * Sergio Fernández (wikier dot apache dot org)
 * Andy Seaborne (andy dot apache dot org)
 * Peter Ansell (ansell dot apache dot org)
 * Stian Soiland-Reyes (stain at apache dot org)
 * Reto Gmür (reto at apache dot org)

=== Alignment ===

Commons RDF comes to help in the integration of the different ASF
projects using RDF technologies, where Apache Jena can be integrated
with others which use Sesame (Any123 and Marmotta). In addition,
proposals by other projects (Clerezza and Stanbol) can be also
aligned.

== Known Risks ==

=== Orphaned Products ===

Probably one of the major risks will that the API provided does not
fit well in the development plan of the main Java toolkits. But we try
to minimize such risk by having on board core developers of those
framework, the API will live or die on its own merits.

=== Inexperience with Open Source ===

The committers have large experience with open source development and
ASF communities.

=== Homogeneous Developers ===

The initial list of developers come from five different organizations
and four different countries.

=== Reliance on Salaried Developers ===

Although the project is also in the strategic agenda of project of our
current employers, so far the main development is h

Re: Design guidelines and SemVer

[Stian Soiland-Reyes]

Also, as changing Java package names is a drastic step, you would
think three times before introducing breaking changes at all. (or if
you do - do so with a big bang and "fix everything" :) ).

So I think this specialization looks all sensible, specially for
Apache Commons which are utility libraries that could easily be found
multiple times in different versions across dependencies.

So it would be good if the Commons versioning guideline linked to the
(now pretty well known) semantic versioning doc and was aligned with
it terminology-wise - as practically it's pretty much the same. Shall
I sketch out a draft?

On 18 February 2015 at 06:19, Benedikt Ritter  wrote:
> 2015-02-18 5:09 GMT+01:00 Peter Ansell :
>
>> On 18 February 2015 at 12:28, sebb  wrote:
>> > On 17 February 2015 at 22:56, Peter Ansell 
>> wrote:
>> >> On 17 February 2015 at 21:48, sebb  wrote:
>> >>> On 17 February 2015 at 06:13, Benedikt Ritter 
>> wrote:
>> >>
>> >> 
>> >>
>> >>>> and the maven coordinates when we break binary compatibility (= bump
>> up the
>> >>>> major version number). We do this to avoid jar hell. This way two
>> versions
>> >>>> of the same commons library can be in the same classpath.
>> >>>
>> >>> I hope most other projects with Maven jars do the same, particularly
>> >>> ones which are libraries.
>> >>> I know HttpComponents does.
>> >>
>> >> I haven't noticed many projects changing their Maven coordinates when
>> >> bumping the major version number, but it is useful for those reasons,
>> >> as long as the package names inside also change.
>> >
>> > I would hope all projects increase the major version when breaking
>> compat.
>>
>> Sorry, I should have been clearer. Even in projects that bump the
>> major version based on a compatibility difference, I haven't noticed
>> many changing their groupId or artifactId, or changing their Java
>> package names internally. Obviously they change the version. Changing
>> package names is just generally viewed as too drastic a step I think
>> in general, given that Java will ensure typesafety and method
>> availability when compiling against the new version anyway. And
>> therefore not needing to change the maven ids as they can't coexist on
>> the classpath without OSGi/etc. anyway. In the case of OSGi either
>> method could work given enough effort on the package wrappers part.
>>
>
> I think it is important to take into account what kind of project we're
> talking about. For a framework like spring or hibernate there is no need to
> change package names and maven coords, because you won't have two different
> versions of the jars in your classpath (it simply makes no sense at all).
> When talking about little libraries like the one developed at commons,
> things are different. It is likely that you will end up with several
> conflicting versions in your classpath through transetive dependencies. So
> often you can do nothing about that, because you don't own the code that
> references an out dated version of, say commons lang. If we don't go all
> the way and change both, maven coords and the package name, users will have
> a hard time getting their applications to work.
>
> Maybe we should elaborate about this in our versioning guide lines...
>
> Regards,
> Benedikt
>
>
>>
>> I am not trying to say that the system is perfect, but that is what
>> the general behaviour seems to be, even with people who try very hard
>> to follow SemVer and similar ideas.
>>
>> Cheers,
>>
>> Peter
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter



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

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

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

[Stian Soiland-Reyes]

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


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

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

[Stian Soiland-Reyes]

Great we are on the same page :)

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

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

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

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

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

Re: [VOTE] Release BCEL 6.0 based on RC3

[Stian Soiland-Reyes]

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

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

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

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


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


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



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

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

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

[Stian Soiland-Reyes]

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

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


> AFAIK Maven does not do that.

No (but perhaps it should).

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


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

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

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


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


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

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






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

See above.

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





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

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

Re: [ALL] Ask for CLA before merging pending GitHub pull requests

[Stian Soiland-Reyes]

Right, just keep in mind:

For contributions, you as the committer would be responsible for the
content being IP clean, not the pull request submitter.

How do you do this from a larger contribution (e.g. 3 new classes) from a
github user known only as "msTentactle"?

If she has signed the CLA, then she is responsible instead, as it includes:

> 4. You represent that you are legally entitled to grant the above license.

Note that this also applies to the committer that does the merge from
non-CLA contribs.

For patches that probably is not even copyrightable or unlikely to be say
copy-pasted from Oracle code, then no need for a CLA.
On 19 Mar 2015 20:39, "Mark Thomas"  wrote:

> On 19/03/2015 17:32, Bruno P. Kinoshita wrote:
> > Hello,
> >
> > There is a pending pull request at GitHub to the incubator [text]
> > component that I would like to merge. Before doing so, could someone
> > confirm whether I have to check if the user has already signed a CLA
> > [1], and if not, ask him/her to sign it, please?
>
> Warning: Personal pet peeve ahead. Apologies in advance for the shouting :)
>
> No, no, no, no, NO!
>
> CLAs are NEVER *required* for the ASF to use patch. Section 5 of the
> Apache License V2 gives us all the legal permissions we *need* to use a
> patch, assuming the conditions of that section are met. There is the
> question of what is an intentional submission but it is safe to assume -
> unless the author states otherwise - that something submitted via Jira
> or a pull request is an intentional submission.
>
> There is a view among many projects that for 'large' contributions is is
> prudent to have a CLA on file. I do not share that view. The only folks
> we *require* CLAs from are committers.
>
> > IIRC, when users
> > submit patches via JIRA it displays an option to donate the code
> > submitted via patch to ASF.
>
> We removed that option years ago because it served no purpose (and it
> was a PITA to maintain the custom plug-in that implemented it). Again,
> section 5 of the ALv2 gives us all the cover we need.
>
> Bugzilla (which pre-dates Jira) has never had such an option.
>
> > If signing CLA's is a requirement for
> > GitHub pull requests, maybe we could ping @infra and check with them
> > if we could use clabot [2] for that?
>
> No need. Just review the pull request and - if it is acceptable - merge it.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [COMMONSRDF] GroupID for incubation releases

[Stian Soiland-Reyes]

I generally prefer one groupId matching the git repository somehow (e.g.
org.apache.commons.rdf), but +1 to the below and be aligned with the rest
of (modern) Commons. Also we won't have that many modules.
On 28 Mar 2015 16:51, "Gary Gregory"  wrote:

> On Sat, Mar 28, 2015 at 9:40 AM, Benedikt Ritter 
> wrote:
>
> > 2015-03-28 16:37 GMT+01:00 Sergio Fernández :
> >
> > > Hi Benedikt,
> > >
> > > that question came to me while working on COMMONSRDF-2...
> > >
> > > Personally I see Apache Commons as our current target for graduation.
> > > Therefore I'd prefer to use those coordinates already in incubation
> > (that's
> > > considered a best practices to avoid issues on graduation). But of
> course
> > > anybody else could have other opinion.
> > >
> > > In that case, how does Commons manages different artifacts per
> component?
> > > Because we currently have three (parent, api and simple imp). So my
> idea
> > > was to put all together under org.apache.commons.rdf groupId, but we
> can
> > > also stay at org.apache.commons and solve it at the artifacts' level.
> > >
> >
> >
> > Apache Commons VFS 2 uses the following pattern [1]:
> >
> > parent:
> >   org.apache.commons:commons-vfs-2-project
> > core:
> >   org.apache.commons:commons-vfs-2
> > examples:
> >   org.apache.commons:commons-vfs-2-examples
> >
> > So for Commons RDF I would recommend the following:
> >
> > parent:
> >   org.apache.commons:commons-rdf-parent
> > api:
> >   org.apache.commons:commons-rdf-api
> > impl:
> >   org.apache.commons:commons-rdf-impl
> >
> > Would that work for you?
> >
>
> Looks good to me.
>
> G
>
> >
> > Benedikt
> >
> > [1] https://github.com/apache/commons-vfs
> >
> >
> > >
> > > Thanks for bringing here this discussion and your valuable feedback.
> > >
> > > Cheers,
> > >
> > >
> > > On 28/03/15 14:13, Benedikt Ritter wrote:
> > >
> > >> Hi guys,
> > >>
> > >> there is a discussion in COMMONSRDF-2 [1] about the maven coordinates
> > for
> > >> incubation releases of Commons RDF. I may have missed something, but
> my
> > >> last information was, that Commons RDF has not yet decided whether it
> > >> want's to join Apache Commons or go TLP in the end. So the situation
> > looks
> > >> like the following to me:
> > >>
> > >> As long as Commons RDF has not decided to join Apache Commons in the
> > end,
> > >> Commons RDF should not use the Apache Commons groupid. So maven
> > >> coordinates
> > >> should be:
> > >>
> > >> org.apache.commonsrdf
> > >> commons-rdf
> > >>
> > >> If Commons RDF has already decided not to go TLP and to join Apache
> > >> Commons
> > >> after incubation, the coordinates should be (have i missed that
> > decision?
> > >> Sorry!):
> > >>
> > >> org.apache.commons
> > >> commons-rdf
> > >>
> > >> Regards,
> > >> Benedikt
> > >>
> > >> [1] https://issues.apache.org/jira/browse/COMMONSRDF-2
> > >>
> > >>
> > > --
> > > Sergio Fernández
> > > Partner Technology Manager
> > > Redlink GmbH
> > > m: +43 660 2747 925
> > > e: sergio.fernan...@redlink.co
> > > w: http://redlink.co
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
> >
> > --
> > http://people.apache.org/~britter/
> > http://www.systemoutprintln.de/
> > http://twitter.com/BenediktRitter
> > http://github.com/britter
> >
>
>
>
> --
> 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: [ALL] Badges for github README.md

[Stian Soiland-Reyes]

a comment in the README.md says I should do mvn commons:readme-md to
update, which doesn't work:

[ERROR] Could not find goal 'readme-md' in plugin
org.apache.commons:commons-build-plugin:1.4 among available goals
copy-javadoc-files, mail-page, download-page, jira-page,
sandbox-jira-page -> [Help 1]

how is the README updated now?

On 9 April 2015 at 00:53, Stian Soiland-Reyes  wrote:
> Looks great! The travis is nice as it also comments on pull requests.
>
>
> .. but .. why are all the README links for homepage, JavaDoc, etc. wrong?
>
> e.g.
> https://commons.apache.org/proper/commons-lang3
> https://commons.apache.org/proper/commons-lang3/download_lang3.cgi
> https://commons.apache.org/proper/commons-lang3/javadocs/api-release
> all 404.
>
> Removing any '3' solves it.
>
>
> On 8 April 2015 at 20:07, Benedikt Ritter  wrote:
>> INFRA-9391 [1] has been resolved, and I've applied the necessary changes.
>> Have a look at the mirror [2]
>>
>> Benedikt
>>
>> [1] https://issues.apache.org/jira/browse/INFRA-9391
>> [2] https://github.com/apache/commons-lang
>>
>> 2015-04-06 18:39 GMT+02:00 Benedikt Ritter :
>>
>>> I've create an infra ticket for activating Travis CI and coveralls for
>>> Commons Lang [1]
>>>
>>> Benedikt
>>>
>>> [1] https://issues.apache.org/jira/browse/INFRA-9391
>>>
>>> 2015-03-18 10:33 GMT+01:00 Benedikt Ritter :
>>>
>>>>
>>>>
>>>> 2015-03-04 20:24 GMT+01:00 Gary Gregory :
>>>>
>>>>> On Wed, Mar 4, 2015 at 9:59 AM, Benedikt Ritter 
>>>>> wrote:
>>>>>
>>>>> > 2015-03-03 21:51 GMT+01:00 Andy Seaborne :
>>>>> >
>>>>> > > Sorry to interrupt - this is not a "for" or "against" comment but
>>>>> > > something I want to make sure was considered.
>>>>> > >
>>>>> > > Apache is independent of any commercial entity.
>>>>> > >
>>>>> > > For example, there was a discussion about the "github/forkme" stripe
>>>>> in
>>>>> > > project home pages.  The outcome was that it was too much like
>>>>> endorsing
>>>>> > > one commercial player.
>>>>> > >
>>>>> > > This isn't the same but some of those are commercial operations.
>>>>> Anything
>>>>> > > that implies endorsement of their services needs to be carefully
>>>>> handled.
>>>>> > >
>>>>> >
>>>>> > Good point. I don't think this will be an issue, but we should be
>>>>> sure. Who
>>>>> > can I talk to about this? legal@?
>>>>> >
>>>>>
>>>>> You can! :-) Since you've taken the lead on the badges, you could follow
>>>>> it
>>>>> through to @legal. You probably know more about them than the rest of us.
>>>>>
>>>>
>>>> I've asked on d...@community.apache.org [1]. Is this good enough for us?
>>>>
>>>> Benedikt
>>>>
>>>> [1] http://markmail.org/message/knnmqvaguaigjsu3
>>>>
>>>>
>>>>>
>>>>> Gary
>>>>>
>>>>>
>>>>> >
>>>>> >
>>>>> > >
>>>>> > > Andy
>>>>> > >
>>>>> > >
>>>>> > > On 03/03/15 19:31, Benedikt Ritter wrote:
>>>>> > >
>>>>> > >> Hi all,
>>>>> > >>
>>>>> > >> as you probably know, I'm a big fan of github :-) I've added
>>>>> README.md
>>>>> > >> files to some of our components. It should make the github
>>>>> repositories
>>>>> > >> more welcoming for github contributors.
>>>>> > >> There are a variety of services available which integrate nicely
>>>>> with
>>>>> > >> github repositories:
>>>>> > >>
>>>>> > >> - Travis CI build service [1]
>>>>> > >> - coveralls.io coverage service [2]
>>>>> > >> - Latest maven release [3]
>>>>> > >> - shield.io license badge [4]
>>>>> > >>
>>>>> > >> This s

Re: [ALL] Badges for github README.md

[Stian Soiland-Reyes]

t;>> > >> the commons-build-plugin.
>>>> > >>
>>>> > >> Note that travis and converalls have to be activated by a INFRA.
>>>> I've
>>>> > >> already seen jira requests for this, which have been resolved by
>>>> INFRA,
>>>> > so
>>>> > >> this should not be a problem.
>>>> > >>
>>>> > >> Regards,
>>>> > >> Benedikt
>>>> > >>
>>>> > >> [1] http://travis-ci.org
>>>> > >> [2] http://coveralls.io
>>>> > >> [3] https://github.com/jirutka/maven-badges
>>>> > >> [4] http://shield.io
>>>> > >> [5] https://github.com/britter/commons-lang
>>>> > >>
>>>> > >>
>>>> > >>
>>>> > >
>>>> > > -
>>>> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>> > > For additional commands, e-mail: dev-h...@commons.apache.org
>>>> > >
>>>> > >
>>>> >
>>>> >
>>>> > --
>>>> > http://people.apache.org/~britter/
>>>> > http://www.systemoutprintln.de/
>>>> > http://twitter.com/BenediktRitter
>>>> > http://github.com/britter
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>>> Java Persistence with Hibernate, Second Edition
>>>> <http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>
>>>
>>>
>>> --
>>> http://people.apache.org/~britter/
>>> http://www.systemoutprintln.de/
>>> http://twitter.com/BenediktRitter
>>> http://github.com/britter
>>>
>>
>>
>>
>> --
>> http://people.apache.org/~britter/
>> http://www.systemoutprintln.de/
>> http://twitter.com/BenediktRitter
>> http://github.com/britter
>>
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter



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

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

Re: [all] Commons Parent - Plugin Updates

[Stian Soiland-Reyes]

Changes look non-intrusive and OK for me. I would say bump the apache
super-parent as well.

Would you let us know how you checked the changes? Using the versions
plugin, or diffing the effective poms?
On 27 Aug 2015 13:47, "Bernd Eckenfels"  wrote:

> Hello,
>
> I plan to release commons-parent, therefore I checked the plugin versions.
>
> Here are the plugins which allow updates, the release notes, my analysis
> and
> decisions (r1698139):
>
>
>
> maven-compiler-plugin  3.2 -> 3.3
>
> https://mail-archives.apache.org/mod_mbox/maven-announce/201503.mbox/%3c20150327182100.6fa0c17...@minotaur.apache.org%3E
>
> Besides a sane 2.2.1 minimum version for Maven, it does not document
> any severe changes. It can also be overwritten by
> commons.compiler.version property. Tested, Bump to 3.3
>
>
>
> maven-enforcer-plugin .. 1.3.1 -> 1.4
>
> http://mail-archives.apache.org/mod_mbox/maven-announce/201501.mbox/%3c20150129201332.d2a1517...@minotaur.apache.org%3E
>
> Bumps Maven minimum to 2.2.1, introduces a few new dependency versions
> but it seems to be sane. Is defined in apache parent (old and new),
> should we overwrite it? Update not tested, not changed.
>
>
>
> maven-jar-plugin . 2.5 -> 2.6
>
> http://mail-archives.apache.org/mod_mbox/maven-announce/201503.mbox/%3c20150310103739.55bad17...@minotaur.apache.org%3E
>
> Bumps some dependencies (especially plexus-archiver 2.9). Has no
> property to overwrite. Tested, Bump to 2.6
>
>
>
> maven-javadoc-plugin .. 2.10.2 -> 2.10.3
>
> http://blog.soebes.de/blog/2015/04/15/apache-maven-javadoc-plugin-version-2-dot-10-dot-3-released/
>
> Minor update. Configured with property commons.javadoc.version. Tested,
> Bump to 2.10.3
>
>
>
> maven-release-plugin . 2.5.1 -> 2.5.2
>
> http://mail-archives.apache.org/mod_mbox/maven-announce/201504.mbox/%3Cop.xxihwzptkdkhrr@robertscholte%3E
>
> Updates some dependency. Not specifically tested, Bump to 2.5.2
>
>
>
> org.codehaus.mojo:build-helper-maven-plugin  1.8 -> 1.9.1
>
> http://blog.soebes.de/blog/2014/09/06/mojo-build-helper-maven-plugin-version-1-dot-9-1-released/
>
> http://blog.soebes.de/blog/2014/06/10/mojo-build-helper-maven-plugin-version-1-dot-9-released/
>
> Mostly Bugfixes. Could affect the version parsing. Tested, Bump to 1.9.1
>
>
>
> When running display-plugin-updates this leaves me with two pending
> updates, one is a false positive (animal-sniffer is updated by profile when
> java7 is used, not sure why versions plugin does not see that) and the
> enforcer, which I would only update when ASF parent does it.
>
>
> If not mentioned otherwise I made the change, deployed the parent, used
> it to build commons-vfs trunk with the following commands:
>
> JAVA_HOME=%JAVA_1_8_HOME% mvn clean verify -Pjava-1.8
> -Dmaven.compiler.target=1.7
>   NB: Animal Sniffer does not yet offer 1.8 signatures
>
> JAVA_HOME=%JAVA_1_7_HOME% mvn clean verify -Pjava-1.7
> -Dmaven.compiler.target=1.7
>
> JAVA_HOME=%JAVA_1_6_HOME% mvn clean site -Pinclude-sandbox
>   * jira ssl problems
>
> JAVA_HOME=%JAVA_1_8_HOME% mvn clean site -Pinclude-sandbox
>
>
>
> I haven't considered updating the apache parent, we can do that later,
> it would introduce:
>
> org.apache:apache  16 -> 17
> - bumps default compile target 1.4 -> 1.5
> - compiler version 3.1 -> 3.2 (old)
> - adds project-info-report plugin,
> - bumps failsave 2.17 -> 2.18.1
> - maven resource plugin 2.6 -> 2.7
> - maven-scm-publish 1.0-beta-2 -> 1.1
> - maven-source-plugin 2.3 -> 2.4
> - adds maven-surefore-report
> - add maven war plugin 2.5
> - add maven-site-plugin attach descriptor
> - jar -> jar-no-fork
> - apache-source-release-assembly-descriptor 1.0.4 -> 1.0.5
> - removes maven-3 profile
>
> Greetings
> Bernd
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Anyone for Apache Commons & Apache Con Core 2016 CFP?!

[Stian Soiland-Reyes]

Sergio, Let me know if you are going and want to collaborate on Commons RDF
slides/demo!

(I don't think I am going this year I'm afraid.  )
On 29 Jan 2016 14:01, "Sergio Fernández"  wrote:

> On Fri, Jan 29, 2016 at 12:59 PM, Siegfried Göschl <
> siegfried.goes...@it20one.com> wrote:
> >
> > there are no "best" persons to make a presentation :-)
> >
>
> Well, meritocracy does not say no... ;-)
>
> Anyway, I understand your points, so keep me as backup just in case
> (although by today I can't warranty 100% I'm attending).
>
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 6602747925
> e: sergio.fernan...@redlink.co
> w: http://redlink.co
>

Re: [VOTE] Release Compress 1.11 Based on RC1

[Stian Soiland-Reyes]

You didn't include the checksums in the mail, but the svn revision
12931 matched.

My vote: -1 (Non-binding)

Due to additional file commons-compress-1.11-SNAPSHOT.jar


sha1 checksums:

74971a345dd8dc9ca3c3dc9af6d407945e9143a5  commons-compress-1.11-src.tar.gz
a2e0a8ef238d5da348cb1b0154cd773ba93be4c9  commons-compress-1.11-src.zip
efb5475cdc3dfb44594d7bde36676c45ad2162ed  commons-compress-1.11-bin.tar.gz
260589c896e80262e3484d93c3fe414eb3786466  commons-compress-1.11-bin.zip


Checked:

-1 binary release contains spurious file commons-compress-1.11-SNAPSHOT.jar
0 mvn apache-rat:rat fails (as the test excludes are only under
 in pom.xml)
0 staging repository matches RC binaries - (but has spurious checksums
like commons-compress-1.11-sources.jar.md5.sha1 )
+1 source/binaries checksums
+1 source/binaries signatures
+1 mvn clean verify
+1 NOTICE/LICENSE

On 30 March 2016 at 14:56, Stefan Bodewig  wrote:
> Hi all
>
> Foo 1.2 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/compress/
> (svn revision 12931)
>
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1144/org/apache/commons/commons-compress/1.11/
>
> Details of changes since 1.10 are in the release notes:
> https://dist.apache.org/repos/dist/dev/commons/compress/RELEASE-NOTES.txt
> http://stefan.samaflost.de/staging/COMPRESS-1.11/changes-report.html
>
> I have tested this with JDK 1.7 and 1.8 using maven3.
>
> The tag is here:
> 
> https://git-wip-us.apache.org/repos/asf?p=commons-compress.git;a=commit;h=ff38bf57378c7cae8617b3c8df692a5ffbe7b83f
> (the tag with the name 1.11-RC1 on commit ff38bf5)
>
> Site:
> http://stefan.samaflost.de/staging/COMPRESS-1.11/
> (note this is not the site I'll publish once the vote gets accepted,
> I'll recreate the site when the release date ist fixed.
> Also download page and the 1.11 javadoc are not expected to work
> right now but will with the correct site)
>
> Clirr Report (compared to 1.1):
> http://stefan.samaflost.de/staging/COMPRESS-1.11/clirr-report.html
>
> RAT Report:
> http://stefan.samaflost.de/staging/COMPRESS-1.11/rat-report.html
>
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
>   This vote will close no sooner that 72 hours from now, i.e. after
>   1400 GMT 02-April 2016
>
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
>
> Thanks!
>
> Stefan
>
> -------------
> 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 RDF (incubating)
http://orcid.org/-0001-9842-9718

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

Re: [VOTE] Release Compress 1.11 Based on RC2

[Stian Soiland-Reyes]

+1 (non-binding)


Checked:
+1 Signatures in source/binaries/repo
+1 Checksums in source/binaries/repo
+1 source/binaries zip match tar.gz
+1 No extra binaries :)
+1 RELEASE-NOTES.txt
+1 mvn clean verify
+1 git commit & tag match src
+1 built commons-compress-1.11.jar file listing match jar from binaries/
+1 RAT OK (from mvn site)
+1 NOTICE/LICENSE
+1 Repository commons-compress-1.11.jar /
commons-compress-1.11-javadoc.jar matches binaries
+1 Repository commons-compress-1.11-sources.jar matches
src/main/java/org in sources


Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T16:41:47+00:00)
Maven home: /home/stain/software/maven
Java version: 1.8.0_72-internal, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "3.16.0-67-generic", arch: "amd64", family: "unix"


Could we delete the tag 1.11-RC1 now?

On 2 April 2016 at 20:25, Stefan Bodewig  wrote:
> Hi all
>
> due to a packaging glitch I had to re-roll the release. It is based on
> the same commit that was used for RC1, so both tags refer to the same
> commit. For this reason I haven't even re-created the site.
>
> Compress 1.11 RC2 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/compress/
> (svn revision 12977)
>
> sha1 checksums:
>
> b26a5bfb8686a42d256562d0a71ee436f81495e5 
> binaries/commons-compress-1.11-bin.tar.gz
> 65abf5df38d665bea3c6c215d247a26f328c84c5 
> binaries/commons-compress-1.11-bin.zip
> 3dd2e40fba93ee3c271187cc204b5b367e671847 
> source/commons-compress-1.11-src.tar.gz
> 0b053fc7937655797c7d6aa0d166d697fb4b1bae source/commons-compress-1.11-src.zip
>
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1145/org/apache/commons/commons-compress/1.11/
>
> Details of changes since 1.10 are in the release notes:
> https://dist.apache.org/repos/dist/dev/commons/compress/RELEASE-NOTES.txt
> http://stefan.samaflost.de/staging/COMPRESS-1.11/changes-report.html
>
> I have tested this with JDK 1.7 and 1.8 using maven3.
>
> The tag is here:
> 
> https://git-wip-us.apache.org/repos/asf?p=commons-compress.git;a=commit;h=ff38bf57378c7cae8617b3c8df692a5ffbe7b83f
> (the tag with the name COMPRESS-1.11-RC2 on commit ff38bf5)
>
> Site:
> http://stefan.samaflost.de/staging/COMPRESS-1.11/
> (note this is not the site I'll publish once the vote gets accepted,
> I'll recreate the site when the release date ist fixed.
> Also download page and the 1.11 javadoc are not expected to work
> right now but will with the correct site)
>
> Clirr Report (compared to 1.10):
> http://stefan.samaflost.de/staging/COMPRESS-1.11/clirr-report.html
>
> RAT Report:
> http://stefan.samaflost.de/staging/COMPRESS-1.11/rat-report.html
>
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
>   This vote will close no sooner than 72 hours from now, i.e. after
>   1930 GMT 05-April 2016
>
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
>
> Thanks!
>
> Stefan
>
> -
> 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 RDF (incubating)
http://orcid.org/-0001-9842-9718

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

Re: Whatever happened to commons-io 2.5?

[Stian Soiland-Reyes]

Right, dist is just using SVN as a convenient way to manage the
distribution tree for the download mirrors, that it is version controlled
is a nice side effect, it would not work well with Git (except possibly
with LFS) as every binary and source release of ASF since the dist repos
inception is in the history :)
On 12 Apr 2016 00:04, "sebb"  wrote:

On 11 April 2016 at 23:57, Benson Margulies  wrote:
> I volunteered here because I (mis?) remembered that commons had
> decided to activate the 'univeral commit bit', so that I would already
> have commit access.

The dist repo is not the same as the commons repo; they don't even
share the same parent.

> Are you willing to add me to the group?

>
> On Mon, Apr 11, 2016 at 6:44 PM, Gary Gregory 
wrote:
>> On Mon, Apr 11, 2016 at 3:41 PM, sebb  wrote:
>>
>>> On 11 April 2016 at 22:56, Benson Margulies 
wrote:
>>> > I'm assuming this code hasn't been moved to git, based on the lack of
>>> > discussion of same on the relevant web page.
>>> >
>>>
>>> AIUI the dist/ tree will never be moved to Git because it has so much
>>> data in it, and it's not possible to check out a part of a Git repo.
>>>
>>
>> Really? It seems like keeping the whole repo is a good idea. How much
data
>> are we talking about here?
>>
>> Are we talking about a Git limit or an Apache limit?
>>
>> Gary
>>
>>>
>>> I think the problem is that you are not in the Commons Unix group.
>>>
>>> > On Mon, Apr 11, 2016 at 5:52 PM, Benson Margulies <
bimargul...@gmail.com>
>>> wrote:
>>> >> First Karma issue:
>>> >>
>>> >> SendingKEYS
>>> >> Transmitting file data .svn: E195023: Commit failed (details follow):
>>> >> svn: E195023: Changing file '/Users/benson/asf/commons/KEYS' is
>>> >> forbidden by the server
>>> >> svn: E175013: Access to
>>> >> '/repos/dist/!svn/txr/13132-b9c/release/commons/KEYS' forbidden
>>> >> svn: E195023: Your commit message was left in a temporary file:
>>> >> svn: E195023:'/Users/benson/asf/commons/svn-commit.tmp'
>>> >>
>>> >>
>>> >> On Mon, Apr 11, 2016 at 5:45 PM, Benson Margulies <
>>> bimargul...@gmail.com> wrote:
>>> >>> So, there's a tag for 2.5-RC3.
>>> >>>
>>> >>> And there are recent commits.
>>> >>>
>>> >>> I propose to move the version on trunk back to 2.5-SNAPSHOT, and
then
>>> >>> tee up a 2.5-RC4 release from the current state of trunk, rather
than
>>> >>> leave all the changes since the RC waiting for another day. Is
there a
>>> >>> reason not to do that?
>>> >>>
>>> >>>
>>> >>> On Mon, Apr 11, 2016 at 4:36 PM, Gary Gregory <
garydgreg...@gmail.com>
>>> wrote:
>>>  There might be a speed bump when it is time to publish to Nexus.
That
>>> might
>>>  require PMC karma. Same for copying files for pub/sub. That would
be
>>> a good
>>>  thing to doc on the wiki/site.
>>> 
>>>  G
>>> 
>>>  On Mon, Apr 11, 2016 at 12:28 PM, Mark Thomas 
>>> wrote:
>>> 
>>> > On 11/04/2016 18:30, Benson Margulies wrote:
>>> > > Well, here we are. I'm willing to help, but you'd have to give
me
>>> > > enough permission.
>>> >
>>> > Benson,
>>> >
>>> > Willing volunteers are always welcome.
>>> >
>>> > As an ASF committer, you already have commit to Commons.
>>> >
>>> > As an ASF Member, you know what is expected.
>>> >
>>> > Crack on and shout if you hit a problem. I should be able to grant
>>> you
>>> > any karma you need. The only exception is if you need to be on the
>>> PMC.
>>> > That will trigger a delay of however long it takes us to vote and
>>> > (assuming we vote yes) the 72 hours we have to wait for the board.
>>> That
>>> > said, I don't think there is anything in the release process that
>>> > requires PMC membership.
>>> >
>>> > Mark
>>> >
>>> >
>>> > >
>>> > > On Mon, Apr 11, 2016 at 1:27 PM,   wrote:
>>> > >> Sorry, let me re-phrase: I don't think someone with commit
rights
>>> can
>>> > be a RM, I think additional JIRA permissions are required.
>>> > >>
>>> > >>
>>> > >> - Original Message -
>>> > >>
>>> > >> From: dlmar...@comcast.net
>>> > >> To: "Commons Developers List" 
>>> > >> Sent: Monday, April 11, 2016 1:09:14 PM
>>> > >> Subject: Re: Whatever happened to commons-io 2.5?
>>> > >>
>>> > >> I don't think a non-committer can be a RM as I don't believe
JIRA
>>> > permissions have been opened up as well. Please correct me if I am
>>> wrong,
>>> > as I have been waiting a long time for a VFS 2.1 release.
>>> > >>
>>> > >>
>>> > >> - Original Message -
>>> > >>
>>> > >> From: "Benson Margulies" 
>>> > >> To: "Commons Developers List" 
>>> > >> Sent: Monday, April 11, 2016 12:48:08 PM
>>> > >> Subject: Re: Whatever happened to commons-io 2.5?
>>> > >>
>>> > >> I was never a member of the commons PMC, or a voted committer,
I
>>> just
>>> > >> had commit access (I thought) due to the decision to give a
wide
>>> group
>>>

Re: [VOTE] Commons-net 3.5 based on RC1

[Stian Soiland-Reyes]

/www.apache.org/dist/commons/KEYS
>
>   Please review the release candidate and vote.
>   This vote will close no sooner than 72 hours from now,
>   i.e. sometime after 23:00 GMT 18 Apr 2016
>
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
>   Thanks!
>
>   Sebb
>
> -
> 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 RDF (incubating)
http://orcid.org/-0001-9842-9718

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

Re: [ALL] Dist layout change to per version directories

[Stian Soiland-Reyes]

+1 for the change for future releases. Being able to do svn mv (or rm) on a
single folder simplifies releasing and reduces chance of errors.

Is the -src and -bin endings already used across all of Commons? That would
be a bit more important without source/ and binaries/

(Do some have download artifacts beyond bin and src?)

I think it is important to mention this URL pattern change in release notes
for downstream distributors, e.g. Debian recipies that download
https://archive.apache.org/commons/foo/source/foo-${version}-src.tar.gz

(They have to use archive as older versions disappear from official mirrors)
On 16 Apr 2016 00:02, "sebb"  wrote:

> The dist layout currently splits archives into source/ and binaries/.
> Where there are multiple active versions, these are all in the same
> directory.
>
> IMO this layout is not ideal any more.
>
> It is harder to tidy up old releases (files have to be individually
> deleted)
> It is harder to move files from dist/dev to dist/release
>
> Are there any disadvantages to allowing the layout to change?
>
> Unless there are objections, I propose to update the commons build
> plugin to support download pages using version ids, e.g. instead of
> the present layout:
>
> lang/source/commons-lang-2.6-src.*
> lang/source/commons-lang3-3.4-src.*
> lang/binaries/commons-lang-2.6-bin.*
> lang/binaries/commons-lang3-3.4-bin.*
>
> It would look like:
>
> lang/commons-lang-2.6/commons-lang-2.6-[bin|src].*
> lang/commons-lang3-3.4/commons-lang3-3.4-[bin|src].*
>
>
> Note: I don't think we should move the existing releases
>
> The intention is to allow new releases to optionally migrate to the new
> layout.
> This would be done on the basis of a new property, e.g.
> commons.release.layout=version
> If the property is defined, then the new layout is used; if not, then
> the current source/binaries layout is used.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [ALL] Dist layout change to per version directories

[Stian Soiland-Reyes]

Changing download links for all existing releases (without a new release)
sounds worse than having slightly inconsistent paths for a while.

Moving the existing releases would also cause duplicates on
archive.apache.org (unless we ask INFRA to reorganise this as well, which
would break even permalink downloads)

However it is also likely that some of the many stable commons components
won't get a new release in a while (many releases are from 2013 or 2014),
so such inconsistency could take long to get rid off.

Would the mirror folks kill us if we do an svn symlinks from the existing
releases to the new layout and let the existing stay until they have been
replaced by newer versions?  (This would add another 550 MB for mirrors
that don't understand symlinks)
On 18 Apr 2016 09:55, "Gilles"  wrote:

> On Mon, 18 Apr 2016 09:12:16 +0100, Stian Soiland-Reyes wrote:
>
>> +1 for the change for future releases. Being able to do svn mv (or rm) on
>> a
>> single folder simplifies releasing and reduces chance of errors.
>>
>
> I think that your remark below calls for making the changes for all
> components right now.
> Otherwise scripts will require to behave differently for different
> components, and force maintainers modify them each time a component
> adopts the new scheme.
>
> The new directories should be created also for existing releases, so
> that maintainers will have to change their scripts only once.
>
> Gilles
>
> Is the -src and -bin endings already used across all of Commons? That would
>> be a bit more important without source/ and binaries/
>>
>> (Do some have download artifacts beyond bin and src?)
>>
>> I think it is important to mention this URL pattern change in release
>> notes
>> for downstream distributors, e.g. Debian recipies that download
>>
>> https://archive.apache.org/commons/foo/source/foo-${version}-src.tar.gz
>>
>> (They have to use archive as older versions disappear from official
>> mirrors)
>> On 16 Apr 2016 00:02, "sebb"  wrote:
>>
>> The dist layout currently splits archives into source/ and binaries/.
>>> Where there are multiple active versions, these are all in the same
>>> directory.
>>>
>>> IMO this layout is not ideal any more.
>>>
>>> It is harder to tidy up old releases (files have to be individually
>>> deleted)
>>> It is harder to move files from dist/dev to dist/release
>>>
>>> Are there any disadvantages to allowing the layout to change?
>>>
>>> Unless there are objections, I propose to update the commons build
>>> plugin to support download pages using version ids, e.g. instead of
>>> the present layout:
>>>
>>> lang/source/commons-lang-2.6-src.*
>>> lang/source/commons-lang3-3.4-src.*
>>> lang/binaries/commons-lang-2.6-bin.*
>>> lang/binaries/commons-lang3-3.4-bin.*
>>>
>>> It would look like:
>>>
>>> lang/commons-lang-2.6/commons-lang-2.6-[bin|src].*
>>> lang/commons-lang3-3.4/commons-lang3-3.4-[bin|src].*
>>>
>>>
>>> Note: I don't think we should move the existing releases
>>>
>>> The intention is to allow new releases to optionally migrate to the new
>>> layout.
>>> This would be done on the basis of a new property, e.g.
>>> commons.release.layout=version
>>> If the property is defined, then the new layout is used; if not, then
>>> the current source/binaries layout is used.
>>>
>>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [ALL] Dist layout change to per version directories

[Stian Soiland-Reyes]

Ah - as long as the INFRA and Mirror guys are OK with the potentially
extra 500 MB then that sounds good!

I've raised
https://issues.apache.org/jira/browse/INFRA-11702
to enquire how we should best do it.



BTW - the -bin and -src suffixes are quite consistent across the
boards. These are the only files that don't match that pattern:


stain@biggie:~/Downloads/912/mirrors.ukfast.co.uk/sites/ftp.apache.org$
find . -type f | grep -v txt  | grep -v -- -src.tar.gz | grep -v --
-src.zip | grep -v -- -bin.zip | grep -v -- -bin.tar.gz

./commons/proxy/binaries/commons-proxy-1.0.tar.gz
./commons/proxy/binaries/commons-proxy-1.0.zip
./commons/primitives/binaries/commons-primitives-1.0.tar.gz
./commons/primitives/binaries/commons-primitives-1.0.zip
./commons/jexl/binaries/commons-jexl-1.1.tar.gz
./commons/jexl/binaries/commons-jexl-1.1.zip
./commons/attributes/binaries/commons-attributes-2.2.tar.gz
./commons/attributes/binaries/commons-attributes-2.2.zip
./commons/bsf/binaries/bsf-bin-2.4.0.tar.gz
./commons/bsf/binaries/bsf-bin-2.4.0.zip
./commons/bsf/source/bsf-src-2.4.0.tar.gz
./commons/bsf/source/bsf-src-2.4.0.zip
./commons/el/binaries/commons-el-1.0.zip
./commons/el/binaries/commons-el-1.0.tar.gz
./commons/vfs/binaries/commons-vfs-2.0.tar.gz
./commons/vfs/binaries/commons-vfs-2.0.zip
./commons/betwixt/binaries/commons-betwixt-0.8.zip
./commons/betwixt/binaries/commons-betwixt-0.8.tar.gz
./commons/bcel/binaries/bcel-5.2.tar.gz
./commons/bcel/binaries/bcel-5.2.zip
./commons/daemon/binaries/commons-daemon-1.0.15.jar
./commons/daemon/binaries/windows/commons-daemon-1.0.15-bin-windows.zip
./commons/daemon/binaries/windows/commons-daemon-1.0.15-bin-windows-signed.zip
./commons/jelly/binaries/commons-jelly-1.0.zip
./commons/jelly/binaries/commons-jelly-1.0.tar.gz
./commons/launcher/binaries/commons-launcher-1.1.tar.gz
./commons/launcher/binaries/commons-launcher-1.1-example.tar.gz
./commons/launcher/binaries/commons-launcher-1.1.zip
./commons/launcher/binaries/commons-launcher-1.1-example.zip
./commons/transaction/binaries/commons-transaction-1.2.zip
./commons/transaction/binaries/commons-transaction-1.2.tar.gz
./commons/modeler/binaries/commons-modeler-2.0.1.tar.gz
./commons/modeler/binaries/commons-modeler-2.0.1.zip
./commons/sanselan/binaries/apache-sanselan-incubating-0.97-bin.tar.bz2
./commons/sanselan/source/apache-sanselan-incubating-0.97-src.tar.bz2
./commons/math/binaries/commons-math-2.2.tar.gz
./commons/math/binaries/commons-math-2.2.zip
./commons/net/binaries/commons-net-1.4.1.tar.gz
./commons/net/binaries/commons-net-1.4.1.zip
./commons/jcs/binaries/jcs-1.3.tar.gz
./commons/jcs/binaries/jcs-1.3.zip

Most of those are binaries that simply lack "-bin" (oh no!) - so they
could just be changed to the new pattern manually within the new
layout.



On 18 April 2016 at 10:28, Gilles  wrote:
> On Mon, 18 Apr 2016 10:22:53 +0100, Stian Soiland-Reyes wrote:
>>
>> Changing download links for all existing releases (without a new release)
>> sounds worse than having slightly inconsistent paths for a while.
>
>
> I did not suggest to _delete_ anything.
> Just that current archives should be accessible through both old and
> new scripts. The latter not having to deal with the old layout.
>
> Gilles
>
>
>> Moving the existing releases would also cause duplicates on
>> archive.apache.org (unless we ask INFRA to reorganise this as well, which
>> would break even permalink downloads)
>>
>> However it is also likely that some of the many stable commons components
>> won't get a new release in a while (many releases are from 2013 or 2014),
>> so such inconsistency could take long to get rid off.
>>
>> Would the mirror folks kill us if we do an svn symlinks from the existing
>> releases to the new layout and let the existing stay until they have been
>> replaced by newer versions?  (This would add another 550 MB for mirrors
>> that don't understand symlinks)
>> On 18 Apr 2016 09:55, "Gilles"  wrote:
>>
>>> On Mon, 18 Apr 2016 09:12:16 +0100, Stian Soiland-Reyes wrote:
>>>
>>>> +1 for the change for future releases. Being able to do svn mv (or rm)
>>>> on
>>>> a
>>>> single folder simplifies releasing and reduces chance of errors.
>>>>
>>>
>>> I think that your remark below calls for making the changes for all
>>> components right now.
>>> Otherwise scripts will require to behave differently for different
>>> components, and force maintainers modify them each time a component
>>> adopts the new scheme.
>>>
>>> The new directories should be created also for existing releases, so
>>> that maintainers will have to change their scripts only once.
>>>
>>> Gilles
>>>
>>> 

Re: [ALL] Dist layout change to per version directories

[Stian Soiland-Reyes]

We might also want to include the "apache-" file prefix for trademark
reasons - as advocated to all incubator projects.

e.g.

/commons/lang/3.4/apache-commons-lang3-3.4-src.tar.gz




On 18 April 2016 at 10:40, Gilles  wrote:
> On Mon, 18 Apr 2016 11:18:49 +0200, Emmanuel Bourg wrote:
>>
>> Le 18/04/2016 10:48, Gilles a écrit :
>>
>>> IIRC, I was once corrected that this is not the component's name (which
>>> in this case would be "Apache Commons Lang").
>>
>>
>> That's consistent with the site URL though:
>>
>>   http://commons.apache.org/proper/commons-lang/
>
>
> I know; and from a purely aesthetics ;-) POV, I also prefer a reference
> to the "component" rather than the "id" which is a concatenation (of
> a name and a version) that exists for practical reasons.
>
> But isn't the change also for a practical reason, namely to avoid
> confusing artefacts?
>
> Hence I thought that the focus should be on the "id", contrary to e.g.
> the web site whose primary focus is to document the "component".
>
>>
>> An alternative would be to use the version only:
>>
>>   lang/2.6/commons-lang-2.6-[bin|src].*
>>   lang/3.4/commons-lang3-3.4-[bin|src].*
>
>
> Perhaps.  It really depends on the issues which the change is trying
> to solve; the new scheme should be a solution that does not create
> new confusions.
>
> Gilles
>
>
>> Emmanuel Bourg
>>
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>



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

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

[ALL] Use apache- prefix in dist?

[Stian Soiland-Reyes]

For the download distributions, we might want to include the "apache-"
file prefix for trademark
reasons - as advocated to all incubator projects.

e.g.

/commons/lang/3.4/apache-commons-lang3-3.4-src.tar.gz

unpacking to:


apache-commons-lang3-3.4/pom.xml
apache-commons-lang3-3.4/src
etc




On 18 April 2016 at 10:59, Gilles  wrote:

> Can it be added automatically to the artefacts, i.e. without requiring
> that the "id" be changed?

It requires careful Maven hand-holding - most of the Commons
components is just a single pom.xml relying on the parent, while
others might have their own assembly or multiple modules.


In theory it should work with:

   apache-${artifactId}-${version}

in the Commons parent pom.

.. but that would need testing.


NOTE: We DON'T want to change the artifactId in Maven repositories
(this would be an easy workaround for multi-module POMs, e.g. parent
is apache-foo while submodules are
foo-bar etc.


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

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

[ALL] Missing -bin suffixes for some modules in dist.apache.org

[Stian Soiland-Reyes]

These downloads lack -bin / -src suffixes:

On 18 April 2016 at 10:43, Stian Soiland-Reyes  wrote:
> stain@biggie:~/Downloads/912/mirrors.ukfast.co.uk/sites/ftp.apache.org$
> find . -type f | grep -v txt  | grep -v -- -src.tar.gz | grep -v --
> -src.zip | grep -v -- -bin.zip | grep -v -- -bin.tar.gz
>
> ./commons/proxy/binaries/commons-proxy-1.0.tar.gz
> ./commons/proxy/binaries/commons-proxy-1.0.zip
> ./commons/primitives/binaries/commons-primitives-1.0.tar.gz
> ./commons/primitives/binaries/commons-primitives-1.0.zip
> ./commons/jexl/binaries/commons-jexl-1.1.tar.gz
> ./commons/jexl/binaries/commons-jexl-1.1.zip
> ./commons/attributes/binaries/commons-attributes-2.2.tar.gz
> ./commons/attributes/binaries/commons-attributes-2.2.zip
> ./commons/bsf/binaries/bsf-bin-2.4.0.tar.gz
> ./commons/bsf/binaries/bsf-bin-2.4.0.zip
> ./commons/bsf/source/bsf-src-2.4.0.tar.gz
> ./commons/bsf/source/bsf-src-2.4.0.zip
> ./commons/el/binaries/commons-el-1.0.zip
> ./commons/el/binaries/commons-el-1.0.tar.gz
> ./commons/vfs/binaries/commons-vfs-2.0.tar.gz
> ./commons/vfs/binaries/commons-vfs-2.0.zip
> ./commons/betwixt/binaries/commons-betwixt-0.8.zip
> ./commons/betwixt/binaries/commons-betwixt-0.8.tar.gz
> ./commons/bcel/binaries/bcel-5.2.tar.gz
> ./commons/bcel/binaries/bcel-5.2.zip
> ./commons/daemon/binaries/commons-daemon-1.0.15.jar
> ./commons/daemon/binaries/windows/commons-daemon-1.0.15-bin-windows.zip
> ./commons/daemon/binaries/windows/commons-daemon-1.0.15-bin-windows-signed.zip
> ./commons/jelly/binaries/commons-jelly-1.0.zip
> ./commons/jelly/binaries/commons-jelly-1.0.tar.gz
> ./commons/launcher/binaries/commons-launcher-1.1.tar.gz
> ./commons/launcher/binaries/commons-launcher-1.1-example.tar.gz
> ./commons/launcher/binaries/commons-launcher-1.1.zip
> ./commons/launcher/binaries/commons-launcher-1.1-example.zip
> ./commons/transaction/binaries/commons-transaction-1.2.zip
> ./commons/transaction/binaries/commons-transaction-1.2.tar.gz
> ./commons/modeler/binaries/commons-modeler-2.0.1.tar.gz
> ./commons/modeler/binaries/commons-modeler-2.0.1.zip
> ./commons/sanselan/binaries/apache-sanselan-incubating-0.97-bin.tar.bz2
> ./commons/sanselan/source/apache-sanselan-incubating-0.97-src.tar.bz2
> ./commons/math/binaries/commons-math-2.2.tar.gz
> ./commons/math/binaries/commons-math-2.2.zip
> ./commons/net/binaries/commons-net-1.4.1.tar.gz
> ./commons/net/binaries/commons-net-1.4.1.zip
> ./commons/jcs/binaries/jcs-1.3.tar.gz
> ./commons/jcs/binaries/jcs-1.3.zip

We need to check if this their POMs need updating or if this is mainly
manually made releases.



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

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

Re: [VOTE][LAZY] Release Commons Build Plugin 1.6 based on RC1

[Stian Soiland-Reyes]

I don't think we can do lazy release votes (even for an "internal" component):

http://www.apache.org/dev/release.html#approving-a-release


I notice this RC is 'straight to Maven' - but this should also be released to
https://dist.apache.org/repos/dist/release/commons/commons-build-plugin/source/

(BTW: 1.5 is missing there)


Here is my vote:

-1 (non-binding)

Checked:
+1 mvn clean install (from svn tag)
-1 apache-rat:check fails on
src/main/resources/commons-xdoc-templates/download-page-body.xml and
src/main/resources/commons-xdoc-templates/download-page-foot.xml
-1 https://dist.apache.org/repos/dist/dev/commons/ area missing
(unclear which source release we are voting over)

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T16:41:47+00:00)
Maven home: /home/stain/software/maven
Java version: 1.8.0_72-internal, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "3.16.0-67-generic", arch: "amd64", family: "unix"

On 17 April 2016 at 15:16, sebb  wrote:
> This is a VOTE by LAZY consensus to release Commons Build Plugin 1.6
> based on RC1
>
> The changes from 1.5 are:
>
> Added new download-page layout property:
>set this to 'version' to use a single directory of the form
> commons-build-plugin-1.6 rather than binaries/source
>
> This VOTE is open for at least 72 hours until Apr 20 2016 15:00 UTC
>
> The files:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1152/org/apache/commons/commons-build-plugin/1.6/
>
> /org/apache/commons/commons-build-plugin/1.6/commons-build-plugin-1.6-sources.jar
> (SHA1: b0482b7becb86c6e1ba5f18e6b513c7bd0621e58)
> /org/apache/commons/commons-build-plugin/1.6/commons-build-plugin-1.6-test-sources.jar
> (SHA1: 6fb7fb9d5f3b228003be8d12dae1de7297d8cbe0)
> /org/apache/commons/commons-build-plugin/1.6/commons-build-plugin-1.6-src.zip
> (SHA1: e899b282253222aca7d0cca160c56d0d211a8fd4)
> /org/apache/commons/commons-build-plugin/1.6/commons-build-plugin-1.6-javadoc.jar
> (SHA1: 9a5b91264e979896b4d8df565d00feaafdd69318)
> /org/apache/commons/commons-build-plugin/1.6/commons-build-plugin-1.6.jar
> (SHA1: 46a803ec284c186039063c4826a22446e1bbc69e)
> /org/apache/commons/commons-build-plugin/1.6/commons-build-plugin-1.6-tests.jar
> (SHA1: ee5dfcd78cbdd7e140ebd77e7599d88bed19a37b)
> /org/apache/commons/commons-build-plugin/1.6/commons-build-plugin-1.6.pom
> (SHA1: c4213ebdeaafda42e7056ca23cbde8a24149e081)
> /org/apache/commons/commons-build-plugin/1.6/commons-build-plugin-1.6-src.tar.gz
> (SHA1: 6ad8957d718de2ae14135f369f18b698e274411e)
>
> The tag:
>
> https://svn.apache.org/repos/asf/commons/proper/commons-build-plugin/tags/commons-build-plugin-1.6-RC1
> (r1739618)
>
> ---------
> 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 RDF (incubating)
http://orcid.org/-0001-9842-9718

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

Re: [VOTE][LAZY] Release Commons Build Plugin 1.6 based on RC1

[Stian Soiland-Reyes]

On 18 April 2016 at 13:43, Stian Soiland-Reyes  wrote:

> -1 apache-rat:check fails on
> src/main/resources/commons-xdoc-templates/download-page-body.xml and
> src/main/resources/commons-xdoc-templates/download-page-foot.xml


These are not really XML files, but templates to be inserted in XML
files - and it would therefore be weird for them to have
the standard ASF file header.

I added them as apache-rat excludes to pom.xml in svn trunk.

(I would still say -1 until the RC is on dist.apache.org)

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

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

Re: [VOTE][LAZY] Release Commons Build Plugin 1.6 based on RC1

[Stian Soiland-Reyes]

On 18 Apr 2016 4:47 p.m., "sebb"  wrote:

> Using lazy votes for this was was agreed by the PMC a while back.

Ah, I thought as it had its own website, (earlier) downloads and Maven
Central artifacts it was one of the releases of Apache Commons.

Perhaps if it is only for internal project use it should not be mirrored to
Maven Central (e.g. kept in a separate Nexus area - perpetual SNAPSHOT) -
or it should be treated as a proper release (even if it happens to be a bit
exotic for non-Commons users), in which case the usual checks and balances
apply.

> > I notice this RC is 'straight to Maven' - but this should also be
released to
> >
https://dist.apache.org/repos/dist/release/commons/commons-build-plugin/source/
> >
> > (BTW: 1.5 is missing there)
>
> The build plugin is entirely optional, and only intended for use by
> Commons Developers.

So none of the components depend on the build plugin as part of their
pom.xml build? (Only on command line or in a -Prelease profile?)

(Sorry, I haven't checked)

> Note we haven't released Commons parent POM there either.
> If anything, that is a more deserving case for a dist release.

Yes, even though the parent pom is a self-contained file, I would support
such a move for consistency reasons and to (if ever so slightly) reduce
reliance on Maven Central. (See NPM usecase:
http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ )

(It could be argued that everything should be source released also in the
Nexus repository, and that it should be treated as official as
dist.apache.org in the ASF policy. I think that is general practice in many
projects, but then we still need to keep a copy of the hashes from the
closed staging repo in the VOTE thread, as the staging repo disappears
after publishing. We would then need more official mirrors)

> It's not clear to me whether it is necessary to use for build tools.

That depends if its needed for third party building or not. In theory I
should be able to grab whatever I need from dist.apache.org (and archive)
to verify and build anything under org.apache and commons* in Maven
Central. Obviously for other Maven Central dependencies I would need to do
the same from their upstream sources.

This is what Linux distributions like Debian do - with their own mirroring
and patching thrown into the mix.

Source code can also be accessed on demand from svn/git, but it is
currently ASF policy that the source code tar/zip on the dist mirrors are
the Gold Standard after a VOTE - I don't know how much leeway Commons PMC
have here, but I found it confusing that an older version 1.4 was on dist,
but not 1.5, even though 1.5 is in Central and on the website.

I think it's OK to not release something that is only needed say for
updating a Commons components website (as is the main purpose of this
particular plugin) or the release process, but then the internal tool
should not be distributed as "released" itself, as that implies something
more within ASF. (e.g. that we have checked the license headers :))

BTW, you are free to ignore my -1 - this is a just my opinion flopping in
from the side corner! ;))

Re: [VOTE][LAZY] Release Commons Build Plugin 1.6 based on RC1

[Stian Soiland-Reyes]

On 18 Apr 2016 4:48 p.m., "sebb"  wrote:
> > (I would still say -1 until the RC is on dist.apache.org)
>
> I'm not convinced it's necessary.

Agreed, as you have provided hashes, so its not necessary to upload also to
dev/commons on dist, although that is the practice for other component
release candidates.

I just wanted to check if it will go to dist after the release VOTE is
passed, and if so, what goes there.

Re: [ALL] Missing -bin suffixes for some modules in dist.apache.org

[Stian Soiland-Reyes]

Well, if we move to the new layout without binaries/ and sources/
subfolders, (see other thread), then the filenames should include -src and
-bin so it is obvious which is which.

In most (modern) cases such dist files are made by the assembly plugin from
Maven, in which case that config needs to be fixed if it generates the
"wrong" filename, ready for the next release.

I am not suggesting a new release of say bsf just to fix the generated
filename :)
On 18 Apr 2016 10:01 p.m., "Jörg Schaible"  wrote:

> Hi Stian,
>
> Stian Soiland-Reyes wrote:
>
> > These downloads lack -bin / -src suffixes:
> >
> > On 18 April 2016 at 10:43, Stian Soiland-Reyes  wrote:
> >> stain@biggie:~/Downloads/912/mirrors.ukfast.co.uk/sites/ftp.apache.org$
> >> find . -type f | grep -v txt  | grep -v -- -src.tar.gz | grep -v --
> >> -src.zip | grep -v -- -bin.zip | grep -v -- -bin.tar.gz
> >>
>
> [snip]
>
> >
> > We need to check if this their POMs need updating or if this is mainly
> > manually made releases.
>
> These are the official commons releases, they have nothing to do with Maven
> repositories. POMs are completely unrelated.
>
> - Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE][ALL] (lazy consensus) Commons Parent 40 based on RC2

[Stian Soiland-Reyes]

Vote: 0 (non-binding)

+1 Signatures, hashes
+1 mvn apache-rat:check :)
+1 mvn install
+1 mvn -Prelease release:prepare -DdryRun=true on commons rdf using 40
as parent  (but see below)
-1 No archive for https://dist.apache.org/repos/dist/release/commons/
-1 Not using latest commons-skin 4.1


This doesn't use the latest version of commons-skin 4.1 (fixes COMMONSSITE-82)
but as that only affects projects outside http://commons.apache.org/
(e.g. only http://commonsrdf.incubator.apache.org/ ) I won't block on
that.



BTW - this failed when I try to use 40 as parent in Commons RDF with
mvn clean install -Prelease :

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-antrun-plugin:1.8:run (default-cli) on
project commons-rdf-parent: An Ant BuildException has occured: Specify
at least one source - a file or a resource collection.
[ERROR] around Ant part .. @ 4:44 in
/home/stain/src/incubator-commonsrdf/target/antrun/build-main.xml
[ERROR] -> [Help 1]

It seems related to this change to the Commons pom for the assembly plugin:


verify

As now our (probably unnecessary) antrun for hashing the dist-files in
target/ was run too early, in phase package:

https://github.com/apache/incubator-commonsrdf/blob/master/pom.xml#L471


I modified the Commons RDF antrun to verify and it was
fine - so I won't block on that.

On 17 April 2016 at 12:50, sebb  wrote:
> Second try:
>
> The Apache Commons Parent POM provides common settings for all Apache
> Commons components.
>
>
> This is a VOTE to release Commons Parent 40 based on RC2
>
>
> This VOTE by LAZY-CONSENSUS is open for at least 72 hours
> It will close sometime after April 20 12:00 UTC
>
>
> Changes in this version include:
>
> - Update Apache parent: 16 -> 17
> - COMMONSSITE-87 - ensure assembly plugin runs after all package phase plugins
> - Require minimum of Maven 3.0.5
> - maven-release-plugin 2.5.2 -> 2.5.3
> - buildnumber-maven-plugin 1.3 -> 1.4 (supports git SCM now)
> - maven-assembly-plugin 2.5.5 -> 2.6
> - maven-surefire-plugin 2.18.1 -> 2.19.1
> - maven-compiler-plugin : 3.3 -> 3.5.1
> - maven-changes-plugin : 2.11 -> 2.12
> - commons-build-plugin : 1.4 -> 1.5
> - felix:maven-bundle-plugin : 2.5.3 -> 3.0.1
> - maven-enforcer-plugin : 1.3.1 -> 1.4.1
> - maven-project-info-reports-plugin : 2.8 -> 2.9
> - maven-source-plugin : 2.4 -> 3.0.0
> - animal-sniffer-maven-plugin : 1.11 -> 1.15
> - build-helper-maven-plugin : 1.9.1 -> 1.10
> - clirr-maven-plugin : 2.6.1 -> 2.7
> - jacoco-maven-plugin : 0.7.5.201505241946 -> 0.7.6.201602180812
> - maven-clean-plugin : 2.6.1 -> 3.0.0
>
>
> The files (staged and md5sums):
>   
> https://repository.apache.org/content/repositories/orgapachecommons-1151/org/apache/commons/commons-parent/40/
>
> commons-parent-40.pom
> (SHA1: fe1642ea816ce800027c12f25d910dc76e0ae9ca)
> commons-parent-40-site.xml
> (SHA1: 4d6ee815f328527d2cf5319c0f7a00414ef1ffab)
>
>
> The tag:
>
> https://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-40-RC2
>   Revision:  1739583
>
> The site: None.
>
> -
> 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 RDF (incubating)
http://orcid.org/-0001-9842-9718

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

Re: [VOTE][ALL] (lazy consensus) Commons Parent 40 based on RC2

[Stian Soiland-Reyes]

Sorry, I'll have to change that to -1 as the pom fails with Java 6 and
Maven 3.0.5

Caused by: java.lang.UnsupportedClassVersionError:
org/codehaus/mojo/buildhelper/ParseVersionMojo : Unsupported
major.minor version 51.
[ERROR] Failed to execute goal
org.codehaus.mojo:build-helper-maven-plugin:1.10:parse-version
(parse-version) on project commons-parent: Execution parse-version of
goal org.codehaus.mojo:build-helper-maven-plugin:1.10:parse-version
failed: Unable to load the mojo 'parse-version' in the plugin
'org.codehaus.mojo:build-helper-maven-plugin:1.10' due to an API
incompatibility:
org.codehaus.plexus.component.repository.exception.ComponentLookupException:
org/codehaus/mojo/buildhelper/ParseVersionMojo : Unsupported
major.minor version 51.0



Using
docker run -it java:6 bash  (c303b30f54b5)
https://archive.apache.org/dist/maven/maven-3/3.0.5/binaries/apache-maven-3.0.5-bin.tar.gz.sha1
svn co 
https://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-40-RC2/

(adding -Pjava-1.6 does not help)

yet the pom.xml claims:


1.3
1.3


Are we able to downgrade build-helper-maven-plugin if JDK < 1.7?   Or
do we simply say that you need Java >=1.7  now? (In which case the
above should change).

btw - build-helper-maven-plugin is activated by the
parse-target-version profile for every build to - ironically perhaps -
set javaTarget.* properties

On 18 April 2016 at 23:43, Stian Soiland-Reyes  wrote:
> Vote: 0 (non-binding)
>
> +1 Signatures, hashes
> +1 mvn apache-rat:check :)
> +1 mvn install
> +1 mvn -Prelease release:prepare -DdryRun=true on commons rdf using 40
> as parent  (but see below)
> -1 No archive for https://dist.apache.org/repos/dist/release/commons/
> -1 Not using latest commons-skin 4.1
>
>
> This doesn't use the latest version of commons-skin 4.1 (fixes COMMONSSITE-82)
> but as that only affects projects outside http://commons.apache.org/
> (e.g. only http://commonsrdf.incubator.apache.org/ ) I won't block on
> that.
>
>
>
> BTW - this failed when I try to use 40 as parent in Commons RDF with
> mvn clean install -Prelease :
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:1.8:run (default-cli) on
> project commons-rdf-parent: An Ant BuildException has occured: Specify
> at least one source - a file or a resource collection.
> [ERROR] around Ant part ... algorithm="MD5">... @ 4:44 in
> /home/stain/src/incubator-commonsrdf/target/antrun/build-main.xml
> [ERROR] -> [Help 1]
>
> It seems related to this change to the Commons pom for the assembly plugin:
>
> 
> verify
>
> As now our (probably unnecessary) antrun for hashing the dist-files in
> target/ was run too early, in phase package:
>
> https://github.com/apache/incubator-commonsrdf/blob/master/pom.xml#L471
>
>
> I modified the Commons RDF antrun to verify and it was
> fine - so I won't block on that.
>
> On 17 April 2016 at 12:50, sebb  wrote:
>> Second try:
>>
>> The Apache Commons Parent POM provides common settings for all Apache
>> Commons components.
>>
>>
>> This is a VOTE to release Commons Parent 40 based on RC2
>>
>>
>> This VOTE by LAZY-CONSENSUS is open for at least 72 hours
>> It will close sometime after April 20 12:00 UTC
>>
>>
>> Changes in this version include:
>>
>> - Update Apache parent: 16 -> 17
>> - COMMONSSITE-87 - ensure assembly plugin runs after all package phase 
>> plugins
>> - Require minimum of Maven 3.0.5
>> - maven-release-plugin 2.5.2 -> 2.5.3
>> - buildnumber-maven-plugin 1.3 -> 1.4 (supports git SCM now)
>> - maven-assembly-plugin 2.5.5 -> 2.6
>> - maven-surefire-plugin 2.18.1 -> 2.19.1
>> - maven-compiler-plugin : 3.3 -> 3.5.1
>> - maven-changes-plugin : 2.11 -> 2.12
>> - commons-build-plugin : 1.4 -> 1.5
>> - felix:maven-bundle-plugin : 2.5.3 -> 3.0.1
>> - maven-enforcer-plugin : 1.3.1 -> 1.4.1
>> - maven-project-info-reports-plugin : 2.8 -> 2.9
>> - maven-source-plugin : 2.4 -> 3.0.0
>> - animal-sniffer-maven-plugin : 1.11 -> 1.15
>> - build-helper-maven-plugin : 1.9.1 -> 1.10
>> - clirr-maven-plugin : 2.6.1 -> 2.7
>> - jacoco-maven-plugin : 0.7.5.201505241946 -> 0.7.6.201602180812
>> - maven-clean-plugin : 2.6.1 -> 3.0.0
>>
>>
>> The files (staged and md5sums):
>>   
>> https://repository.apache.org/content/repositories/orgapachecommons-1151/org/apache/commons/commons-parent/40/
>>
>> commons-parent-40.pom
>> (SHA1: fe1642ea816ce800027c12f25d910dc76e0ae9ca)
>> commons-parent-40-site.xml
>> (SHA1: 4d6ee815f32

Re: [ALL] Missing -bin suffixes for some modules in dist.apache.org

[Stian Soiland-Reyes]

OK, so I get that the feeling is that we can copy the existing releases to
a new folder structure, but can keep the original filenames - even when
there is no -bin suffix for the binary (as there is an equivalent -src
archive).

That way there will also be less confusion if the artifacts are the same or
not for those older versions and don't affect the .asc signatures.
On 18 Apr 2016 11:28 p.m., "sebb"  wrote:

On 18 April 2016 at 22:27, Stian Soiland-Reyes  wrote:
> Well, if we move to the new layout without binaries/ and sources/
> subfolders, (see other thread), then the filenames should include -src and
> -bin so it is obvious which is which.

It's still possible to tell them apart; only the source has -src in it.

But I agree it's clearer if the binaries include -bin.

That will be the case unless someone defines appendAssemblyId=false in
assembly/bin.xml

> In most (modern) cases such dist files are made by the assembly plugin
from
> Maven, in which case that config needs to be fixed if it generates the
> "wrong" filename, ready for the next release.
>
> I am not suggesting a new release of say bsf just to fix the generated
> filename :)

AFAIK, there is no need.

It seems the missing -bin suffixes are a hangover from Maven 1.
The default is to append -bin now (this is defined in Commons Parent);
it's only necessary to override the suffix for some of the older
releases.

> On 18 Apr 2016 10:01 p.m., "Jörg Schaible"  wrote:
>
>> Hi Stian,
>>
>> Stian Soiland-Reyes wrote:
>>
>> > These downloads lack -bin / -src suffixes:
>> >
>> > On 18 April 2016 at 10:43, Stian Soiland-Reyes 
wrote:
>> >> stain@biggie:~/Downloads/912/
mirrors.ukfast.co.uk/sites/ftp.apache.org$
>> >> find . -type f | grep -v txt  | grep -v -- -src.tar.gz | grep -v --
>> >> -src.zip | grep -v -- -bin.zip | grep -v -- -bin.tar.gz
>> >>
>>
>> [snip]
>>
>> >
>> > We need to check if this their POMs need updating or if this is mainly
>> > manually made releases.
>>
>> These are the official commons releases, they have nothing to do with
Maven
>> repositories. POMs are completely unrelated.
>>
>> - Jörg
>>
>>
>> -
>> 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

Fwd: Google Summer of Code 2017 Mentor Registration

[Stian Soiland-Reyes]

Do we have any GSOC2017 ideas for Apache Commons? Tag them with the label
"gsoc2017" in Jira!


Any volunteers to mentor GSOC2017 students? All committers are eligible, I
guess for Commons that is a bit special (as all ASF committers have write
access), but I guess if you have contributed before to any of the Commons
components that should be sufficient.

GSOC is a good way to engage with fresh developers, and the ideas can be
both new/experimental features or incremental improvements and refactoring;
although I will admit the first type of ideas often gets more interest.

Apache Commons can be a good target for GSOC students as most of our
components are independent and easy to get started with.

-- Forwarded message --
From: "Ulrich Stärk" 
Date: 6 Mar 2017 7:39 pm
Subject: Google Summer of Code 2017 Mentor Registration
To: 
Cc: "d...@community.apache.org" 

Dear PMCs,

I'm happy to announce that the ASF has made it onto the list of accepted
organizations for
Google Summer of Code 2017! [1,2]

It is now time for mentors to sign up, so please pass this email on to your
community and
podlings. If you aren’t already subscribed to ment...@community.apache.org
you should do so now else
you might miss important information.

Mentor signup requires two steps: mentor signup in Google's system [3] and
PMC acknowledgement.

If you want to mentor a project in this year's SoC you will have to

1. Be an Apache committer.
2. Request an acknowledgement from the PMC for which you want to mentor
projects. Use the below
template and *do not forget to copy ment...@community.apache.org*. We will
use the email adress you
indicate to send the invite to be a mentor for Apache.

PMCs, read carefully please.

We request that each mentor is acknowledged by a PMC member. This is to
ensure the mentor is in good
standing with the community. When you receive a request for
acknowledgement, please ACK it and cc
ment...@community.apache.org

Lastly, it is not yet too late to record your ideas in Jira (see my
previous emails for details).
Students will now begin to explore ideas so if you haven’t already done so,
record your ideas
immediately!

Cheers,

Uli

mentor request email template:

to: private@.apache.org
cc: ment...@community.apache.org
subject: GSoC 2017 mentor request for 

 PMC,

please acknowledge my request to become a mentor for Google Summer of Code
2017 projects for Apache
.

I would like to receive the mentor invite to 





[1] https://summerofcode.withgoogle.com/organizations/
[2] https://summerofcode.withgoogle.com/organizations/5416945173135360/
[3] https://summerofcode.withgoogle.com/

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

Re: [lang]

[Stian Soiland-Reyes]

Adding a class with a plan to @deprecate it, something doesn't sound right.
:)

We should not be putting much effort (and future maintainability) into
adding functionality in Lang that jdk8 already (easily) can do. The point
of Lang is to complement JDK's Lang classes and friends, not to backport
what the current JDK has already added.

(Obviously existing Lang functionality is or will be superseded by new JDK
additions, that just shows that the philosophy of Lang is right.)

If you are stuck in jdk7 you are often also stuck with older Commons Lang.
(Oversimplification, yes)

We have java7 as target (I'm positive to bump it to 8) - but primarily for
backwards compatibility as Lang is ubiquitous and it makes sense to stay
one behind. But we don't need to add *new* backwards compatibility :)

We could make excemptions and do backports, but then I think that should be
for more core JDK8 improvements like Optional.

That said, your implementation is straightforward​, useful, and unlikely to
cause trouble; I would not veto your commit if it goes forward ;)


On 1 May 2017 9:40 pm, "Gary Gregory"  wrote:

In my mind, we target a given platform, in this case its Java 7. So the
proposal is valid IMO. Then when switch to Java 8, we can mark the class as
deprecated and remove it in 4.0. I'm not hard set on including this
specific class, it's just something I use.

Re: [Numbers] NUMBERS-33

[Stian Soiland-Reyes]

Thanks!

Not being a mathematician I am afraid I have not been able to review the
correctness of the equation use.

Overall the addition looks good and well commented. The javadoc is a bit
sparse and could do with some more hyperlinks.

 I have some code design questions you may be able to clarify:

* Why have static methods all called value()? Static methods are good as
they can be imported independently (and without wasting object state), yet
by calling all the public methods .value() only one can be imported, and
with a meaningless name; we are forced instead to always call them via the
class Gamma.value()

* Why do some of the package private classes (e.g. InvGamma1pm1) have a
needless static singleton instance and a single method (and no state), when
here as well a static method would do? The only reason I can see for this
is to implement interfaces or subclasses, yet none of those seem to be
present, and these could rather follow the same pattern as the public API
with private constructors.

Won't this loop loose precision on digamma? (Could be called up to 49 times)

while (x < C_LIMIT) {
+ digamma -= 1 / x;
+ x += 1;
+ }

In this loop I was confused as the formula does not at first seem to match
the code:
final double inv = 1 / (x * x);
+ // 1 1 1 1
+ // log(x) - --- - -- + --- - ---
+ // 2 x 12 x^2 120 x^4 252 x^6
+ digamma += Math.log(x) - 0.5 / x - inv * (F_1_12 + inv * (F_1_120 -
F_1_252 * inv));
+
+ return digamma;

Here and other places:
/** Helper. */
+ private static final InvGamma1pm1 INV_GAMMA_1P_M1 = InvGamma1pm1.instance;

Unless there were state to initialize in certain order I don't see the
benefit of this field wastage over just calling InvGamma1pm1.value()
directly.

Based on the NSWC Library of Mathematics Subroutines double
+ * precision implementation, {@code DGAMMA}.

What is the license/url of this nswc code? What is the nature of "based on"
here?



On 8 May 2017 1:30 am, "Gilles"  wrote:

Hi.

Please review branch "task_NUMBERS-33__Gamma":
  https://issues.apache.org/jira/browse/NUMBERS-33

Thanks,
Gilles


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

Re: [Numbers] NUMBERS-33

[Stian Soiland-Reyes]

On Mon, 08 May 2017 14:16:12 +0200, Gilles  wrote:
> > Overall the addition looks good and well commented. The javadoc is a 
> > bit
> > sparse and could do with some more hyperlinks.
> Strange; I thought that it was doing rather well on this point.
> Can you be more specific? [Please open a JIRA report.]

Just thought it would be good with a quick one-liner about what the
gamma function is rather than a link to Wolfram Alpha. I added something
generic like:

 * The Gamma function can be seen to extend the factorial function to cover
 * real and complex numbers, but with its argument shifted by 
 * {@code * -1}. This implementation supports real numbers.

(BTW - why does it not support complex numbers?)

> The original (CM) design contained in single big class and static
> methods for all the functions.
> I thought it would be clearer to split it into several classes (each
> with its own unit test class).

Yes, this is a very good design choice, I agree with this.  Part of the
javadoc improvements I tried to add is to also then relate the new
classes to eachother, so I added say a @see Gamma back from Digamma.

 
> One goal was to switch away from static methods, to allow an easy path
> to using the Java 8 functional interfaces.
> [Help is most welcome to check that it will indeed be the case.]

Hm, good insentive - but I don't think this helps much.. The only way I
could use it now is to make a new instance, which looks awkward:

import org.apache.commons.numbers.gamma.Gamma;

@Test
public void streamGamma() throws Exception {
List numbers = 
Arrays.asList(-2.1,-2.0,-1.99,-1.95,-1.9,-1.8,-1.7,-1.6,-1.5,-1.4,-1.3,-1.2,-1.1,-1.0,-0.9);
Stream d = numbers.parallelStream().map(new Gamma()::value);
d.forEachOrdered(System.out::println);
}

Passing just "new Gamma()" won't work as it does not implement any 
@FunctionalInterface. 


If I make the method static and rename it to "gamma", then I can do the much
simpler:

Stream d = numbers.parallelStream().map(Gamma::gamma);

.. as well as import it as a static reference (however Java 8 won't allow 
passing just "gamma").

I can only see this "value()" style make sense if there is also a common
interface, perhaps DoubleFunction?
https://docs.oracle.com/javase/8/docs/api/java/util/function/DoubleFunction.html

.. but this uses apply(x).


 
> I've fixed "Digamma" and "Trigamma" that still inadvertently contained
> static methods.
> Thanks for spotting it.

Hm, but you fixed it the wrong way? :) Now they are all called value() and are
non-static.. why do we need to make instances of these classes which only state
is to other static helper classes?

> The "instance" field is for use "helper" in other classes in the 
> package,
> to avoid a few unnecessary instantiations.
> But I tend to agree that it is perhaps not worth it.

If the class has a public constructor there will be many instansiations of the 
class.
Now it is quite hard to check the class is actually immutable, as we have to
check these fields.  

I know there many good arguments against implicit static initializers, as it
can be quite tricky to determine the initialization order. Referring to such 
instances from static fields can cause such issues. (I don't think that's the
case here though).


> Cf. above.
> I'd be willing to make this package target Java 8. [Any objections?]

+100!  (All of Commons Numbers, presumably)

 

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

Re: [Numbers] NUMBERS-33

[Stian Soiland-Reyes]

On Tue, 9 May 2017 13:29:21 +0100, Stian Soiland-Reyes  wrote:
> I can only see this "value()" style make sense if there is also a common
> interface, perhaps DoubleFunction?
> https://docs.oracle.com/javase/8/docs/api/java/util/function/DoubleFunction.html

DoubleUnaryOperator would be better - double applyDouble(double) - then
Gamma can be used like this with a native DoubleStream:



double[] numbers = { -2.1, -2.0, -1.99, -1.95, -1.9, -1.8, -1.7, -1.6, -1.5, 
-1.4, -1.3, -1.2, -1.1, -1.0,
-0.9 };
Arrays.stream(numbers).map(new Gamma())
.mapToObj(Double::toString)
.forEachOrdered(System.out::println);


Or even -- if you permit:

  DoubleStream d = new Random().doubles().map(new Gamma());


https://docs.oracle.com/javase/8/docs/api/java/util/function/DoubleUnaryOperator.html


Not sure I like the function name "applyDouble(x)" though.. We could have a
static gamma() method (etc) as well.

===

One thought (which don't work too well with Streams without helper functions or
Gamma::new)):

If we are making instances of Gamma, then you could make it extend Number and
take the "x" argument in the constructor:

Number g = new Gamma(0.4);
System.out.println(g.floatValue());

Evaluation of the gamma function can be delayed until the first call on any of
the methods.


This is the style recommended by Elegant Objects:
http://www.yegor256.com/2014/05/05/oop-alternative-to-utility-classes.html
.. and would allow us to extend it to complex numbers in the future.


-- 
Stian Soiland-Reyes
The University of Manchester
http://www.esciencelab.org.uk/
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: [Numbers] NUMBERS-33

[Stian Soiland-Reyes]

On Tue, 09 May 2017 14:52:09 +0200, Gilles  wrote:
> [I specifically avoided "apply" so that it is free for when the 
> component
> targets Java 8.]
> 
> Can the "apply" method be static?

No, interface implementations can't be static (and it is not possible to
make an interface of static methods).

> Won't a private constructor (which was my original intention) preclude
> some of the functional usages?
> If not, I'll make the change

Yes, that would make it harder to do say a collection of functions that
you combine in a stream. But they need a common interface, otherwise
they will just happen to have the same name and extend
java.lang.Object..  (If we upgrade to Java8 we won't need to make such
an interface ourselves)
 

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

Re: [ALL] Build Javadoc with Java 9

[Stian Soiland-Reyes]

Agree to wait for Java 9 GA before it's general practice. Would not -1 a
release candidate with nicer Java 9 javadoc though!

With Java 8 there were many issues with javadoc checks and options
incompatible with Java 7. I  I don't know if anything changes  here for
Java 9, but trying to comply both with Java 8 and a pre-release of Java 9
sounds like wasted effort if Java 9 javadoc defaults still can change.

On 17 May 2017 9:55 pm, "Benedikt Ritter"  wrote:

> Hi,
>
> > Am 17.05.2017 um 15:25 schrieb Gary Gregory :
> >
> > Hi All:
> >
> > I wonder if we should build all of our Javadocs for our sites with Java 9
> > since it provides nice new features like searchable Javadocs and HTML5.
> > Notice the search box on the page
> > http://download.java.net/java/jdk9/docs/api/overview-summary.html <
> http://download.java.net/java/jdk9/docs/api/overview-summary.html>
>
> Looks nice! But I think every RM should decide which JDK she want’s to
> build the JavaDocs with. I for example wait until Java 9 goes GA, before I
> use it as my main build environment.
>
> Regards,
> Benedikt
>
> >
> > Gary
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > Java Persistence with Hibernate, Second Edition
> >  tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
> >
> >  1617290459>
> > JUnit in Action, Second Edition
> >  tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22
> >
> >
> >  1935182021>
> > Spring Batch in Action
> >  tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&
> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> >  1935182951>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
>

Re: [all] Should our gitignore files contain only build-related entries?

[Stian Soiland-Reyes]

On Sat, 27 May 2017 11:37:54 -0400, Rob Tompkins  wrote:
> 
> 
> > On May 27, 2017, at 11:25 AM, Gary Gregory  wrote:
> > 
> > On May 27, 2017 7:23 AM, "Bernd Eckenfels"  wrote:
> > 
> > I vote for a default set optimized for build-related file but allow all
> > commiters to include relevant files (Specifically Editor and IDE specific).
> > One could set up this locally, but it is a better experience for new
> > developers if they use common tools and don't hit a dirty repo. After all a
> > few more lines in .gitignore do not hurt...
> > 
> 
> +1 to IntelliJ, eclipse, mac auto generated files (e.g. .DS_STORE), windows 
> auto generates files, and any other files that could arbitrarily end up in 
> the directory. Furthermore, you can override the .gitignore at commit time 
> with "git commit --force"

+1 to include the "usual IDE suspects" (emacs ~ files anyone?) in
the .gitignore, particularly for Commons which may see many "drive by"
contributors who don't have their global gitignore perfectly set up. (I
don't even have one!)

Should we add it to 
https://commons.apache.org/proper/commons-build-plugin/
or keep the .gitignores drifting per component?

-- 
Stian Soiland-Reyes
The University of Manchester
http://www.esciencelab.org.uk/
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] Deploying components

[Stian Soiland-Reyes]

Personally I am happy about source distributions accompanying the jars in
Maven Central, which are actually rebuildable as opposed to the
-source.jars.

they continue to be retrievable using Maven version mechanisms, compares to
more fragile scripts crawling archive.apache.org (dist only contains the
latest version).

The -bin archives are less useful, however I have used their hashes during
RC testing to confirm the jars in staging reasonably match the RC in dist
(this can also be achieved by simply unpacking the binary dist and
navigating to the jars)



On 28 May 2017 3:01 am, "Rob Tompkins"  wrote:

> Hello all,
>
> Benedikt and I were chatting last week about how the .tar and .zip
> distributions get uploaded to nexus during "mvn deploy” and how annoying
> that side effect of the deployment happens to be. Coincidentally, I just
> ran across a note that  Mladen Turk added at the end of the commons-daemon
> release guide:
>
> https://github.com/apache/commons-daemon/blob/trunk/
> HOWTO-RELEASE.txt#L41-L43  commons-daemon/blob/trunk/HOWTO-RELEASE.txt#L41-L43>
>
> I’m thinking: (1) interesting note, knowing that the problem still exists,
> and (2) I wonder if there would be community appetite for an attempt at
> adding better automation to the release process. I’m betting that with a
> little effort we probably could improve the release experience at least a
> little.
>
> Cheers,
> -Rob

Re: [launcher] Move to dormant?

[Stian Soiland-Reyes]

On 13 Aug 2017 7:43 pm, "Pascal Schumacher" 
wrote:

Hello everybody,

an opinions on moving commons-launcher to dormant?

The last release is from 2007 and their have not been any bugfix or feature
addition commits since.


+1

Re: [CSV][POLL] How to provide mutable records

[Stian Soiland-Reyes]

This came up also for commons rdf where we also have everything immutable,
which I think is a good principle to keep for modern Java 8 programming.

So you need a mutator function like in (4) that either returns a new
immutable (but changed) CSVRecord; or alternatively a different
MutableCSVRecord that can then be built/frozen to a CSVRecord. (These can
then share a common accessor interface for the passive functions)

Is there likely to be many changes to each CSVRecord or just one on each?

On 25 Aug 2017 7:05 pm, "Gary Gregory"  wrote:

On Mon, Aug 21, 2017 at 3:29 PM, sebb  wrote:

> On 21 August 2017 at 21:04, Gary Gregory  wrote:
> > Hi All,
> >
> > We have a request for [CSV] to provide mutable records. There is no
clear
> > consensus to me on how to do this. The current CSVRecord class is
> immutable
> > but is not documented as such. I attribute that to YAGNI up to now.
> >
> > Options range from simply making CSVRecord immutable to creating a new
> > CSVMutableRecord class and a few things in between.
> >
> > I'd like to get a feel what the community thinks here. IMO this boils
> down
> > to whether or not it matters that CSVRecord remains immutable.
> >
> > [0] do nothing
> >
> > [1] Add two put methods to CVSRecord making the class mutable:
> > put(int,Object) and put(String,Object). This does not break BC but
> changes
> > the runtime behavior for apps that expect immutable record and shard the
> > records with other components.
> >
> > [2] Add a "mutableRecord" boolean option to CVSRecord and CSVFormat such
> > that a new boolean in CVSRecord allow method from 1) above to either
work
> > or throw an exception.
> >
> > [3] Add a "mutableRecord" boolean option to CVSRecord and CSVFormat such
> > that subclass of CVSRecord called CVSMutableRecord is created which
> > contains two new put methods. See branch CSV-216.
> >
> > [4] The factory method:
> >  /**
> >   * @param orig Original to be copied.
> >   * @param replace Fields to be replaced.
> >   * @return a copy of "orig", except for the fields in "replace".
> >   */
> >  public static CSVRecord createRecord(CSVRecord orig,
> >   Pair ... replace)
> >
> > Could also be:
> >  public static CSVRecord createRecord(CSVRecord orig,
> >   int[] replaceIndices,
> >   String[] replaceValues)
> >
> > I like the simplicity of [1] and I coded [3] to see how cumbersome that
> > feels.
> >
> > So my preference is [1].
>
> What about [4]?
>
> Would that be more complicated/cumbersome to use than [1]?
>
> Seems to me using a factory or builder to create an updated immutable
> copy is the way to go here.
>

You mean a "mutable" copy right? Because the records are currently
immutable.

Gary


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

Re: [IO] Releasing 2.6

[Stian Soiland-Reyes]

I only got one error on Windows 10 – thanks for the fixes, Pascal and Gary!


The new error is:
  FileSystemUtilsTestCase.testGetFreeSpace_String:89
expected:<1.02861164E8> but was:<1.0286066E8>


I have:
   5 Dir(s)  104,991,649,792 bytes free

Test calls:

final long bytes = FileSystemUtils.freeSpace("");
final long kb = FileSystemUtils.freeSpaceKb("");
assertEquals((double) bytes / 1024, kb, 256d);


Presumably something else on my machine downloaded 504 kB between the
two freeSpace calls – which is not much these days – perhaps one email
:-)

I changed the test to use instead a 1% delta, which should generally
be a considerable amount of disk space (1 GB in my case), which is
still small enough to detect the ~2.4% difference between a kilobyte
vs kibibyte (the legacy freeSpaceKb is misnamed, it actually returns
kibibyte instead of pre-1998 “kilobyte”)

Also added javadoc that it's actually kibibytes -- perhaps a bit too
late :-) -- IO-506 deprecated the remaining methods of FileSystemUtils
in favour of java.nio.file.FileStore -- I think then we can deprecate
the whole FileSystemUtils  class as well.


On 27 September 2017 at 20:24, Pascal Schumacher
 wrote:
> Great!
>
> That should reduce the number of random test failures.
>
> I was just taking a look at this and the usage patterns of the folder looked
> horrible. :/
>
> Cheers,
> Pascal
>
>
> Am 27.09.2017 um 21:19 schrieb Gary Gregory:
>>
>> I updated the tests to use JUnit's TemporaryFolder rule instead of the old
>> custom and _shared_ folder. No more random errors.
>>
>> Gary
>>
>> On Wed, Sep 27, 2017 at 1:05 PM, Pascal Schumacher
>> >>
>>> wrote:
>>> Am 27.09.2017 um 19:58 schrieb Gary Gregory:
>>>
>>>> I wonder if we need to force Maven to disable any concurrency when
>>>> running
>>>> tests?
>>>>
>>> That should not be necessary.
>>>
>>> Maven/Maven-Surefire-Plugin does not run test in parallel by default. The
>>> surefire configuration of commons-io does not specify the parallel
>>> parameter and the forkcount parameter is set to 1 so the tests should be
>>> executed sequentially.
>>>
>>> Cheers,
>>> Pascal
>>>
>>>
>>> -
>>> 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
>



-- 
Stian Soiland-Reyes
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: [VOTE] Release Apache Commons RDF 0.5.0 from RC1

[Stian Soiland-Reyes]

;>
>> On Thu, Nov 2, 2017 at 4:00 AM, Bruno P. Kinoshita <
>> brunodepau...@yahoo.com.br.invalid> wrote:
>> >
>> > Any plans to use the changes.xml file for next releases?
>>
>> Sound like a good idea to me. Registwered as COMMONSRDF-68 for the next
>> release.
>>
>> > I have an automated script that downloads the KEYS file from
>> https://www.apache.org/dist/commons/KEYS,
>> > and it failed. Then re-read the e-mail and found the KEYS here
>> https://dist.apache.org/repos/dist/release/incubator/commonsrdf/KEYS:
>> >
>> > Does it matter which KEYS file is used after the component has been
>> graduated?
>> > I'm fine with the KEYS file location being in the vote thread, but just
>> thought it
>> > would be worth checking.
>>
>> As I pointed in a previous thread, although we graduated as a component,
>> most of the team behind the RDF component we are not PMC members. I don't
>> have karma for that, but someone should add our KEYS there. I just though
>> the file we had during incubation was good enough.
>>
>>
>> > Another minor nit pick: Notice file message was not updated to 2017.
>>
>> Do you think that could be blocking? Well, noted as COMMONSRDF-69 for now.
>>
>>
>> Thanks.
>>
>>
>>



-- 
Stian Soiland-Reyes
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: [VOTE] Release Apache Commons RDF 0.5.0 based on RC2

[Stian Soiland-Reyes]

Good effort, Sergio! Sorry for late review.
I guess you didn't get to many replies as there was confusion with the
dist/svn revision.. :-(


Sorry, my vote is -1 (binding)

.. as META-INF/LICENSE and META-INF/NOTICE are missing in the binary
JARs in the maven repo.

(Not sure how I missed this before, is this caused by a change in
commons-parent affecting submodules?)


+1 gpg signatures dist & staging
+1 dist svn (revision 23205 and 23227 are equal in this subtree)
+1 git commit == tag ~= dist ~= staging  (except .gitignore / .travis.yml)
-0 NOTICE has wrong Copyright year
+1 builds with mvn clean install -T1.0C
-1 META-INF/LICENSE and META-INF/NOTICE missing from JARs (except -api
and -impl)


Built with:

Apache Maven 3.3.9
Maven home: /usr/share/maven
Java version: 1.8.0_151, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.10.0-40-generic", arch: "amd64", family: "unix"

On 4 December 2017 at 11:13, Sergio Fernández  wrote:
> I'd like to bring up this vote, which is waiting for votes for two weeks :-/
>
>
> On Nov 26, 2017 13:21, "Sergio Fernández"  wrote:
>
> I'd like to ask the Commons PMC to cast a, any, vote for this RC. Because
> it's stuck. It's fine to get -1s, but at least something to move forward.
> Thanks.
>
> On Nov 22, 2017 17:52, "Sergio Fernández"  wrote:
>
>> Hi Oliver,
>>
>> thanks for the feedback on RC2. Please, find my answers inline.
>>
>> On Wed, Nov 22, 2017 at 1:25 PM, Oliver Heger <
>> oliver.he...@oliver-heger.de> wrote:
>>>
>>> [ERROR] Failed to execute goal
>>> org.apache.maven.plugins:maven-site-plugin:3.6:site (default-cli) on
>>> project commons-rdf-parent: Error generating
>>> maven-checkstyle-plugin:2.12.1:checkstyle-aggregate: Failed during
>>> checkstyle configuration: cannot initialize module TreeWalker - Property
>>> 'ignoreAnnotationCanonicalNames' in module VisibilityModifier does not
>>> exist, please check the documentation -> [Help 1]
>>>
>>> A problem with the version of the checkstyle plugin?
>>>
>>
>>  Maybe..., the version comes from Commons Parent. The issue is that I'm
>> not able to reproduce the problem in Unix, neither in Linux nor OSX.
>>
>> Some other notes:
>>> * NOTICE has the wrong copyright year. I think this needs to be fixed.
>>>
>>
>> Yeah, I reported that as https://issues.apache.org/j
>> ira/browse/COMMONSRDF-69
>>
>>
>>> * The project does not release binary artifacts. This is probably okay,
>>> but unusual for Commons. It would be nice if you could add a binary
>>> distribution - maybe for the 1.0 release.
>>>
>>
>> Afterwards I updated the vote to include the binary release, too:
>>
>> https://lists.apache.org/thread.html/23cf46d92c2afa191690edc
>> a5ea76c0882c108c1a9dc1709a9d9ee52@%3Cdev.commons.apache.org%3E
>>
>> Thanks.
>>
>>
>>
>> Am 19.11.2017 um 23:08 schrieb Sergio Fernández:
>> > Hi,
>> >
>> > once we addressed most of the issues from RC1, I'd like to propose to
>> > release Apache Commons RDF 0.5.0 based on RC2.
>> >
>> > Apache Commons RDF aims to provide a common Java API for RDF 1.1 graphs
>> and
>> > datasets. API bindings in Commons RDF 0.5.0 include Apache Jena, Eclipse
>> > RDF4J, JSON-LD Java as well as a standalone implementation (simple).
>> >
>> > Apache Commons RDF 0.5.0 RC2 is available for review at (r23205):
>> >
>> > https://dist.apache.org/repos/dist/dev/commons/rdf/apache-co
>> mmons-rdf-0.5.0-RC2/
>> >
>> > The source code for this RC is available from git tagged as 0.5.0-RC2
>> > (commit 186df0c36981a308338792f02d93fc59776b0b7c):
>> >
>> > https://git-wip-us.apache.org/repos/asf?p=commons-rdf.git;a=
>> commit;h=186df0c36981a308338792f02d93fc59776b0b7c
>> >
>> > Mirrored at
>> > https://github.com/apache/commons-rdf/commit/186df0c36981a30
>> 8338792f02d93fc59776b0b7c
>> >
>> > This source release produces the following binary artifacts:
>> >
>> > commons-rdf-parent-0.5.0
>> > commons-rdf-api-0.5.0
>> > commons-rdf-simple-0.5.0
>> > commons-rdf-jena-0.5.0
>> > commons-rdf-rdf4j-0.5.0
>> > commons-rdf-jsonld-java-0.5.0
>> > commons-rdf-integration-tests-0.5.0
>> >
>> > The Maven Staging repository can be found at:
>> >
>> >

Re: [VOTE] Release Commons Release Plugin 1.0 base on RC1

[Stian Soiland-Reyes]

+1 (Binding)

(While I might disagree in principle about removing source .tar.gz and
.zip from Maven repo, I say let's get the plugin released and find
more bugs later! :) )

Checked:

+1 gpg signatures
+1 sha1, md5
+1 source zip vs tar.gz
+1 binary zip vs tar.gz
+1 source vs git (for some reason git has duplicate LICENSE as well as
LICENSE.txt)
+1 mvn apache-rat:check
+1 no binaries (except test archives)
+1 LICENSE, NOTICE
+0 README refers to
https://commons.apache.org/proper/commons-commons-release-plugin/javadocs/api-release
which is 404 Not Found (site.zip has apidocs/)
+1 RELEASE-NOTES
+1 mvn clean install
+0 mvn repository kind of matches src? *)

*) I was unable to verify that
https://repository.apache.org/content/repositories/orgapachecommons-1302
contained artifacts from building this RC as the Maven repo do not
include the source zip/tar.gz (see principle above)




Tested with:

Apache Maven 3.3.9
Maven home: /usr/share/maven
Java version: 1.8.0_151, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.13.0-26-generic", arch: "amd64", family: "unix"

On 11 January 2018 at 02:50, Rob Tompkins  wrote:
> Hello all,
>
> This is a [VOTE] for releasing Apache commons-release-plugin 1.0 (from RC1).
>
> Tag name:
>commons-release-plugin-1.0-RC1 (signature can be checked from git using 
> 'git tag -v')
>
> Tag URL:
>
> https://git-wip-us.apache.org/repos/asf?p=commons-release-plugin.git;a=tag;h=6b05b8bee894ad471c5e1eda979550b344c21020
>
> Commit ID the tag points at:
>2f48a0ebd07318419b4d92a7e7b594f4fca47428
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/commons-release-plugin/site.zip
>
> Distribution files (committed at revision 24125):
>https://dist.apache.org/repos/dist/dev/commons/commons-release-plugin/
>
> Distribution files hashes (SHA1):
>   commons-release-plugin-1.0-bin.tar.gz
>   (SHA1: 02a0e034ed89c87e620ceaf4aef879121d4b87de)
>   commons-release-plugin-1.0-bin.zip
>   (SHA1: e0c4cf6449f6baab4c52c98c1e577512486d8fba)
>   commons-release-plugin-1.0-src.tar.gz
>   (SHA1: e48b67b70b154b7dc69914752814512225024504)
>   commons-release-plugin-1.0-src.zip
>   (SHA1: bc9a6c847899b2700e5873c4ac1a8d983476b255)
>
> These are the Maven artifacts and their hashes:
>   commons-release-plugin-1.0-javadoc.jar
>   (SHA1: bc2cdfa56f55ee538087038a1194ea2789863ca9)
>   commons-release-plugin-1.0-sources.jar
>   (SHA1: eb20eec8580fd5a2633bd2822e951d57043d3d4e)
>   commons-release-plugin-1.0-test-sources.jar
>   (SHA1: 61aa51b44025ced470b0e21b19a3eb65e154df1f)
>   commons-release-plugin-1.0-tests.jar
>   (SHA1: a81f42e01ca77a86048e07963d4ea496a69251f6)
>   commons-release-plugin-1.0.jar
>   (SHA1: 2897ab01d2e8460d100d196db55e53b2a1bab73e)
>   commons-release-plugin-1.0.pom
>   (SHA1: 2bcc663eb212f9a2233acc21773ef80883ac0881)
>
> KEYS file to check signatures:
>http://www.apache.org/dist/commons/KEYS
>
> Maven artifacts:
>https://repository.apache.org/content/repositories/orgapachecommons-1302
>
> Please select one of the following options[1]:
>   [ ] +1 Release it.
>   [ ] +0 Go ahead; I don't care.
>   [ ] -0 There are a few minor glitches: ...
>   [ ] -1 No, do not release it because ...
>
>
> This vote will be open at least 72 hours, i.e. until
> 2018-01-14T03:00:00Z
> (this is UTC time).
>
> 
>
> Cheers,
> -Rob
>
> [1] http://apache.org/foundation/voting.html
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>



-- 
Stian Soiland-Reyes
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] Release 1.6

[Stian Soiland-Reyes]

On Mon, 11 Dec 2017 09:19:46 -0700, Gary Gregory  wrote:
> There is one minor new feature and a proposed fix for
> https://issues.apache.org/jira/browse/CSV-219
>SV-216-with
> I'd like some feedback on CSV-219 before releasing.
> 
> If there is anything you want in a new release, please pipe up.

Hi, I can help do the Commons-CSV 1.6 release.

Do we still need more testing of CSV-219? 



What about mutability in 
https://issues.apache.org/jira/browse/CSV-215 or
https://issues.apache.org/jira/browse/CSV-216

See my take in 
https://github.com/apache/commons-csv/pull/25
proposing mutator functions.





-- 
Stian Soiland-Reyes
The University of Manchester
http://www.esciencelab.org.uk/
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][POLL] How to provide mutable records

[Stian Soiland-Reyes]

On Fri, 25 Aug 2017 19:19:58 +0100, Stian Soiland-Reyes  
wrote:
> This came up also for commons rdf where we also have everything immutable,
> which I think is a good principle to keep for modern Java 8 programming.
> 
> So you need a mutator function like in (4) that either returns a new
> immutable (but changed) CSVRecord; or alternatively a different
> MutableCSVRecord that can then be built/frozen to a CSVRecord. (These can
> then share a common accessor interface for the passive functions)

Picking up this thread to consider this for CSV 1.6.

Not quite as elegant as above, but I made
some mutator functions withValue() in 
https://github.com/apache/commons-csv/pull/25


for (CSVRecord r : csvparser) {
  CSVRecord rSoup = r.withValue(4, "soup")
 .withValue(5, "fish");
  // original r is untouched and can be used again
  CSVRecord rBeans = r.withValue(3, "beans");

  List list;
  // Each now different
  someList.add(r);
  someList.add(rSoup);
  someList.add(rBeans);

  // worried someone might touch your beans?
  consumeCSVRecord(rBeans.immutable())
}

It's not clever enough (yet!) to resize the underlying array if you try to go
outside the existing columns. The existing parser seems to detect column number
(and hence record array size) per line so this might be weird for some
inconsistent CSV files.



Comments and changes on CSV-216 branch welcome.

-- 
Stian Soiland-Reyes
The University of Manchester
http://www.esciencelab.org.uk/
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][POLL] How to provide mutable records

[Stian Soiland-Reyes]

On Mon, 12 Feb 2018 18:10:56 -0700, Gary Gregory  wrote:
> On Fri, Feb 9, 2018 at 10:05 AM, Stian Soiland-Reyes 
> I've not had time to review this yet but I hope to get to it sometimes this
> week.

Thanks. I'll wait for that before prepping a 1.6 RC so we get time to
decide if this is in or not.


-- 
Stian Soiland-Reyes
The University of Manchester
http://www.esciencelab.org.uk/
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: commons-csv git commit: CSV-216: Avoid Arrays.copyOf()

[Stian Soiland-Reyes]

I agree in general for .clone() on objects - and I'm trying to move
away from using .clone() in that Commons RDF fluent mutable/immutable
builder (See COMMONSRDF-49).

But this is an Object[] - a native type.

I must admit I am not sure what is really the preferred way - I
thought .clone() is best as the VM can copy an array natively however
it wants, while with Arrays.copyOf it might have to check if length is
the same before doing anything clever.

On 13 February 2018 at 18:58, Gilles  wrote:
> On Tue, 13 Feb 2018 18:40:13 +, sebb wrote:
>>
>> On 13 February 2018 at 09:31, Gilles  wrote:
>>>
>>> On Tue, 13 Feb 2018 00:16:13 + (UTC), st...@apache.org wrote:
>>>>
>>>>
>>>> Repository: commons-csv
>>>> Updated Branches:
>>>>   refs/heads/CSV-216 637ad2d7a -> f66a83901
>>>>
>>>>
>>>> CSV-216: Avoid Arrays.copyOf()
>>>
>>>
>>>
>>> Why?
>>
>>
>> Agreed
>>
>>>> as .clone() will do
>>>
>>>
>>>
>>> We should rather avoid using "clone()".
>>
>>
>> Again: why?
>
>
> There are many discussions about this topic on the web.[1]
> My point is that using "clone()" is not good advice.
>
> Gilles
>
> [1] E.g. http://vojtechruzicka.com/java-cloning-problems/
>
>
>> It's not clear why Arrays.copyOf(0 is considered bad, nor why clone()
>> is considered bad.
>>
>>
>>> Gilles
>>>
>>>
>>>> -- at least until someone tries to do
>>>> .withValue(x) in an out-of-range column
>>>>
>>>>
>>>> Project: http://git-wip-us.apache.org/repos/asf/commons-csv/repo
>>>> Commit:
>>>> http://git-wip-us.apache.org/repos/asf/commons-csv/commit/f66a8390
>>>> Tree: http://git-wip-us.apache.org/repos/asf/commons-csv/tree/f66a8390
>>>> Diff: http://git-wip-us.apache.org/repos/asf/commons-csv/diff/f66a8390
>>>>
>>>> Branch: refs/heads/CSV-216
>>>> Commit: f66a83901bd026369a2e8d522bd567eb2ef3f8c0
>>>> Parents: 637ad2d
>>>> Author: Stian Soiland-Reyes 
>>>> Authored: Fri Feb 9 16:49:51 2018 +
>>>> Committer: Stian Soiland-Reyes 
>>>> Committed: Tue Feb 13 00:14:52 2018 +
>>>>
>>>>
>>>>
>>>> --
>>>>  src/main/java/org/apache/commons/csv/CSVRecord.java | 4 ++--
>>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> http://git-wip-us.apache.org/repos/asf/commons-csv/blob/f66a8390/src/main/java/org/apache/commons/csv/CSVRecord.java
>>>>
>>>>
>>>> --
>>>> diff --git a/src/main/java/org/apache/commons/csv/CSVRecord.java
>>>> b/src/main/java/org/apache/commons/csv/CSVRecord.java
>>>> index 979119f..2be5c49 100644
>>>> --- a/src/main/java/org/apache/commons/csv/CSVRecord.java
>>>> +++ b/src/main/java/org/apache/commons/csv/CSVRecord.java
>>>> @@ -199,7 +199,7 @@ public class CSVRecord implements Serializable,
>>>> Iterable {
>>>>  public final CSVRecord immutable() {
>>>> if (isMutable()) {
>>>> // Subclass is probably CSVMutableRecord, freeze values
>>>> -   String[] frozenValue = Arrays.copyOf(values,
>>>> values.length);
>>>> +   String[] frozenValue = values.clone();
>>>> return new CSVRecord(frozenValue, mapping, comment,
>>>> recordNumber, characterPosition);
>>>> } else {
>>>> return this;
>>>> @@ -260,7 +260,7 @@ public class CSVRecord implements Serializable,
>>>> Iterable {
>>>> if (isMutable()) {
>>>> return this;
>>>> }
>>>> -   String[] newValues = Arrays.copyOf(values,
>>>> values.length);
>>>> +   String[] newValues = values.clone();
>>>> return new CSVMutableRecord(newValues, mapping, comment,
>>>> recordNumber, characterPosition);
>>>> }
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>



-- 
Stian Soiland-Reyes
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: commons-csv git commit: CSV-216: Avoid Arrays.copyOf()

[Stian Soiland-Reyes]

String is still a type of Object (requiring GC handling of reference
counters), as you can do Object[] o = stringArray.clone(); without
casting.  (other way not so)

https://www.javaspecialists.eu/archive/Issue124.html says there is
hardly any difference, so I don't think we need to fight this one out
and can just go with the cleanest code :)

On 16 February 2018 at 11:22, sebb  wrote:
> On 16 February 2018 at 10:01, Stian Soiland-Reyes  wrote:
>> I agree in general for .clone() on objects - and I'm trying to move
>> away from using .clone() in that Commons RDF fluent mutable/immutable
>> builder (See COMMONSRDF-49).
>>
>> But this is an Object[] - a native type.
>
> Huh?
>
> The code says String[], which is native as it's final.
>
> Object[] may not be native
>
>> I must admit I am not sure what is really the preferred way - I
>> thought .clone() is best as the VM can copy an array natively however
>> it wants, while with Arrays.copyOf it might have to check if length is
>> the same before doing anything clever.
>
> In the specific case of String[] it might be OK to use clone, but in
> general it's better to use the proper JVM methods and not try to
> second-guess how efficient they are.
>
>> On 13 February 2018 at 18:58, Gilles  wrote:
>>> On Tue, 13 Feb 2018 18:40:13 +, sebb wrote:
>>>>
>>>> On 13 February 2018 at 09:31, Gilles  wrote:
>>>>>
>>>>> On Tue, 13 Feb 2018 00:16:13 + (UTC), st...@apache.org wrote:
>>>>>>
>>>>>>
>>>>>> Repository: commons-csv
>>>>>> Updated Branches:
>>>>>>   refs/heads/CSV-216 637ad2d7a -> f66a83901
>>>>>>
>>>>>>
>>>>>> CSV-216: Avoid Arrays.copyOf()
>>>>>
>>>>>
>>>>>
>>>>> Why?
>>>>
>>>>
>>>> Agreed
>>>>
>>>>>> as .clone() will do
>>>>>
>>>>>
>>>>>
>>>>> We should rather avoid using "clone()".
>>>>
>>>>
>>>> Again: why?
>>>
>>>
>>> There are many discussions about this topic on the web.[1]
>>> My point is that using "clone()" is not good advice.
>>>
>>> Gilles
>>>
>>> [1] E.g. http://vojtechruzicka.com/java-cloning-problems/
>>>
>>>
>>>> It's not clear why Arrays.copyOf(0 is considered bad, nor why clone()
>>>> is considered bad.
>>>>
>>>>
>>>>> Gilles
>>>>>
>>>>>
>>>>>> -- at least until someone tries to do
>>>>>> .withValue(x) in an out-of-range column
>>>>>>
>>>>>>
>>>>>> Project: http://git-wip-us.apache.org/repos/asf/commons-csv/repo
>>>>>> Commit:
>>>>>> http://git-wip-us.apache.org/repos/asf/commons-csv/commit/f66a8390
>>>>>> Tree: http://git-wip-us.apache.org/repos/asf/commons-csv/tree/f66a8390
>>>>>> Diff: http://git-wip-us.apache.org/repos/asf/commons-csv/diff/f66a8390
>>>>>>
>>>>>> Branch: refs/heads/CSV-216
>>>>>> Commit: f66a83901bd026369a2e8d522bd567eb2ef3f8c0
>>>>>> Parents: 637ad2d
>>>>>> Author: Stian Soiland-Reyes 
>>>>>> Authored: Fri Feb 9 16:49:51 2018 +
>>>>>> Committer: Stian Soiland-Reyes 
>>>>>> Committed: Tue Feb 13 00:14:52 2018 +
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>  src/main/java/org/apache/commons/csv/CSVRecord.java | 4 ++--
>>>>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://git-wip-us.apache.org/repos/asf/commons-csv/blob/f66a8390/src/main/java/org/apache/commons/csv/CSVRecord.java
>>>>>>
>>>>>>
>>>>>> --
>>>>>> diff --git a/src/main/java/org/apache/commons/csv/CSVRecord.java
>>>>>> b/src/main/java/org/apache/commons

Re: commons-csv git commit: CSV-216: Avoid Arrays.copyOf()

[Stian Soiland-Reyes]

On Fri, 16 Feb 2018 20:11:11 +0100, Gilles  wrote:
> Bottom-line: Don't use clone except to copy arrays.
> So I'd rephrase my comment on the commit: let "clone()" in place
> but with the comment that it's the only acceptable use of it.

OK, I've added such comments :)

(It was also used for copying the headers, which was also String[])

-- 
Stian Soiland-Reyes
The University of Manchester
http://www.esciencelab.org.uk/
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

[RDF] Fluent parser API?

[Stian Soiland-Reyes]

and pass the
config along yourself.

The advantage I see here is that the JenaParser implementation gets a
very clean Parser interface to implement, no abstract class needed.  It
might however need to check itself that the config is complete enough
for its needs as in theory it could be a null-config with nothing set.

I'll come back to the alternative ParserBuilder interface
which guides the client caller step by step straight into a parsed file.


-- 
Stian Soiland-Reyes
The University of Manchester
http://www.esciencelab.org.uk/
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: [RDF] Fluent parser API?

[Stian Soiland-Reyes]

On Tue, 20 Feb 2018 16:49:23 +, Stian Soiland-Reyes 
 wrote:
> ajs6f and others who like talking about immutability and fluent APIs:
> I'll come back to the alternative ParserBuilder interface
> which guides the client caller step by step straight into a parsed file.

OK, so really this is what I started with, but which I'm also less sure
about - a fluent API with a single direction.


The idea here is that RDF.parserBuilder()
https://s.apache.org/parserBuilder
returns a ParserBuilder which you can use directly.
Simplest use is something like:


Parsed p = rdf.parserBuilder()
 .syntax(RDFSyntax.JSONLD)
 .source("http://example.com/data.jsonld";)
 .parse();
Dataset ds = p.target().dest();

Compared to the ParserConfig interfaces (which this uses underneath), we have a
more parser-oriented drive here, but where you have to do things in the
prescribed order, represented by "state" interfaces like 
https://s.apache.org/NeedSourceOrBase


You can start by setting .base(), .target() or .source().   If you skip setting
the .target() we'll assume you want to make a new Dataset, as in the example
above.

It is opionionated, for instance after setting .base() you can only set
.source()  but .option()  is allowed at any stage.

Once you have reached the Sync stage you can call .parse() as in the example,
or move to .async() where you can call parseAsync().

Through dark generics magic (@SuppressWarnings("rawtypes") ..)
the typing is preserved so that the returned Parsed reflects
the particular targets and sources set.


Future> f = rdf.parserBuilder()
   .source(Paths.get("/tmp/file.ttl")
   .target(graph).async().parseAsync();


When parsing this will use the RDF.parser(RDFSyntax) method to find 
the corresponding parser and pass it the generated ParserConfig.
The parseAsync() method is using its own executor thread pool as before in
experimental - but probably we could make an AsyncParser interface it can check
for and delegate instead.



You can bail out at any point using either .immutable() or .build() 

If you use .immutable() you just get a copy of the same ParserBuilder state
(where you can only continue forward in the fluent API), but now with an
immutable ParserConfig inside. Any further changes will thus not affect
each-other.

If you use .build() you simply build the current ParserConfig - an immutable
version is always returned here. This can then be used if you change your mind,
but you can't step back into the ParserBuilder and have to use the Parser 
"manually".


BTW: How to implement all those interfaces?
Well, they are all implemented by a single class:
https://s.apache.org/ParserConfigBuilder
It generally just calls .withWhatever() on the ParserConfig and 
return itself or a new instance if it's immutable. No clones()!


-- 
Stian Soiland-Reyes
The University of Manchester
http://www.esciencelab.org.uk/
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

Google summer of code ideas?

[Stian Soiland-Reyes]

Commons folks,

I've added a general GSOC catch-all bug-hunt idea
at https://issues.apache.org/jira/browse/COMMONSSITE-103

(Hope it's OK that Alice used Commons Crypto as example!)

but feel free to add more specific ideas in Jira using gsoc2018 label
and link it to that issue. 

Note that we still need mentors - it might or might not be someone that
has particular knowledge of the component, that all depends on what the
student wants to do. 

For instance if someone wants to fix javadocs warnings or do Java 9
support then they can probably work on that for any component together
with any ASF committer as a mentor. But if the student wants to refactor
Commons VFS, then some VFS person should probably be involved.


For details on GSOC  mentorship see  also 
https://lists.apache.org/thread.html/4e2b5b0ef2e565a08470ecbf9b2a6fc27a25ce28d4708334c9073fb9@%3Cgeneral.incubator.apache.org%3E


-- 
Stian Soiland-Reyes
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] Dist layout change to per version directories

[Stian Soiland-Reyes]

On 21 April 2016 at 12:06, sebb  wrote:

> Note that once we have released (say) NET 3.5, the downloads for NET
> 3.4 need to be removed from the mirrors.
> So the only place that the links will then exist is in the archives.
>
> Unless we also set up links for every past release in every Commons
> component, there is going to be a discontinuity at some point in the
> naming convention.
>
> Seems to me we either accept that we cannot change the names ever, or
> we accept that downstream users will need to change their URLs.
>
> They have to change the URL anyway when a new release is made.
> Does it really matter if the URL changes more than just a version string?

Yes, so I initially suggested a simpler approach, we only do the new
layout for new releases - as they would come with an equivalent
release email etc - however Gilles suggested we do the change for all
components at once - which I admit gives greater consistency but could
also break many downstream packaging in one go unless we do
consistency symlinks **for the transitionary versions**.   (On the
other side that would be a "everything breaks at once" event rather
than "every component download script breaks bit by bit over the next
years)




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

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

Re: [io] Make requirement Java 7?

[Stian Soiland-Reyes]

+1 - now is the time.

Also I love the java.nio.file APIs. :)



On 25 April 2016 at 22:53, Gary Gregory  wrote:
> Does anyone object updating [io] to Java 7?
>
> I have a coupe of utils that sit on top of Java 7 IO classes I'd like to
> include.
>
> Gary
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory



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

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

Re: [VOTE] Commons NET 3.5 based on RC3

[Stian Soiland-Reyes]

+1 (non-binding)

+1 signatures, hashes
+1 tar vs gz
+1 src has no binaries (except logo)
0 README.md OK  (except it says 3.5-SNAPSHOT)
+1 RELEASE-NOTES.txt
+1 mvn clean install


stain@biggie:/tmp/3.5_RC3/src/commons-net-3.5-src$ mvn -v
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T16:41:47+00:00)
Maven home: /home/stain/software/maven
Java version: 1.8.0_72-internal, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "3.16.0-67-generic", arch: "amd64", family: "unix"

On 2 May 2016 at 00:12, sebb  wrote:
> Try again.
>
> ==
>
> NET 3.5 RC3 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/net/3.5_RC3/ (13489)
>
> commons-net-3.5-bin.tar.gz.sha1:4941d802a78dd198786d4f6a0a9500f658f44a85
> commons-net-3.5-bin.zip.sha1:b03fc180862aff92de7aaa6ca94b83ef7f3435cf
> commons-net-3.5-src.tar.gz.sha1:1215a0df6fe67cc2671679f58b29dede752f232d
> commons-net-3.5-src.zip.sha1:ea576c3a5f7d83d037e0ee9dcedb98a5ac076c1a
>
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1158/commons-net/commons-net/3.5/
>
> These are the artifacts and their hashes
>
> commons-net-3.5-test-sources.jar
> (SHA1: 5172e1c4f6544eb7755f034c89b812714fead83d)
> commons-net-3.5-sources.jar
> (SHA1: 185dea3736a8583323da4d6ce647719ddf452ccf)
> commons-net-3.5-ftp.jar
> (SHA1: 6e28fe5e21df8e2b1f166f85d69820f844c0d48e)
> commons-net-3.5.jar
> (SHA1: 342fc284019f590e1308056990fdb24a08f06318)
> commons-net-3.5-examples.jar
> (SHA1: 6272d80e897347c3c5f3691c8d76eae5deb764e1)
> commons-net-3.5-tests.jar
> (SHA1: b8925a81e0e7ed09e81341f17f1408dd6fec6f43)
> commons-net-3.5.pom
> (SHA1: d0306becf8a919442cf01a925ffaadd67dead3cf)
> commons-net-3.5-javadoc.jar
> (SHA1: 72850d3da769c0ea7b7dad00da52b7912140aee0)
>
>
> Details of changes since 3.4 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/net/3.5_RC3/RELEASE-NOTES.txt
> http://home.apache.org/~sebb/net-3.5-RC3/changes-report.html
>
>   I have tested this with JDK 1.6, 7, 8 using Apache Maven 3.3.9
>
> Note: Maven 3.1.1 works too, but has problems with the Nexus deploy -
> peer not authenticated
> Maven 3.2.5 also fails to deploy - Could not generate DH keypair
>
>   The tag is here:
> http://svn.apache.org/repos/asf/commons/proper/net/tags/NET_3_5_RC3/
> (1741905)
>
>   Site:
> http://home.apache.org/~sebb/net-3.5-RC3/
>(some *relative* links are broken - these will be OK once the site
> is deployed)
>
>   Clirr Report (compared to 3.4):
> http://home.apache.org/~sebb/net-3.5-RC3/clirr-report.html
>
>   RAT Report:
> http://home.apache.org/~sebb/net-3.5-RC3/rat-report.html
>
>   KEYS:
>   https://www.apache.org/dist/commons/KEYS
>
>   Please review the release candidate and vote.
>   This vote will close no sooner than 72 hours from now,
>   i.e. sometime after 23:30 GMT 4 May 2016
>
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
>   Thanks!
>
>   Sebb
>
> -
> 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 RDF (incubating)
http://orcid.org/-0001-9842-9718

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

Re: [ALL] Dist layout change to per version directories

[Stian Soiland-Reyes]

mmons-math3-3.6-bin.zip ->
../binaries/commons-math3-3.6-bin.zip
lrwxrwxrwx 1 stain stain  41 May  3 10:43
commons-math3-3.6-bin.zip.asc ->
../binaries/commons-math3-3.6-bin.zip.asc
lrwxrwxrwx 1 stain stain  41 May  3 10:43
commons-math3-3.6-bin.zip.md5 ->
../binaries/commons-math3-3.6-bin.zip.md5
lrwxrwxrwx 1 stain stain  42 May  3 10:43
commons-math3-3.6-bin.zip.sha1 ->
../binaries/commons-math3-3.6-bin.zip.sha1
lrwxrwxrwx 1 stain stain  38 May  3 10:43 commons-math3-3.6-src.tar.gz
-> ../source/commons-math3-3.6-src.tar.gz
lrwxrwxrwx 1 stain stain  42 May  3 10:43
commons-math3-3.6-src.tar.gz.asc ->
../source/commons-math3-3.6-src.tar.gz.asc
lrwxrwxrwx 1 stain stain  42 May  3 10:43
commons-math3-3.6-src.tar.gz.md5 ->
../source/commons-math3-3.6-src.tar.gz.md5
lrwxrwxrwx 1 stain stain  43 May  3 10:43
commons-math3-3.6-src.tar.gz.sha1 ->
../source/commons-math3-3.6-src.tar.gz.sha1
lrwxrwxrwx 1 stain stain  35 May  3 10:43 commons-math3-3.6-src.zip ->
../source/commons-math3-3.6-src.zip
lrwxrwxrwx 1 stain stain  39 May  3 10:43
commons-math3-3.6-src.zip.asc ->
../source/commons-math3-3.6-src.zip.asc
lrwxrwxrwx 1 stain stain  39 May  3 10:43
commons-math3-3.6-src.zip.md5 ->
../source/commons-math3-3.6-src.zip.md5
lrwxrwxrwx 1 stain stain  40 May  3 10:43
commons-math3-3.6-src.zip.sha1 ->
../source/commons-math3-3.6-src.zip.sha1


e.g. the new-style download link pattern would become

http://www.eu.apache.org/dist/commons/math/3.6/commons-math3-3.6-src.tar.gz
http://www.eu.apache.org/dist/commons/math/3.6/commons-math3-3.6-bin.tar.gz

We then update download pages/templates to use this pattern.


For a new release (e.g. commons-math-2.3 or commons-math3-3.7) the
files would be added directly to their version folders 2.3/ and 3.7/ -
e.g. they would not exist in binaries/ and source) - when clearing a
old folder io/2.2/ we would then also clear binaries/*2.2* and
sources/*2.2*


Complete example:

https://paste.apache.org/8MKJ


(Note for this example commons-math-2.2  includes
commons-math-2.2-src.tar.gz and the binary commons-math-2.2.tar.gz
as we agreed not to rename to -bin on older)





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

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

Re: [ALL] Dist layout change to per version directories

[Stian Soiland-Reyes]

Because e.g. Math 2.2 was released on 2013-03-03 - a "re-release" of
2.2 at a new location is unexpected - at least if the old location
goes 404.


You are right that my approach would not make 2.1 available in the new
layout - which I think there is not much point in as naturally there
are other inconsistencies across components and filenames for any code
historian browsing https://archive.apache.org/dist/commons/

The goal of my approach was just ensuring that the latest version of
every commons component is available in the new layout (consistency,
as raised by Gilles) - without breaking the active download links on
the mirrors for existing versions that have not (yet or ever) been
replaced.

Practically using symlinks on dist.apache.org in SVN is probably an
easier change to implement as you don't need to re-upload 500 MB or
script thousands of svn cp commands (and check they all worked).


Just my take - I'm not insisting on this - go ahead and break the web
:)  At least then the new layout will be picked up quickly..

On 3 May 2016 at 16:18, sebb  wrote:
> On 3 May 2016 at 11:13, Stian Soiland-Reyes  wrote:
>> Trying to summarize here.. :)
>>
>> On 25 April 2016 at 10:49, sebb  wrote:
>>
>>>>> Does it really matter if the URL changes more than just a version string?
>>>> Yes,
>>> I don't understand why that should be.
>>> Can you explain in more detail?
>>
>> Mainly in download recipes with a URL pattern patterns using
>> ${version} or similar.
>>
>> For instance:
>>
>> https://anonscm.debian.org/cgit/pkg-java/commons-io.git/tree/debian/watch
>> https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/java-commons-io
>>
>>
>> Obviously these patterns will for the next versions need to change
>> anyway with the new layout (they already have to deal with the fact
>> that only the newest version is in the mirrors, that's why Debian
>> clone into their own git repositories based on that watch file)
>>
>> Personally when using Apache software from a Docker build file I have
>> to use http://archive.apache.org/ fallback URLs to make sure my recipe
>> keeps working - see for instance
>> https://github.com/stain/jena-docker/blob/master/jena/Dockerfile#L34
>>
>> But the old releases won't be affected on archive.apache.org (e.g.
>> they will stay in */source */binarines).
>>
>>
>>
>>> Unless we continue providing links for every future release, the
>>> downstream provider has to change the download URL.
>>> Once they have done that, why should there be a need to refer to
>>> previous releases at all?
>>> And if there is a need to do so, does it really matter if the URL is 
>>> different?
>>
>> I agree it doesn't matter if it's a new versions - as they will come
>> with release emails and so on. However I don't think consumers expect
>> existing Download links to change over night without a corresponding
>> new release email for that component.
>>
>> We should of course do a general release email about the download link
>> changes - but then we still have a job to ensure we have updated all
>> our own download pages correctly :)
>>
>> https://archive.apache.org/dist/commons/ would still keep the older
>> versions under binaries/ and sources/ - I don't suggest to make
>> symlinks for every old release in there to the new pattern.
>>
>>
>> The question is what to do with the existing releases in the mirrors.
>>
>> I think from INFRA-11702 we have OK from INFRA to use symlinks for
>> this if we want - e.g. from the new folder structure to the old one -
>> so my suggestion is that we make the change smoother for downstream
>> like that.
>>
>> e.g let's consider
>>
>> https://dist.apache.org/repos/dist/release/commons/math/
>>
>> Current structure (for simplicity only showing *.tar.gz):
>>
>> ./source/commons-math-2.2-src.tar.gz
>> ./source/commons-math3-3.6-src.tar.gz
>> ./source/commons-math3-3.6.1-src.tar.gz
>> ./source/commons-math3-3.5-src.tar.gz
>> ./binaries/commons-math3-3.5-bin.tar.gz
>> ./binaries/commons-math-2.2.tar.gz
>> ./binaries/commons-math3-3.6-bin.tar.gz
>> ./binaries/commons-math3-3.6.1-bin.tar.gz
>>
>>
>>
>> We make the new version folders as you suggested (vary for your
>> preferred 3.5 / math3-3.5 vs math-3.5 folder name style)
>>
>> Adding folders:
>> 2.2/
>> 3.5/
>> 3.6/
>> 3.6.1/
>>
>> - and then (as we've not made new math releases yet) thei

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Stian Soiland-Reyes]

.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html
>
> Changes since rc0:
>
> * Improved release notes and website for compatibility
> * Fixes to pom.xml for building website
>
> This vote will be open for 72-hours, 2016/05/06 0400 UTC.
>
>   [ ] +1 Release these artifacts as version 2.1
>   [ ] 0  OK, but...
>   [ ] -1 I oppose these artifacts as version 2.1 because..
>
> - Josh
>
> -
> 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 RDF (incubating)
http://orcid.org/-0001-9842-9718

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

US Export classification & ECCN registration for encryption in commons?

[Stian Soiland-Reyes]

Hi,

Sorry for spotting this..


Apache Commons Crypto  is not listed on
http://www.apache.org/licenses/exports/ - does it need to be?  (One
would assume so..)

Also it was raised that Commons VFS depends on Bouncy Castle/Apache
Mina/Jetty/SSHD/Hadoop/jsch and has encryption binding for AES128 -
perhaps that also needs to be listed and registered?


We only have listed:

Commons Compress
Commons OpenPGP


See guidance on
http://www.apache.org/dev/crypto.html


BTW - I've raised https://issues.apache.org/jira/browse/LEGAL-250 to
see if merely using a listed source as a Maven  means you
also are classified - or if you would need to also bundle the
dependency's binary (which I think we don't do).



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

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

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Stian Soiland-Reyes]

Raised as https://issues.apache.org/jira/browse/VFS-604

I'll investigate a bit with the return values to see if VFS claims the
setting of permissions succeeded.

noexec is a bit weird.. you are allowed to SET the executable bit
(e.g. it would be correctly tar-ed up with exec flag), it just doesn't
have the effect if trying to exec it.


stain@biggie:/tmp$ echo '#!/bin/cat' > hello
stain@biggie:/tmp$ chmod 755 hello

stain@biggie:/tmp$ ./hello
-bash: ./hello: Permission denied

stain@biggie:/tmp$ ls -al hello
-rwxr-xr-x 1 stain stain 11 May  5 10:16 hello



On 4 May 2016 at 19:53, Bernd Eckenfels  wrote:
> Thanks Stian!
>
> Do you plan to report the noexec issue? If not let me know and I will
> file one.
>
> I thought we already had one but I cant find it.
>
> I will do some windows tests and then vote.
>
> Gruss
> Bernd
>
>  Am Wed, 4 May 2016 13:28:54 +0100
> schrieb Stian Soiland-Reyes :
>
>> +1 (non-binding)
>>
>> +1 signatures
>> +1 hashes
>> +1 LICENSE, NOTICE
>> 0 README.md says 2.0
>> 0 Extra README.txt (confusing)
>> +1 RELEASE-NOTES.txt
>> +1 mvn apache-rat:check
>> +1 maven repository signatures/hashes
>> +1 maven repository *distribution* matches dist/
>> 0 mvn clean install OK (but 1 test fails on tmpfs)
>> +1 target/*jar matches binaries
>> +1 source matches svn tag (minus sandbox/ :-) )
>> +1 Dependency licenses OK
>> -1 Unclassified use of encryption libraries Bouncy Castle/Apache
>> Mina/SSHD/Hadoop/jsch/Jetty (plus some AES128 in DefaultCryptor) - but
>> Commons VFS is not classified on
>> http://www.apache.org/licenses/exports/
>>
>> I won't take a stand on the US Export classification requirement as
>> https://issues.apache.org/jira/browse/LEGAL-250 has not been resolved
>> yet.
>>
>>
>> I get this test error (because my /tmp is mounted with noexec):
>>
>> Tests run: 90, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 4.259
>> sec <<< FAILURE! - in
>> org.apache.commons.vfs2.provider.local.test.LocalProviderTestCase
>> testExecutable(org.apache.commons.vfs2.test.PermissionsTests)  Time
>> elapsed: 0.011 sec  <<< FAILURE!
>> java.lang.AssertionError
>> at org.junit.Assert.fail(Assert.java:86)
>> at org.junit.Assert.assertTrue(Assert.java:41)
>> at org.junit.Assert.assertTrue(Assert.java:52)
>> at
>> org.apache.commons.vfs2.test.PermissionsTests.testExecutable(PermissionsTests.java:70)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498) at
>> org.apache.commons.vfs2.test.AbstractProviderTestCase.runTest(AbstractProviderTestCase.java:218)
>> at junit.framework.TestCase.runBare(TestCase.java:141) at
>> junit.framework.TestResult$1.protect(TestResult.java:122) at
>> junit.framework.TestResult.runProtected(TestResult.java:142) at
>> junit.framework.TestResult.run(TestResult.java:125) at
>> junit.framework.TestCase.run(TestCase.java:129) at
>> junit.framework.TestSuite.runTest(TestSuite.java:252) at
>> junit.framework.TestSuite.run(TestSuite.java:247) at
>> junit.extensions.TestDecorator.basicRun(TestDecorator.java:23) at
>> org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:149)
>> at junit.framework.TestResult.runProtected(TestResult.java:142) at
>> org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:154)
>>
>> Building from /var/tmp worked.
>>
>> I won't fail because of this - I'm probably special still using tmpfs
>> :)   (And adding conditional testing would mean using the same APIs or
>> requivalent Java 7 NIO files APIs to see if executable bit is
>> supported).
>>
>>
>> Checked with:
>>
>> stain@biggie:/tmp/vfs/source/commons-vfs-2.1$ mvn -v
>> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
>> 2015-11-10T16:41:47+00:00)
>> Maven home: /home/stain/software/maven
>> Java version: 1.8.0_72-internal, vendor: Oracle Corporation
>> Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
>> Default locale: en_GB, platform encoding: UTF-8
>> OS name: "linux", version: "3.16.0-67-generic", arch: "amd64",
>> family: "unix"
>>
>> On 4 May 2016 at 04:43, Josh Elser  wrote:
>> > All,
>> >
>> > Please consider the following for Apache Commons VFS2

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Stian Soiland-Reyes]

Test dependency should be fine. The SSHD and JSch integration is
however probably not OK without classification.


I think integrating with "encryption functionality" (without bundling)
is sufficient to become an "encryption item":

http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201605.mbox/%3CD35026DE.692DB%25aharui%40adobe.com%3E

https://www.bis.doc.gov/index.php/policy-guidance/encryption/identifying-encryption-items


Let's try to sort this in the separate thread:
http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CCAB917R%2BuGHPiOUUq_F48n3-m-nKdgrgndcBkmpmA%3DS1H3Ngs5Q%40mail.gmail.com%3E

It could be that Apache's pages about this is out of date.

On 4 May 2016 at 18:50, Jörg Schaible  wrote:
> Hi Stian,
>
> Stian Soiland-Reyes wrote:
>
>
> [snip]
>
>> -1 Unclassified use of encryption libraries Bouncy Castle/Apache
>> Mina/SSHD/Hadoop/jsch/Jetty (plus some AES128 in DefaultCryptor) - but
>> Commons VFS is not classified on
>> http://www.apache.org/licenses/exports/
>
>
> Sorry, but I fail to see the problem. BC is used as test dependency only and
> it is nowhere part of our deliveries or used in our code. AES128 is part of
> the Java runtime.
>
> Cheers,
> Jörg
>
>
> -
> 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 RDF (incubating)
http://orcid.org/-0001-9842-9718

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

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Stian Soiland-Reyes]

> [ERROR] Failed to execute goal on project commons-vfs2: Could not resolve
> dependencies for project org.apache.commons:commons-vfs2:jar:2.1: Could not
> find artifact jdk.tools:jdk.tools:jar:1.6 at specified path /opt/oracle-jdk-
> bin-1.9.0.0_beta116/../lib/tools.jar -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR]   mvn  -rf :commons-vfs2
> = %< ==
>
> The reason is an invalid (transitive) system dependency on tools.jar of
> Hadoop which is no longer present in Java 9.

hadoop-common:test-jar pulls in:

http://central.maven.org/maven2/org/apache/hadoop/hadoop-annotations/2.6.0/hadoop-annotations-2.6.0.pom

With two different profiles, the os.linux profile activates for me as
well, as the activation here is "Not a mac".


The newer Hadoop 2.7.1 seems to have fixed to these activations.

http://central.maven.org/maven2/org/apache/hadoop/hadoop-annotations/2.7.1/hadoop-annotations-2.7.1.pom

(Hadoop 2.7 presumably no longer works on JDK6)


Could you try changing all the Hadoop 2.6.0 dependencies in pom.xml to
2.7.1 and see if JDK9 is happy then?

(We can always exclude it tools.jar in the test dependency, I don't
see how it's needed for our tests)

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

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Stian Soiland-Reyes]

t; [INFO]
> 
> [INFO]
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Commons VFS . SUCCESS [  3.068
> s]
> [INFO] Apache Commons VFS Core  FAILURE [  0.350
> s]
> [INFO] Apache Commons VFS Examples  SKIPPED
> [INFO] Apache Commons VFS Distribution  SKIPPED
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time: 3.738 s
> [INFO] Finished at: 2016-05-05T00:09:12+02:00
> [INFO] Final Memory: 23M/78M
> [INFO]
> 
> [ERROR] Failed to execute goal on project commons-vfs2: Could not resolve
> dependencies for project org.apache.commons:commons-vfs2:jar:2.1: Could not
> find artifact jdk.tools:jdk.tools:jar:1.6 at specified path /opt/oracle-jdk-
> bin-1.9.0.0_beta116/../lib/tools.jar -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR]   mvn  -rf :commons-vfs2
> = %< ==
>
> The reason is an invalid (transitive) system dependency on tools.jar of
> Hadoop which is no longer present in Java 9.
>
> Cheers,
> Jörg
>
>
> Josh Elser wrote:
>
>> All,
>>
>> Please consider the following for Apache Commons VFS2 version 2.1 (rc1).
>>
>> Maven repository:
>> https://repository.apache.org/content/repositories/orgapachecommons-1163
>> Artifacts: https://dist.apache.org/repos/dist/dev/commons/vfs/ r13511
>>
>> MD5  commons-vfs-distribution-2.1-bin.tar.gz
>> 1192914d1ba6f8ca3a2a688feeff602c
>> SHA1 commons-vfs-distribution-2.1-bin.tar.gz
>> 285097f1db6cbc9d76ae5bb3adf66a315344a864
>> MD5  commons-vfs-distribution-2.1-src.tar.gz
>> 0646187562302a7dcfbddb93204fc9eb
>> SHA1 commons-vfs-distribution-2.1-src.tar.gz
>> 24bab87fd4049b9389acd1b6e272f405630aeb25
>> MD5  commons-vfs-distribution-2.1-bin.zip 3785874aa0cda64d68acbb8fb7db8bea
>> SHA1 commons-vfs-distribution-2.1-bin.zip
>> 942a23fb202b89b1a8432beeb0a66469959e661d
>> MD5  commons-vfs-distribution-2.1-src.zip c8ef43d308bed1b3ffcb363c15285176
>> SHA1 commons-vfs-distribution-2.1-src.zip
>> 1ddf0d218f659766f136894eab0beca504ab9f8c
>>
>> Signed with 4677D66C from
>> https://dist.apache.org/repos/dist/release/commons/KEYS
>>
>> SVN tag is available at
>> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.1-RC1/
>> r1742212
>>
>> Staged Maven website:
>> http://home.apache.org/~elserj/commons/commons-vfs-2.1/
>>
>> All reports are available in the provided staged Maven site (see
>> "Project Reports" at the root-level as well as under each sub-module).
>> JIRA-generated release notes are available in the dist.a.o "Artifacts"
>> repository. Unit tests pass and the RC was built util JDK6.
>>
>> (For Sebb) A direct Clirr link
>> http://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html
>>
>> Changes since rc0:
>>
>> * Improved release notes and website for compatibility
>> * Fixes to pom.xml for building website
>>
>> This vote will be open for 72-hours, 2016/05/06 0400 UTC.
>>
>>[ ] +1 Release these artifacts as version 2.1
>>[ ] 0  OK, but...
>>[ ] -1 I oppose these artifacts as version 2.1 because..
>>
>> - Josh
>
>
>
> -
> 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 RDF (incubating)
http://orcid.org/-0001-9842-9718

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

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Stian Soiland-Reyes]

Thanks, I've added ${hadoop.version} so it's easier to upgrade in the
future, and also committed the  of tools.jar


I think the maven-jar-maven JDK9 issue is due to
https://issues.apache.org/jira/browse/MJAR-206
https://issues.apache.org/jira/browse/MJAR-205

so you would need to wait for maven-jar-plugin 3.0.0



Not sure about the JspRuntimeContext class cast exception..

jdk.internal.loader.ClassLoaders$AppClassLoader (in module: java.base)
cannot be cast to java.net.URLClassLoader

sounds like a bit naive casting by Jasper.  Perhaps we would then also
need to force a newer version - this is PRETTY old:

[INFO] |  +- tomcat:jasper-compiler:jar:5.5.23:test
[INFO] |  +- tomcat:jasper-runtime:jar:5.5.23:test

(This version is also coming in as a Hadoop test dependency)

Fixed in Tomcat 8.0.0 at least:

https://github.com/apache/tomcat/blob/TOMCAT_8_0_0/java/org/apache/jasper/compiler/JspRuntimeContext.java#L403


On 5 May 2016 at 11:49, Jörg Schaible  wrote:
> Hi Stian,
>
> Stian Soiland-Reyes wrote:
>
>>> [ERROR] Failed to execute goal on project commons-vfs2: Could not resolve
>>> dependencies for project org.apache.commons:commons-vfs2:jar:2.1: Could
>>> not find artifact jdk.tools:jdk.tools:jar:1.6 at specified path
>>> /opt/oracle-jdk- bin-1.9.0.0_beta116/../lib/tools.jar -> [Help 1]
>>> [ERROR]
>>> [ERROR] To see the full stack trace of the errors, re-run Maven with the
>>> [-e
>>> switch.
>>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>>> [ERROR]
>>> [ERROR] For more information about the errors and possible solutions,
>>> [please
>>> read the following articles:
>>> [ERROR] [Help 1]
>>>
> http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
>>> [ERROR]
>>> [ERROR] After correcting the problems, you can resume the build with the
>>> command
>>> [ERROR]   mvn  -rf :commons-vfs2
>>> = %< ==
>>>
>>> The reason is an invalid (transitive) system dependency on tools.jar of
>>> Hadoop which is no longer present in Java 9.
>>
>> hadoop-common:test-jar pulls in:
>>
>> http://central.maven.org/maven2/org/apache/hadoop/hadoop-annotations/2.6.0/hadoop-annotations-2.6.0.pom
>>
>> With two different profiles, the os.linux profile activates for me as
>> well, as the activation here is "Not a mac".
>>
>>
>> The newer Hadoop 2.7.1 seems to have fixed to these activations.
>>
>> http://central.maven.org/maven2/org/apache/hadoop/hadoop-annotations/2.7.1/hadoop-annotations-2.7.1.pom
>>
>> (Hadoop 2.7 presumably no longer works on JDK6)
>>
>>
>> Could you try changing all the Hadoop 2.6.0 dependencies in pom.xml to
>> 2.7.1 and see if JDK9 is happy then?
>>
>> (We can always exclude it tools.jar in the test dependency, I don't
>> see how it's needed for our tests)
>
> After finally upgrading all four (!) Hadoop versions in the parent (we
> should introduce a property for the Hadoop version), Oracle JDK 8 passes
> again. However, Java 9 fails still with the jar plugin (and an ignored
> ClassCastExceptions in the tests caused by Jetty):
>
>  %< =
> $ mvn -version
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> 2015-11-10T17:41:47+01:00)
> Maven home: /usr/share/maven-bin-3.3
> Java version: 9-ea, vendor: Oracle Corporation
> Java home: /opt/oracle-jdk-bin-1.9.0.0_beta116
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.6-gentoo", arch: "amd64", family: "unix"
>  %< =
> Tests run: 84, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 30.141 sec
> - in org.apache.commons.vfs2.provider.ftps.test.FtpsProviderExplicitTestCase
> Running org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase
> 2016-05-05 12:37:16,660 [main] ERROR: unavailable
> java.lang.ClassCastException:
> jdk.internal.loader.ClassLoaders$AppClassLoader (in module: java.base)
> cannot be cast to java.net.URLClassLoader (in module: java.base)
> at
> org.apache.jasper.compiler.JspRuntimeContext.(JspRuntimeContext.java:174)
> at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:150)
> at
> org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:431)
> at
> org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263)
> at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
>   

Re: [VOTE] Apache Commons VFS 2.1 rc1

[Stian Soiland-Reyes]

No, it shouldn't matter the class loader content to do a normal https
connection, should it?  Or do you consider that optional support from
the JDK? In that case the tests would need to test for https
capability first and ignore themselves if the JDK doesn't support SSL.

Is this the latest IBM JDK patch release..?

On 5 May 2016 at 12:05, Jörg Schaible  wrote:
> Hi Stian,
>
> Stian Soiland-Reyes wrote:
>
>> "EC AlgorithmParameters not available" seems to be a OpenJDK bug
>> because Elastic Curves relies on the sunec native library -
>> http://armoredbarista.blogspot.co.uk/2013/10/how-to-use-ecc-with-openjdk.html
>>
>>
>> Presumably this would also fail in those JDKs?
>>
>> URL url = new
>> java.net.URL("https://www.google.com/images/logos/ps_logo2.png";);
>> url.openConnection();
>>
>>
>> We can modify https/test/GetContentInfoFunctionalTest to not rely on
>> fetching https://www.google.com/images/logos/ps_logo2.png - this
>> sounds a bit fragile to me anyway - for how long would that file
>> remain available?
>>
>> If we need to do an external test, then we should use say
>> https://www.apache.org/licenses/LICENSE-2.0.txt
>>
>> Obviously if INFRA changes the SSL configuration there to also request
>> Elastic Curves, then the test could still fail.
>>
>>
>> Tracked as https://issues.apache.org/jira/browse/VFS-605
>> and fix committed on trunk to instead test against
>> https://www.apache.org/licenses/LICENSE-2.0.tx
>>
>> Could you verify if trunk builds on icedtea-bin-3.0.0 and IBM JDK?
>
> Icedtea 3 builds fine now, but the IBM JDKs still fail with the same errors.
> To me it looks like the test simply makes wrong assumptions about the
> content of the classloader.
>
> Cheers,
> Jörg
>
>
> -
> 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 RDF (incubating)
http://orcid.org/-0001-9842-9718

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

Re: US Export classification & ECCN registration for encryption in commons?

[Stian Soiland-Reyes]

 My take:

(But we can also ask Legal separately as LEGAL-250 got a bit long thread)


The exception for open source means we just need to self-classify as
5D002 and send a notification email according to
http://www.apache.org/dev/crypto.html


https://www.bis.doc.gov/index.php/policy-guidance/encryption/identifying-encryption-items
has some updated guidance after the 2010 changes:

> Almost all items controlled under Category 5, Part 2 of the EAR are 
> controlled because they include encryption functionality. Items may be 
> controlled as encryption items even if the encryption is actually performed 
> by the operating system, an external library, a third-party product or a 
> cryptographic processor. If an item uses encryption functionality, whether or 
> not the code that performs the encryption is included with the item, then BIS 
> evaluates the item based on the encryption functionality it uses.

By not making binary distributions with third-party JARs we would not
be INCLUDING the encryption functionality.  However we would in some
cases USE the encryption functionality.


There IS an exemption from being classified at all in
https://www.bis.doc.gov/index.php/policy-guidance/encryption/identifying-encryption-items#Three



> Note 4: Category 5, Part 2 does not apply to items incorporating or using 
> "cryptography" and meeting all of the following:
>
> (a) The primary function or set of functions is not any of the following:
> (1) "Information security";
> (2) A computer, including operating systems, parts and components 
> therefor;
> (3) Sending, receiving or storing information (except in support of 
> entertainment, mass commercial broadcasts, digital rights
>  management or medical records management); or
> (4) Networking (includes operation, administration, management and 
> provisioning);
> > (b) The cryptographic functionality is limited to supporting their primary 
> > function or set of functions; and
> (c) When necessary, details of the items are accessible and will be provided, 
> upon request, to the appropriate authority in the exporter’s
> country in order to ascertain compliance with conditions described in 
> paragraphs (a) and (b) above.

meaning that say Commons Imaging would be exempt from any registration
- even if it included support for reading encrypted images.

(however some software using such a hypothetical Commons Imaging
w/crypto, and incidentally also doing sending/receiving/storing
information, WOULD need to classify)


but Commons-VFS - with support for SFTP, WebDav etc., is arguably
"Sending, receiving or storing information", and would by having
strong bindings to Apache SSHd (itself listed) and JSCH  which
encryption functionality VFS would be using.

The test dependency on Bouncy Castle is ironically not cause for
registration as VFS code is not designed to use BCProv, and do not
bundle the Bouncy Castle implementation.



Commons Crypto would be doing "information security" and  Iwould say
also need to be registered.

On 5 May 2016 at 10:45, sebb  wrote:
> Also note that there is a TSU Exception, EAR 740.13(e) - Publicly
> available encryption source code - which the dev/crypto.html page says
> applies to the ASF.
>
> I think we need to wait for guidance from Legal.
>
> On 5 May 2016 at 10:04, Benedikt Ritter  wrote:
>> Hi,
>>
>> Stian Soiland-Reyes  schrieb am Mi., 4. Mai 2016 um
>> 14:35 Uhr:
>>
>>> Hi,
>>>
>>> Sorry for spotting this..
>>>
>>>
>>> Apache Commons Crypto  is not listed on
>>> http://www.apache.org/licenses/exports/ - does it need to be?  (One
>>> would assume so..)
>>>
>>> Also it was raised that Commons VFS depends on Bouncy Castle/Apache
>>> Mina/Jetty/SSHD/Hadoop/jsch and has encryption binding for AES128 -
>>> perhaps that also needs to be listed and registered?
>>>
>>
>> Thank you for pointing this out. I've reported this as
>> https://issues.apache.org/jira/browse/CRYPTO-54. I'm not involved in VFS,
>> but I've seen that the discussion about that has already started on the
>> vote for VFS 2.0 rc1.
>>
>> Benedikt
>>
>>
>>>
>>>
>>> We only have listed:
>>>
>>> Commons Compress
>>> Commons OpenPGP
>>>
>>>
>>> See guidance on
>>> http://www.apache.org/dev/crypto.html
>>>
>>>
>>> BTW - I've raised https://issues.apache.org/jira/browse/LEGAL-250 to
>>> see if merely using a listed source as a Maven  means you
>>> also are classified - or if you would need to also bundle the
>>> dependency's binary (which I think

Re: The state of 2.1

[Stian Soiland-Reyes]

Hi,

I assume you mean Commons VFS 2.1.

The second release candidate was effectively pulled because we were
missing a LICENSE/NOTICE entry:

https://lists.apache.org/thread.html/Zif1iomxs7u25tt

This should be trivial to fix, but also important to get right legally.


I assume Josh Elser (as the Release Manager for this candidate) will
formally mark the 2.1 RC2  thread as [CANCELLED] and then we can
prepare a new RC3 for voting.

..but be aware that many Apache committers have been involved with
ApacheCon which just finished last Friday, so folks probably have lots
of things to catch up on.

On 16 May 2016 at 01:45, Dmitry Goldenberg  wrote:
> Hi,
>
> Could someone summarize the state of the VOTE for 2.1?
>
> Thank you.



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

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

[VFS] NOTICE required for Jackrabbit's JcrUtils? (was: [VOTE] Apache Commons VFS 2.1 rc2)

[Stian Soiland-Reyes]

os/asf/commons/proper/vfs/tags/commons-vfs2-project-2.1-rc2/
>> >> r1743451
>> >>
>> >> Staged Maven website:
>> >> http://home.apache.org/~elserj/commons/commons-vfs-2.1/
>> >>
>> >> All reports are available in the provided staged Maven site (see
>> "Project
>> >> Reports" at the root-level as well as under each sub-module).
>> JIRA-generated
>> >> release notes are available in the dist.a.o "Artifacts" repository. Unit
>> >> tests pass and the RC was built util JDK6.
>> >>
>> >> (For Sebb) A direct Clirr link
>> >>
>> http://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html
>> >>
>> >> Changes since rc1:
>> >>
>> >> * Fixed more compatibility concerns against 2.0 (thanks, Greg)
>> >> * Improved release notes (thanks, Sebb)
>> >>
>> >> This vote will be open for 72-hours, 2016/05/14 0400 UTC.
>> >>
>> >>[ ] +1 Release these artifacts as version 2.1
>> >>[ ] 0  OK, but...
>> >>[ ] -1 I oppose these artifacts as version 2.1 because..
>> >>
>> >> - Josh
>> >>
>> >> -
>> >> 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
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory



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

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

NOTICE required for JcrUtils from Jackrabbit 2.4.0?

[Stian Soiland-Reyes]

Hi,

In reviewing an RC for Apache Commons VFS 2.1

https://lists.apache.org/thread.html/Zjouqd6cpmohrj3

we wondered about a file

https://github.com/apache/commons-vfs/blob/trunk/core/src/test/java/org/apache/commons/vfs2/provider/webdav/test/JcrUtils.java

which we have adapted from Jackrabbit 2.4.0.

Jackrabbit has a NOTICE which includes

> Based on source code originally developed by
> Day Software (http://www.day.com/).


Looking at the git history

https://github.com/apache/jackrabbit/commits/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/JcrUtils.java

I think this file was earliest added in JackRabbit in 2009 by Jukka Zitting:

https://github.com/apache/jackrabbit/commit/0882a5cc1ed4ce1cf9d3c6b3a592f97c5772ce25

(first released in 1.6.0 and 2.0-alpha1 )

Is this correct, or was this file based on earlier code?



As Jackrabbit graduated from the Incubator in 2006, am I right to
assume then that JcrUtils.java is NOT covered by the earlier "Day
Software" Software Grant and corresponding NOTICE attribution?

That is, is Apache Commons free to not propagate your NOTICE for using JcrUtils?


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

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

Re: [VFS] NOTICE required for Jackrabbit's JcrUtils? (was: [VOTE] Apache Commons VFS 2.1 rc2)

[Stian Soiland-Reyes]

On 16 May 2016 at 10:10, sebb  wrote:

> Ignore that, I see you found the actual source file,
> so clearly it is not from the original Day contribution.
>
> I was mislead by the comments in the source which implied it came from
> various sources.
> It would be helpful to identify the actual sources in the JIRA and VFS
> once they have been established (not a blocker IMO)
>
>>> I'll ask on dev@jackrabbit to be sure.

Agreed - so I've tracked it as https://issues.apache.org/jira/browse/VFS-611

Could you assign it to me so I can mark it as In Progress?

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

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

Re: [VFS] NOTICE required for Jackrabbit's JcrUtils? (was: [VOTE] Apache Commons VFS 2.1 rc2)

[Stian Soiland-Reyes]

JackrabbitMain seems to be based on jackrabbit-standalone module

https://github.com/apache/jackrabbit/blob/1.5/jackrabbit-standalone/src/main/java/org/apache/jackrabbit/standalone/Main.java

which starts in 2008:

https://github.com/apache/jackrabbit/commit/de58b89320ed768a89035197b46f1486b35d430d

On 16 May 2016 at 11:57, sebb  wrote:
> On 16 May 2016 at 10:56, Stian Soiland-Reyes  wrote:
>> On 16 May 2016 at 10:10, sebb  wrote:
>>
>>> Ignore that, I see you found the actual source file,
>>> so clearly it is not from the original Day contribution.
>>>
>>> I was mislead by the comments in the source which implied it came from
>>> various sources.
>>> It would be helpful to identify the actual sources in the JIRA and VFS
>>> once they have been established (not a blocker IMO)
>>>
>>>>> I'll ask on dev@jackrabbit to be sure.
>>
>> Agreed - so I've tracked it as https://issues.apache.org/jira/browse/VFS-611
>>
>> Could you assign it to me so I can mark it as In Progress?
>
> Tried, but cannot find you as an assign target.
>
> BTW, there is a sibling file which also was derived from JackRabbit:
>
> JackrabbitMain.java
>
> I've not checked when this was added to the JR repo.
>
>> --
>> Stian Soiland-Reyes
>> Apache Taverna (incubating), Apache Commons RDF (incubating)
>> http://orcid.org/-0001-9842-9718
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>



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

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

Re: [ALL] Performance of foreach loop with arrays.

[Stian Soiland-Reyes]

On 16 May 2016 at 14:13, sebb  wrote:
> Looking for feedback on C-style and foreach() loops when using arrays.
> [This email does not consider collections; please start another thread
> if you want to discuss that.]
>
> TLDR; Always use foreach() with arrays unless you need access to the index.

+1 - even if C-style happened to be faster (which I think you argue it
isn't), I would not think the majority of for-loops need that
micro-optimization.

Also note that in Java 8 (I know, I know.. we're still doing 6) you
can do lots of things in parallel with Arrays (including Streams):

https://docs.oracle.com/javase/8/docs/api/java/util/Arrays.html


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

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

Re: [VFS] NOTICE required for Jackrabbit's JcrUtils? (was: [VOTE] Apache Commons VFS 2.1 rc2)

[Stian Soiland-Reyes]

See https://lists.apache.org/thread.html/Zk01ufa8icmfvo8

It should be Jackrabbit who best decides what is covered by what in the
NOTICE file; however evidence so far is strongly showing JcrUtils to be IP
clean not needing any NOTICE; and so I would suggest continuing with the
RC2 vote as is. If Jackrabbit responds differently, then we can do a 2.1.1
with modified NOTICE
On 17 May 2016 5:32 a.m., "Dave Fisher"  wrote:

> Just a suggestion. Ask on the jackrabbit Dev list.
>
> Regards,
> Dave
>
> Sent from my iPhone
>
> > On May 16, 2016, at 5:28 AM, Stian Soiland-Reyes 
> wrote:
> >
> > JackrabbitMain seems to be based on jackrabbit-standalone module
> >
> >
> https://github.com/apache/jackrabbit/blob/1.5/jackrabbit-standalone/src/main/java/org/apache/jackrabbit/standalone/Main.java
> >
> > which starts in 2008:
> >
> >
> https://github.com/apache/jackrabbit/commit/de58b89320ed768a89035197b46f1486b35d430d
> >
> >> On 16 May 2016 at 11:57, sebb  wrote:
> >>> On 16 May 2016 at 10:56, Stian Soiland-Reyes  wrote:
> >>>> On 16 May 2016 at 10:10, sebb  wrote:
> >>>>
> >>>> Ignore that, I see you found the actual source file,
> >>>> so clearly it is not from the original Day contribution.
> >>>>
> >>>> I was mislead by the comments in the source which implied it came from
> >>>> various sources.
> >>>> It would be helpful to identify the actual sources in the JIRA and VFS
> >>>> once they have been established (not a blocker IMO)
> >>>>
> >>>>>> I'll ask on dev@jackrabbit to be sure.
> >>>
> >>> Agreed - so I've tracked it as
> https://issues.apache.org/jira/browse/VFS-611
> >>>
> >>> Could you assign it to me so I can mark it as In Progress?
> >>
> >> Tried, but cannot find you as an assign target.
> >>
> >> BTW, there is a sibling file which also was derived from JackRabbit:
> >>
> >> JackrabbitMain.java
> >>
> >> I've not checked when this was added to the JR repo.
> >>
> >>> --
> >>> Stian Soiland-Reyes
> >>> Apache Taverna (incubating), Apache Commons RDF (incubating)
> >>> http://orcid.org/-0001-9842-9718
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
> >
> > --
> > Stian Soiland-Reyes
> > Apache Taverna (incubating), Apache Commons RDF (incubating)
> > http://orcid.org/-0001-9842-9718
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: US Export classification & ECCN registration for encryption in commons?

[Stian Soiland-Reyes]

Hi, for Taverna the question mainly came down to:

1) What encryption functionality have we designed to use? (e.g. we use
BouncyCastle for encryption, but our use of Derby does not use
encryption)

2) What encryption items (e.g. JARs) will we include in distros (we
will bundle BouncyCastle, Derby, etc)


With Commons Crypto you have to be careful also about the ECCN
classification if it can be seen as a development toolkit for creating
encryption algorithms.


See

https://www.bis.doc.gov/index.php/policy-guidance/encryption/identifying-encryption-items


>From the linked "Flow chart 1" I find for Commons Crypto:

Designed to use or contain cryptography? Yes
Specifically designed for medical? No
Exempt by Note 4?  No  (Primary function is "Information security")
Limited to DRM stuff? No
-> Category 5, Part 2 controlled

So then we go through
https://www.bis.doc.gov/index.php/policy-guidance/encryption/registration

Flow chart 2:

Is the item publicly available encryption source code?  Yes.
-> ECCN 5D002 self-classify


For the classification listing on
https://www.apache.org/licenses/exports/ you basically just list that
you are designed to be used with OpenSSL and JCE, with links to them.



But note:

https://www.bis.doc.gov/index.php/policy-guidance/encryption/classification

Do any of those apply to Commons Crypto?



On 19 May 2016 at 07:45, Chen, Haifeng  wrote:
> Hi Stian,
> I saw you worked actively on same registration issue for Taverna. Do you have 
> any suggestions on what steps we should take for Crypto registration?
> We are keenly to get a first release of Crypto.
>
> Regards,
> Haifeng
>
> -Original Message-
> From: Chen, Haifeng [mailto:haifeng.c...@intel.com]
> Sent: Friday, May 13, 2016 1:39 PM
> To: Commons Developers List 
> Subject: RE: US Export classification & ECCN registration for encryption in 
> commons?
>
> Hi folks,
> From LEGAL-250 discussion, it showed that Commons Crypto should be registered.
> Shall we also add Commons Crypto to ECCN Matrix in 
> http://www.apache.org/licenses/exports/ page (eccnmatrix.xml) the same as 
> what Apache Taverna did?
>
> Regards,
> Haifeng
>
> -Original Message-
> From: sebb [mailto:seb...@gmail.com]
> Sent: Monday, May 9, 2016 7:48 PM
> To: Commons Developers List 
> Subject: Re: US Export classification & ECCN registration for encryption in 
> commons?
>
> On 9 May 2016 at 11:52, Stian Soiland-Reyes  wrote:
>>  My take:
>>
>> (But we can also ask Legal separately as LEGAL-250 got a bit long
>> thread)
>
> +1
>
>>
>> The exception for open source means we just need to self-classify as
>> 5D002 and send a notification email according to
>> http://www.apache.org/dev/crypto.html
>>
>>
>> https://www.bis.doc.gov/index.php/policy-guidance/encryption/identifyi
>> ng-encryption-items has some updated guidance after the 2010 changes:
>>
>>> Almost all items controlled under Category 5, Part 2 of the EAR are 
>>> controlled because they include encryption functionality. Items may be 
>>> controlled as encryption items even if the encryption is actually performed 
>>> by the operating system, an external library, a third-party product or a 
>>> cryptographic processor. If an item uses encryption functionality, whether 
>>> or not the code that performs the encryption is included with the item, 
>>> then BIS evaluates the item based on the encryption functionality it uses.
>>
>> By not making binary distributions with third-party JARs we would not
>> be INCLUDING the encryption functionality.  However we would in some
>> cases USE the encryption functionality.
>>
>>
>> There IS an exemption from being classified at all in
>> https://www.bis.doc.gov/index.php/policy-guidance/encryption/identifyi
>> ng-encryption-items#Three
>>
>>
>>
>>> Note 4: Category 5, Part 2 does not apply to items incorporating or using 
>>> "cryptography" and meeting all of the following:
>>>
>>> (a) The primary function or set of functions is not any of the following:
>>> (1) "Information security";
>>> (2) A computer, including operating systems, parts and components 
>>> therefor;
>>> (3) Sending, receiving or storing information (except in support of 
>>> entertainment, mass commercial broadcasts, digital rights
>>>  management or medical records management); or
>>> (4) Networking (includes operation, administration, management
>>> and provisioning);
>>> > (b) The cryptographic functionality is limited to supporting their
>>> > primary fun

Re: NOTICE required for JcrUtils from Jackrabbit 2.4.0?

[Stian Soiland-Reyes]

On 19 May 2016 at 11:50, Benedikt Ritter  wrote:

>> As Jackrabbit graduated from the Incubator in 2006, am I right to
>> assume then that JcrUtils.java is NOT covered by the earlier "Day
>> Software" Software Grant and corresponding NOTICE attribution?
>> That is, is Apache Commons free to not propagate your NOTICE for using
>> JcrUtils?
> Does Jackrabbit contain a NOTICE for JcrUtils? If not, I don't think we
> need one.


It is just a general NOTICE:

https://github.com/apache/jackrabbit/blob/trunk/NOTICE.txt


> Apache Jackrabbit
> Copyright 2014 The Apache Software Foundation
>
> This product includes software developed at
> The Apache Software Foundation (http://www.apache.org/).
>
> Based on source code originally developed by
> Day Software (http://www.day.com/).



Which doesn't say if the "Day Software" bit applies to JcrUtils or not.

For VFS 2.1 we have assumed it does NOT apply, due to the SVN history
dating it 3 years after import of the Day Software code, but that is
an interpretation I would leave open for Jackrabbit PMC to correct us
in case we are wrong. The ASF license allow us to make that kind of
interpretation, as we have used the SVN history for figuring out
"excluding those notices that do not pertain to any part of the
Derivative Works".



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

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

Re: US Export classification & ECCN registration for encryption in commons?

[Stian Soiland-Reyes]

On 20 May 2016 at 08:53, Benedikt Ritter  wrote:

> b. "Open Cryptographic Interface" items. [740.17(b)(2)]
> looks correct. But this is just my lucky guess.

I'm struggling to find the official definition of "OCI", but I think it's this:

https://www.bis.doc.gov/index.php/forms-documents/doc_view/838-772

> (Open cryptographic interface - A mechanism which is designed to allow a
> customer or other party to insert cryptographic functionality without
> the intervention, help or assistance of the manufacturer or its agents
> (i.e., manufacturer's signing of cryptographic code or proprietary
> interfaces). If the cryptographic interface implements a fixed set of
> cryptographic algorithms, key lengths or key exchange management
> systems, that cannot be changed, it will not be considered an "open"
> cryptographic interface. All general application programming interfaces
> (i.e., those that accept either a cryptographic or non-cryptographic
> interface, but do not themselves maintain any cryptographic
> functionality) will not be considered "open" cryptographic interfaces
> either.)

Are you sure this is the case for commons-crypto? I thought we only
supported JCE encryption and Open SSL encryption.


If it is the case it seems we have to submit a formal "encryption
classification request", and export would be more restricted on which
countries are permitted.


See:

https://www.bis.doc.gov/index.php/policy-guidance/encryption/classification


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

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

Re: Interest in some code to read DMG files?

[Stian Soiland-Reyes]

It certainly sounds like it could fit within Commons VFS, or perhaps
Commons Compress.

DMG is tricky as it's a filesystem image, which could have many types of
filesystems within it. It sounds like you have already thought about it -
what inner filesystems in DMG would this code plan to support?
On 21 May 2016 9:10 a.m., "Christofer Dutz" 
wrote:

> Hi,
>
>
> for the Apache Flex project I have been working hard on some code to
> unpack DMG images as all libs I could find were GPL I implemented
> everything by reading the specs. I am not quite finished. The DMG part is
> finished, now I'm working on parsing the mac filesystem BTree ... will
> still take a while, but I think locating this code in the Apache Flex
> project doesn't seem to be the right place. After reading the Apache
> Commons VFS release earlier today I think this would be the best place to
> put it.
>
>
> Is there any interest in this?
>
>
> Chris
>

RE: US Export classification & ECCN registration for encryption in commons?

[Stian Soiland-Reyes]

On 23 May 2016 3:42 a.m., "Chen, Haifeng"  wrote:
>
> So how about we go to the process of ECCN 5D002 self-classify category
and registration like Taverna did?

Agree on your evaluation, so ECCN 5D002 is good. This makes things a lot
easier! :)

Let's create a Jira issue to track the categorisation process.

Re: [VOTE] Release Apache Commons CSV 1.4 RC1

[Stian Soiland-Reyes]

On 23 May 2016 at 06:53, Gary Gregory  wrote:
> Apache Commons CSV 1.4 RC1 is available for review here:
>
> https://dist.apache.org/repos/dist/dev/commons/csv/1.4-RC1/
> (revision 13733)

I assume you mean

https://dist.apache.org/repos/dist/dev/commons/csv/CSV_1_4_RC1/  (@13733)

My vote: -1  due to NOTICE issues.


Checked:

+1 Signatures
+1 Hashes
+1 mvn clean install
+1 mvn apache-rat:check
-1 NOTICE is outdated, and material copyright

Notice includes:


src/main/resources/contract.txt
This file was downloaded from
http://www.ferc.gov/docs-filing/eqr/soft-tools/sample-csv/contract.txt
and contains neither copyright notice nor license.

src/main/resources/transaction.txt
This file was downloaded from
http://www.ferc.gov/docs-filing/eqr/soft-tools/sample-csv/transaction.txt
and contains neither copyright notice nor license.


(I don't care that the URLs are 404)





however these files are now in

./src/test/resources/ferc.gov/


We can't include files that "contain neither copyright notice nor
license" - that means regular copyright remains and we don't have
permission to use it.


As a US government organization, ferc.gov SHOULD be publishing under
Public Domain - but we can't include their work if that has not been
expressed.


Note that I have not searched the email archive or Jira in case the IP
of these files have already been cleared.




This bit of the NOTICE should be removed as it is not a required
attribution notice. Move it to a comment in the apache-rat exclude in
the pom.xml

src/test/resources/CSVFileParser/bom.csv
src/test/resources/CSVFileParser/test.csv
src/test/resources/CSVFileParser/test_default.txt
src/test/resources/CSVFileParser/test_default_comment.txt
src/test/resources/CSVFileParser/test_rfc4180.txt
src/test/resources/CSVFileParser/test_rfc4180_trim.txt
src/test/resources/CSVFileParser/testCSV85.csv
src/test/resources/CSVFileParser/testCSV85_default.txt
src/test/resources/CSVFileParser/testCSV85_ignoreEmpty.txt
These files are used as test data and test result specifications.



Checked using Ubuntu 16:04 x/64:

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T16:41:47+00:00)
Maven home: /home/stain/software/maven
Java version: 1.8.0_91, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-22-generic", arch: "amd64", family: "unix"



> commons-csv-1.4-bin.tar.gz
> (SHA1: 19806d3a6b2f8c6569f50b294da1d3f3a5be4429)
> commons-csv-1.4-bin.zip
> (SHA1: f551f471081c75a4cb6710b9981a3e0c858debd3)
> commons-csv-1.4-src.tar.gz
> (SHA1: 08151857d96af4c95ddbd5131f40e56b05eb088f)
> commons-csv-1.4-src.zip
> (SHA1: c379ec116117e0a9bbd66f7bb3279cfe1e9697ef)
>
>   Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1172/org/apache/commons/commons-csv/1.4/
>
> These are the artifacts and their hashes:
>
> commons-csv-1.4-test-sources.jar
> (SHA1: fa468674f62177f6182a318f4d1bb7b385e146b6)
> commons-csv-1.4-sources.jar
> (SHA1: f8e3c6b3d3c1a5bbd80ad5b73c72a98af471c401)
> commons-csv-1.4.pom
> (SHA1: c065422ac0fd4ff25016fb2fcb00af3874103935)
> commons-csv-1.4.jar
> (SHA1: 5221b8e5d24f26aab600d367313c6620c7f1fdb6)
> commons-csv-1.4-javadoc.jar
> (SHA1: 878a92f52149c3d3050332fbfb9702ed3a64c515)
> commons-csv-1.4-tests.jar
> (SHA1: 2eb791225c8f002be1fa0f4b6d68110e63b14f5a)
>
>   Details of changes since 1.3 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/csv/CSV_1_4_RC1/RELEASE-NOTES.txt
> http://home.apache.org/~ggregory/csv-1.4-rc1/site/changes-report.html
>
>
>   The tag is here:
> http://svn.apache.org/repos/asf/commons/proper/csv/tags/csv-1.4-RC1/
> (revision 1745108)
>
>   Site:
> http://home.apache.org/~ggregory/csv-1.4-rc1/site/
>
>(some *relative* links are broken - these will be OK once the site
> is deployed)
>
>   Clirr Report (compared to 1.3):
> http://home.apache.org/~ggregory/csv-1.4-rc1/site/clirr-report.html
>
>   RAT Report:
> http://home.apache.org/~ggregory/csv-1.4-rc1/site/rat-report.html
>
>   KEYS:
>   https://www.apache.org/dist/commons/KEYS
>
>   Please review the release candidate and vote.
>
>   This vote will close no sooner than 72 hours from now,
>   i.e. sometime after 23:00 PST 25 May 2016
>
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
>   Thanks!
>   Gary Gregory
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Ed

Re: [Vfs] to git (was: Apache Commons git repositories now writable for all ASF committers)

[Stian Soiland-Reyes]

t denied to jochenw.
>> > > fatal: unable to access
>> > > 'https://github.com/apache/commons-fileupload.git/': The requested URL
>> > > returned error: 403
>> > >
>> > >
>> > > --
>> > > 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
>> > >
>> > >
>> > > -
>> > > 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
>> >
>> >
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>



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

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

Re: Stian to PMC

[Stian Soiland-Reyes]

Done - now live on

http://commons.apache.org/team-list.html


Do I need to do something special to get Jira admin access? (e.g. to
manage Versions)

On 24 May 2016 at 20:20, Gary Gregory  wrote:
> Stian,
>
> You should add yourself as a PMC member here:
> https://svn.apache.org/repos/asf/commons/cms-site/trunk/pom.xml
>
> Gary
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory



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

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

Re: [CSV] License Issues in Commons CSV (Was: [VOTE] Release Apache Commons CSV 1.4 RC1)

[Stian Soiland-Reyes]

; >> >>
>>> >> >
>>> >> > These files show that we are testing against real world data, as
>>> opposed
>>> >> to
>>> >> > using our own CSVPrinter to create test data or cobbling up tests by
>>> >> hand.
>>> >> > Using our own CSVPrinter would provide that we can parse what we can
>>> >> print,
>>> >> > a useful test but this does not show "real" data. Hand-created test
>>> files
>>> >> > may have a subjective bias as to the range of features tested.
>>> >> >
>>> >> > At least it is a sanity check, and for more, using real world data may
>>> >> also
>>> >> > end up letting us find bugs, edge cases and discover the need for new
>>> >> > features.
>>> >>
>>> >> Then if we want to keep them, we need to establish what the license is.
>>> >> Or find some other CSV files that have a suitable license.
>>> >>
>>> >> Note that the FercGovTest.java file contains details which appear to
>>> >> be extracted from the test files.
>>> >>
>>> >> If we want to release CSV in the near future, I suggest we remove the
>>> >> data files and the test case for now.
>>> >>
>>> >> Meanwhile someone can try again to contact FERC. I note that there is
>>> >> a phone number, so perhaps there is someone in the US who can progress
>>> >> this.
>>> >>
>>> >> The relevant page is at:
>>> >>
>>> >> http://www.ferc.gov/docs-filing/eqr/xml.asp
>>> >>
>>> >> I also note that there are two e-mail addresses on the page.
>>> >> They are different from the one mentioned in the JIRA from which there
>>> >> was no response, so might be worth trying.
>>> >>
>>> >> > Gary
>>> >> >
>>> >> >
>>> >> >>
>>> >> >> > Gary
>>> >> >> >
>>> >> >> >>
>>> >> >> >> Gary
>>> >> >> >>
>>> >> >> >> On Mon, May 23, 2016 at 10:49 AM, Gary Gregory <
>>> >> garydgreg...@gmail.com>
>>> >> >> >> wrote:
>>> >> >> >>
>>> >> >> >>> Hi All:
>>> >> >> >>>
>>> >> >> >>> These files were discussed here:
>>> >> >> >>> https://issues.apache.org/jira/browse/LEGAL-175
>>> >> >> >>>
>>> >> >> >>> I never got a reply IIRC from FERC, see the above link for my
>>> email.
>>> >> >> >>>
>>> >> >> >>> So we decided to ship the files in the configuration as they
>>> still
>>> >> are
>>> >> >> in
>>> >> >> >>> 1.4-RC1.
>>> >> >> >>>
>>> >> >> >>> I looks like we want to do it differently now, so:
>>> >> >> >>>
>>> >> >> >>> - I removed the entries from the NOTICE file.
>>> >> >> >>>
>>> >> >> >>> - I added a comment in the POM RAT excludes section.
>>> >> >> >>>
>>> >> >> >>> FWIW: Here are the current FERC examples:
>>> >> >> >>> http://www.ferc.gov/docs-filing/eqr/xml.asp but still no
>>> license or
>>> >> >> >>> copyright on the files.
>>> >> >> >>>
>>> >> >> >>> In the future (>1.4), I'd like to use these files and keep
>>> >> gathering a
>>> >> >> >>> pile of IRL examples.
>>> >> >> >>>
>>> >> >> >>> Is the state of trunk (now at revision 1745238) OK for an RC2?
>>> >> >> >>>
>>> >> >> >>> Gary
>>> >> >> >>>
>>> >> >> >>> On Mon, May 23, 2016 at 7:14 AM, Benedikt Ritter <
>>> >> brit...@apache.org>
>>> >> >> >>> wrote:
>>> >> >> >>>
>>> >> >> >>>> Hi,
>>&g

Re: [VOTE] Release Apache Commons FileUpload 1.3.2 based on RC1

[Stian Soiland-Reyes]

My vote: +1 (binding)

FYI - dist sha1 checksums according to svn r13750

6650d1c878b1142a0c8e3be3534ad24d6f422fc2
binaries/commons-fileupload-1.3.2-bin.tar.gz
0d1004f3aab4ecc62b2fb14056b9c92489d79121
binaries/commons-fileupload-1.3.2-bin.zip
6f254ad51f5e2c9d9a039995bc1a2295cabc95f6
source/commons-fileupload-1.3.2-src.tar.gz
10da7c5124b52d713da0f45b2f63ae9683e6591d
source/commons-fileupload-1.3.2-src.zip

Tested:

+1 signatures
+1 hashes
+1 mvn apache-rat:check
+1 mvn clean install
+1 zip vs tar.gz
+1 binary jar content matches target jar
+1 binary jar same checksum in maven repo
+1 -sources.jar matches src.tar
0 mvn site  (except site/index.html says latest is 1.3 instead of 1.3.1)
+1 LICENSE, NOTICE
+1 RELESE-NOTES
+1 PMD, CLR reports
+1 source matches svn tag (except download_fileupload.cgi and
doap_fileupload.rdf)


Tested with:

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T16:41:47+00:00)
Maven home: /home/stain/software/maven
Java version: 1.8.0_91, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-22-generic", arch: "amd64", family: "unix"

On 23 May 2016 at 16:23, Benedikt Ritter  wrote:
> It has been a long time since the last release of Apache Commons
> FileUpload, so I'd like to release Apache Commons FileUpload 1.3.2 based on
> RC1.
>
> Apache Commons FileUpload 1.3.2 RC1 is available for review here:
>   https://dist.apache.org/repos/dist/dev/commons/fileupload (rev 13750)
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1173/commons-fileupload/commons-fileupload/1.3.2/
>
> These are the Maven artifacts and their hashes
>
> commons-fileupload-1.3.2-javadoc.jar
> (SHA1: 12bbb300a1b61e038defb1dee85e8302d6f1bbaa)
> commons-fileupload-1.3.2-sources.jar
> (SHA1: 23996750d5a80dc74dad55633c2a0f3db91462cb)
> commons-fileupload-1.3.2-test-sources.jar
> (SHA1: 2df285ad143910759a3763fcec0cd58e8525d881)
> commons-fileupload-1.3.2-tests.jar
> (SHA1: 310e3713308073a0392be30c129b55e872fe48f6)
> commons-fileupload-1.3.2,jar
> (SHA1: 5d7491ed6ebd02b6a8d2305f8e6b7fe5dbd95f72)
> commons-fileupload-1.3.2.pom
> (SHA1: a4c3e5d590c2e83bba42768c5b5fbef43219b5c4)
>
> Details of the change since 1.3.1 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/fileupload/RELEASE-NOTES.txt
>
> http://home.apache.org/~britter/commons/fileupload-1.3.2-rc1/changes-report.html
>
> I have tested this with:
>   JDK 1.6 and Maven 3.2.5
>   JDK 1.7 and Maven 3.3.9
>   JDK 1.8 and Maven 3.3.9
> Note that commons-fileupload should be JDK 1.5 compatible, but I don't have
> a JDK 1.5 installation on my MacBook. If someone could check the build with
> JDK 1.5, that would be great!
>
> The tag is here:
>
> https://svn.apache.org/repos/asf/commons/proper/fileupload/tags/FILEUPLOAD_1_3_2_RC1
>  (rev 1745203)
>
> Site:
>   http://home.apache.org/~britter/commons/fileupload-1.3.2-rc1/
> (note some *relative* links are broken and the 1.3.2 directories are not
> yet created - these will be OK once the site is deployed)
>
> Clirr Report (compared to 1.3):
>
> http://home.apache.org/~britter/commons/fileupload-1.3.2-rc1/clirr-report.html
> (note that the API additions have been introduced in 1.3.1 not in 1.3.2)
>
> RAT Report:
>
> http://home.apache.org/~britter/commons/fileupload-1.3.2-rc1/rat-report.html
>
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now,
> i.e. sometime after 17:30 CEST 26-May 2016
>
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] +0 OK, but really should fix...
> [ ] -1 I oppose this release because...
>
> Thanks!
> Benedikt



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

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

Re: [VOTE] Release Apache Commons CSV 1.4 RC2

[Stian Soiland-Reyes]

On 25 May 2016 at 05:20, Gary Gregory  wrote:
> Apache Commons CSV 1.4 RC2 is available for review here:
>
> https://svn.apache.org/repos/asf/commons/proper/csv/tags/csv-1.4-RC2
> (revision 1745420)

Did you mean:

https://dist.apache.org/repos/dist/dev/commons/csv/CSV_1_4_RC2/
revision 13776  ?




> commons-csv-1.4-bin.tar.gz
> (SHA1: 620580a88953cbcf4528459e485054e7c27c0889)
> commons-csv-1.4-bin.zip
> (SHA1: b0060ed8397bfec39b397807f63e778618f324ce)
> commons-csv-1.4-src.tar.gz
> (SHA1: fac74d68fadad3e54025ac23a50c9559013d1b89)
> commons-csv-1.4-src.zip
> (SHA1: 047e0149af25c186969ea8ad2366e8ac6e2b2450)
>
>   Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1175/org/apache/commons/commons-csv/1.4/
>
> These are the artifacts and their hashes:
>
> commons-csv-1.4-test-sources.jar
> (SHA1: 494f6c95c3b00841436d158938249d81b1a7c200)
> commons-csv-1.4-sources.jar
> (SHA1: fde86fe0c44998b90a2a22ac038bc363121c9861)
> commons-csv-1.4.pom
> (SHA1: 28a9778fb5758d19187aad7537181486aeb40ca9)
> commons-csv-1.4.jar
> (SHA1: fc2512d2109144df353501266ac4bbe179058afd)
> commons-csv-1.4-javadoc.jar
> (SHA1: 4673391adc8a1f8a107a0a52bafed0618808a904)
> commons-csv-1.4-tests.jar
> (SHA1: 93124b682ceb24ac62af06d08736d430cf13fcb6)
>
>   Details of changes since 1.3 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/csv/CSV_1_4_RC2/RELEASE-NOTES.txt
> http://home.apache.org/~ggregory/csv-1.4-rc2/site/changes-report.html
>
>
>   The tag is here:
> http://svn.apache.org/repos/asf/commons/proper/csv/tags/csv-1.4-RC2/
> (revision 1745420)
>
>   Site:
> http://home.apache.org/~ggregory/csv-1.4-rc2/site/
>
>(some *relative* links are broken - these will be OK once the site
> is deployed)
>
>   Clirr Report (compared to 1.3):
> http://home.apache.org/~ggregory/csv-1.4-rc2/site/clirr-report.html
>
>   RAT Report:
> http://home.apache.org/~ggregory/csv-1.4-rc2/site/rat-report.html
>
>   KEYS:
>   https://www.apache.org/dist/commons/KEYS
>
>   Please review the release candidate and vote.
>
>   This vote will close no sooner than 72 hours from now,
>   i.e. sometime after 23:00 PST 25 May 2016
>
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
>   Thanks!
>   Gary Gregory
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory



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

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

Re: [VOTE] Release Apache Commons CSV 1.4 RC2

[Stian Soiland-Reyes]

Thanks for preparing this release candidate, Gary!

My vote: +1 (binding)

Tested:

+1 signatures, hashes
+1 sources-jar vs src.zip
+1 mvn clean install
+1 mvn apache-rat:check
+1 LICENSE, NOTICE (thanks!)
+1 RELEASE-NOTES
0 Confusing file LICENSE-header.txt should not be in the src dist
+1 mvn repository jar/gz/zip matches src/bin in dist
0 svn only matches src if I ignore whitespace (CRLF added in src
archives) -- also src/test/**/CSVBenchmark.java is missing from src -
why?
+1 bin jar filenames match target jar



Does CR vs CRLF make any difference for the CSV parsing and our test resources?

Using just "svn co" in Ubuntu only these files are locked to have CRLF:

stain@biggiebuntu:~/src/csv-1.4-rc2/svn$ find . -type f | xargs file |grep CRLF
./src/assembly/src.xml:
 exported SGML document, ASCII text, with CRLF line terminators
./src/assembly/bin.xml:
 exported SGML document, ASCII text, with CRLF line terminators
./src/test/resources/CSVFileParser/test.csv:
 ASCII text, with CRLF line terminators
./src/test/resources/CSVFileParser/testCSV85.csv:
 ASCII text, with CRLF line terminators
./src/test/java/org/apache/commons/csv/CSVFormatPredefinedTest.java:
 ASCII text, with CRLF line terminators



Tested with:

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T16:41:47+00:00)
Maven home: /home/stain/software/maven
Java version: 1.8.0_91, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-22-generic", arch: "amd64", family: "unix"

On 25 May 2016 at 17:37, Stian Soiland-Reyes  wrote:
> On 25 May 2016 at 05:20, Gary Gregory  wrote:
>> Apache Commons CSV 1.4 RC2 is available for review here:
>>
>> https://svn.apache.org/repos/asf/commons/proper/csv/tags/csv-1.4-RC2
>> (revision 1745420)
>
> Did you mean:
>
> https://dist.apache.org/repos/dist/dev/commons/csv/CSV_1_4_RC2/
> revision 13776  ?
>
>
>
>
>> commons-csv-1.4-bin.tar.gz
>> (SHA1: 620580a88953cbcf4528459e485054e7c27c0889)
>> commons-csv-1.4-bin.zip
>> (SHA1: b0060ed8397bfec39b397807f63e778618f324ce)
>> commons-csv-1.4-src.tar.gz
>> (SHA1: fac74d68fadad3e54025ac23a50c9559013d1b89)
>> commons-csv-1.4-src.zip
>> (SHA1: 047e0149af25c186969ea8ad2366e8ac6e2b2450)
>>
>>   Maven artifacts are here:
>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1175/org/apache/commons/commons-csv/1.4/
>>
>> These are the artifacts and their hashes:
>>
>> commons-csv-1.4-test-sources.jar
>> (SHA1: 494f6c95c3b00841436d158938249d81b1a7c200)
>> commons-csv-1.4-sources.jar
>> (SHA1: fde86fe0c44998b90a2a22ac038bc363121c9861)
>> commons-csv-1.4.pom
>> (SHA1: 28a9778fb5758d19187aad7537181486aeb40ca9)
>> commons-csv-1.4.jar
>> (SHA1: fc2512d2109144df353501266ac4bbe179058afd)
>> commons-csv-1.4-javadoc.jar
>> (SHA1: 4673391adc8a1f8a107a0a52bafed0618808a904)
>> commons-csv-1.4-tests.jar
>> (SHA1: 93124b682ceb24ac62af06d08736d430cf13fcb6)
>>
>>   Details of changes since 1.3 are in the release notes:
>>
>> https://dist.apache.org/repos/dist/dev/commons/csv/CSV_1_4_RC2/RELEASE-NOTES.txt
>> http://home.apache.org/~ggregory/csv-1.4-rc2/site/changes-report.html
>>
>>
>>   The tag is here:
>> http://svn.apache.org/repos/asf/commons/proper/csv/tags/csv-1.4-RC2/
>> (revision 1745420)
>>
>>   Site:
>> http://home.apache.org/~ggregory/csv-1.4-rc2/site/
>>
>>(some *relative* links are broken - these will be OK once the site
>> is deployed)
>>
>>   Clirr Report (compared to 1.3):
>> http://home.apache.org/~ggregory/csv-1.4-rc2/site/clirr-report.html
>>
>>   RAT Report:
>> http://home.apache.org/~ggregory/csv-1.4-rc2/site/rat-report.html
>>
>>   KEYS:
>>   https://www.apache.org/dist/commons/KEYS
>>
>>   Please review the release candidate and vote.
>>
>>   This vote will close no sooner than 72 hours from now,
>>   i.e. sometime after 23:00 PST 25 May 2016
>>
>>
>>   [ ] +1 Release these artifacts
>>   [ ] +0 OK, but...
>>   [ ] -0 OK, but really should fix...
>>   [ ] -1 I oppose this release because...
>>
>>   Thanks!
>>   Gary Gregory
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
>
>
> --
> Stian Soiland-Reyes
> Apache Commons, Apache Taverna (incubating), Apache Commons RDF (incubating)
> http://orcid.org/-0001-9842-9718



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

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