Il giorno sab 12 gen 2019 alle ore 11:45 Enrico Olivelli
ha scritto:
>
>
>
> Il sab 12 gen 2019, 11:39 Tibor Digana ha scritto:
>>
>> Such a drastic change?
>
>
> If that version is buggy we should fix it or drop it.
>
> Do we have already released that buggy version to users?
>
>
> How did you
Il sab 12 gen 2019, 11:39 Tibor Digana ha scritto:
> Such a drastic change?
>
If that version is buggy we should fix it or drop it.
Do we have already released that buggy version to users?
How did you see our processes on Jenkins slave? Do you have access to
slaves console?
Enrico
First
Le vendredi 11 janvier 2019, 12:55:03 CET Tibor Digana a écrit :
> ok, Herve, the fact is that these plugins have been updated from time to
> time.
yes, we did it in the past (years ago, look at the history) and went to the
conclusion we should not do that to improve reproducibility, unless there
original idea, let's try to evaluate :)
IMHO this could work for packaging plugins in default lifecycle, that are
defined in default-bindings.xml, but would not for other lifecycles that are
configured in components.xml (without copy/pasting content not related to
plugins)
I don't think an
Can't we rollback to the previous version instead of a snapshot?
Enrico
Il sab 12 gen 2019, 09:23 Tibor Digana ha scritto:
> I think we should downgrade maven-shared-utils to 3.1.0 in the m-invoker-p
> because we found the same problem in surefire:3.0.0-M1.
> We did not have time to fix it and
>> which commit could have broken shared utils ?
I have picked up three candidate commits:
362805fbf6341523edfdf509905812acb42f6a97
fd082c077c78f8ce83fce2a92f0265e83599a42f
f2246e0653b185297451902ee278e6aec1ff470e
Those devs who have Windows should run the build of maven-jar-plugin (mvn
verify
I had chats with both Adam Bien and Sebastian Daschner asking for a better
way to work with a simple high-speed throw-away development pom.
They are both working a lot with Java EE applications and want to rely on
defaults as much as possible.
So in a way they don't care about plugin
I think that’s a real bad idea if you have to do local modifications to get to
a working build environment. Maven is all about not requiring you to do that
(anymore). So even requiring a certain Maven Version does not fit in that
pattern (although unavoidable if you do not want to work with
I want to do a release of the plugin very soon. Cleaning up the workspace
is mostly caused by an invoker-report. I also noticed that some
input/outputstreams weren't closed properly, that has been fixed already.
If maven-shared-utils 3.2.1 is a likely cause too, then I'll downgrade
that one.
On Sat, 12 Jan 2019 15:04:34 +0100, Enrico Olivelli
wrote:
Il sab 12 gen 2019, 14:09 Robert Scholte ha
scritto:
Using the following line to see all java.exe processes
tasklist /FI "IMAGENAME eq java.exe"
How do you do this on slave Jenkins machines?
I ran it locally. Also ran it
Such a drastic change?
First we should get the confidence using Jenkins CI for a long time run.
On Sat, Jan 12, 2019 at 11:20 AM Enrico Olivelli
wrote:
> Can't we rollback to the previous version instead of a snapshot?
>
> Enrico
>
> Il sab 12 gen 2019, 09:23 Tibor Digana ha
> scritto:
>
> > I
I think we should downgrade maven-shared-utils to 3.1.0 in the m-invoker-p
because we found the same problem in surefire:3.0.0-M1.
We did not have time to fix it and I have realized the connection to the
Invoker just now.
Faster than a release is to deploy SNAPSHOT version of the Invoker and use
Il sab 12 gen 2019, 14:09 Robert Scholte ha scritto:
> Using the following line to see all java.exe processes
>
> tasklist /FI "IMAGENAME eq java.exe"
>
How do you do this on slave Jenkins machines?
Enrico
>
> current maven-jar-plugin (master) is using maven-shared-utils-3.2.1
> After running
I have a strong reason to update Surefire due to new JRE versions have been
updated too many times last two years.
They required a fix done within a few days and some of them are shaking on
the chair...
Our Maven Core is stable and Java 9+ ready but the obsolete plugins are not.
I want only the
we have 2 opposite objectives:
- make default near-empty pom work at best,
- but force people to have defined plugins versions (then not really empty pom)
to get stable build
and I checked about the warning message: I was wrong, there is no warning
message when plugins without versions are
The original plan was to make plugin version mandatory. Perhaps 3.7.0 is
the time to do that, with a CLI option (to be removed after 3.7.x) to pull
in the 3.6.x default versions if your pom is missing plugin versions.
The warning has been there long enough. Let’s pull the trigger.
On Sat 12 Jan
I think the warning is a really good idea but I don’t think this wording will
mean anything to the average maven user, as I don’t understand from it what I
should do to fix the problem. How about something like: “Specify explicit
versions for these plugins in the project pom or an ancestor
Using the following line to see all java.exe processes
tasklist /FI "IMAGENAME eq java.exe"
current maven-jar-plugin (master) is using maven-shared-utils-3.2.1
After running this, I don't see new/hanging java processes
Robert
On Sat, 12 Jan 2019 12:59:08 +0100, Tibor Digana
wrote:
which
Just wondering, can this be solved by an extension?
So instead of changing this in Maven Core itself, people can add an
extension to Maven with the latest+stable releases.
Hervé and I already discovered that current focus is mainly on plugins
right now. We should also work on extensions.
19 matches
Mail list logo
