Good Morning Michael
any timeline on pom.xml creation for tomcat source distros? i d/l 8.5.4 https://archive.apache.org/dist/tomcat/tomcat-8/v8.5.4/src/ and i see only 1 pom.xml for jdbc-pool but I see 3 build.xml find . name build.xml ./modules/jdbc-pool/build.xml ./res/deployer/build.xml ./webapps/ROOT/build.xml for each attempt to track down a TC problem i am forced to create pom.xml from scratch so I can build, package and deploy the war to locate the problem I of course will help you *behind the scenes* for any assistance you may require thanks, Martin ______________________________________________ "why do you help the british?..in 1812 they burned your capitol"..The Great Escape ________________________________ From: Michael Osipov <micha...@apache.org> Sent: Friday, May 12, 2017 6:58 PM To: Maven Developers List Subject: Re: [MNG-6169] Lifecycle/binding plugin version updates Am 2017-05-13 um 00:30 schrieb Hervé BOUTEMY: > Le vendredi 12 mai 2017, 13:50:37 CEST Michael Osipov a écrit : >> Am 2017-05-12 um 08:25 schrieb Hervé BOUTEMY: >>> Jenkins build is not flaky: it is strict on dependency resolution from >>> cache, which is an intent, not a bug >> >> This pretty much explains why a lot of ITs fail here at work with a >> empty repo. I will to work this through. > beware to not make the ITs fail with previous Maven versions All I did is this: https://github.com/apache/maven-integration-testing/commit/5c01864e44c7c96cac95545e8568acd044b6d7dc [https://avatars3.githubusercontent.com/u/573017?v=3&s=200]<https://github.com/apache/maven-integration-testing/commit/5c01864e44c7c96cac95545e8568acd044b6d7dc> [MNG-6169] Lifecycle/binding plugin version updates · apache/maven-integration-testing@5c01864<https://github.com/apache/maven-integration-testing/commit/5c01864e44c7c96cac95545e8568acd044b6d7dc> github.com MNG-5895 and MNG-6090 with ArtifactResolutionException. Add dependencies Maven Resources Plugin 3.0.2 and Maven Surefire 2.2.0 to bootstrap's group 7. >> >>> that's why I don't like changing default plugins versions: >>> >>> 1. depending on default plugins versions is a bad practice: IMHO, having >>> old plugins helps people know that they should not rely on it >> >> This basically means that people would need to provide versions >> explicitly in the POMs starting with Maven 4. > ??? Why are you talking about Maven 4? If you are saying that depending on default version is a bad practice it actually means to me that this should change in the new major. Shouldn't it? >> Looks like a lot of >> hassle, doesn't it? I'd better see this in the Super POM rather embedded >> in a JAR. > ??? "embedded in a JAR"? what did I say that lead to something like this? I assumed that your idea is rather nothing this up to the Super POM: ./maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml >>> 2. people who do a "dependency:go-offline" with a previous Maven version >>> but run offline with updated Maven version will see their build fail and >>> report about dependency:go-offline not being reliable, which is >>> technically not true, but is sensitive to Maven version (something that >>> is hard to explain) >> >> Pretty good point. We should actually ad this information to the goal >> doc. This will also fail if your change your POM. >> >>> On the first objection, it's a question of choice on how to promote the >>> good practice about explicitely choosing your plugins versions >>> >>> On the second objection, I had an idea of Maven core improvement that >>> would fix the go-offline dependency on Maven version used: what if Maven >>> core distribution did contain a (read-only) local repo with default >>> plugins already resolved? >>> >>> With such a feature, go-offline would not be dependant on Maven version >>> used (starting from the Maven version that has this pre-built repo). And >>> user would better see the default dependencies by looking at this >>> pre-builot repo = something I'm sure they will do (but they don't have a >>> look at lifecycle definition files, which are opaque for them) >>> >>> I didn't have time to work on implementing this idea, I suppose this would >>> just require a new default repository with file://${maven.home}/default- >>> plugins/ url, and to fill this repo at build time with appropriate >>> go-offline >> Sounds like a good idea but would produce a lot of bloat, wouldn't it? > what do you call "bloat"? and what do you call "a lot"? Is it better to > download plugin artifacts from network instead? > >> All plugin dependency trees. This should be configurable in settings.xml >> and MDEP should provide a goal to populate such a repo. >> I am afraid that no one will pick this up anytime soon. >> >> Do you know completely reject the issue to be merged? > I'd like to have us understand each other: > - what do you expect to win? > - what do we loose? > I know doing this update is easy to do and corresponds to a lot of good > intentions on giving latest of everything for lazy users: but the consequences > are IMHO not so positive and are for the moment misunderstood/ignored > My position is not definitive, the discussion on evaluating with multiple many > eyes if this change is really good or not, and goot at what, will make my > final > opinion on this: but sure, for the moment, I'm not convinced this update goes > in a good direction It wasn't easy. I invested quite some time to make all ITs pass. Some plugins weren't even updated because they cause regressions in ITs which I still haven't investigated yet. Some even cause zlib failures in native code (known JVM issue due to bad code). >> Michael >> >>> Le jeudi 11 mai 2017, 22:30:43 CEST Michael Osipov a écrit : >>>> Who seconds MNG-6169 for 3.5.1? I have a fully working branch >>>> (MNG-6169_2/not-updated-MJAR-MCOMPILER) passing all ITs on Windows 10 >>>> and FreeBSD 10.3-RELEASE. >>>> >>>> Jenkins build is flaky with notorious file://target/null artifact not >>>> found. >>>> >>>> Some bindings haven't been updated because they cause several ITs to >>>> fail (regressions). I will report them separately. >>>> >>>> >>>> Michael >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
