sspath
> 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.
>
> Some thought of mine.
I probably did not understand your point(s).
Regards,
Gilles
>
> Kind regards
> Karl H
:
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&q
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
[...]
-
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 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 >
> > >
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
sion 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
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
> &
M 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
; > 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
> > ma
gt; > > > 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/
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 use
rsion
> > > > > 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 mar
ool 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:
> > > > >
> &
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 20
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 Sa
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 som
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 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/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&q
39 matches
Mail list logo
