Re: Review the API of a new component of the "Commons" project before release 1.0.

2016-11-30 Thread Gilles 

Hi.

I'm very sorry for the late reply; somehow your mail got buried
in my mailbox.

On Mon, 31 Oct 2016 16:14:46 +0330, Navid Veradi wrote:

Hello
I'm a newcomer to ASF and wanted to start contributing on projects. 
As I
was browsing the "Help Wanted" section, I saw your add for "Review 
the API
of a new component of the "Commons" project before release 1.0." and 
I want

to help.

I'm quite new to open source development and java but I'm not new to
development. I have 3+ years of work experience in Php, Swift and 
Python. I
know my way around java though I'm not as thorough in it as the 
others I

mentioned.
I can help with any task like documentation, writing unit tests or
development but will surely need some help to get a hang on the 
project.

Let me know if I could be of any help.


Surely, you could, in one way or another.

The first step, would probably be to browse the web site and/or
the source repository of "Commons RNG":
  http://commons.apache.org/proper/commons-rng/

Note that there is an ongoing vote for having an official first
release of the new component:
  http://markmail.org/message/r24rz5ldvqaudyuh

You are welcome to give your opinion:
  http://apache.org/foundation/voting.html


Best regards,
Gilles



Regards
Navid Veradi



-
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

2016-11-30 Thread 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: [VOTE][LAZY] Release Commons Parent POM 42 based on RC1

2016-11-30 Thread Gary Gregory 
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:
> >>
> >> 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 release candidate and vote.
> >>
> >> This lazy vote will close no sooner that 72 hours from now, i.e.
> sometime
> >> after

[GitHub] commons-fileupload issue #5: Update DiskFileItem.java: Avoiding NPE when not...

2016-11-30 Thread OleHornischer 
Github user OleHornischer commented on the issue:

https://github.com/apache/commons-fileupload/pull/5
  
Hi @garydgregory,
yes, that potential NullPointerException I also addressed in my fix, as 
well as others. 
I updated the sources now to handle exceptions and fixed a few compile 
errors. The test now includes a test for all methods that have been fixed.

Ole


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: [RDF] Graduating Commons RDF to Commons PMC

2016-11-30 Thread Andy Seaborne 



On 30/11/16 11:03, Sergio Fernández wrote:

On Wed, Nov 30, 2016 at 11:21 AM, Andy Seaborne  wrote:


There are other RDF related projects in ASF. That's a confusing choice of
key name.



I agree. But then, how do we accommodate to the current Apache Commons
naming in Jira? Feedback would be more than welcomed.


I read your initial message and this remark as saying it is a done deal. 
 There is a raised the JIRA that represents community agreement.


One rules should not force the choice.  Yes, one factor is that there is 
value in systematic naming but if that leads to disadvantages, it should 
be balanced.


Leave it as COMMONSRDF for now so there is only one infra task.

It's COMMONSSITE (SITE is in use)

Andy




On 30/11/16 07:33, Sergio Fernández wrote:


Well, that's a question I also had. So far we have been using COMMONSRDF
as
Jira key. All the current components simply use the component name a key
[1] (e.g., LANG).







-
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

2016-11-30 Thread Sergio Fernández 
On Wed, Nov 30, 2016 at 11:21 AM, Andy Seaborne  wrote:

> There are other RDF related projects in ASF. That's a confusing choice of
> key name.


I agree. But then, how do we accommodate to the current Apache Commons
naming in Jira? Feedback would be more than welcomed.


On 30/11/16 07:33, Sergio Fernández wrote:
>>
>> Well, that's a question I also had. So far we have been using COMMONSRDF
>> as
>> Jira key. All the current components simply use the component name a key
>> [1] (e.g., LANG).
>
>

-- 
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 6602747925
e: sergio.fernan...@redlink.co
w: http://redlink.co

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

2016-11-30 Thread 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

2016-11-30 Thread Andy Seaborne 
There are other RDF related projects in ASF. That's a confusing choice 
of key name.


Andy

On 30/11/16 07:33, Sergio Fernández wrote:

Hi,

On Wed, Nov 30, 2016 at 4:58 AM, Matt Sicker  wrote:


Is there anything to be done for jira?



Well, that's a question I also had. So far we have been using COMMONSRDF as
Jira key. All the current components simply use the component name a key
[1] (e.g., LANG). I already requested the change to INFRA [2].

BTW, I've just created INFRA-13004 epic for all INFRA stuff [3]. Please,
add there whatever other subtask I've forgot.

Also, don't forget to update the scm URLs in the pom file.




Stian has already started with that [4]. We have a open issue with the
publication of the different maven components [5], but I'll try to take a
look later today.

Cheers,

[1] https://issues.apache.org/jira/secure/BrowseProjects.jspa#10260
[2] https://issues.apache.org/jira/browse/INFRA-13003
[3] https://issues.apache.org/jira/browse/INFRA-13004
[4] https://github.com/apache/incubator-commonsrdf/commit/
285a6c172fed01fc966b24621110e609321df021
[5] https://issues.apache.org/jira/browse/COMMONSRDF-50



On 28 November 2016 at 05:35, Stian Soiland-Reyes  wrote:



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





--
Matt Sicker 







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

Re: [complex][math-util] dependencies

2016-11-30 Thread Gilles 

On Tue, 29 Nov 2016 18:44:34 -0800, Gary Gregory wrote:
On Tue, Nov 29, 2016 at 5:19 AM, Eric Barnhill 


wrote:

I thought it would be good to raise a structural question here 
rather than

in the commons-complex JIRA.

The Complex library has multiple dependencies on three packages:

-- commons-math base classes (e.g. Field et al.)


-- commons-math exceptions




I have never been a fan of packages that include all exceptions. It 
does

not make sense to me. If an exception is only used in package foo, it
should be defined in that package.

If it is used in foo.one and foo.bar, maybe it belongs in foo. YMMV. 
But
kitchen-sink package for all exceptions does not seem like good 
design to

me.


This kind of hand-waving argument serves little.
[And I'm not saying now that Commons Math's design was good or bad
in that area.]
But did you look at the subject of discussion, i.e. the package in
question and by which packages some of those exception are used?

If one considers an "error" type as a concept, then the _same_ "error"
can appear in multiple places, so this is an argument for having them
stand alone in their own package, rather than having multiple copies,
or have everything in the top-level package.[1]

But I agree that with a true "component"[2], it is probably not worth
to not having a specific "exception" package (namely because the number
of exceptions is likely to be very limited).
[I think that, on that matter, my answer to Eric was clear and in line
with your statement.]


Regards,
Gilles

[1] Which I consider bad design, for reasons not worth mentioning
because I know (from experience, now) that this discussion
will lead to nowhere.
[2] I.e. not with kitchen sinks that [Math] or [Lang] are now.



2c,
Gary



[...]



-
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

2016-11-30 Thread 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 release candidate and vote.
>>
>> This lazy vote will close no sooner that 72 hours from now, i.e. sometime
>> after 09:00 UTC 30-November 2016
>>
>> [ ] +1 Release these artifacts
>> [ ] +0 OK, but...
>> [ ] -0 OK, but really should fix...
>> [ ] -1 I oppose this release because...
>>
>> Thanks!
>>
>> Gary Gregory
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
>> Java Persistence with Hibernate, Second Edition
>>
>> 
>>
>>
>>

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

2016-11-30 Thread Stian Soiland-Reyes 
+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 release candidate and vote.
>
> This lazy vote will close no sooner that 72 hours from now, i.e. sometime
> after 09:00 UTC 30-November 2016
>
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
>
> Thanks!
>
> Gary Gregory
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
> Java Persistence with Hibernate, Second Edition
> <
https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8=1789=9325=1617290459=as2=garygregory-20=cadb800f39946ec62ea2b1af9fe6a2b8
>
>
> <
http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1617290459
>
> JUnit in Action, Second Edition
> <
https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8=1789=9325=1935182021=as2=garygregory-20=31ecd1f6b6d1eaf8886ac902a24de418%22
>
>
> <
http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1935182021
>
> Spring Batch in Action
> <
https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8=1789=9325=1935182951=%7B%7BlinkCode%7D%7D=garygregory-20=%7B%7Blink_id%7D%7D%22%3ESpring%20Batch%20in%20Action
>
>
> <
http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=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: [complex][math-util] dependencies

2016-11-30 Thread Eric Barnhill 
On Tue, Nov 29, 2016 at 8:48 PM, Gilles 
wrote:

> Hello Eric.
>
> On Tue, 29 Nov 2016 14:19:54 +0100, Eric Barnhill wrote:
>
>> I thought it would be good to raise a structural question here rather than
>> in the commons-complex JIRA.
>>
>> The Complex library has multiple dependencies on three packages:
>>
>> -- commons-math base classes (e.g. Field et al.)
>>
>
> Do you foresee any application for "Field" or "FieldElement" classes
> in this component?
> If not, just drop them.
>

There is a ComplexField class. To keep my thoughts short, it looks like the
highly generic Field hierarchy does not have a place in C-M anymore and
should be dropped, including ComplexField.


>
> -- commons-math exceptions
>>
>
> In "Commons RNG", I completely dropped all custom-made exceptions.
> I suggest you do the same here.
> IMO, "simple", low-level, components can do with just throwing
> runtime exceptions from the standard library (with a hard-coded
> _English_ message).
>

Almost all of these are called in the various dependent classes. Given your
suggestions for getting rid of the dependent classes this should become
simple to fix.



>
> -- commons-math util (numerous classes)
>>
>
> My suggestions:
>
>  * CompositeFormat: drop
>  * FastMath: replace with JDK's "Math" calls[1]
>  * IntegerSequence: use a _private_ copy[2][3]
>  * MathUtils:
>- drop "checkNotNull"[4]
>- drop "equals(double,double)", "hash(double)" and
>  "hash(double[])"[5]
>  * Precision: extract the needed bits and make a private copy.
>
> [1] Until we set out to make them interchangeable at runtime.
> [2] Until we agree on creating a component for _very_ low-level
> utilities, and on its contents.
> [3] Like I did with classes "InternalUtils" and "InternalGamma"
> in the "sampling" module of "Commons RNG".
> [4] Let the JVM do it.
> [5] They are trivial; use methods from the JDK directly.
>
>
>> Otherwise it is self-contained. (Some tests within the  QuaternionTest
>> class use a large chain of dependencies from the geometry package, so I
>> think it is best to simply remove the geometry-dependent tests until
>> someone arrives to maintain that library.)
>>
>
> Better keep the tests, and make "Commons Math" (v3.6.1) a
> dependency with scope "test" (as I did for module "sampling"
> in "Commons RNG").
>

Okay, this all ought to work.

Eric

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

2016-11-30 Thread Gilles 

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