Le 29/09/2016 à 12:23, Gilles a écrit :
>> And multiple projects would hypothetically ease one migration every five
>> years?
>
> This would happen for _every_ release.
How do you come to this conclusion? We are talking about an incompatible
update, the kind of update that forces to change the n
I think this is a good idea. It might even be more "generic" to indicate why it
includes adaptor methods. The Banana RDF effort actually uses typeclasses with
names like RDF and RDFOps.
---
A. Soroka
Committer/PMC Apache Jena
On 2016-09-15 07:11 (-0400), Stian Soiland-Reyes wrote:
> Hi,
>
>
On Thu, 29 Sep 2016 12:19:44 +0200, Emmanuel Bourg wrote:
Le 29/09/2016 à 12:12, er...@apache.org a écrit :
+
+Commons RNG is intended to be a repository of pure Java
implementations of
+random number generators that produce deterministic
sequences.
+The current
On Thu, 29 Sep 2016 14:41:11 +0300, Artem Barger wrote:
On Thu, Sep 29, 2016 at 1:48 PM, Stian Soiland-Reyes
wrote:
A good question is - if rng-core changes - would the other modules
need to change as well? If not, then there's not a big reason why
they
need to be together in the same proje
On Thu, 29 Sep 2016 13:40:08 +0300, Artem Barger wrote:
Hi,
What you are arguing here is that if "some-lib" is
upgraded, then the JDK must change version too!
Does that (extreme) comparison make the issue clearer?
I agree that the mixing of versions, even if allowed,
is not the best choice;
On Thu, Sep 29, 2016 at 1:48 PM, Stian Soiland-Reyes
wrote:
> A good question is - if rng-core changes - would the other modules
> need to change as well? If not, then there's not a big reason why they
> need to be together in the same project (but we would end up with
> Commons Commons Component
Having all modules in the project have the same is just a convention.
It could make sense to increment the rng-core module more slowly,
while still allowing it in the build.
For instance:
commons-rng 1.2.0 could include:
rng-core 1.1.2 (nothing actually changed, but we can't re-deploy 1.1.1)
Hi,
On Thu, Sep 29, 2016 at 1:06 PM, Emmanuel Bourg wrote:
>
> >> Multi-module projects are quite common and the case you mention isn't
> >> unusual.
> >
> > Please show an example.
>
> Spring, Jetty, Jackson, Log4j, Hadoop, Lucene, Maven, Hipparchus...
> There is no lack of examples. Multi-
Le 29/09/2016 à 12:12, er...@apache.org a écrit :
> +
> +Commons RNG is intended to be a repository of pure Java
> implementations of
> +random number generators that produce deterministic sequences.
> +The current design has made no provision for features generally
On Thu, 29 Sep 2016 12:06:36 +0200, Emmanuel Bourg wrote:
Le 28/09/2016 à 15:58, Gilles a écrit :
Multi-module projects are quite common and the case you mention
isn't
unusual.
Please show an example.
Spring, Jetty, Jackson, Log4j, Hadoop, Lucene, Maven, Hipparchus...
There is no lack of e
Le 28/09/2016 à 15:58, Gilles a écrit :
>> Multi-module projects are quite common and the case you mention isn't
>> unusual.
>
> Please show an example.
Spring, Jetty, Jackson, Log4j, Hadoop, Lucene, Maven, Hipparchus...
There is no lack of examples. Multi-module projects routinely publish
new r
On Thu, 29 Sep 2016 10:55:07 +0200, Emmanuel Bourg wrote:
Le 29/09/2016 à 01:37, Gilles a écrit :
The more so that the issue was encountered by several people
in different components, and IIRC now, the consensus (or
workaround) had been to indeed disable "doclint".
This is a wise workaround,
Le 29/09/2016 à 01:37, Gilles a écrit :
> The more so that the issue was encountered by several people
> in different components, and IIRC now, the consensus (or
> workaround) had been to indeed disable "doclint".
This is a wise workaround, fixing old Javadocs is a waste of time, but
it isn't for
Le 29/09/2016 à 02:55, Brent Worden a écrit :
> If it is only used by RandomSource, would making ProviderBuilder a private,
> inner class provide better isolation and further prevent misuse?
>From a user point of view this would make no difference. A separate
package private class is as good as a
14 matches
Mail list logo
