You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ole Ersoy <ol...@gmail.com> on 2015/11/06 22:06:35 UTC
[math] Smaller Packages / Artifacts / Dependencies
If math is broken up into smaller artifacts it will make it easier for users to upgrade, even if it it breaks compatibility, as well as speed up the release frequency. So for example:
commons-math-optimization (Or even more granular commons-math-optimization-lp, commons-math-optimization-ga, commons-math-optimization-nlp, etc)
commons-math-simulation
commons-math-statistics
commons-math-ai (Neural Networks, ...)
etc.
Cheers,
- Ole
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Smaller Packages / Artifacts / Dependencies
Posted by Ole Ersoy <ol...@gmail.com>.
On 11/07/2015 04:00 AM, Gilles wrote:
> On Fri, 6 Nov 2015 15:06:35 -0600, Ole Ersoy wrote:
>> If math is broken up into smaller artifacts it will make it easier
>> for users to upgrade, even if it it breaks compatibility, as well as
>> speed up the release frequency. So for example:
>> commons-math-optimization (Or even more granular
>> commons-math-optimization-lp, commons-math-optimization-ga,
>> commons-math-optimization-nlp, etc)
>> commons-math-simulation
>> commons-math-statistics
>> commons-math-ai (Neural Networks, ...)
>> etc.
>
> I also believe that modularity is a worthy goal.
>
> A first step would be to collect some statistics on inter-package
> dependencies.
Personally I like modules and repositories that are very small and focused with as few dependencies as possible. I'm probably in the extreme bulleye of the circle on this. The reason I like it is because I can read a few usage lines in the github README.md and go. It's easy to contribute to and minimizes indirection. For example I think the optimizers are complex enough to warrant their own module. The distributions probably belong in a single module, etc.
I'm still in the process of getting a demo repository setup, but it will be along these lines. Once that's done it should make it really simple for someone to just clone, build, and get to work. It's nice if it's on Maven, but if the module is tiny, and easy to verify visually, then cloning and building is a reasonable way to get things done.
> There will certainly be a "commons-math-core" containing packages
> like "o.a.c.m.util" and "o.a.c.m.exception".
> [At some point, releasing separate JARs could also provide us with
> indirect feedback on which parts of CM are actually used.]
And the stars on github are a pretty good indicator as well.
Cheers,
- Ole
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Smaller Packages / Artifacts / Dependencies
Posted by Gilles <gi...@harfang.homelinux.org>.
On Sat, 7 Nov 2015 18:54:59 +0100, Pascal Schumacher wrote:
> I guess searching github is more representative:
>
>
> https://github.com/search?q=org.apache.commons.math3&type=Code&utf8=%E2%9C%93
Thanks. But the number of references is so large
---CUT---
We’ve found 355,855 code results
---CUT---
that it is not telling much either.
Do you know how to sort and group the results in a meaningful way?
Gilles
> Am 07.11.2015 um 18:43 schrieb Gilles:
>> On Sat, 7 Nov 2015 16:56:45 +0100, Emmanuel Bourg wrote:
>>> Le 07/11/2015 11:00, Gilles a écrit :
>>>
>>>> [At some point, releasing separate JARs could also provide us with
>>>> indirect feedback on which parts of CM are actually used.]
>>>
>>> You might find this interesting:
>>
>> Thanks for the link. Interesting indeed.
>>
>>> https://codesearch.debian.net/perpackage-results/import
>>> org.apache.commons.math
>>
>> I did the more useful search for "org.apache.commons.math3"
>>
>> Apart from CM itself, there is only one (1) other package
>> that uses CM...
>>
>> But isn't looking for Java application usage through the lens
>> of Debian packages totally misleading?
>> I mean, beyond installing the JDK, isn't the Java applications
>> "eco-system" largely independent of a distribution (since a
>> Java program can be "run anywhere")?
>>
>>
>> Gilles
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Smaller Packages / Artifacts / Dependencies
Posted by Pascal Schumacher <pa...@gmx.net>.
I guess searching github is more representative:
https://github.com/search?q=org.apache.commons.math3&type=Code&utf8=%E2%9C%93
Am 07.11.2015 um 18:43 schrieb Gilles:
> On Sat, 7 Nov 2015 16:56:45 +0100, Emmanuel Bourg wrote:
>> Le 07/11/2015 11:00, Gilles a écrit :
>>
>>> [At some point, releasing separate JARs could also provide us with
>>> indirect feedback on which parts of CM are actually used.]
>>
>> You might find this interesting:
>
> Thanks for the link. Interesting indeed.
>
>> https://codesearch.debian.net/perpackage-results/import
>> org.apache.commons.math
>
> I did the more useful search for "org.apache.commons.math3"
>
> Apart from CM itself, there is only one (1) other package
> that uses CM...
>
> But isn't looking for Java application usage through the lens
> of Debian packages totally misleading?
> I mean, beyond installing the JDK, isn't the Java applications
> "eco-system" largely independent of a distribution (since a
> Java program can be "run anywhere")?
>
>
> Gilles
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Smaller Packages / Artifacts / Dependencies
Posted by Gilles <gi...@harfang.homelinux.org>.
On Sat, 7 Nov 2015 16:56:45 +0100, Emmanuel Bourg wrote:
> Le 07/11/2015 11:00, Gilles a écrit :
>
>> [At some point, releasing separate JARs could also provide us with
>> indirect feedback on which parts of CM are actually used.]
>
> You might find this interesting:
Thanks for the link. Interesting indeed.
> https://codesearch.debian.net/perpackage-results/import
> org.apache.commons.math
I did the more useful search for "org.apache.commons.math3"
Apart from CM itself, there is only one (1) other package
that uses CM...
But isn't looking for Java application usage through the lens
of Debian packages totally misleading?
I mean, beyond installing the JDK, isn't the Java applications
"eco-system" largely independent of a distribution (since a
Java program can be "run anywhere")?
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Smaller Packages / Artifacts / Dependencies
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 07/11/2015 11:00, Gilles a écrit :
> [At some point, releasing separate JARs could also provide us with
> indirect feedback on which parts of CM are actually used.]
You might find this interesting:
https://codesearch.debian.net/perpackage-results/import
org.apache.commons.math
Emmanuel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Smaller Packages / Artifacts / Dependencies
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 6 Nov 2015 15:06:35 -0600, Ole Ersoy wrote:
> If math is broken up into smaller artifacts it will make it easier
> for users to upgrade, even if it it breaks compatibility, as well as
> speed up the release frequency. So for example:
> commons-math-optimization (Or even more granular
> commons-math-optimization-lp, commons-math-optimization-ga,
> commons-math-optimization-nlp, etc)
> commons-math-simulation
> commons-math-statistics
> commons-math-ai (Neural Networks, ...)
> etc.
I also believe that modularity is a worthy goal.
A first step would be to collect some statistics on inter-package
dependencies.
There will certainly be a "commons-math-core" containing packages
like "o.a.c.m.util" and "o.a.c.m.exception".
[At some point, releasing separate JARs could also provide us with
indirect feedback on which parts of CM are actually used.]
Best regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org