Re: [numbers] Making Quaternion a VALJO

[Matt Juntunen]

Hi guys,

FYI, I've been working on a quaternion-related class named QuaternionRotation 
for commons-geometry (see link below). It includes slerp as well as several 
other geometry-oriented methods, such as conversion to/from axis-angle 
representations and creation from basis rotations. It's not quite ready for a 
merge yet since I still need to finish the Euler angle conversions.

I did not use the Quaternion class from commons-numbers since I wanted to focus 
solely on using quaternions to represent 3D rotations. I felt like the 
commons-numbers class was too general for this.

Regards,
Matt


https://github.com/darkma773r/commons-geometry/blob/transforms/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/threed/QuaternionRotation.java
[https://avatars1.githubusercontent.com/u/3809623?s=400=4]

darkma773r/commons-geometry
Apache Commons Geometry. Contribute to darkma773r/commons-geometry development 
by creating an account on GitHub.
github.com





From: Gilles 
Sent: Friday, November 30, 2018 9:37 AM
To: dev@commons.apache.org
Subject: Re: [numbers] Making Quaternion a VALJO

On Fri, 30 Nov 2018 14:22:45 +, Steve Bosman wrote:
>> > and I have also emailed an ICLA.
>
>> Not received/acknowledged yet.
>
> I am now listed on the "Persons with signed CLAs but who are not
> (yet)
> committers." page.

Welcome!

>> > I think two convenience divide methods performing qr^{-1} and
>> r^{-1}q
>> > for q
>> > and r would be useful, but I couldn't think of nice names for
>> them.
>
>> What are the use-cases?
>> Why aren't "multiply" and "inverse" enough?
>
> I must admit I'm new to quaternions and stumbled into the project
> while
> trying to improve my understanding so I'm not going to claim great
> knowledge of how common these operations are. I was primarily
> thinking of
> Quaternion Interpolation - SLERP and SQUAD. It seems to me that you
> end up
> creating inverse instances and throwing them away a lot and I thought
> it
> would be good to reduce that overhead.

Surely, the class "Quaternion" is minimal but, before adding to
the API, we be careful to have use-cases for low-level operations.
Those mentioned above seems more high-level, tied to a specific
domain (see also "Commons Geometry", another new component not yet
released) but I may be wrong...

Regards,
Gilles

>
> Steve


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

Re: commons-numbers git commit: NUMBERS-79: Fraction.add() and .subtract() are long-based

[Gilles]

Convention is to set the "serialVersionUID" to the date of the change.

Regards,
Gilles

On Sat,  1 Dec 2018 00:10:48 + (UTC), ericbarnh...@apache.org 
wrote:

Repository: commons-numbers
Updated Branches:
  refs/heads/fraction-dev 16f60190b -> ac4d27549


NUMBERS-79: Fraction.add() and .subtract() are long-based

Converted add() and subtract() methods of Fraction class to 
long-based

operations with recommendation to use BigFraction for very large
numerators and denominators. Updated corresponding documentation.

Project: http://git-wip-us.apache.org/repos/asf/commons-numbers/repo
Commit:

http://git-wip-us.apache.org/repos/asf/commons-numbers/commit/ac4d2754
Tree: 
http://git-wip-us.apache.org/repos/asf/commons-numbers/tree/ac4d2754
Diff: 
http://git-wip-us.apache.org/repos/asf/commons-numbers/diff/ac4d2754


Branch: refs/heads/fraction-dev
Commit: ac4d27549483a67b5cb1f87fe952c86ea687ccd3
Parents: 16f6019
Author: Eric Barnhill 
Authored: Fri Nov 30 16:07:17 2018 -0800
Committer: Eric Barnhill 
Committed: Fri Nov 30 16:07:17 2018 -0800


--
 .../commons/numbers/fraction/Fraction.java  | 177 
---

 1 file changed, 76 insertions(+), 101 deletions(-)

--



http://git-wip-us.apache.org/repos/asf/commons-numbers/blob/ac4d2754/commons-numbers-fraction/src/main/java/org/apache/commons/numbers/fraction/Fraction.java

--
diff --git

a/commons-numbers-fraction/src/main/java/org/apache/commons/numbers/fraction/Fraction.java

b/commons-numbers-fraction/src/main/java/org/apache/commons/numbers/fraction/Fraction.java
index 673d0d5..aeb5030 100644
---

a/commons-numbers-fraction/src/main/java/org/apache/commons/numbers/fraction/Fraction.java
+++

b/commons-numbers-fraction/src/main/java/org/apache/commons/numbers/fraction/Fraction.java
@@ -19,18 +19,19 @@ package org.apache.commons.numbers.fraction;
 import java.io.Serializable;
 import java.math.BigInteger;
 import org.apache.commons.numbers.core.ArithmeticUtils;
+import org.apache.commons.numbers.core.NativeOperators;

 /**
  * Representation of a rational number.
- *
- * implements Serializable since 2.0
  */
 public class Fraction
 extends Number
-implements Comparable, Serializable {
+implements Comparable,
+   Serializable,
+   NativeOperators {

-/** A fraction representing "2 / 1". */
-public static final Fraction TWO = new Fraction(2, 1);
+/** Serializable version identifier */
+private static final long serialVersionUID = 
3698073679419233275L;


[...]


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

Re: [numbers] Fraction() and Knuth 4.5.1 -- overflow, BigInteger, long, and rounding

[Gilles]

On Fri, 30 Nov 2018 15:56:54 -0800, Eric Barnhill wrote:
Here is what I propose for the Fraction doc text regarding this 
issue:


 * Implement add and subtract. This algorithm is similar to that
 * described in Knuth 4.5.1. while making some concessions to
 * performance. Note Knuth 4.5.1 Exercise 7, which observes that
 * adding two fractions with 32-bit numerators and denominators
 * requires 65 bits in extreme cases. Here calculations are 
performed

 * with 64-bit longs and the BigFraction class is recommended for
numbers
 * that may grow large enough to be in danger of overflow.


Does this mean that computations can "unpredictably" overflow
(or throw an exception)?
Is it acceptable, or should we enclose the problematic code in
a "try" block and redo the computation with "BigInteger" when
necessary?

What is the performance hit of using "BigFraction" rather than
"Fraction"?
Are there use-cases that would need the ultimate performance from
"Fraction" while not worry about overflow?

Regards,
Gilles




On Fri, Nov 9, 2018 at 4:33 PM Eric Barnhill  
wrote:


Addendum to the above. In an exercise in the Knuth book Knuth does 
indeed

state that "If the inputs are n-bit binary numbers, 2N+1 bits may be
necessary to represent t." where t is a derived quantity that would 
take

some time to explain.

So that means in extreme cases, the needed precision to represent a
fraction operation with 32 bits ints is 65 bits, one more than a 
long has.


The present code solves this by using BigInteger briefly in the 
code,
which strikes me as an awfully big performance hit for what must 
surely be

very occasional and very  extreme cases.

I think the most sensible strategy would be to restrict the 
precision of

Fraction to longs, with user guidance to use BigFraction if there is
concern of overflow.

Eric







On Thu, Nov 8, 2018 at 11:11 AM Gary Gregory 


wrote:

I'm all for the Javadoc made to reflect the reality of the code. It 
is

fine
to have an additional section that points out Knuth and how we may 
want to

change things as a hint or request to contributors.

Gary

On Wed, Nov 7, 2018 at 10:52 AM Eric Barnhill 


wrote:

> I read Kunth's "Art of Computer Programming 4.5.1" that is 
referenced

many
> times in the doc as the guidance for the 
commons-math/commons-numbers
> Fraction class. It is an interesting read. Also, for all the 
times it is
> cited in the doc, it is interesting that Fraction doesn't really 
use it

as
> implemented. Here is one example.
>
> Knuth is concerned about overflow in multiplication and division,
because
> numerator of f1 is multiplied by denominator of f2 and so forth, 
so he

> suggests a technique called "mediant rounding" that allows for
intermediate
> quantities in fraction multiplication to be rounded.
>
> It is a clever technique and probably works well, however the 
current
> Fraction class cites this chapter, then implements multiplication 
with

> BigInteger instead, ignoring this suggestion.
>
> First of all, the doc should be clear that the code is NOT 
following

4.5.1,
> while it gives the opposite impression. And that's ok but the use 
of
> BigInteger creates additional inconsistency: Multiply and divide 
are

> accomplished using ArithmeticUtils.addAndCheck and
> ArithmeticUtils.mulAndCheck . These convert the relevant ints to 
longs,
> then perform the operation, then if the resulting long is greater 
than

the
> range of an int, throw an OverflowException. So some parts of 
Fraction

> check for overflow using longs and others use BigInteger.
>
> It seems to me that BigInteger is overkill here for the vast 
majority of

> practical uses of Fraction in a way that could be damaging for
performance.
> And furthermore, we already have a BigFraction class to handle 
cases

that
> require BigInteger.
>
> So, I propose rewriting the doc to say the opposite of what it 
currently
> says when appropriate, and get usages of BigInteger out of 
Fraction, use

> them only in BigFraction, and use the long-based ArithmeticUtils
methods to
> check for overflow and underflow in fraction addition and 
subtraction.

>
> Eric
>






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

Re: [numbers] Fraction() and Knuth 4.5.1 -- overflow, BigInteger, long, and rounding

[Eric Barnhill]

Here is what I propose for the Fraction doc text regarding this issue:

 * Implement add and subtract. This algorithm is similar to that
 * described in Knuth 4.5.1. while making some concessions to
 * performance. Note Knuth 4.5.1 Exercise 7, which observes that
 * adding two fractions with 32-bit numerators and denominators
 * requires 65 bits in extreme cases. Here calculations are performed
 * with 64-bit longs and the BigFraction class is recommended for
numbers
 * that may grow large enough to be in danger of overflow.


On Fri, Nov 9, 2018 at 4:33 PM Eric Barnhill  wrote:

> Addendum to the above. In an exercise in the Knuth book Knuth does indeed
> state that "If the inputs are n-bit binary numbers, 2N+1 bits may be
> necessary to represent t." where t is a derived quantity that would take
> some time to explain.
>
> So that means in extreme cases, the needed precision to represent a
> fraction operation with 32 bits ints is 65 bits, one more than a long has.
>
> The present code solves this by using BigInteger briefly in the code,
> which strikes me as an awfully big performance hit for what must surely be
> very occasional and very  extreme cases.
>
> I think the most sensible strategy would be to restrict the precision of
> Fraction to longs, with user guidance to use BigFraction if there is
> concern of overflow.
>
> Eric
>
>
>
>
>
>
>
> On Thu, Nov 8, 2018 at 11:11 AM Gary Gregory 
> wrote:
>
>> I'm all for the Javadoc made to reflect the reality of the code. It is
>> fine
>> to have an additional section that points out Knuth and how we may want to
>> change things as a hint or request to contributors.
>>
>> Gary
>>
>> On Wed, Nov 7, 2018 at 10:52 AM Eric Barnhill 
>> wrote:
>>
>> > I read Kunth's "Art of Computer Programming 4.5.1" that is referenced
>> many
>> > times in the doc as the guidance for the commons-math/commons-numbers
>> > Fraction class. It is an interesting read. Also, for all the times it is
>> > cited in the doc, it is interesting that Fraction doesn't really use it
>> as
>> > implemented. Here is one example.
>> >
>> > Knuth is concerned about overflow in multiplication and division,
>> because
>> > numerator of f1 is multiplied by denominator of f2 and so forth, so he
>> > suggests a technique called "mediant rounding" that allows for
>> intermediate
>> > quantities in fraction multiplication to be rounded.
>> >
>> > It is a clever technique and probably works well, however the current
>> > Fraction class cites this chapter, then implements multiplication with
>> > BigInteger instead, ignoring this suggestion.
>> >
>> > First of all, the doc should be clear that the code is NOT following
>> 4.5.1,
>> > while it gives the opposite impression. And that's ok but the use of
>> > BigInteger creates additional inconsistency: Multiply and divide are
>> > accomplished using ArithmeticUtils.addAndCheck and
>> > ArithmeticUtils.mulAndCheck . These convert the relevant ints to longs,
>> > then perform the operation, then if the resulting long is greater than
>> the
>> > range of an int, throw an OverflowException. So some parts of Fraction
>> > check for overflow using longs and others use BigInteger.
>> >
>> > It seems to me that BigInteger is overkill here for the vast majority of
>> > practical uses of Fraction in a way that could be damaging for
>> performance.
>> > And furthermore, we already have a BigFraction class to handle cases
>> that
>> > require BigInteger.
>> >
>> > So, I propose rewriting the doc to say the opposite of what it currently
>> > says when appropriate, and get usages of BigInteger out of Fraction, use
>> > them only in BigFraction, and use the long-based ArithmeticUtils
>> methods to
>> > check for overflow and underflow in fraction addition and subtraction.
>> >
>> > Eric
>> >
>>
>

[GitHub] commons-collections issue #63: [COLLECTIONS-707] Added PrefixMap - WIP!

[nielsbasjes]

Github user nielsbasjes commented on the issue:

https://github.com/apache/commons-collections/pull/63
  
Code coverage is now 100% of the new code.


---

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

Re: [IMAGING] Pull request

[Gilles]

Hi.

On Fri, 30 Nov 2018 14:00:52 +, Sukant Kumar wrote:

Hello Everyone,

I am Shukant Pal, look at my PR for Commons Imaging
https://github.com/apache/commons-imaging/pull/38. I want to get it
merged, how to do that?


A committer has to do it.
IIRC the main committer of [Imaging] (Bruno) is busy elsewhere
at the moment, so some patience will be necessary until someone
can review your contribution.

Best regards,
Gilles



Regards,

ShukantPal



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

[GitHub] commons-collections pull request #63: [COLLECTIONS-707] Added PrefixMap - WI...

[nielsbasjes]

GitHub user nielsbasjes opened a pull request:

https://github.com/apache/commons-collections/pull/63

[COLLECTIONS-707] Added PrefixMap - WIP!

First version of the PrefixMap implementation.
I consider this a work in progress and expect various review comments.

I have included two implementations of this interface:
- StringPrefixMap where any String can be used as prefix.
- ASCIIPrefixMap where only readable ASCII is allowed as the key. This 
restriction cuts the retrieval time in half and as such may be useful where 
speed is very important.

About the tests:
- I have to add more tests regarding special characters in the Prefix.
- Right now there are also a few very simple performance tests to verify 
the lookup speed. It may be needed to remove these before committing. 



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nielsbasjes/commons-collections 
COLLECTIONS-707-PrefixMap

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-collections/pull/63.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #63


commit aab3af5b3eba732b12d4a87a093a881d89723a56
Author: Niels Basjes 
Date:   2018-11-30T21:59:12Z

[COLLECTIONS-707] Added PrefixMap




---

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

Propose new type of collection: PrefixMap

[Niels Basjes]

Hi,

I was working on a project ( https://github.com/nielsbasjes/yauaa )
where I ran into the situation that I needed a type of collection that
was not yet present in either Java or commons-collections.

So I wrote my own implementation and I think this may be a useful
addition to commons-collections.

At this point we have
- the Map that allows retrieval of a single value based on an exact key.
- the Trie that allows retrieval of a set of values based where the
keys all start with the same prefix.

What I needed a structure where it holds the prefixes and associated
values and I want to retrieve the 'best matching prefix' for a given
input.

To illustrate what I mean using the original use case:
PrefixMap prefixMap = new ASCIIPrefixMap<>(false); // false ==
match case insensitive
prefixMap.put("SM-", "Samsung");
prefixMap.put("Mi-", "Xiaomi");
prefixMap.getLongestMatch("SM-1234"); // ---> "Samsung"

I propose to make a PrefixMap interface and then add the two
implementations I have created separately.

For now I have called this a PrefixMap and I want to know if you agree
this would be a useful addition.

-- 
Best regards / Met vriendelijke groeten,

Niels Basjes
Committer/PMC Apache Avro

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

Re: Modular version/edition of Apache Commons

[Gary Gregory]

Hi,

The best way to go IMO will be to get a GitHub account, fork the repo you
want, and create PRs from there.

All projects are rooted under https://github.com/apache/

For example https://github.com/apache/commons-logging

Gary

On Fri, Nov 30, 2018 at 8:01 AM Hannes H.  wrote:

> At the moment I am not even able to clone the git repository since I do not
> have sufficient credentials .. .do I need to register somewhere?
>
> Am Fr., 30. Nov. 2018 um 15:46 Uhr schrieb Gary Gregory <
> garydgreg...@gmail.com>:
>
> > Patches are always welcome :-)
> >
> > Gary
> >
> > On Fri, Nov 30, 2018, 07:44 Hannes H.  >
> > > My precise problem is that some Spring Framework modules reading
> classes
> > > from the package ' org.apache.commons.logging from both
> commons.logging'
> > > and so does 'commons.dbcp2' (which seems to be a module of DBCP). That
> is
> > > apparently a condition called "split package" which is not allowed in
> > > modularized code bases.
> > >
> > > The exact error message would be: 'Error:java: module commons.dbcp2
> reads
> > > package org.apache.commons.logging from both commons.logging and
> > > spring.jcl'.
> > >
> > > Hannes
> > >
> > >
> > > Am Fr., 30. Nov. 2018 um 15:26 Uhr schrieb Gilles <
> > > gil...@harfang.homelinux.org>:
> > >
> > > > On Fri, 30 Nov 2018 15:01:57 +0100, Hannes H. wrote:
> > > > > So there is no common approach planned for Apache Commons?
> > > >
> > > > Recently released components probably have an
> > > >   Automatic-Module-Name
> > > > defined for each artefact.
> > > >
> > > > Is there a precise question?
> > > > Do you have a suggestion?
> > > >
> > > >
> > > > Regards,
> > > > Gilles
> > > >
> > > > >
> > > > > Am Fr., 30. Nov. 2018 um 14:50 Uhr schrieb A. Soroka
> > > > > :
> > > > >
> > > > >>  Since each Commons component is released separately, each can
> have
> > > > >> its own
> > > > >> plan.
> > > > >>
> > > > >> ajs6f
> > > > >>
> > > > >> On Fri, Nov 30, 2018, 8:46 AM Hannes H.  > > > >>
> > > > >> > Hi,
> > > > >> >
> > > > >> > I am talking about Apache Commons in general and its approach to
> > > > >> Java
> > > > >> > modules which came with JDK 9 (project Jigsaw).
> > > > >> >
> > > > >> > Hannes
> > > > >> >
> > > > >> > Am Fr., 30. Nov. 2018 um 13:22 Uhr schrieb Gary Gregory <
> > > > >> > garydgreg...@gmail.com>:
> > > > >> >
> > > > >> > > Hi,
> > > > >> > >
> > > > >> > > Apache Common is a single project but is made up of Components
> > > > >> that are
> > > > >> > > developed and released individually.
> > > > >> > >
> > > > >> > > Can you be more specific? Which Components are you talking
> > > > >> about?
> > > > >> > >
> > > > >> > > Gary
> > > > >> > >
> > > > >> > > On Fri, Nov 30, 2018, 01:52 Hannes H.  wrote:
> > > > >> > >
> > > > >> > > > Good day,
> > > > >> > > >
> > > > >> > > > while migrating a code base which depends on Apache Commons
> > > > >> from
> > > > >> Java 8
> > > > >> > > to
> > > > >> > > > Java 11 the problem with 'split packages' crossed my efforts
> > > > >> to do
> > > > >> so.
> > > > >> > > >
> > > > >> > > > I did some research but I could not find anything, so I try
> by
> > > > >> asking
> > > > >> > > here:
> > > > >> > > > Is there a modularized version/edition of Apache Commons
> > > > >> available,
> > > > >> or
> > > > >> > is
> > > > >> > > > there a timeline until when this will be done?
> > > > >> > > >
> > > > >> > > > If not: Is there any suggestion on how to approach that
> > > > >> problem when
> > > > >> > > > migration to a newer, jigsaw-enabled JDK version?
> > > > >> > > >
> > > > >> > > > Thanks for your time and help,
> > > > >> > > > Hannes
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
> > > >
> > >
> >
>

Re: Modular version/edition of Apache Commons

[Bernd Eckenfels]

Hello,

The split package is a problem in spring.jcl not in Apache commons Logging. 
Also adding module info would unfortunately require a multi release JAR if it 
is supposed to be compatible with Java 8.

So I guess parallel release would be the solution (but it does not help with 
your problem). In your case you can just delete the Apache classes in the 
spring jar.

Gruß
Bernd

--
https://Bernd.eckenfels.net


Von: Hannes H. 
Gesendet: Freitag, November 30, 2018 4:01 PM
An: dev@commons.apache.org
Betreff: Re: Modular version/edition of Apache Commons

At the moment I am not even able to clone the git repository since I do not
have sufficient credentials .. .do I need to register somewhere?

Am Fr., 30. Nov. 2018 um 15:46 Uhr schrieb Gary Gregory <
garydgreg...@gmail.com>:

> Patches are always welcome :-)
>
> Gary
>
> On Fri, Nov 30, 2018, 07:44 Hannes H. 
> > My precise problem is that some Spring Framework modules reading classes
> > from the package ' org.apache.commons.logging from both commons.logging'
> > and so does 'commons.dbcp2' (which seems to be a module of DBCP). That is
> > apparently a condition called "split package" which is not allowed in
> > modularized code bases.
> >
> > The exact error message would be: 'Error:java: module commons.dbcp2 reads
> > package org.apache.commons.logging from both commons.logging and
> > spring.jcl'.
> >
> > Hannes
> >
> >
> > Am Fr., 30. Nov. 2018 um 15:26 Uhr schrieb Gilles <
> > gil...@harfang.homelinux.org>:
> >
> > > On Fri, 30 Nov 2018 15:01:57 +0100, Hannes H. wrote:
> > > > So there is no common approach planned for Apache Commons?
> > >
> > > Recently released components probably have an
> > > Automatic-Module-Name
> > > defined for each artefact.
> > >
> > > Is there a precise question?
> > > Do you have a suggestion?
> > >
> > >
> > > Regards,
> > > Gilles
> > >
> > > >
> > > > Am Fr., 30. Nov. 2018 um 14:50 Uhr schrieb A. Soroka
> > > > :
> > > >
> > > >> Since each Commons component is released separately, each can have
> > > >> its own
> > > >> plan.
> > > >>
> > > >> ajs6f
> > > >>
> > > >> On Fri, Nov 30, 2018, 8:46 AM Hannes H.  > > >>
> > > >> > Hi,
> > > >> >
> > > >> > I am talking about Apache Commons in general and its approach to
> > > >> Java
> > > >> > modules which came with JDK 9 (project Jigsaw).
> > > >> >
> > > >> > Hannes
> > > >> >
> > > >> > Am Fr., 30. Nov. 2018 um 13:22 Uhr schrieb Gary Gregory <
> > > >> > garydgreg...@gmail.com>:
> > > >> >
> > > >> > > Hi,
> > > >> > >
> > > >> > > Apache Common is a single project but is made up of Components
> > > >> that are
> > > >> > > developed and released individually.
> > > >> > >
> > > >> > > Can you be more specific? Which Components are you talking
> > > >> about?
> > > >> > >
> > > >> > > Gary
> > > >> > >
> > > >> > > On Fri, Nov 30, 2018, 01:52 Hannes H.  > > >> > >
> > > >> > > > Good day,
> > > >> > > >
> > > >> > > > while migrating a code base which depends on Apache Commons
> > > >> from
> > > >> Java 8
> > > >> > > to
> > > >> > > > Java 11 the problem with 'split packages' crossed my efforts
> > > >> to do
> > > >> so.
> > > >> > > >
> > > >> > > > I did some research but I could not find anything, so I try by
> > > >> asking
> > > >> > > here:
> > > >> > > > Is there a modularized version/edition of Apache Commons
> > > >> available,
> > > >> or
> > > >> > is
> > > >> > > > there a timeline until when this will be done?
> > > >> > > >
> > > >> > > > If not: Is there any suggestion on how to approach that
> > > >> problem when
> > > >> > > > migration to a newer, jigsaw-enabled JDK version?
> > > >> > > >
> > > >> > > > Thanks for your time and help,
> > > >> > > > Hannes
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
>

Re: Modular version/edition of Apache Commons

[Gilles]

On Fri, 30 Nov 2018 16:01:15 +0100, Hannes H. wrote:
At the moment I am not even able to clone the git repository since I 
do not

have sufficient credentials .. .do I need to register somewhere?


No.

Repository is:
  https://git-wip-us.apache.org/repos/asf?p=commons-dbcp.git

This command should work:
  $ git clone http://git-wip-us.apache.org/repos/asf/commons-dbcp.git

[If not, please file a bug report.]

Rgards,
Gilles




Am Fr., 30. Nov. 2018 um 15:46 Uhr schrieb Gary Gregory <
garydgreg...@gmail.com>:


Patches are always welcome :-)

Gary

On Fri, Nov 30, 2018, 07:44 Hannes H. > My precise problem is that some Spring Framework modules reading 
classes
> from the package ' org.apache.commons.logging from both 
commons.logging'
> and so does 'commons.dbcp2' (which seems to be a module of DBCP). 
That is
> apparently a condition called "split package" which is not allowed 
in

> modularized code bases.
>
> The exact error message would be: 'Error:java: module 
commons.dbcp2 reads

> package org.apache.commons.logging from both commons.logging and
> spring.jcl'.
>
> Hannes
>
>
> Am Fr., 30. Nov. 2018 um 15:26 Uhr schrieb Gilles <
> gil...@harfang.homelinux.org>:
>
> > On Fri, 30 Nov 2018 15:01:57 +0100, Hannes H. wrote:
> > > So there is no common approach planned for Apache Commons?
> >
> > Recently released components probably have an
> >   Automatic-Module-Name
> > defined for each artefact.
> >
> > Is there a precise question?
> > Do you have a suggestion?
> >
> >
> > Regards,
> > Gilles
> >
> > >
> > > Am Fr., 30. Nov. 2018 um 14:50 Uhr schrieb A. Soroka
> > > :
> > >
> > >>  Since each Commons component is released separately, each 
can have

> > >> its own
> > >> plan.
> > >>
> > >> ajs6f
> > >>
> > >> On Fri, Nov 30, 2018, 8:46 AM Hannes H. wrote:

> > >>
> > >> > Hi,
> > >> >
> > >> > I am talking about Apache Commons in general and its 
approach to

> > >> Java
> > >> > modules which came with JDK 9 (project Jigsaw).
> > >> >
> > >> > Hannes
> > >> >
> > >> > Am Fr., 30. Nov. 2018 um 13:22 Uhr schrieb Gary Gregory <
> > >> > garydgreg...@gmail.com>:
> > >> >
> > >> > > Hi,
> > >> > >
> > >> > > Apache Common is a single project but is made up of 
Components

> > >> that are
> > >> > > developed and released individually.
> > >> > >
> > >> > > Can you be more specific? Which Components are you 
talking

> > >> about?
> > >> > >
> > >> > > Gary
> > >> > >
> > >> > > On Fri, Nov 30, 2018, 01:52 Hannes H. wrote:

> > >> > >
> > >> > > > Good day,
> > >> > > >
> > >> > > > while migrating a code base which depends on Apache 
Commons

> > >> from
> > >> Java 8
> > >> > > to
> > >> > > > Java 11 the problem with 'split packages' crossed my 
efforts

> > >> to do
> > >> so.
> > >> > > >
> > >> > > > I did some research but I could not find anything, so I 
try by

> > >> asking
> > >> > > here:
> > >> > > > Is there a modularized version/edition of Apache 
Commons

> > >> available,
> > >> or
> > >> > is
> > >> > > > there a timeline until when this will be done?
> > >> > > >
> > >> > > > If not: Is there any suggestion on how to approach that
> > >> problem when
> > >> > > > migration to a newer, jigsaw-enabled JDK version?
> > >> > > >
> > >> > > > Thanks for your time and help,
> > >> > > > Hannes
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> >
> > 
-

> > 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: Modular version/edition of Apache Commons

[Hannes H.]

At the moment I am not even able to clone the git repository since I do not
have sufficient credentials .. .do I need to register somewhere?

Am Fr., 30. Nov. 2018 um 15:46 Uhr schrieb Gary Gregory <
garydgreg...@gmail.com>:

> Patches are always welcome :-)
>
> Gary
>
> On Fri, Nov 30, 2018, 07:44 Hannes H. 
> > My precise problem is that some Spring Framework modules reading classes
> > from the package ' org.apache.commons.logging from both commons.logging'
> > and so does 'commons.dbcp2' (which seems to be a module of DBCP). That is
> > apparently a condition called "split package" which is not allowed in
> > modularized code bases.
> >
> > The exact error message would be: 'Error:java: module commons.dbcp2 reads
> > package org.apache.commons.logging from both commons.logging and
> > spring.jcl'.
> >
> > Hannes
> >
> >
> > Am Fr., 30. Nov. 2018 um 15:26 Uhr schrieb Gilles <
> > gil...@harfang.homelinux.org>:
> >
> > > On Fri, 30 Nov 2018 15:01:57 +0100, Hannes H. wrote:
> > > > So there is no common approach planned for Apache Commons?
> > >
> > > Recently released components probably have an
> > >   Automatic-Module-Name
> > > defined for each artefact.
> > >
> > > Is there a precise question?
> > > Do you have a suggestion?
> > >
> > >
> > > Regards,
> > > Gilles
> > >
> > > >
> > > > Am Fr., 30. Nov. 2018 um 14:50 Uhr schrieb A. Soroka
> > > > :
> > > >
> > > >>  Since each Commons component is released separately, each can have
> > > >> its own
> > > >> plan.
> > > >>
> > > >> ajs6f
> > > >>
> > > >> On Fri, Nov 30, 2018, 8:46 AM Hannes H.  > > >>
> > > >> > Hi,
> > > >> >
> > > >> > I am talking about Apache Commons in general and its approach to
> > > >> Java
> > > >> > modules which came with JDK 9 (project Jigsaw).
> > > >> >
> > > >> > Hannes
> > > >> >
> > > >> > Am Fr., 30. Nov. 2018 um 13:22 Uhr schrieb Gary Gregory <
> > > >> > garydgreg...@gmail.com>:
> > > >> >
> > > >> > > Hi,
> > > >> > >
> > > >> > > Apache Common is a single project but is made up of Components
> > > >> that are
> > > >> > > developed and released individually.
> > > >> > >
> > > >> > > Can you be more specific? Which Components are you talking
> > > >> about?
> > > >> > >
> > > >> > > Gary
> > > >> > >
> > > >> > > On Fri, Nov 30, 2018, 01:52 Hannes H.  > > >> > >
> > > >> > > > Good day,
> > > >> > > >
> > > >> > > > while migrating a code base which depends on Apache Commons
> > > >> from
> > > >> Java 8
> > > >> > > to
> > > >> > > > Java 11 the problem with 'split packages' crossed my efforts
> > > >> to do
> > > >> so.
> > > >> > > >
> > > >> > > > I did some research but I could not find anything, so I try by
> > > >> asking
> > > >> > > here:
> > > >> > > > Is there a modularized version/edition of Apache Commons
> > > >> available,
> > > >> or
> > > >> > is
> > > >> > > > there a timeline until when this will be done?
> > > >> > > >
> > > >> > > > If not: Is there any suggestion on how to approach that
> > > >> problem when
> > > >> > > > migration to a newer, jigsaw-enabled JDK version?
> > > >> > > >
> > > >> > > > Thanks for your time and help,
> > > >> > > > Hannes
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
>

Re: Where's Rob been the last few weeks?

[Gary Gregory]

Ah, a Task Attack! ;-)

Good luck and thank you for the update.

Gary

On Fri, Nov 30, 2018, 05:30 Rob Tompkins  I’ve been tasked with taking something to production at my day job using
> the newest internal processes with a deadline of EOY. And, there’s just a
> lot to do for that. So I’ve been fairly heavily distracted in that zone.
>
> Just trying to keep everyone in the loop.
>
> -Rob
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Modular version/edition of Apache Commons

[Gary Gregory]

Patches are always welcome :-)

Gary

On Fri, Nov 30, 2018, 07:44 Hannes H.  My precise problem is that some Spring Framework modules reading classes
> from the package ' org.apache.commons.logging from both commons.logging'
> and so does 'commons.dbcp2' (which seems to be a module of DBCP). That is
> apparently a condition called "split package" which is not allowed in
> modularized code bases.
>
> The exact error message would be: 'Error:java: module commons.dbcp2 reads
> package org.apache.commons.logging from both commons.logging and
> spring.jcl'.
>
> Hannes
>
>
> Am Fr., 30. Nov. 2018 um 15:26 Uhr schrieb Gilles <
> gil...@harfang.homelinux.org>:
>
> > On Fri, 30 Nov 2018 15:01:57 +0100, Hannes H. wrote:
> > > So there is no common approach planned for Apache Commons?
> >
> > Recently released components probably have an
> >   Automatic-Module-Name
> > defined for each artefact.
> >
> > Is there a precise question?
> > Do you have a suggestion?
> >
> >
> > Regards,
> > Gilles
> >
> > >
> > > Am Fr., 30. Nov. 2018 um 14:50 Uhr schrieb A. Soroka
> > > :
> > >
> > >>  Since each Commons component is released separately, each can have
> > >> its own
> > >> plan.
> > >>
> > >> ajs6f
> > >>
> > >> On Fri, Nov 30, 2018, 8:46 AM Hannes H.  > >>
> > >> > Hi,
> > >> >
> > >> > I am talking about Apache Commons in general and its approach to
> > >> Java
> > >> > modules which came with JDK 9 (project Jigsaw).
> > >> >
> > >> > Hannes
> > >> >
> > >> > Am Fr., 30. Nov. 2018 um 13:22 Uhr schrieb Gary Gregory <
> > >> > garydgreg...@gmail.com>:
> > >> >
> > >> > > Hi,
> > >> > >
> > >> > > Apache Common is a single project but is made up of Components
> > >> that are
> > >> > > developed and released individually.
> > >> > >
> > >> > > Can you be more specific? Which Components are you talking
> > >> about?
> > >> > >
> > >> > > Gary
> > >> > >
> > >> > > On Fri, Nov 30, 2018, 01:52 Hannes H.  > >> > >
> > >> > > > Good day,
> > >> > > >
> > >> > > > while migrating a code base which depends on Apache Commons
> > >> from
> > >> Java 8
> > >> > > to
> > >> > > > Java 11 the problem with 'split packages' crossed my efforts
> > >> to do
> > >> so.
> > >> > > >
> > >> > > > I did some research but I could not find anything, so I try by
> > >> asking
> > >> > > here:
> > >> > > > Is there a modularized version/edition of Apache Commons
> > >> available,
> > >> or
> > >> > is
> > >> > > > there a timeline until when this will be done?
> > >> > > >
> > >> > > > If not: Is there any suggestion on how to approach that
> > >> problem when
> > >> > > > migration to a newer, jigsaw-enabled JDK version?
> > >> > > >
> > >> > > > Thanks for your time and help,
> > >> > > > Hannes
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: Modular version/edition of Apache Commons

[Hannes H.]

My precise problem is that some Spring Framework modules reading classes
from the package ' org.apache.commons.logging from both commons.logging'
and so does 'commons.dbcp2' (which seems to be a module of DBCP). That is
apparently a condition called "split package" which is not allowed in
modularized code bases.

The exact error message would be: 'Error:java: module commons.dbcp2 reads
package org.apache.commons.logging from both commons.logging and
spring.jcl'.

Hannes


Am Fr., 30. Nov. 2018 um 15:26 Uhr schrieb Gilles <
gil...@harfang.homelinux.org>:

> On Fri, 30 Nov 2018 15:01:57 +0100, Hannes H. wrote:
> > So there is no common approach planned for Apache Commons?
>
> Recently released components probably have an
>   Automatic-Module-Name
> defined for each artefact.
>
> Is there a precise question?
> Do you have a suggestion?
>
>
> Regards,
> Gilles
>
> >
> > Am Fr., 30. Nov. 2018 um 14:50 Uhr schrieb A. Soroka
> > :
> >
> >>  Since each Commons component is released separately, each can have
> >> its own
> >> plan.
> >>
> >> ajs6f
> >>
> >> On Fri, Nov 30, 2018, 8:46 AM Hannes H.  >>
> >> > Hi,
> >> >
> >> > I am talking about Apache Commons in general and its approach to
> >> Java
> >> > modules which came with JDK 9 (project Jigsaw).
> >> >
> >> > Hannes
> >> >
> >> > Am Fr., 30. Nov. 2018 um 13:22 Uhr schrieb Gary Gregory <
> >> > garydgreg...@gmail.com>:
> >> >
> >> > > Hi,
> >> > >
> >> > > Apache Common is a single project but is made up of Components
> >> that are
> >> > > developed and released individually.
> >> > >
> >> > > Can you be more specific? Which Components are you talking
> >> about?
> >> > >
> >> > > Gary
> >> > >
> >> > > On Fri, Nov 30, 2018, 01:52 Hannes H.  >> > >
> >> > > > Good day,
> >> > > >
> >> > > > while migrating a code base which depends on Apache Commons
> >> from
> >> Java 8
> >> > > to
> >> > > > Java 11 the problem with 'split packages' crossed my efforts
> >> to do
> >> so.
> >> > > >
> >> > > > I did some research but I could not find anything, so I try by
> >> asking
> >> > > here:
> >> > > > Is there a modularized version/edition of Apache Commons
> >> available,
> >> or
> >> > is
> >> > > > there a timeline until when this will be done?
> >> > > >
> >> > > > If not: Is there any suggestion on how to approach that
> >> problem when
> >> > > > migration to a newer, jigsaw-enabled JDK version?
> >> > > >
> >> > > > Thanks for your time and help,
> >> > > > Hannes
> >> > > >
> >> > >
> >> >
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [numbers] Making Quaternion a VALJO

[Gilles]

On Fri, 30 Nov 2018 14:22:45 +, Steve Bosman wrote:

> and I have also emailed an ICLA.



Not received/acknowledged yet.


I am now listed on the "Persons with signed CLAs but who are not 
(yet)

committers." page.


Welcome!

> I think two convenience divide methods performing qr^{-1} and 
r^{-1}q

> for q
> and r would be useful, but I couldn't think of nice names for 
them.



What are the use-cases?
Why aren't "multiply" and "inverse" enough?


I must admit I'm new to quaternions and stumbled into the project 
while

trying to improve my understanding so I'm not going to claim great
knowledge of how common these operations are. I was primarily 
thinking of
Quaternion Interpolation - SLERP and SQUAD. It seems to me that you 
end up
creating inverse instances and throwing them away a lot and I thought 
it

would be good to reduce that overhead.


Surely, the class "Quaternion" is minimal but, before adding to
the API, we be careful to have use-cases for low-level operations.
Those mentioned above seems more high-level, tied to a specific
domain (see also "Commons Geometry", another new component not yet
released) but I may be wrong...

Regards,
Gilles



Steve



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

Re: Modular version/edition of Apache Commons

[Gilles]

On Fri, 30 Nov 2018 15:01:57 +0100, Hannes H. wrote:

So there is no common approach planned for Apache Commons?


Recently released components probably have an
 Automatic-Module-Name
defined for each artefact.

Is there a precise question?
Do you have a suggestion?


Regards,
Gilles



Am Fr., 30. Nov. 2018 um 14:50 Uhr schrieb A. Soroka 
:


 Since each Commons component is released separately, each can have 
its own

plan.

ajs6f

On Fri, Nov 30, 2018, 8:46 AM Hannes H.  Hi,
>
> I am talking about Apache Commons in general and its approach to 
Java

> modules which came with JDK 9 (project Jigsaw).
>
> Hannes
>
> Am Fr., 30. Nov. 2018 um 13:22 Uhr schrieb Gary Gregory <
> garydgreg...@gmail.com>:
>
> > Hi,
> >
> > Apache Common is a single project but is made up of Components 
that are

> > developed and released individually.
> >
> > Can you be more specific? Which Components are you talking 
about?

> >
> > Gary
> >
> > On Fri, Nov 30, 2018, 01:52 Hannes H.  >
> > > Good day,
> > >
> > > while migrating a code base which depends on Apache Commons 
from

Java 8
> > to
> > > Java 11 the problem with 'split packages' crossed my efforts 
to do

so.
> > >
> > > I did some research but I could not find anything, so I try by 
asking

> > here:
> > > Is there a modularized version/edition of Apache Commons 
available,

or
> is
> > > there a timeline until when this will be done?
> > >
> > > If not: Is there any suggestion on how to approach that 
problem when

> > > migration to a newer, jigsaw-enabled JDK version?
> > >
> > > Thanks for your time and help,
> > > Hannes
> > >
> >
>




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

Re: [numbers] Making Quaternion a VALJO

[Steve Bosman]

> > and I have also emailed an ICLA.

> Not received/acknowledged yet.

I am now listed on the "Persons with signed CLAs but who are not (yet)
committers." page.

> > I think two convenience divide methods performing qr^{-1} and r^{-1}q
> > for q
> > and r would be useful, but I couldn't think of nice names for them.

> What are the use-cases?
> Why aren't "multiply" and "inverse" enough?

I must admit I'm new to quaternions and stumbled into the project while
trying to improve my understanding so I'm not going to claim great
knowledge of how common these operations are. I was primarily thinking of
Quaternion Interpolation - SLERP and SQUAD. It seems to me that you end up
creating inverse instances and throwing them away a lot and I thought it
would be good to reduce that overhead.

Steve

Re: Modular version/edition of Apache Commons

[Hannes H.]

So there is no common approach planned for Apache Commons?

Am Fr., 30. Nov. 2018 um 14:50 Uhr schrieb A. Soroka :

>  Since each Commons component is released separately, each can have its own
> plan.
>
> ajs6f
>
> On Fri, Nov 30, 2018, 8:46 AM Hannes H. 
> > Hi,
> >
> > I am talking about Apache Commons in general and its approach to Java
> > modules which came with JDK 9 (project Jigsaw).
> >
> > Hannes
> >
> > Am Fr., 30. Nov. 2018 um 13:22 Uhr schrieb Gary Gregory <
> > garydgreg...@gmail.com>:
> >
> > > Hi,
> > >
> > > Apache Common is a single project but is made up of Components that are
> > > developed and released individually.
> > >
> > > Can you be more specific? Which Components are you talking about?
> > >
> > > Gary
> > >
> > > On Fri, Nov 30, 2018, 01:52 Hannes H.  > >
> > > > Good day,
> > > >
> > > > while migrating a code base which depends on Apache Commons from
> Java 8
> > > to
> > > > Java 11 the problem with 'split packages' crossed my efforts to do
> so.
> > > >
> > > > I did some research but I could not find anything, so I try by asking
> > > here:
> > > > Is there a modularized version/edition of Apache Commons available,
> or
> > is
> > > > there a timeline until when this will be done?
> > > >
> > > > If not: Is there any suggestion on how to approach that problem when
> > > > migration to a newer, jigsaw-enabled JDK version?
> > > >
> > > > Thanks for your time and help,
> > > > Hannes
> > > >
> > >
> >
>

[IMAGING] Pull request

[Sukant Kumar]

Hello Everyone,

I am Shukant Pal, look at my PR for Commons Imaging 
https://github.com/apache/commons-imaging/pull/38. I want to get it 
merged, how to do that?

Regards,

ShukantPal

Re: Modular version/edition of Apache Commons

[ajs6f]

Since each Commons component is released separately, each can have its own
plan.

ajs6f


> On Fri, Nov 30, 2018, 8:46 AM Hannes H. 
>> Hi,
>>
>> I am talking about Apache Commons in general and its approach to Java
>> modules which came with JDK 9 (project Jigsaw).
>>
>> Hannes
>>
>> Am Fr., 30. Nov. 2018 um 13:22 Uhr schrieb Gary Gregory <
>> garydgreg...@gmail.com>:
>>
>> > Hi,
>> >
>> > Apache Common is a single project but is made up of Components that are
>> > developed and released individually.
>> >
>> > Can you be more specific? Which Components are you talking about?
>> >
>> > Gary
>> >
>> > On Fri, Nov 30, 2018, 01:52 Hannes H. > >
>> > > Good day,
>> > >
>> > > while migrating a code base which depends on Apache Commons from Java
>> 8
>> > to
>> > > Java 11 the problem with 'split packages' crossed my efforts to do so.
>> > >
>> > > I did some research but I could not find anything, so I try by asking
>> > here:
>> > > Is there a modularized version/edition of Apache Commons available,
>> or is
>> > > there a timeline until when this will be done?
>> > >
>> > > If not: Is there any suggestion on how to approach that problem when
>> > > migration to a newer, jigsaw-enabled JDK version?
>> > >
>> > > Thanks for your time and help,
>> > > Hannes
>> > >
>> >
>>
>

Re: Modular version/edition of Apache Commons

[A. Soroka]

 Since each Commons component is released separately, each can have its own
plan.

ajs6f

On Fri, Nov 30, 2018, 8:46 AM Hannes H.  Hi,
>
> I am talking about Apache Commons in general and its approach to Java
> modules which came with JDK 9 (project Jigsaw).
>
> Hannes
>
> Am Fr., 30. Nov. 2018 um 13:22 Uhr schrieb Gary Gregory <
> garydgreg...@gmail.com>:
>
> > Hi,
> >
> > Apache Common is a single project but is made up of Components that are
> > developed and released individually.
> >
> > Can you be more specific? Which Components are you talking about?
> >
> > Gary
> >
> > On Fri, Nov 30, 2018, 01:52 Hannes H.  >
> > > Good day,
> > >
> > > while migrating a code base which depends on Apache Commons from Java 8
> > to
> > > Java 11 the problem with 'split packages' crossed my efforts to do so.
> > >
> > > I did some research but I could not find anything, so I try by asking
> > here:
> > > Is there a modularized version/edition of Apache Commons available, or
> is
> > > there a timeline until when this will be done?
> > >
> > > If not: Is there any suggestion on how to approach that problem when
> > > migration to a newer, jigsaw-enabled JDK version?
> > >
> > > Thanks for your time and help,
> > > Hannes
> > >
> >
>

Re: Modular version/edition of Apache Commons

[Hannes H.]

Hi,

I am talking about Apache Commons in general and its approach to Java
modules which came with JDK 9 (project Jigsaw).

Hannes

Am Fr., 30. Nov. 2018 um 13:22 Uhr schrieb Gary Gregory <
garydgreg...@gmail.com>:

> Hi,
>
> Apache Common is a single project but is made up of Components that are
> developed and released individually.
>
> Can you be more specific? Which Components are you talking about?
>
> Gary
>
> On Fri, Nov 30, 2018, 01:52 Hannes H. 
> > Good day,
> >
> > while migrating a code base which depends on Apache Commons from Java 8
> to
> > Java 11 the problem with 'split packages' crossed my efforts to do so.
> >
> > I did some research but I could not find anything, so I try by asking
> here:
> > Is there a modularized version/edition of Apache Commons available, or is
> > there a timeline until when this will be done?
> >
> > If not: Is there any suggestion on how to approach that problem when
> > migration to a newer, jigsaw-enabled JDK version?
> >
> > Thanks for your time and help,
> > Hannes
> >
>

JDK 12 build 22 is now available at : - jdk.java.net/12/

[Rory O'Donnell]

Hi Benedikt,

*NOTE:- *The JDK 12 schedule  
rampdown phase 1 of the release is coming up in a few weeks on Dec. 13, 
2018.


**

*JDK 12 Early Access build 22 **is now available **at : - jdk.java.net/12/*

 * Release Note updates since last email *
   *
 o Build 21 - Deprecating the default keytool -keyalg value
   (JDK-8212003)
 o Build 21 - Change to X25519 and X448 encoded private key format
   (JDK-8213363)
 o Build 20 - New command-line flag for more extensive error
   reporting in crash logs  (JDK-8211845)
 o Build 20 -Initial Value of user.timezone System Property Changed
   (JDK-8185496)

 * JEPs proposed for JDK 12 :
 o JEP 189: Shenandoah: A Low-Pause-Time Garbage
   Collector(Experimental) 
 o JEP 334: JVM Constants API 
 o JEP 344: Abortable Mixed Collections for G1
   
 o JEP 346: Promptly Return Unused Committed Memory from G1
   

 * JEPs targeted to JDK 12, so far
 o JEP 230: Microbenchmark Suite 
 o JEP 325: Switch Expressions (Preview)
   
 o JEP 326: Raw String Literals (Preview)
   
 o JEP 340: One AArch64 Port, Not Two
   
 o JEP 341: Default CDS Archives 

Rgds,Rory

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

Where's Rob been the last few weeks?

[Rob Tompkins]

I’ve been tasked with taking something to production at my day job using the 
newest internal processes with a deadline of EOY. And, there’s just a lot to do 
for that. So I’ve been fairly heavily distracted in that zone.

Just trying to keep everyone in the loop.

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

Re: Modular version/edition of Apache Commons

[Gary Gregory]

Hi,

Apache Common is a single project but is made up of Components that are
developed and released individually.

Can you be more specific? Which Components are you talking about?

Gary

On Fri, Nov 30, 2018, 01:52 Hannes H.  Good day,
>
> while migrating a code base which depends on Apache Commons from Java 8 to
> Java 11 the problem with 'split packages' crossed my efforts to do so.
>
> I did some research but I could not find anything, so I try by asking here:
> Is there a modularized version/edition of Apache Commons available, or is
> there a timeline until when this will be done?
>
> If not: Is there any suggestion on how to approach that problem when
> migration to a newer, jigsaw-enabled JDK version?
>
> Thanks for your time and help,
> Hannes
>

Modular version/edition of Apache Commons

[Hannes H.]

Good day,

while migrating a code base which depends on Apache Commons from Java 8 to
Java 11 the problem with 'split packages' crossed my efforts to do so.

I did some research but I could not find anything, so I try by asking here:
Is there a modularized version/edition of Apache Commons available, or is
there a timeline until when this will be done?

If not: Is there any suggestion on how to approach that problem when
migration to a newer, jigsaw-enabled JDK version?

Thanks for your time and help,
Hannes