This is not the point Tibor and I'll just repeat it a last time: there are
fixes in this version - rerun is not one - and we agreed one month ago to
let it be released as a milestone. There is no real way to excuse the fact
we missed it cause of other featurethis is exactly why it is
Romain, You have to understand also me, users, contributors. You are not
alone. Olivier is also not alone.
See the others, e.g. Enrico, Jonathan, Matt, etc. They are greatly
communicating, understanding, and they are petitioned what it means to
accept requirements from others and making a
@Tibor: I'd like to gently remind you that we - asf - are community driven
and holding a release is generally bad if it does not bite us after which
is the case there. As mentionned by Olivier we already agreed to release
and it got delayed for no reason compared to the original agreement. Please
Roman, it does not make sense to continue with you because you do not
understand the whole track with this project, and again nobody said
anything about architecture. It's your permanent opinions and very bad
attitude. So it is waste of the time to continue to explain the same things
over rand
@Tibor: point is more that we don't need to hold a milestone for a feature,
we can just release and let fixes get out and get this huge architectural
change in another milestone. Only valid reason to delay a release is IMO a
regression or a major change we can't revert later (3.0.0 would be in
The reason of M4 was to introduce TCP communication.
Meanwhile first we wanted to cut the release one month ago but we postponed
it and we were waiting for clarifying license issues and fixed J13 issue
yesterday.
I was working on TCP/Pipes together with Jonathan Bell and we wanted to
make it in M4
+1 to release next week, no reason to wait since it is another "m" release
IMHO
Le lun. 11 nov. 2019 à 12:44, Olivier Lamy a écrit :
> That will be great.
> If you don't have time before end of the week. I'm happy to help and do it.
> cheers
> Olivier
>
> On Mon, 11 Nov 2019 at 21:35, Tibor
That will be great.
If you don't have time before end of the week. I'm happy to help and do it.
cheers
Olivier
On Mon, 11 Nov 2019 at 21:35, Tibor Digana wrote:
> @Olivier as we clarified this Slack. The release will be fast. No delay!
>
> On Mon, Nov 11, 2019 at 12:07 PM Olivier Lamy wrote:
>
@Olivier as we clarified this Slack. The release will be fast. No delay!
On Mon, Nov 11, 2019 at 12:07 PM Olivier Lamy wrote:
> Why? delay again
> I thought 1 month ago we agreed ago to move non finished stuff to 3.0.0-M5
> and release 3.0.0-M5 later.
>
>
> On Mon, 11 Nov 2019 at 20:59, Tibor
Why? delay again
I thought 1 month ago we agreed ago to move non finished stuff to 3.0.0-M5
and release 3.0.0-M5 later.
On Mon, 11 Nov 2019 at 20:59, Tibor Digana wrote:
> Pls don't do it.
> I will cut it and move some issues to M5 but I need Matt to finish his
> work. I am in contact with
Pls don't do it.
I will cut it and move some issues to M5 but I need Matt to finish his
work. I am in contact with Mat.
I talked about it with the contributor Jonathan Bell about reasoning.
T
On Mon, Nov 11, 2019 at 11:41 AM Olivier Lamy wrote:
> Hi
> Starting again this thread as we agreed but
Hi
Starting again this thread as we agreed but I didn't do it.
So I'd like to cut release 3.0.0-M4 by the end of this week.
On Mon, 14 Oct 2019 at 11:40, Tibor Digana wrote:
> The SUREFIRE-1689 progress has been finished until the CI build succeeds.
> T
>
> On Sun, Oct 13, 2019 at 10:27 AM
The SUREFIRE-1689 progress has been finished until the CI build succeeds.
T
On Sun, Oct 13, 2019 at 10:27 AM Robert Scholte
wrote:
> Ah, there it is :)
>
> On Sun, 13 Oct 2019 08:21:53 +0200, Romain Manni-Bucau
> wrote:
>
> > Didnt expect my comment about shade to take so much space in this
Ah, there it is :)
On Sun, 13 Oct 2019 08:21:53 +0200, Romain Manni-Bucau
wrote:
Didnt expect my comment about shade to take so much space in this thread
but yes we rely on asm for relocation:
On Sun, 13 Oct 2019 00:35:51 +0200, Tibor Digana
wrote:
It is ONLY required when the runtime is Java 8 or lower AND you need to
read the module descriptors.
thx for clarifying.
Am i right if I say that it would happen with J9/Toolchain used in
Compiler
but J8 in the Maven build?
Is it
Didnt expect my comment about shade to take so much space in this thread
but yes we rely on asm for relocation:
https://github.com/apache/maven-shade-plugin/blob/master/src/main/java/org/apache/maven/plugins/shade/DefaultShader.java#L453
Le dim. 13 oct. 2019 à 00:20, Robert Scholte a
écrit :
>
>> It is ONLY required when the runtime is Java 8 or lower AND you need to
>> read the module descriptors.
thx for clarifying.
Am i right if I say that it would happen with J9/Toolchain used in Compiler
but J8 in the Maven build?
Is it realistic?
Maybe some people would do it due to some other
On Sat, 12 Oct 2019 13:44:48 +0200, Romain Manni-Bucau
wrote:
Le sam. 12 oct. 2019 à 13:33, Robert Scholte a
écrit :
As far as I know, surefire won't touch the Plexus Java code that
requires
ASM.
It is ONLY required when the runtime is Java 8 or lower AND you need to
read the module
Because i understood you talking about relocating ASM within Surefire here
in this thread.
It did not make sense for me since the ASM always has to adapt to a new
bytecode.
So you mean relocating ASM in the m-shade-p, right?
User's dependencies are loaded in a separate classloader, no need to
Not sure what you meant Tibor, just completed that relocation can need asm
upgrade in shade plugin - if we dont want users to do it in the pom which
is ok/needed if they use new java versions.
Le sam. 12 oct. 2019 à 20:24, Tibor Digana a
écrit :
> Relocation is useless. The ASM is changed
Relocation is useless. The ASM is changed because of the bytecode
compatibility. We always had to upgrade plexus-java in the past; otherwise
the users reported a bug directly or in the Stackoverflow.
On Sat, Oct 12, 2019 at 1:45 PM Romain Manni-Bucau
wrote:
> Le sam. 12 oct. 2019 à 13:33,
Le sam. 12 oct. 2019 à 13:33, Robert Scholte a
écrit :
> As far as I know, surefire won't touch the Plexus Java code that requires
> ASM.
> It is ONLY required when the runtime is Java 8 or lower AND you need to
> read the module descriptors.
>
> Maven Shade is a different case: it must parse
As far as I know, surefire won't touch the Plexus Java code that requires
ASM.
It is ONLY required when the runtime is Java 8 or lower AND you need to
read the module descriptors.
Maven Shade is a different case: it must parse the Java bytecode (and only
when using minifyJar), hence it
Have to admit I dont know, clearly a different load though. Feel free to
ask Joel on the ticket.
Le sam. 12 oct. 2019 à 12:49, Tibor Digana a
écrit :
> I have noticed this happening only with snapshot versions. The snapshot and
> release repos have different h/w?!
>
> On Sat, Oct 12, 2019 at
I have noticed this happening only with snapshot versions. The snapshot and
release repos have different h/w?!
On Sat, Oct 12, 2019 at 12:44 PM Romain Manni-Bucau
wrote:
> They work on it with some rate limiting until it gets resolved.
> They had some abnormal load.
>
> Le sam. 12 oct. 2019 à
They work on it with some rate limiting until it gets resolved.
They had some abnormal load.
Le sam. 12 oct. 2019 à 12:24, Tibor Digana a
écrit :
> Romain, I have enabled JUnit5 5.6.0/1.6.0-SNAPSHOT.
> I want to know if the bug OSSRH-51220 is fixed.
>
>
Romain, I have enabled JUnit5 5.6.0/1.6.0-SNAPSHOT.
I want to know if the bug OSSRH-51220 is fixed.
https://builds.apache.org/job/maven-box/job/maven-surefire/job/junit5-snapshots/
On Sat, Oct 12, 2019 at 12:10 PM Tibor Digana
wrote:
> Here is the pull request
>
Here is the pull request
https://github.com/codehaus-plexus/plexus-languages/pull/29
On Sat, Oct 12, 2019 at 11:49 AM Romain Manni-Bucau
wrote:
> I understand and if we can we must do but not a blocker - was my point
> Also keep in mind we could do the update automatically with asm versioning
>
I understand and if we can we must do but not a blocker - was my point
Also keep in mind we could do the update automatically with asm versioning
scheme using our resolver in the mojo.
So let's fix issues for most users - once again j > 11 is a play area, not
for prod today - and maybe enhance our
all bad, see the stackoverflow. It happens that the users argue that they
have to update our dependencies which is our responsibility!
On Sat, Oct 12, 2019 at 11:40 AM Romain Manni-Bucau
wrote:
> Dont think there is an api version upgrade between 7.0 and 7.2 so can be
> upgraded in user pom so
Dont think there is an api version upgrade between 7.0 and 7.2 so can be
upgraded in user pom so not a blocker for a milestone release IMHOj13
and j14 are still not adopted too so all good.
Le sam. 12 oct. 2019 à 11:35, Tibor Digana a
écrit :
> We still use plexus-java:1.0.3 which depends
We still use plexus-java:1.0.3 which depends on ASM 7.0.
The support for JDk 13 and 14 is in the version 7.2.
We have similar upgrade in
https://github.com/apache/maven-shade-plugin/pull/29
On Thu, Oct 10, 2019 at 2:53 AM Olivier Lamy wrote:
> Hi,
> It's now almost 10 months since last and
I have to try to merge the fix because it avoids a situation when the VM
hanged. It is very important for the users.
The remaining fixes may go to M5.
I will adjust Jira release notes, oki?
I have time to cut the release, no problem. The only problem was to find
some spare time for coding the
We can release now 3.0.0-M4 and then release later with your remaining
fixes/new features.
As far I know we do not have a fix release content we can easily move the
remaining fixes to a 3.0.0-M5
I'm happy to release it myself if you don't have time.
On Thu, 10 Oct 2019 at 21:11, Tibor Digana
I understood the wish from JUnit5 fans e.g. Olivier Lamy but still we have
important fixes for the stability and it is hard to find new developers.
I was thinking about this release/3.0.0-M4 and adding one more milestone
too but there is fix on my PC that I have a problem to merge without new
+1
Enrico
Il gio 10 ott 2019, 06:40 Romain Manni-Bucau ha
scritto:
> Anything user facing preventing to let it be a final?
>
> Anyway +1 to let fixes get out.
>
> Le jeu. 10 oct. 2019 à 02:53, Olivier Lamy a écrit :
>
> > Hi,
> > It's now almost 10 months since last and around 30 issues fixed.
Anything user facing preventing to let it be a final?
Anyway +1 to let fixes get out.
Le jeu. 10 oct. 2019 à 02:53, Olivier Lamy a écrit :
> Hi,
> It's now almost 10 months since last and around 30 issues fixed.
> Maybe time for a new release?
> Moving issues still open to 3.0.0-M5?
>
> cheers
Hi,
It's now almost 10 months since last and around 30 issues fixed.
Maybe time for a new release?
Moving issues still open to 3.0.0-M5?
cheers
--
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy
38 matches
Mail list logo
