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: [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

[ANNOUNCE] Apache Commons RDF 0.3.0-incubating

[Stian Soiland-Reyes]

The Apache Commons RDF team is pleased to announce:

* Apache Commons RDF 0.3.0-incubating


Apache Commons RDF aims to provide a common Java API for RDF 1.1
graphs and datasets.

Commons RDF 0.3.0 adds API bindings for Apache Jena, Eclipse RDF4J,
JSON-LD Java as well as a standalone implementation.

This release also adds support for Quads, Datasets and generalized RDF.

Note that Commons RDF 0.3.0 adds an experimental RDFParser API which
is subject to change in the following releases; we welcome any
feedback and suggestions.


Commons RDF 0.3.0 is available from Maven Central and from:

https://commonsrdf.incubator.apache.org/download


For documentation and more, see
https://commonsrdf.incubator.apache.org/



Apache Commons RDF is an effort undergoing incubation at The Apache
Software Foundation (ASF) sponsored by the Apache Incubator PMC.
Incubation is required of all newly accepted projects until a further
review indicates that the infrastructure, communications, and decision
making process have stabilized in a manner consistent with other
successful ASF projects. While incubation status is not necessarily a
reflection of the completeness or stability of the code, it does
indicate that the project has yet to be fully endorsed by the ASF.



sha1 checksums:
965cbbb52946ae9ba710ab19a8fb931fbfe65e7f
apache-commons-rdf-0.3.0-incubating-src.zip
9e08b3edcc633eb07a1c303b1939a0faaebb6c1f
apache-commons-rdf-0.3.0-incubating-src.tar.gz


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

How to publish multi-module site..?

[Stian Soiland-Reyes]

Hi, (in particular Gilles and Artem)

What was the status of how to do a multi-site publish?  I just tried
now for the Commons RDF 0.3.0 site, and I could not get it to work
properly.


As mentioned in
http://central.maven.org/maven2/org/apache/commons/commons-parent/41/commons-parent-41.pom
I added a to  using
scm:svn:${commons.scmPubUrl}


Note that as Commons RDF is still in the incubator (watch this space)
it has a slightly different properties:

https://svn.apache.org/repos/infra/websites/production/commonsrdf/content/

${project.build.directory}/site-content


But I could not get it to publish the submodule sites correctly.


mvn clean package site-deploy

  overwrites the main site with the last module's site instead! (Do not use!)




mvn clean package site scm-publish:publish-scm

seems to work - but does not publish the sub-sites (e.g.
commons-rdf-api/ subfolder)


mvn clean package site site:stage scm-publish:publish-scm

seems to have the same problem.


And so I had to do this manual hack to afterwards add the submodules
site folders to the SVN of the website:

for a in api integration-tests jena jsonld-java rdf4j simple ;
  do cp -r $a/target/site target/site-content/commons-rdf-$a ;
done

cd target/site-content/
svn add commons-rdf-*
svn commit -m "submodules"


Any ideas..?

-- 
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: How to publish multi-module site..?

[Stian Soiland-Reyes]

On 16 November 2016 at 11:26, Stian Soiland-Reyes  wrote:
> But I could not get it to publish the submodule sites correctly.
> mvn clean package site-deploy
>
>   overwrites the main site with the last module's site instead! (Do not use!)

https://maven.apache.org/plugins/maven-site-plugin/examples/multimodule.html
mentions


> If subprojects inherit the (distribution) site URL from a parent POM, they 
> will automatically append their artifactId to form their effective deployment 
> location. This goes for both the project url and the url defined in the 
> element of the pom.

> If your multi-module tree does not follow the Maven conventions, or if module 
> directories are named differently than module artifacts, you have to specify 
> the url's for each child project. See also How does the Site Plugin use the 
>  element in the POM?.

This is the case for Commons RDF, as it has sub-modules like
commons-rdf-api, which (for some reason) is in a subfolder named api/
-- perhaps renaming them to match the artifactId is sufficient?


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

[DISCUSS] Commons RDF as new component?

[Stian Soiland-Reyes]

Commons RDF (incubating) has been in the Apache Incubator since 2015,
with an aim to graduate into the Apache Commons PMC.   I think now the
time has come to propose such a move.


This route was agreed with the Commons PMC at the time, and we have
had good guidance from our mentors, including Commons PMC folks Gary
Gregory, Benedikt Ritter and lately myself :)




As noted in the 0.3.0 release today, Commons RDF aims to provide a
common Java API for RDF 1.1 graphs and datasets.  Commons RDF 0.3.0
adds API bindings for Apache Jena, Eclipse RDF4J, JSON-LD Java as well
as a standalone implementation.

http://commonsrdf.incubator.apache.org/


Now I think Commons RDF is stabilized and is ready to graduate to be a
component under Commons PMC where we can do a 1.0.0 release to mark
the spot.


(Concurrent thread on dev@commonsrdf:
https://lists.apache.org/thread.html/760b2d58e344e51550dcc9f6452395efe72e97d3dc06169ef72f09c6@%3Cdev.commonsrdf.apache.org%3E
)


I must admit that community-wise Commons RDF is not as strong as when
the podling started - forming a uniform API across multiple
implementations and use cases did mean many hard technical and
semantic discussions which caused some people to withdraw for a while.
Several has since returned as indirect contributors (e.g. code
review).


Now that the Commons RDF API has settled, and given that Commons has a
"any ASF committer have write access" policy and an open development
mode, I would like to propose here (and at dev@commonsrdf) that the
component graduate to be owned by Apache Commons PMC.


Views..?


Here's a project maturity report
https://github.com/apache/incubator-commonsrdf/blob/master/MATURITY.md



Want to crunch some code ? Have a look at

https://commonsrdf.incubator.apache.org/download
https://github.com/apache/incubator-commonsrdf/
https://commonsrdf.incubator.apache.org/apidocs/


-- 
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: [ANNOUNCE] Apache Commons RDF 0.3.0-incubating

[Stian Soiland-Reyes]

Agree that the announce emails need to be generic enough.

However I am not sure - if you don't know what RDF is, then you are
almost just as likely to not know what "Resource Description
Framework" is; as practically no-one uses this expansion anymore.

The Semanic Web community does however now often use the term "Linked
Data" to include the "http" aspect, which I think could be included in
our Commons RDF description - for instance you could in theory use
Commons RDF to parse (some) http://schema.org/ annotations from the
web - but that would also rely on the parser API which in this release
is currently marked as experimental.


If a developer already know one of popular Java frameworks for RDF,
Jena or RDF4J, and perhaps wish there was some interoperability level
beyond saving and loading RDF files or SPARQL servers, then I hope
they should be able to recognize that Commons RDF is an API that can
provide just that.

But we should also move on to target new RDF users who don't know what
Jena and RDF4J are - perhaps they are scared by their large APIs - and
that is exactly what Commons RDF is also trying to cover.

I am thinking in particular it could be useful to do some kind of RDF
introduction tutorial similar to
https://jena.apache.org/documentation/rdf/ using Commons RDF as API -
which would focus much less on the interoperability aspect.

On 16 November 2016 at 13:50, sebb  wrote:
> What is the project about? Why should I be interested in it?
> [rhetorical questions]
>
> The Announce emails are sent to people not on the developer or user lists.
>
> Whilst the mail does mention RDF, it does not say what RDF is.
> It would help to add a short description, even just adding
> "Resource Description Framework"
> would help as there are other possible meanings for the acronym RDF.
> Most are unlikely to apply but the reader should not have to research this.
>
>
> On 16 November 2016 at 11:15, Stian Soiland-Reyes  wrote:
>> The Apache Commons RDF team is pleased to announce:
>>
>> * Apache Commons RDF 0.3.0-incubating
>>
>>
>> Apache Commons RDF aims to provide a common Java API for RDF 1.1
>> graphs and datasets.
>>
>> Commons RDF 0.3.0 adds API bindings for Apache Jena, Eclipse RDF4J,
>> JSON-LD Java as well as a standalone implementation.
>>
>> This release also adds support for Quads, Datasets and generalized RDF.
>>
>> Note that Commons RDF 0.3.0 adds an experimental RDFParser API which
>> is subject to change in the following releases; we welcome any
>> feedback and suggestions.
>>
>>
>> Commons RDF 0.3.0 is available from Maven Central and from:
>>
>> https://commonsrdf.incubator.apache.org/download
>>
>>
>> For documentation and more, see
>> https://commonsrdf.incubator.apache.org/
>>
>>
>>
>> Apache Commons RDF is an effort undergoing incubation at The Apache
>> Software Foundation (ASF) sponsored by the Apache Incubator PMC.
>> Incubation is required of all newly accepted projects until a further
>> review indicates that the infrastructure, communications, and decision
>> making process have stabilized in a manner consistent with other
>> successful ASF projects. While incubation status is not necessarily a
>> reflection of the completeness or stability of the code, it does
>> indicate that the project has yet to be fully endorsed by the ASF.
>>
>>
>>
>> sha1 checksums:
>> 965cbbb52946ae9ba710ab19a8fb931fbfe65e7f
>> apache-commons-rdf-0.3.0-incubating-src.zip
>> 9e08b3edcc633eb07a1c303b1939a0faaebb6c1f
>> apache-commons-rdf-0.3.0-incubating-src.tar.gz
>>
>>
>> --
>> 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
>>
>
> -
> 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: [DISCUSS] Commons RDF as new component?

[Stian Soiland-Reyes]

OK, I'll go straight to VOTE in a couple of days to allow
dev@commonsrdf list to sync up first :)

(One questions would be how to do mailing list transition)

On 16 November 2016 at 13:30, Jochen Wiedmann  wrote:
> On Wed, Nov 16, 2016 at 2:22 PM, Stian Soiland-Reyes  wrote:
>
>> Views..?
>
> Start a formal vote.
>
> Jochen
>
> -
> 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: [DISCUSS] Commons RDF as new component?

[Stian Soiland-Reyes]

Agree that many features are brand new in 0.3.0; I did not mean to imply
that 1.0.0 would be a rubber stamp copy of 0.3.0, but after sorting the
issues, like what we found during your review, for instance the RDFSyntax
as interface instead of enum, or transactions.

Were there any of the issues from your review that we didn't record in
Jira..?

We also need to decide if parser/writer is in or out, and if so what those
interfaces should look like.

Would you be willing to help stabilise, perhaps towards an intermediate
0.4.0 under Commons? Just similar reviews would be a large help!

On 16 Nov 2016 10:25 pm, "Peter Ansell"  wrote:

> Hi Stian,
>
> I personally don't think Commons RDF is ready for a 1.0.0 release. The
> APIs have still been changing recently and many of my comments on pull
> requests, both when I was an active member and recently reviewing the
> still evolving RDF4J integration, have been deferred to the future and
> they would not be easily addressed if a 1.0 release line was declared
> now.
>
> However, that isn't a reason to keep it in incubation. Good luck!
>
> Cheers,
>
> Peter
>
> On 17 November 2016 at 00:22, Stian Soiland-Reyes 
> wrote:
> > Commons RDF (incubating) has been in the Apache Incubator since 2015,
> > with an aim to graduate into the Apache Commons PMC.   I think now the
> > time has come to propose such a move.
> >
> >
> > This route was agreed with the Commons PMC at the time, and we have
> > had good guidance from our mentors, including Commons PMC folks Gary
> > Gregory, Benedikt Ritter and lately myself :)
> >
> >
> >
> >
> > As noted in the 0.3.0 release today, Commons RDF aims to provide a
> > common Java API for RDF 1.1 graphs and datasets.  Commons RDF 0.3.0
> > adds API bindings for Apache Jena, Eclipse RDF4J, JSON-LD Java as well
> > as a standalone implementation.
> >
> > http://commonsrdf.incubator.apache.org/
> >
> >
> > Now I think Commons RDF is stabilized and is ready to graduate to be a
> > component under Commons PMC where we can do a 1.0.0 release to mark
> > the spot.
> >
> >
> > (Concurrent thread on dev@commonsrdf:
> > https://lists.apache.org/thread.html/760b2d58e344e51550dcc9f6452395
> efe72e97d3dc06169ef72f09c6@%3Cdev.commonsrdf.apache.org%3E
> > )
> >
> >
> > I must admit that community-wise Commons RDF is not as strong as when
> > the podling started - forming a uniform API across multiple
> > implementations and use cases did mean many hard technical and
> > semantic discussions which caused some people to withdraw for a while.
> > Several has since returned as indirect contributors (e.g. code
> > review).
> >
> >
> > Now that the Commons RDF API has settled, and given that Commons has a
> > "any ASF committer have write access" policy and an open development
> > mode, I would like to propose here (and at dev@commonsrdf) that the
> > component graduate to be owned by Apache Commons PMC.
> >
> >
> > Views..?
> >
> >
> > Here's a project maturity report
> > https://github.com/apache/incubator-commonsrdf/blob/master/MATURITY.md
> >
> >
> >
> > Want to crunch some code ? Have a look at
> >
> > https://commonsrdf.incubator.apache.org/download
> > https://github.com/apache/incubator-commonsrdf/
> > https://commonsrdf.incubator.apache.org/apidocs/
> >
> >
> > --
> > 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
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [DISCUSS] Commons RDF as new component?

[Stian Soiland-Reyes]

Another is that ServiceLoader don't work well under OSGi without careful
hand holding, so it may be best to leave that to the consumer code rather
than say have a static method in the API with a fixed ServiceLoader.

(I always have trouble with the ServiceLoader instances built in to Java,
which become very sensitive to which thread initates first)

It might be worth adding the OSGi service @annotations (or corresponding
XML files) so RDF implementations can be used as OSGI services; all Commons
RDF modules should already be bundles.

OSGi is probably a good fit with Commons RDF as a library can export only
use of interfaces org.apache.commons.rdf.api, but depend on say RDF4J
internally or get any RDF implementation injected as an OSGi service; which
would not be visible to clients of said library.

And as the Commons RDF API is interoperable, another part of the
application may use Jena (without knowing it) and pass say a Graph to said
library without any problems.

BTW, anchor link didn't work because GitHub and Maven have different
Markdown flavours, link is instead:

https://commonsrdf.incubator.apache.org/userguide.html#Finding_an_RDF_implementation

As noted in there, care must be taken with reuse of an RDF instance and
labeled blank nodes: there is no RDFFactoryFactory.
rdf.getClass().newInstance() should work for anything from a ServiceLoader
(but not an OSGi Service which uses proxy classes).

On 16 Nov 2016 10:02 pm, "Peter Ansell"  wrote:

> Hi Gary,
>
> There is support for java.util.ServiceLoader with the relevant
> META-INF/services files and default constructors, detailed in the
> userguide.md file currently, but could also be in README.md:
>
> https://github.com/apache/incubator-commonsrdf/blob/
> master/src/site/markdown/userguide.md#Finding_an_RDF_implementation
>
> However, users may be aware of which implementation they prefer and
> use it specifically, to match up with their database drivers or other
> libraries so the direct constructor patterns will be used regularly
> also.
>
> The main reason for that would be that if you use the ServiceLoader
> approach (just using the RDF interface) you don't have object level
> access to the mutators to create native Jena/RDF4J/etc. objects out of
> the Commons RDF objects. There should still be static methods for
> those cases, but they are less simple to use than the mutators in
> general.
>
> Cheers,
>
> Peter
>
> On 17 November 2016 at 02:49, Gary Gregory  wrote:
> > In the read me I see a link to an example that has
> >
> > public RDF createFactory() {
> > return new SimpleRDF();
> > }
> >
> > Is/should a service loader be used to allow pluging in/discovering
> > implementations?
> >
> > Gary
> >
> > On Nov 16, 2016 5:22 AM, "Stian Soiland-Reyes"  wrote:
> >
> > Commons RDF (incubating) has been in the Apache Incubator since 2015,
> > with an aim to graduate into the Apache Commons PMC.   I think now the
> > time has come to propose such a move.
> >
> >
> > This route was agreed with the Commons PMC at the time, and we have
> > had good guidance from our mentors, including Commons PMC folks Gary
> > Gregory, Benedikt Ritter and lately myself :)
> >
> >
> >
> >
> > As noted in the 0.3.0 release today, Commons RDF aims to provide a
> > common Java API for RDF 1.1 graphs and datasets.  Commons RDF 0.3.0
> > adds API bindings for Apache Jena, Eclipse RDF4J, JSON-LD Java as well
> > as a standalone implementation.
> >
> > http://commonsrdf.incubator.apache.org/
> >
> >
> > Now I think Commons RDF is stabilized and is ready to graduate to be a
> > component under Commons PMC where we can do a 1.0.0 release to mark
> > the spot.
> >
> >
> > (Concurrent thread on dev@commonsrdf:
> > https://lists.apache.org/thread.html/760b2d58e344e51550dcc9f6452395
> > efe72e97d3dc06169ef72f09c6@%3Cdev.commonsrdf.apache.org%3E
> > )
> >
> >
> > I must admit that community-wise Commons RDF is not as strong as when
> > the podling started - forming a uniform API across multiple
> > implementations and use cases did mean many hard technical and
> > semantic discussions which caused some people to withdraw for a while.
> > Several has since returned as indirect contributors (e.g. code
> > review).
> >
> >
> > Now that the Commons RDF API has settled, and given that Commons has a
> > "any ASF committer have write access" policy and an open development
> > mode, I would like to propose here (and at dev@commonsrdf) that the
> > component graduate to be owned by A

Re: How to publish multi-module site..?

[Stian Soiland-Reyes]

Thanks for having a go, Sergio!


I've tried it (after accidentally touching the live site) with the
corresponding staging SVN directory:


https://svn.apache.org/repos/infra/websites/staging/commonsrdf/trunk/

(for test speed commented out all s except api, using -pl api
would also work)


However deploying did not work for me:

   mvn clean site site:stage scm-publish:publish-scm

As it did not check in the sub-modules folders to SVN.

The top level target/staging/ do contain the correct sub-folders like
api/ and simple/ so they are easy enough to copy over manually to
target/site-content (where they are missing) - we can just complicate
our SITE.md with the manual cp and svn commands.



Neither did this work:

  mvn clean site site:stage site:deploy

(Same result)


Strangely I get log output like:

[INFO] Relativizing decoration links with respect to project URL:
https://commonsrdf.incubator.apache.org/commons-rdf-api/


..however the menu items are correctly going to /api/ - it's just that
api/ and simple/ etc. are not given to "svn add" and thus not checked
in.


Also svn is very slow to check in javadocs.. git2pub any day now please! :-)



On 16 November 2016 at 23:45, Sergio Fernández  wrote:
> I believe with f6a80e6fcd39a8ee7426826e7b25e5cfe0628820 we've fixed the
> COMMONSRDF-50 issue:
>
> https://git1-us-west.apache.org/repos/asf?p=incubator-commonsrdf.git;a=commitdiff;h=f6a80e6fcd39a8ee7426826e7b25e5cfe0628820;hp=b05e3e6e6acad0baeeb7e19358093232119548bb
>
> At list for the the result at target/staging looks good when executing: mvn
> clean site site:stage
>
> Please Stian, take a look to double check it.
>
> Cheers,
>
>
> On Thu, Nov 17, 2016 at 12:25 AM, Gilles 
> wrote:
>
>> On Wed, 16 Nov 2016 11:26:41 +, Stian Soiland-Reyes wrote:
>>
>>> Hi, (in particular Gilles and Artem)
>>>
>>> What was the status of how to do a multi-site publish?  I just tried
>>> now for the Commons RDF 0.3.0 site, and I could not get it to work
>>> properly.
>>>
>>>
>>> As mentioned in
>>>
>>> http://central.maven.org/maven2/org/apache/commons/commons-
>>> parent/41/commons-parent-41.pom
>>> I added a to  using
>>> scm:svn:${commons.scmPubUrl}
>>>
>>>
>>> Note that as Commons RDF is still in the incubator (watch this space)
>>> it has a slightly different properties:
>>>
>>>
>>> https://svn.apache.org/repos/infra/websit
>>> es/production/commonsrdf/content/
>>>
>>>
>>> ${project.build.directory}/
>>> site-content
>>>
>>>
>>> But I could not get it to publish the submodule sites correctly.
>>>
>>>
>>> mvn clean package site-deploy
>>>
>>>   overwrites the main site with the last module's site instead! (Do not
>>> use!)
>>>
>>>
>>>
>>>
>>> mvn clean package site scm-publish:publish-scm
>>>
>>> seems to work - but does not publish the sub-sites (e.g.
>>> commons-rdf-api/ subfolder)
>>>
>>>
>>> mvn clean package site site:stage scm-publish:publish-scm
>>>
>>> seems to have the same problem.
>>>
>>
>> In "Commons RNG" (most recent code is in branch "RNG-30__sampling"),
>> I've been using the following:
>>
>> $ mvn clean install site site:stage
>>
>> It creates the all the (sub-)sites in
>>   src//target
>> and concatenates them under
>>   src/target/staging
>> (in the top-level directory).
>>
>> The problem is that the above command creates a
>>   site-content
>> svn repository inside each module's directory that contains all the
>> (concatenated) web site; whereas IIUC that maven page:
>>   https://maven.apache.org/plugins/maven-site-plugin/examples/
>> multimodule.html
>> it should not be that way (since the "artefactId" and module directory
>> name _are_ the same).
>> IOW, why does maven automatically create the _sub_-site in each
>>   /target/site
>> directory but does not copy its content under
>>   /site-content//
>> ?
>>
>> I wonder why have a "site-content" under each
>>   
>> directory, that would only duplicate whole (currently) or part of
>> the "top-level"
>>   site-content
>> ?
>>
>> Regards,
>> Gilles
>>
>>
>> And so I had to do this manual hack to afterwards add the submodules
>>> site folders to the SVN of the website:
>>>
>>> for a in api integration-tests jena jsonld-java rdf4j simple ;
>>>   do cp -r $a/target/site target/site-content/commons-rdf-$a ;
>>> done
>>>
>>> cd target/site-content/
>>> svn add commons-rdf-*
>>> svn commit -m "submodules"
>>>
>>>
>>> Any ideas..?
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 6602747925
> e: sergio.fernan...@redlink.co
> w: http://redlink.co



-- 
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: Build failed in Jenkins: commons-beanutils #17

[Stian Soiland-Reyes]

lass(ClassLoader.java:247)
> Could not find the main class: ${argLine}.  Program will exit.
> Exception in thread "main" java.lang.NoClassDefFoundError: ${argLine}
> Caused by: java.lang.ClassNotFoundException: ${argLine}
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> Could not find the main class: ${argLine}.  Program will exit.
> Exception in thread "main" java.lang.NoClassDefFoundError: ${argLine}
> Caused by: java.lang.ClassNotFoundException: ${argLine}
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> Could not find the main class: ${argLine}.  Program will exit.
> Exception in thread "main" java.lang.NoClassDefFoundError: ${argLine}
> Caused by: java.lang.ClassNotFoundException: ${argLine}
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> Could not find the main class: ${argLine}.  Program will exit.
> Exception in thread "main" java.lang.NoClassDefFoundError: ${argLine}
> Caused by: java.lang.ClassNotFoundException: ${argLine}
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> Could not find the main class: ${argLine}.  Program will exit.
>
> Results :
>
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
>
> [JENKINS] Recording test results
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 38.554 s
> [INFO] Finished at: 2016-11-17T00:34:24+00:00
> [INFO] Final Memory: 33M/417M
> [INFO] 
> 
> Waiting for Jenkins to finish collecting data
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on 
> project commons-beanutils: ExecutionException The forked VM terminated 
> without properly saying goodbye. VM crash or System.exit called?
> [ERROR] Command was /bin/sh -c cd 
> <https://builds.apache.org/job/commons-beanutils/ws/> && 
> /home/jenkins/tools/java/latest1.6/bin/java -Xmx49M '${argLine}' -jar 
> <https://builds.apache.org/job/commons-beanutils/ws/target/surefire/surefirebooter305925594730864.jar>
>  
> <https://builds.apache.org/job/commons-beanutils/ws/target/surefire/surefire6659744902052208714tmp>
>  
> <https://builds.apache.org/job/commons-beanutils/ws/target/surefire/surefire_0173508163941142471tmp>
> [ERROR] -> [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/MojoFailureException
> [JENKINS] Archiving 
> <https://builds.apache.org/job/commons-beanutils/ws/pom.xml> to 
> commons-beanutils/commons-beanutils/1.9.4-SNAPSHOT/commons-beanutils-1.9.4-SNAPSHOT.pom
> Sending e-mails to: dev@commons.apache.org
> channel stopped
>
> -
> 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: [ALL] How to "deploy" selectively (multi-module project)?

[Stian Soiland-Reyes]

I guess it's only relevant if you were to build a sub-module
independently from the source archive - if it is not deployed then you
would have to build commons-rng-build-tools locally first. Normally as
the rest of the module is deployed to Central it would work fine to
compile just a submodule.

I don't see a problem with commons-rng-build-tools being deployed as
long as we don't document it - we don't need to support API
compatibility here.  If you want to make sure, perhaps they could be
made a test jar?

On 17 November 2016 at 10:58, Gilles  wrote:
> On Thu, 17 Nov 2016 09:30:16 +0100, Jörg Schaible wrote:
>>
>> Benedikt Ritter wrote:
>>
>>> Hello Gilles,
>>>
>>> Gilles  schrieb am Do., 17. Nov. 2016 um
>>> 00:38 Uhr:
>>>
>>>> Hello.
>>>>
>>>> For "Commons RNG" (branch "RNG-30__sampling"),
>>>>
>>>>$ mvn clean deploy -Prelease -Ptest-deploy
>>>>
>>>> fails with
>>>> ---
>>>> Failed to execute goal
>>>> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy)
>>>> on project commons-rng-build-tools: Deployment failed: repository
>>>> element was not specified in the POM inside distributionManagement
>>>> element or in -DaltDeploymentRepository=id::layout::url parameter ->
>>>> [Help 1]
>>>> ---
>>>>
>>>> The module referred to is "commons-rng-build-tools" but in fact
>>>> that one must NOT be released (as, IIUC, it is only used to build
>>>> the "public" modules of the component).
>>>>
>>>> How does one specify that the module should be built but not deployed?
>>>>
>>>
>>> Does http://maven.apache.org/plugins/maven-deploy-plugin/faq.html do the
>>> trick for you?
>>
>>
>> However, if the build tools are required (i.e. referenced) to build the
>> other components, you probably will have to release the build tools also.
>
>
> You mentioned that earlier, but I don't understand why it should
> be released.
> It's the build process that needs this module being built (first).
> It only contains various reporting tools' config files; no Java
> source.[1]
>
> Developers who check out from the repository will get everything,
> and can build the binaries on their own.
>
> Or do I miss something?
>
>
> Regards,
> Gilles
>
> [1] See the contents of the module here:
>
> https://git-wip-us.apache.org/repos/asf?p=commons-rng.git;a=tree;f=commons-rng-build-tools;h=a126e20df3ed8921783b0ca4754e33f6ed6e9692;hb=refs/heads/RNG-30__sampling
>
>
>>
>> Cheers,
>> Jörg
>>
>>
>>>
>>> Regards,
>>> Benedikt
>>>
>>>
>>>>
>>>>
>>>> Regards,
>>>> Gilles
>>>>
>
>
> -
> 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: [ANNOUNCE] Apache Commons JCS 2.0-beta-2 Released

[Stian Soiland-Reyes]

(reduce the CC list, please! :)

http://mvnrepository.com/ is not part of Maven Central, it is
maintained independently by https://twitter.com/frodriguez.
I don't know how often it refresh, but is likely to lag behind Maven
Central by a few days.

For example 
http://mvnrepository.com/artifact/org.apache.commons/commons-rdf-simple
shows 0.3.0, which was published to Central on Tuesday.

On 16 November 2016 at 15:05, Tim Cronin  wrote:
> doesn't show up in the main maven repo the listings
>
> http://mvnrepository.com/artifact/org.apache.commons/commons-jcs-core
>
> On Wed, Nov 16, 2016 at 8:54 AM, Thomas Vandahl  wrote:
>
>> On 16.11.16 14:56, Tim Cronin wrote:
>> > when will it be accessible via maven/ivy repo?
>>
>> It already is:
>> http://repo1.maven.org/maven2/org/apache/commons/commons-
>> jcs-core/2.0-beta-2/
>>
>> Bye, Thomas.
>>
>>
>> -
>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>> For additional commands, e-mail: user-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: [BEANUTILS] Docker Jenkins Job?!

[Stian Soiland-Reyes]

You can delete it, it was my attempt to test the build on different jdk
versions not already on Jenkins slaves, I think there were some oracle vs
OpenJDK issues in the last Release Candidate.

On 18 Nov 2016 10:21 pm, "Benedikt Ritter"  wrote:

> Hello,
>
> we have this jenkins job that executes a build inside some docker
> containers:
> https://builds.apache.org/view/Apache%20Commons/job/
> Commons%20Beanutils%20docker/
>
> Why do we need it?
>
> Benedikt
>

[RDF] Draft introduction to Commons RDF

[Stian Soiland-Reyes]

As raised in the recent vote, Commons RDF could do with an
introduction to RDF for people who have not used RDF before. The API
should be quite suitable for RDF beginners, as unlike say Jena or
Sesame they should not be so easily overwhelmed by the API size.


Here's my first attempt at such a tutorial:
http://commonsrdf.incubator.apache.org/introduction.html


Feedback welcome - particularly from Commons folks who don't know too
much about RDF!


Note that this tutorial does not yet go into the crucial part of
loadinh/save of RDF files, as that involves using the other RDF
implementations, which would require use of Maven for dependencies. I
thing a second tutorial could cover that aspect.

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

[VOTE] Accept Commons RDF as a new component

[Stian Soiland-Reyes]

[Note: this is the Commons PMC vote on dev@commons - there's a
concurrent IPMC VOTE thread on general@incubator]

Since Commons RDF entered incubation, it has evolved the understanding
of its purpose, developed and released code base that is now
stabilizing, moving towards a 1.0.0 release.

Although the Commons RDF developer community is small it has continued
to grow interest, and Apache Commons feels like a natural home for the
component; as intended when this podling was started. We appreciate
all the help we have received from Commons while incubating, in
particular Gary and Benedikt!


The Commons RDF podling has voted to graduate from the Incubator
to join Apache Commons as a new component:

https://lists.apache.org/thread.html/886ed903b3649203c794f7b7409f311b2391ebef1d9157177ba943b6@%3Cdev.commonsrdf.apache.org%3E


This email carries over 3 Commons PMC binding votes from dev@commonsrdf:


+1 Stian Soiland-Reyes (Commons PMC binding)
+1 Benedikt Ritter (Commons PMC binding)
+1 Gary Gregory (Commons PMC binding)


Proposed component name: rdf

Proposed package name: org.apache.commons.rdf

Source code of RDF component:
https://git-wip-us.apache.org/repos/asf?p=incubator-commonsrdf.git
https://github.com/apache/incubator-commonsrdf

Incubator releases:
http://archive.apache.org/dist/incubator/commonsrdf/

Website:
http://commonsrdf.incubator.apache.org/

Project Maturity report (more links from there):
https://github.com/apache/incubator-commonsrdf/blob/master/MATURITY.md


This email propose a VOTE to accept Commons RDF as a new component of
Apache Commons.


Formally the Apache Incubator PMC will also need to agree the
graduation, a concurrent vote thread is on

https://lists.apache.org/list.html?gene...@incubator.apache.org




Please VOTE on graduating Commons RDF as new component:

[ ] +1 Yes, accept Commons RDF as new component
[ ]  0 Undecided
[ ] -1 No, because...


This vote will be open for at least 72 hours, let's say 2016-11-26 17:00 UTC.

-- 
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: [RNG] Aggregate artefacts (for archive download)

[Stian Soiland-Reyes]

Within the assembly descriptor you can use a  for the modules
you want to include.

See
https://github.com/apache/commons-jcs/blob/trunk/commons-jcs-dist/src/assembly/bin.xml
for example, here the assembly is done in a -dist submodule itself, but it
can also be done directly in the parent as long as the assembly plugin is
configured to not run in submodules.

On 24 Nov 2016 8:01 am, "Jörg Schaible" 
wrote:

> Gilles wrote:
>
> > On Wed, 23 Nov 2016 09:12:33 -0800, Gary Gregory wrote:
> >> You use the assembly plugin.
> >>
> >> mvn assembly:single
> >>
> >
> > After running
> >   $ mvn clean deploy assembly:single -Prelease -Ptest-deploy
> >
> > There is no single archive file containing all the distribution.
> > [Neither in "target", nor in "targer/deploy".]
> >
> > Shouldn't something be added to
> >src/assembly/src.xml
> >src/assembly/bin.xml
> > in order to achieve that goal?
>
> That's what Gary meant. You have to add an execution for the assembly to
> the
> parent pom and configure an own assembly descriptor. assembly:single does
> not work from the command line.
>
> Cheers,
> Jörg
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [RNG][ALL] Official vs "courtesy" code ?

[Stian Soiland-Reyes]

I think I'll tend towards agreeing with Jochen here, rather get half the
modules out early than fight ourselves with versioning workarounds if the
rest of the modules are not ready for prime time.

However I see concerns of selective "part releases" and reproducible
builds, so I would do this using Maven profiles - the release profile can
have a smaller  set.

I then think all the modules that appear in the src release should also go
to Nexus as binaries, even if they are more exotic "internal" modules. I
would not mess around with selective deployment as it is a recipe for
maintenance nightmare and manual mistakes.

It only gets tricky if the leftover modules get a release cycle of their
own.

It is OK if the -bin release don't have all modules, that is more of a
convenience of jars that are useful out of the box. I've been thinking for
Commons RDF it would make sense to have a bin with the commons-rdf-api.jar
and commons-rdf-simple.jar as they have no external dependencies - the
remaining Integration modules require a large set of deps and mostly useful
through Maven.

(OSGi folks might still like the extra jars as they are bundles)

On 25 Nov 2016 11:47 am, "Jochen Wiedmann" 
wrote:

> Hi, Gary,
>
>
> I humbly disagree on your response to Gilles questions. In more detail:
>
>
> a. Is it OK if the official release does not contain (5) and (6)?
>[Rationale is that it would allow to make changes without
>bothering about compatibility with _unintended_ uses.]
>
> A release is a release, because it fulfills the typical requirements
> (ASL licensed, source first, binary is for convenience only,
> LICENSE.txt, and NOTICE.txt, etc.)
> and, most importantly, because the PMC endorses it as such.
>
> I can't think of any reason, why the PMC should refuse a release, if
> it fulfills the requirement, just because the source release can be
> used to build four jars only, and not six. At least, I'd be glad to
> vote +1 in such a case.
>
> That being said, and having had the experience of a multi-module
> project (Apache RAT) in the past, I strongly recommend that RNG
>
> - abstains from full releases (all six jar files) and
> - starts by pushing out single jar files by default (in whatever order
> seems to make sense). (Possibly more than one at once, okay.)
>
> Otherwise, I have learned that the hurdle to push out a release can
> become overwhelming, and leads to deferring releases endlessly. Forget
> "release early, release often".
>
> Besides, you'd have to maintain varying build scripts, or even worse:
> Create individual build scripts, depending on what is being released.
> Not, what I would like to see in a project of mine.
>
> b. If so, is it still OK to provide JARs for them via the web site
>(but not upload them to Nexus)?
>
> For all practical purposes, Nexus is more important nowadays for
> distributing binary jars, than the ASF web site. The source archives
> are another story, of course, as they constitute the actual release.
> Those *must* be available from the web site.
>
>
> c. Is it OK that the modules have different versions (reflecting
>the perceived status of development)?
>[This is related to the "commons-rng-sampling" issue of the
>post with subject "Ralease policy for version < 1".]
>
> If they are successfully voted upon: Why not?
>
> Jochen
>
>
> On Thu, Nov 24, 2016 at 7:01 PM, Gary Gregory 
> wrote:
> > Preface: This thread, the questions it contains, as well as other recent
> > emails in general feels like the result of the normal learning curve one
> > must go through when dealing with a Maven multi-module project. This is
> > time well-spent IMO as most non-trivial (>1 jar) projects are
> multi-module
> > projects.
> >
> > Now for the meat:
> >
> > Strictly speaking, Apache Commons (and all Apache projects) release
> sources
> > as the official release artifacts on Apache "dist" servers. Any binary
> > files we provide are a convenience whether on Apache servers or Maven
> > Central.
> >
> > That means that ALL sources for a component (Apache Commons RNG in this
> > case) must be released in the -src ZIPs and GZs. I'd like to hear a good
> > reason not to do that. If a module is not ready for prime time, then I
> > suppose it could either be excluded or packaged in an module and package
> > with an appropriate artifact ID and name (like .ea/-early-access or
> > .experimental/-experimental).
> >
> > It makes the most sense if the -bin version of a component contains the
> > result of building what is in all of the -src ZIP/GZ.
> >
> > So that would be a "no" to (a).
> >
> > "[Rationale is that it would allow to make changes without
> >bothering about compatibility with _unintended_ uses.]"
> >
> > You should make it clear which module you guaranteed binary
> compatibility.
> > For example, in Log4j 2 we do our utmost to keep the API module 100% BC.
> > For all other modules (there are a few), we make no such guarantee but
> also
> > try not to make our user's li

[RESULT] [VOTE] Accept Commons RDF as a new component

[Stian Soiland-Reyes]

On 23 November 2016 at 13:47, Stian Soiland-Reyes  wrote:
> [Note: this is the Commons PMC vote on dev@commons - there's a
> concurrent IPMC VOTE thread on general@incubator]

>
> Please VOTE on graduating Commons RDF as new component:

Thanks to everyone who voted! The results from the Commons PMC are:

+1 Stian Soiland-Reyes (binding)
+1 Benedikt Ritter (binding)
+1 Gary Gregory (binding)
+1 Jochen Wiedmann (binding)
+1 Rob Tompkins
+1 Jörg Schaible (binding)
+1 Bruno P Kinoshita (binding)
+0 Bernd Eckenfels (binding) "there is argument for dedicated community"
+1 Oliver Heger (binding)

The vote PASSES with 7 positive votes (6 binding), 1 abstained and 0
negative votes.

I will let the incubator vote run a bit longer over the weekend to
reflect this result.

-- 
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] Version number(s) for modular components

[Stian Soiland-Reyes]

I think Gilles' reasoning is sound for semantic versioning and releases, in
line with OSGi principles. However I think that would be better suited in a
large or enterprise project with mainly internal usersnpf the libraries
that can play along, not in Apache Commons which are making general
availability libraries for the whole Java community.

So I'm afraid I agree with the quorum here, let's keep it simple with a
single version across modules - it is so much easier for downstream users
if we make the version in the distribution match the tag, which should
match every module (and also the OSGi package version)

Users with Maven can then just have a single $commons.foo.versiom property
to update and it all plays along, as tested in our release candidate.

Having to figure out the internal release policies and selecting across
many different source releases is not just a barrier to use, but also for
inviting new collaborators, they may struggle to know what to rebuild when
fixing a bug.

Another convenience argument for co-releasing is that the 
section will pull the latest friends, users won't have to manage each
version to update, unless they want to deliberately stay behind "at own
risk" (Commons won't have tested that combination)

It does mean we sometimes get "pointless" upgrades on some modules where
nothing has changed. As long as we are not claiming major/breaking changes,
and don't use restricting (version,ranges] I don't think there is a big
problem with that.

The cases Gilles mention that is very much a potential scenario is where a
-utils module does breaking changes, but the -api module has not broken
anything. I think here we can be more lax about our package/artifact name
change rule, so you *could* release foo-api 2.0.0 and foo-utils2 2.0.0.  If
foo-api later breaks, that would be foo-api3 3.0.0 (there was never a
foo-api2) and foo-utils3 3.0.0 (not the very confusing double versioned
foo3-utils2! )

On 26 Nov 2016 10:49 pm, "Jörg Schaible"  wrote:

> Gary Gregory wrote:
>
> > On Sat, Nov 26, 2016 at 9:06 AM, Jörg Schaible 
> > wrote:
> >
> >> Sorry, for me this is going down the wrong road. For me different
> >> versions mean different components. Allowing multiple versions for
> >> modules in one component will exactly open the can of worms Gilles
> >> described below. We had that already with Jakarta.
> >>
> >
> > +1 and we do not need a Commons within Commons.
> >
> > For the case:
> >
> >   commons-modproj-foo-1.0
> >   commons-modproj-bar-1.1
> >
> > You'd just release
> >
> >   commons-modproj-foo-1.0
> >   commons-modproj-bar-1.0
> >
> > and then
> >
> >   commons-modproj-foo-1.1
> >   commons-modproj-bar-1.1
> >
> > If nothing has changed in commons-modproj-foo between 1.0 and 1.1, then
> > that's fine. You just get all your matching modules and you are done.
> >
> >
> >> I still propose commons-rng-tools as separate component. Because of this
> >> mail. KISS.
> >>
> >
> > I'm not even in favor of that. Commons is already loose ecosystem of
> > components, having sibling components will fog things up IMO. It's not
> > just what's compatible with what according to some guidelines, it's more
> > what has been tested with what so I can know for sure what will work.
> When
> > I get Commons Foo 1.3 and it has 10 modules, I know it's all MEANT to
> work
> > together, I KNOW it was all BUILT and TESTED together.
> >
> > Just keep it all in one component and make user's life easy.
>
> We already have dbcp depending heavily on pool.
>
> - Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[RDF] Graduating Commons RDF to Commons PMC

[Stian Soiland-Reyes]

The Commons RDF graduation vote passed on Commons and Incubator, so
Commons RDF will now formally move to become a component of Apache
Commons. Thanks everyone who voted!


I will continue on Wednesday with doing the technical bureaucracy like
updating Incubator meta-files, moving repositories, websites and
"closing" the dev@commonsrdf mailing list (autoreply?), as well as
listing RDF on the Commons main pages.


I hope it won't be too much trouble with the empty commons-rdf
repository already existing: https://github.com/apache/commons-rdf --
I will ask INFRA to delete that so we can formally do a rename in
GitHub to keep all the pull requests and watchers. However I think the
new name will be just that, commons-rdf (not "commonsrdf").

Likewise I'll ask for redirects for the website after deploying it at
https://commons.apache.org/proper/commons-rdf/ and similar for moving
the dist.apache.org artifacts to be under
http://www.apache.org/dist/commons/rdf/


Anything I forgot? Oh, and update our pom.xml to not say "-incubating"
anymore :)


>From now, please post/reply any Commons RDF questions to
dev@commons.apache.org with the subject [RDF]. (I'll send a separate
reminder about this to the dev@commonsrdf list before it closes)


-- 
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][LAZY] Release Commons Parent POM 42 based on RC1

[Stian Soiland-Reyes]

tem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021
>
> Spring Batch in Action
> <
https://www.amazon.com/gp/product/1935182951/ref=as_li_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%20Batch%20in%20Action
>
>
> <
http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951
>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

Re: [VOTE][LAZY] Release Commons Parent POM 42 based on RC1

[Stian Soiland-Reyes]

Just a thing I noticed..

In 
https://dist.apache.org/repos/dist/release/commons/commons-parent/commons-parent-41/
and before we had a -src.tar.gz and -src.zip
(just like any other

while your candidate in
https://dist.apache.org/repos/dist/dev/commons/commons-parent/42-RC1/
 is just the deployed pom file and so can't as easily be "built" or installed.

Not a blocker for me personally, but it would be good if we can keep
the parent similar to the other components, even if it doesn't have
any source code. For instance Debian packages Commons parent.

On 30 November 2016 at 09:25, Stian Soiland-Reyes  wrote:
> +1
>
> Checked:
>
> +1 Signatures, hashes
> +1 tag matches repo matches dist
> +1 No binaries
> +1 Works with beanutils
>
> I got a bug when using it with Commons RDF for "mvn clean package install",
> related to the updated site-plugin:
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.6:site (default-site) on
> project commons-rdf-parent: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.6:site failed: A required class
> was missing while executing
> org.apache.maven.plugins:maven-site-plugin:3.6:site:
> org/apache/maven/doxia/sink/impl/XhtmlBaseSink
>
> This was fixed by updating its doxia-module-markdown dependency from 1.6 to
> 1.7.
>
> With beanutils I tested the parent with "mvn clean install site" and "mvn
> release:prepare".
>
> On 27 November 2016 at 08:21, Gary Gregory  wrote:
>> We have added some enhancements since Commons Parent POM 41 was released,
>> so I would like to release Commons Parent POM 42.
>>
>> Commons Parent POM 42 RC1 is available for review here:
>> https://dist.apache.org/repos/dist/dev/commons/commons-parent/42-RC1/
>> (svn revision 17171)
>>
>> The tag is here:
>>
>>
>> http://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-42-RC1/
>> (svn revision 1771539)
>> N.B. the SVN revision is required because SVN tags are not immutable.
>>
>> Maven artifacts are here:
>>
>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1221/org/apache/commons/commons-parent/42/
>>
>> These are the Maven artifacts and their hashes
>>
>> /org/apache/commons/commons-parent/42/commons-parent-42-site.xml
>> (SHA1: a76e03e9059f31abc5e3c22f4e857366e689068f)
>> /org/apache/commons/commons-parent/42/commons-parent-42-site.xml.asc
>> (SHA1: 16b625891e404d95eb7688a99889dc499148d060)
>> /org/apache/commons/commons-parent/42/commons-parent-42.pom
>> (SHA1: b95e1096a4cf0d8bcd52740900a474b1e7f87dd1)
>> /org/apache/commons/commons-parent/42/commons-parent-42.pom.asc
>> (SHA1: 810728ac23f181f0f706ae0132bdb406288f5859)
>>
>> I built this with:
>>
>> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
>> 2015-11-10T08:41:47-08:00)
>> Maven home: E:\Java\apache-maven-3.3.9\bin\..
>> Java version: 1.8.0_112, vendor: Oracle Corporation
>> Java home: C:\Program Files\Java\jdk1.8.0_112\jre
>> Default locale: en_US, platform encoding: Cp1252
>> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>>
>> The site was built with:
>>
>> Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1;
>> 2014-12-14T09:29:23-08:00)
>> Maven home: E:\Java\apache-maven-3.2.5
>> Java version: 1.7.0_79, vendor: Oracle Corporation
>> Java home: C:\Program Files\Java\jdk1.7.0_79\jre
>> Default locale: en_US, platform encoding: Cp1252
>> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>>
>> [because Maven 3.3.9 gets an exception due to a binary compatiblity break
>> in Slf4j.)
>>
>> Details of changes since 41 are in the release notes:
>>
>>
>> https://dist.apache.org/repos/dist/dev/commons/commons-parent/42-RC1/RELEASE-NOTES.txt
>>
>>
>> https://people.apache.org/~ggregory/commons-parent-42-RC1/site/changes-report.html
>>
>> Site:
>> https://people.apache.org/~ggregory/commons-parent-42-RC1/site/
>> (note some *relative* links are broken and the 42 directories are
>> not yet created - these will be OK once the site is deployed)
>>
>> There is no Clirr Report (compared to 41) since there is no Java code in
>> this project.
>>
>> RAT Report:
>>
>>
>> https://people.apache.org/~ggregory/commons-parent-42-RC1/site/rat-report.html
>> KEYS:
>> https://www.apache.org/dist/commons/KEYS
>>
>> Please review the rele

Re: [ALL] Version number(s) for modular components

[Stian Soiland-Reyes]

Yeah, that could be the better way, with a branched off commit for the
"shrunk" project with a smaller  list in the parent, then no
particular flags are needed to build from the resulting tag or source repo.

I initially planned to do so within the Taverna project (before we moved to
ASF), as it could mean smaller releases and avoiding updating OSGi
coordinates for no-change. It turned out to alienate the rest of the team
as then releasing become even more special, particularly if more than one
submodule needed updating. After moving to ASF we had to do release
artifacts (not just tags and Maven repo) and we abandoned this idea and had
to bite the bullet to release all modules every time.

As an example of projects doing the partial, look at the Clerezza project
which practices this using alternative release parents and dists; as an
outsider I find it a bit difficult to understand what of the project has
been released where (or at all), and which versions go together.

Commons components are luckily small, so I think it could be done - but
only IF NEEDED, rather than as general practice.

There is also the consideration of operation system distributions like
Debian who prefer a single source archive or tag for the whole project (and
no dual versions) - varying this per release means they are going to not
update correctly. Several commons component (including math3) are already
in Debian.

On 30 Nov 2016 9:04 am, "Gilles"  wrote:

> On Tue, 29 Nov 2016 21:56:34 -0600, Matt Sicker wrote:
>
>> What if a feature was added to the maven-release-plugin to release a
>> subset
>> of submodules? I wonder how feasible that would be.
>>
>
> When I thought of independent module releases, I assumed that
> it would just be a matter of excluding some of the ""
> sections in the (parent) POM.  [That seemed to work for making
> the Jenkins build pass on Java 6 while the "commons-rng-examples"
> requires Java 7.]
>
> Gilles
>
> On 28 November 2016 at 19:00, Jörg Schaible  wrote:
>>
>> Gilles wrote:
>>>
>>> > On Mon, 28 Nov 2016 07:31:36 -0700, Apache wrote:
>>> >> Gilles,
>>> >>
>>> >> If you try to do this you are going to get very frustrated with
>>> >> Maven. You cannot use the Maven Release plugin if all the versions
>>> >> are
>>> >> not SNAPSHOTs, and if they always have to be SNAPSHOTs it makes very
>>> >> little sense to have them be out of sync. If you don’t use the
>>> >> release
>>> >> plugin then you will have to come up with some custom release
>>> >> mechanism that somehow can only release a portion of your project.
>>> >> This is going to get rather messy as you will constantly be updating
>>> >> the parent pom to increment versions and require that to be released
>>> >> along with the modules you are releasing - which means your other
>>> >> modules really need to be updated to reflect the new parent version.
>>> >>
>>> >> To be honest, I did what you are suggesting at a former employer. We
>>> >> eventually stopped and synchronized the versions of all the modules.
>>> >> It simply wasn’t worth the effort to have all the versions be
>>> >> different and the only real cost was releasing components with new
>>> >> versions that hadn’t changed.
>>> >
>>> > Thanks for the testimony.
>>> > Even if I have no clue how the version string causes a problem,
>>> > I can readily concede that we can be constrained in how to manage
>>> > a project because of the shortcomings of some tool.
>>>
>>> There is no no short coming, you can do otherwise, but if you follow
>>> conventions Maven makes your life easy (Maven is all about conventions).
>>> However, the release process described in rng does not use the release
>>> plugin, so the point is moot.
>>>
>>> > Out of curiosity, is there an alternative (to maven?) that would
>>> > not suffer from this limitation?
>>>
>>> It's not the tool we're discussing.
>>>
>>> Cheers,
>>> Jörg
>>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [RDF] Graduating Commons RDF to Commons PMC

[Stian Soiland-Reyes]

On 30 November 2016 at 03:58, Matt Sicker  wrote:
> Is there anything to be done for jira? Also, don't forget to update the scm
> URLs in the pom file.

Yes, I've now changed the permissions of COMMONSRDF in Jira (should
now match IO, all "Commons developers" are 'Admins'), and asked INFRA
to change it to the commons notification scheme (issues@commons). I
also put  Apache Commons Developers  (e.g. issues@commons) as the
"Lead".

I also renamed the Jenkins build from incubator-commonsrdf to
commons-rdf (but did not change it's git repo setting yet).

-- 
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] Version number(s) for modular components

[Stian Soiland-Reyes]

I don't think we have to be super rigid, just have a general principle. If
a case comes up, we can consider deviations then, rather than form fixed
rules from hypothetical scenarios and then be bound by them.

Something like RFC-style SHOULD - a component release may deviate from the
general rule, but then needs to be aware of the consequences and kind of
justify it on a case by case basis.

(Example: we released a new  "major" version BCEL 6 but ended up NOT
changing the package/artifact away from bcel5, even if that is Commons
general rule for major releases. This meant many downstream users could
upgrade without breaking their own APIs.)

As for "dual versions" I'm afraid that was a bit of a tangent - if Foo
release 2.0 produced foo-api 2.0 and foo-util 2.0, then in Debian this
would typically be a single source project "commons-foo" that then produces
two jars in each their own Deb.

Now if Foo Util release 2.1 comes out, which don't include foo-api, then
Debian can't use the same build instructions to build a foo-util 2.1 Deb,
as they would then first need to compile foo-api 2.0 from a different
release. (As an open source distro, Debian insists on compiling from source
and don't access Maven Central). That would however also install the old
foo-util 2.0 - but in Debian you can't have two versions of the same
library without renaming to include the version number in the package name.

A possible workaround then is for such a release to also include the old
2.0 foo-api source, the Debian packaging would the only need to deal with
the differentiated version numbers. This would however require some
trickery release-wise or repository-wise (e.g. gitflow model). Trickery and
complexity makes it harder for everyone.

I'm not sure what rational evidence to present as I think this is mainly a
"style" issue. We have heard several anecdotal arguments against
sub-releases as a general principle, but there is no absolute rational case
against it - many Maven users still do it, so it depends on the situation.
We are also "constrained" by ASF policy to make source releases as
archives, Commons' current use of Maven, and a general feeling about what
can be a separate Commons Component.

This can all change over time - I think this discussion is part of that. In
general open source (e.g. on GitHub) I observe a trend towards smaller
projects in smaller git repositories, with faster release cycles, with
fixes going from a pull request to live deployment in less than a day. ASF
have certain infrastructure, policies and practices, Commons modulate with
our own, and each component can tweak those. It's not all fixed in stone,
changes happen when there is  community consensus and someone actively
driving change.

So thank you for raising this point, we should not just assume that
whatever we did yesterday should always be the same way!

I do hope we can agree that the general rule for Commons is simplicity,
both for the user and for developers. While an unnecessary module upgrade
is not as "beautiful" as clean semantic version separations per module, it
is, I would argue, simpler to deal with for both consumers, developers and
release managers.

On 1 Dec 2016 9:05 am, "Gilles"  wrote:

> On Wed, 30 Nov 2016 10:23:37 +, Stian Soiland-Reyes wrote:
>
>> Yeah, that could be the better way, with a branched off commit for the
>> "shrunk" project with a smaller  list in the parent, then no
>> particular flags are needed to build from the resulting tag or source
>> repo.
>>
>> I initially planned to do so within the Taverna project (before we moved
>> to
>> ASF), as it could mean smaller releases and avoiding updating OSGi
>> coordinates for no-change. It turned out to alienate the rest of the team
>> as then releasing become even more special, particularly if more than one
>> submodule needed updating. After moving to ASF we had to do release
>> artifacts (not just tags and Maven repo) and we abandoned this idea and
>> had
>> to bite the bullet to release all modules every time.
>>
>
> IIUC, it then makes it easier for the RM, not the users (especially
> those who have to upgrade for "no-change").
>
> I've no problem with that; but let's just say it the way it is.
>
> As an example of projects doing the partial, look at the Clerezza project
>> which practices this using alternative release parents and dists; as an
>> outsider I find it a bit difficult to understand what of the project has
>> been released where (or at all), and which versions go together.
>>
>
> I was not considering a way to make it more difficult for users:
> either they don't touch anything, or they upgrade; in the latter
> alternative, a few lines in the re

Re: [VOTE][LAZY] Release Commons Parent POM 42 based on RC1

[Stian Soiland-Reyes]

I did "mvn clean install -Prelease" from SVN and got in target/:

commons-parent-42-SNAPSHOT-src.tar.gz
commons-parent-42-SNAPSHOT-src.zip

however they were not installed to the Maven repository, because the
pom says "false"



On 30 November 2016 at 19:04, Gary Gregory  wrote:
> On Wed, Nov 30, 2016 at 1:34 AM, Stian Soiland-Reyes 
> wrote:
>
>> Just a thing I noticed..
>>
>> In https://dist.apache.org/repos/dist/release/commons/commons-
>> parent/commons-parent-41/
>> and before we had a -src.tar.gz and -src.zip
>> (just like any other
>>
>> while your candidate in
>> https://dist.apache.org/repos/dist/dev/commons/commons-parent/42-RC1/
>>  is just the deployed pom file and so can't as easily be "built" or
>> installed.
>>
>> Not a blocker for me personally, but it would be good if we can keep
>> the parent similar to the other components, even if it doesn't have
>> any source code. For instance Debian packages Commons parent.
>>
>
> I looks like we started providing the src zip/gz with version 40 only. Crud!
>
> I'm not sure why the assembly plugin did not kick in.
>
> Can someone take a look?
>
> Thank you,
> Gary
>
>
>>
>> On 30 November 2016 at 09:25, Stian Soiland-Reyes 
>> wrote:
>> > +1
>> >
>> > Checked:
>> >
>> > +1 Signatures, hashes
>> > +1 tag matches repo matches dist
>> > +1 No binaries
>> > +1 Works with beanutils
>> >
>> > I got a bug when using it with Commons RDF for "mvn clean package
>> install",
>> > related to the updated site-plugin:
>> >
>> > [ERROR] Failed to execute goal
>> > org.apache.maven.plugins:maven-site-plugin:3.6:site (default-site) on
>> > project commons-rdf-parent: Execution default-site of goal
>> > org.apache.maven.plugins:maven-site-plugin:3.6:site failed: A required
>> class
>> > was missing while executing
>> > org.apache.maven.plugins:maven-site-plugin:3.6:site:
>> > org/apache/maven/doxia/sink/impl/XhtmlBaseSink
>> >
>> > This was fixed by updating its doxia-module-markdown dependency from 1.6
>> to
>> > 1.7.
>> >
>> > With beanutils I tested the parent with "mvn clean install site" and "mvn
>> > release:prepare".
>> >
>> > On 27 November 2016 at 08:21, Gary Gregory  wrote:
>> >> We have added some enhancements since Commons Parent POM 41 was
>> released,
>> >> so I would like to release Commons Parent POM 42.
>> >>
>> >> Commons Parent POM 42 RC1 is available for review here:
>> >> https://dist.apache.org/repos/dist/dev/commons/commons-parent/42-RC1/
>> >> (svn revision 17171)
>> >>
>> >> The tag is here:
>> >>
>> >>
>> >> http://svn.apache.org/repos/asf/commons/proper/commons-
>> parent/tags/commons-parent-42-RC1/
>> >> (svn revision 1771539)
>> >> N.B. the SVN revision is required because SVN tags are not immutable.
>> >>
>> >> Maven artifacts are here:
>> >>
>> >>
>> >> https://repository.apache.org/content/repositories/
>> orgapachecommons-1221/org/apache/commons/commons-parent/42/
>> >>
>> >> These are the Maven artifacts and their hashes
>> >>
>> >> /org/apache/commons/commons-parent/42/commons-parent-42-site.xml
>> >> (SHA1: a76e03e9059f31abc5e3c22f4e857366e689068f)
>> >> /org/apache/commons/commons-parent/42/commons-parent-42-site.xml.asc
>> >> (SHA1: 16b625891e404d95eb7688a99889dc499148d060)
>> >> /org/apache/commons/commons-parent/42/commons-parent-42.pom
>> >> (SHA1: b95e1096a4cf0d8bcd52740900a474b1e7f87dd1)
>> >> /org/apache/commons/commons-parent/42/commons-parent-42.pom.asc
>> >> (SHA1: 810728ac23f181f0f706ae0132bdb406288f5859)
>> >>
>> >> I built this with:
>> >>
>> >> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
>> >> 2015-11-10T08:41:47-08:00)
>> >> Maven home: E:\Java\apache-maven-3.3.9\bin\..
>> >> Java version: 1.8.0_112, vendor: Oracle Corporation
>> >> Java home: C:\Program Files\Java\jdk1.8.0_112\jre
>> >> Default locale: en_US, platform encoding: Cp1252
>> >> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>> >>
>> >> The site was built with:
>> >>
>> >&g

Re: [VOTE][RC5] Release "Apache Commons RNG" version 1.0

[Stian Soiland-Reyes]

My vote: +1 (binding)

Looking good!


Checked:

+1 commit matches tag (even signed tag, yay!)
+0 commit matches src (git tag is missing
"true" -- why?)
+0 src matches staging repo -sources (hard to check as *-src.tar.gz
was not staged :-( )
+1 bin JARs matches staging repo hashes
+1 zip vs tar.gz
+1 .asc signatures of dist and repo
+1 md5/sha1 hashes (email's hash filenames says .sha1, but match
correctly the zip/tar.gz)
+0 mvn apache-rat:check (exceptions are already excluded for )
+1 no unexpected binaries
+1 mvn clean install
  +1 .. and afterwards in commons-rng-examples
+0 binary vs source (binary adds commons-rng-examples-1.0.jar, built
separately in source)
+1 RELEASE-NOTES
+1 LICENSE, NOTICE
+1 site (minor markdown highlight bug "64 bits" at
http://home.apache.org/~erans/commons-rng-1.0-RC5-site/userguide/rng.html)
+1 javadoc

On 30 November 2016 at 00:08, Gilles  wrote:
> Hi.
>
> This is a [VOTE] for releasing Apache Commons RNG 1.0 (from RC5).
>
> Main changes wrt the preceding vote (RC2, on September 16) are:
>   * Modularization
>   * Non-uniform deviates (in module "commons-rng-sampling")
>
>
> Tag name:
>   RNG_1_0_RC5 (signature can be checked from git using 'git tag -v')
>
> Tag URL:
>
> https://git-wip-us.apache.org/repos/asf?p=commons-rng.git;a=commit;h=f9de6401e981554c3f44936c2272429e290fdbec
>
> Commit ID the tag points at:
>   f9de6401e981554c3f44936c2272429e290fdbec
>
> Site:
>   http://home.apache.org/~erans/commons-rng-1.0-RC5-site
>
> Distribution files:
>   https://dist.apache.org/repos/dist/dev/commons/rng/
>
> Distribution files hashes (SHA1):
>   de2a54518a0ef10ba5a2be1c3b060a441f4466e2  commons-rng-1.0-bin.tar.gz.sha1
>   cfcfde1f65dec9c30be1273ff2237d551eb87933  commons-rng-1.0-bin.zip.sha1
>   6d529de9418314066727a7d5ada88dd87dc0163d  commons-rng-1.0-src.tar.gz.sha1
>   561dd3e5ebf53d60e883d5c04e543f58374c45b6  commons-rng-1.0-src.zip.sha1
>
> KEYS file to check signatures:
>   http://www.apache.org/dist/commons/KEYS
>
> Maven artifacts:
>   https://repository.apache.org/content/repositories/orgapachecommons-1225/
>
>
> [ ] +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 close in 72 hours, at 2016-12-03T00:00:00Z (this is UTC
> time).
> --
>
>
> Thanks,
> Gilles
>
>
> -----
> 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: [CANCE][VOTE][LAZY] Release Commons Parent POM 42 based on RC1

[Stian Soiland-Reyes]

I would prefer the source distribution to also be deployed in Maven
Central, as most Maven projects now do through the Apache super pom (but
then called -source-release). This means the Maven distribution for a
particular version should be completely reproducible without having to hunt
around the archive.apache.org (which is discouraged for direct downloads)
and have slight variations in paths and filenames.


We have not heard complaints from Sonatype to stop including the source
distros - that would affect all Maven-using ASF project - their presence
cause no harm.


When reviewing an RC a -src.tar.gz in the repo also makes it very easy to
check that the deployed version matches src dist (barring deliberate fraud)
- for the rng RC I had to instead check each of the -sources.jar (which are
not guaranteed to be compilable).


Another matter is the -bin releases (they are just aggregates of jars
already deployed separately) and making sure there are not like .asc.asc
extras. In a multi-module build only the top level distros should be made -
most ASF projects manage this in different ways.

On 2 Dec 2016 2:07 am, "Charles Honton"  wrote:

> Why do we expect the src zip to be present in the maven repository?  No
> other commons project pushes the src zip/gz to maven central.
>
> If we want to supply src zip/gz as a convenience, why wouldn’t it be at
> http://commons.apache.org/proper/ <http://commons.apache.org/proper/> as
> all other components are?
>
> thanks,
> chas
>
> > On Dec 1, 2016, at 9:15 AM, Gary Gregory  wrote:
> >
> > [editing subject]
> >
> > On Thu, Dec 1, 2016 at 9:14 AM, Gary Gregory 
> wrote:
> >
> >> I am canceling this VOTE to deal with the missing src files.
> >>
> >> Gary
> >>
> >> On Thu, Dec 1, 2016 at 3:26 AM, Stian Soiland-Reyes 
> >> wrote:
> >>
> >>> I did "mvn clean install -Prelease" from SVN and got in target/:
> >>>
> >>> commons-parent-42-SNAPSHOT-src.tar.gz
> >>> commons-parent-42-SNAPSHOT-src.zip
> >>>
> >>> however they were not installed to the Maven repository, because the
> >>> pom says "false"
> >>>
> >>>
> >>>
> >>> On 30 November 2016 at 19:04, Gary Gregory 
> >>> wrote:
> >>>> On Wed, Nov 30, 2016 at 1:34 AM, Stian Soiland-Reyes <
> st...@apache.org>
> >>>> wrote:
> >>>>
> >>>>> Just a thing I noticed..
> >>>>>
> >>>>> In https://dist.apache.org/repos/dist/release/commons/commons-
> >>>>> parent/commons-parent-41/
> >>>>> and before we had a -src.tar.gz and -src.zip
> >>>>> (just like any other
> >>>>>
> >>>>> while your candidate in
> >>>>> https://dist.apache.org/repos/dist/dev/commons/commons-
> parent/42-RC1/
> >>>>> is just the deployed pom file and so can't as easily be "built" or
> >>>>> installed.
> >>>>>
> >>>>> Not a blocker for me personally, but it would be good if we can keep
> >>>>> the parent similar to the other components, even if it doesn't have
> >>>>> any source code. For instance Debian packages Commons parent.
> >>>>>
> >>>>
> >>>> I looks like we started providing the src zip/gz with version 40 only.
> >>> Crud!
> >>>>
> >>>> I'm not sure why the assembly plugin did not kick in.
> >>>>
> >>>> Can someone take a look?
> >>>>
> >>>> Thank you,
> >>>> Gary
> >>>>
> >>>>
> >>>>>
> >>>>> On 30 November 2016 at 09:25, Stian Soiland-Reyes 
> >>>>> wrote:
> >>>>>> +1
> >>>>>>
> >>>>>> Checked:
> >>>>>>
> >>>>>> +1 Signatures, hashes
> >>>>>> +1 tag matches repo matches dist
> >>>>>> +1 No binaries
> >>>>>> +1 Works with beanutils
> >>>>>>
> >>>>>> I got a bug when using it with Commons RDF for "mvn clean package
> >>>>> install",
> >>>>>> related to the updated site-plugin:
> >>>>>>
> >>>>>> [ERROR] Failed to execute goal
> >>>>>> org.apache.maven.plugins:maven-site-plugin:3.6:site (default-site)
> >>> on
> >&g

Re: [CANCE][VOTE][LAZY] Release Commons Parent POM 42 based on RC1

[Stian Soiland-Reyes]

They won't be signed or hashed if the files are not "attached" because then
they are not officially output artifacts of the build, and won't be
deployed.

You can run hashing and signing plugins manually, but then the ordering of
the phases matter; to avoid a race condition where the assembly plugin is
run after the signing or hashing.

Here's how we tried that in earlier release of Commons RDF:

https://github.com/apache/incubator-commonsrdf/blob/0.2.0-incubating/pom.xml#L446


note that this was buggy in other ways, e.g. it deployed .sha1.md5 etc and
I think was meant more as a convenience for the RM than for deployment. If
done on a detached file that should avoid double signatures. (My view is
that the source distros SHOULD be deployed - but of course only for the
main distro, not per module.

Maven assembly plugin etc can be hard.. should we ask on users@maven ..?

On 3 Dec 2016 4:41 pm, "Gary Gregory"  wrote:

So, when I run:

mvn clean deploy -Duser.name=ggregory -Prelease -Ptest-deploy

The zip and gz files are created but not signed or hashed.

Thoughts?

Gary


On Sat, Dec 3, 2016 at 2:53 AM, Stian Soiland-Reyes 
wrote:

> I would prefer the source distribution to also be deployed in Maven
> Central, as most Maven projects now do through the Apache super pom (but
> then called -source-release). This means the Maven distribution for a
> particular version should be completely reproducible without having to
hunt
> around the archive.apache.org (which is discouraged for direct downloads)
> and have slight variations in paths and filenames.
>
>
> We have not heard complaints from Sonatype to stop including the source
> distros - that would affect all Maven-using ASF project - their presence
> cause no harm.
>
>
> When reviewing an RC a -src.tar.gz in the repo also makes it very easy to
> check that the deployed version matches src dist (barring deliberate
fraud)
> - for the rng RC I had to instead check each of the -sources.jar (which
are
> not guaranteed to be compilable).
>
>
> Another matter is the -bin releases (they are just aggregates of jars
> already deployed separately) and making sure there are not like .asc.asc
> extras. In a multi-module build only the top level distros should be made
-
> most ASF projects manage this in different ways.
>
> On 2 Dec 2016 2:07 am, "Charles Honton"  wrote:
>
> > Why do we expect the src zip to be present in the maven repository?  No
> > other commons project pushes the src zip/gz to maven central.
> >
> > If we want to supply src zip/gz as a convenience, why wouldn’t it be at
> > http://commons.apache.org/proper/ <http://commons.apache.org/proper/> as
> > all other components are?
> >
> > thanks,
> > chas
> >
> > > On Dec 1, 2016, at 9:15 AM, Gary Gregory 
> wrote:
> > >
> > > [editing subject]
> > >
> > > On Thu, Dec 1, 2016 at 9:14 AM, Gary Gregory 
> > wrote:
> > >
> > >> I am canceling this VOTE to deal with the missing src files.
> > >>
> > >> Gary
> > >>
> > >> On Thu, Dec 1, 2016 at 3:26 AM, Stian Soiland-Reyes  >
> > >> wrote:
> > >>
> > >>> I did "mvn clean install -Prelease" from SVN and got in target/:
> > >>>
> > >>> commons-parent-42-SNAPSHOT-src.tar.gz
> > >>> commons-parent-42-SNAPSHOT-src.zip
> > >>>
> > >>> however they were not installed to the Maven repository, because the
> > >>> pom says "false"
> > >>>
> > >>>
> > >>>
> > >>> On 30 November 2016 at 19:04, Gary Gregory 
> > >>> wrote:
> > >>>> On Wed, Nov 30, 2016 at 1:34 AM, Stian Soiland-Reyes <
> > st...@apache.org>
> > >>>> wrote:
> > >>>>
> > >>>>> Just a thing I noticed..
> > >>>>>
> > >>>>> In https://dist.apache.org/repos/dist/release/commons/commons-
> > >>>>> parent/commons-parent-41/
> > >>>>> and before we had a -src.tar.gz and -src.zip
> > >>>>> (just like any other
> > >>>>>
> > >>>>> while your candidate in
> > >>>>> https://dist.apache.org/repos/dist/dev/commons/commons-
> > parent/42-RC1/
> > >>>>> is just the deployed pom file and so can't as easily be "built" or
> > >>>>> installed.
> > >>>>>
> > >>>>> Not a blocker for me personally, but it would be good if we can
> 

Re: Commons release policy

[Stian Soiland-Reyes]

ry 
>> wrote:
>> >>
>> >> > On Dec 3, 2016 9:34 AM, "Charles Honton"  wrote:
>> >> > >
>> >> > > To follow up the thread on releasing parent 42 and exactly what
>> needs
>> >> to
>> >> > signed, etc.  I’ve researched asf release policy.  Here’s the gist:
>> >> > >
>> >> > > 1. Every ASF release must contain a source package, which must be
>> >> > sufficient for a user to build and test the release provided they have
>> >> > access to the appropriate platform and tools. <
>> >> > http://www.apache.org/dev/release#what-must-every-release-contain>
>> >> > >
>> >> > > 2. A release isn't 'released' until the contents are in the
>> project's
>> >> > distribution directory, which is a subdirectory of
>> www.apache.org/dist/
>> >> <
>> >> > http://www.apache.org/dev/release#where-do-releases-go>.
>> >> > >
>> >> > > 3. Every artifact distributed to the public through Apache channels
>> >> MUST
>> >> > be accompanied by one file containing an OpenPGP compatible ASCII
>> armored
>> >> > detached signature and another file containing an MD5 checksum. <
>> >> > https://www.apache.org/dev/release-distribution.html#sigs-and-sums>
>> >> > >
>> >> > > What do we consider the source package for our releases?
>> >> > > Are the xxx-sources.jar,  xxx-test-sources.jar, and pom sufficient
>> to
>> >> > build and test the release?
>> >> >
>> >> > Nope. A sources jar is a convenience for IDEs, it usually does not
>> >> contain
>> >> > build scripts and such. I am AFK so I am hoping someone can provide an
>> >> > example.
>> >> >
>> >> > > Is the zip/gz just a convenience and is it still useful/required?
>> >> >
>> >> > That should contain almost everything that is in the repo except for
>> >> things
>> >> > like old files like proposal.html.
>> >> >
>> >> > > Or is it the reverse, the zip/gz is the release and the jars are the
>> >> > convenience distributions?
>> >> >
>> >> > Yep. The release are the zip/gz sources. All binaries are
>> conveniences.
>> >> > Granted that without a Maven Central jar release, a component is not
>> easy
>> >> > to reuse.
>> >> >
>> >> > Gary
>> >> >
>> >> > >
>> >> > > regards,
>> >> > > chas
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Matt Sicker 
>> >>
>> >
>> >
>> >
>> > --
>> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> > Java Persistence with Hibernate, Second Edition
>> > <https://www.amazon.com/gp/product/1617290459/ref=as_li_
>> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
>> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>> >
>> > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
>> 1617290459>
>> > JUnit in Action, Second Edition
>> > <https://www.amazon.com/gp/product/1935182021/ref=as_li_
>> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
>> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22
>> >
>> >
>> > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
>> 1935182021>
>> > Spring Batch in Action
>> > <https://www.amazon.com/gp/product/1935182951/ref=as_li_
>> 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>
>> > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
>> 1935182951>
>> > Blog: http://garygregory.wordpress.com
>> > Home: http://garygregory.com/
>> > Tweet! http://twitter.com/GaryGregory
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> Matt Sicker 



-- 
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] Why is the component's web site part of the release vote?

[Stian Soiland-Reyes]

That sounds like not a problem at all as RAT passes on the RC.
Just regenerate the site after releasing. (We have to verify download page
manually anyway).

(Perhaps building the site from the RC's tar-ball rather than the "dirty"
mvn tree post release is safer)


I think it would only block a release vote if the site showed something
wrong that also affects the code or jars; e.g. a very broken javadoc or an
actual RAT violation. Anything else can be fixed post release (but
comitters to master of course :-)

On 8 Dec 2016 4:21 pm, "Gilles"  wrote:

> On Thu, 8 Dec 2016 12:33:43 +0100, Jochen Wiedmann wrote:
>
>> On Thu, Dec 8, 2016 at 9:33 AM, Gilles 
>> wrote:
>>
>> I've just noticed a small problem in the (staged) web site
>>> submitted for the release of Commons RNG v1.0:
>>>   http://home.apache.org/~erans/commons-rng-1.0-RC6-site/rat-report.html
>>>
>>> Since this must be fixed in the regenerated site will
>>> not reflect the released version number, why do we
>>> actually have to vote on the site?
>>>
>>
>> In my opinion: We do not vote on the site. Which is why deficiencies
>> in the proposed site aren't blocking a release.
>>
>> That being said:
>>
>> a) The proposed site may be helpful for the release vote, if for no
>> other reasons than the
>>  RAT report.
>>
>
> The problem, in this particular case is that the RAT output published
> in the RC version of the site reports violations on files not part of
> the release.
>
> Gilles
>
>
>> b) The proposal leads to people verifying the site, which they usually
>> wouldn't do.
>>
>>
>> Jochen
>>
>>
>>
>> http://www.keystonedevelopment.co.uk/wp-content/uploads/
>> 2014/10/evolution-of-the-wheel-300x85.jpg
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE][RC6] Release Commons RNG 1.0 (reminder)

[Stian Soiland-Reyes]

On 11 December 2016 at 06:11, Gilles  wrote:
>> This is a [VOTE] for releasing Apache Commons RNG 1.0 (from RC6).
>> Tag name:
>>   RNG_1_0_RC6 (signature can be checked from git using 'git tag -v')
>>
>> Tag URL:
>>
>>
>>
>> https://git-wip-us.apache.org/repos/asf?p=commons-rng.git;a=commit;h=4581a4520315657a4219b37c81f5db80e4a4e43c
>>
>> Commit ID the tag points at:
>>   4581a4520315657a4219b37c81f5db80e4a4e43c
>>
>> Site:
>>   http://home.apache.org/~erans/commons-rng-1.0-RC6-site
>>
>> Distribution files (committed at revision 17284):
>>   https://dist.apache.org/repos/dist/dev/commons/rng/
>>
>> Distribution files hashes (SHA1):
>>   c5e70a523160ed848194eeba0efa2b14d23c7a61 commons-rng-1.0-bin.tar.gz.sha1
>>   66d7701afc90aafa4c4b6e033b8df6cd84365161 commons-rng-1.0-bin.zip.sha1
>>   ef56543c8882a0e4771de83ecf8b3be190f122cf commons-rng-1.0-src.tar.gz.sha1
>>   3dc56b0793d8bbd703a4efa68547eb58f6fb5b35 commons-rng-1.0-src.zip.sha1
>>
>> KEYS file to check signatures:
>>   http://www.apache.org/dist/commons/KEYS

NOTE:
URL to KEYS should always be with https, not http

>> Maven artifacts:
>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1229/
>>
>> 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 2016-12-10T00:00:00Z
>> (this is UTC time).
>> --
>
>
> Ping?
>
> Unless I'm mistaken, after 100 hours have elapsed, there are only
> 2 votes for RC6.

I wouldn't interpret that in any direction.. probably just busy days
in December. I just finished putting a dead tree in my living room, so
time for some release candidate testing!



My vote:
+1 (binding)


Checked:

+1 commit matches tag  (signed yay)
+1 commit matches src
+1 src matches staging repo -sources
+1 bin JARs matches staging repo hashes
+1 zip vs tar.gz
+1 .asc signatures of dist (+1 for sha256 digest)
+1 .asc signatures of repo
+1 md5/sha1 hashes
+0 mvn apache-rat:check (failed on checkstyle/suppressions.xml - tiny,
OK for now, fixed in git)
+1 no unexpected binaries
+1 mvn clean install
  +1 .. and afterwards in commons-rng-examples
+0 binary vs source (bin distro includes -sources.jar and -javadoc.jar
which are not built by default from src distro)
+1 RELEASE-NOTES
+1 LICENSE, NOTICE
+1 META-INF/LICENSE and NOTICE in repo JARs (which include
MersenneTwister BSD license)
+1 site
+1 javadoc


Great work! Thanks for preparing this release candidate!


As this is RC6 I would have preferred that reflected somewhat in the
dist folder-name under vote (e.g. /dist/dev/commons/rng-1.0-RC6) , but
you included properly the SVN revision number and sha1 hashes, so no
doubt in this particular case.

The amended apache-rat config was only under  so it didn't
pick up RNG-specific excludes when running mvn apache-rat:check -- I
added it also to  in git and simplified using .  This does not affect this vote.



Why isn't commons-rng-examples part of the normal build when it is
deployed to Maven and part of the bin distro; is it because because it
needs JDK7? Java 7 no longer counts as "special requirement" -- in
fact I would have preferred a first 1.0 release to not commit us to
future Java 6 support.. but IMHO we're OK to go for Java 7 or even
Java 8 in a future 1.1 release and no longer need to keep
commons-rng-examples special.



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_111, 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-53-generic", arch: "amd64", family: "unix"+

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

Re: [REPORT][DRAFT] Apache Commons Board Report for December 2016

[Stian Soiland-Reyes]

We had waited for Infra to do the rename/move of the commons rdf git
repository; that was just completed two days ago.


I did not republish site yet from src as half the pages would have many
broken links to the new repo; in src/site it is already updated. Sergio was
looking at ways to ensure the submodule site gets published, but we can
remove the links to those from the menu.

The old incubator website now redirects to the commons URL so I guess we
can add it to the main site listing already. It's ticked off from the
Incubator side.


I have not moved the downloads in dist/, I guess we will have to leave the
old releases under dist/incubator as they have not been voted on by Commons
PMC?

Next is also to close the old mail list and set up an autoreply.

I'm afraid my bandwidth has been a bit constrained over the last two weeks
with various project meetings and business trips, so thanks for helping
out, Sergio!

I should be able to help more in later part of December and we can start
discussing what needs doing towards a Commonsrdf release of RDF. Perhaps an
incremental 0.4.0 first before we lock down 1.0.0.

On 15 Dec 2016 11:36 am, "Andy Seaborne"  wrote:

>
>
> On 15/12/16 11:04, Gary Gregory wrote:
>
>> On Thu, Dec 15, 2016 at 2:40 AM, Andy Seaborne  wrote:
>>
>>
>>>
>>> On 14/12/16 23:06, Gary Gregory wrote:
>>>
>>> Hi All: I am requesting your feedback before I send this off.


>>>
>>> ## Activity:
>>>
  - The project is active with 6 releases this reporting period. We
 released
  one new component Commons RNG 1.0. Commons Math still feels in
 semi-limbo
 and
  now depends on Commons RNG in our repository. Commons RDF is making its
  way out of the incubator into Commons.

  - The Commons community has decided to bring forth and maintain a new
  component, Commons RNG, out of the larger Commons Math code base, which
 is
  has seen no activity in the last quarter. The future of Commons Math is
  still uncertain and being discussed from time to time. There are
 several
  proposals for fostering new communities in place of the dwindling
  Commons Math one, but that those are in limbo because no consensus
  has been reached yet.


>>> Is it worth adding:
>>>
>>>   - A new component, Commons RDF, has been added.
>>>   This graduated through the incubator.
>>>
>>
>>
>> Metata are missing as it is not showing up on:
>>
>> - reporter.apache.org
>> - https://commons.apache.org/
>>
>> and
>>
>> https://commons.apache.org/proper/commons-rdf/
>>
>> shows Last Published: 22 November 2016|Version: 0.4.0-incubating-SNAPSHOT
>>
>> So where is it?
>>
>
> Formally, it's accepted into Apache Commons (isn't it?) which is the key
> point for the board. The process is catching up.
>
> Andy
>
>
>> Gary
>>
>>
>>>
>>>
>>> ## Health report:
  - Most components in Commons are mature, but are still actively
  maintained (6 releases). The dev list is active. JIRA is active. Speed
 of
  responses to users is reasonable in most cases. We have 1 new PMC
 member,
  and Commons is still open to any Apache Committer.

 Unedited reporter data follows.

 ## PMC changes:

  - Currently 36 PMC members.
  - Bruno P. Kinoshita was added to the PMC on Wed Oct 26 2016

 ## Committer base changes:

  - Currently 142 committers.
  - No new committers added in the last 3 months
  - Last committer addition was Eric Barnhill at Tue Sep 06 2016

 ## Releases:

  - BEANUTILS-1.9.3 was released on Sat Sep 24 2016
  - BUILDPLUGIN 1.7 was released on Mon Nov 21 2016
  - JCS-2.0-beta-2 was released on Mon Oct 31 2016
  - LANG-3.5 was released on Thu Oct 13 2016
  - RNG-1.0 was released on Sun Dec 11 2016
  - WEAVER-1.3 was released on Mon Oct 17 2016

 ## Mailing list activity:

  - TODO Please explain what the following statistics mean
for the project. If there is nothing significant in the figures, omit
 this
section.

  - dev@commons.apache.org:
 - 671 subscribers (down -8 in the last 3 months):
 - 1381 emails sent to list (1607 in previous quarter)

  - iss...@commons.apache.org:
 - 300 subscribers (down -2 in the last 3 months):
 - 1743 emails sent to list (1646 in previous quarter)

  - notificati...@commons.apache.org:
 - 12 subscribers (up 0 in the last 3 months):
 - 201 emails sent to list (247 in previous quarter)

  - u...@commons.apache.org:
 - 1231 subscribers (down -5 in the last 3 months):
 - 130 emails sent to list (83 in previous quarter)


 ## JIRA activity:

  - 177 JIRA tickets created in the last 3 months
  - 184 JIRA tickets closed/resolved in the last 3 months

  Gary Gregory, Your Apache Commons PMC Chair.


 --

Re: [rdf] roles after graduation

[Stian Soiland-Reyes]

I agree on not expanding too much on the roles and would favour removing
PPMC roles except for those who are listed only as emeritus.

On 17 Jan 2017 10:30 am, "Jochen Wiedmann" 
wrote:

> Hi, Sergio,
>
> On Tue, Jan 17, 2017 at 8:31 AM, Sergio Fernández 
> wrote:
>
> > adjusting Stian's role [1} I realized we never had the discussion about
> the
> > roles of people on the component after graduation: who wants to keep in
> the
> > project, PPMC members need to be voted for Commons PMC, etc.
> >
> > Nothing urgent, but eventually needs to be discussed.
>
> given Commons history, and my personal experience, I'd strongly
> discourage to fix any particular "roles" for an open source project. A
> project works best, if anyone does, what she or he feels needs to be
> done. (Assuming she, or he, has the necessary privileges, of course.)
>
> From reading through your POM, the component has three current
> (hopefully active :-) PMC members. That's more, than most others have,
> thus should be sufficient.
>
> Jochen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: StringUtils.isEmpty() family of methods on Objects

[Stian Soiland-Reyes]

Agree with Benedikt here, if it's only the .toString() that is important,
then "string" should appear in the method name; otherwise we need to do
Commons Collections style handling of anything that can be empty or not.

To support null (which isn't really "empty" but missing), perhaps just have
the inverse method

hasNonEmptyString() ?

Then it would be false both for null and "", true for anything else.

On 28 Jan 2017 9:13 am, "Benedikt Ritter"  wrote:

>
> > Am 28.01.2017 um 02:53 schrieb Gary Gregory :
> >
> > The simplest examples I have on hand are instances of Path and URI which
> > can be built with an empty string. I want to know if these are "empty".
> For
> > the app I am now on for example, a Path or null and "" should be treated
> > the same. Same for a URI.
>
> I don’t think it is a good idea to define emptiness based on the return
> value of Object.toString(). Consider the following:
>
> isEmpty(null) -> true
> isEmpty(„“) -> true
> isEmpty(new URI(„“)) -> true
>
> But:
>
> isEmpty(Collections.emptyList()) -> false
> isEmpty(new int[0]) -> false
>
> This is because toString() has nothing to do with emptiness. For this
> reason I think it would be better to have explicitly typed method overloads
> for the use cases you’re thinking about:
>
> boolean isEmpty(Path)
> boolean isEmpty(URI)
>
> I’m not sure whether this belong to [lang]. The first looks like it
> belongs to [io] while the second would better fit into [net]…
>
> Benedikt
>
> >
> > Gary
> >
> > On Fri, Jan 27, 2017 at 5:37 PM, Matt Sicker  wrote:
> >
> >> That's an interesting use case, though I've never come across a
> toString()
> >> implementation that would be affected. Can you go into more detail?
> >>
> >> On 27 January 2017 at 16:04, Gary Gregory 
> wrote:
> >>
> >>> _Like_ that except that our Log4j version does not do the case I want:
> >>> object.toString().
> >>>
> >>> Gary
> >>>
> >>> On Fri, Jan 27, 2017 at 1:58 PM, Matt Sicker  wrote:
> >>>
>  Something like this?
> 
>  https://github.com/apache/logging-log4j2/blob/master/
>  log4j-core/src/main/java/org/apache/logging/log4j/core/
>  util/Assert.java#L43
> 
>  On 27 January 2017 at 15:54, Gary Gregory 
> >>> wrote:
> 
> > Hi All,
> >
> > There are certain kinds of objects, _descriptor_ kind of objects that
>  would
> > benefit from isEmpty semantics. These kind of objects can describe
>  complex
> > command line arguments and other kind of configuration objects.
> >
> > I'd like to add with this pseudo code:
> >
> > boolean isEmpty(Object) {
> >  return object == null ? true : isEmpty(object.toString());
> > }
> >
> > Thoughts?
> >
> > Same idea of isBlank(), isNotEmpty() and so on.
> >
> > 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=
> >> cadb800f39946ec62ea2b1af9fe6a2
> >>> b8>
> >
> >  >> garygregory-20&l=am2&o=1&a=
> > 1617290459>
> > JUnit in Action, Second Edition
> >  > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> > linkCode=as2&tag=garygregory-20&linkId=
> >> 31ecd1f6b6d1eaf8886ac902a24de4
>  18%22
> >>
> >
> >  >> garygregory-20&l=am2&o=1&a=
> > 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>
> >  >> garygregory-20&l=am2&o=1&a=
> > 1935182951>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
> >
> 
> 
> 
>  --
>  Matt Sicker 
> 
> >>>
> >>>
> >>>
> >>> --
> >>> 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=cadb800f39946ec62ea2b1af9fe6a2
> b8>
> >>>
> >>>  >>> 1617290459>
> >>> JUnit in Action, Second Edition
> >>>  >>> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> >>> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de4
> >> 18%22
> 
> >>>
> >>> 

Re: RDF commons testing

[Stian Soiland-Reyes]

On Mon, 30 Jan 2017 09:08:27 +1100, Peter Ansell  wrote:
> Hi Claude,
> Abstract test classes are working well for Commons RDF so far. Others
> may benefit from your solution, so feel free to suggest the approach
> to others who may be interested in exploring it.

I would not dismiss Claude's suggestion out of hand. Apache Commons is
for anyone who wants to participate! :-)

Claude  - if you would like to have a go in a branch at what Commons RDF
tests look like using contract testing, then feel free!

>> https://www.linkedin.com/pulse/contract-testing-why-abstract-tests-enough-claude-warren-jr

I liked this blog article which explains the problem. We in a way
already have this problem twice in Commons RDF tests because we have the
Triple/Quad duality (TripleLike) and Graph/Dataset duality (GraphLike)
as well as the multiple implementations of the commons-rdf-api
interfaces.

So you will notice some of those tests have considerable duplication
with subtle differences, e.g. along the lines of:


graph.add(triple);
assertTrue(graph.contains(triple)
assertTrue(graph.contains(triple.getSubject(),
triple.getPredicate(), triple.getObject());

vs

dataset.add(quad);
assertTrue(dataset.contains(quad));
assertTrue(dataset.contains(quad.getGraphName(),
  quad.getSubject(), quad.getPredicate(), quad.getObject());

This could in theory be harmonized so that there's a single abstract
test class with an abstract method to make the triple/quad - and then
extensions for Triple and Quad that adds the last decomposition
assertion.

But as we already use abstract classes to run the tests per RDF
implementation, and so I thought it would get messy to try to reorganize
it.


Another thing is that now the tests are munged together
into mainly AbstractRDFTest (which must create an RDF factory instance,
that then can create the other things) - otherwise you will have to
make many SomethingImplTest in each module (and easily forget to
specialize one of the tests in one of the modules)

With your approach, would you still have to make a such specialization,
or is that automatic?


BTW - in your approach, would it work to run the tests out of the box 
from an IDE like Eclipse? I think that is quite important so Commons RDF
can be maintainable by many people in Apache Commons.




-- 
Stian Soiland-Reyes
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 commons testing

[Stian Soiland-Reyes]

On Mon, 30 Jan 2017 10:20:46 +, Stian Soiland-Reyes  
wrote:
> BTW - in your approach, would it work to run the tests out of the box 
> from an IDE like Eclipse? I think that is quite important so Commons RDF
> can be maintainable by many people in Apache Commons.

They did run out of the box in Eclipse thanks to the @TestRunner, and it
looks quite nice, separated out per interface contract tested:

https://raw.githubusercontent.com/stain/junit-contracts/patch-1/docs/junit-contracts.png


I was confused by your examples still using test class hierarchy like
"BarTest extends FooTest" which then turns out to be not needed at all.
Also I don't think there's generally a need to use the confusing
indirection of IProducer but rather give the instance to be tested
directly.

I was confused with @Contract.Inject being the annotation both for
the property to be set and the factory method to generate the
implementaton.


I added a suggestion to your README to show how junit-contracts can be
used with multiple interfaces and multiple implementations, using
java.util.Set as an example which I think many on this list will 
be familiar with.

https://github.com/stain/junit-contracts/tree/patch-1#motivation

I also think the ability to have different @Before is a strong
argument - so this could be relevant in multiple project with
several interface implementaton, but also for Commons RDF.


-- 
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: [Text] Consider making the project "multimodule"

[Stian Soiland-Reyes]

Modules of Text would make sense if we get larger differences of
dependencies; if it is just different functionality, subpackages within a
single module would be better.

On 30 Jan 2017 5:53 pm, "Emmanuel Bourg"  wrote:

> Le 30/01/2017 à 15:16, Rob Tompkins a écrit :
>
> > I lean towards going with a single module out of simplicity
>
> +1
>
> Emmanuel Bourg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Immutable builder pattern for parsers?

[Stian Soiland-Reyes]

Peter Ansell raised a valid question about why in Commons RDF I made the 
RDFParser interface as an immutable factory-like builder pattern.

https://commons.apache.org/proper/commons-rdf/apidocs/org/apache/commons/rdf/experimental/RDFParser.html


Here is how it can be used today:

 RDF rdf = new JenaRDF();
 Graph g1 = rdf.createGraph();
 Future future = new JenaRDFParser()
 .source(Paths.get("/tmp/graph.ttl"))
 .contentType(RDFSyntax.TURTLE)
 .target(g1).parse();
 future.get(30, TimeUnit.Seconds); // block
 

You may notice it is not a factory as-such, as you only get a Future
of the parser result, rather than the actual "parser". Also it is
currently an interface, with multiple implementations (one per RDF
implementation).



Although the javadoc only suggests for it to be immutable and
threadsafe, the abstract class AbstractRDFParser
https://commons.apache.org/proper/commons-rdf/apidocs/org/apache/commons/rdf/simple/experimental/AbstractRDFParser.html
https://github.com/apache/commons-rdf/blob/master/simple/src/main/java/org/apache/commons/rdf/simple/experimental/AbstractRDFParser.java
is both, and thus every "option setter" method therefore return a cloned
copy of the factory with the mutated fields set there. This simply uses 
.clone() at the moment.

This abstract class and immutability pattern is used by each of the
three RDF implementations of the interface.


This means it's safe to parse many files like this:

 JenaRDFParser parser = new JenaRDFParser()
 .contentType(RDFSyntax.TURTLE)
 .target(g1);
  
 // Parse multiple files in parallell
 Future future1 = parser.source(Paths.get("/tmp/graph1.ttl")).parse();
 Future future2 = parser.source(Paths.get("/tmp/graph2.ttl")).parse();

 // Wait for both to finish
 future1.get(30, TimeUnit.Seconds); 
 future2.get(30, TimeUnit.Seconds);


Above the second call to parser.source(..) is not a problem (even if
it happens in another thread) as both .source() calls return separate
cloned JenaRDFParser instances and don't mutate the "parser" instance.


Now a valid critique of such a pattern is that it's wasteful to make
clones that are immediately thrown away, for instance the above
future1/future2 example would cause 7 instantiations of JenaRDFParser()
(.parse() does some finalization in a final clone).  

I have not done any benchmarking, but envision that as parsing RDF files
generally creates many thousands of RDFTerm instances, a couple of
extra parser instantiations shouldn't make a big dent in the bill.


The typical builder pattern is rather to return "this" and mutate fields
directly. This is obviously not thread-safe but generally achives the
same. Multiple threads would however instead have to create a brand new
parser from start and set all the options themselves.  (Or they could a
similar .clone() method from a carefully locked down "proto" instance
that everyone has to be careful not to call any mutating methods on)


Now multiple threads is now very common because of Java 8 streams, and
for instance it would not be unthinkable that a parallelStream() is
mapped as a .source() or .target() on such a parser builder. The Futures
fit somewhat into this picture as well.   I think this would get
complicated with having to set everything again rather than just pass
"parser::source" as a method reference.




As this was just thrown together as an experiment (and we've not yet
tried writing the corresponding RDFWriter interface), I think we could
revisit how to do this pattern, hopefully drawing on the wider
experience of the Apache Commons developers on this list.



Roughly here are my requirements:

* Ability to set various options (e.g. path of file to parse, format,
  destination) in any order
* Avoid mega-constructors/multi-arg methods 
* Some options take multiple types, e.g a source can be given as a Path,
  InputStream or IRI (URL) -- but would override each other

Nice to have:

* Reusable (e.g. set options that are common, but modify
  source() to parse multiple files)
* Thread-safe (e.g. immediate reuse of builder before a parsing session
  has started or finished) 
* Easy to serialize / keep around (should not keep references to big
  objects in memory uneccessarily)
* Parsing in the background, e.g. return Future. (implementation manages
  threads/queues as it pleases)

Unclear:

* How to select between the multiple RDFParser instances? 
  I was thinking the RDF interface could have a .makeParser() method, 
  but not all parsers can take all formats, so possibly some kind of 
  registry or "what can you handle" mechanism might be needed.


How do you think we should proceed? Mutable or immutable? How should the
settings be kept? Fields, map, or what?  Does it make sense with an
interface, abstract class (keeps settings) and implementations
(processess settings), or should we 

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: 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