Re: [VOTE][LAZY] Migrate Apache Commons DBCP to Git

[Gary Gregory]

+1

Gary

On Tue, Aug 16, 2016 at 7:00 PM, Matt Sicker  wrote:

> I'd like to call a VOTE by LAZY consensus to migrate dbcp to git. The 2.2
> release process is currently on hold, so I'd like to take this opportunity
> to migrate from svn to git. If there are no objections to migrating, this
> vote will pass in 72 hours (19 Aug 2016, 21:00 CDT).
>
> --
> Matt Sicker 
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[VOTE][LAZY] Migrate Apache Commons DBCP to Git

[Matt Sicker]

I'd like to call a VOTE by LAZY consensus to migrate dbcp to git. The 2.2
release process is currently on hold, so I'd like to take this opportunity
to migrate from svn to git. If there are no objections to migrating, this
vote will pass in 72 hours (19 Aug 2016, 21:00 CDT).

-- 
Matt Sicker 

Re: [rng] JARs with different dependencies within the same component?

[Jörg Schaible]

Gilles wrote:

> On Tue, 16 Aug 2016 15:53:44 +0300, Artem Barger wrote:
>> On Tue, Aug 16, 2016 at 3:00 PM, Gilles
>> 
>> wrote:
>>
>>> That's what I was afraid of; in this case, it would defeat the
>>> purpose:
>>> We shouldn't have to release "core-2.0" (thus a with change of the
>>> top-level package name), just because we want to fix something in
>>> the
>>> "utils" code.
>>>
>>> Given this situation, would it be possible to consider a separate
>>> component: "commons-rng-utils"?
>>>
>>
>> I think following layout should actually work:
>>
>> commons-rng-parent (pom) v1.0
>> |commons-rng-core (jar) v1.0
>> |commons-rng-tools (jar) v1.0​
>>
>> ​And suppose you want to update commong-rng-tools from v1.0 to v2.0
>> it will
>> look like:​
>>
>> commons-rng-parent (pom) v1.1
>> |commons-rng-core (jar) v1.0
>> |commons-rng-tools (jar) v2.0​
>>
>> ​where you do not really have to touch version of core component.
>> Unless
>> this is somehow
>> restricted by ASF commons coding standards or something.​
> 
> The restriction, as Jörg wrote, is that a single component can only
> release artifacts with the same version.

It's also the tooling. What should Maven tag for a release?

> If we have to put the tools in a separate component, it will already
> inherit from "commons-parent". Then, is there an interest to define
> an additional "commons-rng-parent" level.

I don't think you'd gain something for an additional parent. What would it 
contain?

Cheers,
Jörg


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

Re: [RESULT][VOTE] Release Configuration 2.1 based on RC3

[Gary Gregory]

You can wait and ask for more reviews too...

Gary

On Tue, Aug 16, 2016 at 12:40 PM, Oliver Heger  wrote:

> The vote to release Configuration 2.1 based on RC3 failed with the
> following binding votes:
>
> Gary Gregory:   -1
> Jörg Schaible:  +1
> Oliver Heger:   +1
>
> Oliver
>
> Am 11.08.2016 um 22:02 schrieb Oliver Heger:
> > Hi all,
> >
> > after the failed votes for RC1 and RC2 a new RC has been created. There
> > has been further tweaking of the checkstyle configuration to solve build
> > problems on Java 1.6.
> >
> > Configuration 2.1 RC3 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/configuration
> > (revision 14770)
> >
> > Maven artifacts are here:
> >
> > https://repository.apache.org/content/repositories/
> orgapachecommons-1197/
> >
> > Details of changes since 2.0 are in the release notes:
> >
> > https://dist.apache.org/repos/dist/dev/commons/
> configuration/RELEASE-NOTES.txt
> >
> > https://home.apache.org/~oheger/configuration-2.1-rc3/
> changes-report.html
> >
> > Here is the tag:
> >
> > http://svn.apache.org/repos/asf/commons/proper/configuration/tags/
> CONFIGURATION_2_1_RC3
> > (revision 1755836)
> >
> > Site:
> >https://home.apache.org/~oheger/configuration-2.1-rc3/
> > (note some links in the menu are not yet working)
> >
> > KEYS:
> >   http://www.apache.org/dist/commons/KEYS
> >
> > Please review the release candidate and vote.
> > This vote will close no sooner than 72 hours from now, i.e. after 2000
> > GMT 14-Aug-2016
> >
> >   [ ] +1 Release these artifacts
> >   [ ] +0 OK, but...
> >   [ ] -0 OK, but really should fix...
> >   [ ] -1 I oppose this release because...
> >
> > Thanks!
> > Oliver
> >
> >
> >
> > -
> > 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
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [rng] JARs with different dependencies within the same component?

[Gilles]

On Wed, 17 Aug 2016 00:01:14 +0300, Artem Barger wrote:
On Tue, Aug 16, 2016 at 6:49 PM, Gilles 


wrote:



The restriction, as Jörg wrote, is that a single component can only
release artifacts with the same version.



​Ok, I think this is very common practice, as far as I recall 
correctly

same
thing also happens in many other open source projects, Spring could 
be an
example out of head. So even if you haven't changes in rng-core it 
make

sense to align its release cycle w/ rng-tools.


-1

It doesn't make sense to release an unchanged codebase just because
tools that depend on it have changed!

If one has to do that, there is absolutely zero advantage in having
separate JARs.

The only way out is to create a separate project to collect the tools.
Thus I propose to drop that discussion out of the "[rng]" threads.
We can experiment with this (higher-level API, add-ons) within the
Commons Math repository.
There, it will be useful to think in terms of multiple modules as a
first step toward multiple components (or TLP).  For example, I guess
that the contents of package "o.a.c.math4.random" could lead to a
separate JAR (functionally equivalent to "commons-rng-utils").

Regards,
Gilles





Best regards,
  Artem Barger.



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

Re: [rng] JARs with different dependencies within the same component?

[Artem Barger]

On Tue, Aug 16, 2016 at 6:49 PM, Gilles 
wrote:

>
> The restriction, as Jörg wrote, is that a single component can only
> release artifacts with the same version.


​Ok, I think this is very common practice, as far as I recall correctly
same
thing also happens in many other open source projects, Spring could be an
example out of head. So even if you haven't changes in rng-core it make
sense to align its release cycle w/ rng-tools.


Best regards,
  Artem Barger.

[RESULT][VOTE] Release Configuration 2.1 based on RC3

[Oliver Heger]

The vote to release Configuration 2.1 based on RC3 failed with the
following binding votes:

Gary Gregory:   -1
Jörg Schaible:  +1
Oliver Heger:   +1

Oliver  

Am 11.08.2016 um 22:02 schrieb Oliver Heger:
> Hi all,
> 
> after the failed votes for RC1 and RC2 a new RC has been created. There
> has been further tweaking of the checkstyle configuration to solve build
> problems on Java 1.6.
> 
> Configuration 2.1 RC3 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/configuration
> (revision 14770)
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1197/
> 
> Details of changes since 2.0 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/configuration/RELEASE-NOTES.txt
> 
> https://home.apache.org/~oheger/configuration-2.1-rc3/changes-report.html
> 
> Here is the tag:
> 
> http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_2_1_RC3
> (revision 1755836)
> 
> Site:
>https://home.apache.org/~oheger/configuration-2.1-rc3/
> (note some links in the menu are not yet working)
> 
> KEYS:
>   http://www.apache.org/dist/commons/KEYS
> 
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now, i.e. after 2000
> GMT 14-Aug-2016
> 
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
> 
> Thanks!
> Oliver
> 
> 
> 
> -
> 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: [VOTE] Release Configuration 2.1 based on RC3

[Oliver Heger]

+1

Oliver

Am 11.08.2016 um 22:02 schrieb Oliver Heger:
> Hi all,
> 
> after the failed votes for RC1 and RC2 a new RC has been created. There
> has been further tweaking of the checkstyle configuration to solve build
> problems on Java 1.6.
> 
> Configuration 2.1 RC3 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/configuration
> (revision 14770)
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1197/
> 
> Details of changes since 2.0 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/configuration/RELEASE-NOTES.txt
> 
> https://home.apache.org/~oheger/configuration-2.1-rc3/changes-report.html
> 
> Here is the tag:
> 
> http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_2_1_RC3
> (revision 1755836)
> 
> Site:
>https://home.apache.org/~oheger/configuration-2.1-rc3/
> (note some links in the menu are not yet working)
> 
> KEYS:
>   http://www.apache.org/dist/commons/KEYS
> 
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now, i.e. after 2000
> GMT 14-Aug-2016
> 
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
> 
> Thanks!
> Oliver
> 
> 
> 
> -
> 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: [rng] Adding JMH dependency, RNG-2.

[Benedikt Ritter]

Gilles  schrieb am Di., 16. Aug. 2016 um
21:20 Uhr:

> On Tue, 16 Aug 2016 19:06:28 +, Benedikt Ritter wrote:
> > Hi Artem,
> >
> > we've added JMH for Commons CSV in a special profile. Maybe you can
> > use
> > that as inspiration for RNG [1]
>
> Was done.
> See further down in the mail stack... ;-)
>

Sorry! So many emails to work through :-)

Benedikt


>
> Gilles
>
> > Regards,
> > Benedikt
> >
> > [1]
> > https://github.com/apache/commons-csv/blob/master/pom.xml#L390-L498
> >
> > [...]
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [rng] JIRA "pid" ?

[Gilles]

On Tue, 16 Aug 2016 18:56:43 +, Benedikt Ritter wrote:

Hi,

you can't see the PID directly in the JIRA UI. The PID for RNG is 
12320623.

I found it using this how to [1]

Regards,
Benedikt

[1]

http://stackoverflow.com/questions/9884381/how-to-get-project-id-to-create-a-direct-link



Was done.

Gilles



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

Re: [rng] Adding JMH dependency, RNG-2.

[Gilles]

On Tue, 16 Aug 2016 19:06:28 +, Benedikt Ritter wrote:

Hi Artem,

we've added JMH for Commons CSV in a special profile. Maybe you can 
use

that as inspiration for RNG [1]


Was done.
See further down in the mail stack... ;-)

Gilles


Regards,
Benedikt

[1] 
https://github.com/apache/commons-csv/blob/master/pom.xml#L390-L498


[...]



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

Re: [rng] Web site

[Gilles]

On Tue, 16 Aug 2016 19:04:44 +, Benedikt Ritter wrote:

Hi,

looking at

https://svn.apache.org/repos/infra/websites/production/commons/content/ 
I
can't see a directory for RNG. Let me know if I can help to set up 
the site.


You are welcome to do so.
This is one of the items here:
  https://issues.apache.org/jira/browse/RNG-6

Gilles



Benedikt


[...]


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

Re: [LANG] LANG-1252 - NumberUtils.isNumber and NumberUtils.createNumber resolve inconsistently

[Benedikt Ritter]

Hello Rob,

I'm back from vacation and I will have a look at this issue again later
this week.

Benedikt

Rob Tompkins  schrieb am Do., 11. Aug. 2016 um
16:48 Uhr:

>
> > On Jul 31, 2016, at 3:03 PM, Rob Tompkins  wrote:
> >
> > I figured that I would run an analogous test to the original with
> isParsable and createNumber, and I ran into the following:
> >
> > System.out.println(NumberUtils.isParsable("+2")); > false
> > System.out.println(NumberUtils.createNumber("+2")); ---> 2
> If I had to guess the cause of this discrepancy, I would think that we
> would want “isNumber(str)” and “isParsable(str)” to be as restrictive as
> Java 1.6 for the sake of compatibility, noting that “+2” only can be parsed
> to a Double or Float in Java 1.6. That said, I’m assuming that we want
> “createNumber(str)” to hit a wider range of strings for number
> instantiation.
>
> I’m guessing then that we would want to pick either “isParsable(str)” or
> “isNumber(str)” to track along with the wider range encapsulated in
> “createNumber(str),” which, based upon the conversation below, I would
> guess would be “isParsable(str).”
>
> My question now is: should I go ahead and incorporate that into LANG-1252
> with the namespace change/deprecation given below or should that go into a
> new issue?
>
> Cheers,
> -Rob
>
> > I’m not sure if we should tackle that in this Jira issue. What do you
> guys think?
> >
> > -Rob
> >
> >> On Jul 31, 2016, at 6:23 AM, Benedikt Ritter  > wrote:
> >>
> >> How about deprecating and renaming?
> >>
> >> isNumber -> isJavaNumberLiteral
> >> createNumber -> parseNumber
> >>
> >> this way there would be a clearer connection between isParsebale and the
> >> method that parses the number. Furthermore it is clearer what isNumber
> >> really does.
> >>
> >> Benedikt
> >>
> >> Rob Tompkins > schrieb
> am Sa., 30. Juli 2016 um 21:17:
> >>
> >>>
>  On Jul 30, 2016, at 12:41 PM, Gary Gregory  >
> >>> wrote:
> 
>  Can this all be solved with better Javadocs?
> 
> >>>
> >>> I don’t think so. So, I would think that we would do one of two things:
> >>>
> >>> (1) Clarify Javadocs, and set up unit tests to reflect the intent (that
> >>> being that createNumber and isNumber as slightly different)
> >>>
> >>> or
> >>>
> >>> (2) Refactor the code so that they use the same checks to either return
> >>> the boolean or create the number.
> >>>
> >>> Personally I’m indifferent, but I think those are the two different
> tacks
> >>> we can take.
> >>>
> >>> -Rob
> >>>
>  Gary
> 
>  On Jul 29, 2016 7:59 AM, "Rob Tompkins" > wrote:
> 
> > Hi Benedikt,
> >
> > Thanks for the insights here.
> >
> >> On Jul 29, 2016, at 3:53 AM, Benedikt Ritter  >
> >>> wrote:
> >>
> >> Hello Rob,
> >>
> >> Rob Tompkins 
> >> schrieb
> > am Do., 28. Juli 2016 um
> >> 14:23 Uhr:
> >>
> >>> In short, I’m trying to generalize LANG-1060, LANG-1040, LANG-1038,
> >>> and
> >>> LANG-992 with a single issue that actually hits all the bases here
> >>> with
> >>> NumberUtils.isNumber.
> >>>
> >>> Bug (1):
> >>>
> >>>  System.out.println(lang.math.NumberUtils.isNumber(“+2”));
> >
> >>> false
> >>>
> >>> while
> >>>
> >>>  System.out.println(lang.math.NumberUtils.createNumber(“+2));
> > >
> >>> 2
> >>>
> >>> Bug (2):
> >>>
> >>>
> >>>  System.out.println(lang.math.NumberUtils.isNumber(“01.5”));
> >>> >
> >>> false
> >>>
> >>> while
> >>>
> >>>  System.out.println(lang.math.NumberUtils.createNumber(“01.5));
> >>> > 1.5.
> >>>
> >>>
> >>>
> >>> It seems to me that we could externalize a considerable amount of
> the
> > code
> >>> underlying the two methods into shared methods, as it seems like
> all
> >>> the
> >>> validations in createNumber that predicate object creation should
> be
> >>> directly used in isNumber. I would love to hear folks’ thoughts.
> >>>
> >>
> >> I think it is important to pay close attention to the JavaDocs in
> this
> > case.
> >>
> >> NumberUtils.isNumber :
> >> Checks whether the String a valid Java number.
> >>
> >> This has nothing to do with createNumber:
> >> NumberUtils.createNumber: Turns a string value into a
> java.lang.Number
> >>
> >> What you're probably looking for is:
> >>
> >> NumberUtils.isParsebale: Checks whether the given String is a
> parsable
> >> number.
> >>
> >> The difference is, that isNumber tells you, whether putting the
> 

Re: [rng] Update .gitignore to ignore MacOS related files.

[Benedikt Ritter]

I personally think this kind of ignores belong into your global .gitignore
file. But that's just me :-)

Benedikt

Artem Barger  schrieb am Do., 11. Aug. 2016 um 00:20 Uhr:

> On Thu, Aug 11, 2016 at 1:12 AM, Gilles 
> wrote:
>
> > Hi,
> >>
> >> Will it be possible to apply patch for .gitignore file to skip Mac
> related
> >> files?
> >>
> >
> > Done.
>
>
> ​Thanks.​
>
>
> Best regards,
>   Artem Barger.
>

Re: [rng] Adding JMH dependency, RNG-2.

[Benedikt Ritter]

Hi Artem,

we've added JMH for Commons CSV in a special profile. Maybe you can use
that as inspiration for RNG [1]

Regards,
Benedikt

[1] https://github.com/apache/commons-csv/blob/master/pom.xml#L390-L498

Artem Barger  schrieb am Di., 9. Aug. 2016 um 14:39 Uhr:

> Hi,
>
> I've created a following JIRA task, to add JMH dependency and allow
> execution of microbenchmarks based on JMH framework. I've added maven
> profile to separate compilation of benchmark related jar from the main
> stream. My proposed changes attached to the JIRA issue, any comments or
> suggestions are welcomed.
>
>
> Also it will be interesting to hear ideas where to actually write and
> implement the benchmarks once such change will be added. Moreover it's
> important to note, that using JMH it only allows to compare algorithms and
> different implementations performance wise rather than comparing the
> actually accuracy of result produced. For example if I'll add a benchmark
> to compare different random source providers, I will receive results which
> show me what is the most performant provider for given workload, while
> nothing regarding the actually accuracy of the algorithm I've implemented
> to run the comparison.
>
> More particularly I've added a benchmark to estimate value of PI add this
> is the results I've got out of JMH:
>
> # Run complete. Total time: 00:01:35
>
> Benchmark (pairsToGenerate)  (randomSourceName)
> Mode  Cnt  Score   Error  Units
> PiComputationBenchmark.computePi100 JDK
> avgt5  44076.310 ±  2794.888  us/op
> PiComputationBenchmark.computePi100  WELL_512_A
> avgt5  19374.112 ±  4973.542  us/op
> PiComputationBenchmark.computePi100 WELL_1024_A
> avgt5  20575.240 ±  4298.444  us/op
> PiComputationBenchmark.computePi100WELL_19937_A
> avgt5  42208.136 ±  2062.648  us/op
> PiComputationBenchmark.computePi100WELL_19937_C
> avgt5  45105.231 ±  2752.918  us/op
> PiComputationBenchmark.computePi100WELL_44497_A
> avgt5  49710.663 ± 15786.830  us/op
> PiComputationBenchmark.computePi100WELL_44497_B
> avgt5  48984.700 ±  2449.719  us/op
> PiComputationBenchmark.computePi100  MT
> avgt5  22466.565 ±  1377.585  us/op
> PiComputationBenchmark.computePi100   ISAAC
> avgt5  21615.283 ±  1080.331  us/op
>
> Note, there is nothing here that shows how actually computed PI results is
> close to real value.
>
> Best regards,
>   Artem Barger.
>

Re: [rng] Web site (Was: [rng] JIRA is up)

[Benedikt Ritter]

Hi,

looking at
https://svn.apache.org/repos/infra/websites/production/commons/content/ I
can't see a directory for RNG. Let me know if I can help to set up the site.

Benedikt

Artem Barger  schrieb am Di., 9. Aug. 2016 um 12:49 Uhr:

> On Tue, Aug 9, 2016 at 1:25 PM, Gilles 
> wrote:
>
> > In short, you might try this:
> >
> >   
> > 
> >   org.apache.maven.plugins
> >   maven-javadoc-plugin
> >   
> > -Xdoclint:none
> >   
> > 
> >   
> >
> > If it fixes your problem, I'll commit the change.
> >
>
> ​Yeah, now it's better. Based on this created a patch and attached to the
> issue report, since the change wasn't exactly the same.​
>
>
> Best regards,
>   Artem Barger.
>

Re: [Website] download link could not redirect consistently

[Benedikt Ritter]

Hi,

the redirects a defined in
https://svn.apache.org/repos/infra/websites/production/commons/content/.htaccess
I can't find a reason why it does not work for crypto.

Sebb do you have an idea? I think you set the redirects up initially.

Regards,
Benedikt

Sun, Dapeng  schrieb am Fr., 5. Aug. 2016 um
11:34 Uhr:

> Hello
>
> The following link cannot redirect. Anyone know the reason about it?
> https://commons.apache.org/crypto/download_crypto.cgi
> It should redirect to
> https://commons.apache.org/proper/commons-crypto/download_crypto.cgi
>
> Sites for other components could redirect. But some download_*cgi redirect
> *.cgi, others redirect to *html.
>
> For example:
> https://commons.apache.org/codec/download_codec.cgi  ->
> https://commons.apache.org/proper/commons-codec/download_codec.cgi
> https://commons.apache.org/net/download_net.cgi  ->
> http://commons.apache.org/proper/commons-net/download_net.html
>
>
> Regards
> Dapeng
>
>

Re: [rng] JIRA "pid" ?

[Benedikt Ritter]

Hi,

you can't see the PID directly in the JIRA UI. The PID for RNG is 12320623.
I found it using this how to [1]

Regards,
Benedikt

[1]
http://stackoverflow.com/questions/9884381/how-to-get-project-id-to-create-a-direct-link

Gilles  schrieb am Mi., 10. Aug. 2016 um
12:34 Uhr:

> On Wed, 10 Aug 2016 12:24:24 +0200, Jochen Wiedmann wrote:
> > The URL https://issues.apache.org/jira/browse/RNG works, so I guess
> > its RNG.
>
> IIUC, "RNG" is the JIRA "projectKey".
> The "pid" is a number (see the URL below).
>
> Gilles
>
> > Jochen
> >
> >
> > On Tue, Aug 9, 2016 at 6:28 PM, Gilles 
> > wrote:
> >> Hello.
> >>
> >> How does one find the project identifier to be used in links such as
> >>
> >>
> >>
> http://issues.apache.org/jira/secure/CreateIssueDetails!init.jspa?pid=12310485=1=4=-1
> >> ?
> >>
> >> Thanks,
> >> Gilles
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [rng] JARs with different dependencies within the same component?

[Gilles]

On Tue, 16 Aug 2016 15:53:44 +0300, Artem Barger wrote:
On Tue, Aug 16, 2016 at 3:00 PM, Gilles 


wrote:

That's what I was afraid of; in this case, it would defeat the 
purpose:

We shouldn't have to release "core-2.0" (thus a with change of the
top-level package name), just because we want to fix something in 
the

"utils" code.

Given this situation, would it be possible to consider a separate
component: "commons-rng-utils"?



I think following layout should actually work:

commons-rng-parent (pom) v1.0
|commons-rng-core (jar) v1.0
|commons-rng-tools (jar) v1.0​

​And suppose you want to update commong-rng-tools from v1.0 to v2.0 
it will

look like:​

commons-rng-parent (pom) v1.1
|commons-rng-core (jar) v1.0
|commons-rng-tools (jar) v2.0​

​where you do not really have to touch version of core component. 
Unless

this is somehow
restricted by ASF commons coding standards or something.​


The restriction, as Jörg wrote, is that a single component can only
release artifacts with the same version.

If we have to put the tools in a separate component, it will already
inherit from "commons-parent". Then, is there an interest to define
an additional "commons-rng-parent" level.


Regards,
Gilles



Or, do you have something else in your mind?

Best regards,
  Artem Barger.



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

Re: [rng] JARs with different dependencies within the same component?

[Artem Barger]

On Tue, Aug 16, 2016 at 3:00 PM, Gilles 
wrote:

> That's what I was afraid of; in this case, it would defeat the purpose:
> We shouldn't have to release "core-2.0" (thus a with change of the
> top-level package name), just because we want to fix something in the
> "utils" code.
>
> Given this situation, would it be possible to consider a separate
> component: "commons-rng-utils"?
>

I think following layout should actually work:

commons-rng-parent (pom) v1.0
|commons-rng-core (jar) v1.0
|commons-rng-tools (jar) v1.0​

​And suppose you want to update commong-rng-tools from v1.0 to v2.0 it will
look like:​

commons-rng-parent (pom) v1.1
|commons-rng-core (jar) v1.0
|commons-rng-tools (jar) v2.0​

​where you do not really have to touch version of core component. Unless
this is somehow
restricted by ASF commons coding standards or something.​

Or, do you have something else in your mind?

Best regards,
  Artem Barger.

Re: [rng] JARs with different dependencies within the same component?

[Gilles]

On Tue, 16 Aug 2016 13:42:53 +0200, Jörg Schaible wrote:

Gilles wrote:


On Tue, 16 Aug 2016 09:10:06 +0200, Jörg Schaible wrote:

Hi Gilles,

Gilles wrote:


Hi.

Suppose that
   commons-rng-core-1.0.jar
depends on JDK 1.6.

And that we wish to offer utilities (e.g. random strings) and 
other

syntactic sugar (such as Java 8 streams) in
   commons-rng-utils-1.0.jar
that would depend on JDK 1.8.

Is it possible?


Yes. Have a look at XStream
(https://github.com/x-stream/xstream/blob/master/xstream/pom.xml), 
it

already does this (since
years), currently to support lambda expressions. It declarers 
simply

a
second compiler execution. Note, there's a bug in Maven that forces
you to
define as many excludes in the second execution as in the first 
one.


IIUC, it is not exactly what I had in mind, which would amount to
having two separate JARs: "core" and "utils".
"core" is anticipated to be stable (hopefully) while "utils" could
evolve faster and possibly in a non-compatible way.

I.e. we could have

core-1.0

utils-1.0
   depends on core-1.0

utils-1.1
   depends on core-1.0

utils-2.0
   depends on core-1.0

core-1.1 (e.g. after adding a new RNG implementation)

utils-2.1
   depends on core-1.1


Well, a commons component has *one* version. You can introduce 
another
artifact (just like Artem proposed), but there's no independent 
release

cycle.


That's what I was afraid of; in this case, it would defeat the purpose:
We shouldn't have to release "core-2.0" (thus a with change of the
top-level package name), just because we want to fix something in the
"utils" code.

Given this situation, would it be possible to consider a separate
component: "commons-rng-utils"?


Regards,
Gilles


Cheers,
Jörg




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

Re: [rng] JARs with different dependencies within the same component?

[Jörg Schaible]

Gilles wrote:

> On Tue, 16 Aug 2016 09:10:06 +0200, Jörg Schaible wrote:
>> Hi Gilles,
>>
>> Gilles wrote:
>>
>>> Hi.
>>>
>>> Suppose that
>>>commons-rng-core-1.0.jar
>>> depends on JDK 1.6.
>>>
>>> And that we wish to offer utilities (e.g. random strings) and other
>>> syntactic sugar (such as Java 8 streams) in
>>>commons-rng-utils-1.0.jar
>>> that would depend on JDK 1.8.
>>>
>>> Is it possible?
>>
>> Yes. Have a look at XStream
>> (https://github.com/x-stream/xstream/blob/master/xstream/pom.xml), it
>> already does this (since
>> years), currently to support lambda expressions. It declarers simply
>> a
>> second compiler execution. Note, there's a bug in Maven that forces
>> you to
>> define as many excludes in the second execution as in the first one.
> 
> IIUC, it is not exactly what I had in mind, which would amount to
> having two separate JARs: "core" and "utils".
> "core" is anticipated to be stable (hopefully) while "utils" could
> evolve faster and possibly in a non-compatible way.
> 
> I.e. we could have
> 
> core-1.0
> 
> utils-1.0
>depends on core-1.0
> 
> utils-1.1
>depends on core-1.0
> 
> utils-2.0
>depends on core-1.0
> 
> core-1.1 (e.g. after adding a new RNG implementation)
> 
> utils-2.1
>depends on core-1.1

Well, a commons component has *one* version. You can introduce another 
artifact (just like Artem proposed), but there's no independent release 
cycle.

Cheers,
Jörg


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

Re: [rng] JARs with different dependencies within the same component?

[Gilles]

On Tue, 16 Aug 2016 09:10:06 +0200, Jörg Schaible wrote:

Hi Gilles,

Gilles wrote:


Hi.

Suppose that
   commons-rng-core-1.0.jar
depends on JDK 1.6.

And that we wish to offer utilities (e.g. random strings) and other
syntactic sugar (such as Java 8 streams) in
   commons-rng-utils-1.0.jar
that would depend on JDK 1.8.

Is it possible?


Yes. Have a look at XStream
(https://github.com/x-stream/xstream/blob/master/xstream/pom.xml), it
already does this (since
years), currently to support lambda expressions. It declarers simply 
a
second compiler execution. Note, there's a bug in Maven that forces 
you to

define as many excludes in the second execution as in the first one.


IIUC, it is not exactly what I had in mind, which would amount to
having two separate JARs: "core" and "utils".
"core" is anticipated to be stable (hopefully) while "utils" could
evolve faster and possibly in a non-compatible way.

I.e. we could have

core-1.0

utils-1.0
  depends on core-1.0

utils-1.1
  depends on core-1.0

utils-2.0
  depends on core-1.0

core-1.1 (e.g. after adding a new RNG implementation)

utils-2.1
  depends on core-1.1


Regards,
Gilles

There are some minor drawbacks though. Android users fail to use the 
jar,
because there's no support for Java 8. App servers running with Java 
7 may
fail if they scan the libraries in the classpath for annotations 
(e.g.

http://x-stream.github.io/faq.html#Compatibility_webSphere_8).

Cheers,
Jörg




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

Re: [rng] JARs with different dependencies within the same component?

[Jörg Schaible]

Hi Gilles,

Gilles wrote:

> Hi.
> 
> Suppose that
>commons-rng-core-1.0.jar
> depends on JDK 1.6.
> 
> And that we wish to offer utilities (e.g. random strings) and other
> syntactic sugar (such as Java 8 streams) in
>commons-rng-utils-1.0.jar
> that would depend on JDK 1.8.
> 
> Is it possible?

Yes. Have a look at XStream 
(https://github.com/x-stream/xstream/blob/master/xstream/pom.xml), it already 
does this (since 
years), currently to support lambda expressions. It declarers simply a 
second compiler execution. Note, there's a bug in Maven that forces you to 
define as many excludes in the second execution as in the first one.

There are some minor drawbacks though. Android users fail to use the jar, 
because there's no support for Java 8. App servers running with Java 7 may 
fail if they scan the libraries in the classpath for annotations (e.g. 
http://x-stream.github.io/faq.html#Compatibility_webSphere_8).

Cheers,
Jörg


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