means to automate the
renaming of the packages.
>
> Furthermore If you are running on module path you have no classpath
> anymore which means you have only a single module name which must be
> unique..(a little bit like groupId/artifactId).
So?
If we change it, it's unique.
>
>
ise
On 04.06.19 14:42, 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
Le dim. 9 juin 2019 à 15:46, sebb a écrit :
>
> On Sun, 9 Jun 2019 at 14:20, Gilles Sadowski wrote:
> >
> > Hi.
> >
> > Le dim. 9 juin 2019 à 14:06, James Carman a
> > écrit :
> > >
> > > On Sun, Jun 9, 2019 at 7:36 AM sebb wrote:
> > >
> > > >
> > > > Huh?
> > > > That can still cause jar iss
On Sun, 9 Jun 2019 at 14:20, Gilles Sadowski wrote:
>
> Hi.
>
> Le dim. 9 juin 2019 à 14:06, James Carman a
> écrit :
> >
> > On Sun, Jun 9, 2019 at 7:36 AM sebb wrote:
> >
> > >
> > > Huh?
> > > That can still cause jar issues, *precisely because* only one jar will
> > > reach the Java classpa
Hi.
Le dim. 9 juin 2019 à 14:06, James Carman a écrit :
>
> On Sun, Jun 9, 2019 at 7:36 AM sebb wrote:
>
> >
> > Huh?
> > That can still cause jar issues, *precisely because* only one jar will
> > reach the Java classpath.
> >
> > Suppose there is jar1 with API-V1.
> > This is depended on by app
On Sun, Jun 9, 2019 at 7:36 AM sebb wrote:
>
> Huh?
> That can still cause jar issues, *precisely because* only one jar will
> reach the Java classpath.
>
> Suppose there is jar1 with API-V1.
> This is depended on by app1 and app2.
>
> Then jar2 is produced with API-V2 (not BC-compatible with API
On Sun, 9 Jun 2019 at 12:01, James Carman wrote:
>
> On Sun, Jun 9, 2019 at 5:40 AM Gilles Sadowski wrote:
>
> >
> > Ultimately the PMC still needs to vote on the release, no?
> > Hence I don't see what advantage there is in allowing different
> > beta policies. [Of course, no component is requi
On Sun, Jun 9, 2019 at 5:40 AM Gilles Sadowski wrote:
>
> Ultimately the PMC still needs to vote on the release, no?
> Hence I don't see what advantage there is in allowing different
> beta policies. [Of course, no component is required to provide
> a beta release...]
> What the proposal aims to
Hi.
Le jeu. 6 juin 2019 à 15:18, sebb a écrit :
>
> On Wed, 5 Jun 2019 at 23:40, Gary Gregory wrote:
> >
> > 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
On Wed, 5 Jun 2019 at 23:40, Gary Gregory wrote:
>
> 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.
N.B. This by definition exclu
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 y
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 br
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
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 b
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
th
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 in
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 bas
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,
j
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
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
[...]
-
T
o 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
> > > >
> > > > >
>
t; 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
&g
e?
> > >
> > > 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 >
> >
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
> > > >
matically 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.
> > > > > >
> > > > > >
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
> &g
: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, f
ersion
> > > > > > keyword like "alpha" may require some additional code, though maybe
> > > > > > the shade plugin already supports that.
> > > > > >
> > > > > > Alternatively, JUnit 5.x uses a tool called
de, 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://git
e 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
&g
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 to
etect 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 Guardi
Unit 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:
> > > &
n 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
ade 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,
y, 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.
> > >
> > > Doe
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 behaviour
ardian 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/be
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"
39 matches
Mail list logo
