Re: [RDF] Bump Java requirement from Java 8 to 11

[Martijn Verburg]

Let's move the ecosystem forward :-)

Cheers,
Martijn


On Mon, 19 Feb 2024 at 05:07, Gary Gregory  wrote:

> To use a new Jena version, we would require Java 11.
>
> Raise your hand if this would be a deal breaker for you and why.
>
> Raise your hand to say hi or anything else ;-)
>
> See:
>
> - the thread [RDF] New Jena Version
> - the PR https://github.com/apache/commons-rdf/pull/196
>
> Gary
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [all] Amazon Corretto

[Martijn Verburg]

We're (AdoptOpenJDK) are working with Amazon if that helps :-).  They're
using a bunch of our build and test scripts.

Cheers,
Martijn


On Wed, 14 Nov 2018 at 19:03, Pascal Schumacher 
wrote:

> Isn't this basically the same as Adopt Open JDK:
>
> https://adoptopenjdk.net
>
> or am I missing something?
>
> -Pascal
>
> Am 14.11.2018 um 15:14 schrieb Rob Tompkins:
> > Curious to see what people’s thoughts are to this:
> >
> > https://aws.amazon.com/corretto/
> >
> > -Rob
> > -
> > 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: [All] "Commons Math" is not a component

[Martijn Verburg]

This sounds like an approach analogous to the incubator modules in OpenJDK
itself.

Hopefully this will suit both worlds.  Those who want the complete bundle
can do so, those who want discrete modules can do so.

Cheers,
Martijn

On 9 December 2017 at 01:59, Gilles <gil...@harfang.homelinux.org> wrote:

> Hi all.
>
> Stephen Colebourne correctly summarized the situation[1]:
> Project management must be based on life-cycle, not the
> other way around.
>
> Here below, a concrete plan is proposed in answer to the
> suggestion (of a fork) made by Martijn Verburg[2].
>
> 1. Initial (beta?) release of "Commons Numbers".[3][4]
> 2. Create separate git repositories for functionalities
>that have independent life-cycles and move the codes
>out of "Commons Math".
> 3. Modularize "Commons Math" into
>a. A set of "supported" modules: functionalities having
>   undergone a review in order to define a stable API.
>b. A set of "experimental"/"beta" modules: functionalities
>   that have been modified since the last release (e.g.
>   bug fixes[5]) but are expected to undergo API changes.
>c. A "legacy" module for heavily used functionalities known
>   to harbour difficult design issues.
> 4. Initial (beta?) release of codes in category (2) as new
>components.
> 5. First non-beta release of "Commons Numbers".
> 6. Release v4.0 of "Commons Math".
> 7. First non-beta release of codes in category (2).
> 8. Progressively move code from category (3c) to (3b) and
>from (3b) to (3a), or to (2). And RERO accordingly.
>
> Do you (PMC, committers, developers and users) foresee any
> show-stoppers in the above sequence?
>
> Regards,
> Gilles
>
> [1] http://markmail.org/message/w3imqvbf3wphvokj
> [2] http://markmail.org/message/rribnh3tiikqtllf
> [3] https://git1-us-west.apache.org/repos/asf?p=commons-numbers.git
> [4] https://issues.apache.org/jira/projects/NUMBERS
> [5] https://issues.apache.org/jira/projects/MATH
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [All][Math][Numbers] Refactoring "Commons Math" (Was: [...] "Commons Geometry"?)

[Martijn Verburg]

Hi Gilles,

That sounds eminently sensible to me as an end user.  I'd like my 3rd party
deps to be as small as possible, so a modularised Math is good for me.

Cheers,
Martijn

On 7 December 2017 at 17:05, Gilles <gil...@harfang.homelinux.org> wrote:

> Hi Martijn.
>
> On Tue, 5 Dec 2017 23:45:43 +, Martijn Verburg wrote:
>
>> Can this project be forked to a new domain over on GitHub (under the
>> existing Apache license),
>>
>
> It is allowed, of course.  However, I think that it is the
> last option to consider, because it will further dilute the
> community that has an interest in the "Commons Math" codebase.
> For developers and for users, there are practical advantages
> in keeping the spin-off projects within "Commons".
> It is even a more appropriate place than a TLP!
> [In this evaluation, I of course do not account for the
> negative stance of part of the PMC.]
>
> split up and then continued in that case?
>>
>
> The work had started.
> Did you have a look at "Commons RNG"[1] and "Commons Numbers"[2]?
> Both were spun off the development version of "Commons Math"[3].
>
> IMO, current priority is to have an initial (beta?) release of
> "Commons Numbers". There is a list of issues in the bug-tracking
> system:
>   https://issues.apache.org/jira/projects/NUMBERS
>
> An important test must pass (before a release can make sense):
> All the code that was "moved" (to "Numbers") must be removed
> from "Math", and functionalities of the latter must be adapted
> to depend on "Numbers".
>
> Afterwards, a probably easy task would be to create another
> generally useful component out of the "o.a.c.math4.geometry"
> package (no other part of CM depends on it and it has almost
> no dependencies on any other CM class).
> Another easy move would be the code in package "o.a.c.math4.ml"
> (zero cross-dependencies). [Although developer and user of that
> package, I admit that the functionality might currently be too
> limited to warrant a component.]
> Less easy (but quite useful) would be a component based on a
> selection of the functionalities in package "o.a.c.math4.analysis"
> (root solver, interpolation, integration).
>
> The rest of CM is either too advanced or with cross-dependencies
> not easy to untangle and/or too many issues to solve, in order
> to create good components, given the scarce human resources...
>
> Next, we can tackle tasks on CM itself:
> - make modules for functionality that is free of issues and
>   supported, and
> - make a "legacy" module for everything else.
> Then, we head toward a long-overdue release.
>
> Opinions on the plan is appreciated, and help to make progress
> (forward!) is most welcome.
>
> Regards,
> Gilles
>
> [1] https://git1-us-west.apache.org/repos/asf?p=commons-rng.git
> [2] https://git1-us-west.apache.org/repos/asf?p=commons-numbers.git
> [3] https://git1-us-west.apache.org/repos/asf?p=commons-math.git
>
>
>> Cheers,
>> Martijn
>>
>> On 3 December 2017 at 11:51, Gilles <gil...@harfang.homelinux.org> wrote:
>>
>> On Sun, 3 Dec 2017 11:18:18 +0100, Jochen Wiedmann wrote:
>>>
>>> On Fri, Dec 1, 2017 at 2:26 PM, Gilles <gil...@harfang.homelinux.org>
>>>> wrote:
>>>>
>>>> There hasn't been any progress towards a decision.
>>>>
>>>>> There isn't even a consensus on one of the central tenets of
>>>>> Apache ("Those who do the work..."): how sad/strange (?).
>>>>>
>>>>>
>>>> Those who do the work are welcome to decide on their own, if they do
>>>> not involve others.
>>>>
>>>>
>>> The conditional is not part of the well-known mantra.
>>>
>>> The issue here is to answer the question of what to do with
>>> a non-trivial code base.  My stance is to try and fix the
>>> problem(s), a.o. difficult management, by rooting out its
>>> main cause: CM has become an aggregate of components with
>>> completely different subject matters, scopes, designs,
>>> efficiencies, provisions for extension, etc.
>>> [An array of issues which "maven" modules will not solve.]
>>>
>>> We are seemingly faced with a choice between:
>>> 1. Maintain CM as the huge library that it is now.
>>> 2. Incrementally create maintainable components.
>>>
>>> A long time has passed since these alternatives were first
>>> exposed, only proving that none of the people who informa

Re: [All][Math] New component: "Commons Geometry"?

[Martijn Verburg]

Can this project be forked to a new domain over on GitHub (under the
existing Apache license), split up and then continued in that case?

Cheers,
Martijn

On 3 December 2017 at 11:51, Gilles  wrote:

> On Sun, 3 Dec 2017 11:18:18 +0100, Jochen Wiedmann wrote:
>
>> On Fri, Dec 1, 2017 at 2:26 PM, Gilles 
>> wrote:
>>
>> There hasn't been any progress towards a decision.
>>> There isn't even a consensus on one of the central tenets of
>>> Apache ("Those who do the work..."): how sad/strange (?).
>>>
>>
>> Those who do the work are welcome to decide on their own, if they do
>> not involve others.
>>
>
> The conditional is not part of the well-known mantra.
>
> The issue here is to answer the question of what to do with
> a non-trivial code base.  My stance is to try and fix the
> problem(s), a.o. difficult management, by rooting out its
> main cause: CM has become an aggregate of components with
> completely different subject matters, scopes, designs,
> efficiencies, provisions for extension, etc.
> [An array of issues which "maven" modules will not solve.]
>
> We are seemingly faced with a choice between:
> 1. Maintain CM as the huge library that it is now.
> 2. Incrementally create maintainable components.
>
> A long time has passed since these alternatives were first
> exposed, only proving that none of the people who informally
> chose option(1) invested work to make it a reality.
>
> Refusing option (2) not only "involves others"; it is harming
> them (very real people, having done a lot of work here, on
> that code base).
>
> Establishing a new commons component doesn't
>> qualify, IMO.
>>
>
> True; that's why we are stalled, despite that a majority
> of the PMC did not explicitly oppose option (2).
>
> A handful of PMC people prefer to let the code base become
> "dormant" rather than give any chance to an alternate view.
> [If, say, you looked at the "Commons RNG" project, and
> concluded that, decidedly, this is not how a component
> should look like, then I could perhaps fathom out where
> those reservations come from.]
>
> Gilles
>
>
>> Jochen
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [All][Math] New component: "Commons Geometry"?

[Martijn Verburg]

Has the PMC and the active developers met over a video call to try and hash
this out?

It would be a shame to see this library fall into disuse.

I'd also argue with Jigsaw being the heart of Java 9+ that more modular
libs now make sense.

Cheers,
Martijn

On 1 December 2017 at 14:56, Gilles  wrote:

> On Fri, 1 Dec 2017 19:23:57 +0530, Amey Jadiye wrote:
>
>> On Fri, Dec 1, 2017 at 6:56 PM, Gilles 
>> wrote:
>>
>> Hello Amey.
>>>
>>
>>
>> Hi Gilles,
>>
>>
>>>
>>> On Thu, 30 Nov 2017 23:45:45 +0530, Amey Jadiye wrote:
>>>
>>> Pardon me for pulling this thread up again, I havent read anything about
 "Commons Geometry" since long


>>> Thanks for your renewed interest.
>>>
>>> (or may be I missed any other disscussion? ).
>>>


>>> Probably not.
>>>
>>> is someone working on this ?
>>>


>>> It would be a surprise.
>>>
>>> what is the final decision ?
>>>


>>> There hasn't been any progress towards a decision.
>>>
>>>
>> I'm not sure if "Lazy Consensus" works in these matters ? better take help
>> of it, its fast and easy.
>>
>
> By definition, it does not apply when people voice their opinion:
> Some did it one way, others did it in another (non-compatible way).
>
> The strange thing here is that some PMC members seem to prefer
> moving Commons Math to "dormant" rather than let the few remaining
> active developers do some cleanup in the hope to revivify some of
> the code base in a more modern Java eco-system.
>
> Gilles
>
> [...]
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [ALL][Math] Anyone?

[Martijn Verburg]

Purely as an end user yes I'd like to see another release :-)
Cheers,
Martijn


On 19 March 2017 at 18:27, Gilles  wrote:
> Hello.
>
>
> Issues are piling up on JIRA.
> I'm the only one interacting with external contributors.
>
> Is there interest in having 4.0 released?
> [There have been 74 fixes/changes/improvements wrt the
> last official release, one year ago.]
>
>
> Regards,
> Gilles
>
>
> -
> 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

Status of BCEL 6.0 release

[Martijn Verburg]

Hi all,

I had a look through the archives and noticed a conversation around early
Nov discussing getting some fixes contributed to the BCEL lib and doing a
release to support Java 8.  Is there anything I can do to help?

Cheers,
Martijn