Re: issues with the user property "maven.test.failure.ignore" and new proposals

On Thu, 24 Mar 2022 at 01:18, Tibor Digana wrote: > Hi Olivier, I have used the Maven branch according to your instructions. I > have used the snapshot version of the plugin and JDK 1.8.0u05. > Both implementations end up with the same build result. The only > difference is the number of IF-Else

Re: issues with the user property "maven.test.failure.ignore" and new proposals

Hi Olivier, I have used the Maven branch according to your instructions. I have used the snapshot version of the plugin and JDK 1.8.0u05. Both implementations end up with the same build result. The only difference is the number of IF-Else branches in the implementation. I started Maven build twice

Re: issues with the user property "maven.test.failure.ignore" and new proposals

On Tue, 22 Mar 2022 at 14:40, Tibor Digana wrote: > Sorry for late reply. > > I have created a demo project > https://github.com/Tibor17/maven.test.failure.ignore/ which simulates > OOM. > > According to the definition of the parameter "maven.failure.test.ignore" > the failures (also errors) sho

Re: issues with the user property "maven.test.failure.ignore" and new proposals

On Tue, 22 Mar 2022 at 14:40, Tibor Digana wrote: > Sorry for late reply. > > I have created a demo project > https://github.com/Tibor17/maven.test.failure.ignore/ which simulates > OOM. > > According to the definition of the parameter "maven.failure.test.ignore" > the failures (also errors) sho

Re: issues with the user property "maven.test.failure.ignore" and new proposals

Sorry for late reply. I have created a demo project https://github.com/Tibor17/maven.test.failure.ignore/ which simulates OOM. According to the definition of the parameter "maven.failure.test.ignore" the failures (also errors) should be ignored during testing. The word "during" is important beca

Re: issues with the user property "maven.test.failure.ignore" and new proposals

Hi, I start to feel that we first try to define technical details but we don't know for what. Each business requirement should be resolved as simply as possible from a technical perspective. In other ways we will start to build complicated and many features which probably were not needed at all.

Re: issues with the user property "maven.test.failure.ignore" and new proposals

Hi Tibor, just to make it clear, I don't talkin about log-levels here but how to intepret/handle a failure/failing/crashing test. Am 18.03.22 um 21:54 schrieb Tibor Digaňa: Christoph, just let me briefly explain the log level hierarchy. If you select WARN log level, then ERROR can be printed

Re: issues with the user property "maven.test.failure.ignore" and new proposals

Christoph, just let me briefly explain the log level hierarchy. If you select WARN log level, then ERROR can be printed too. Similar with INFO, means that WARN and ERROR would be printed as well. The real decision making in the plugin is a bit more complicated, see the pull request https://github.

Re: issues with the user property "maven.test.failure.ignore" and new proposals

No I think more about if (severity == "WARN") { log.warn("There is something wrong"); } else if (severity == "ERROR") { throw new MojoFailureException("...") { } else { throw new MojoExecutionException("...") { } That way the plugin can handle any error/failure/... in a way that the user

Re: issues with the user property "maven.test.failure.ignore" and new proposals

@Christoph FATAL , WARN , ERROR They are log levels? The plugin does not control the log level after caught exception in Maven core. The Maven Core does! I think it's time to make a demo. On Thu, Mar 17, 2022 at 6:21 AM Christoph Läubrich wrote: > Hi Tibor, > > it shouldn't be to hard to gue

Re: issues with the user property "maven.test.failure.ignore" and new proposals

Hi Tibor, it shouldn't be to hard to guess another property like maven.test.jvmcrash=FATAL maven.test.failure=WARN maven.test.error=ERROR :-) Am 16.03.22 um 12:25 schrieb Tibor Digana: Hi Christoph, Such a granularity with error/failure might be also an additional requirement but still you m

Re: issues with the user property "maven.test.failure.ignore" and new proposals

Hi Slawomir, Your second second example -DargLine=-Xxx is used in an integration test in order to force producing exceptions, but IMHO it wants to simulate two different situations. In such cases the JVM: 1. fails on JVM startup because of low RAM (fails the JVM on --add-reads or illegal V

Re: issues with the user property "maven.test.failure.ignore" and new proposals

Hi Christoph, Such a granularity with error/failure might be also an additional requirement but still you miss the third option to JVM error which is different from test error/failure - they don;t have the same meaning. T On Mon, Mar 14, 2022 at 10:57 AM Christoph Läubrich wrote: > Just wonde

Re: issues with the user property "maven.test.failure.ignore" and new proposals

Hi First sentence: Set this to "true" to ignore a failure during testing. It is clear for me - we want to ignore a failure during testing ... So if the testing process is not starting for any reason or was broken for reasons other than test failure this property should not be considered. Most of

Re: issues with the user property "maven.test.failure.ignore" and new proposals

pon., 14 mar 2022 o 10:52 Tibor Digana napisał(a): > Romain, it is not a bug. > Don't consider this as a bug. It was a feature request for change by > Olivier, and not a bug. > I closed both issues years ago but not because of ignorance but because the > appearance of the exceptional behavior is

Re: issues with the user property "maven.test.failure.ignore" and new proposals

@Tibor: I never said it was a bug, my point is that you never needs it so we should keep that deprecated/not recommended and enable people having too constrained env to work on it through a SPI as proposed by Guillaume. So proposal was to drop that property support and add a SPI if anyone think thi

Re: issues with the user property "maven.test.failure.ignore" and new proposals

Just wondering but maybe it would be better to configure the severity instead of a true/false, something like: maven.test.failure=WARN maven.test.error=ERROR would only warn about failing tests but thrw exception if starting the test fails? Am 14.03.22 um 10:52 schrieb Tibor Digana: Romain,

Re: issues with the user property "maven.test.failure.ignore" and new proposals

Romain, it is not a bug. Don't consider this as a bug. It was a feature request for change by Olivier, and not a bug. I closed both issues years ago but not because of ignorance but because the appearance of the exceptional behavior is a wrong compromise and which does not help anyone and even it m

Re: issues with the user property "maven.test.failure.ignore" and new proposals

+1 if it is to investigate a CI issue, it is generally easy to add debug insights (by code or agent) so a SPI sounds like the sanest for the plugin to me. Romain Manni-Bucau @rmannibucau | Blog | Old Blog

Re: issues with the user property "maven.test.failure.ignore" and new proposals

If that's not currently possible, maybe a SPI should be provided so that people can use plug in extensions to analyze the test result and override it if necessary (transforming an error into a warning, storing results in a way which is easier to use by other tools later...) ? Guillaume Le lun. 14

Re: issues with the user property "maven.test.failure.ignore" and new proposals

I also agree that the test at least should run, we use this property to run the test and produce result and later on have a buildstep that analyze the results (and probably fail the build job). As it is not recommend, I wonder what is the recommended way to archive something similar? Am 14.0

Re: issues with the user property "maven.test.failure.ignore" and new proposals

On Mon, 14 Mar 2022 at 11:55, Tibor Digana wrote: > In case of the user property *maven.test.failure.ignore* the MOJO must not > throw any exception which is interpreted by the Maven Core as BUILD > SUCCESS. > This is a very simple reduction of the problem description. The documentation here htt

issues with the user property "maven.test.failure.ignore" and new proposals

In case of the user property *maven.test.failure.ignore* the MOJO must not throw any exception which is interpreted by the Maven Core as BUILD SUCCESS. We have received an internal requirement to change the behavior of the user property *maven.test.failure.ignore* so that the behavior will have on

Re: Advice + proposals regarding automodule naming

and keep our proposals up to date. thanks, Robert [1] http://mail.openjdk.java.net/mailman/listinfo/jpms-spec-observers [2] http://mail.openjdk.java.net/pipermail/jpms-spec-observers/ [3] http://mail.openjdk.java.net/mailman/listinfo/jpms-spec-comments

Advice + proposals regarding automodule naming

, thoughts, conclusions and will suggest two proposals. Traditionally, the Java ecosystem has been very mature in terms of naming and namespacing. The reverse fqdn introduced into the java package was a great choice to ensure classes don’t conflict. Popular build tools such as Maven and nearly all

Re: svn commit: r616127 - in /maven/site/trunk/src/site: ./ apt/developers/release/ apt/guides/introduction/ apt/guides/mini/ apt/guides/plugin/ apt/plugin-developers/ apt/proposals/incubator/ xdoc/

t;>maven/site/trunk/src/site/apt/guides/mini/guide-repository-ssl.apt > >>maven/site/trunk/src/site/apt/guides/plugin/guide-java-plugin- > >> development.apt > >>maven/site/trunk/src/site/apt/plugin-developers/plugin-testing.apt > >>

Re: svn commit: r616127 - in /maven/site/trunk/src/site: ./ apt/developers/release/ apt/guides/introduction/ apt/guides/mini/ apt/guides/plugin/ apt/plugin-developers/ apt/proposals/incubator/ xdoc/

trunk/src/site/apt/guides/mini/guide-ide-eclipse.apt > > >>maven/site/trunk/src/site/apt/guides/mini/guide-m1-m2.apt > > >>maven/site/trunk/src/site/apt/guides/mini/guide-repository-ssl.apt > > >>maven/site/trunk/src/site/apt/guides/plugin

Re: svn commit: r616127 - in /maven/site/trunk/src/site: ./ apt/developers/release/ apt/guides/introduction/ apt/guides/mini/ apt/guides/plugin/ apt/plugin-developers/ apt/proposals/incubator/ xdoc/

/guide-m1-m2.apt > >>maven/site/trunk/src/site/apt/guides/mini/guide-repository-ssl.apt > >>maven/site/trunk/src/site/apt/guides/plugin/guide-java-plugin- > >> development.apt > >>maven/site/trunk/src/site/apt/plugin-developers/plugin-testin

Re: svn commit: r616127 - in /maven/site/trunk/src/site: ./ apt/developers/release/ apt/guides/introduction/ apt/guides/mini/ apt/guides/plugin/ apt/plugin-developers/ apt/proposals/incubator/ xdoc/

maven/site/trunk/src/site/apt/guides/mini/guide-m1-m2.apt > > maven/site/trunk/src/site/apt/guides/mini/guide-repository-ssl.apt > > > maven/site/trunk/src/site/apt/guides/plugin/guide-java-plugin-development.apt > > maven/site/trunk/src/site/apt/plugin-develo

Re: svn commit: r616127 - in /maven/site/trunk/src/site: ./ apt/developers/release/ apt/guides/introduction/ apt/guides/mini/ apt/guides/plugin/ apt/plugin-developers/ apt/proposals/incubator/ xdoc/

/src/site/apt/plugin-developers/plugin-testing.apt maven/site/trunk/src/site/apt/proposals/incubator/nmaven.apt maven/site/trunk/src/site/site.xml maven/site/trunk/src/site/xdoc/articles.xml Modified: maven/site/trunk/src/site/apt/developers/release/pmc-gpg- keys.apt URL: http://svn.a

Re: svn commit: r616127 - in /maven/site/trunk/src/site: ./ apt/developers/release/ apt/guides/introduction/ apt/guides/mini/ apt/guides/plugin/ apt/plugin-developers/ apt/proposals/incubator/ xdoc/

ides/mini/guide-m1-m2.apt maven/site/trunk/src/site/apt/guides/mini/guide-repository-ssl.apt maven/site/trunk/src/site/apt/guides/plugin/guide-java-plugin-development.apt maven/site/trunk/src/site/apt/plugin-developers/plugin-testing.apt maven/site/trunk/src/site/apt/proposals/incub

Final reminder for 2.1 proposals

Hi, Just another friendly reminder that you have to get your proposals in for 2.1 by Friday in order to be considered for 2.1 Devs: http://docs.codehaus.org/display/MAVEN/All+Proposals Users: http://docs.codehaus.org/display/MAVENUSER/User+Proposals Thanks, Jason

Call for 2.1 Proposals

As we are approaching an alpha release of 2.1, the Maven Team would like to make a final call for proposals. The cutoff date for new proposals will be Friday 9/21. During this time, we will review and discuss new proposals and make a final cut at scheduling the 2.1 release. The current aim is to

RE: Gathering proposals for 2.1

I'll email the user list. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 04, 2007 5:41 AM To: Maven Developers List Subject: Re: Gathering proposals for 2.1 On 3 Sep 07, at 6:30 PM 3 Sep 07, Brian E. Fox wrote: > I'm leaning tha

Re: Gathering proposals for 2.1

e need to get a stable release out sooner rather than later. I think that we should set a timeframe starting and ending soon (say starting tomorrow and going for 2 weeks) where we will collect proposals for 2.1 in the wiki. At the close of that timeframe, we review/discuss the proposals and sele

Re: Gathering proposals for 2.1

nges that would make everyone's life easier. If nothing else, it provides the motivation now to get some proposals started for 2.2. I think that's good, it's really just a final call proposals after which you have to wait until 2.2. I agree that sooner is better then la

RE: Gathering proposals for 2.1

lse, it provides the motivation now to get some proposals started for 2.2. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Monday, September 03, 2007 9:27 PM To: Maven Developers List Subject: Re: Gathering proposals for 2.1 On 04/09/2007, at 11:20 AM, Brian E

Re: Gathering proposals for 2.1

On 04/09/2007, at 11:20 AM, Brian E. Fox wrote: WDYT? +Integer.MAX_VALUE I've got all the ones in that I care about, and my previous mail highlights the ones I think we should do. Cheers, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/

Gathering proposals for 2.1

I think that we should set a timeframe starting and ending soon (say starting tomorrow and going for 2 weeks) where we will collect proposals for 2.1 in the wiki. At the close of that timeframe, we review/discuss the proposals and select ones for 2.1 with an eye on keeping the release scope manage

Re: Proposals

o all these :) Ok, I'll hold back the other 295 proposals for a while :-) If there's no responses, that's fine - but it's a better medium for discussion and we may be able to use that to improve them up front (or cull really bad ideas :) ...and I'll try to leave ou

Re: Proposals

On 2007-07-04 03:01:00 +0200, Brett Porter <[EMAIL PROTECTED]> said: Definitely agree here, though I like to see them come to the list too (preferably staggered, it's going to take a week to find time to read and respond to all these :) Ok, I'll hold back the other 295

Re: Proposals

use that to improve them up front (or cull really bad ideas :) Cheers, Brett On 04/07/2007, at 3:08 AM, Jason van Zyl wrote: Hi, I see that many users are making proposals, and as I've stated before they will get lost on the mailing lists. Especially if you have a wave of inspi

Re: Proposals

On 2007-07-03 19:08:00 +0200, Jason van Zyl <[EMAIL PROTECTED]> said: Hi, I see that many users are making proposals, and as I've stated before they will get lost on the mailing lists. Especially if you have a wave of inspiration and create several proposals. Schedules gener

Proposals

Hi, I see that many users are making proposals, and as I've stated before they will get lost on the mailing lists. Especially if you have a wave of inspiration and create several proposals. Schedules generally don't sync up and it's often days before developers can respond w

Re: svn commit: r331054 [3/3] - in /maven/site/trunk/src/site/apt: ./ background/ guides/development/ guides/getting-started/ guides/introduction/ guides/mini/ proposals/

My fault, I added before the properties without the "svn:" On 11/6/05, Brett Porter <[EMAIL PROTECTED]> wrote: > > > > Propchange: > > maven/site/trunk/src/site/apt/guides/mini/guide-naming-conventions.apt > > ('eol-style' removed) > > > > Propchange: > > maven/site/trunk/src/site/ap

Re: svn commit: r331054 [3/3] - in /maven/site/trunk/src/site/apt: ./ background/ guides/development/ guides/getting-started/ guides/introduction/ guides/mini/ proposals/

Propchange: maven/site/trunk/src/site/apt/guides/mini/guide-naming-conventions.apt ('eol-style' removed) Propchange: maven/site/trunk/src/site/apt/guides/mini/guide-naming-conventions.apt ('keywords' removed) What happened here? - Brett -

svn commit: r170866 - in /maven/components/trunk/maven-site/src/site: apt/proposals/plugin-tool-refactoring.apt fml/maven1.fml

Author: brett Date: Wed May 18 21:41:05 2005 New Revision: 170866 URL: http://svn.apache.org/viewcvs?rev=170866&view=rev Log: add some extra documentation, fix formatting Modified: maven/components/trunk/maven-site/src/site/apt/proposals/plugin-tool-refactoring.apt maven/compon

svn commit: r170139 - in /maven/components/trunk/maven-site/src/site/apt/proposals: ./ plugin-tool-refactoring.apt

Author: jvanzyl Date: Sat May 14 06:05:29 2005 New Revision: 170139 URL: http://svn.apache.org/viewcvs?rev=170139&view=rev Log: o adding john's plugin tool refactoring document Added: maven/components/trunk/maven-site/src/site/apt/proposals/ maven/components/trunk/maven-site

Re: Changelog modification proposals to use incremental logs

Ben Walding <[EMAIL PROTECTED]> wrote on 10/07/2003 06:27:46 AM: > As you noted on #maven, linkcheck does have the capability of writing > it's cache in an area other than target. I usually configure linkcheck > to write to /tmp/linkcheck-${pom.id}.cache. Then let the OS clear it > out every o

Re: Changelog modification proposals to use incremental logs

As you noted on #maven, linkcheck does have the capability of writing it's cache in an area other than target. I usually configure linkcheck to write to /tmp/linkcheck-${pom.id}.cache. Then let the OS clear it out every once in a while. Perhaps we should formalise a slightly less volatile are

Re: Changelog modification proposals to use incremental logs

Luke Taylor wrote: if(incremental && output.exists()) { if(range != null && isn't empty) { // Parse existing xml file and build the entries list from it. Obviously I should have said here that entries before the requested range wouldn't be added to the list... -- Luke

Changelog modification proposals to use incremental logs

Hi, Following brief discussion on #Maven, I've had a look at the plugin and think the following would be the simplest approach - only requiring some changes to the ChangeLog class and an equals method in ChangeLogEntry. 1. Add equals method to ChangeLogEntry to compare author, date and comment.