Re: [all] Is it possible to commit from github via gitbox?

[Eitan Adler]

(please remember to CC me on replies)

On Wed, 5 Jun 2019 at 16:00, Alex Herbert  wrote:

>
>
> On 5 Jun 2019, at 23:51, Eitan Adler  wrote:
>
> (please remember to CC me on replies)
>
> When I want to merge a PR [0] it seems I don't have write permission
> according to github. Is this intentional such that I should push directly
> to gitbox, did I miss some step, or do I need to file an INFRA ticket?
>
>
> You have to set up 2 factor authentication on GitHub and link accounts
> using this:
>
> https://gitbox.apache.org/setup/
>

That appears to be done already:
https://www.dropbox.com/s/sg9pkk143sgr1o9/Screenshot%202019-06-05%2019.22.59.png?dl=0


-- 
Eitan Adler

Re: [all] Is it possible to commit from github via gitbox?

[Alex Herbert]

> On 5 Jun 2019, at 23:51, Eitan Adler  wrote:
> 
> (please remember to CC me on replies)
> 
> When I want to merge a PR [0] it seems I don't have write permission
> according to github. Is this intentional such that I should push directly
> to gitbox, did I miss some step, or do I need to file an INFRA ticket?

You have to set up 2 factor authentication on GitHub and link accounts using 
this:

https://gitbox.apache.org/setup/ 


> 
> [0] https://github.com/apache/commons-numbers/pull/47
> 
> -- 
> Eitan Adler

[all] Is it possible to commit from github via gitbox?

[Eitan Adler]

(please remember to CC me on replies)

When I want to merge a PR [0] it seems I don't have write permission
according to github. Is this intentional such that I should push directly
to gitbox, did I miss some step, or do I need to file an INFRA ticket?

[0] https://github.com/apache/commons-numbers/pull/47

-- 
Eitan Adler

[numbers][fraction] pulling fraction-dev into master

[Eric Barnhill]

For some months I worked on the Fraction class on a fraction-dev branch,
now others are furthering it, but IIUC working off of master, plus it
sounds like my edits are out of date in other ways.

So within the next day, I will pull fraction-dev into master. I would
request any other contributors contributing to Fraction, to merge these
changes into their own work and rebase.

I was at the final checkstyle edits of what I was working on, so hopefully
it will not cause anyone more than minor conveniences. If it will cause you
a larger inconvenience and you would rather work together to merge it,
please post here. If you find after the fact it causes you a headache I can
roll it back, I will keep the branch around for a while.

Eric

Re: [All] Alpha/beta releases

[Gary Gregory]

Hi All:

I see two lines of usage IRL from people:

- I use whatever is "released" on Maven Central. I quote the word released
since that includes ANY artifacts, pre 1.0 like a 0.87 or -alpha, and
-betas.
- I am not allowed to use alpha, beta, or SNAPSHOT versions.

The reality ends up being that you see some stacks that have a mix of both
of the above.

We all know that Jar hell is created when breaking BC within the same
package name (and Maven coordinates.)

We have clear rules of engagement of major, minor and maintenance releases.

The question for me is how should we treat other kinds of releases: alphas
and betas. This is assuming that we want to keep on releasing alphas and
betas.

Jar hell is, well, hellish. I like to avoid it.

Since the very nature of alphas and betas is that changing APIs should be
allowed, even encouraged in order to get the API in the right shape before
a x.y.z release, I am warming to using alpha and beta in package names...
If you are to be so bold as to use such a thing, then reflecting that in
the import states what you are doing clearly, and avoid any jar hell.

That said, it should be left to each component to decide whether or not to
opt in such naming.

Gary


On Wed, Jun 5, 2019 at 6:25 PM Gilles Sadowski  wrote:

> Le mer. 5 juin 2019 à 23:14, sebb  a écrit :
> >
> > On Wed, 5 Jun 2019 at 17:16, Gilles Sadowski 
> wrote:
> > >
> > > Le mer. 5 juin 2019 à 17:57, James Carman 
> a écrit :
> > > >
> > > > I’m having a hard time understanding the comparing APIs use case.
> If I
> > > > were to want to try that, I’d create a branch and import the new
> dependency
> > > > version and see what breaks.  The performance part I wouldn’t think
> I’d use
> > > > one code base either.  I’m not suggesting my way is the only or best
> way,
> > > > just explaining why I’m having a hard time understanding what you’re
> > > > doing.  Maybe this will be a learning opportunity for me! :)
> > >
> > > Case mainly in point is getting to the first release of new components.
> > > This is happening now for [Imaging], and will be soon (hopefully) for
> > > [Numbers], [Statistics] and [Geometry].
> > >
> > > IIUC, the former is going to release a beta version without modifying
> > > the top-level package name.  This will create the possibility of JAR
> > > hell (when 1.0 will be out).
> > >
> > > Since we don't have that much review/feedback on these new and/or
> > > refactored codes, I thought we could be on a safer ground if we first
> > > release beta version(s) that
> > >  * won't be subject to JAR hell and
> > >  * will be easy (i.e. just add the dependency in the POM file) to
> > >integrate for people kind enough to give it a try.
> > >[If it's not easy[1], they won't do it.]
> > >
> > > Regards,
> > > Gilles
> > >
> > > [1] Like: You "just" have to install "git", check out the source,
> install
> > > "maven", run the "package" goal, then move the "target/whatever.jar"
> > > file to where your code will look for it.
> >
> > No need to install Git; can just download the source archive and unpack
> it.
> > I think we can assume they already have Maven, otherwise why are we
> > worried about releasing to Maven?
> >
> > Note that the suggestion of using different package names will force
> > users to edit their code.
>
> So what; this is the purpose of beta-testing features that don't
> exist in previous releases or in the previous beta version.
>
> > They will then have to compile their source, probably using Maven.
> >
> > Seems to me the suggestion creates more work for end users.
>
> People will have to do something.
> When they raise an issue, it is easier for me and for them to point
> to one-line change in their dependencies  (and the corresponding
> change in their code), then to start explaining that they should
> build from source.
>
> From the discussion, I'm still missing the opinion stating explicitly
> that "we don't care about JAR hell produced by a beta release".
> My suggestion is only to avoid that.  Is the PMC fine releasing
> *incompatible* beta releases (and of course incompatible with the
> "stable" release that will follow) with the same package name?
>
> Gilles
>
> > > >
> > > > On Wed, Jun 5, 2019 at 11:33 AM Gilles Sadowski <
> gillese...@gmail.com>
> > > > wrote:
> > > >
> > > > > Le mer. 5 juin 2019 à 17:04, James Carman <
> ja...@carmanconsulting.com> a
> > > > > écrit :
> > > > > >
> > > > > > What sort of comparison are you looking to do within the same
> code?
> > > > > > Performance?
> > > > >
> > > > > Yes, that's one possibility; another is comparing different APIs.
> > > > >
> > > > > Gilles
> > > > >
> > > > >  [...]
> > > > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [rng] Update ProviderBuilder factory methods

[Alex Herbert]

> On 5 Jun 2019, at 22:51, Gilles Sadowski  wrote:
> 
> Hi.
> 
> Le lun. 3 juin 2019 à 16:49, Alex Herbert  > a écrit :
>> 
>> Can I get a review of a PR that changes the ProviderBuilder [1]?
>> 
>> The aim is to move the creation of the seed and the RNG into the
>> RandomSourceInternal.
>> 
>> This allows for customisation of the seed creation on a per-RNG basis.
>> The reason is that some new generators in the library for v1.3 require
>> the seed is non-zero. For example this is a realistic possibility when
>> the seed is an array of ints of size 2.
>> 
>> The code change has required updating the routines using the
>> SeedConverter interface and adding a Seed2ArrayConverter interface:
>> 
>> public interface Seed2ArrayConverter extends SeedConverter 
>> {
>> /**
>>  * Converts seed from input type to output type. The output type is 
>> expected to be an array.
>>  *
>>  * @param seed Original seed value.
>>  * @param outputSize Output size.
>>  * @return the converted seed value.
>>  */
>> OUT convert(IN seed, int outputSize);
>> }
>> 
>> I've moved conversion to a new enum class for seed creation and
>> conversion. Previously the ProviderBuilder used maps to store all the
>> conversions. These are now explicitly written as conversion methods in
>> the enum. The amount of code is the same and the conversions are the
>> same. However use of the enum for conversion has removed the need to
>> support the Seed2ArrayConverter interface in all the converters. This
>> has deprecated some methods and classes. I've not yet marked them as so
>> in the PR.
>> 
>> i.e.
>> 
>> private static final Map, SeedConverter> CONV_LONG_ARRAY 
>> =
>> new ConcurrentHashMap, SeedConverter>();
>> 
>> does not have to become:
>> 
>> private static final Map, Seed2ArrayConverter> 
>> CONV_LONG_ARRAY =
>> new ConcurrentHashMap, Seed2ArrayConverter>();
>> 
>> with the corresponding conversion as:
>> 
>> nativeSeed = CONV_LONG_ARRAY.get(source.getSeed()).convert((long[]) seed, 
>> source.getSeedSize());
>> 
>> 
>> Currently conversions of arrays to arrays ignore the seed size. Creation
>> of a new seed is limited to a maximum of 128.
> 
> +0
> See below.
> 
>> This matches the previous
>> functionality. It could be changed to create the full length seed.
> 
> +0
> See below.
> 
>> The
>> impact would be more work done within synchronized blocks in the
>> SeedFactory. I would expect the generation to be slower but the seed
>> quality will be higher.
> 
> As per the previous discussion, special needs should be covered
> by the user.
> However, it could be construed that 128 is large enough for a casual
> user, and a larger seed could also pass as a special need that the
> user can provide explicitly...
> 
> So either way is fine I guess.

So we stick to an upper limit of 128. I was just pointing out that there is no 
need for this limit anymore since the actual length is known. However I agree 
that a size of 128 is pretty big. Those generators with larger seeds will self 
generate the rest of the seed so the full length seed is created, just not all 
from the same RNG.

> 
>> 
>> Only creation of arrays from int/long seeds will use the seed size. This
>> does not operate within a synchronized block.
>> 
>> 
>> Note that RNG constructor is obtained using reflection. Previously was
>> done on each invocation. However now that the method is within the
>> RandomSourceInternal enum caching the constructor is a natural
>> modification since it is always the same.
> 
> +1
> But please rename the local variable in method "getConstructor()".[1]
> ;-)

Sorry about that. 

I have a habit of avoiding name clashes between local and class variables. I 
chose poorly in this case. I'll change it to something more verbose.

> 
>> I have not done this in the
>> constructor for the RandomSourceInternal enum as:
>> 
>> - it adds overhead when building all the enums (e.g.
>> RandomSourceInternal.values())
>> 
>> - it may throw lots of different types of exception. Rather than
>> catching them all in the constructor for the enum they can now be thrown
>> during creation of the RNG instance so the user gets the appropriate
>> stack trace.
>> 
>> 
>> The change to create an array using the correct size has performance
>> implications (see [2]):
>> 
>> - For small array sizes the creation is faster
>> 
>> - For large array sizes built using an int/long the creation is
>> marginally slower (but the seed should be better as it uses the SplitMix
>> algorithm rather than the self-seeding strategy of the BaseProvider [3])
> 
> Where is it done?

In the call to:

RandomSourceInternal.convertSeed(Object seed) {
return nativeSeedType.convertSeed(seed, nativeSeedSize);
}

If the native seed type is an array and the input seed is Integer or Long then 
the nativeSeedSize is used and a full length array is created by either:

NativeSeedType.INT_ARRAY
NativeSeedType.LONG_ARRAY 

Object convert

Re: [All] Alpha/beta releases

[Gilles Sadowski]

Le mer. 5 juin 2019 à 23:14, sebb  a écrit :
>
> On Wed, 5 Jun 2019 at 17:16, Gilles Sadowski  wrote:
> >
> > Le mer. 5 juin 2019 à 17:57, James Carman  a 
> > écrit :
> > >
> > > I’m having a hard time understanding the comparing APIs use case.  If I
> > > were to want to try that, I’d create a branch and import the new 
> > > dependency
> > > version and see what breaks.  The performance part I wouldn’t think I’d 
> > > use
> > > one code base either.  I’m not suggesting my way is the only or best way,
> > > just explaining why I’m having a hard time understanding what you’re
> > > doing.  Maybe this will be a learning opportunity for me! :)
> >
> > Case mainly in point is getting to the first release of new components.
> > This is happening now for [Imaging], and will be soon (hopefully) for
> > [Numbers], [Statistics] and [Geometry].
> >
> > IIUC, the former is going to release a beta version without modifying
> > the top-level package name.  This will create the possibility of JAR
> > hell (when 1.0 will be out).
> >
> > Since we don't have that much review/feedback on these new and/or
> > refactored codes, I thought we could be on a safer ground if we first
> > release beta version(s) that
> >  * won't be subject to JAR hell and
> >  * will be easy (i.e. just add the dependency in the POM file) to
> >integrate for people kind enough to give it a try.
> >[If it's not easy[1], they won't do it.]
> >
> > Regards,
> > Gilles
> >
> > [1] Like: You "just" have to install "git", check out the source, install
> > "maven", run the "package" goal, then move the "target/whatever.jar"
> > file to where your code will look for it.
>
> No need to install Git; can just download the source archive and unpack it.
> I think we can assume they already have Maven, otherwise why are we
> worried about releasing to Maven?
>
> Note that the suggestion of using different package names will force
> users to edit their code.

So what; this is the purpose of beta-testing features that don't
exist in previous releases or in the previous beta version.

> They will then have to compile their source, probably using Maven.
>
> Seems to me the suggestion creates more work for end users.

People will have to do something.
When they raise an issue, it is easier for me and for them to point
to one-line change in their dependencies  (and the corresponding
change in their code), then to start explaining that they should
build from source.

>From the discussion, I'm still missing the opinion stating explicitly
that "we don't care about JAR hell produced by a beta release".
My suggestion is only to avoid that.  Is the PMC fine releasing
*incompatible* beta releases (and of course incompatible with the
"stable" release that will follow) with the same package name?

Gilles

> > >
> > > On Wed, Jun 5, 2019 at 11:33 AM Gilles Sadowski 
> > > wrote:
> > >
> > > > Le mer. 5 juin 2019 à 17:04, James Carman  a
> > > > écrit :
> > > > >
> > > > > What sort of comparison are you looking to do within the same code?
> > > > > Performance?
> > > >
> > > > Yes, that's one possibility; another is comparing different APIs.
> > > >
> > > > Gilles
> > > >
> > > >  [...]
> > > >

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

Re: [rng] Update ProviderBuilder factory methods

[Gilles Sadowski]

Hi.

Le lun. 3 juin 2019 à 16:49, Alex Herbert  a écrit :
>
> Can I get a review of a PR that changes the ProviderBuilder [1]?
>
> The aim is to move the creation of the seed and the RNG into the
> RandomSourceInternal.
>
> This allows for customisation of the seed creation on a per-RNG basis.
> The reason is that some new generators in the library for v1.3 require
> the seed is non-zero. For example this is a realistic possibility when
> the seed is an array of ints of size 2.
>
> The code change has required updating the routines using the
> SeedConverter interface and adding a Seed2ArrayConverter interface:
>
> public interface Seed2ArrayConverter extends SeedConverter {
>  /**
>   * Converts seed from input type to output type. The output type is 
> expected to be an array.
>   *
>   * @param seed Original seed value.
>   * @param outputSize Output size.
>   * @return the converted seed value.
>   */
>  OUT convert(IN seed, int outputSize);
> }
>
> I've moved conversion to a new enum class for seed creation and
> conversion. Previously the ProviderBuilder used maps to store all the
> conversions. These are now explicitly written as conversion methods in
> the enum. The amount of code is the same and the conversions are the
> same. However use of the enum for conversion has removed the need to
> support the Seed2ArrayConverter interface in all the converters. This
> has deprecated some methods and classes. I've not yet marked them as so
> in the PR.
>
> i.e.
>
> private static final Map, SeedConverter> CONV_LONG_ARRAY =
>  new ConcurrentHashMap, SeedConverter>();
>
> does not have to become:
>
> private static final Map, Seed2ArrayConverter> 
> CONV_LONG_ARRAY =
>  new ConcurrentHashMap, Seed2ArrayConverter>();
>
> with the corresponding conversion as:
>
> nativeSeed = CONV_LONG_ARRAY.get(source.getSeed()).convert((long[]) seed, 
> source.getSeedSize());
>
>
> Currently conversions of arrays to arrays ignore the seed size. Creation
> of a new seed is limited to a maximum of 128.

+0
See below.

> This matches the previous
> functionality. It could be changed to create the full length seed.

+0
See below.

> The
> impact would be more work done within synchronized blocks in the
> SeedFactory. I would expect the generation to be slower but the seed
> quality will be higher.

As per the previous discussion, special needs should be covered
by the user.
However, it could be construed that 128 is large enough for a casual
user, and a larger seed could also pass as a special need that the
user can provide explicitly...

So either way is fine I guess.

>
> Only creation of arrays from int/long seeds will use the seed size. This
> does not operate within a synchronized block.
>
>
> Note that RNG constructor is obtained using reflection. Previously was
> done on each invocation. However now that the method is within the
> RandomSourceInternal enum caching the constructor is a natural
> modification since it is always the same.

+1
But please rename the local variable in method "getConstructor()".[1]
;-)

> I have not done this in the
> constructor for the RandomSourceInternal enum as:
>
> - it adds overhead when building all the enums (e.g.
> RandomSourceInternal.values())
>
> - it may throw lots of different types of exception. Rather than
> catching them all in the constructor for the enum they can now be thrown
> during creation of the RNG instance so the user gets the appropriate
> stack trace.
>
>
> The change to create an array using the correct size has performance
> implications (see [2]):
>
> - For small array sizes the creation is faster
>
> - For large array sizes built using an int/long the creation is
> marginally slower (but the seed should be better as it uses the SplitMix
> algorithm rather than the self-seeding strategy of the BaseProvider [3])

Where is it done?

>
> Caching the constructor for use with reflection has improved performance.

+1

Thanks,
Gilles

>
>
> [1] https://github.com/apache/commons-rng/pull/46
>
> [2] https://issues.apache.org/jira/browse/RNG-75
>
> [3] This could be tested by creating a new generator that implements the
> self-seeding strategy as its output and running it through the stress
> test applications.
>

Gilles

[1] https://www.linguee.com/french-english/translation/con.html

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

Re: [All] Alpha/beta releases

[Otto Fowler]

On June 5, 2019 at 12:16:33, Gilles Sadowski (gillese...@gmail.com) wrote:

Le mer. 5 juin 2019 à 17:57, James Carman  a
écrit :
>
> I’m having a hard time understanding the comparing APIs use case. If I
> were to want to try that, I’d create a branch and import the new
dependency
> version and see what breaks. The performance part I wouldn’t think I’d use

> one code base either. I’m not suggesting my way is the only or best way,
> just explaining why I’m having a hard time understanding what you’re
> doing. Maybe this will be a learning opportunity for me! :)

Case mainly in point is getting to the first release of new components.
This is happening now for [Imaging], and will be soon (hopefully) for
[Numbers], [Statistics] and [Geometry].

IIUC, the former is going to release a beta version without modifying
the top-level package name. This will create the possibility of JAR
hell (when 1.0 will be out).

Sounds like the issue is doing ‘alpha’ and ‘beta’ releases instead of just
using versioning.




Since we don't have that much review/feedback on these new and/or
refactored codes, I thought we could be on a safer ground if we first
release beta version(s) that
* won't be subject to JAR hell and
* will be easy (i.e. just add the dependency in the POM file) to
integrate for people kind enough to give it a try.
[If it's not easy[1], they won't do it.]

Regards,
Gilles

[1] Like: You "just" have to install "git", check out the source, install
"maven", run the "package" goal, then move the "target/whatever.jar"
file to where your code will look for it.

>
> On Wed, Jun 5, 2019 at 11:33 AM Gilles Sadowski 
> wrote:
>
> > Le mer. 5 juin 2019 à 17:04, James Carman  a

> > écrit :
> > >
> > > What sort of comparison are you looking to do within the same code?
> > > Performance?
> >
> > Yes, that's one possibility; another is comparing different APIs.
> >
> > 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

Re: [All] Alpha/beta releases

[sebb]

On Wed, 5 Jun 2019 at 17:16, Gilles Sadowski  wrote:
>
> Le mer. 5 juin 2019 à 17:57, James Carman  a 
> écrit :
> >
> > I’m having a hard time understanding the comparing APIs use case.  If I
> > were to want to try that, I’d create a branch and import the new dependency
> > version and see what breaks.  The performance part I wouldn’t think I’d use
> > one code base either.  I’m not suggesting my way is the only or best way,
> > just explaining why I’m having a hard time understanding what you’re
> > doing.  Maybe this will be a learning opportunity for me! :)
>
> Case mainly in point is getting to the first release of new components.
> This is happening now for [Imaging], and will be soon (hopefully) for
> [Numbers], [Statistics] and [Geometry].
>
> IIUC, the former is going to release a beta version without modifying
> the top-level package name.  This will create the possibility of JAR
> hell (when 1.0 will be out).
>
> Since we don't have that much review/feedback on these new and/or
> refactored codes, I thought we could be on a safer ground if we first
> release beta version(s) that
>  * won't be subject to JAR hell and
>  * will be easy (i.e. just add the dependency in the POM file) to
>integrate for people kind enough to give it a try.
>[If it's not easy[1], they won't do it.]
>
> Regards,
> Gilles
>
> [1] Like: You "just" have to install "git", check out the source, install
> "maven", run the "package" goal, then move the "target/whatever.jar"
> file to where your code will look for it.

No need to install Git; can just download the source archive and unpack it.
I think we can assume they already have Maven, otherwise why are we
worried about releasing to Maven?

Note that the suggestion of using different package names will force
users to edit their code.
They will then have to compile their source, probably using Maven.

Seems to me the suggestion creates more work for end users.

> >
> > On Wed, Jun 5, 2019 at 11:33 AM Gilles Sadowski 
> > wrote:
> >
> > > Le mer. 5 juin 2019 à 17:04, James Carman  a
> > > écrit :
> > > >
> > > > What sort of comparison are you looking to do within the same code?
> > > > Performance?
> > >
> > > Yes, that's one possibility; another is comparing different APIs.
> > >
> > > 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
>

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

Re: [gsoc] Weekly meeting tomorrow

[Alex Herbert]

> On 5 Jun 2019, at 20:47, Eric Barnhill  wrote:
> 
> That looked like a list of times.

It showed ideal points for a meeting from all times of day. UTC +3 or +4 should 
be daytime hours for everyone except those in IST.

> How is this one for you all
> 
> https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=6&day=6&hour=16&min=0&sec=0&p1=136&p2=224&p3=265&p4=1249&p5=1860&iv=1800
>  
> 

Better. UTC +4, I will be there.

Alex

> 
> 
> On Wed, Jun 5, 2019 at 11:59 AM Alex Herbert 
> wrote:
> 
>> Time for another meeting to discuss progress.
>> 
>> Shall we change to UTC +4 this time? Here is the meeting time clock for
>> everyone:
>> 
>> 
>> https://www.timeanddate.com/worldclock/meetingtime.html?iso=20190606&p1=136&p2=224&p3=265&p4=1249&p5=1860
>> <
>> https://www.timeanddate.com/worldclock/meetingtime.html?iso=20190606&p1=136&p2=224&p3=265&p4=1249&p5=1860
>>> 
>> 
>> Alex
>> 
>> 

Re: [gsoc] Weekly meeting tomorrow

[Eric Barnhill]

That looked like a list of times. How is this one for you all

https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=6&day=6&hour=16&min=0&sec=0&p1=136&p2=224&p3=265&p4=1249&p5=1860&iv=1800


On Wed, Jun 5, 2019 at 11:59 AM Alex Herbert 
wrote:

> Time for another meeting to discuss progress.
>
> Shall we change to UTC +4 this time? Here is the meeting time clock for
> everyone:
>
>
> https://www.timeanddate.com/worldclock/meetingtime.html?iso=20190606&p1=136&p2=224&p3=265&p4=1249&p5=1860
> <
> https://www.timeanddate.com/worldclock/meetingtime.html?iso=20190606&p1=136&p2=224&p3=265&p4=1249&p5=1860
> >
>
> Alex
>
>

Re: [gsoc] Weekly meeting tomorrow

[Alex Herbert]

Time for another meeting to discuss progress.

Shall we change to UTC +4 this time? Here is the meeting time clock for 
everyone:

https://www.timeanddate.com/worldclock/meetingtime.html?iso=20190606&p1=136&p2=224&p3=265&p4=1249&p5=1860
 


Alex

Re: [All] Alpha/beta releases

[Gary Gregory]

In the past we have only guarded against jar-hell with major component
releases matching a package name changes and Maven coordinate name change.

It seems some want to apply the same principles to other kinds of versions,
not just major version. Like a 0.9.alpha1 or even a 2.0.beta-1. I suppose
there is nothing stopping us from that...

Gary

On Wed, Jun 5, 2019 at 12:16 PM Gilles Sadowski 
wrote:

> Le mer. 5 juin 2019 à 17:57, James Carman  a
> écrit :
> >
> > I’m having a hard time understanding the comparing APIs use case.  If I
> > were to want to try that, I’d create a branch and import the new
> dependency
> > version and see what breaks.  The performance part I wouldn’t think I’d
> use
> > one code base either.  I’m not suggesting my way is the only or best way,
> > just explaining why I’m having a hard time understanding what you’re
> > doing.  Maybe this will be a learning opportunity for me! :)
>
> Case mainly in point is getting to the first release of new components.
> This is happening now for [Imaging], and will be soon (hopefully) for
> [Numbers], [Statistics] and [Geometry].
>
> IIUC, the former is going to release a beta version without modifying
> the top-level package name.  This will create the possibility of JAR
> hell (when 1.0 will be out).
>
> Since we don't have that much review/feedback on these new and/or
> refactored codes, I thought we could be on a safer ground if we first
> release beta version(s) that
>  * won't be subject to JAR hell and
>  * will be easy (i.e. just add the dependency in the POM file) to
>integrate for people kind enough to give it a try.
>[If it's not easy[1], they won't do it.]
>
> Regards,
> Gilles
>
> [1] Like: You "just" have to install "git", check out the source, install
> "maven", run the "package" goal, then move the "target/whatever.jar"
> file to where your code will look for it.
>
> >
> > On Wed, Jun 5, 2019 at 11:33 AM Gilles Sadowski 
> > wrote:
> >
> > > Le mer. 5 juin 2019 à 17:04, James Carman 
> a
> > > écrit :
> > > >
> > > > What sort of comparison are you looking to do within the same code?
> > > > Performance?
> > >
> > > Yes, that's one possibility; another is comparing different APIs.
> > >
> > > 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
>
>

Re: [All] Alpha/beta releases

[James Carman]

On Wed, Jun 5, 2019 at 12:16 PM Gilles Sadowski  wrote:
>
> Case mainly in point is getting to the first release of new components.
> This is happening now for [Imaging], and will be soon (hopefully) for
> [Numbers], [Statistics] and [Geometry].
>

Okay, so the main issue is getting releases out into the hands of
folks sooner rather than later.  That, I can get behind for sure.

> IIUC, the former is going to release a beta version without modifying
> the top-level package name.  This will create the possibility of JAR
> hell (when 1.0 will be out).
>

I think the package rename piece is the part that is throwing me off.
I'd rather release something as "beta" or "alpha" (we've done this
before IIRC) where folks understand that things can change when the
final release comes out.  I would leave the package names intact (they
should be whatever they're going to be in the final release, barring
any reorganization or whatever), however.

> Since we don't have that much review/feedback on these new and/or
> refactored codes, I thought we could be on a safer ground if we first
> release beta version(s) that
>  * won't be subject to JAR hell and
>  * will be easy (i.e. just add the dependency in the POM file) to
>integrate for people kind enough to give it a try.
>[If it's not easy[1], they won't do it.]
>

Unless you also change the maven coordinates, these two flavors of the
same artifact alpha/beta and "real" will not be able to coexist in the
same maven project, so the JAR hell issue isn't possible.  You can't
just change the package names and allow them to coexist.  That's why
we change both when we do a major release.

In all, I really like the spirit of this, but I think the answer would
be to just release them as alphas/betas while keeping everything else
(artifactId/package name) intact.  Release early, release often! :)

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

Re: [beanutils] Towards 1.10

[Rob Tompkins]

I suppose doing both wouldn’t be unreasonable. It’ll take me a few weeks as I’m 
in the ramp up phase at a new gig. But I’ll start heading that direction.

-Rob

> On Jun 5, 2019, at 8:39 AM, Melloware  wrote:
> 
> Do you think we could also get a BeanUtils2 release while we are at it?  It 
> supports Java 8 and has many fixes in the last 3 years.
> 
> 
> On 6/5/2019 8:37 AM, Rob Tompkins wrote:
>> I can try to backport the fix to the 1.X branch.
>> 
>> -Rob
>> 
>> On 6/5/2019 8:09 AM, Melloware wrote:
>>> Rob,
>>> 
>>> I 100% agree since CVE-2014-0114 has been fixed in BeanUtils I think we 
>>> need a release.
>>> 
>>> However the 1.X branch seems dormant it seems for the last 3 years 
>>> everything has been working on is BeanUtils2 which is where all the fixes 
>>> have been made?
>>> 
>>> Mello
>>> 
>>> 
>>> -
>>> 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] Alpha/beta releases

[Gilles Sadowski]

Le mer. 5 juin 2019 à 17:57, James Carman  a écrit :
>
> I’m having a hard time understanding the comparing APIs use case.  If I
> were to want to try that, I’d create a branch and import the new dependency
> version and see what breaks.  The performance part I wouldn’t think I’d use
> one code base either.  I’m not suggesting my way is the only or best way,
> just explaining why I’m having a hard time understanding what you’re
> doing.  Maybe this will be a learning opportunity for me! :)

Case mainly in point is getting to the first release of new components.
This is happening now for [Imaging], and will be soon (hopefully) for
[Numbers], [Statistics] and [Geometry].

IIUC, the former is going to release a beta version without modifying
the top-level package name.  This will create the possibility of JAR
hell (when 1.0 will be out).

Since we don't have that much review/feedback on these new and/or
refactored codes, I thought we could be on a safer ground if we first
release beta version(s) that
 * won't be subject to JAR hell and
 * will be easy (i.e. just add the dependency in the POM file) to
   integrate for people kind enough to give it a try.
   [If it's not easy[1], they won't do it.]

Regards,
Gilles

[1] Like: You "just" have to install "git", check out the source, install
"maven", run the "package" goal, then move the "target/whatever.jar"
file to where your code will look for it.

>
> On Wed, Jun 5, 2019 at 11:33 AM Gilles Sadowski 
> wrote:
>
> > Le mer. 5 juin 2019 à 17:04, James Carman  a
> > écrit :
> > >
> > > What sort of comparison are you looking to do within the same code?
> > > Performance?
> >
> > Yes, that's one possibility; another is comparing different APIs.
> >
> > 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

Re: [All] Alpha/beta releases

[James Carman]

I’m having a hard time understanding the comparing APIs use case.  If I
were to want to try that, I’d create a branch and import the new dependency
version and see what breaks.  The performance part I wouldn’t think I’d use
one code base either.  I’m not suggesting my way is the only or best way,
just explaining why I’m having a hard time understanding what you’re
doing.  Maybe this will be a learning opportunity for me! :)



On Wed, Jun 5, 2019 at 11:33 AM Gilles Sadowski 
wrote:

> Le mer. 5 juin 2019 à 17:04, James Carman  a
> écrit :
> >
> > What sort of comparison are you looking to do within the same code?
> > Performance?
>
> Yes, that's one possibility; another is comparing different APIs.
>
> Gilles
>
>  [...]
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [All] Alpha/beta releases

[Matt Sicker]

Maybe we should have a separate maven repo for alpha and beta releases.
That could make them less likely to cause jar hell conflicts. It could even
be similar to snapshots if they’re not voted on.

On Wed, Jun 5, 2019 at 10:33, Gilles Sadowski  wrote:

> Le mer. 5 juin 2019 à 17:04, James Carman  a
> écrit :
> >
> > What sort of comparison are you looking to do within the same code?
> > Performance?
>
> Yes, that's one possibility; another is comparing different APIs.
>
> Gilles
>
>  [...]
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
> --
Matt Sicker 

Re: [All] Alpha/beta releases

[Gilles Sadowski]

Le mer. 5 juin 2019 à 17:04, James Carman  a écrit :
>
> What sort of comparison are you looking to do within the same code?
> Performance?

Yes, that's one possibility; another is comparing different APIs.

Gilles

 [...]

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

Re: [All] Alpha/beta releases

[Gilles Sadowski]

Le mer. 5 juin 2019 à 17:02, James Carman  a écrit :
>
> Wouldn’t you have a package collision between two different alpha releases?

Ah, I got it:
In "1.0-alpha1", class "o.a.c.somecomp.alpha1.Foo".
In "1.2-alpha1", class "o.a.c.somecomp.alpha1.Foo".

But those 2 classes can very well be different and incompatible.
However, we can consider that after the release of "1.0", all
"1.0-alphaX" releases are obsolete and serve zero purpose.
The beta releases are "comparable" only within the same base
(unreleased) version.

Gilles

>
> On Wed, Jun 5, 2019 at 10:56 AM Gilles Sadowski 
> wrote:
>
> > Le mer. 5 juin 2019 à 16:47, James Carman  a
> > écrit :
> > >
> > > Ok, what about 1.2?
> >
> > How is it different?
> >
> > Gilles
> >
> > >
> > > On Wed, Jun 5, 2019 at 10:44 AM Gilles Sadowski 
> > > wrote:
> > >
> > > > Le mer. 5 juin 2019 à 16:18, James Carman 
> > a
> > > > écrit :
> > > > >
> > > > > What happens if/when you want to release a 2.0-alpha1 in the future?
> > > >
> > > > Hmm, what happens?
> > > > [At point, we'd have renamed "o.a.c.compid" to ""o.a.c.compid2".]
> > > >
> > > > Gilles
> > > >
> > > > >
> > > > > On Tue, Jun 4, 2019 at 6:53 AM Gilles Sadowski  > >
> > > > wrote:
> > > > >
> > > > > > Hello.
> > > > > >
> > > > > > Does someone see a practical way to automate package names
> > > > > > and source files conversions so that each all alpha/beta releases
> > > > > > can be used together (e.g. to compare their behaviours).
> > > > > >
> > > > > > I mean, for release version "1.0-alpha1", the top-level package
> > > > > > name "o.a.c.compid" would be turned into "o.a.c.compid.alpha1".
> > > > > >
> > > > > > This would also solve issues with compatibility checkers (with the
> > > > > > added bonus that JAR hell could never happen).
> > > > > >
> > > > > > Couldn't the "shade" plugin be put to use (so that all artefacts
> > have
> > > > > > their top-level package transparently set to "o.a.c.compid.alpha1"
> > > > > > and all the tools operate on that)?
> > > > > >
> > > > > >
> > > > > > Regards,
> > > > > > Gilles
> > > > > >

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

Re: [All] Alpha/beta releases

[James Carman]

What sort of comparison are you looking to do within the same code?
Performance?

On Wed, Jun 5, 2019 at 10:54 AM Gilles Sadowski 
wrote:

> Le mer. 5 juin 2019 à 16:22, sebb  a écrit :
> >
> > On Wed, 5 Jun 2019 at 15:06, Gilles Sadowski 
> wrote:
> > >
> > > Le mer. 5 juin 2019 à 15:59, sebb  a écrit :
> > > >
> > > > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski 
> wrote:
> > > > >
> > > > > Le mer. 5 juin 2019 à 15:18, sebb  a écrit :
> > > > > >
> > > > > > I'm not sure what problem this is trying to solve.
> > > > > >
> > > > > > How is it intended to use the facility?
> > > > >
> > > > > Ideally:
> > > > > $ mvn -Pbetarelease [... other settings ...]
> -Dbetasubversion=alpha1
> > > > > where the latter profile would take care of changing the
> > > > > toplevel package name
> > > > > o.a.c.somecomp
> > > > > to
> > > > > o.a.c.somecomp.alpha1
> > > > >
> > > > > And, if the upcoming version is, say, "2.3", the generated
> > > > > artefact(s) would be:
> > > > >   commons-somecomp-2.3-alpha1
> > > >
> > > > That's not what I intended to ask.
> > > >
> > > > What problem does the ability to readily change the package name
> actually solve?
> > > > And how are the amended packages going to be used?
> > >
> > > Maybe, I don't understand the question.
> > > The purpose is to be able to quickly produce several beta releases that
> > > don't have to be compatible with other beta releases but that can
> coexist
> > > for the purpose of allowing users to compare the impact of the changes.
> >
> > I don't understand how the user can actually test the release unless
> > they also produce code that is likewise shaded to invoke the
> > appropriate version of the package.
>
> Of course, if they want to test "alpha1", they need to depend on it,
> and modify their code accordingly.
>
> > Surely it would be easier to test the code if it used the standard
> > package names, i.e. no need to change the user code?
>
> Yes, but that means that we cannot compare "alpha1" and "alpha2" in
> the same code.
>
> > i.e. take their app, and run it against the relevant alpha- or
> beta-release.
>
> Then the main concern is the possibility of JAR hell (e.g. when several
> "alpha" are in the classpath).
>
> > This is already possible if the user has the ability to compile the
> > component from source.
>
> I think that If we hope to get help from users, we should provide a JAR.
>
> Regards,
> Gilles
>
> >
> > > Gilles
> > >
> > > >
> > > > > Regards,
> > > > > Gilles
> > > > >
> > > > > >
> > > > > > On Tue, 4 Jun 2019 at 17:35, Matt Sicker 
> wrote:
> > > > > > >
> > > > > > > This sounds like a shade feature, yes. However, in order to
> > > > > > > automatically extract the version extra data and detect a
> version
> > > > > > > keyword like "alpha" may require some additional code, though
> maybe
> > > > > > > the shade plugin already supports that.
> > > > > > >
> > > > > > > Alternatively, JUnit 5.x uses a tool called API Guardian for
> marking
> > > > > > > which APIs are stable or not:
> > > > > > > https://github.com/apiguardian-team/apiguardian
> > > > > > >
> > > > > > > On Tue, 4 Jun 2019 at 05:53, Gilles Sadowski <
> gillese...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Hello.
> > > > > > > >
> > > > > > > > Does someone see a practical way to automate package names
> > > > > > > > and source files conversions so that each all alpha/beta
> releases
> > > > > > > > can be used together (e.g. to compare their behaviours).
> > > > > > > >
> > > > > > > > I mean, for release version "1.0-alpha1", the top-level
> package
> > > > > > > > name "o.a.c.compid" would be turned into
> "o.a.c.compid.alpha1".
> > > > > > > >
> > > > > > > > This would also solve issues with compatibility checkers
> (with the
> > > > > > > > added bonus that JAR hell could never happen).
> > > > > > > >
> > > > > > > > Couldn't the "shade" plugin be put to use (so that all
> artefacts have
> > > > > > > > their top-level package transparently set to
> "o.a.c.compid.alpha1"
> > > > > > > > and all the tools operate on that)?
> > > > > > > >
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Gilles
> > > > > > > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [All] Alpha/beta releases

[James Carman]

Wouldn’t you have a package collision between two different alpha releases?

On Wed, Jun 5, 2019 at 10:56 AM Gilles Sadowski 
wrote:

> Le mer. 5 juin 2019 à 16:47, James Carman  a
> écrit :
> >
> > Ok, what about 1.2?
>
> How is it different?
>
> Gilles
>
> >
> > On Wed, Jun 5, 2019 at 10:44 AM Gilles Sadowski 
> > wrote:
> >
> > > Le mer. 5 juin 2019 à 16:18, James Carman 
> a
> > > écrit :
> > > >
> > > > What happens if/when you want to release a 2.0-alpha1 in the future?
> > >
> > > Hmm, what happens?
> > > [At point, we'd have renamed "o.a.c.compid" to ""o.a.c.compid2".]
> > >
> > > Gilles
> > >
> > > >
> > > > On Tue, Jun 4, 2019 at 6:53 AM Gilles Sadowski  >
> > > wrote:
> > > >
> > > > > Hello.
> > > > >
> > > > > Does someone see a practical way to automate package names
> > > > > and source files conversions so that each all alpha/beta releases
> > > > > can be used together (e.g. to compare their behaviours).
> > > > >
> > > > > I mean, for release version "1.0-alpha1", the top-level package
> > > > > name "o.a.c.compid" would be turned into "o.a.c.compid.alpha1".
> > > > >
> > > > > This would also solve issues with compatibility checkers (with the
> > > > > added bonus that JAR hell could never happen).
> > > > >
> > > > > Couldn't the "shade" plugin be put to use (so that all artefacts
> have
> > > > > their top-level package transparently set to "o.a.c.compid.alpha1"
> > > > > and all the tools operate on that)?
> > > > >
> > > > >
> > > > > Regards,
> > > > > Gilles
> > > > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [All] Alpha/beta releases

[Gilles Sadowski]

Le mer. 5 juin 2019 à 16:47, James Carman  a écrit :
>
> Ok, what about 1.2?

How is it different?

Gilles

>
> On Wed, Jun 5, 2019 at 10:44 AM Gilles Sadowski 
> wrote:
>
> > Le mer. 5 juin 2019 à 16:18, James Carman  a
> > écrit :
> > >
> > > What happens if/when you want to release a 2.0-alpha1 in the future?
> >
> > Hmm, what happens?
> > [At point, we'd have renamed "o.a.c.compid" to ""o.a.c.compid2".]
> >
> > Gilles
> >
> > >
> > > On Tue, Jun 4, 2019 at 6:53 AM Gilles Sadowski 
> > wrote:
> > >
> > > > Hello.
> > > >
> > > > Does someone see a practical way to automate package names
> > > > and source files conversions so that each all alpha/beta releases
> > > > can be used together (e.g. to compare their behaviours).
> > > >
> > > > I mean, for release version "1.0-alpha1", the top-level package
> > > > name "o.a.c.compid" would be turned into "o.a.c.compid.alpha1".
> > > >
> > > > This would also solve issues with compatibility checkers (with the
> > > > added bonus that JAR hell could never happen).
> > > >
> > > > Couldn't the "shade" plugin be put to use (so that all artefacts have
> > > > their top-level package transparently set to "o.a.c.compid.alpha1"
> > > > and all the tools operate on that)?
> > > >
> > > >
> > > > Regards,
> > > > Gilles
> > > >

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

Re: [All] Alpha/beta releases

[Gilles Sadowski]

Le mer. 5 juin 2019 à 16:22, sebb  a écrit :
>
> On Wed, 5 Jun 2019 at 15:06, Gilles Sadowski  wrote:
> >
> > Le mer. 5 juin 2019 à 15:59, sebb  a écrit :
> > >
> > > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski  wrote:
> > > >
> > > > Le mer. 5 juin 2019 à 15:18, sebb  a écrit :
> > > > >
> > > > > I'm not sure what problem this is trying to solve.
> > > > >
> > > > > How is it intended to use the facility?
> > > >
> > > > Ideally:
> > > > $ mvn -Pbetarelease [... other settings ...] -Dbetasubversion=alpha1
> > > > where the latter profile would take care of changing the
> > > > toplevel package name
> > > > o.a.c.somecomp
> > > > to
> > > > o.a.c.somecomp.alpha1
> > > >
> > > > And, if the upcoming version is, say, "2.3", the generated
> > > > artefact(s) would be:
> > > >   commons-somecomp-2.3-alpha1
> > >
> > > That's not what I intended to ask.
> > >
> > > What problem does the ability to readily change the package name actually 
> > > solve?
> > > And how are the amended packages going to be used?
> >
> > Maybe, I don't understand the question.
> > The purpose is to be able to quickly produce several beta releases that
> > don't have to be compatible with other beta releases but that can coexist
> > for the purpose of allowing users to compare the impact of the changes.
>
> I don't understand how the user can actually test the release unless
> they also produce code that is likewise shaded to invoke the
> appropriate version of the package.

Of course, if they want to test "alpha1", they need to depend on it,
and modify their code accordingly.

> Surely it would be easier to test the code if it used the standard
> package names, i.e. no need to change the user code?

Yes, but that means that we cannot compare "alpha1" and "alpha2" in
the same code.

> i.e. take their app, and run it against the relevant alpha- or beta-release.

Then the main concern is the possibility of JAR hell (e.g. when several
"alpha" are in the classpath).

> This is already possible if the user has the ability to compile the
> component from source.

I think that If we hope to get help from users, we should provide a JAR.

Regards,
Gilles

>
> > Gilles
> >
> > >
> > > > Regards,
> > > > Gilles
> > > >
> > > > >
> > > > > On Tue, 4 Jun 2019 at 17:35, Matt Sicker  wrote:
> > > > > >
> > > > > > This sounds like a shade feature, yes. However, in order to
> > > > > > automatically extract the version extra data and detect a version
> > > > > > keyword like "alpha" may require some additional code, though maybe
> > > > > > the shade plugin already supports that.
> > > > > >
> > > > > > Alternatively, JUnit 5.x uses a tool called API Guardian for marking
> > > > > > which APIs are stable or not:
> > > > > > https://github.com/apiguardian-team/apiguardian
> > > > > >
> > > > > > On Tue, 4 Jun 2019 at 05:53, Gilles Sadowski  
> > > > > > wrote:
> > > > > > >
> > > > > > > Hello.
> > > > > > >
> > > > > > > Does someone see a practical way to automate package names
> > > > > > > and source files conversions so that each all alpha/beta releases
> > > > > > > can be used together (e.g. to compare their behaviours).
> > > > > > >
> > > > > > > I mean, for release version "1.0-alpha1", the top-level package
> > > > > > > name "o.a.c.compid" would be turned into "o.a.c.compid.alpha1".
> > > > > > >
> > > > > > > This would also solve issues with compatibility checkers (with the
> > > > > > > added bonus that JAR hell could never happen).
> > > > > > >
> > > > > > > Couldn't the "shade" plugin be put to use (so that all artefacts 
> > > > > > > have
> > > > > > > their top-level package transparently set to "o.a.c.compid.alpha1"
> > > > > > > and all the tools operate on that)?
> > > > > > >
> > > > > > >
> > > > > > > Regards,
> > > > > > > Gilles
> > > > > > >

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

Re: [All] Alpha/beta releases

[James Carman]

Ok, what about 1.2?

On Wed, Jun 5, 2019 at 10:44 AM Gilles Sadowski 
wrote:

> Le mer. 5 juin 2019 à 16:18, James Carman  a
> écrit :
> >
> > What happens if/when you want to release a 2.0-alpha1 in the future?
>
> Hmm, what happens?
> [At point, we'd have renamed "o.a.c.compid" to ""o.a.c.compid2".]
>
> Gilles
>
> >
> > On Tue, Jun 4, 2019 at 6:53 AM Gilles Sadowski 
> wrote:
> >
> > > Hello.
> > >
> > > Does someone see a practical way to automate package names
> > > and source files conversions so that each all alpha/beta releases
> > > can be used together (e.g. to compare their behaviours).
> > >
> > > I mean, for release version "1.0-alpha1", the top-level package
> > > name "o.a.c.compid" would be turned into "o.a.c.compid.alpha1".
> > >
> > > This would also solve issues with compatibility checkers (with the
> > > added bonus that JAR hell could never happen).
> > >
> > > Couldn't the "shade" plugin be put to use (so that all artefacts have
> > > their top-level package transparently set to "o.a.c.compid.alpha1"
> > > and all the tools operate on that)?
> > >
> > >
> > > Regards,
> > > Gilles
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [All] Alpha/beta releases

[Gilles Sadowski]

Le mer. 5 juin 2019 à 16:18, James Carman  a écrit :
>
> What happens if/when you want to release a 2.0-alpha1 in the future?

Hmm, what happens?
[At point, we'd have renamed "o.a.c.compid" to ""o.a.c.compid2".]

Gilles

>
> On Tue, Jun 4, 2019 at 6:53 AM Gilles Sadowski  wrote:
>
> > Hello.
> >
> > Does someone see a practical way to automate package names
> > and source files conversions so that each all alpha/beta releases
> > can be used together (e.g. to compare their behaviours).
> >
> > I mean, for release version "1.0-alpha1", the top-level package
> > name "o.a.c.compid" would be turned into "o.a.c.compid.alpha1".
> >
> > This would also solve issues with compatibility checkers (with the
> > added bonus that JAR hell could never happen).
> >
> > Couldn't the "shade" plugin be put to use (so that all artefacts have
> > their top-level package transparently set to "o.a.c.compid.alpha1"
> > and all the tools operate on that)?
> >
> >
> > Regards,
> > Gilles
> >

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

Re: [All] Alpha/beta releases

[Gilles Sadowski]

Le mer. 5 juin 2019 à 16:18, Gary Gregory  a écrit :
>
> On Wed, Jun 5, 2019 at 10:06 AM Gilles Sadowski 
> wrote:
>
> > Le mer. 5 juin 2019 à 15:59, sebb  a écrit :
> > >
> > > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski 
> > wrote:
> > > >
> > > > Le mer. 5 juin 2019 à 15:18, sebb  a écrit :
> > > > >
> > > > > I'm not sure what problem this is trying to solve.
> > > > >
> > > > > How is it intended to use the facility?
> > > >
> > > > Ideally:
> > > > $ mvn -Pbetarelease [... other settings ...]
> > -Dbetasubversion=alpha1
> > > > where the latter profile would take care of changing the
> > > > toplevel package name
> > > > o.a.c.somecomp
> > > > to
> > > > o.a.c.somecomp.alpha1
> > > >
> > > > And, if the upcoming version is, say, "2.3", the generated
> > > > artefact(s) would be:
> > > >   commons-somecomp-2.3-alpha1
> > >
> > > That's not what I intended to ask.
> > >
> > > What problem does the ability to readily change the package name
> > actually solve?
> > > And how are the amended packages going to be used?
> >
> > Maybe, I don't understand the question.
> > The purpose is to be able to quickly produce several beta releases that
> > don't have to be compatible with other beta releases but that can coexist
> > for the purpose of allowing users to compare the impact of the changes.
> >
>
> This is over the top IMO. That's what JApiCmp is for unless I am missing
> something.

Seems so.  Or I am.
I'm talking about producing official releases; no idea how japicmp
is related...

>
> Gayr
>
>
> >
> > Gilles
> >
> > >
> > > > Regards,
> > > > Gilles
> > > >
> > > > >
> > > > > On Tue, 4 Jun 2019 at 17:35, Matt Sicker  wrote:
> > > > > >
> > > > > > This sounds like a shade feature, yes. However, in order to
> > > > > > automatically extract the version extra data and detect a version
> > > > > > keyword like "alpha" may require some additional code, though maybe
> > > > > > the shade plugin already supports that.
> > > > > >
> > > > > > Alternatively, JUnit 5.x uses a tool called API Guardian for
> > marking
> > > > > > which APIs are stable or not:
> > > > > > https://github.com/apiguardian-team/apiguardian
> > > > > >
> > > > > > On Tue, 4 Jun 2019 at 05:53, Gilles Sadowski 
> > wrote:
> > > > > > >
> > > > > > > Hello.
> > > > > > >
> > > > > > > Does someone see a practical way to automate package names
> > > > > > > and source files conversions so that each all alpha/beta releases
> > > > > > > can be used together (e.g. to compare their behaviours).
> > > > > > >
> > > > > > > I mean, for release version "1.0-alpha1", the top-level package
> > > > > > > name "o.a.c.compid" would be turned into "o.a.c.compid.alpha1".
> > > > > > >
> > > > > > > This would also solve issues with compatibility checkers (with
> > the
> > > > > > > added bonus that JAR hell could never happen).
> > > > > > >
> > > > > > > Couldn't the "shade" plugin be put to use (so that all artefacts
> > have
> > > > > > > their top-level package transparently set to
> > "o.a.c.compid.alpha1"
> > > > > > > and all the tools operate on that)?
> > > > > > >
> > > > > > >
> > > > > > > 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

Re: [All] Alpha/beta releases

[sebb]

On Wed, 5 Jun 2019 at 15:06, Gilles Sadowski  wrote:
>
> Le mer. 5 juin 2019 à 15:59, sebb  a écrit :
> >
> > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski  wrote:
> > >
> > > Le mer. 5 juin 2019 à 15:18, sebb  a écrit :
> > > >
> > > > I'm not sure what problem this is trying to solve.
> > > >
> > > > How is it intended to use the facility?
> > >
> > > Ideally:
> > > $ mvn -Pbetarelease [... other settings ...] -Dbetasubversion=alpha1
> > > where the latter profile would take care of changing the
> > > toplevel package name
> > > o.a.c.somecomp
> > > to
> > > o.a.c.somecomp.alpha1
> > >
> > > And, if the upcoming version is, say, "2.3", the generated
> > > artefact(s) would be:
> > >   commons-somecomp-2.3-alpha1
> >
> > That's not what I intended to ask.
> >
> > What problem does the ability to readily change the package name actually 
> > solve?
> > And how are the amended packages going to be used?
>
> Maybe, I don't understand the question.
> The purpose is to be able to quickly produce several beta releases that
> don't have to be compatible with other beta releases but that can coexist
> for the purpose of allowing users to compare the impact of the changes.

I don't understand how the user can actually test the release unless
they also produce code that is likewise shaded to invoke the
appropriate version of the package.

Surely it would be easier to test the code if it used the standard
package names, i.e. no need to change the user code?
i.e. take their app, and run it against the relevant alpha- or beta-release.
This is already possible if the user has the ability to compile the
component from source.

> Gilles
>
> >
> > > Regards,
> > > Gilles
> > >
> > > >
> > > > On Tue, 4 Jun 2019 at 17:35, Matt Sicker  wrote:
> > > > >
> > > > > This sounds like a shade feature, yes. However, in order to
> > > > > automatically extract the version extra data and detect a version
> > > > > keyword like "alpha" may require some additional code, though maybe
> > > > > the shade plugin already supports that.
> > > > >
> > > > > Alternatively, JUnit 5.x uses a tool called API Guardian for marking
> > > > > which APIs are stable or not:
> > > > > https://github.com/apiguardian-team/apiguardian
> > > > >
> > > > > On Tue, 4 Jun 2019 at 05:53, Gilles Sadowski  
> > > > > wrote:
> > > > > >
> > > > > > Hello.
> > > > > >
> > > > > > Does someone see a practical way to automate package names
> > > > > > and source files conversions so that each all alpha/beta releases
> > > > > > can be used together (e.g. to compare their behaviours).
> > > > > >
> > > > > > I mean, for release version "1.0-alpha1", the top-level package
> > > > > > name "o.a.c.compid" would be turned into "o.a.c.compid.alpha1".
> > > > > >
> > > > > > This would also solve issues with compatibility checkers (with the
> > > > > > added bonus that JAR hell could never happen).
> > > > > >
> > > > > > Couldn't the "shade" plugin be put to use (so that all artefacts 
> > > > > > have
> > > > > > their top-level package transparently set to "o.a.c.compid.alpha1"
> > > > > > and all the tools operate on that)?
> > > > > >
> > > > > >
> > > > > > 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

Re: [All] Alpha/beta releases

[Gary Gregory]

On Wed, Jun 5, 2019 at 10:06 AM Gilles Sadowski 
wrote:

> Le mer. 5 juin 2019 à 15:59, sebb  a écrit :
> >
> > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski 
> wrote:
> > >
> > > Le mer. 5 juin 2019 à 15:18, sebb  a écrit :
> > > >
> > > > I'm not sure what problem this is trying to solve.
> > > >
> > > > How is it intended to use the facility?
> > >
> > > Ideally:
> > > $ mvn -Pbetarelease [... other settings ...]
> -Dbetasubversion=alpha1
> > > where the latter profile would take care of changing the
> > > toplevel package name
> > > o.a.c.somecomp
> > > to
> > > o.a.c.somecomp.alpha1
> > >
> > > And, if the upcoming version is, say, "2.3", the generated
> > > artefact(s) would be:
> > >   commons-somecomp-2.3-alpha1
> >
> > That's not what I intended to ask.
> >
> > What problem does the ability to readily change the package name
> actually solve?
> > And how are the amended packages going to be used?
>
> Maybe, I don't understand the question.
> The purpose is to be able to quickly produce several beta releases that
> don't have to be compatible with other beta releases but that can coexist
> for the purpose of allowing users to compare the impact of the changes.
>

This is over the top IMO. That's what JApiCmp is for unless I am missing
something.

Gayr


>
> Gilles
>
> >
> > > Regards,
> > > Gilles
> > >
> > > >
> > > > On Tue, 4 Jun 2019 at 17:35, Matt Sicker  wrote:
> > > > >
> > > > > This sounds like a shade feature, yes. However, in order to
> > > > > automatically extract the version extra data and detect a version
> > > > > keyword like "alpha" may require some additional code, though maybe
> > > > > the shade plugin already supports that.
> > > > >
> > > > > Alternatively, JUnit 5.x uses a tool called API Guardian for
> marking
> > > > > which APIs are stable or not:
> > > > > https://github.com/apiguardian-team/apiguardian
> > > > >
> > > > > On Tue, 4 Jun 2019 at 05:53, Gilles Sadowski 
> wrote:
> > > > > >
> > > > > > Hello.
> > > > > >
> > > > > > Does someone see a practical way to automate package names
> > > > > > and source files conversions so that each all alpha/beta releases
> > > > > > can be used together (e.g. to compare their behaviours).
> > > > > >
> > > > > > I mean, for release version "1.0-alpha1", the top-level package
> > > > > > name "o.a.c.compid" would be turned into "o.a.c.compid.alpha1".
> > > > > >
> > > > > > This would also solve issues with compatibility checkers (with
> the
> > > > > > added bonus that JAR hell could never happen).
> > > > > >
> > > > > > Couldn't the "shade" plugin be put to use (so that all artefacts
> have
> > > > > > their top-level package transparently set to
> "o.a.c.compid.alpha1"
> > > > > > and all the tools operate on that)?
> > > > > >
> > > > > >
> > > > > > Regards,
> > > > > > Gilles
> > > > > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [All] Alpha/beta releases

[James Carman]

What happens if/when you want to release a 2.0-alpha1 in the future?

On Tue, Jun 4, 2019 at 6:53 AM Gilles Sadowski  wrote:

> Hello.
>
> Does someone see a practical way to automate package names
> and source files conversions so that each all alpha/beta releases
> can be used together (e.g. to compare their behaviours).
>
> I mean, for release version "1.0-alpha1", the top-level package
> name "o.a.c.compid" would be turned into "o.a.c.compid.alpha1".
>
> This would also solve issues with compatibility checkers (with the
> added bonus that JAR hell could never happen).
>
> Couldn't the "shade" plugin be put to use (so that all artefacts have
> their top-level package transparently set to "o.a.c.compid.alpha1"
> and all the tools operate on that)?
>
>
> Regards,
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [All] Alpha/beta releases

[Gilles Sadowski]

Le mer. 5 juin 2019 à 16:04, Gary Gregory  a écrit :
>
> On Wed, Jun 5, 2019 at 9:59 AM sebb  wrote:
>
> > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski  wrote:
> > >
> > > Le mer. 5 juin 2019 à 15:18, sebb  a écrit :
> > > >
> > > > I'm not sure what problem this is trying to solve.
> > > >
> > > > How is it intended to use the facility?
> > >
> > > Ideally:
> > > $ mvn -Pbetarelease [... other settings ...] -Dbetasubversion=alpha1
> > > where the latter profile would take care of changing the
> > > toplevel package name
> > > o.a.c.somecomp
> > > to
> > > o.a.c.somecomp.alpha1
> > >
> > > And, if the upcoming version is, say, "2.3", the generated
> > > artefact(s) would be:
> > >   commons-somecomp-2.3-alpha1
> >
> > That's not what I intended to ask.
> >
> > What problem does the ability to readily change the package name actually
> > solve?
> > And how are the amended packages going to be used?
> >
>
> Also, the renamed sources would need to be in git as well.

The script/profile/whatever could be:
 1. create a "beta-release-2.3-alpha1" branch
 2. perform the top-level package name change
 3. commit
 4. proceed as usual

Gilles

> Gary
>
>
> >
> > > Regards,
> > > Gilles
> > >
> > > >
> > > > On Tue, 4 Jun 2019 at 17:35, Matt Sicker  wrote:
> > > > >
> > > > > This sounds like a shade feature, yes. However, in order to
> > > > > automatically extract the version extra data and detect a version
> > > > > keyword like "alpha" may require some additional code, though maybe
> > > > > the shade plugin already supports that.
> > > > >
> > > > > Alternatively, JUnit 5.x uses a tool called API Guardian for marking
> > > > > which APIs are stable or not:
> > > > > https://github.com/apiguardian-team/apiguardian
> > > > >
> > > > > On Tue, 4 Jun 2019 at 05:53, Gilles Sadowski 
> > wrote:
> > > > > >
> > > > > > Hello.
> > > > > >
> > > > > > Does someone see a practical way to automate package names
> > > > > > and source files conversions so that each all alpha/beta releases
> > > > > > can be used together (e.g. to compare their behaviours).
> > > > > >
> > > > > > I mean, for release version "1.0-alpha1", the top-level package
> > > > > > name "o.a.c.compid" would be turned into "o.a.c.compid.alpha1".
> > > > > >
> > > > > > This would also solve issues with compatibility checkers (with the
> > > > > > added bonus that JAR hell could never happen).
> > > > > >
> > > > > > Couldn't the "shade" plugin be put to use (so that all artefacts
> > have
> > > > > > their top-level package transparently set to "o.a.c.compid.alpha1"
> > > > > > and all the tools operate on that)?
> > > > > >
> > > > > >
> > > > > > Regards,
> > > > > > Gilles

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

Re: [All] Alpha/beta releases

[Gilles Sadowski]

Le mer. 5 juin 2019 à 15:59, sebb  a écrit :
>
> On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski  wrote:
> >
> > Le mer. 5 juin 2019 à 15:18, sebb  a écrit :
> > >
> > > I'm not sure what problem this is trying to solve.
> > >
> > > How is it intended to use the facility?
> >
> > Ideally:
> > $ mvn -Pbetarelease [... other settings ...] -Dbetasubversion=alpha1
> > where the latter profile would take care of changing the
> > toplevel package name
> > o.a.c.somecomp
> > to
> > o.a.c.somecomp.alpha1
> >
> > And, if the upcoming version is, say, "2.3", the generated
> > artefact(s) would be:
> >   commons-somecomp-2.3-alpha1
>
> That's not what I intended to ask.
>
> What problem does the ability to readily change the package name actually 
> solve?
> And how are the amended packages going to be used?

Maybe, I don't understand the question.
The purpose is to be able to quickly produce several beta releases that
don't have to be compatible with other beta releases but that can coexist
for the purpose of allowing users to compare the impact of the changes.

Gilles

>
> > Regards,
> > Gilles
> >
> > >
> > > On Tue, 4 Jun 2019 at 17:35, Matt Sicker  wrote:
> > > >
> > > > This sounds like a shade feature, yes. However, in order to
> > > > automatically extract the version extra data and detect a version
> > > > keyword like "alpha" may require some additional code, though maybe
> > > > the shade plugin already supports that.
> > > >
> > > > Alternatively, JUnit 5.x uses a tool called API Guardian for marking
> > > > which APIs are stable or not:
> > > > https://github.com/apiguardian-team/apiguardian
> > > >
> > > > On Tue, 4 Jun 2019 at 05:53, Gilles Sadowski  
> > > > wrote:
> > > > >
> > > > > Hello.
> > > > >
> > > > > Does someone see a practical way to automate package names
> > > > > and source files conversions so that each all alpha/beta releases
> > > > > can be used together (e.g. to compare their behaviours).
> > > > >
> > > > > I mean, for release version "1.0-alpha1", the top-level package
> > > > > name "o.a.c.compid" would be turned into "o.a.c.compid.alpha1".
> > > > >
> > > > > This would also solve issues with compatibility checkers (with the
> > > > > added bonus that JAR hell could never happen).
> > > > >
> > > > > Couldn't the "shade" plugin be put to use (so that all artefacts have
> > > > > their top-level package transparently set to "o.a.c.compid.alpha1"
> > > > > and all the tools operate on that)?
> > > > >
> > > > >
> > > > > Regards,
> > > > > Gilles
> > > > >

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

Re: [All] Alpha/beta releases

[Gary Gregory]

On Wed, Jun 5, 2019 at 9:59 AM sebb  wrote:

> On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski  wrote:
> >
> > Le mer. 5 juin 2019 à 15:18, sebb  a écrit :
> > >
> > > I'm not sure what problem this is trying to solve.
> > >
> > > How is it intended to use the facility?
> >
> > Ideally:
> > $ mvn -Pbetarelease [... other settings ...] -Dbetasubversion=alpha1
> > where the latter profile would take care of changing the
> > toplevel package name
> > o.a.c.somecomp
> > to
> > o.a.c.somecomp.alpha1
> >
> > And, if the upcoming version is, say, "2.3", the generated
> > artefact(s) would be:
> >   commons-somecomp-2.3-alpha1
>
> That's not what I intended to ask.
>
> What problem does the ability to readily change the package name actually
> solve?
> And how are the amended packages going to be used?
>

Also, the renamed sources would need to be in git as well.

Gary


>
> > Regards,
> > Gilles
> >
> > >
> > > On Tue, 4 Jun 2019 at 17:35, Matt Sicker  wrote:
> > > >
> > > > This sounds like a shade feature, yes. However, in order to
> > > > automatically extract the version extra data and detect a version
> > > > keyword like "alpha" may require some additional code, though maybe
> > > > the shade plugin already supports that.
> > > >
> > > > Alternatively, JUnit 5.x uses a tool called API Guardian for marking
> > > > which APIs are stable or not:
> > > > https://github.com/apiguardian-team/apiguardian
> > > >
> > > > On Tue, 4 Jun 2019 at 05:53, Gilles Sadowski 
> wrote:
> > > > >
> > > > > Hello.
> > > > >
> > > > > Does someone see a practical way to automate package names
> > > > > and source files conversions so that each all alpha/beta releases
> > > > > can be used together (e.g. to compare their behaviours).
> > > > >
> > > > > I mean, for release version "1.0-alpha1", the top-level package
> > > > > name "o.a.c.compid" would be turned into "o.a.c.compid.alpha1".
> > > > >
> > > > > This would also solve issues with compatibility checkers (with the
> > > > > added bonus that JAR hell could never happen).
> > > > >
> > > > > Couldn't the "shade" plugin be put to use (so that all artefacts
> have
> > > > > their top-level package transparently set to "o.a.c.compid.alpha1"
> > > > > and all the tools operate on that)?
> > > > >
> > > > >
> > > > > Regards,
> > > > > Gilles
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > > >
> > > >
> > > >
> > > > --
> > > > Matt Sicker 
> > > >
> > > > -
> > > > 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
> > >
> >
> > -
> > 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] Alpha/beta releases

[sebb]

On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski  wrote:
>
> Le mer. 5 juin 2019 à 15:18, sebb  a écrit :
> >
> > I'm not sure what problem this is trying to solve.
> >
> > How is it intended to use the facility?
>
> Ideally:
> $ mvn -Pbetarelease [... other settings ...] -Dbetasubversion=alpha1
> where the latter profile would take care of changing the
> toplevel package name
> o.a.c.somecomp
> to
> o.a.c.somecomp.alpha1
>
> And, if the upcoming version is, say, "2.3", the generated
> artefact(s) would be:
>   commons-somecomp-2.3-alpha1

That's not what I intended to ask.

What problem does the ability to readily change the package name actually solve?
And how are the amended packages going to be used?

> Regards,
> Gilles
>
> >
> > On Tue, 4 Jun 2019 at 17:35, Matt Sicker  wrote:
> > >
> > > This sounds like a shade feature, yes. However, in order to
> > > automatically extract the version extra data and detect a version
> > > keyword like "alpha" may require some additional code, though maybe
> > > the shade plugin already supports that.
> > >
> > > Alternatively, JUnit 5.x uses a tool called API Guardian for marking
> > > which APIs are stable or not:
> > > https://github.com/apiguardian-team/apiguardian
> > >
> > > On Tue, 4 Jun 2019 at 05:53, Gilles Sadowski  wrote:
> > > >
> > > > Hello.
> > > >
> > > > Does someone see a practical way to automate package names
> > > > and source files conversions so that each all alpha/beta releases
> > > > can be used together (e.g. to compare their behaviours).
> > > >
> > > > I mean, for release version "1.0-alpha1", the top-level package
> > > > name "o.a.c.compid" would be turned into "o.a.c.compid.alpha1".
> > > >
> > > > This would also solve issues with compatibility checkers (with the
> > > > added bonus that JAR hell could never happen).
> > > >
> > > > Couldn't the "shade" plugin be put to use (so that all artefacts have
> > > > their top-level package transparently set to "o.a.c.compid.alpha1"
> > > > and all the tools operate on that)?
> > > >
> > > >
> > > > Regards,
> > > > Gilles
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
> > >
> > >
> > > --
> > > Matt Sicker 
> > >
> > > -
> > > 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
> >
>
> -
> 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] Alpha/beta releases

[Gilles Sadowski]

Le mer. 5 juin 2019 à 15:18, sebb  a écrit :
>
> I'm not sure what problem this is trying to solve.
>
> How is it intended to use the facility?

Ideally:
$ mvn -Pbetarelease [... other settings ...] -Dbetasubversion=alpha1
where the latter profile would take care of changing the
toplevel package name
o.a.c.somecomp
to
o.a.c.somecomp.alpha1

And, if the upcoming version is, say, "2.3", the generated
artefact(s) would be:
  commons-somecomp-2.3-alpha1

Regards,
Gilles

>
> On Tue, 4 Jun 2019 at 17:35, Matt Sicker  wrote:
> >
> > This sounds like a shade feature, yes. However, in order to
> > automatically extract the version extra data and detect a version
> > keyword like "alpha" may require some additional code, though maybe
> > the shade plugin already supports that.
> >
> > Alternatively, JUnit 5.x uses a tool called API Guardian for marking
> > which APIs are stable or not:
> > https://github.com/apiguardian-team/apiguardian
> >
> > On Tue, 4 Jun 2019 at 05:53, Gilles Sadowski  wrote:
> > >
> > > Hello.
> > >
> > > Does someone see a practical way to automate package names
> > > and source files conversions so that each all alpha/beta releases
> > > can be used together (e.g. to compare their behaviours).
> > >
> > > I mean, for release version "1.0-alpha1", the top-level package
> > > name "o.a.c.compid" would be turned into "o.a.c.compid.alpha1".
> > >
> > > This would also solve issues with compatibility checkers (with the
> > > added bonus that JAR hell could never happen).
> > >
> > > Couldn't the "shade" plugin be put to use (so that all artefacts have
> > > their top-level package transparently set to "o.a.c.compid.alpha1"
> > > and all the tools operate on that)?
> > >
> > >
> > > Regards,
> > > Gilles
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> >
> >
> > --
> > Matt Sicker 
> >
> > -
> > 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
>

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

Will there be a SCXML2 release any time?

[Christofer Dutz]

Hi all,

Just wanted to ask if we can expect a release of SCXML2 soon?
Otherwise we’ll have to drop that component we were using it in the PLC4X 
project.
Don’t want to have our release-managers do the extra checks needed for having 
SNAPSHOTS in our releases.

Chris

Re: [All] Alpha/beta releases

[sebb]

I'm not sure what problem this is trying to solve.

How is it intended to use the facility?

On Tue, 4 Jun 2019 at 17:35, Matt Sicker  wrote:
>
> This sounds like a shade feature, yes. However, in order to
> automatically extract the version extra data and detect a version
> keyword like "alpha" may require some additional code, though maybe
> the shade plugin already supports that.
>
> Alternatively, JUnit 5.x uses a tool called API Guardian for marking
> which APIs are stable or not:
> https://github.com/apiguardian-team/apiguardian
>
> On Tue, 4 Jun 2019 at 05:53, Gilles Sadowski  wrote:
> >
> > Hello.
> >
> > Does someone see a practical way to automate package names
> > and source files conversions so that each all alpha/beta releases
> > can be used together (e.g. to compare their behaviours).
> >
> > I mean, for release version "1.0-alpha1", the top-level package
> > name "o.a.c.compid" would be turned into "o.a.c.compid.alpha1".
> >
> > This would also solve issues with compatibility checkers (with the
> > added bonus that JAR hell could never happen).
> >
> > Couldn't the "shade" plugin be put to use (so that all artefacts have
> > their top-level package transparently set to "o.a.c.compid.alpha1"
> > and all the tools operate on that)?
> >
> >
> > Regards,
> > Gilles
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
>
> --
> Matt Sicker 
>
> -
> 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: [beanutils] Towards 1.10

[Melloware]

Do you think we could also get a BeanUtils2 release while we are at it?  
It supports Java 8 and has many fixes in the last 3 years.



On 6/5/2019 8:37 AM, Rob Tompkins wrote:

I can try to backport the fix to the 1.X branch.

-Rob

On 6/5/2019 8:09 AM, Melloware wrote:

Rob,

I 100% agree since CVE-2014-0114 has been fixed in BeanUtils I think 
we need a release.


However the 1.X branch seems dormant it seems for the last 3 years 
everything has been working on is BeanUtils2 which is where all the 
fixes have been made?


Mello


-
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: [beanutils] Towards 1.10

[Rob Tompkins]

I can try to backport the fix to the 1.X branch.

-Rob

On 6/5/2019 8:09 AM, Melloware wrote:

Rob,

I 100% agree since CVE-2014-0114 has been fixed in BeanUtils I think 
we need a release.


However the 1.X branch seems dormant it seems for the last 3 years 
everything has been working on is BeanUtils2 which is where all the 
fixes have been made?


Mello


-
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

[VOTE][RESULT] Release Apache Commons CSV 1.7 based on RC1

[Gary Gregory]

This vote passes with the following binding PMC +1 votes:

- Alex Herbert
- Gary Gregory
- Bruno P. Kinoshita

Gary

On Sat, Jun 1, 2019 at 8:31 PM Gary Gregory  wrote:

> We have fixed quite a few bugs and added some enhancements since Apache
> Commons CSV 1.6 was released, so I would like to release Apache Commons CSV
> 1.7.
>
> Apache Commons CSV 1.7 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/csv/1.7-RC1 (svn
> revision 34356)
>
> The Git tag commons-csv-1.7-RC1 commit for this RC is a227a
>
1e2fb61ff5f192cfd8099e7e6f4848d7d43 which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-csv.git;a=commit;h=a227a1e2fb61ff5f192cfd8099e7e6f4848d7d43
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-csv.git
> --branch commons-csv-1.7-RC1 commons-csv-1.7-RC1
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1440/org/apache/commons/commons-csv/1.7/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Sat Jun 01 20:15:22 EDT 2019
>
> commons-csv-1.7-bin.tar.gz=0ad5497846a780b470d356ec4519639f39dbc0dd5941dd80a842e641e72b9d28a489808147cd61bc36850ad1cb11578d68f0156c08c5575524671714b519e41d
>
> commons-csv-1.7-bin.zip=6c593931b4c5a43baf75bb978f62a2f91b83cfa55e4035e95218e255d9be900bd2e7ebef899d8ae986f33ac9e68c9077ae7548a7d42b22fc63c094b06a3903ae
>
> commons-csv-1.7-javadoc.jar=8a6c17c97f98dc549a79f60ea7bc744c75337ae537bebdf5a4b414d6aade8f5c3b0c948a473ce5a73d8428a267f79bf488fef2b3eb3fdb46aba7d4bd251e21b6
>
> commons-csv-1.7-sources.jar=17b7ab8aff6deb9dc032c667088f7fffa1c3e8646b16325c25951d51957f0bfa16b4108c94a97348f0c61572bef2cd62ff1efc18352605c36365c342ab68cc2b
>
> commons-csv-1.7-src.tar.gz=1b82fff41abc43762f1d5c037ac6b2e56097b2ac658335c056f384b9914bfaf73c7cde3474e9f75197b8ed75b4744079e37707f0d6d840480dead291e76e6465
>
> commons-csv-1.7-src.zip=a560978d89f2336ddb7a81dd44f5e06909ebc3ae44ef777bf21832737e4962185e68f981e221ff7ed9c6ad1efed44b137b392f1bf9eddd366ad5eba5aabb7121
>
> commons-csv-1.7-test-sources.jar=30ddb09a95a164de4459e9749b37ed8fd287269d4ed179bf90f13ddac6150646ab0c035046a2e0dc29d50d7e0fc9bd2ee3b90530bbcd710007446d6880631cdf
>
> commons-csv-1.7-tests.jar=343e20a8621fe306a65056b2b2c0d16e8333b4fb7365cbcafe154176f27815866097c946869a039dec5e9d46faa7c60a82c07ce31c53c9f1382430e9f44c7ed1
>
> I have tested this with 'mvn clean install site -Pjacoco' using:
>
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T15:00:29-04:00)
> Maven home: C:\Java\apache-maven-3.6.1\bin\..
> Java version: 1.8.0_212, vendor: Oracle Corporation, runtime: C:\Program
> Files\Java\jdk1.8.0_212\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>
> Details of changes since 1.6 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/csv/1.7-RC1/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/csv/1.7-RC1/site/changes-report.html
>
> Site:
> https://dist.apache.org/repos/dist/dev/commons/csv/1.7-RC1/site/index.html
> (note some *relative* links are broken and the 1.7 directories are not
> yet created - these will be OK once the site is deployed.)
>
> JApiCmp Report (compared to 1.6):
>
> https://dist.apache.org/repos/dist/dev/commons/csv/1.7-RC1/site/japicmp.html
>
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/csv/1.7-RC1/site/rat-report.html
>
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now.
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Thank you,
>
> Gary Gregory,
> Release Manager (using key 86fdc7e2a11262cb)
>
> For following is intended as a helper and refresher for reviewers.
>
> Validating a release candidate
> ==
>
> These guidelines are NOT complete.
>
> Requirements: Git, Java, Maven.
>
> You can validate a release from a release candidate (RC) tag as follows.
>
> 1) Clone and checkout the RC tag
>
> git clone https://gitbox.apache.org/repos/asf/commons-csv.git --branch
> commons-csv-1.7-RC1 commons-csv-1.7-RC1
> cd commons-csv-1.7-RC1
>
> 2) Check Apache licenses
>
> This step is not required if the site includes a RAT report page which you
> then must check.
>
> mvn apache-rat:check
>
> 3) Check binary compatibility
>
> Older components still use Apache Clirr:
>
> This step is not required if the site includes a Clirr report page which
> you then must check.
>
> mvn clirr:check
>
> Newer components use JApiCmp with the japicmp Maven Profile:
>
> This step is not required if the site includes a JApiCmp report page which
> you then must check.
>
> mvn install -DskipTests -P japicmp japicmp:cmp
>
> 4) Build the package
>
> mvn -V clean package
>
> You can rec

Re: [beanutils] Towards 1.10

[Gary Gregory]

Note that BeanUtils 2 is a major update with a package name change, meaning
it is not a drop in replacement.

The one main remaining issue to discuss IIRC is whether the BU API should
make public Commons Collections interface and classes, as opposed to more
generic JRE Collections.

Gary

On Wed, Jun 5, 2019 at 8:10 AM Melloware  wrote:

> Rob,
>
> I 100% agree since CVE-2014-0114 has been fixed in BeanUtils I think we
> need a release.
>
> However the 1.X branch seems dormant it seems for the last 3 years
> everything has been working on is BeanUtils2 which is where all the
> fixes have been made?
>
> Mello
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Geometry] Build aborted on Jenkins

[Gilles Sadowski]

Hello.

Le ven. 31 mai 2019 à 20:54, Karl Heinz Marbaise  a écrit :
>
> Hi,
>
> I have created an INFRA ticket, cause one module is stuck and for all
> builds which blocks the whole build process..
>
> https://issues.apache.org/jira/browse/INFRA-18546

Ticket has been closed but the problem hasn't been fixed.
See

https://builds.apache.org/view/A-D/view/Commons/job/commons-geometry/65/console

>
> Kind regards
> Karl Heinz Marbaise
> On 31.05.19 20:10, Karl Heinz Marbaise wrote:
> > Hi,
> >
> > On 31.05.19 20:03, Gilles Sadowski wrote:
> >> Hi.
> >>
> >> All builds fail:
> >>
> >> https://builds.apache.org/view/A-D/view/Commons/job/commons-geometry/
> >
> > Based on a hard configured Time-Out Strategy of 15 minutes...
> >
> > There are currently modules hanging...
> >
> > I will try to kill job ...
> >
> >
> > Kind regards
> > Karl Heinz Marbaise
> >>

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

Re: [beanutils] Towards 1.10

[Melloware]

Rob,

I 100% agree since CVE-2014-0114 has been fixed in BeanUtils I think we 
need a release.


However the 1.X branch seems dormant it seems for the last 3 years 
everything has been working on is BeanUtils2 which is where all the 
fixes have been made?


Mello


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

Re: *** GMX Spamverdacht *** Aw: Re: Proposal to introduce JUnit 5 in commons-numbers

[Eitan Adler]

On Tue, 4 Jun 2019 at 16:09, Heinrich Bohne  wrote:

> So, if the migration from JUnit 4 to JUnit 5 has to happen
> instantaneously, how about creating a new branch for the migration? It's
> a lot of files that have to be refactored, which is going to take some
> time, and since the changes will need to be reviewed, it would probably
> be easier if the review can already take place while the migration is in
> progress, rather than all at once when it is finished. Also, it would
> reduce the risk of conflicting pull requests, thus potentially saving time.
>

I don't think it has to be done instantaneously but it shouldn't drag on,
or be done "as we go". In terms of creating a branch: seems reasonable to
me. I'll happily contribute and review.

That said, the first change we need to make is to modify `pom.xml` to
support running JUnit 5 tests + the vintage runner. I don't know maven too
well but took a stab at it here:
https://github.com/apache/commons-numbers/pull/47


-- 
Eitan Adler