[All] Alpha/beta releases

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[All] Alpha/beta releases

Gilles Sadowski-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All] Alpha/beta releases

Matt Sicker
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


--
Matt Sicker <[hidden email]>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All] Alpha/beta releases

sebb-2-2
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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
> --
> Matt Sicker <[hidden email]>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All] Alpha/beta releases

Gilles Sadowski-2
Le mer. 5 juin 2019 à 15:18, sebb <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> >
> >
> > --
> > Matt Sicker <[hidden email]>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All] Alpha/beta releases

sebb-2-2
On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski <[hidden email]> wrote:

>
> Le mer. 5 juin 2019 à 15:18, sebb <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > >
> > >
> > > --
> > > Matt Sicker <[hidden email]>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All] Alpha/beta releases

garydgregory
On Wed, Jun 5, 2019 at 9:59 AM sebb <[hidden email]> wrote:

> On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski <[hidden email]> wrote:
> >
> > Le mer. 5 juin 2019 à 15:18, sebb <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > > > >
> > > >
> > > >
> > > > --
> > > > Matt Sicker <[hidden email]>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [All] Alpha/beta releases

Gilles Sadowski-2
In reply to this post by sebb-2-2
Le mer. 5 juin 2019 à 15:59, sebb <[hidden email]> a écrit :

>
> On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski <[hidden email]> wrote:
> >
> > Le mer. 5 juin 2019 à 15:18, sebb <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All] Alpha/beta releases

Gilles Sadowski-2
In reply to this post by garydgregory
Le mer. 5 juin 2019 à 16:04, Gary Gregory <[hidden email]> a écrit :

>
> On Wed, Jun 5, 2019 at 9:59 AM sebb <[hidden email]> wrote:
>
> > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski <[hidden email]> wrote:
> > >
> > > Le mer. 5 juin 2019 à 15:18, sebb <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All] Alpha/beta releases

James Carman
In reply to this post by Gilles Sadowski-2
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [All] Alpha/beta releases

garydgregory
In reply to this post by Gilles Sadowski-2
On Wed, Jun 5, 2019 at 10:06 AM Gilles Sadowski <[hidden email]>
wrote:

> Le mer. 5 juin 2019 à 15:59, sebb <[hidden email]> a écrit :
> >
> > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski <[hidden email]>
> wrote:
> > >
> > > Le mer. 5 juin 2019 à 15:18, sebb <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [All] Alpha/beta releases

sebb-2-2
In reply to this post by Gilles Sadowski-2
On Wed, 5 Jun 2019 at 15:06, Gilles Sadowski <[hidden email]> wrote:

>
> Le mer. 5 juin 2019 à 15:59, sebb <[hidden email]> a écrit :
> >
> > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski <[hidden email]> wrote:
> > >
> > > Le mer. 5 juin 2019 à 15:18, sebb <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All] Alpha/beta releases

Gilles Sadowski-2
In reply to this post by garydgregory
Le mer. 5 juin 2019 à 16:18, Gary Gregory <[hidden email]> a écrit :

>
> On Wed, Jun 5, 2019 at 10:06 AM Gilles Sadowski <[hidden email]>
> wrote:
>
> > Le mer. 5 juin 2019 à 15:59, sebb <[hidden email]> a écrit :
> > >
> > > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski <[hidden email]>
> > wrote:
> > > >
> > > > Le mer. 5 juin 2019 à 15:18, sebb <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All] Alpha/beta releases

Gilles Sadowski-2
In reply to this post by James Carman
Le mer. 5 juin 2019 à 16:18, James Carman <[hidden email]> 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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All] Alpha/beta releases

James Carman
Ok, what about 1.2?

On Wed, Jun 5, 2019 at 10:44 AM Gilles Sadowski <[hidden email]>
wrote:

> Le mer. 5 juin 2019 à 16:18, James Carman <[hidden email]> 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 <[hidden email]>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [All] Alpha/beta releases

Gilles Sadowski-2
In reply to this post by sebb-2-2
Le mer. 5 juin 2019 à 16:22, sebb <[hidden email]> a écrit :

>
> On Wed, 5 Jun 2019 at 15:06, Gilles Sadowski <[hidden email]> wrote:
> >
> > Le mer. 5 juin 2019 à 15:59, sebb <[hidden email]> a écrit :
> > >
> > > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski <[hidden email]> wrote:
> > > >
> > > > Le mer. 5 juin 2019 à 15:18, sebb <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All] Alpha/beta releases

Gilles Sadowski-2
In reply to this post by James Carman
Le mer. 5 juin 2019 à 16:47, James Carman <[hidden email]> a écrit :
>
> Ok, what about 1.2?

How is it different?

Gilles

>
> On Wed, Jun 5, 2019 at 10:44 AM Gilles Sadowski <[hidden email]>
> wrote:
>
> > Le mer. 5 juin 2019 à 16:18, James Carman <[hidden email]> 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 <[hidden email]>
> > 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>
wrote:

> Le mer. 5 juin 2019 à 16:47, James Carman <[hidden email]> a
> écrit :
> >
> > Ok, what about 1.2?
>
> How is it different?
>
> Gilles
>
> >
> > On Wed, Jun 5, 2019 at 10:44 AM Gilles Sadowski <[hidden email]>
> > wrote:
> >
> > > Le mer. 5 juin 2019 à 16:18, James Carman <[hidden email]>
> 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 <[hidden email]
> >
> > > 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [All] Alpha/beta releases

James Carman
In reply to this post by Gilles Sadowski-2
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 <[hidden email]>
wrote:

> Le mer. 5 juin 2019 à 16:22, sebb <[hidden email]> a écrit :
> >
> > On Wed, 5 Jun 2019 at 15:06, Gilles Sadowski <[hidden email]>
> wrote:
> > >
> > > Le mer. 5 juin 2019 à 15:59, sebb <[hidden email]> a écrit :
> > > >
> > > > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski <[hidden email]>
> wrote:
> > > > >
> > > > > Le mer. 5 juin 2019 à 15:18, sebb <[hidden email]> 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 <[hidden email]>
> 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 <
> [hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [All] Alpha/beta releases

Gilles Sadowski-2
In reply to this post by James Carman
Le mer. 5 juin 2019 à 17:02, James Carman <[hidden email]> 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 <[hidden email]>
> wrote:
>
> > Le mer. 5 juin 2019 à 16:47, James Carman <[hidden email]> a
> > écrit :
> > >
> > > Ok, what about 1.2?
> >
> > How is it different?
> >
> > Gilles
> >
> > >
> > > On Wed, Jun 5, 2019 at 10:44 AM Gilles Sadowski <[hidden email]>
> > > wrote:
> > >
> > > > Le mer. 5 juin 2019 à 16:18, James Carman <[hidden email]>
> > 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 <[hidden email]
> > >
> > > > 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All] Alpha/beta releases

Gilles Sadowski-2
In reply to this post by James Carman
Le mer. 5 juin 2019 à 17:04, James Carman <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

12