[geometry] Initial Project Structure

2018-04-07 Thread Matt Juntunen
Hi all,

I'm forwarding a conversation I had with Gilles on the project structure for 
the new commons-geometry project in order to get feedback on it from everyone. 
Basically, Gilles is proposing (and has initially set up) a multi-module 
project with the following modules so far:

  *   commons-geometry-bsp
  *   commons-geometry-euclidean-oned
  *   commons-geometry-euclidean-twod
  *   commons-geometry-euclidean-threed

My thought was that this module break up is too fine-grain and would make 
development of code that uses more than one dimension more difficult than it 
should be. I was initially picturing having a single project for all of the 
current geometry code since it's all so closely related and there's not much of 
it. However, I can see where Gilles is coming from with the previous experience 
on commons-math. So, I'd like to propose an alternative module break up, one 
that keeps all of the basic euclidean primitives in one place:

  *   commons-geometry-core -- This would contain the code currently in the 
packages
 *   o.a.c.m.geometry
 *   o.a.c.m.partitioning
 *   o.a.c.m.geometry.euclidean.oned
 *   o.a.c.m.geometry.euclidean.twod
 *   o.a.c.m.geometry.euclidean.threed
 *   o.a.c.m.geometry.hull
 *   o.a.c.m.geometry.twod.hull
 *   o.a.c.m.geometry.enclosing (this is the odd-ball in the group here so 
I could be convinced to put this elsewhere)
  *   commons-geometry-spherical -- This would contain
 *   o.a.c.m.geometry.spherical.oned
 *   o.a.c.m.geometry.spherical.twod

Basically, core would contain the main geometry interfaces (eg, Point, Space, 
Vector) as well as all of the basic euclidean functionality. Most users would 
only ever need to pull in this module. The other modules would be for other 
spaces, such as spherical, and other special-purpose code that we have yet to 
develop.

Thoughts?

Thanks,
Matt Juntunen



From: Gilles 
Sent: Saturday, April 7, 2018 6:39 PM
To: Matt Juntunen
Subject: Re: Commons Geometry Project Structure

Hi Matt.

On Sat, 7 Apr 2018 16:01:32 +, Matt Juntunen wrote:
> Hi Gilles,
>
> Yes, I'm picturing a few possible issues with the current structure.
> First, I think that splitting everything up into modules at this
> point
> will inhibit development. For example, each time we add a new
> feature,
> we'll need to worry about either creating a new module or making it
> fit into existing modules. For example, if we make a general utility
> class that makes use of 1D, 2D, and 3D, we'd need to make a separate
> module for it so that it can pull in all of the other dimension
> modules.

Yes. No problem then?

> It wouldn't make sense to put it into 3D since it wouldn't
> just be 3D. This is actually the case with the GeometryTestUtils
> class
> I wrote.
>
> Also, the code may be able to be split up now but there's no
> guarantee that features we want to add in the future won't introduce
> circular dependencies and other issues.

I find it difficult to reason on hypotheticals.
 From a developer's POV, circular dependencies are best avoided.

> Second, having a single module for the current functionality will be
> much more convenient for users. They would just need to pull in a
> single dependency to have access to core functionality for all
> standard dimensions. Plus, a single module makes it much easier to
> discover the overall functionality of the project. This is actually
> how I found out that commons-math had a BSP tree implementation: by
> browsing the code from the source jar. Otherwise, I would have had no
> idea.

I've a bad experience here with "more convenient for users"
arguments: "Commons Math" has remained monolithic primarily
because of it, pulling back development in some packages
because others needed (for some users) to maintain
compatibility with older JVMs.

> Another practical point in my particular case is that I work on a
> project where every 3rd-party artifact needs to be documented and
> approved. Having a bunch of small artifacts makes this really
> difficult.

But this is were Java is going (cf. modularization of the JDK
itself in Java 9)!

Moreover, in the context of Apache and Commons, either one
or more artefacts/modules, the notion of "official release"
is the same and concerns the *source*.
If the issue is with one vs several JAR files, it is readily
solved by creating a so-called "uber" JAR.  For user's
convenience, "Commons Geometry" may provide the necessary
maven goal.

> In short, I think modules are great but not at this point for this
> project. I'm picturing all of the existing geometry code as core
> functionality that should be bundled together. As we add more
> features, we can then make decisions about splitting off separate
> modules. It's too early now.

My opinion is that it is never too early to think about
developer's convenience; without developers, no code,
and no users. ;-)
Opposite to the path which you outline, I'd

Re: [LAZY][VOTE] Release Commons Parent 46 based on RC1.

2018-04-07 Thread Rob Tompkins
Thanks for the catch. Will get to another RC tomorrow probably. 

> On Apr 7, 2018, at 1:56 PM, Gary Gregory  wrote:
> 
> Hi Rob,
> 
> Thank you for preparing yet another RC.
> 
> When I run 'mvn clean package site' and 'mvn clean site' I get:
> 
> [INFO] Generating "japicmp" report   ---
> japicmp-maven-plugin:0.11.1:cmp-report
> [debug] No packaging support defined, no filtering
> [info] Skipping execution because packaging of this module is 'pom'.
> [debug] Searching for versions in versionRange: (,46)
> [INFO] artifact org.apache.commons:commons-parent: checking for updates
> from central
> [debug] Parameter  not configured, i.e. no version
> filtered.
> [warn] No new version specified and file
> 'C:\temp\rc\commons-parent-46-src\pom.xml' of artifact could not be opened
> as jar archive: error in opening zip file
> 
> java.util.zip.ZipException: error in opening zip file
>at java.util.zip.ZipFile.open(Native Method)
>at java.util.zip.ZipFile.(ZipFile.java:225)
>at java.util.zip.ZipFile.(ZipFile.java:155)
>at java.util.jar.JarFile.(JarFile.java:166)
>at java.util.jar.JarFile.(JarFile.java:130)
>at
> japicmp.maven.JApiCmpMojo.populateArchivesListsFromParameters(JApiCmpMojo.java:345)
>at japicmp.maven.JApiCmpMojo.getOptions(JApiCmpMojo.java:708)
>at japicmp.maven.JApiCmpReport.getOptions(JApiCmpReport.java:108)
>at
> japicmp.maven.JApiCmpReport.getDescription(JApiCmpReport.java:127)
>at
> org.apache.maven.plugins.site.render.CategorySummaryDocumentRenderer.renderDocument(CategorySummaryDocumentRenderer.java:155)
>at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:349)
>at
> org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.java:184)
>at
> org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:133)
>at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
>at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
>at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
>at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
>at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
>at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
>at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
>at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
>at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
>at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
>at org.apache.maven.cli.MavenCli.execute(MavenCli.java:956)
>at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:290)
>at org.apache.maven.cli.MavenCli.main(MavenCli.java:194)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.lang.reflect.Method.invoke(Method.java:498)
>at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
>at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
>at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> 
> [warn] Please provide at least one resolvable new version using one of the
> configuration elements  or .
> [INFO]
> 
> [INFO] BUILD SUCCESS
> [INFO]
> 
> [INFO] Total time: 22.978 s
> [INFO] Finished at: 2018-04-07T11:52:28-06:00
> [INFO]
> 
> 
> Running 'mvn package' is OK.
> 
> I am using:
> 
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
> 2018-02-24T12:49:05-07:00)
> Maven home: C:\Java\apache-maven-3.5.3\bin\..
> Java version: 1.8.0_162, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_162\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> 
> Gary
> 
> 
> 
> 
>> On Sat, Apr 7, 2018 at 8:33 AM, Rob Tompkins  wrote:
>> 
>> Hello all,
>> 
>> 
>> This is a [LAZY][VOTE] for releasing Apache Commons Parent 46 (from RC1).
>> 
>> 
>> Tag name:
>>   

Re: [LAZY][VOTE] Release Commons Parent 46 based on RC1.

2018-04-07 Thread Gary Gregory
Hi Rob,

If you roll another RC, we can consider if we should take into account what
'mvn versions:display-plugin-updates' says:

maven-assembly-plugin ... 3.0.0 -> 3.1.0

Gary

On Sat, Apr 7, 2018 at 8:33 AM, Rob Tompkins  wrote:

> Hello all,
>
>
> This is a [LAZY][VOTE] for releasing Apache Commons Parent 46 (from RC1).
>
>
> Tag name:
>commons-parent-46-RC1
>
>
> Tag URL:
>https://svn.apache.org/repos/asf/commons/proper/commons-
> parent/tags/commons-parent-46-RC1/
>
>
> Commit ID the tag points at:
> 1828594
>
>
> Site Zip:
>https://dist.apache.org/repos/dist/dev/commons/commons-parent/site.zip
>
>
> Distribution files (committed at revision 26215):
>https://dist.apache.org/repos/dist/dev/commons/commons-parent/
>
>
> Distribution files hashes (SHA1):
>commons-parent-46-src.tar.gz
>(SHA1: e7f853fb128e265dda53378e0dc48496e234b515)
>commons-parent-46-src.zip
>(SHA1: f8a541ee6c47087faadd15b965a639ffc1479308)
>
>
> These are the Maven artifacts and their hashes:
>commons-parent-46-site.xml
>(SHA1: 02b3b54d26d97a72fd55b20d027040ca0daf52b7)
>commons-parent-46.pom
>(SHA1: ab870c61db51aec38cba6ee86f594a7f744d9a26)
>
>
> KEYS file to check signatures:
>http://www.apache.org/dist/commons/KEYS
>
>
> Maven artifacts:
>https://repository.apache.org/content/repositories/
> orgapachecommons-1322
>
>
> 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-04-10T15: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
>
>


Re: [LAZY][VOTE] Release Commons Parent 46 based on RC1.

2018-04-07 Thread Gary Gregory
Hi Rob,

Thank you for preparing yet another RC.

When I run 'mvn clean package site' and 'mvn clean site' I get:

[INFO] Generating "japicmp" report   ---
japicmp-maven-plugin:0.11.1:cmp-report
[debug] No packaging support defined, no filtering
[info] Skipping execution because packaging of this module is 'pom'.
[debug] Searching for versions in versionRange: (,46)
[INFO] artifact org.apache.commons:commons-parent: checking for updates
from central
[debug] Parameter  not configured, i.e. no version
filtered.
[warn] No new version specified and file
'C:\temp\rc\commons-parent-46-src\pom.xml' of artifact could not be opened
as jar archive: error in opening zip file

java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:225)
at java.util.zip.ZipFile.(ZipFile.java:155)
at java.util.jar.JarFile.(JarFile.java:166)
at java.util.jar.JarFile.(JarFile.java:130)
at
japicmp.maven.JApiCmpMojo.populateArchivesListsFromParameters(JApiCmpMojo.java:345)
at japicmp.maven.JApiCmpMojo.getOptions(JApiCmpMojo.java:708)
at japicmp.maven.JApiCmpReport.getOptions(JApiCmpReport.java:108)
at
japicmp.maven.JApiCmpReport.getDescription(JApiCmpReport.java:127)
at
org.apache.maven.plugins.site.render.CategorySummaryDocumentRenderer.renderDocument(CategorySummaryDocumentRenderer.java:155)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:349)
at
org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.java:184)
at
org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:133)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:290)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:194)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)

[warn] Please provide at least one resolvable new version using one of the
configuration elements  or .
[INFO]

[INFO] BUILD SUCCESS
[INFO]

[INFO] Total time: 22.978 s
[INFO] Finished at: 2018-04-07T11:52:28-06:00
[INFO]


Running 'mvn package' is OK.

I am using:

Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
2018-02-24T12:49:05-07:00)
Maven home: C:\Java\apache-maven-3.5.3\bin\..
Java version: 1.8.0_162, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_162\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Gary




On Sat, Apr 7, 2018 at 8:33 AM, Rob Tompkins  wrote:

> Hello all,
>
>
> This is a [LAZY][VOTE] for releasing Apache Commons Parent 46 (from RC1).
>
>
> Tag name:
>commons-parent-46-RC1
>
>
> Tag URL:
>https://svn.apache.org/repos/asf/commons/proper/commons-
> parent/tags/commons-parent-46-RC1/
>
>
> Commit ID the tag points at:
> 1828594
>
>
> Site Zip:
>https://dist.apache.org/repos/dist/dev/commons/commons-parent/site.zip
>
>
> Distribution files (committed

[LAZY][VOTE] Release Commons Parent 46 based on RC1.

2018-04-07 Thread Rob Tompkins
Hello all,


This is a [LAZY][VOTE] for releasing Apache Commons Parent 46 (from RC1).


Tag name:
   commons-parent-46-RC1


Tag URL:
   
https://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-46-RC1/


Commit ID the tag points at:
1828594


Site Zip:
   https://dist.apache.org/repos/dist/dev/commons/commons-parent/site.zip


Distribution files (committed at revision 26215):
   https://dist.apache.org/repos/dist/dev/commons/commons-parent/


Distribution files hashes (SHA1):
   commons-parent-46-src.tar.gz
   (SHA1: e7f853fb128e265dda53378e0dc48496e234b515)
   commons-parent-46-src.zip
   (SHA1: f8a541ee6c47087faadd15b965a639ffc1479308)


These are the Maven artifacts and their hashes:
   commons-parent-46-site.xml
   (SHA1: 02b3b54d26d97a72fd55b20d027040ca0daf52b7)
   commons-parent-46.pom
   (SHA1: ab870c61db51aec38cba6ee86f594a7f744d9a26)


KEYS file to check signatures:
   http://www.apache.org/dist/commons/KEYS


Maven artifacts:
   https://repository.apache.org/content/repositories/orgapachecommons-1322


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-04-10T15: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



Re: [ANNOUNCE] Apache Commons Build Plugin 1.8 Released

2018-04-07 Thread Rob Tompkins


> On Apr 6, 2018, at 8:26 AM, Otto Fowler  wrote:
> 
> Congratulations!

Thanks :-)

> 
> 
> On April 6, 2018 at 08:10:55, Rob Tompkins (chtom...@apache.org 
> ) wrote:
> 
>> [Not cross posted to @announce since this is internal to Commons] 
>> 
>> Apache Commons has released the Apache Commons Build Plugin 1.8. 
>> 
>> The Apache Commons Build Plugin is a Maven Plugin which can be used by 
>> Apache Commons components. 
>> 
>> See: 
>> http://commons.apache.org/commons-build-plugin/ 
>>  
>> 
>> VERSION 1.8 - 2018-04-05 
>>  
>> 
>> Changes since the last release 
>> 1. Fix EOL-style so generated files have correct setting 
>> 2. Change download page from MD5 to SHA1 
>> 3. Include JavaDoc badge in README.md file. 
>> 
>> Cheers, 
>> -Rob 
>> 
>> - 
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org 
>>  
>> For additional commands, e-mail: dev-h...@commons.apache.org 
>> 


Re: Google Summer of Code

2018-04-07 Thread Gilles

Hi.

On Fri, 6 Apr 2018 21:09:56 -0400, Greg Driscoll wrote:

Hello all,

I'm a computer science student that's really interested in doing a 
Google

Summer of Code project working on the commons-numbers User Guide and
benchmarks.  In Jira 
it'shttps://issues.apache.org/jira/browse/NUMBERS-70.


Thanks for your interest, and welcome.

The link to my proposal is here 
https://docs.google.com/document/d/1i6yy2cW0x9MYbDOuLPdZrV0XA0eKO5q5N0SNg99mJfA/edit?usp=sharing


Looks good.
A few remarks:
 * There is no structure for benchmarks in Commons Math" (there are
   home-made codes used there for "FastMath" (that have shown that
   "FastMath is nos always fast...).
   Here the purpose is to use JMH. [There are examples in "Commons
   RNG".]
 * I'd suggest "apt" for the documentation format since it is
   somewhat easier than "xdoc" for tables (as the likely output
   of the benchmark project).
 * Don't hesitate to open JIRA reports for each task that may need
   interaction on the details
 * At first sight, script(s) to convert from JMH's output to "apt"
   would be welcome.

Please let me know what you think about it.  You can reply to this 
mailing

list, comment on the doc, or email me directly.


Let's keep discussion on this list so that everyone interested
can participate.

Best,
Gilles


Thanks.



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