JDK 23 Feature Freeze / New Loom EA builds
on JDK 22 and bring multiple enhancements. For additional details, make sure to check [13]. Moreover, a new jextract guide [14] has been published. [12] https://jdk.java.net/jextract/ [13] https://mail.openjdk.org/pipermail/jextract-dev/2024-May/001699.html [14] https://github.com/openjdk/jextract/blob/master/doc/GUIDE.md ## JavaFX Early-Access Builds These are early access builds of the JavaFX 23 Runtime built from openjdk/jfx [15]. These builds enable JavaFX application developers to build and test their applications with JavaFX 23 on JDK 23. Although these builds are designed to work with JDK 23EA, they are also known to work with JDK 21 and later versions. The latest early access builds of JavaFX 23 are available here [16], under the GNU General Public License, version 2, with the Classpath Exception. JavaFX 23 API Javadocs [17] are also available. [15] https://github.com/openjdk/jfx [16] https://jdk.java.net/javafx23/ [17] https://download.java.net/java/early_access/javafx23/docs/api/overview-summary.html ## Topics of Interest - All Java 23 Features - Inside Java Newscast https://inside.java/2024/06/06/newscast-70/ - Module Imports in Java 23 - Inside Java Newscast https://inside.java/2024/05/16/newscast-69/ - Java 23: JavaDoc Hits the Markdown on Comments - Inside Java Newscast https://inside.java/2024/05/01/newscast-68/ - Java 23: Restoring the Balance with Primitive Patterns - Inside Java Newscast https://inside.java/2024/04/04/newscast-66/ - Java in 2024 - Constant evolution, delivered. https://inside.java/2024/06/01/java-in-2024-keynote/ - Introduction to JDK Mission Control https://inside.java/2024/05/18/jmc-intro/ - What's New in JMC 9? - Sip of Java https://inside.java/2024/04/21/sip096/ - Programmer's Guide to JDK Flight Recorder https://inside.java/2024/04/12/programmer-guide-to-jfr/ - A Decade of JDK Updates in OpenJDK https://inside.java/2024/04/09/a-decade-of-jdk-updates/ - Data-Oriented Programming - Version 1.1 https://inside.java/2024/05/23/dop-v1-1-introduction/ ~ As usual, let us know if you find any issues while testing your project(s) with the latest JDK early-access builds. Thank you! --David
Java 22 is GA + Heads-up!
nd DateTimeFormatter - JDK-8265372: Simplify PKCS9Attribute - JDK-8317431: Implement simpler Comparator when building certification paths - JDK-8327093: Add truncate function to BitMap API Note: A more detailed list of changes can be found here [12]. [10] https://jdk.java.net/23/ [11] https://jdk.java.net/23/release-notes [12] https://github.com/openjdk/jdk/compare/jdk-23+10...jdk-23+16 ## JavaFX 23 Early-Access Builds These are early access builds of the JavaFX 23 Runtime built from openjdk/jfx [13]. These builds enable JavaFX application developers to build and test their applications with JavaFX 23 on JDK 23. Although these builds are designed to work with JDK 23, they are also known to work with JDK 17 and later versions. The latest early access builds of JavaFX 23 Builds 10 (2024/3/26) are available [14], under the GNU General Public License, version 2, with the Classpath Exception. [13] https://github.com/openjdk/jfx [14] https://jdk.java.net/javafx23/ ## Topics of Interest: - The Arrival of Java 22 https://inside.java/2024/03/19/the-arrival-of-java-22/ - JDK 22 Release Notes Review (video) https://inside.java/2024/03/14/newscast-65/ - Java 22 in 2 Minutes https://inside.java/2024/03/21/sip095/ - (Dirty?) Tricks in Java 22 https://inside.java/2024/02/29/newscast-64/ - JDK 22 Security Enhancements https://seanjmullan.org/blog/2024/03/20/jdk22 - Java 17 to 21 - A Showcase of JDK Security Enhancements https://inside.java/2024/03/03/jfokus-jdk-security-changes/ - Netflix - Bending Pause Times to Your Will with Generational ZGC https://netflixtechblog.com/bending-pause-times-to-your-will-with-generational-zgc-256629c9386b - MethodHandle Primer https://jornvernee.github.io/methodhandles/2024/01/19/methodhandle-primer.html - Pruning Dead Exception Handlers https://jornvernee.github.io/hotspot/jit/2024/02/16/prune-dead-exception-handlers.html - Update on String Templates (JEP 459) https://mail.openjdk.org/pipermail/amber-spec-experts/2024-March/004010.html - The State of OpenJDK https://inside.java/2024/02/23/fosdem2024-openjdk-state/ - Project Wakefield - The JDK Wayland Desktop on Linux https://inside.java/2024/03/24/openjdk-wakefield/ - Project Leyden - Capturing Lightning in a Bottle https://inside.java/2024/02/28/leyden/ - jlink - Java's Custom Runtime Builder https://inside.java/2024/02/25/jlink-stackwalker/ - Modern Java in Action https://inside.java/2024/03/09/jfokus-modern-java-action/ - New Java Platform Extension for VS Code Release https://inside.java/2024/03/27/vscode-extension-update/ ~ That's it for this instalment. And don't forget to ping me if you encounter issues with JDK 23 EA builds. --David
Re: [VOTE] Require Java 17 for Maven 4
+1 (non binding, occasional user) David Jencks > On Feb 27, 2024, at 11:30 PM, Benjamin Marwell wrote: > > Hi Maven Devs/Users/Committers and PMC members! > > After several discussions on the mailing lists, I would like to > start a vote in favour of setting the minimal Java bytecode target > of Maven-Core 4 to 17 and hence require Java 17 for Maven 4. > > This is a procedural majority vote [1*]: > You can also vote with fractions and negative votes are not vetoes. > > Please also notice: > * Maven 3 will stay at Java 8 no matter what. > * We may raise Maven 4 to JDK 21 later if we feel like it (depending > on the release date). > This is not part of this vote. > * The linked PR is not part of this vote (this is not a code vote). > But you may take a look at it to understand the intended change. > > PR: https://github.com/apache/maven/pull/1430 > > Maven-Parent will not be raised with this vote, the other PR is not > part of this vote. > > Please refrain from starting discussions in this thread, but do > include a reasoning on downvotes and feel free to start a new > discussion on the mailing list, or comment on the existing ones. > > --- > > Vote open for 72 hours: > > [ ] +1 (set JDK17 min version for Maven 4.x) > [ ] +0 > [ ] -1 (please include reasoning) > > --- > > - Ben > > [1*]: https://www.apache.org/foundation/voting.html > > - > 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
Re: [DISCUSS] Java version for Maven
From your first paragraph I’d guess you would be on the “maven built on a recent LTS java” side. I was wondering, given these omnipresent IDES, and possibly from a philosophical perspective, what the arguments for “maven built on an antique JVM” would be. Thanks David Jencks > On Feb 20, 2024, at 8:10 PM, Hunter C Payne > wrote: > > IDEs, including the 2 you named, have a configuration system for multiple > JDKs. This allows devs to build for multiple versions of the JVM. Likewise, > Maven has multiple ways to configure multiple JDKs for use by different > phases or plugins used in a given compilation setup and to target different > versions of the JVM. Javac can target any older version than itself when > compiling to classfiles. So my JDK 17 can compile for Java 8-17 but not 18 > or higher. > > On the JVM, packaging is just a jar and inside that jar's classfiles will be > a specific minimum version of the JVM required for it to run. Generally > speaking, for a variety of reasons, most Java code is backwards compatible to > Java 8 which was released about 15 years ago. No specific code is that > backwards compatible but most of it is. That's why you don't realize that > these things exist. Because unless you are a professional developer, why > would you ever care in a language with 15 years of backwards compatibility > baked into the culture and large base of 3rd party code. Hope this answers > your question. > > Hunter > >On Tuesday, February 20, 2024 at 08:01:27 PM PST, David Jencks > wrote: > > I’ve been wondering for some time… My uninformed impression is that most > corporate development uses Eclipse or IntilliJ, which I believe run only on > the java version they come packaged with, which presumably is not usually the > target java version for the code being developed. Aside from packaging > questions (IIUC there’s no way for the maven project to ship a java > implementation), why should Maven be different? > > Thanks > David Jencks > >> On Feb 20, 2024, at 1:30 PM, Tamás Cservenák wrote: >> >> Romain, >> >> you immediately revealed your WHY: >> Take off your "paid dev" hat, and please try again. >> >> We ARE an open source project. >> So it IS about us, the volunteers. >> Is not about THEM, downstream users. >> >> As it was told a million times: >> if they are stuck (due whatever policy or who knows what), they can just >> stay with 3.9, 3.8 or whatever suits them. >> Why align with the "stuck" ones? >> >> T >> >> PS: and no, I just collected the last release VOTEs w/ Herve responses on >> ML. If you consider that biased, then you have a problem ;) >> >> >> >> On Tue, Feb 20, 2024 at 10:18 PM Romain Manni-Bucau >> wrote: >> >>>> I am sure the majority of Maven users do not run Maven on the same Java >>> version they target with their build. >>> >>> Do you use that and the following figures to do a biased conclusion? >>> >>> "If people don't use the same version then we can higher the version"? >>> >>> I think we need to consider two things: >>> >>> * We are OSS dev so not representative of the majority - in a company you >>> most of the time use the same version you target and want to run that, just >>> either laziness, policy or quality (building with different versions can >>> lead to surprises and falsy passing tests = broken prod), sadly it is hard >>> to find data there but I'm pretty sure it is a common experience >>> * Guess there is a "use the first matching version I have" in the stats you >>> mention, so if you target 11 and have 17 you would use 17 but does not mean >>> you are ok to run 21 (random numbers, move them a bit to be a counter >>> example on whatever digit you want for maven 4) >>> * Guess very few people want to have >= 1 JDK >>> >>> So clearly the question is not the latest LTS which would be for me just a >>> moving version we can't support and would be bad for our end users IMHO but >>> only the version we pick to start at 4.0.0. >>> Choices stay: >>> >>> * Latest LTS at that moment to start fresh and not inherit from a legacy at >>> day 0 >>> * Latest LTS - 1 - which would enable to cover more projects and get more >>> adoptions >>> * Something older but I don't find any valid reason since people skipping 2 >>> LTS will likely never reach maven 4 before we discuss to move our baseline >>> again. >>> >
Re: [DISCUSS] Java version for Maven
I’ve been wondering for some time… My uninformed impression is that most corporate development uses Eclipse or IntilliJ, which I believe run only on the java version they come packaged with, which presumably is not usually the target java version for the code being developed. Aside from packaging questions (IIUC there’s no way for the maven project to ship a java implementation), why should Maven be different? Thanks David Jencks > On Feb 20, 2024, at 1:30 PM, Tamás Cservenák wrote: > > Romain, > > you immediately revealed your WHY: > Take off your "paid dev" hat, and please try again. > > We ARE an open source project. > So it IS about us, the volunteers. > Is not about THEM, downstream users. > > As it was told a million times: > if they are stuck (due whatever policy or who knows what), they can just > stay with 3.9, 3.8 or whatever suits them. > Why align with the "stuck" ones? > > T > > PS: and no, I just collected the last release VOTEs w/ Herve responses on > ML. If you consider that biased, then you have a problem ;) > > > > On Tue, Feb 20, 2024 at 10:18 PM Romain Manni-Bucau > wrote: > >>> I am sure the majority of Maven users do not run Maven on the same Java >> version they target with their build. >> >> Do you use that and the following figures to do a biased conclusion? >> >> "If people don't use the same version then we can higher the version"? >> >> I think we need to consider two things: >> >> * We are OSS dev so not representative of the majority - in a company you >> most of the time use the same version you target and want to run that, just >> either laziness, policy or quality (building with different versions can >> lead to surprises and falsy passing tests = broken prod), sadly it is hard >> to find data there but I'm pretty sure it is a common experience >> * Guess there is a "use the first matching version I have" in the stats you >> mention, so if you target 11 and have 17 you would use 17 but does not mean >> you are ok to run 21 (random numbers, move them a bit to be a counter >> example on whatever digit you want for maven 4) >> * Guess very few people want to have >= 1 JDK >> >> So clearly the question is not the latest LTS which would be for me just a >> moving version we can't support and would be bad for our end users IMHO but >> only the version we pick to start at 4.0.0. >> Choices stay: >> >> * Latest LTS at that moment to start fresh and not inherit from a legacy at >> day 0 >> * Latest LTS - 1 - which would enable to cover more projects and get more >> adoptions >> * Something older but I don't find any valid reason since people skipping 2 >> LTS will likely never reach maven 4 before we discuss to move our baseline >> again. >> >> The other question we should probably anticipate is when do we move our >> support version range. >> Since java is not more predictable in terms of releases I think it can make >> sense to target for "new" releases only 2 (maybe 3 but really unsure?) LTS >> - indeed with best effort on later versions but no guarantee upfront. >> With such a policy calendar can be communicated and people can follow or >> not without surprises. >> >> So today, since we don't have yet a final I think 21 can make sense but not >> cause it is the current latest, cause it will likely be the ~N-1 at 4.0.0 >> time. >> >> Romain Manni-Bucau >> @rmannibucau <https://twitter.com/rmannibucau> | Blog >> <https://rmannibucau.metawerx.net/> | Old Blog >> <http://rmannibucau.wordpress.com> | Github < >> https://github.com/rmannibucau> | >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book >> < >> https://www.packtpub.com/application-development/java-ee-8-high-performance >>> >> >> >> Le mar. 20 févr. 2024 à 21:50, Tamás Cservenák a >> écrit : >> >>> Howdy, >>> >>> I intentionally used "Maven" here, and not "Maven 4" as I am sure the >>> majority of Maven users do not run Maven on the same Java version they >>> target with their build. We do not do that either. >>> >>> Some snippets from Herve (who is the ONLY one doing reproducible checks, >>> kudos for that) votes: >>> >>> Sun, Feb 18, 2024, 9:38 AM >>> [VOTE] Release Apache Maven Shade Plugin version 3.5.2 >>> Reproducible Build ok: reference build done with JDK 11 on *nix >>> >>> Wed, Jan 31, 2024, 5:06 AM >>&
JDK 22 Release Candidates & Virtual Threads pinning heads-up
early access builds of the JavaFX 22 & 23 Runtime built from openjdk/jfx [14]. These builds enable JavaFX application developers to build and test their applications with JavaFX 22 & 23 on JDK 22 & 23 respectively. Although these builds are designed to work with JDK 22 and above, they are also known to work with JDK 17 and later versions. The latest early access builds of JavaFX 22 Builds 29 are available [15], under the GNU General Public License, version 2, with the Classpath Exception. JavaFX 22 API Javadocs [16] are also available. The latest early access builds of JavaFX 23 Builds 5 are available [17], under the GNU General Public License, version 2, with the Classpath Exception. JavaFX 23 API Javadocs [18] are also available. [14] https://github.com/openjdk/jfx [15] https://jdk.java.net/javafx22/ [16] https://download.java.net/java/early_access/javafx22/docs/api/overview-summary.html [17] https://jdk.java.net/javafx23/ [18] https://download.java.net/java/early_access/javafx23/docs/api/overview-summary.html ## Topics of Interest - Java Renaissance Keynote https://inside.java/2024/02/05/java-renaissance/ - Managing Throughput with Virtual Threads - Sip of Java https://inside.java/2024/02/04/sip094/ - Data-Oriented Programming in Java 21 - JEP Café https://inside.java/2024/02/08/jepcafe22/ - Does Java 22 Kill Build Tools? - Inside Java Newscast https://inside.java/2024/02/15/newscast-63/ - JDK 22 G1/Parallel/Serial GC changes https://tschatzl.github.io/2024/02/06/jdk22-g1-parallel-gc-changes.html - Java 22 Previews Statements Before super(...) and this(...) https://inside.java/2024/02/01/newscast-62/ - State of jextract https://cr.openjdk.org/~mcimadamore/panama/jextract_changes.html - FOSDEM 2024: FFM API - A (quick) peek under the hood https://inside.java/2024/02/13/fosdem2024-ffm-api/ - FOSDEM 2024: Virtual Threads - Next Steps https://inside.java/2024/02/17/virtual-threads-next-steps/ - Java Language Update - Early 2024 Edition https://inside.java/2024/02/18/java-language-update-early-2024-update/ - When Should a Compiler Expand Garbage Collection Barriers? https://robcasloz.github.io/blog/2024/02/14/when-should-a-compiler-expand-garbage-collection-barriers.html - Emulating C# LINQ in Java using Code Reflection https://openjdk.org/projects/babylon/articles/linq - Automatic differentiation of Java code using Code Reflection https://openjdk.org/projects/babylon/articles/auto-diff ## Java Cryptographic Roadmap Update The Java Cryptographic Roadmap [19] has been updated with the following planned changes. * Enable XML Signature secure validation mode by default on JDK 11 and JDK 8 - Target date changed from the July 2024 CPU to the April 2024 CPU. - This change has already been made in JDK 17 and later releases. * Disable DTLS 1.0 in JDK 17 and 11 with the July 2024 CPU - This change has already been made in JDK 20 and later releases. - DTLS is not available in releases prior to JDK 9. [19] https://www.java.com/en/jre-jdk-cryptoroadmap.html ~ That's it for this installment. As usual, if you have issues, or questions, please ping me. --David
JDK 22 RDP2 & Deprecate sun.misc.Unsafe Memory-Access Methods…
When Processing Non-existent Files - JDK-8323659: LinkedTransferQueue add and put methods call overridable offer Note: A complete list of changes can be found here [11]. [8] https://jdk.java.net/22/ [9] https://jdk.java.net/22/release-notes [10] https://download.java.net/java/early_access/jdk22/docs/api/ [11] https://github.com/openjdk/jdk/compare/jdk-22+27...jdk-22+33 ## JDK 23 Early-Access builds JDK 23 Early-Access builds 7 are available [12] for testing. These EA builds are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes [13] are also available. ### Changes in recent JDK 23 builds that may be of interest: - JDK-8320597: RSA signature verification fails on signed data that does not encode params correctly [Reported by Apache POI] - JDK-8322214: Return value of XMLInputFactory.getProperty() changed from boolean to String in JDK 22 early access builds [Reported by Apache POI] - JDK-8321545: Override toString() for Format subclasses - JDK-8322366: Add IEEE rounding mode corruption check to JNI checks - JDK-8322383: G1: Only preserve marks on objects that are actually moved - JDK-8275338: Add JFR events for notable serialization situations - JDK-8320458: Improve structural navigation in API documentation - JDK-8320786: Remove ThreadGroup.stop - JDK-8320532: Remove Thread/ThreadGroup suspend/resume - JDK-8312150: Remove -Xnoagent option - JDK-8322829: Refactor nioBlocker to avoid blocking while holding Thread's interrupt lock - JDK-8322725: (tz) Update Timezone Data to 2023d - JDK-8321480: ISO 4217 Amendment 176 Update - JDK-8318971: Better Error Handling for Jar Tool When Processing Non-existent Files - JDK-8321594: NativeThreadSet should use placeholder for virtual threads - JDK-8321940: Improve CDSHeapVerifier in handling of interned strings - JDK-8321802: (zipfs) Add validation of incorrect LOC signature in ZipFileSystem - JDK-8322841: Parallel: Remove unused using-declaration in MutableNUMASpace - JDK-8319626: Override toString() for ZipFile - JDK-8322878: Including sealing information Class.toGenericString() Note: A more exhaustive changes list can be found here [14]. [12] https://jdk.java.net/23/ [13] https://jdk.java.net/23/release-notes [14] https://github.com/openjdk/jdk/compare/jdk-23+1...jdk-23+7 ## JavaFX 22 & 23 Early-Access Builds These are early access builds of the JavaFX 22 Runtime built from openjdk/jfx [14]. These builds enable JavaFX application developers to build and test their applications with JavaFX 22 on JDK 22. Although JavaFX 22 is designed to work with JDK 22, it is also known to work with JDK 17 and later versions. The latest early access builds of JavaFX 22 Builds 26 (2024/1/20) are available [15], under the GNU General Public License, version 2, with the Classpath Exception. JavaFX 22 API Javadocs [16] are also available. The first early access builds (2024/1/19) of JavaFX 23 are now also available [17]. [14] https://github.com/openjdk/jfx [15] https://jdk.java.net/javafx22/ [16] https://download.java.net/java/early_access/javafx22/docs/api/overview-summary.html [17] https://jdk.java.net/javafx23/ ## Topics of Interest - Podcast “The Panama Effect” with Jorn Vernee https://inside.java/2024/01/08/podcast-032/ - Java's Plans for 2024 - Inside Java Newscast https://inside.java/2024/01/18/newscast-61/ - Java 22 Unpacking - Inside Java Newscast https://inside.java/2023/12/07/newscast-59/ - Java Highlights of 2023 - Inside Java Newscast https://inside.java/2023/12/21/newscast-60/ - JDK 21: The GCs keep getting better https://kstefanj.github.io/2023/12/13/jdk-21-the-gcs-keep-getting-better.html - Java SE Security Developer’s Guide https://docs.oracle.com/en/java/javase/21/security/index.html#Java-Platform%2C-Standard-Edition - Another VS Code Extension for Java https://inside.java/2023/12/03/java-vscode-extension/ ## January 2024 Critical Patch Update Released As part of the January 2024 CPU, Oracle released OpenJDK 21.0.2, JDK 21.0.2 LTS, JDK 17.0.10 LTS, 11.0.22 LTS, 8u401, and 8u401-perf. ~ As usual, let us know if you find any quirks while testing your project(s) with the latest JDK early-access builds. --David
Re: JPMS support, refactored proposal
Apologies if this was already covered somewhere else, but would (or could) path accumulation support multi-release JAR layouts for all cases (whether it be modular or class-path JARs or filesystem paths)? On Tue, Jan 2, 2024 at 10:13 AM Martin Desruisseaux < martin.desruisse...@geomatys.com> wrote: > Hello all > > Following the recommendations in the "Guidance on Maven 4 API issue" > thread, I refactored the proposal. The new commits (only 2 at this time) > replace the previous ones. > > > Commit 1 > > The first commit [1] adds the following constants in the API: > > * In Type interface: POM, JAR, CLASSPATH_JAR, MODULAR_JAR, > JAVA_SOURCE, JAVADOC, TEST_JAR (see note below for December 14 change). > * In DependencyProperties interface: FLAG_MODULE_PATH_CONSTITUENT, > FLAG_PATCH_MODULE. > > The isAddedToModulePath() method is no longer introduced. Instead, this > commit deprecates isAddedToClasspath() methods because checking this > boolean value is not sufficient for determining if a dependency should > be on the classpath. > > The change in the MavenProject class are only factorization for reducing > code duplication and should not have behavioural impact. It is a > side-effect of the previous version of JPMS support proposal, with the > new methods removed. > > Note: I noticed that a commit on December 14th removed the POM, JAR, > etc. constants from the Type interface. So I suspect that my first > commit needs to be changed, but I'm not sure how. Where those constants > are supposed to be now, or has the "type" approach changed? > > > Commit 2 > > The second commit [2] add a new "enumeration" in the API: PathType. This > is actually implemented as a class for allowing extensions, but should > be understood as an enumeration. The enumeration contains the following > values: > > * CLASSES for the --class-path option > * MODULES for the --module-path option > * UPGRADE_MODULES for the --upgrade-module-path option > * PROCESSOR_CLASSES for the --processor-path option > * PROCESSOR_MODULES for the --processor-module-path option > * AGENT for the -agentpath option > * DOCLET for the -doclet option > * TAGLET for the -tagletpath option > * patchModule(String moduleName) for the --patch-module option > > The latter is the reason why this enumeration cannot be a > java.lang.Enum. Another reason is for allowing plugins to define their > own enumeration values. Then, this commit add a new method in > DependencyResolverResult: > > Map> getDispatchedPaths(); > > Above method is like getPaths(), but returns a distinct List for > each PathType instead of a single list mixing all kinds of path. The > PathType of each dependency is fully determined by the > DependencyProperties, which are themselves determined by the Type (at > least before the December 14th commit), except in the following cases: > > * If the type is "jar" instead of "classpath-jar" or "modular-jar", > then an heuristic rule similar to Maven 3 is applied. > * If the type is "test-jar", a more complex analysis is done for > inferring the --patch-module option value. > * The main and test output directories also needs some analysis for > inferring which Java 9+ compiler layout is used (package hierarchy > versus module hierarchy). > > Finally, this commit adds an implementation of above methods. In the > DefaultDependencyResolver class, the DefaultDependencyResolverResult > inner class has been extracted as a top-level class for making room for > more development. Then the resolve(DependencyResolverRequest) has been > refactored, but this refactoring should not change the way that the > existing `dependencies` and `paths` collections were populated. Then new > codes were added for populating the above-cited `dispatchedPath` map. > > This is not yet tested, but before working on tests and would like to > know what need to be changed (I suspect some changes will be needed, > e.g. regarding Type constants). > > Thanks, > > Martin > > > [1] > https://github.com/Geomatys/maven/commit/d05c51bd0f5fa5610b744ef66f159128303a67d7 > [2] > https://github.com/Geomatys/maven/commit/322dffddeb18d7acaea4a3670966dd5f8aeb4add > -- - DML • he/him
JDK 22 Feature Freeze!
Welcome to the final OpenJDK Quality Outreach update of 2023!
JDK 22, scheduled for General Availability on March 19, 2024, is now in
Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 22 feature set is
frozen (see the final list of JEPs integrated into JDK 22 below) and only
low-risk enhancements might still be considered. The coming weeks should be
leveraged to identify and resolve as many issues as possible, i.e. before JDK
22 enters the Release Candidates phase in early February 2024. So, we count on
you to test your projects and help us make JDK 22 another solid release!
[1] https://mail.openjdk.org/pipermail/jdk-dev/2023-December/008535.html
## JDK 22 Early-Access Builds
JDK 22 Early-Access builds 27 are now available [2] with the Release Notes here
[3]. Those builds are provided under the GNU GPL v2, with the Classpath
Exception.
### JEPs integrated into JDK 22:
- JEP 423: Region Pinning for G1
- JEP 447: Statements before super(…) (Preview)
- JEP 454: Foreign Function & Memory API
- JEP 456: Unnamed Variables & Patterns
- JEP 457: Class-File API (Preview)
- JEP 458: Launch Multi-File Source-Code Programs
- JEP 459: String Templates (2nd Preview)
- JEP 460: Vector API (7th Incubator)
- JEP 461: Stream Gatherers (Preview)
- JEP 462: Structured Concurrency (2nd Preview)
- JEP 463: Implicitly Declared Classes and Instance Main Methods (2nd Preview)
- JEP 464: Scoped Values (2nd Preview)
### Changes in recent JDK 22 builds that may be of interest:
- JDK-8318646: Integer#parseInt("") throws empty NumberFormatException message
[Reported by Apache Lucene]
- JDK-8318082: ConcurrentModificationException from IndexWriter [Reported by
JOOQ]
- JDK-8319450: New methods java.net.InetXAddress.ofLiteral() miss @since tag
[Reported by JaCoCo]
- JDK-8321164: javac w/ annotation processor throws AssertionError: Filling
jrt:/… during … [Reported by Hibernate]
- JDK-8310644: Make panama memory segment close use async handshakes
- JDK-8302233: HSS/LMS: keytool and jarsigner changes
- JDK-8211238: New @Deprecated JFR event
- JDK-8319124: Update XML Security for Java to 3.0.3
- JDK-8306055: Add a built-in Catalog to JDK XML module
- JDK-8319244: implement JVMTI handshakes support for virtual threads
- JDK-8319196: ExecutableElement.getReceiverType doesn't return receiver types
for methods loaded from bytecode
- JDK-8318759: Add four DigiCert root certificates
- JDK-8317374: Add Let's Encrypt ISRG Root X2
- JDK-8306116: Update CLDR to Version 44.0
- JDK-8287843: File::getCanonicalFile doesn't work for \\?\C:\ style
paths DOS device paths
- JDK-8288899: java/util/concurrent/ExecutorService/CloseTest.java failed with
"InterruptedException: sleep interrupted"
- JDK-8311596: Add separate system properties for TLS server and client for
maximum chain length
- JDK-8318160: javac does not reject private method reference with
type-variable receiver
- JDK-8305753: Allow JIT compilation for -Xshare:dump
- JDK-8187591: -Werror turns incubator module warning to an error
- JDK-8318096: Introduce AsymmetricKey interface with a getParams method
- JDK-8319174: Enhance robustness of some j.m.BigInteger constructors
- JDK-8288899: Changes to java.util.concurrent.ForkJoinPool and ForkJoinTask
- JDK-8272215: Add InetAddress methods for parsing IP address literals
- JDK-8316996: Catalog API Enhancement: add a factory method
- JDK-8305814: Update Xalan Java to 2.7.3
- JDK-8313643: Update HarfBuzz to 8.2.2
- JDK-8316030: Update Libpng to 1.6.40
Note: A more comprehensive list of changes can be found here [4].
[2] https://jdk.java.net/22/
[3] https://jdk.java.net/22/release-notes
[4] https://github.com/openjdk/jdk/compare/jdk-22+20...jdk-22+27
## JDK 23 Early-Access Builds
Given that JDK 22 is in Rampdown Phase, the initial JDK 23 EA builds are now
also available [5]. These EA builds are provided under the GNU General Public
License v2, with the Classpath Exception.
[5] https://jdk.java.net/23/
## JavaFX 22 Early-Access Builds
These are early-access builds of the JavaFX 22 [8] Runtime built from
openjdk/jfx [9]. This allows JavaFX application developers to build and test
their applications with JavaFX 22 on JDK 22. The JavaFX 22 API Javadocs are
also available [10].
The JavaFX runtime is delivered as an SDK and as a set of jmods for each
platform. You can use the SDK to compile and run JavaFX applications. You can
use the jmods with jlink to create a JDK that includes the JavaFX modules, and
optionally, your modular application. JavaFX 22 is designed to work with JDK
22,but it is known to work with JDK 17 and later versions.
[8] https://jdk.java.net/javafx22/
[9] https://github.com/openjdk/jfx
[10]
https://download.java.net/java/early_access/javafx22/docs/api/overview-summary.html
## Topics of Interest:
- Java 22 Unpacking - Inside Java Newscast
https://inside.java/2023/12/07/newscast-59/
- Java On The GPU - Inside Java Newscast
https://inside.java/2023/11/16/newscast-58/
- Better Java
Re: Request for a release of Maven Surefire
On Thu, Nov 30, 2023 at 1:40 PM Michael Osipov wrote: > On 2023/11/30 16:54:44 David Lloyd wrote: > > Would it be possible to request that a committer initiate a release of > > Maven Surefire? There are a couple of bugfixes that are blocking releases > > of a couple of Red Hat projects and it would be good to get them cleared > up > > before everyone disappears for the holidays. > > I need to merge one more PR and then I will do the release. > Great, thank you! -- - DML • he/him
Request for a release of Maven Surefire
Would it be possible to request that a committer initiate a release of Maven Surefire? There are a couple of bugfixes that are blocking releases of a couple of Red Hat projects and it would be good to get them cleared up before everyone disappears for the holidays. Thanks! -- - DML • he/him
JDK 21 Is Now GA, a New VS Code Extension, and an Annotation Processing Heads-up
URL https://stuartmarks.wordpress.com/2023/09/22/my-favorite-jdk-21-feature-javadoc-search-url/ Upgrading from Java 17 to 21 #RoadTo21 https://inside.java/2023/08/27/roadto21-upgrade/ Java 21 API Changes #RoadTo21 https://inside.java/2023/09/10/roadto21-api/ Java 21 Security #RoadTo21 https://inside.java/2023/09/13/roadto21-security/ Java 21 Tool Enhancements: Better Across the Board #RoadTo21 https://inside.java/2023/09/06/roadto21-performance/ Java 21 JVM and GC Improvements #RoadTo21 https://inside.java/2023/09/03/roadto21-performance/ Java 21 Brings Full Pattern Matching #RoadTo21 https://inside.java/2023/09/17/roadto21-pattern-matching/ Java 21 new feature: Virtual Threads #RoadTo21 https://inside.java/2023/08/30/roadto21-virtualthreads/ G1: Java's Default Garbage Collector https://inside.java/2023/10/15/g1/ New candidate JEP: 457: Class-File API (Preview) https://openjdk.org/jeps/457 Using JAXB in Custom Ant Tasks on Recent Java Versions https://jaitechwriteups.blogspot.com/2023/10/using-jaxb-in-custom-ant-tasks-on.html Java Records are "Trusted" and Consequently Faster http://minborgsjavapot.blogspot.com/2023/09/java-records-are-trusted-and.html JVMLS 2023 Keynote https://inside.java/2023/09/14/jvmls-keynote/ JVMLS - Project Leyden https://inside.java/2023/09/07/project-leyden/ JVMLS - Value Objects in Valhalla https://inside.java/2023/09/05/value-objects-in-valhalla/ Complete JVMLS 2023 playlist https://www.youtube.com/playlist?list=PLX8CzqL3ArzW90jKUCf4H6xCKpStxsOzp Teaching Old Streams New Tricks https://inside.java/2023/10/11/devoxx-teaching-old-streams-new-tricks/ Support Markdown in javadoc Comments https://mail.openjdk.org/pipermail/javadoc-dev/2023-October/006455.html Brian Goetz Answers Your Java Questions https://inside.java/2023/10/20/ama-brian/ ## October 2023 Critical Patch Update Released As part of the October 2023 CPU, Oracle released OpenJDK 21.0.1, JDK 21.0.1, JDK 17.0.9 LTS, 11.0.21 LTS, 8u391, and 8u391-perf. ~ PS: Don't forget to update me about your plans related to Java 21. Until next time! --David
JDK 21 Release Candidates & JVM Language Summit
/ JVMLS - Foreign Function & Memory API https://inside.java/2023/08/21/jvmls-ffm-api/ JVMLS - Java and GPU … are we nearly there yet? https://inside.java/2023/08/22/java-and-gpu/ Draft JEP: Computed Constants https://minborgsjavapot.blogspot.com/2023/08/java-new-draft-jep-computed-constants.html Using Computed Constants to Manage Static State in Leyden https://cr.openjdk.org/~jrose/leyden/after-computed-constants.html Project Leyden: Toward Condensers https://openjdk.org/projects/leyden/notes/03-toward-condensers New OpenJDK Container mailing list https://mail.openjdk.org/pipermail/container-discuss/2023-August/00.html Introduction: Q-descriptors and v-bytecodes https://cr.openjdk.org/~jrose/values/larval-values.html ~ Until next time! --David
JDK 22 is in Rampdown Phase 2 | Annotation Processing Change Heads-up
JDK-8027711: Unify wildcarding syntax for CompileCommand and CompileOnly - JDK-8282797: CompileCommand parsing errors should exit VM - JDK-8305104: Remove the old core reflection implementation - JDK-8310460: Remove jdeps -profile option - JDK-8309032: jpackage does not work for module projects unless --module-path is specified - JDK-8291065: Creating a VarHandle for a static field triggers class initialization - JDK-8312072: Deprecate for removal the -Xnoagent option - JDK-8304885: Reuse stale data to improve DNS resolver resiliency= - JDK-8310047: Add UTF-32 based Charsets into StandardCharsets - JDK-8302483: Enhance ZIP performance - JDK-8300596: New System Property to Control the Maximum Size of Signature Files - JDK-8294323: ASLR Support for CDS Archive - JDK-8311038: Incorrect exhaustivity computation - JDK-8312089: Simplify and modernize equals, hashCode, and compareTo in java.nio… - JDK-8311188: Simplify and modernize equals and hashCode in java.text - JDK-8300285: Enhance TLS data handling - JDK-8302475: Enhance HTTP client file downloading [14] https://github.com/openjdk/jdk/compare/jdk-22%2B1...jdk-22%2B8 ## JavaFX Early-Access Builds These are early access builds of the JavaFX 21 Runtime, built from openjdk/jfx [15]. They enable JavaFX application developers to build and test their applications with JavaFX 21 on JDK 21. The latest JavaFX 21 early-access builds (build 27 - 2023/7/21) are now available [16] with their related Javadoc [17]. Moreover, the initial JavaFX 22 early-access builds [18] are now also available. These early-access builds are provided under the GNU General Public License, version 2, with the Classpath Exception. Please send feedback to the openjfx-dev mailing list [19]. [15] https://github.com/openjdk/jfx [16] https://jdk.java.net/javafx21/ [17] https://download.java.net/java/early_access/javafx21/docs/api/overview-summary.html [18] https://jdk.java.net/javafx22/ [19] http://mail.openjdk.org/mailman/listinfo/openjfx-dev ## Topics of Interest: Foreign Function & Memory API Summer Update https://mail.openjdk.org/pipermail/panama-dev/2023-July/019510.html What's Arriving for JFR in JDK 21 - Inside Java Newscast #53 https://inside.java/2023/07/20/java-21-jfr/ Java's Startup Booster: CDS - Stack Walker https://inside.java/2023/07/11/javas-startup-booster-cds/ ## July 2023 Critical Patch Update Released As part of the July 2023 CPU, Oracle released OpenJDK 20.0.2, JavaFX 20.0.2, JDK 20.0.2, JDK 17.0.8 LTS, JDK 11.0.20 LTS, JDK 8u381, as well as JDK 8u381-perf. ~ We still have a few days before JDK 21 enters into the Release Candidate phase so please make sure to test your projects on the latest early-access builds and report any issue. PS: Make sure to enjoy the summer and recharge your batteries! --David
JDK 21 is in Rampdown / The importance of testing with Early-Access Builds
JDK-8307478: Implementation of Prepare to Restrict The Dynamic Loading of Agents - JDK-8301553: Support Password-Based Cryptography in SunPKCS11 - JDK-8308341: JNI_GetCreatedJavaVMs returns a partially initialized JVM - JDK-8308108: Support Unicode extension for collation settings - JDK-8305972: Update XML Security for Java to 3.0.2 - JDK-8305091: Change ChaCha20 cipher init behavior to match AES-GCM - JDK-8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts - JDK-8307547: Support variant collations - JDK-8308876: JFR: Deserialization of EventTypeInfo uses incorrect attribute names - JDK-8297878: KEM: Implementation - JDK-8308819: add JDWP and JDI virtual thread support for ThreadReference.ForceEarlyReturn - JDK-8307779: Relax the java.awt.Robot specification - JDK-8306703: JFR: Summary views - JDK-8309146: extend JDI StackFrame.setValue() and JDWP StackFrame.setValues minimal support for virtual threads - JDK-8307840: SequencedMap view method specification and implementation adjustments - JDK-8304438: jcmd JVMTI.agent_load should obey EnableDynamicAgentLoading - JDK-8306431: File.listRoots method description should be re-examined [5] https://jdk.java.net/21/ [6] https://jdk.java.net/21/release-notes [7] https://download.java.net/java/early_access/jdk21/docs/api/ [8] https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007910.html [9] https://github.com/openjdk/jdk/compare/jdk-21+23...jdk-21+26 ## JDK 22 Early-Access Builds Given that JDK 21 is now in Rampdown Phase, the initial JDK 22 Early-Access builds are now also available [10]. Those EA builds are provided under the GNU General Public License v2, with the Classpath Exception. [10] https://jdk.java.net/22/ ## JavaFX 21 Early-Access Builds These are early access builds of the JavaFX 21 Runtime, built from openjdk/jfx [11]. They are intended to allow JavaFX application developers to build and test their applications with JavaFX 21 on JDK 21. The latest builds 21 (2023/6/8) are now available [12]. These early-access builds are provided under the GNU General Public License, version 2, with the Classpath Exception. Feedback should be reported to the openjfx-dev mailing list [13]. [11] https://github.com/openjdk/jfx [12] https://jdk.java.net/javafx21/ [13] http://mail.openjdk.org/mailman/listinfo/openjfx-dev ## Topics of Interest All That is in Java 21?! https://inside.java/2023/06/08/newscast-50/ Script Java Easily in 21 and Beyond https://inside.java/2023/05/25/newscast-49/ New JFR `view` Command https://egahlin.github.io/2023/05/30/views.html Patterns: Exhaustiveness, Unconditionality, and Remainder https://openjdk.org/projects/amber/design-notes/patterns/exhaustiveness Design Document on Nullability and Value Types https://mail.openjdk.org/pipermail/valhalla-spec-observers/2023-May/002243.html JFR: Java's Observability & Monitoring Framework - Stack Walker #2 https://inside.java/2023/05/14/stackwalker-02/ ## JDK Crypto Roadmap Update Oracle updated the JDK Cryptographic Roadmap to announce a change, with the Oct CPU (2023-10-17), of the priority order used by JDK 8 and JDK 11 when negotiating cipher suites to use on TLS connections. Please check the JDK Cryptographic Roadmap page [14] for more details. [14] https://www.java.com/en/jre-jdk-cryptoroadmap.html ~ Please, make sure to test your projects using the JDK 21 EA builds as we still have time to fix potential issues. And thanks for participating in the OpenJDK Quality Outreach program! --David
Re: Question - JDK Minimum of future Apache Maven 4.0.0
I wonder if having maven require java 8 syntax discourages any potential contributors who are used to coding using more recent developments. I have no idea how to tell, but maybe someone else does. David Jencks > On Jun 1, 2023, at 3:02 PM, Karl Heinz Marbaise wrote: > > Hi, > > my clear opinion is to go with most recent JDK LTS version for the > release point of Maven 4.0.0 which I assume will be JDK 21... > > That means clear the build time requirement which is completely > different from runtime of an application. > > > Older JDK's are supported by some vendors by having particular special > support which most of the time requires special contracts (means also > paying money for it)..some of them offering builds without paying money > yes.. > > Older runtime target are supported with different approaches like > Toolchain or via `--release XX` which exists since JDK9+. > > > Furthermore if someone is not capable of upgrading the build environment > to JDK9+ they can continue to use Maven 3.8.X or Maven 3.9.X... > > If it would be requirement to port things back to 3.8.X or 3.9.X it > could be handled by someone who has the time etc. to do that ... if not, > those people might think of paying someone to do that work... > > > The given argument about JPMS for migration causes issues is from my > point of view false-positive because migration to newer JDK versions > does not require JPMS usage... > > Even platforms like AWS support JDK17 in the meantime which is the > runtime... > > > Based on the argument we don't need features of JDK17+ I see a number > of things which could make our handling/maintenance easier for example > using sealed classes to prevent exposing internal things to public which > could be used etc. also some other small features (`var` for example; > Text-Blocks in Tests etc) or using records in some situation... > > > Based on the maintenance part it would mean in consequence to downgrade > to even JDK7... (or even lower) because you can get support for older > JDK version in some ways... (JDK7 from azul for example) > > Kind regards > Karl Heinz Marbaise > > [1] https://www.oracle.com/java/technologies/java-se-support-roadmap.html > > - > 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
JDK 21 EA builds 22 & Sequenced Collections Heads-up
rticipating in the OpenJDK Quality Outreach program. If you find any issue on JDK 21 EA builds, please send it my way! --David
JDK 20 is now GA, JDK 21 Early-Access builds, and 2 important heads-up!
nded to allow JavaFX application developers to build and test their applications with JavaFX 21 on JDK 21. The latest builds 9 (2023/3/20) are now available [19] and are provided under the GNU General Public License, version 2, with the Classpath Exception. Please report feedback on the openjfx-dev mailing list [20]. [18] https://github.com/openjdk/jfx [19] https://jdk.java.net/javafx21/ [20] http://mail.openjdk.org/mailman/listinfo/openjfx-dev ## New Generational ZGC Early-Access Builds The latest builds 21-genzgc+5-33 (2023/3/9) are available [21]. These open-source binaries of Generational ZGC [22] are based on an incomplete version of JDK 21 and are provided under the GNU General Public License, version 2, with the Classpath Exception. Please send feedback on the zgc-dev mailing list [23]. [21] https://jdk.java.net/genzgc/ [22] https://openjdk.org/jeps/439 [23] http://mail.openjdk.org/mailman/listinfo/zgc-dev ## Topics of Interest: The Arrival of Java 20! https://inside.java/2023/03/21/the-arrival-of-java-20/ Video: Java First. Java Always. | Level Up Keynote https://inside.java/2023/03/22/levelup-keynote/ Video: Java 20 Unboxing - Inside Java Newscast https://inside.java/2023/03/23/newscast-44/ JDK 20 Security Enhancements https://seanjmullan.org/blog/2023/03/22/jdk20 G1/Parallel/Serial GC improvements in JDK 20 https://tschatzl.github.io/2023/03/14/jdk20-g1-parallel-gc-changes.html Podcast: “Preview Features: A Look Back and A Look Ahead” with Alex Buckley https://inside.java/2023/03/21/podcast-030/ Video: Write performant Java code with the Vector API - JEP Café https://inside.java/2023/03/14/jepcafe18/ Video: Data-Oriented Programming in Java https://inside.java/2023/03/09/data-oriented-programming/ Video: ZGC - Java’s Highly Scalable Low-Latency Garbage Collector https://inside.java/2023/03/05/stackwalker-01/ Video: The Holy Grail of Java Performance - Inside Java Newscast https://inside.java/2023/03/02/newscast-43/ Video: Programmer's Guide to JDK Flight Recorder https://inside.java/2023/02/27/programmer-guide-to-jfr/ Video: Foreign Function & Memory API Live https://inside.java/2023/02/16/ffm-api/ JEP targeted to JDK 21: 430: String Templates (Preview) https://openjdk.org/jeps/430 JEP targeted to JDK 21: 431: Sequenced Collections https://openjdk.org/jeps/431 ~ Thanks for participating in the OpenJDK Quality Outreach program. And as always, if you find an issue, please let us know through the usual channels. -- David - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
JDK 20 Release Candidate and Deprecation
va.net/21/ [10] https://download.java.net/java/early_access/jdk21/docs/api/ [11] https://jdk.java.net/21/release-notes ### Changes in recent JDK 21 builds that may be of interest: - JDK-8299891: JMX ObjectInputFilter additional classes needed [Reported by Apache Derby] - JDK-8298478: (fs) Path.of should allow input to include long path prefix - JDK-8300869: Make use of the Double.toString(double) algorithm in java.ut… - JDK-8300891: Deprecate for removal javafx21x.swing.plaf.synth.SynthLookAndFee… - JDK-8286907: keytool should warn about weak PBE algorithms - JDK-8298445: Add LeakSanitizer support in HotSpot - JDK-8288050: SunJCE provider now supports SHA-512/224 and SHA-512/256 as digests for the PBES2 algorithms - JDK-8301207: (jdeps) Deprecate jdeps -profile option - JDK-8300247: Harden C1 xchg on AArch64 and PPC - JDK-8208077: File::listRoots Changed To Return All Available Drives On Windows - JDK-8300623: Lambda deserialization regression involving Enum method reference - JDK-8294680: Refactor scaled border rendering - JDK-8300584: Accelerate AVX-512 CRC32C for small buffers - JDK-8299896: Reduce enum values of HtmlLinkInfo.Kind - JDK-8300266: Detect Virtualization on Linux aarch64 - JDK-8298908: Instrument Metaspace for Asan ## Generational ZGC Early-Access Builds The latest Early-Access builds (build 21-genzgc+1-8 - 2023/1/27) of Generational ZGC [12] are available [13]. Those builds are based on an incomplete version of JDK 21 and are provided under the GNU General Public License, version 2, with the Classpath Exception. Feedback should be sent to the zgc-dev mailing list [14]. [12] https://bugs.openjdk.org/browse/JDK-8272979 [13] https://jdk.java.net/genzgc/ [14] https://mail.openjdk.org/pipermail/zgc-dev ## JavaFX 21 Early-Access Builds The Early-Access builds of the JavaFX runtime, built from openjdk/jfx [15], allow JavaFX application developers to build and test their applications with JavaFX 21 on JDK 21. The latest Early-Access builds (build 2 2023/1/27) are now available [16] under the GNU General Public License, version 2, with the Classpath Exception. The related Javadocs are available here [17]. Feedback should be sent to the openjfx-dev mailing list [18]. [15] https://github.com/openjdk/jfx [16] https://jdk.java.net/javafx21/ [17] https://download.java.net/java/early_access/javafx21/docs/api/index.html [18] http://mail.openjdk.org/mailman/listinfo/openjfx-dev ## Topics of Interest: - JDK 21 - Image Performance Improvements https://minborgsjavapot.blogspot.com/2023/02/jdk-21-image-performance-improvements.html - JDK 21 - Performance Improvements Revealed https://minborgsjavapot.blogspot.com/2023/01/java-21-performance-improvements.html - From Java Security with Love - Inside Java Newscast #42 https://inside.java/2023/02/14/newscast-42/ - ZGC - The Future of Low-Latency Garbage Collection Is Here https://inside.java/2023/01/25/zgc/ - Draft JEP: JDK Packaging Guidelines https://mail.openjdk.org/pipermail/jdk-dev/2023-February/007327.html - Future Java - Prepare Your Codebase Now! - Inside Java Newscast #41 https://inside.java/2023/02/02/newscast-41/ - Java Modules in Real Life https://inside.java/2023/01/29/java-modules-in-real-life/ ~ Thanks for participating in the OpenJDK Quality Outreach program. And as always, if you find an issue, please let us know through the usual channels. -- David - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
JDK 20 Rampdown Phase 2 & JMX Heads-up
Hi, First off, on behalf of Oracle’s Java Team, I’d like to wish you a happy and prosperous new year! In 2023, two Java releases will be made available: JDK 20 (March) & JDK 21 (September). JDK 20 [1] has entered Rampdown Phase Two (RDP2) [2], its initial Release Candidate is planned for February 9. Given that and to be better prepared for the future, it makes sense to begin testing your project(s) using JDK 21 early-access (EA) builds. Your feedback allows us to evaluate and address issues you find while testing EA builds. [1] https://jdk.java.net/20/ [2] https://mail.openjdk.org/pipermail/jdk-dev/2023-January/007308.html [3] https://jdk.java.net/21/ ## Heads-up - JDK 21: JMX Subject Delegation & Fine-grained Security Deprecation JMX has some features that rely on Security Manager APIs which are deprecated for removal (see JEP 411 [4]). These features are "Subject Delegation" and "Fine-grained Security", which both seem to be generally unused, and would require significant investment to implement without touching the deprecated APIs. As a consequence, "Subject Delegation" is being proposed for deprecation in JDK 21 [5]. Fine-grained Security is also being considered for deprecation at the same time. This feature [6] has allowed configuration of a security policy to restrict or permit access to specific MBean actions. It is expected that this feature is generally unused, possibly because there is simply no demand for such detailed control, and that it is too complex to create and maintain the policies. [4] https://openjdk.org/jeps/411 [5] https://bugs.openjdk.org/browse/JDK-8298966 [6] https://docs.oracle.com/en/java/javase/19/jmx/fine-grained-security-example.html ## JDK 20 Early-Access builds The latest early-access builds of JDK 20 (builds 32) are available [7], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [8]. [7] https://openjdk.org/projects/jdk/20/ [8] https://jdk.java.net/20/release-notes ### JEPs integrated into JDK 20: - JEP 429: Scoped Values (Incubator) - JEP 432: Record Patterns (2nd Preview) - JEP 433: Pattern Matching for switch (4th Preview) - JEP 434: Foreign Function & Memory API (2nd Preview) - JEP 436: Virtual Threads (2nd Preview) - JEP 437: Structured Concurrency (2nd Incubator) ### Changes in recent JDK 20 builds that may be of interest: - JDK-8298525: javadoc crashes with "UnsupportedOperationException: Not yet implemented" in SeeTaglet.inherit [Reported by Apache Ant] - JDK-8298893: Rename option UsePolyIntrinsics to UsePoly1305Intrinsics - JDK-8287411: Enhance DTLS Performance - JDK-8293554: Enhanced DH Key Exchanges ## JDK 21 Early-Access builds The latest early-access builds of JDK 21 (builds 6) are available [9], and are provided under the GNU General Public License v2, with the Classpath Exception. The related EA API Javadoc is also available [10]. [9] https://jdk.java.net/21/ [10] https://download.java.net/java/early_access/jdk21/docs/api/ ### Changes in recent JDK 21 builds that may be of interest: - JDK-8297295: Remove ThreadGroup.allowThreadSuspension - JDK-8287411: Enhance DTLS performance - JDK-8233269: Improve handling of JAVA_ARGS - JDK-8297933: Compiler should only use verified interface types for optimization - JDK-8298381: Improve handling of session tickets for multiple SSLContexts - JDK-8299501: Usage of constructors of primitive wrapper classes should be avoided in java.util API docs - JDK-8299475: Enhance SocketException by cause where it is missing in net and nio area - JDK-8299544: Improve performance of CRC32C intrinsics (non-AVX-512) for small inputs - JDK-8299576: Reimplement java.io.Bits using VarHandle access - JDK-8278326: Socket close is not thread safe and other cleanup - JDK-8299673: Simplify object pinning interactions with string deduplication ## JavaFX 20 & 21 Early-Access Builds These are early-access builds of the JavaFX Runtime, built from openjdk/jfx [11]. Those EA builds are intended to allow JavaFX application developers to build and test their applications with JavaFX 20 on JDK 20. The latest EA builds (JavaFX 20 EA b16 2023/1/14) are now available [12] and are provided under the GNU General Public License, version 2, with the Classpath Exception. Please note that initial JavaFX 21 early-access builds (JavaFX 21 b1 2023/1/19) are now available [13] as well. Feedback should be reported to the openjfx-dev mailing list [14]. [11] https://github.com/openjdk/jfx [12] https://jdk.java.net/javafx20/ [13] https://jdk.java.net/javafx21/ [14] http://mail.openjdk.org/mailman/listinfo/openjfx-dev ## Topics of Interest: - On Markdown in (Java) documentation comments https://mail.openjdk.org/pipermail/javadoc-dev/2023-January/005563.html - Lifetimes in the Foreign Function & Memory API https://cr.openjdk.java.net/~mcimadamore/panama/why_lifetimes.html - Java's Plans for 2023 - Inside Java
JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds
New Generational ZGC [13] Early-Access Builds have been updated recently [14]. These EA builds are provided under the GNU GPL v2, with the Classpath Exception. ### Changes include : - Rebased on top of jdk-20+21 - Added macOS builds - Heuristics rewriten to deal with a problematic case where Generational ZGC spent too much focus on doing young generation collection when it’s more beneficial to spend resources to collect the old generation. - GC logging rewriten to easier see what log lines belong to what collection / generation, plus many additional changes that should make it easier to read and understand GC logs - Barrier elision enhanced to remove barriers from array access of newly allocated arrays - Enhanced the generated hs_err crash text file - Fixed and unified code quality and style For more information, make sure to watch this Inside Java Newscast [15] dedicated on Generational ZGC. Feedback should be sent to the zgc-dev mailing list [16]. [13] https://jdk.java.net/genzgc/ [14] https://bugs.openjdk.org/browse/JDK-8272979 [15] https://inside.java/2022/11/17/insidejava-newscast-037/ [16] https://mail.openjdk.org/pipermail/zgc-dev/ ## JavaFX 20 Early-Access Builds These are early access builds of the JavaFX 20 Runtime, built from openjdk/jfx [17]. They allow JavaFX application developers to build and test their applications with JavaFX 20 on JDK 20. The latest builds 10 (2022/12/5) are now available [18] with javadoc here [19]. Feedback should be forwarded to the openjfx-dev [19] mailing list. For more details, you might want to listen this Inside Java podcast episode [20]. [17] https://github.com/openjdk/jfx [18] https://jdk.java.net/javafx20/ [19] https://download.java.net/java/early_access/javafx20/docs/api/overview-summary.html [20] http://mail.openjdk.org/mailman/listinfo/openjfx-dev [21] https://inside.java/2022/11/18/podcast-027/ ## Topics of Interest: - Building and Deploying Java Client Desktop Applications with JDK 17 and Beyond https://inside.java/2022/12/08/building-java-desktop-app/ - Java Value Objects in Action with Valhalla - JEP Café #15 https://inside.java/2022/12/06/jepcafe15/ - Java 20 - Sneak Peek on the Foreign Function & Memory API https://minborgsjavapot.blogspot.com/2022/12/java-20-sneak-peek-on-panama-ffm-api.html - A Glimpse at Java 20 - Pattern Matching, Concurrent Programming and Valhalla - Inside Java Newscast #38 https://inside.java/2022/12/01/newscast-38/ - “JavaFX” - Inside Java Podcast #27 https://inside.java/2022/11/18/podcast-027/ - Generational ZGC - Inside Java Newscast #37 https://inside.java/2022/11/17/insidejava-newscast-037/ - Java 17 to 20 Pattern Matching full tutorial with Records, Instanceof and Switch - JEP Café #14 https://inside.java/2022/11/08/jepcafe14/ - Script Friendly JDK Download URLs https://inside.java/2022/11/14/sip072/ - Using the JShell API to improvement a Java Source Browser https://inside.java/2022/11/21/jshell-java-source-browser/ ~ As usual, let us know if you find any quirks while testing your project(s) on the latest JDK early-access builds. As year-end is approaching, I'd like to thank you for being part of the OpenJDK Quality Outreach Program. I hope that you will disconnect a bit to spend time with your family and your friends. See you in 2023 with Java 20 and Java 21! --David - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Speed up release process?
Evidently you know something I don’t, and I hope you’ll explain it to me. For the 3rd time, >>>>> Which developers have to pause what activities? — Right now there are usually release votes in parallel. As I pointed out, all 308 could be in parallel. What relevance does your calculation have to anything? This discussion looks to me like the others I’ve seen about shortening release votes: someone is basically complaining that the apache process is inconvenient for a particular subset of developers on a particular project, without examining what the actual roadblocks to effective development are or what other solutions might be possible. In particular, I’d like to see an analysis of what would happen if a “release” was for a particular project plus all downstream changes needed to use it, whether as a single vote or as concurrent votes. Thanks David Jencks > On Nov 18, 2022, at 1:48 PM, Tamás Cservenák wrote: > > damn me > > 16848 hours = 702 days = almost TWO YEARS of Maven releases just to build > Maven itself. > > But, if you consider all apache artifacts (almost all, unsure is there > other in different groupId) > [cstamas@blondie local (master %)]$ find * -type f -name "*.jar" | grep > "commons-" | wc -l > 45 > [cstamas@blondie local (master %)]$ find * -type f -name "*.jar" | grep > "org/apache" | wc -l > 263 > > In total, 308 JARs = 22176 hours = 924 days = 2,5 years. > > T > > On Fri, Nov 18, 2022 at 10:30 PM Tamás Cservenák > wrote: > >> David, >> >> I agree, and understand. >> >> But let me step back a bit: >> ASF (as it all started around httpd) as a foundation hosts MANY projects >> wildly different projects, and those projects usually have a handful (few, >> when compared to Maven) of "deliverables" or "artifacts" being released. Or >> in other words (and am not trying to lessen their complexity or nor to >> present Maven as something "special" here), most of ASF projects have few, >> very few deliverables (again, I am talking about the majority, correct me >> if I am wrong). Really, are there any statistics about: >> - number of reposes used per ASF project >> - number of different (!) artifact releases done per project? >> >> Maven on the other hand, while id DOES also have ONE "downloadable" item >> on download page (https://maven.apache.org/download.cgi) we all know that >> story does not end there: it is known to "download the whole internet", >> just to run Maven "mvn clean verify" it will download zillion of plugins >> and their dependant artifacts (and I did not even mention 3rd party, non >> ASF plugins). So, Maven, as a "deliverable" or "product" is definitely not >> one ZIP file you see on the download page. ASF Maven project has many >> interconnected reposes/artifacts/releases. >> >> So, what I want to say: is it possible that ASF "way" works for "typical" >> projects, while Maven is more like "atypical"? >> >> Or, to make my example more concrete: >> 1. I checked out master of maven from http://github.com/apache/maven >> 2. built it w/ pristine local repo >> 3. and run some stats on it: >> 4. https://gist.github.com/cstamas/ee2bba03f61d09fa3f5e9c57844207b7 >> >> This simply means that for the end user, the "experience of ASF Maven" is >> literally 1 (that on download page) + 233 = 234 releases. And it is all >> very interconnected. >> >> Btw, I just downloaded 16848 hours :) >> >> T >> >> On Fri, Nov 18, 2022 at 9:53 PM David Jencks >> wrote: >> >>> You are free to do your own research. I’ve seen plenty of “but we want >>> the convenience of <72hr releases” discussions over the years, and the >>> feedback I’ve seen is consistently that the reason for the “should” rather >>> than “must” is to account for emergency security patches etc, not normal >>> releases. >>> >>> David Jencks >>> >>>> On Nov 18, 2022, at 11:54 AM, Tamás Cservenák >>> wrote: >>>> >>>> As I wrote, we did have examples of changes + cascading, it is okay. >>>> >>>> But I don't agree with your statement about the board, as they >>> themselves >>>> state "should" not "must" for 72h. If it does not cut with them, they >>>> should modify the refd page(s). >>>> >>>> And it's not "we're impatient" either, part of the response for that is >>&
Re: [DISCUSS] Speed up release process?
If all 153 projects released at once with 72 hour windows, that would be 72 hours. That’s just as plausible as sequential releases. David Jencks > On Nov 18, 2022, at 11:54 AM, Tamás Cservenák wrote: > > As I wrote, we did have examples of changes + cascading, it is okay. > > But I don't agree with your statement about the board, as they themselves > state "should" not "must" for 72h. If it does not cut with them, they > should modify the refd page(s). > > And it's not "we're impatient" either, part of the response for that is in > "hasty changes" canned response. > > Simply put: > - people see releases as a chore, as some "burden" that needs to be done > once in a while (see refd Slack messages in 1st mail), and when it comes to > be done, "let's do it when it's worth". We have MANY user questions on ML > of type "when is X released? As the issue [the user is interested in] is > fixed". And we have too many "dropped balls" in our court. IMHO, modifying > the process (to take less than 72+2h) is one step toward making release > less painful, less blocker. > > Fun fact: maven project consists of (not sure of exact count, just > guessing) 150+ repositories (GH on ASF org gives 153 when I type in > "maven-" in the repo search bar). This is a LOT. If we'd, for some reason, > start releasing all of those in 72h windows, it would be 10800 hours, or > 450 days, more than a year. > > > On Fri, Nov 18, 2022 at 8:34 PM David Jencks > wrote: > >> Which developers have to pause what activities? >> >> From previous discussions elsewhere, I’m strongly of the opinion that < 72 >> hr release votes are intended only for emergency security fixes and similar >> events, and that “we’re impatient” isn’t going to cut it with the board. >> It certainly wouldn’t with me. >> >> How many of these annoyances would be eliminated by an easy way to release >> and vote on a set of changed artifacts + the cascading dependencies all at >> once? >> >> thanks >> David Jencks >> >>> On Nov 18, 2022, at 11:17 AM, Tamás Cservenák >> wrote: >>> >>> David, >>> >>> I just meant that there is a "forced pause" of 72h. >>> >>> T >>> >>> On Fri, Nov 18, 2022 at 7:50 PM David Jencks >>> wrote: >>> >>>> +1 from the sidelines. >>>> >>>> I don’t understand >>>>>>> * current process causes (forced) context switching, and can likely >>>> lead to >>>> human mistakes: when the release vote is announced, developer is FORCED >> to >>>> stop for 72h and possibly switch. This is just a productivity killer. >>>> <<< >>>> Who is forced to do anything and for what reason? >>>> >>>> >> >> >> - >> 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
Re: [DISCUSS] Speed up release process?
You are free to do your own research. I’ve seen plenty of “but we want the convenience of <72hr releases” discussions over the years, and the feedback I’ve seen is consistently that the reason for the “should” rather than “must” is to account for emergency security patches etc, not normal releases. David Jencks > On Nov 18, 2022, at 11:54 AM, Tamás Cservenák wrote: > > As I wrote, we did have examples of changes + cascading, it is okay. > > But I don't agree with your statement about the board, as they themselves > state "should" not "must" for 72h. If it does not cut with them, they > should modify the refd page(s). > > And it's not "we're impatient" either, part of the response for that is in > "hasty changes" canned response. > > Simply put: > - people see releases as a chore, as some "burden" that needs to be done > once in a while (see refd Slack messages in 1st mail), and when it comes to > be done, "let's do it when it's worth". We have MANY user questions on ML > of type "when is X released? As the issue [the user is interested in] is > fixed". And we have too many "dropped balls" in our court. IMHO, modifying > the process (to take less than 72+2h) is one step toward making release > less painful, less blocker. > > Fun fact: maven project consists of (not sure of exact count, just > guessing) 150+ repositories (GH on ASF org gives 153 when I type in > "maven-" in the repo search bar). This is a LOT. If we'd, for some reason, > start releasing all of those in 72h windows, it would be 10800 hours, or > 450 days, more than a year. > > > On Fri, Nov 18, 2022 at 8:34 PM David Jencks > wrote: > >> Which developers have to pause what activities? >> >> From previous discussions elsewhere, I’m strongly of the opinion that < 72 >> hr release votes are intended only for emergency security fixes and similar >> events, and that “we’re impatient” isn’t going to cut it with the board. >> It certainly wouldn’t with me. >> >> How many of these annoyances would be eliminated by an easy way to release >> and vote on a set of changed artifacts + the cascading dependencies all at >> once? >> >> thanks >> David Jencks >> >>> On Nov 18, 2022, at 11:17 AM, Tamás Cservenák >> wrote: >>> >>> David, >>> >>> I just meant that there is a "forced pause" of 72h. >>> >>> T >>> >>> On Fri, Nov 18, 2022 at 7:50 PM David Jencks >>> wrote: >>> >>>> +1 from the sidelines. >>>> >>>> I don’t understand >>>>>>> * current process causes (forced) context switching, and can likely >>>> lead to >>>> human mistakes: when the release vote is announced, developer is FORCED >> to >>>> stop for 72h and possibly switch. This is just a productivity killer. >>>> <<< >>>> Who is forced to do anything and for what reason? >>>> >>>> >> >> >> - >> 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
Re: [DISCUSS] Speed up release process?
Lets try one question/issue per email… Which developers have to pause what activities. David Jencks > On Nov 18, 2022, at 11:54 AM, Tamás Cservenák wrote: > > As I wrote, we did have examples of changes + cascading, it is okay. > > But I don't agree with your statement about the board, as they themselves > state "should" not "must" for 72h. If it does not cut with them, they > should modify the refd page(s). > > And it's not "we're impatient" either, part of the response for that is in > "hasty changes" canned response. > > Simply put: > - people see releases as a chore, as some "burden" that needs to be done > once in a while (see refd Slack messages in 1st mail), and when it comes to > be done, "let's do it when it's worth". We have MANY user questions on ML > of type "when is X released? As the issue [the user is interested in] is > fixed". And we have too many "dropped balls" in our court. IMHO, modifying > the process (to take less than 72+2h) is one step toward making release > less painful, less blocker. > > Fun fact: maven project consists of (not sure of exact count, just > guessing) 150+ repositories (GH on ASF org gives 153 when I type in > "maven-" in the repo search bar). This is a LOT. If we'd, for some reason, > start releasing all of those in 72h windows, it would be 10800 hours, or > 450 days, more than a year. > > > On Fri, Nov 18, 2022 at 8:34 PM David Jencks > wrote: > >> Which developers have to pause what activities? >> >> From previous discussions elsewhere, I’m strongly of the opinion that < 72 >> hr release votes are intended only for emergency security fixes and similar >> events, and that “we’re impatient” isn’t going to cut it with the board. >> It certainly wouldn’t with me. >> >> How many of these annoyances would be eliminated by an easy way to release >> and vote on a set of changed artifacts + the cascading dependencies all at >> once? >> >> thanks >> David Jencks >> >>> On Nov 18, 2022, at 11:17 AM, Tamás Cservenák >> wrote: >>> >>> David, >>> >>> I just meant that there is a "forced pause" of 72h. >>> >>> T >>> >>> On Fri, Nov 18, 2022 at 7:50 PM David Jencks >>> wrote: >>> >>>> +1 from the sidelines. >>>> >>>> I don’t understand >>>>>>> * current process causes (forced) context switching, and can likely >>>> lead to >>>> human mistakes: when the release vote is announced, developer is FORCED >> to >>>> stop for 72h and possibly switch. This is just a productivity killer. >>>> <<< >>>> Who is forced to do anything and for what reason? >>>> >>>> >> >> >> - >> 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
Re: [DISCUSS] Speed up release process?
Which developers have to pause what activities? From previous discussions elsewhere, I’m strongly of the opinion that < 72 hr release votes are intended only for emergency security fixes and similar events, and that “we’re impatient” isn’t going to cut it with the board. It certainly wouldn’t with me. How many of these annoyances would be eliminated by an easy way to release and vote on a set of changed artifacts + the cascading dependencies all at once? thanks David Jencks > On Nov 18, 2022, at 11:17 AM, Tamás Cservenák wrote: > > David, > > I just meant that there is a "forced pause" of 72h. > > T > > On Fri, Nov 18, 2022 at 7:50 PM David Jencks > wrote: > >> +1 from the sidelines. >> >> I don’t understand >>>>> * current process causes (forced) context switching, and can likely >> lead to >> human mistakes: when the release vote is announced, developer is FORCED to >> stop for 72h and possibly switch. This is just a productivity killer. >> <<< >> Who is forced to do anything and for what reason? >> >> - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Speed up release process?
+1 from the sidelines.
I don’t understand
>>>* current process causes (forced) context switching, and can likely lead to
human mistakes: when the release vote is announced, developer is FORCED to
stop for 72h and possibly switch. This is just a productivity killer.
<<<
Who is forced to do anything and for what reason?
AFAIK cascading dependencies can be handled by releasing cause + all effects at
once. If that’s hard to do now, maybe there’s a way to make it easier. I’d
expect it would make testing a change more plausible as well.
David Jencks
> On Nov 18, 2022, at 10:44 AM, Romain Manni-Bucau
> wrote:
>
> Hi Tamás,
>
> Is 3 days that bothering - didnt spot it to be honest?
> Indeed, strictly speaking you can do "until we get 3 bindings +1" - don't
> think you can say for a maximum otherwise it means you need to cancel if
> you don't get it ;) - but it also means you mean the project does not care
> about its core people - if you start the release on friday night you
> potentially let 0s to some PMC and users to review the release.
> Indeed it is ont an apache requirement but I think it is a good thing to
> enable people to review a release and have the opportunity to give feedback
> so 3 days sounds like a very good default if you take into account the
> world side - timezones - of our project.
>
> Side note: guess exceptions can be done for CVE, milestones, beta, alpha,
> ... - anything not final or urgent but very located.
>
> Hope it makes sense.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le ven. 18 nov. 2022 à 18:55, Tamás Cservenák a
> écrit :
>
>> Howdy,
>>
>> My pet peeve these days is our release process. IMHO, we should be able to
>> release ("move") much faster than today.
>>
>> My proposal would be:
>> * vote is "done done" the moment quorum is reached
>> * change the wording in the vote email from "Vote open for at least 72
>> hours." to "Vote open for a maximum of 72 hours.".
>>
>> Reasoning:
>> * vote cannot be vetoed by definition (only release mgr can cancel it).
>> * change would not conflict with ASF defined rules, the 72h is not
>> compulsory (document states "should" not "must").
>> * the release process is already wearisome, complex, and is easy to miss
>> (over-represented) manual steps. For example yesterday for some reason it
>> took almost 2 hours to sync release artifacts to Maven Central, during
>> which you are in a "busy loop" (the announcement and site depends on sync).
>> Leaving it "for tomorrow" may cause users to learn about a new release thru
>> Artifact Listener or whatever other service, causing confusion. Ideally,
>> site and announcement mail should be tied to sync, and that does lead to
>> "busy loop".
>> * current process causes (forced) context switching, and can likely lead to
>> human mistakes: when the release vote is announced, developer is FORCED to
>> stop for 72h and possibly switch. This is just a productivity killer.
>> * which part do you like: as a developer sitting on needles while being
>> blocked on upstream (dependency) bugfix or as a user waiting for bugfix?
>> * we already agreed on one minor process improvement: we have quite long
>> "chains" of dependencies, so a bugfix that can span on long trails could
>> take weeks to be done serially, even if the bugfix itself is trivial. Hence
>> we did accept that we can do "batch votes" (release together) and can do
>> one vote for this case.
>> * on positive site this could lead to mindset change of bugfix releases, as
>> today, few wants to go thru painful release process for "single simple
>> change" (see ASF Slack #maven for "ahh Apache process..."), that IMHO is
>> wrong: we all should release early and often. And be happy with it, not
>> feel it like chores :)
>>
>> Finally some "canned responses":
>> * "time is needed for all interested parties to review": If someone cannot
>> get to it in 5 minutes, or in 5 hours or in 5 days, it really but really
>> does not matter, as release is to happen anyway (unless release mgr cancels
>> it). One not getting to it, will be notified via mails anyway (vote
JDK 20 EAb22, ZenGC EA builds, JavaFX 20 EAb5 and several heads-ups!
ndations for High-Scale Java Applications https://www.infoq.com/articles/java-virtual-threads/ ## October 2022 Critical Patch Update Released As part of the October 2022 CPU, we released JDK 19.0.1, JDK 17.0.5 LTS, JDK 11.0.17 LTS and JDK 8u351 as well as OpenJDK 19.0.1. That's it for this time. As usual, let us know if you find any issues while testing your project(s) on the latest JDK early-access builds. Thanks for your support! --David - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Automatically format and sort imports
A possible data point… For a while I worked on isomorphic-git (javascript) which had a pre-commit hook to format the code. It was rather surprising at first, but I ended up really liking it, more than projects that attempted to check the formatting during the build, which were susceptible to ways of running the build that skipped the format check. David Jencks > On Oct 13, 2022, at 8:31 AM, Guillaume Nodet wrote: > > Le jeu. 13 oct. 2022 à 17:13, Łukasz Dywicki <mailto:l...@code-house.org>> a écrit : > >> Some of findings I have: >> >> - Static code analysis might be slow, reformatting code will add >> additional time to the build which might not be desired for developer >> experience >> > > This is usually reduced to 0 because the plugins just check on files that > have been modified since the last build. > > >> - Error messages produced after reformatting might mistake first time >> contributors who are not familiar with reformatting step done before >> compilation >> > > Not sure to understand what you mean. Formatting is not supposed to throw > errors... > > >> - I recently found a plugin for IJ: >> https://github.com/krasa/EclipseCodeFormatter >> <https://github.com/krasa/EclipseCodeFormatter> (allows to unify two >> dominant IDEs) >> > > Forcing specific a environment in IDE is not ideal imho. If you work on > different projects, you then need to activate / deactivate plugins or > your code style everytime you switch. > In addition, not enforcing the code style strictly leads to source files > being not inline with the formatter settings. WHich in turns means that > you can't really use it because whenever you do, you end up with many > changes unrelated to your current work that you need to undo in order to > keep your PR clean and minimal. > I think that's a real problem, and that would also be solved by an > automatic format imho. > > >> - Verification of code style might be automated via pull requests, if >> PRs are enforced. Otherwise core developers must take care of their >> habits or commit hooks. >> > > I still don't see the problems with an automatic format step. I've been > using it in projects for years in camel. The only problem is when people > don't build before committing, but that can't really happen in the maven > land > where almost all changes are done through PRs and validated. We just need > to enforce the no-file modified step in PRs. Ideally, we'd even have a > commit hook to enforce that. Not sure if that's doable. > > If there a real problems, what could be done is move the autoformatting > step in a separate profile which could be deactivated by default (though > people that want it can activate it in their settings). The PR workflow > would enable this profile and ensure there's no modification to the input > files. I really don't see the benefit of not running it for everyone, but > if some people do, that's fine with me. > > >> >> Cheers, >> Łukasz >> >> On 13.10.2022 15:27, Guillaume Nodet wrote: >>> Le jeu. 13 oct. 2022 à 12:50, Olivier Lamy a écrit : >>> >>>> On Thu, 13 Oct 2022 at 17:47, Tamás Cservenák >> wrote: >>>>> >>>>> Howdy, >>>>> >>>>> to not get lost in implementation details, it is really unimportant >>>>> (spotless, this or that...) >>>>> >>>>> What IS important is that we agree to implement "IDE agnostic source >>>>> formatting", that happens during build >>>>> (by maven plugin). This means _everyone_ will end up with 100% the same >>>>> result. >>>>> >>>>> The only thing that comes to my mind is "sloppy committer" who does not >>>>> build but pushes >>>> >>>> not sure to understand. You mean formatting sources will be bind to a >>>> phase and be executed automatically? >>>> >>> >>> Yes, I meant "automatic" in opposition to "on demand". Sorry if that was >>> not clear. >>> >>> >>>> >>>> Wouldn’t it be better to still have a check as today (checkstyle:check >>>> or the used foo-bar-formatter-plugin:check) which checks the sources >>>> at validate phase. >>>> Then in case of failure, the committer can just run >>>> foo-bar-formatted-plugin:format. >>>> So committer can apply some manual changes as well. >>>> this will detect "sloppy" committer as today by simp
JDK 19 GA, JDK 20 EAb16, and some heads-up!
rialData system property - JDK-8244681: Add a warning for possibly lossy conversion in compound assignments - JDK-8256265: G1: Improve parallelism in regions that failed evacuation - JDK-8293861: G1: Disable preventive GCs by default - JDK-8293922: Extend barrier-less Java thread transitions to native transition - JDK-8290169: adlc: Improve child constraints for vector unary operations ### Additional changes that may be of interest: - JDK-8288933: Improve the implementation of Double/Float.isInfinite - JDK-8173605: Remove support for source and target 1.7 option in javac - JDK-8288966: Better handle very spiky promotion in G1 - JDK-8291753: Add JFR event for GC CPU Time - JDK-8292579: (tz) Update Timezone Data to 2022c - JDK-8282648: Weaken the InflaterInputStream specification in order to allow faster Zip implementations - JDK-8291660: Grapheme support in BreakIterator - JDK-8292240: CarrierThread.blocking not reset when spare not activated - JDK-8287908: Use non-cloning reflection methods where acceptable - JDK-8292628: x86: Improve handling of constants in trigonometric stubs - JDK-8292878: x86: Make scratch register usage explicit in assembler code - JDK-8290249: Vectorize signum on AArch64 - JDK-8292203: AArch64: Represent Registers as values - JDK-8292587: AArch64: Support SVE fabd instruction - JDK-8292575: risc-v: Represent Registers as values ## Topics of Interest: - Moving Java Forward with Java 19 https://inside.java/2022/09/20/moving-java-forward/ - “Java 19 is Here!” with Brian Goetz and Ron Pressler - Inside Java Podcast https://inside.java/2022/09/20/podcast-026/ - JDK 19 - Security Enhancements https://seanjmullan.org/blog/2022/09/22/jdk19 - JDK 19 - G1/Parallel/Serial GC improvements https://tschatzl.github.io/2022/09/16/jdk19-g1-parallel-gc-changes.html - “Java 19 in Action” - Inside Java Newscast https://inside.java/2022/09/08/insidejava-newscast-033/ - G1 Pre-Barrier Implementation https://albertnetymk.github.io/2022/07/22/g1_barrier/ - New candidate JEP: 430: String Templates (Preview) https://openjdk.org/jeps/430 - OpenJDK: Where the Magic Happens https://inside.java/2022/09/12/change-the-future-of-java/ That's it for this time. I hope to see some of you in a few weeks during JavaOne in Vegas. And again, if you haven't made your J1 plans yet, please ping me. --David - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
JDK 19 first Release Candidates!
a.net/jextract/ [7] https://github.com/openjdk/jextract [8] https://openjdk.org/projects/code-tools/ [9] http://mail.openjdk.org/mailman/listinfo/jextract-dev ## Topics of Interest * Podcast: “JavaOne is Back!” https://inside.java/2022/08/03/podcast-025/ * Sequenced Collections, Purity, and more at JavaOne https://inside.java/2022/08/11/insidejava-newscast-031/ * Concurrent Marking in G1 https://tschatzl.github.io/2022/08/04/concurrent-marking.html * Java Asynchronous Programming Full Tutorial with Loom and Structured Concurrency - JEP Café https://inside.java/2022/08/02/jepcafe13/ * New candidate JEP: 429: Extent-Local Variables (Incubator) https://openjdk.org/jeps/429 ## JDK Update Patch Release To fix a regression (JDK-8292260) in the C2 JIT compiler, we have produced update patch releases for the impacted supported Java SE versions. The new versions are JDK 18.0.2.1 (publicly available), 17.0.4.1 (publicly available), 11.0.16.1.1, and OpenJDK 18.0.2.1 (publicly available). As usual, let us know if you find any issues while testing your project(s) on the latest JDK early-access builds. Thanks for your support! --David - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
JDK 19: Rampdown Phase 2 + JavaOne
7/07/jepcafe12/ * Java 19 Virtual Threads - JEP Café https://inside.java/2022/06/08/jepcafe11/ ## July 2022 Critical Patch Update Released As part of the July 2022 CPU, we released JDK 18.0.2, JDK 17.0.4 LTS, JDK 11.0.16 LTS, JDK 8u341 and JDK 7u351 as well as OpenJDK 18.0.2 ~ As always, if you find an issue while testing your project(s), please let us know through the usual channels. Thanks for your support! -- David - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
JDK 19: Rampdown Phase 1 + EA builds 26 & JDK 20: EA builds 1
g Finalizers with Cleaners https://inside.java/2022/05/25/clean-cleaner/ * Testing Clean Cleaner Cleanup https://inside.java/2022/05/27/testing-clean-cleaner-cleanup/ * Improved JFR Ergonomics https://egahlin.github.io/2022/05/31/improved-ergonomics.html * Java 19 Virtual Threads - JEP Café https://inside.java/2022/06/08/jepcafe11/ * Deconstructing Records in Pattern Matching - Inside Java Newscast https://inside.java/2022/06/02/insidejava-newscast-026/ * Concurrent Thread-stack Processing in the Z Garbage Collector https://inside.java/2022/05/31/zgc-concurrent-thread-stack-processing/ As usual, let us know if you find any issues while testing your project(s) on the latest JDK early-access builds. Thanks for your support! --David - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [RESULT] [VOTE] Apache Maven Surefire 3.0.0-M7
Well, we had found that we couldn't get all the required variations of JUnit 5 working in Maven without the M release, so we had to upgrade. We have tested our scenarios with M7, including test suites and mixed Junit4 and JUnit5 tests, and we're not seeing any problems (including one scenario that produced the BufferOverflow exception with M6). The thing is, if you're not confident enough with it to produce a non-M release, that makes us a little nervous also. The scenarios we've tested are a tiny fraction of the services that will be using this. I don't expect to see any unexpected problems, but that's normal. However, I can certainly understand you concluding you don't have enough data to really be confident it's fully ready. The one thing we've determined in our testing is that if a particular service finds some unexpected problem at any level of the JUnit 5 upgrade (starting with simply upgrading the surefire version to 3.0.0-M7), they can simply stay with JUnit 4 and Surefire 2.x, and they can move forward with that, while we file that as a scenario that we need to troubleshoot. We can live with that. On Wed, Jun 8, 2022 at 6:20 PM Olivier Lamy wrote: > On Wed, 8 Jun 2022 at 04:29, David Karr > wrote: > > > Now that M7 is released, I have a feeling I know the answer to this, but > > what are your thoughts about when a full release will go out with these > > latest changes? I'm currently evaluating whether we can upgrade our > > internal platform to support Junit 5. As far as we know, M7 will address > > the last problem we were seeing (buffer overflow), and we'll be testing > > that this morning, but my "platform" team only has a small set of > services > > we can easily test platform upgrades with. Our platform is used by a > large > > number of services. Using a "beta" version carries some amount of > > indeterminate risk (sort of redundant), so I have to be more careful > about > > planning for contingencies if we discover unexpected problems from the M7 > > version in other services we don't directly support. Those contingencies > > include staying on Surefire 2.22.0, but still using Spring Boot 2.3.12 > > (upgrading this will be coming soon), and only using JUnit 4. > > > > > Well I think using Mx is because we are a bit conservative :) > version naming is a bit of a chicken and egg problem! > We'd like to have more feedback/tests (even issues :)) etc.. from the real > world but as it's called M* people do not upgrade. > I do not see real issues with junit5. > BUT I think there are still some problems with JPMS and the default (and > non configurable) options used. > Let me explain that. First you need to know surefire (and few other plugins > such compiler, javadoc) rely on a library called plexus-java which from a > list of jars will parse all the module-info files to build a sort of graph > and so build the module-path and the classpath. > 3.0.0-M5 has been released in June 2020 with plexus-java 1.0.5 from > February 2020. > 3.0.0-M6 has been released at the end of March 2022 with plexus-java 1.1.1 > from January 2022. > It's always 2 years between those releases and by the way plenty of changes > in the plexus-java library (because of some issues with compiler, javadoc > etc..) > (With my committer of Jetty project hat) we use JPMS now and moving from > 3.0.0-M5 to M6 is impossible because of > https://issues.apache.org/jira/browse/SUREFIRE-2057 which is breaking > change in plexus-java > and now upgrading to M7 is impossible either because of another issue > (which I need to create a jira for it). (but there is a gist explaining the > problem here > https://gist.github.com/olamy/d651e21fd89b73612a42e3617a1d0261 > ) > Ideally I'd like to have more configurable options for jpms (e.g module > graph resolution) because actually it's based on some assumptions which can > be wrong for some use cases. > I'm currently collecting use cases etc... Then I will create a Jira to ask > for comments (such as what do you want guys to be configurable for jpms: > test scope should be in module-path or classpath, same for provided, do we > need to add automatically providers to the module-path even if it's a test > dependency). > I think this needs to be fixed before removing the M* :) because jpms get > more and more adoptions now. > > > > > > > > > > > > > > > On Mon, Jun 6, 2022 at 4:16 PM Olivier Lamy wrote: > > > > > Hi > > > The vote has passed. > > > +1 Enrico, Hervé, Michael, Romain, Slawomor, Olivier > > > > > > PMC quorum reached. I will continue the release process. > > > > > > cheers > > > Olivier > > > > > >
Re: [RESULT] [VOTE] Apache Maven Surefire 3.0.0-M7
Now that M7 is released, I have a feeling I know the answer to this, but what are your thoughts about when a full release will go out with these latest changes? I'm currently evaluating whether we can upgrade our internal platform to support Junit 5. As far as we know, M7 will address the last problem we were seeing (buffer overflow), and we'll be testing that this morning, but my "platform" team only has a small set of services we can easily test platform upgrades with. Our platform is used by a large number of services. Using a "beta" version carries some amount of indeterminate risk (sort of redundant), so I have to be more careful about planning for contingencies if we discover unexpected problems from the M7 version in other services we don't directly support. Those contingencies include staying on Surefire 2.22.0, but still using Spring Boot 2.3.12 (upgrading this will be coming soon), and only using JUnit 4. On Mon, Jun 6, 2022 at 4:16 PM Olivier Lamy wrote: > Hi > The vote has passed. > +1 Enrico, Hervé, Michael, Romain, Slawomor, Olivier > > PMC quorum reached. I will continue the release process. > > cheers > Olivier >
JDK 19 - Virtual Threads Testing!
nate Data Streams by default - JDK-8284930: Re-examine FilterInputStream mark/reset - JDK-8284890: Support for Do not fragment IP socket options - JDK-8282823: javac should constrain more uses of preview APIs - JDK-8285477: Add a PRECISION public static field to j.l.Float and j.l.Double Build 19: - JDK-8186958: New Methods to Create Preallocated HashMaps - JDK-8284775: Simplify String.substring(_, length()) calls - JDK-8283892: Compress and expand bits - JDK-8280915: Better parallelization for AbstractSpliterator and IteratorS… - JDK-8284681: compiler/c2/aarch64/TestFarJump.java fails with "RuntimeExce… - JDK-8283790: G1: Remove redundant card/heap-address transition - JDK-8285001: Simplify StringLatin1.regionMatches - JDK-8284880: Re-examine sun.invoke.util.Wrapper hash tables - JDK-8278356: Improve file creation ## Topics of Interest - Java Cryptographic Roadmap update https://java.com/en/jre-jdk-cryptoroadmap.html - Virtual Thread Deep Dive https://inside.java/2022/04/07/insidejava-newscast-023/ - Why Write an Empty finalize() Method? https://stuartmarks.wordpress.com/2022/04/27/why-write-an-empty-finalize-method/ - WHEN and NULL In Pattern Matching https://inside.java/2022/05/05/insidejava-newscast-024/ - JDK 8 to JDK 18 in GC: 10 Releases, 2000+ Enhancements https://inside.java/2022/05/02/odl-jdk8-to-jdk18-gc/ - ZGC - What's new in JDK 18 https://malloc.se/blog/zgc-jdk18 - Java Next - From Amber to Loom, from Panama to Valhalla https://inside.java/2022/05/09/java-next/ ## JDK Update Patch Release As announced with the April 2022 CPU release, we have produced update patch releases for all Java SE supported versions. The new versions are JDK 18.0.1.1 (publicly available), 17.0.3.1 (publicly available), 11.0.15.1, 8u333, 7u343, and OpenJDK 18.0.1.1 (publicly available). As usual, let us know if you find any issues while testing your project(s) on the latest JDK early-access builds. Thanks for your support! --David - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
New JDK 19 EA builds and JCE Survey!
Greetings! The proposed schedule for JDK 19 is now known [1] with ‘Rampdown Phase One’ set for June 9th and ‘General Availability’ set for September 20th. The next several weeks will be interesting to watch as the scope of JDK 19 is revealed. You also play an important roll during these phases, which is your opportunity to share feedback . When developers such as yourself tell us of issues faced in the latest OpenJDK early-access (EA) builds, we then have a chance to fix them before that feature release reaches general availability (GA). We also enjoy when people tell us that all their tests are green! It gives us confidence ;-) So regardless of the tests color (red or green), please do not hesitate to send me a short mail as both types of feedback are useful. [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-April/006481.html ## Heads-Up: Java Cryptographic Extension Survey The Java Cryptographic Extension (JCE) has been in Java SE for a long time and has made incremental changes over the years. The OpenJDK Security Team is conducting a survey [2] to know more about how projects are using JCE and what changes, features, and API enhancements would be useful going forward. The survey is clossing on April 29 so if you have written or maintain code that uses the JCE API, please make sure to fill this short survey [2] as soon as possible. [2] https://www.questionpro.com/t/AUzP7ZrFWv ## Heads-Up: New macOS Rendering Pipeline on macOS JEP 382 [3] introduced in JDK 17 support for the new macOS Metal graphics pipeline for Swing and Java2D. JDK 19 starting build 18 is switching the default to be the new macOS Metal rendering pipeline instead of the old Apple OpenGL API. For more details please see JDK-8284378 [4]. Java applications running on macOS (10.14 or later) will not need to take any action, as they will automatically benefit from faster graphics with lower power consumption, and the use of a more modern stable graphics API which will be able to work better on current and future Apple systems. [3] https://openjdk.java.net/jeps/382 [4] https://bugs.openjdk.java.net/browse/JDK-8284378 ## JDK 19 Early-Access builds JDK 19 Early-Access builds 18 are now available [5], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [6]. [5] https://jdk.java.net/19/ [6] https://jdk.java.net/19/release-notes ### JEPs targeted to JDK 19, so far: - JEP 422: Linux/RISC-V Port https://openjdk.java.net/jeps/422 ### Recent changes that maybe of interest: Build 18: - JDK-8284378: Make Metal the default Java 2D rendering pipeline for macOS - JDK-8265315: Update CLDR to version 41 - JDK-8270090: C2: LCM may prioritize CheckCastPP nodes over projections [Reported by JaCoCo] - JDK-8284361: Updating ASM to 9.3 for JDK 19 - JDK-8284330: jcmd may not be able to find processes in the container - JDK-8284579: Improve VarHandle checks for interpreter Build 17: - JDK-8282819: Deprecate Locale class constructors - JDK-8254935: Deprecate the PSSParameterSpec(int) constructor - JDK-8283060: RawNativeLibraries should allow multiple clients to load/unload the same library Build 16: - JDK-8281561: Disable http DIGEST mechanism with MD5 and SHA-1 by default - JDK-8264160: Regex \b is not consistent with \w without UNICODE_CHARACTER_CLASS - JDK-8163327: Remove 3DES from the default enabled cipher suites list - JDK-8267319: Use larger default key sizes and algorithms based on CNSA - JDK-8283350: (tz) Update Timezone Data to 2022a ## Project Loom Updates The first Loom related JEP is now in Candidate phase, i.e. JEP: 425: Virtual Threads (Preview) [7]. As of now, JEP 425 doesn't yet 'propose to target' any particular feature release. [7] https://openjdk.java.net/jeps/425 In addition, Project Loom early-access builds 19-loom+5-429 (2022/4/4) are now available [8] with related Javadoc [9]. These builds are based on JDK 19 and are provided under the GNU General Public License, version 2, with the Classpath Exception and are produced for the purpose of gathering feedback. Use for any other purpose is at your own risk. Proper feedback should be sent to the `loom-dev` mailing list [10]. [8] https://jdk.java.net/loom/ [9] https://download.java.net/java/early_access/loom/docs/api/ [10] https://mail.openjdk.java.net/mailman/listinfo/loom-dev ## Topics of Interest: * New candidate JEP: 426: Vector API (4th Incubator) https://openjdk.java.net/jeps/426 * Virtual Thread Deep Dive - Inside Java Newscast #23 https://inside.java/2022/04/07/insidejava-newscast-023/ * Project Panama: Say Goodbye to JNI https://inside.java/2022/04/04/projectpanama/ * Java Cryptographic Extension Survey https://inside.java/2022/04/12/jce-survey/ As usual, let us know if you find any issues while testing your project(s) on the latest JDK early-access builds. Thanks for your support! --David
JDK 18 General Availability, and oracle-actions/setup-java
pet/index.html - JDK 18 - G1/Parallel/Serial GC improvements https://tschatzl.github.io/2022/03/14/jdk18-g1-parallel-gc-changes.html - “Java Language Futures: Spring 2022 Edition” (video) https://www.youtube.com/watch?v=m7Ypbw-xVRo - Project Panama : `jextract` Standalone Repository https://mail.openjdk.java.net/pipermail/panama-dev/2022-March/016632.html Again, let us know if you find any issues while testing your project(s) on the latest JDK Early Access builds. Thanks for your support! --David - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Dependency Plugin - Log4j vulnerabilities
Hey guys Let’s be courteous and civil. As part of vulnerability management, an assessment has to be made about the potential security impact of a vulnerability in software. New vulnerabilities are found every day on older components and it is not practical nor feasible to chase down every rabbit. What I read from this chain is 1. The business application is not exposed to any log4j vulnerability - that’s the most important 2. The maven build environment might (can’t confirm at this point) download a transitive dependency on log4j 1.x which has a newly found vulnerability. IMHO the impact is low. it’s a build environment, not actual business application and you surely don’t (and shouldn’t) build on your production systems. The probability of occurrence of an attack on this is probably null, knowing that attack vectors on log4j involve tricking the exposed application into logging something malicious, and a build environment does not expose logging to outside like a web app would. Based on this, I’d flag those occurrences at the scanner as assessed and ignored and move on. As a best practice, clean up your build environment after each build. Or use ephemeral containerized build environments. > On Mar 3, 2022, at 02:53, Thomas Matthijs wrote: > > That was just to demonstrate how i got the dependency chain, that file > was there, but if you're going to be this hostile, i'm not interested > anymore, muting thread > >> On Thu, 3 Mar 2022 at 08:48, Piotr Żygieło wrote: >> >>> On Thu, 3 Mar 2022 at 08:37, Thomas Matthijs wrote: >>> >>> Can confirm this project downloads log4j 1.12.12 for me >> >> As I see it - you confirm something else. >> >>> Failed to read artifact descriptor for log4j:log4j:jar:1.2.12: >> >> Failed to read artifact descriptor for log4j:log4j:jar:1.2.12: >> _artifact descriptor_ >> >> -- >> Piotrek >> >> - >> 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
JDK 18 Release Candidate builds & JDK 19 Early-Access builds
Robert, All, The Release Candidates of JDK 18 have been released [1]. At this stage, only P1 issues will be evaluated [2]. And with the JDK 18 General Availability sets for March 22nd, it is now time to shift the focus to JDK 19. I'd like to thank those of you who have already provided feedback on the early Early Builds of JDK 19. Feedback is always extremely useful, even more, when it comes early in the development cycle. [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-February/006404.html [2] https://openjdk.java.net/jeps/3 ## JDK 18 Release Candidate The Release Candidate builds of JDK 18 are now available [3], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [4]. [3] https://jdk.java.net/18/ [4] https://jdk.java.net/18/release-notes ## JDK 19 Early-Access builds JDK 19 Early-Access builds 11 are now available [5], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [6]. [5] https://jdk.java.net/19/ [6] https://jdk.java.net/19/release-notes Recent changes that maybe of interest: * JDK-8278067: Make HttpURLConnection default keep alive timeout configurable * JDK-8281000: ClassLoader::registerAsParallelCapable throws NPE if caller is null * JDK-8282279: Interpret case-insensitive string locale independently * JDK-8176706: Support CLDR's Additional (Skeleton) Date-Time Formats * JDK-5041655: (ch) FileLock: negative param and overflow issues * JDK-8255266: Update Public Suffix List to 3c213aa * JDK-8280958: G1/Parallel: Unify marking code structure * JDK-8072070: Improve interpreter stack banging * JDK-8277175: Add a parallel multiply method to BigInteger * JDK-8278947: Support for array constants in constant table * JDK-8281462: Annotation toString output for enum not reusable for source input * JDK-8281175: Add a -providerPath option to jarsigner * JDK-8277795: ldap connection timeout not honoured under contention * JDK-8279842: HTTPS Channel Binding support for Java GSS/Kerberos * JDK-8280744: Allow SuppressWarnings to be used in all declaration contexts * JDK-8272984: javadoc support for reproducible builds * JDK-8272317: jstatd has dependency on Security Manager which needs to be removed ## New Project Loom Early-Access builds Project Loom Early-Access builds19-loom+4-115 (2022/2/13) are available [7] with the related Javadoc [8]. These EA builds are based on JDK 19 (jdk-19+9). In those builds, the APIs for Structured Concurrency and Scope Locals have been moved into the `jdk.incubator.concurrent` incubator module. Note that the module name may change later. To use those APIs, simply use `--add-modules jdk.incubator.concurrent` at compile and runtime. Those EA builds are provided under the GNU General Public License, version 2, with the Classpath Exception and are produced for the purpose of gathering feedback. Use for any other purpose is at your own risk. Proper feedback should be sent to the `loom-dev` mailing list [9]. [7] https://jdk.java.net/loom/ [8] https://download.java.net/java/early_access/loom/docs/api/ [9] https://mail.openjdk.java.net/mailman/listinfo/loom-dev ## Topics of Interest * JDK 18 - Card Table Card Size Shenanigans https://tschatzl.github.io/2022/02/15/card-table-card-size.html * Compiled & Tested Code In Javadoc - Inside Java Newscast #20 https://inside.java/2022/02/10/insidejava-newscast-020/ * New candidate JEP: 423: Region Pinning for G1 https://mail.openjdk.java.net/pipermail/jdk-dev/2022-February/006368.html * Refactoring Java 8 code with Java 17 new features - JEP Café #9 https://inside.java/2022/02/01/jepcafe9/ As always, let us know if you find any issues while testing your projects on the latest JDK Early Access builds. Thanks for your support! --David - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Dependency Plugin - Log4j vulnerabilities
Where I work we decided to address log4j vulnerabilities only for components directly used by the application and actually performing logging. We ignored transitive dependencies and maven plug-ins. I’m curious about this use case from Venu though, what application would rely on the maven dependency plugin at runtime? Does it mean you’re pulling maven dependencies after application startup? > On Feb 28, 2022, at 03:30, Slawomir Jaranowski wrote: > > Hi, > > Please provide more information, like plugin, mven, os version. > > We also need an example project which reproduces your issue. > When we can't reproduce we can't help. > > pon., 28 lut 2022 o 08:55 Jaladi, Venumadhav > napisał(a): > >> Hi team, >> >> Can I expect any response? Is this the right email address for my >> question? >> >> Thanks, >> Venu >> >> >>> On Thu, Feb 24, 2022 at 6:47 AM Jaladi, Venumadhav < >>> jaladi.venumad...@verizon.com> wrote: >>> >>> Hi team, >>> >>> We are using the Maven Dependency Plugin in one of our projects and our >>> scanning tools are showing multiple vulnerabilities related to Log4j >>> (CVE-2019-17571, CVE-2020-9488, CVE-2022-23302, CVE-2022-23305, >>> CVE-2022-23307 and CVE-2021-4104). >>> >>> We would like to know if there are any plans to release a newer version >>> of Maven Dependency Plugin with the fixes of these >>> vulnerabilities(referring to the latest version of Log4j libraries). If >>> so, is there any planned date for this release? >>> >>> Please let us know any any more information is required. >>> >>> Thanks, >>> Venu >>> >> > > > -- > Sławomir Jaranowski - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
JDK 18 Rampdown Phase 2 & JDK 19 Early-Access Builds
builds (including jextract) jdk 18 https://mail.openjdk.java.net/pipermail/panama-dev/2022-January/016131.html - January 2022 Critical Patch Update Released As part of the Jan 2022 Critical Patch Update we released JDK 17.0.2 LTS, JDK 11.0.14 LTS, JDK 8u321, and JDK 7u331 as well as OpenJDK 17.0.2 (publicly available). https://www.oracle.com/security-alerts/cpujan2022.html In closing, I'd like to thank you again for being a welcomed part of the Quality Outreach program! We look forward to your continued participation in 2022. And as always, if you find an issue, please let us know through the usual channels. Regards, --David - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
JDK 18: Rampdown Phase 1 & Early-Access builds 27
Robert, Thank you for being part of the OpenJDK Quality Outreach Program. As year-end 2021 approaches, I'd like to share some updates on JDK 18, which is scheduled for General Availability on March 22, 2022. JDK 18 has now entered Rampdown Phase One (RDP1) [1], which means that the main-line has been forked into a dedicated JDK 18 stabilization repository. At this point, the overall JDK 18 feature set is now frozen and no additional JEPs will be targeted to JDK 18. Only low-risk enhancements that add small bits of missing functionality or improve usability might still be considered. The next few weeks should be leveraged to try to identify and resolve as many issues as possible (i.e. before JDK 18 enters the Release Candidates phase). And as you can see below, JDK 18 EA Builds 26 & 27 include fixes for issues that were reported by you! So thank you for your help contributing to the overall quality of OpenJDK! [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-December/006287.html ## JEP 400 - UTF-8 by Default All JEPs are now integrated, but we would like to draw your attention to JEP 400 especially if you are deploying on Windows as it might induce some incompatible behavior on that platform. JEP 400 [2] is changing the default charset to UTF-8. This aligns with the existing `newBufferedReader`/`Writer` methods of the `java.nio.file.Files` class where UTF-8 is the default when no explicit charset is set. By making UTF-8 the default charset, the JDK I/O APIs will now always work in the same, predictable manner, with no need to pay attention to the host and or user’s environment! Further, we encourage you to test your project(s) with the latest JDK 18 Early Access builds. We don't expect issues on macOS and Linux as their default encoding is already UTF-8. On Windows, especially for East Asian locales such as Chinese/Japanese/Korean, some incompatible behavior could be anticipated. If that’s the case, please consider a mitigation strategy [3]. [2] https://openjdk.java.net/jeps/400 [3] https://inside.java/2021/10/04/the-default-charset-jep400/ ## JDK 18 JDK 18 Early-Access builds 27 are now available [4], and are provided under the GNU General Public License v2, with the Classpath Exception. Make sure to check the Release Notes [5]. As usual, we encourage you to test your project(s) using those EA builds and provide us feedback. [4] https://jdk.java.net/18/ [5] https://jdk.java.net/18/release-notes ### JEPs integrated to JDK 18: - JEP 400: UTF-8 by Default - JEP 408: Simple Web Server - JEP 413: Code Snippets in Java API Documentation - JEP 416: Reimplement Core Reflection with Method Handles - JEP 417: Vector API (Third Incubator) - JEP 418: Internet-Address Resolution SPI - JEP 419: Foreign Function & Memory API (Second Incubator) - JEP 420: Pattern Matching for switch (Second Preview) - JEP 421: Deprecate Finalization for Removal ### Changes in recent builds that maybe of interest: Build 27: - JDK-8266435: WBMPImageReader.read() should not truncate the input stream [Reported by PDFBox] - JDK-8278078: Cannot reference super before supertype constructor has been called - JDK-8177819: DateTimeFormatterBuilder zone parsing should recognise DST - JDK-8277965: Enclosing instance optimization affects serialization - JDK-8275821: Optimize random number generators developed in JDK-8248862 using Math.unsignedMultiplyHigh() - JDK-8225181: KeyStore should have a getAttributes method - JDK-8275082: Update XML Security for Java to 2.3.0 - JDK-8278270: ServerSocket is not thread safe - JDK-8277863: Deprecate sun.misc.Unsafe methods that return offsets Build 26: - JDK-8277451: j.l.r.Field::set on static field with invalid argument type should throw IAE [Reported by Hibernate & ByteBuddy] - JDK-8258117: jar tool sets the time stamp of module-info.class entries to the current time [Reported by Apache Maven] - JDK-8268743: Require a better way for copying data between MemorySegments and on-heap arrays [Reported by Apache Lucene] - JDK-8277986: Typo in javadoc of java.util.zip.ZipEntry#setTime [Reported by Apache Ant] - JDK-8277861: Terminally deprecate Thread.stop - JDK-8276665: ObjectInputStream.GetField.get(name, object) should throw ClassNotFoundException - JDK-8271623: Omit enclosing instance fields from inner classes that don't use it - JDK-8231107: Allow store password to be null when saving a PKCS12 KeyStore - JDK-8193682: Infinite loop in ZipOutputStream.close() - JDK-8277459: Add `jwebserver` tool [see Topics of Interest] Build 25: - JDK-8259643: ZGC can return metaspace OOM prematurely - JDK-8277212: GC accidentally cleans valid megamorphic vtable inline caches - JDK-8276970: Default charset for PrintWriter that wraps PrintStream - JDK-8272773: Configurable card table card size - JDK-4337793: Mark non-serializable fields of java.security.cert.Certificate and CertPath Build 24: - JDK-8275056: Allow G1 heap regions
JDK 18 Early-Access builds 23 are available
Java Newscast, https://youtu.be/eDgBnjOid-g Thank you for being a welcomed part of the Quality Outreach program! -- David Delabassée / @delabassee - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Maven dependency plugin release?
Is there a release of the Maven dependency plugin scheduled? I am very excited about the return of verbose with https://issues.apache.org/jira/browse/MDEP-644, and I'm sure I'm not the only one. Thanks! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: APT vs Markdown formats for site docs
I looked for a few minutes at https://github.com/apache/logging-log4j2 and found 3 or 4 markdown pages under site that didn’t appear to have anything that would be hard to write in AsciiDoc. The root level pages such as README.md, if written in (limited) AsciiDoc, will display nicely at GitHub. David Jencks > On Feb 1, 2021, at 7:24 AM, Ralph Goers wrote: > > Log4j didn’t switch everything. A couple pages had to be left as Markdown for > things AsciiDoc doesn’t support, although at the moment I don’t remember what > those things were at the moment. > > Ralph > >> On Feb 1, 2021, at 6:30 AM, Gary Gregory wrote: >> >> FYI, over at Log4j, we switched to Asciidoc. >> >> Gary >> >> On Mon, Feb 1, 2021, 05:19 Artem Krosheninnikov < >> artem.krosheninni...@gmail.com> wrote: >> >>> Hello there, whilst looking at some docs in maven-enforcer-plugin, I found >>> .apt.vm format not very convenient and developer-friendly, especially for a >>> newcomer. >>> >>> Is it a standard for all maven plugins or were there any discussions on >>> using another format? I see that maven-parent-34 has several modules for >>> other formats like markdown or fml. >>> -- >>> Sincerely yours, >>> Krosheninnikov Artem. >>> > > > > - > 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
Re: APT vs Markdown formats for site docs
Asciidoctor Maven Tools is the more supported way of using Asciidoctor from maven, either directly or through Doxia. https://docs.asciidoctor.org/maven-tools/latest/ <https://docs.asciidoctor.org/maven-tools/latest/> (docs) https://github.com/asciidoctor/asciidoctor-maven-plugin <https://github.com/asciidoctor/asciidoctor-maven-plugin> (GitHub) AsciiDoc support in Jekyll using jekyll-asciidoc is quite good, and GitHub is rather jekyll-friendly. You do have to build the site yourself, GitHub’s built in AsciiDoc rendering is somewhat crippled for incomprehensible reasons. I’m now the primary maintainer of jekyll-asciidoc so issues may receive prompt attention. I think Antora is incomparable, and would certainly produce fabulous results properly used for maven documentation, but with the investment in Doxia organization that may be a better choice. David Jencks > On Feb 1, 2021, at 3:34 AM, Andres Almiray wrote: > > FWIW Doxia supports Asciidoc pretty well. You just have to add an extra > dependency for it to find Asciidoctorj, as demonstrated at > > https://github.com/kordamp/pomchecker/blob/master/pom.xml#L200-L227 > > You can mix all kind of supported formats if needed. Or use only asciidoc, > the choice is yours ;-) > > Cheers, > Andres > > --- > Java Champion; Groovy Enthusiast > http://andresalmiray.com > http://www.linkedin.com/in/aalmiray > -- > What goes up, must come down. Ask any system administrator. > There are 10 types of people in the world: Those who understand binary, and > those who don't. > To understand recursion, we must first understand recursion. > > > On Mon, Feb 1, 2021 at 12:29 PM Artem Krosheninnikov < > artem.krosheninni...@gmail.com> wrote: > >> I agree that there are several implementations thus it may be not a good >> choice. >> >> FML looks very ancient from my point of view but asciidoc is more or less a >> standard format in docops community. >> >> It's not that everything should be immediately converted to another format, >> just trying to understand whether apt is convenient for all and is a >> standard for all maven projects. >> >> пн, 1 февр. 2021 г. в 13:32, Benjamin Marwell : >> >>> Markdown is not a "standard" or "standardized". >>> Even worse, different implementations have different feature sets. >>> Thus my -1 for md. >>> >>> But another format might be feasible, really. fml looks verbose. >>> >>> Asciidoc might be a sane choice here. It was specially designed for >>> technical documentation and >>> has neat features which are handy for exactly those cases. >>> Besides, it is also supported on GitHub. >>> >>> --- >>> >>> A quick check revealed there was no such discussion in the last 12 >>> months on the mailing list. >>> >>> - Ben >>> >>> >> >> -- >> Sincerely yours, >> Krosheninnikov Artem. >>
Re: How does maven-site publishing work?
I strongly recommend using the most up to date infra site support which involves a git repo with an asf.yaml file indicating that it’s your website. Push to the git repo and as if by magic your website appears. See https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features I’m also strongly in favor of using asciidoc rather than markdown and using Antora, however that’s a separate issue. Completely off topic for this thread, but…. how hard would it be for the maven site plugin to generate asciidoc? David Jencks > On Oct 19, 2020, at 11:38 AM, Michael Osipov wrote: > > Folks, > > we at the HttpComponents TLP we'd like use the same approach as maven-site > does. We'd ilke to automatate as much as possible, means: push to repo should > trigger a a push to the website. I can see that svnpubub is obviously used in > the POM. But the question is, where is the trigger performing the actual > step? Who knows best? > > See discussion [1] > > Thanks, > > Michael > > [1] https://www.mail-archive.com/dev@hc.apache.org/msg27650.html > > - > 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
Re: Merging via GitHub
As a side note, I’m personally in favor of the author squashing manually and the “merge” into master using rebase-and-commit. To your main issue, I’m pretty sure that GitHub doesn’t keep any secret information, instead you are using an insufficiently verbose log command. Try git log --pretty=fuller By default git log just shows the author, and you are looking for the committer (person who merged in the commit). See git-log <https://git-scm.com/docs/git-log#_pretty_formats> david jencks > On May 16, 2020, at 4:53 PM, Olivier Lamy wrote: > > I wonder what is exactly the problem here? (except a noisy commit but who > cares really compared to the useless noise email notifications when someone > rebase a branch) > But at least there are real person name. > That's weird because I just used the "Squash and merge' for this PR ( > https://github.com/apache/maven-shared-utils/pull/30) and got nice commit > https://github.com/apache/maven-shared-utils/commit/32942621ff5df2f8779e0f55276c902a1fcb42b9 > Elliotte Maybe something with your GH configuration? > > I have definitely more concerns with this one > https://github.com/apache/maven-shared-utils/commit/bb2f85e98c3c651ae50b7f642500cb74f50abb0d > > some github UI features show it as `dependabot-preview authored and > slachiewicz committed` > But looking at log with a real git tool call 'git' :) I get > > > commit bb2f85e98c3c651ae50b7f642500cb74f50abb0d > Author: dependabot-preview[bot] <27856297+dependabot-preview[bot]@ > users.noreply.github.com> > Date: Mon Mar 9 04:19:41 2020 + >Bump hamcrest-core from 1.3 to 2.2 > Bumps [hamcrest-core](https://github.com/hamcrest/JavaHamcrest) from 1.3 to > 2.2. > - [Release notes](https://github.com/hamcrest/JavaHamcrest/releases) > - [Changelog]( > https://github.com/hamcrest/JavaHamcrest/blob/master/CHANGES.md) > - [Commits]( > https://github.com/hamcrest/JavaHamcrest/compare/hamcrest-java-1.3...v2.2) > > Signed-off-by: dependabot-preview[bot] > > And this is totally wrong! we must have a real person name in the commit > logs (and github UI is not the real commit logs). > not sure how to fix that
Re: Merging via GitHub
It's possible to configure GitHub to allow rebase and merge, which I think is what you want. It may be possible to configure GitHub to only allow this. I’m not sure if this is something infra has to do or if a project admin can set it up. Camel recently made a related change. David Jencks > On May 11, 2020, at 3:23 PM, Benson Margulies wrote: > > Could you send me a pointer to refresh my memory on procedures? It's been a > while ... > > On Mon, May 11, 2020 at 1:42 PM Michael Osipov wrote: > >> Folks, >> >> please do NOT merge via merge button in GitHub: >> >>> commit 158f54e3abc5c1d602146a08902482b6a19e2c27 (origin/master, >> origin/HEAD) >>> Merge: 34253e3d f7de3a6e >>> Author: Elliotte Rusty Harold >>> Commit: GitHub >>> >>>Merge pull request #66 from apache/plex >>> >>>[SCM-930] update plexus-utils >>> >>> commit f7de3a6ea5e182d7fab28e8f0548da2324097ba9 >>> Author: Elliotte Rusty Harold >>> Commit: Elliotte Rusty Harold >>> >>>update plexus-utils >> >> 1. It produces useless merge commits >> 2. GitHub is NOT a blessed committer >> >> It is OK, wenn a clean rebased merge is performed and not traces of >> GitHub are left. >> >> 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
Re: Update versions of all plugins in default-bindings.xml
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 pom:...” If someone is maintaining plug-in versions manually is there a tool to point out all the upgrade possibilities? Thanks David Jencks Sent from my iPhone > On Jan 12, 2019, at 7:39 PM, Hervé BOUTEMY wrote: > > 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 injected by default lifecycle > bindings > > Just test for yourself following pom.xml from any beginner: > >4.0.0 >com.mycompany.app >my-app >1.0-SNAPSHOT > > > it works = what we expect to ease newcomers experience > but there is no warning... > > IMHO, this is where we need to improve the tool, by adding a warning: > I worked on a PoC of DefaultLifecycleBindingsInjector improvement that > displays: > [WARNING] > [WARNING] Some problems were encountered while building the effective model > for com.mycompany.app:my-app:jar:1.0-SNAPSHOT > [WARNING] Using default plugins versions from bindings: > [org.apache.maven.plugins:maven-clean-plugin, > org.apache.maven.plugins:maven-install-plugin, > org.apache.maven.plugins:maven-resources-plugin, > org.apache.maven.plugins:maven-surefire-plugin, > org.apache.maven.plugins:maven-compiler-plugin, > org.apache.maven.plugins:maven-jar-plugin, > org.apache.maven.plugins:maven-deploy-plugin, > org.apache.maven.plugins:maven-site-plugin] > [WARNING] > [WARNING] It is highly recommended to fix these problems because they > threaten the stability of your build. > [WARNING] > [WARNING] For this reason, future Maven versions might no longer support > building such malformed projects. > [WARNING] > > With this warning, and a parent pom to have an easy fix (instead of 8 plugins > versions definition), IMHO, we have what we strongly need. > > And even better, with this warning in place to avoid people to continue to > rely on default plugins versions (because of the nasty warning), I could find > upgrading default plugins versions not an issue any more!!! > > Should we try to go this route? > > Regards, > > Hervé > > Le dimanche 13 janvier 2019, 00:15:38 CET Stephen Connolly a écrit : >> 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 2019 at 21:34, Tibor Digana wrote: >>> 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 same compatibility with default plugins because people do >>> not see these plugins as a distinct community. They are both Maven and >>> plugins from us Apache, so they most probably would expect it consistent >>> altogether. >>> Makes sense? >>> >>> On Sat, Jan 12, 2019 at 7:24 PM Bernd Eckenfels >>> >>> wrote: >>>> 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 >>>> wrappers). >>>> >>>> So this means: keep old standard versions and overwrite them always in >>>> poms. (And it means the amount of default versions should be reduced or >>> >>> at >>> >>>> least not add new ones) >>>> >>>> Gruss >>>> Bernd >>>> -- >>>> http://bernd.eckenfels.net >>>> >>>> >>>> Von: Robert Scholte >>>> Gesendet: Samstag, Januar 12,
Re: Formal verification of thread correctness in maven core
I wonder that too. I don't think cglib is maintained, AFAIK most people use asm nowadays. I believe it is fairly easy to use asm to add byte code to the beginning and end of every method for e.g. logging method entry/exit. Apache Aries has an asm based thing to enable adding some kind of before/after logic (this is designed for osgi weaving hooks). With this approach you would not need subclasses. david jencks On Jan 5, 2015, at 9:51 AM, Igor Fedorenko i...@ifedorenko.com wrote: What kind of changes to the model do you expect? Can you give some pointers that explain verification logic you have in mind? -- Regards, Igor On 2015-01-05 9:11, Kristian Rosenvold wrote: I'd be interested in using cglib to generate a full set of subclasses for the entire maven model. These subclasses could assert stuff about proper thread correctness wrt the current correct threading model for maven. This would be capable of blowing up /immediately/ a plugin violates the contract and could be used to make a formal verficiation that the entire set of plugins performs to specification in a given build. I could potentially see this added as a diagnostic mode to core. I know how to create the verification logic, but I am totally blank when it comes to cglib. Is there anyone who can help me a bit ? Maybe even someone who could code the actual cglib bit :) ? Kristian - 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
Re: [VOTE] Name our mascot: Shotgun vs The Maven Owl
B david jencks On Dec 15, 2014, at 5:39 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: After the run-off round, we are left with two names standing. This second vote will be a straight and simple majority wins. The vote will be open for at least 72 hours (with the potential of an extension until I send a message saying that the polls are closed) There will be no discussion in this thread, we have talked it all enough already. If you want to discuss something, please use a different thread. Vote: [A]: Shotgun [B]: The Maven Owl Thank you very much for your time -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Ticket Transition Workflow: Abandoned issues
Retired rather than Archived? This cleanup seems like a really good idea :-) david jencks On Nov 26, 2014, at 12:41 PM, Paul Benedict pbened...@apache.org wrote: My 2-cents on the word Archived is that it's a synonym for Backup/Storage, which I don't think is what this process is about. Cheers, Paul On Wed, Nov 26, 2014 at 1:57 PM, Michael Osipov micha...@apache.org wrote: Am 2014-11-26 um 16:16 schrieb Paul Benedict: This email is related to thread Abandoned bug analysis [1]. We have done the Great Ticket Cleanup of 2014 twice this year. It has really been productive for anyone who triages outstanding bugs and enhancements. We've been adding a note in the ticket, as a courtesy to the participants, and closing them as Won't Fix. This is certainly one valid way of accomplishing the goal. However, I do believe we should enhance our workflow by adding an Abandoned (my fav) or Archived resolution. Why? Because Won't Fix is typically is used to close out a bug that will never be fixed (i.e., too many people rely on the bad behavior) or the enhancement is deemed worthless or incorrect. But more importantly, it's not possible to do a JIRA search and distinguish between these two conditions unless a new resolution is introduced. We need two new things: 1. Status: Awaiting Feedback (not just labels). 2. Resolution: Archived 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
Re: Ticket Transition Workflow: Abandoned issues
In my work life use of RTC Backlog means needs to be investigated by a developer. I think Cancelled as Incomplete might be a closer RTC match to the meaning we are looking for here. david jencks On Nov 26, 2014, at 2:14 PM, Chris Graham chrisgw...@gmail.com wrote: RTC uses Backlog. Does Jira have something similar? Sent from my iPhone On 27/11/2014, at 8:13 AM, David Jencks david_jen...@yahoo.com.INVALID wrote: Retired rather than Archived? This cleanup seems like a really good idea :-) david jencks On Nov 26, 2014, at 12:41 PM, Paul Benedict pbened...@apache.org wrote: My 2-cents on the word Archived is that it's a synonym for Backup/Storage, which I don't think is what this process is about. Cheers, Paul On Wed, Nov 26, 2014 at 1:57 PM, Michael Osipov micha...@apache.org wrote: Am 2014-11-26 um 16:16 schrieb Paul Benedict: This email is related to thread Abandoned bug analysis [1]. We have done the Great Ticket Cleanup of 2014 twice this year. It has really been productive for anyone who triages outstanding bugs and enhancements. We've been adding a note in the ticket, as a courtesy to the participants, and closing them as Won't Fix. This is certainly one valid way of accomplishing the goal. However, I do believe we should enhance our workflow by adding an Abandoned (my fav) or Archived resolution. Why? Because Won't Fix is typically is used to close out a bug that will never be fixed (i.e., too many people rely on the bad behavior) or the enhancement is deemed worthless or incorrect. But more importantly, it's not possible to do a JIRA search and distinguish between these two conditions unless a new resolution is introduced. We need two new things: 1. Status: Awaiting Feedback (not just labels). 2. Resolution: Archived 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
Re: [jira] (SCM-775) Request for new optional parameter RTC (workItem) with release:prepare to associate workitem with changesets got created during build process
Sorry for the reply on list, my codehaus jira credentials seem to have gotten
messed up….
I would expect the best normal workflow would be to have the release plugin
create the work item, then attach the change sets to it. I have some evidence
that it is possible for external programs to do stuff like this, but I have no
idea how.
david jencks
On Sep 10, 2014, at 8:51 AM, AShit Shah (JIRA) j...@codehaus.org wrote:
[
https://jira.codehaus.org/browse/SCM-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=352607#comment-352607
]
AShit Shah commented on SCM-775:
Both options are fine.
I think ANT have it via build.xml. I personally would prefer to have it via a
-D option at command line and not hard-coded in pom.xml.
I was thinking of creating one release build WI for every agile sprint. Not
sue if this is right approach though.
Request for new optional parameter RTC (workItem) with release:prepare to
associate workitem with changesets got created during build process
-
Key: SCM-775
URL: https://jira.codehaus.org/browse/SCM-775
Project: Maven SCM
Issue Type: Improvement
Components: maven-scm-provider-jazz
Affects Versions: 1.9.1
Reporter: AShit Shah
Maven {{release:prepare}} command is failing with below error while
delivering updated pom.xml to the stream due to Preconditions configured in
RTC to have comments and associated work item with every delivery.
[ERROR] Name: Deliver
[ERROR] Participant Reports:
[ERROR] Name: Require Work items and Comments
[ERROR] A work item must be associated with the change set.`
[ERROR] At least one of the associated work items must specify that the work
is planned for the current iteration.
[ERROR] At least one of the associated work items must be assigned to you.
[ERROR] Problem running 'deliver':
[ERROR] 'Deliver' failed. Preconditions have not been met: A work item must
be associated with the change set.
[ERROR] - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-release-plugin:2.5:prepare (default-cli)
on project junit-ext: Unable to commit files
Provider message:
Error code for Jazz SCM deliver command - 17
I can not find any optional parameters on
http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html
for release:prepare command which I can use and pass the RTC workitem number
on command line.
Suggestion:
It will be great if you can provide optional parameters like workItem
which I can use and pass RTC workitem number with release:prepare at command
line.
Example: mvn -PmyProfile release:prepare -DworkItem=123456
So build process should associate change sets created by release:prepare
with work item 123456 and deliver change sets to the stream.
As of now I have to use -DpushChanges=false parameter to block delivery
process and I have to manually find the change sets, associate them with
work item and deliver them before I run release:perform.
Thanks.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
MNG-5511 - Can't override a profile setting in a plugin's dependency
Hi, This is preventing us from running code coverage on our macs... Can anyone confirm whether this is a bug or whether I am missing something? cheers, David
Release enforcer plugin?
Hi. Would anybody care to release the enforcer 1.3.1 plugin so we can go around http://jira.codehaus.org/browse/MENFORCER-156? All issues for 1.3.1 are fixed: http://jira.codehaus.org/browse/MENFORCER/fixforversion/19426#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel -- -- David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
Re: running maven programmatically, the DefaultRemoteRepositoryManager.connectorFactories is empty
it works after adding these two dependencies, thanks! :)
but it seems to me that there is something wrong with this dependency
injection mechanism.
it would be fantastic to have something that fails at compile time (as the
implicit in the scala language), but if that's not the case,
at least to throw an injection exception during runtime...
why there is not even an injection exception?
regards,
David
On Mon, Apr 29, 2013 at 11:19 PM, Stuart McCulloch mccu...@gmail.comwrote:
IIRC you need to also add dependencies to aether-connector-wagon and
wagon-http...
http://stackoverflow.com/questions/4206679/can-anyone-give-a-good-example-of-using-org-apache-maven-cli-mavencli-programatt/6255514#6255514
--
Cheers, Stuart
On 29 April 2013 21:22, David Portabella david.portabe...@gmail.com
wrote:
I have a very simple project that starts maven programmatically, as
follows:
import org.apache.maven.cli.MavenCli;
public class Example {
public static void main(String[] args) throws Exception {
new MavenCli().doMain(new String[]{clean, install},
/test/a_maven_project, null, null);
}
}
which uses only these two dependencies:
dependency
groupIdorg.apache.maven/groupId
artifactIdmaven-embedder/artifactId
version3.0.5/version
/dependency
dependency
groupIdorg.codehaus.plexus/groupId
artifactIdplexus-utils/artifactId
version3.0.10/version
/dependency
The program initializes maven with plexus, and every seems to work,
*but the execution fails if some dependencies of the
/test/a_maven_project maven project are not in the local repository.*
(all using default configurations (no custom settings.xml file))
What can be the problem?
I debugged building the /test/a_maven_project project in two ways:
1- Running my Example project (it fails)
2- Running mvnDebug clean install from the command line and debugging
remotely (it works)
The difference is that in the second case,
DefaultRemoteRepositoryManager.connectorFactories has an instance of a
WagonRepositoryConnectorFactory,
while in the first
case DefaultRemoteRepositoryManager.connectorFactories is empty.
aether-impl-1.13.1-sources.jar!/org/sonatype/aether/impl/internal/DefaultRemoteRepositoryManager.java
aether-connector-wagon/1.13.1/aether-connector-wagon-1.13.1.jar!/org/sonatype/aether/connector/wagon/WagonRepositoryConnectorFactory.class
Any idea of why in the first case the
DefaultRemoteRepositoryManager.connectorFactories is empty?
how to modify the Example to make it work?
Regards,
David Portabella
ConfigurationContainer.getConfiguration returns Object. Is it always a Xpp3Dom instance?
the documentation for org.apache.maven.model.ConfigurationContainer.getConfiguration() says Get the configuration as DOM object, however it returns an Object. how to handle this? is it always an instance of org.codehaus.plexus.util.xml.Xpp3Dom? Regards, David
the property ${project.artifact.selectedVersion.majorVersion} does not get resolved after projectBuilder.build()?
When calling to this function,
ListProjectBuildingResult projectBuildingResults =
projectBuilder.build(Arrays.asList(new File(pomFile)), true,
projectBuildingRequest);
all the properties used in the pom file, such as ${spring.version} in here,
get resolved successfully.
dependency
groupIdorg.springframework/groupId
artifactIdspring-web/artifactId
version${spring.version}/version
/dependency
however, the property ${project.artifact.selectedVersion.majorVersion} does
not get resolved after the call to projectBuilder.build().
why is that?
how to get this resolved?
Regards,
David
running maven programmatically, the DefaultRemoteRepositoryManager.connectorFactories is empty
I have a very simple project that starts maven programmatically, as follows:
import org.apache.maven.cli.MavenCli;
public class Example {
public static void main(String[] args) throws Exception {
new MavenCli().doMain(new String[]{clean, install},
/test/a_maven_project, null, null);
}
}
which uses only these two dependencies:
dependency
groupIdorg.apache.maven/groupId
artifactIdmaven-embedder/artifactId
version3.0.5/version
/dependency
dependency
groupIdorg.codehaus.plexus/groupId
artifactIdplexus-utils/artifactId
version3.0.10/version
/dependency
The program initializes maven with plexus, and every seems to work,
*but the execution fails if some dependencies of the
/test/a_maven_project maven project are not in the local repository.*
(all using default configurations (no custom settings.xml file))
What can be the problem?
I debugged building the /test/a_maven_project project in two ways:
1- Running my Example project (it fails)
2- Running mvnDebug clean install from the command line and debugging
remotely (it works)
The difference is that in the second case,
DefaultRemoteRepositoryManager.connectorFactories has an instance of a
WagonRepositoryConnectorFactory,
while in the first
case DefaultRemoteRepositoryManager.connectorFactories is empty.
aether-impl-1.13.1-sources.jar!/org/sonatype/aether/impl/internal/DefaultRemoteRepositoryManager.java
aether-connector-wagon/1.13.1/aether-connector-wagon-1.13.1.jar!/org/sonatype/aether/connector/wagon/WagonRepositoryConnectorFactory.class
Any idea of why in the first case the
DefaultRemoteRepositoryManager.connectorFactories is empty?
how to modify the Example to make it work?
Regards,
David Portabella
debug mvn clean install from IntelliJ
I am trying to debug maven from my IDE (IntelliJ). To do so, I run from IntelliJ with this configuration: Main class: org.codehaus.plexus.classworlds.launcher.Launcher VM options: -Dclassworlds.conf=/Users/david/nespresso/david/code_analysis/maven/apache-maven-3.0.5/apache-maven/src/bin/m2.conf -Dmaven.home=/Users/david/nespresso/david/code_analysis/maven/apache-maven-3.0.5/apache-maven/src/ Program arguments: clean install Working directory: /test/my_example_maven_project --- but I get the following: [ERROR] Error executing Maven. [ERROR] java.util.NoSuchElementException role: org.apache.maven.eventspy.internal.EventSpyDispatcher roleHint: [ERROR] Caused by: null --- What am I missing? How can I run/debug a mvn clean install from IntelliJ? Regards, David --- David Portabella - Senior IT Architect AlmaZ Informatique SA - www.almazsa.com david.portabe...@almazsa.com +41 78 802 6411
Re: RFP: Version Range Policy
Can you explain how you think osgi semantic versioning can reasonably be applied to non-osgi-bundles? It typically takes a project a year or two to figure out what semantic versioning means when converting a project to osgi, I think you would find that trying to apply semantic versioning to non-osgi projects will mean that every update is a major version change. It would be nice if all projects converted to osgi and used semantic versioning correctly, but I don't think that is going to happen any time soon and I don't think the majority of maven projects will be osgi any time soon. thanks david jencks On Apr 10, 2013, at 10:27 AM, Andrei Pozolotin andrei.pozolo...@gmail.com wrote: *Maven Developers* 1) This is a formal request to resolve long standing version range policy problem in maven, expressed for example in the following ticket: http://jira.codehaus.org/browse/MNG-3092 THE PROBLEM: LACK OF VERSION RANGE POLICY. 2) I there are no better ideas, I suggest Maven to adopt OSGI Semantic Version Guidelines. https://github.com/barchart/barchart-version-tester/wiki/Version-Policy 3) I have working prototype based on maven 3.0.4 with back port of aether 0.9.0.M2 specifically applied to karaf use case, which could be generalized. https://github.com/barchart/barchart-maven-karaf-plugin 4) there is an Aries version check plugin, that shows generic java binary compatibility checks which should be part of the new maven semantic version contract. https://github.com/apache/aries/tree/trunk/versioning Thank you, Andrei - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RFP: Version Range Policy
so you are basically saying all packages are exported. I think you will find that few meaningful code changes will result in a non-major-version change whether or not the intended api changes. Have you tried this out with some real non-osgi projects to see what versions you'd come up with and whether they correspond in any way with what the project developers think the versions are? thanks david jencks On Apr 10, 2013, at 3:23 PM, Andrei Pozolotin andrei.pozolo...@gmail.com wrote: I am more optimistic then you. here is the idea https://github.com/barchart/barchart-version-tester/wiki/Maven-OSGI Original Message Subject: Re: RFP: Version Range Policy From: David Jencks david_jen...@yahoo.com To: Maven Developers List dev@maven.apache.org Date: Wed 10 Apr 2013 12:44:19 PM CDT Can you explain how you think osgi semantic versioning can reasonably be applied to non-osgi-bundles? It typically takes a project a year or two to figure out what semantic versioning means when converting a project to osgi, I think you would find that trying to apply semantic versioning to non-osgi projects will mean that every update is a major version change. It would be nice if all projects converted to osgi and used semantic versioning correctly, but I don't think that is going to happen any time soon and I don't think the majority of maven projects will be osgi any time soon. thanks david jencks On Apr 10, 2013, at 10:27 AM, Andrei Pozolotin andrei.pozolo...@gmail.com wrote: *Maven Developers* 1) This is a formal request to resolve long standing version range policy problem in maven, expressed for example in the following ticket: http://jira.codehaus.org/browse/MNG-3092 THE PROBLEM: LACK OF VERSION RANGE POLICY. 2) I there are no better ideas, I suggest Maven to adopt OSGI Semantic Version Guidelines. https://github.com/barchart/barchart-version-tester/wiki/Version-Policy 3) I have working prototype based on maven 3.0.4 with back port of aether 0.9.0.M2 specifically applied to karaf use case, which could be generalized. https://github.com/barchart/barchart-maven-karaf-plugin 4) there is an Aries version check plugin, that shows generic java binary compatibility checks which should be part of the new maven semantic version contract. https://github.com/apache/aries/tree/trunk/versioning Thank you, Andrei - 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
Maven2 updates in a closed area
Greetings, I support a team of Java professionals working in a closed area. Up until a few months ago I had supplied them with a frequently updated distribution of Maven2 artifacts. I did this while connected to the internet using rsync of Maven2 to a hard drive that contained my previously obtained rsync'd repository. This ensured that only updates of Maven2 be retrieved since the last time the repository had updated. Having a complete updated Maven2 repository is a requirement of our team of professionals working in a closed area. However since Maven2 no longer supports rsync, I need to find another way to satisfy this requirement. I know that repository management tools exist. In fact we are using Apache Archiva in an open area for another team of Java developers. New versions of Jars are added to POM files and Archiva goes out and downloads the specific JAR an its dependencies. Since we work in a closed area, is there a repository management tool capable of automatically updating my local Maven2 repository without looking in a modified POM? We would like the management tool to go out every 6 to 8 weeks ensuring Maven2 updates to be minimum. Thank you, David
Re: the simplest possible maven plugin, sort of
Our experience in geronimo has always been that maven does not support this, and I thought for maven 3 it was announced that it never ever would. We have a proflie to build up through the plugin, then you can do the full build. Releasing is a pain as you have to do the manual profile build with the release-version code to get the plugin available in the local maven repo before running the actual release. If I'm wrong for any version of maven I'd love to know how :-) thanks david jencks On Sep 10, 2012, at 1:45 PM, Daniel Kulp wrote: Interesting… I wonder how I've managed to do CXF releases for all these years then. :-) Seriously, for CXF =2.5.x, I use Maven 2.2.1 and it just works. Parts of the build certainly do use the plugins that are built as part of the reactor. That said, we use install as the default target and not test or anything. I'm fairly certain it wouldn't work if we didn't use install as the target, but I'm not sure if that would work with 3.x either. The clean target doesn't work if the plugin is part of the reactor and not in .m2/repository. I'll give you that. Dan On Sep 10, 2012, at 2:59 PM, Anders Hammar and...@hammar.net wrote: I'm fairly sure this didn't work in Maven 2.x. It was one of the unsolvable Maven 2.x bugs which was fixed in Maven 3. The workaround would be to use an older released version of the plugin. Don't think running a build twice is/was a workable workaround as I can't see how that would work in a release process. /Anders On Mon, Sep 10, 2012 at 8:11 PM, Arnaud Héritier aherit...@gmail.com wrote: On Mon, Sep 10, 2012 at 5:30 PM, Benson Margulies bimargul...@gmail.comwrote: On Mon, Sep 10, 2012 at 11:25 AM, Daniel Kulp dk...@apache.org wrote: On Sep 10, 2012, at 11:14 AM, Benson Margulies bimargul...@gmail.com wrote: In Maven 2.x, the following was true; the reactor could not apply a plugin it had just built. So, if a particular problem required a plugin (e.g., for generating code), the plugin has to be an independent project that is built in advance. Is this still true in 3.x? I don't think this is/was true. CXF has always used it's own codegen plugins within its reactor build, even with Maven 2.x. Dan, I'll try it again, but I could have sworn that this only works by running 'mvn' twice, so that there's a SNAPSHOT in ~/.m2/repository. I'm almost sure I had the same experience like Benson. It doesn't work in one step because maven reads all projects in the reactor, then tries to resolve the plugin where you are using it and cannot because it was built. Arnaud - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - 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
Re: Git as the canonical SCM
On Sep 5, 2012, at 10:08 PM, Kristian Rosenvold wrote: 2012/9/5 Romain Manni-Bucau rmannibu...@gmail.com: Last note: i think the plugin you speak about (create a kind of virtual project) will be a nightmare. Scm are nice but can be broken and when you dont have a 1:1 with remote repo it is even harder I would really like some elaboration on this, since I'm not sure I understand what you're trying to say. I work with the maven codebase all the time and I generally find working with layered components that are from different release modules to be a little painful although manageable. Most of this pain does /not/ stem from the fact that they are in different version control systems or different checkouts from the version control system (which they are). I think from my experience that your proposed plugin is sort of essential for working with maven code. I usually give up quickly because I can't find all the dependencies that some plugin I want to improve uses in a finite amount of time. However, I wonder how useful it will be on projects with more separation between interface and implementation, as in some osgi projects. If you have a module AIntf with interfaces and then the implementations in AImpl and project B uses AIntf how do you know to check out AImpl? (or the several AImpls). I'd love to see this work I like to think there are a few main use cases for checking out code: A) I want to fix a single problem/issue and when I'm done with that I'm going to submit a patch and get on with my life. B) I'm hooked. I fix things in a limited subset of the code base all the time. So I need to keep it recent, fresh and patched. C) I'm all over the place. I do global updates to dependencies and reformat code like there's no tomorrow. I think these are the three models we need to support well. I think especially A is important, since it's the gateway to entry ;) I like this division. And BTW as a very occasional maven patcher and git user elsewhere I think git would be an improvement over svn. thanks! david jencks Kristian - 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
Re: improving incremental builds
Is what you want different from what mvn -amd moduleA does? So your idea is to find the list of changed modules and then build that list with -amd? thanks david jencks On Aug 25, 2012, at 1:32 PM, Mark Struberg wrote: Hi folks! After a short discussion with Kristian, I've created a small app with 2 modules which shows a few problems with mavens incremental build logic. And since incremental builds do not work well, people use $ mvn _clean_ install all the time. We could speed up the development effort heavily if we make $ mvn install (without an upfront clean) more reliable. The sample [1] consists of moduleA and moduleB with BeanA and BeanB respectively. BeanB has a private BeanA field and moduleB has a dependency on moduleA. If I change BeanA and just invoke mvn install then only moduleA gets rebuilt. We currently do not rebuild moduleB, but we should do to create a reliable output. In fact, the incremental build within a single module already works to some degrees, but we must detect a change in dependencies and trigger a full rebuild on all depending modules. This could be done by storing the md5 of all dependency artifacts and compare them on the next build. If the md5 of a dependency did change, then we need to build the module full cycle. Other ideas are welcome. Slaps as well if I forgot some obvious stuff and all works well already. LieGrue, strub - 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
Re: Maven release plugin not honoring -Darguments
An FYI on the escaping/quoting as that's come up twice and isn't the issue.
public class Arguments {
public static void main(String[] args) {
for (String arg : args) {
System.out.printf([%s], arg);
}
System.out.println();
}
}
$ java Arguments mvn release:prepare -DdryRun=true
-Darguments=-DskipTests=true -DfailIfNoTests=false
[mvn][release:prepare][-DdryRun=true][-Darguments=-DskipTests=true
-DfailIfNoTests=false]
$ java Arguments mvn release:prepare -DdryRun=true
-Darguments=-DskipTests=true -DfailIfNoTests=false
[mvn][release:prepare][-DdryRun=true][-Darguments=-DskipTests=true
-DfailIfNoTests=false]
$ java Arguments mvn release:prepare -DdryRun=true
-Darguments=-DskipTests=true -DfailIfNoTests=false
[mvn][release:prepare][-DdryRun=true][-Darguments=-DskipTests=true
-DfailIfNoTests=false]
$ java Arguments mvn release:prepare -DdryRun=true
-Darguments=-DskipTests=true' '-DfailIfNoTests=false
[mvn][release:prepare][-DdryRun=true][-Darguments=-DskipTests=true
-DfailIfNoTests=false]
$ java Arguments mvn release:prepare -DdryRun=true
-Darguments=-DskipTests=true\ -DfailIfNoTests=false
[mvn][release:prepare][-DdryRun=true][-Darguments=-DskipTests=true
-DfailIfNoTests=false]
The next one just to be goofy :)
$ java Arguments mvn release:prepare -DdryRun=true
-Dargum'en'ts=-Ds'k'ipTests=true\ -DfailIfNoTest's'=false
[mvn][release:prepare][-DdryRun=true][-Darguments=-DskipTests=true
-DfailIfNoTests=false]
And finally an actually broken one:
$ java Arguments mvn release:prepare -DdryRun=true -Darguments=-DskipTests=true
-DfailIfNoTests=false
[mvn][release:prepare][-DdryRun=true][-Darguments=-DskipTests=true][-DfailIfNoTests=false]
The problem isn't with the plugin but the Apache parent pom. Thanks, Benson,
for the feedback on that. There're half dozen committers on that pom so I'm
not sure who has the objection to allowing -Darguments to be used.
I've created this jira and attached a patch. Hopefully we can either fix it or
document it as intentionally not working and give reasons and workarounds like
the ones you suggest. I'm fine with either outcome.
https://issues.apache.org/jira/browse/MPOM-35
On a side note,... Happy new year to all! :)
-David
On Dec 30, 2011, at 2:22 AM, Ansgar Konermann wrote:
Am 27.09.2011 14:48 schrieb David Blevins david.blev...@gmail.com:
Is it a known issue that the release plugin does not honor the
-Darguments?
Specifically, I'm attempting to:
mvn release:prepare -DdryRun=true -Darguments=-DskipTests=true
-DfailIfNoTests=false
Try:
mvn release:prepare -DdryRun=true -Darguments=-DskipTests=true
-DfailIfNoTests=false
Notice the slightly different quoting (before -Darguments). Works well for
me.
Best regards
Ansgar
It takes 40 minutes to get through a dryRun with tests on. We still have
several kinks in the build to work out before the release plugin will work,
so obviously running with tests on every dryRun is just making a hard task
impossible.
maven 3.0.3, apache-10 parent pom, maven-release-plugin 2.1
-David
-
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
Re: Maven release plugin not honoring -Darguments
On Tue, Sep 27, 2011 at 1:09 PM, David Blevins david.blev...@gmail.com wrote:
Did some more digging and it seems the issue is in the apache-10 parent pom.
If you alter it like so, the arguments are passed as expected:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.1/version
configuration
useReleaseProfilefalse/useReleaseProfile
goalsdeploy/goals
!--arguments-Papache-release/arguments--
arguments-Papache-release ${arguments}/arguments
/configuration
/plugin
Seems this is just a mistake as the full config as reported via -X contains
quite a bit of foo${foo}/foo style declarations. We likely just missed
it here.
Going to use a hacked parent pom for the moment but it would be great if we
could get an apache-11 pom out soonish.
This came up again. Posting so I don't forget to deal with it when I
have time. Will file an issue with a patch tomorrow unless someone
beats me to it.
-David
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Meta information about dependencies in a pom?
I've run into this problem in 3 or 4 situations and the only practical solution is to individually list the dependencies with the extra info in the plugin configurations. I don't really understand the mindset that only the information needed for some bits of well-known maven can be associated with dependencies, and all other uses should just duplicate large swathes of maven configuration to be able to add a couple bits of info per dependency. My impression is that aether takes a more inclusive view of dependency properties. thanks david jencks On Nov 8, 2011, at 9:00 AM, Brett Porter wrote: On 08/11/2011, at 8:15 AM, Carsten Ziegeler wrote: Yes, we were using that approach for years now and it turned out to be too error prone as you have to keep the plugin configuration and the dependency list in sync. It doesn't sound like a hard task first, but in our case it caused trouble many times. That's why we would like to have a single point of information. So, wildcards or excludes lists don't help with the sync task? There's no convention that can be applied (e.g. all dependencies of a certain type, or the same group ID as the project)? How would you handle transitive dependencies? - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - 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
Re: [VOTE] Usage of Aether and Sisu as dependencies of maven core with EPL licenses - take 2
Another month went by any progress? david jencks On Sep 30, 2011, at 3:50 AM, Stephen Connolly wrote: To clarify... I last checked yesterday, and the PMC in question is some eclipse PMC but it is unclear to me, only having just got my eclipse account set up, exactly which On 30 September 2011 11:48, Stephen Connolly stephen.alan.conno...@gmail.com wrote: When I last checked, the code import is still waiting for PMC approval... I suspect that until the code has been imported there cannot be a release ;-) On 30 September 2011 10:05, Mark Derricutt m...@talios.com wrote: Jason - is there any further news on the Aether/Sisu front? Really starting to get an itch for a 3.0.4 release - my manager this morning was having strange resolution issues that I traced to same issues I've been seeing with the currently shipped aether. Would be good to get a 3.0.4 release out with some updated plugin versions set as well ( the new wagon, archetype come to mind ). Mark -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Wed, Sep 21, 2011 at 12:17 AM, Baptiste MATHUS m...@batmat.net wrote: To be sure, are you talking about renaming Aether packages to something like org.eclipse.aether? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Maven release plugin not honoring -Darguments
Is it a known issue that the release plugin does not honor the -Darguments? Specifically, I'm attempting to: mvn release:prepare -DdryRun=true -Darguments=-DskipTests=true -DfailIfNoTests=false It takes 40 minutes to get through a dryRun with tests on. We still have several kinks in the build to work out before the release plugin will work, so obviously running with tests on every dryRun is just making a hard task impossible. maven 3.0.3, apache-10 parent pom, maven-release-plugin 2.1 -David - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven release plugin not honoring -Darguments
IIRC you have to include your forked maven arguments in the release plugin configuration under arguments-DskipTests=true -DfailIfNoTests=false/arguments Perhaps someone else can say _why_ the m-r-p is set up so you can't set this on the command line? thanks david jencks On Sep 27, 2011, at 5:40 AM, David Blevins wrote: Is it a known issue that the release plugin does not honor the -Darguments? Specifically, I'm attempting to: mvn release:prepare -DdryRun=true -Darguments=-DskipTests=true -DfailIfNoTests=false It takes 40 minutes to get through a dryRun with tests on. We still have several kinks in the build to work out before the release plugin will work, so obviously running with tests on every dryRun is just making a hard task impossible. maven 3.0.3, apache-10 parent pom, maven-release-plugin 2.1 -David - 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
Re: Maven release plugin not honoring -Darguments
That's not it, the quoting was fine. Even with a single argument with no
spaces to -Darguments it still does not work.
Did some more digging and it seems the issue is in the apache-10 parent pom.
If you alter it like so, the arguments are passed as expected:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.1/version
configuration
useReleaseProfilefalse/useReleaseProfile
goalsdeploy/goals
!--arguments-Papache-release/arguments--
arguments-Papache-release ${arguments}/arguments
/configuration
/plugin
Seems this is just a mistake as the full config as reported via -X contains
quite a bit of foo${foo}/foo style declarations. We likely just missed it
here.
Going to use a hacked parent pom for the moment but it would be great if we
could get an apache-11 pom out soonish.
-David
On Sep 27, 2011, at 10:54 AM, Stephen Connolly wrote:
you can if you understand shell escaping.
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 27 Sep 2011 17:58, David Jencks david_jen...@yahoo.com wrote:
IIRC you have to include your forked maven arguments in the release plugin
configuration under
arguments-DskipTests=true -DfailIfNoTests=false/arguments
Perhaps someone else can say _why_ the m-r-p is set up so you can't set
this on the command line?
thanks
david jencks
On Sep 27, 2011, at 5:40 AM, David Blevins wrote:
Is it a known issue that the release plugin does not honor the
-Darguments?
Specifically, I'm attempting to:
mvn release:prepare -DdryRun=true -Darguments=-DskipTests=true
-DfailIfNoTests=false
It takes 40 minutes to get through a dryRun with tests on. We still have
several kinks in the build to work out before the release plugin will work,
so obviously running with tests on every dryRun is just making a hard task
impossible.
maven 3.0.3, apache-10 parent pom, maven-release-plugin 2.1
-David
-
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
Re: are multi-threaded builds still working reliably?
Maybe it would be a good idea to mention this on the siki page? Anyone know why? I thought maven used the eclipse compiler which is IIUC just java code so why would it behave differently on different os? thanks david jencks On Sep 24, 2011, at 12:11 AM, Olivier Lamy wrote: On osx you must fork compiler. -- Olivier Le 24 sept. 2011 04:41, David Jencks david_jen...@yahoo.com a écrit : I tried out the multi-threaded builds again recently ( https://cwiki.apache.org/MAVEN/parallel-builds-in-maven-3.html) (maven 3.0.3) and got some really strange results several minutes into the build. - the compiler plugin seemed to get corrupted source files and reported lots of nonexistent syntax errors - transitive dependencies didn't work the same as with a normal build I don't really have time to investigate what's going on but wonder if anyone has a stable large-project multi-threaded build running on a recent macbook pro with snow leopard? OSX 10.6.8 java version 1.6.0_26 Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425) Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode) thanks david jencks - 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
are multi-threaded builds still working reliably?
I tried out the multi-threaded builds again recently (https://cwiki.apache.org/MAVEN/parallel-builds-in-maven-3.html) (maven 3.0.3) and got some really strange results several minutes into the build. - the compiler plugin seemed to get corrupted source files and reported lots of nonexistent syntax errors - transitive dependencies didn't work the same as with a normal build I don't really have time to investigate what's going on but wonder if anyone has a stable large-project multi-threaded build running on a recent macbook pro with snow leopard? OSX 10.6.8 java version 1.6.0_26 Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425) Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode) thanks david jencks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
I also was just about to point out that the legal discuss thread indicated that (b) and (c) are equivalent violations of apache policy. Since jason/sonatype doesn't want this code at apache, and the board doesn't want us forking it somewhere else to use it because jason/sonatype doesn't want the code at apache, I don't see why the dual licensing would make any difference. We still can't bring the code here or fork it anywhere else to use it inconsistently with the owners wishes. I think we either use it as-is, or don't use it at all. I'm not sure I understand the thinking behind the idea that sonatype will make aether unusable for maven (isn't this the basic concern over using aether?). I don't see this as a plausible scenario. thanks david jencks On Jul 30, 2011, at 10:14 AM, Ralph Goers wrote: The board made it pretty clear that option b is also highly discouraged so I wouldn't list that as an option. The only viable path I see will be to ultimately include the EPL version of Aether and then replace it with our own code when someone decides there is something they want to do that requires it. A dual licensed version of Aether would probably insure a complete replacement is never necessary. Ralph On Jul 30, 2011, at 4:46 AM, Benson Margulies wrote: I'd like to to try to put a little oxygen into this thread now, given the rather clear results of the vote thread. Ralph posed the following question on Legal Discuss: 'Can the Maven PMC pull a dual-licensed version of AEther back into Apache without a grant from Sonatype?' The answer was, legally yes, but it is counter to long-established policy, and strongly discouraged by a number of senior ASF people (including a board member or two). So, the community has some choices. It seems to me that the viability of these different choices depends on the viability of walking away from AEther. In practical terms, the choices are: a) Use versions of AEther controlled by 'someone else'. b) Create our own 'someone else' at apache-extras or elsewhere. c) Go down the path of becoming an exception to the policy and take on reworking AEther from the last dual-licensed version. d) Start All Over Again from Maven 2.2. From the vote comments, it seemed to me that a plurality of people felt that EPL at Eclipse was tolerable. So that argues for sitting still for now. I offer only the observation that forking into apache-extras 'works' the same way today, or after the code appears in Eclipse. In other words, adopting what's out there today only makes choice (c) harder, it doesn't have any impact that I see on a, b, or d. However, a 'no' vote is a 'no' vote, so this is all just food for thought. - 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
Possible feature request about scary warnings
I often see lots of stuff like this in my m3 builds: [WARNING] Invalid POM for org.apache.openejb:openejb-core:jar:4.0.0-SNAPSHOT, transitive dependencies (if any) will not be available, enable debug logging for more details but the build appears to work fine and I sure can't see for myself what the problem might be. If I turn on debug logging then I get a multimegabyte text file that it's very hard to find the relevant info in. Would it make sense to have something like a build option that would fail the build for invalid poms and print the relevant info? Or maybe this is already possible but there's no way to find out about it? thanks david jencks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [maven-assembly-plugin] smart(er) dependency merge
I think the shade plugin does something like this. david jencks On Jun 30, 2011, at 12:45 AM, Robert Burrell Donkin wrote: (If support for this use case already exists then apologies in advance but I suspect it's not supported and that I'll need to hack some extra code...) specific use case: assemble a jar containing all dependencies without losing legal meta-data example: LICENSE and NOTICE in META-INF must be preserved when including an Apache License, Version 2 dependency workaround: manually maintaining specific LICENSE and NOTICE for the assembly and updating any time any dependency changes upstream Perhaps add this would be a little too specific for a general plugin. So, one way to satisfy this case is by adding a solution to more general use case: extensible support for smart dependency mergers with collision detection and resolution Opinions? Robert - 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
Parent POM built first + assembly plugin
Hello Maven Developers, I assume you all are familiar with the Maven issue causing this symptom: http://jira.codehaus.org/browse/MASSEMBLY-94. That report, along with the assembly plugin FAQ, suggests an assembly-only child module. This works, but has a remaining problem of manipulating that child module's dependencies to get it to build last which requires developers to remember to update that child's dependencies whenever they add or remove modules. Is there any resolution in sight to this issue? I tried to search for a mailing list discussion, but couldn't find anything. Thanks in advance, David -- Wise men _still_ seek Him. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Article proposed for Maven Article Page
I think what Jochen is trying to convey is that you are leaving it entirely up to the developers to assure that the api/client jar can be used without the contents of the impl jar. There is nothing in the build system stopping developers from putting a subclass of an implementation class in the api jar, thus making the api jar completely useless as a guide to an api. If you make separate projects for the api and implementation, the build system will prevent you from doing this. It is definitely less convenient for developers to have to deal with 2 projects, but you get enforcement of the principle that the api is usable without implementation classes from the build system, not from developers possibly remembering to think. In extreme cases where the build system doesn't enforce any separation rules you get projects like tomcat which build all their classes together and then partition them into jars that have circular uses relationships so that it is impossible to build them individually in any order. My experience is that if you rely on developers you can set something up that initially works but good intentions quickly give way to expedience and very quickly your intended separation has disappeared. I'm now willing to put up with a really lot of build system annoyance to get it to enforce this kind of separation. hope I haven't made this thread too long... thanks david jencks On Apr 20, 2011, at 2:45 AM, xanadu72 wrote: Jochen, I agree with you. The isolation is achieved for external usage but not between the api and the implementation. It is not the recommended way to distribute framework libraries but i find it more suitable for multi tier application to reduce the configuration management work load. In this context the API is not intended to provided a way to implement multiple implementations. The term api can be replaced with client. On Wed, Apr 20, 2011 at 11:34 AM, jochen-2 [via Maven] ml-node+4315334-12416097-197...@n5.nabble.com wrote: On Wed, Apr 20, 2011 at 11:28 AM, xanadu72 [hidden email]http://user/SendEmail.jtp?type=nodenode=4315334i=0by-user=t wrote: The client api is a separate artifact. You can reuse it as you want. In your repository you will get in the same release folder two artifacts : That's completely understood. But as a separate jar file, you should ensure that it is compilable without any of the other classes. For example, it might accidentally import something from the rest of the packages. You don't get that safety by just repackaging a bunch of class files in another jar file. -- I Am What I Am And That's All What I Yam (Popeye) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: really threadsafe?
http://jira.codehaus.org/browse/MRRESOURCES-54 thank you so much for looking into this the parallel build is great! thanks david jencks On Mar 27, 2011, at 11:17 PM, Kristian Rosenvold wrote: I was sent the url to the old velocity stuff and I see several thread safety issues in the (*really* old) version being used by m-r-r-p. I checked out the latest version of velocity and all the problems I found were fixed there, so I think we'll just give it a shot. Just make an issue under http://jira.codehaus.org/browse/MRRESOURCES and I'll push it through. Kristian Den 23.03.2011 23:29, skrev David Jencks: I've been trying out the parallel stuff in maven 3.0.3 and when it works it's great.However I'm wondering what's going on here with this intermittent error. I've never gotten this error bulding single threaded. https://cwiki.apache.org/MAVEN/parallel-builds-in-maven-3.html says the maven-remote-resources-plugin 1.2 is threadsafe. However... [ERROR] Failed to execute goal org.apache.maven.plugins:maven-remote-resources-plugin:1.2:process (default) on project assemblies: Error rendering velocity resource. NullPointerException - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-remote-resources-plugin:1.2:process (default) on project assemblies: Error rendering velocity resource. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167) at org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:164) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:680) Caused by: org.apache.maven.plugin.MojoExecutionException: Error rendering velocity resource. at org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.processResourceBundles(ProcessRemoteResourcesMojo.java:1212) at org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.execute(ProcessRemoteResourcesMojo.java:519) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 13 more Caused by: java.lang.NullPointerException at org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:831) at org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:440) at org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:419) at org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.processResourceBundles(ProcessRemoteResourcesMojo.java:1125) ... 16 more I ran with -T 4. It looks like there were 3 failures with this same stack trace all in pom projects that aggregate subprojects. I don't have a lot of time to track down whats going on but might be able to spend a little time given enough advice. thanks david jencks - 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
Re: [VOTE] Release Maven ACR Plugin version 1.0
+1
really threadsafe?
I've been trying out the parallel stuff in maven 3.0.3 and when it works it's great.However I'm wondering what's going on here with this intermittent error. I've never gotten this error bulding single threaded. https://cwiki.apache.org/MAVEN/parallel-builds-in-maven-3.html says the maven-remote-resources-plugin 1.2 is threadsafe. However... [ERROR] Failed to execute goal org.apache.maven.plugins:maven-remote-resources-plugin:1.2:process (default) on project assemblies: Error rendering velocity resource. NullPointerException - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-remote-resources-plugin:1.2:process (default) on project assemblies: Error rendering velocity resource. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167) at org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:164) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:680) Caused by: org.apache.maven.plugin.MojoExecutionException: Error rendering velocity resource. at org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.processResourceBundles(ProcessRemoteResourcesMojo.java:1212) at org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.execute(ProcessRemoteResourcesMojo.java:519) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 13 more Caused by: java.lang.NullPointerException at org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:831) at org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:440) at org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:419) at org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.processResourceBundles(ProcessRemoteResourcesMojo.java:1125) ... 16 more I ran with -T 4. It looks like there were 3 failures with this same stack trace all in pom projects that aggregate subprojects. I don't have a lot of time to track down whats going on but might be able to spend a little time given enough advice. thanks david jencks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: How do you get aether to traverse the entire dependency tree?
This ended up being good advice. The problem was an antique maven-install-plugin specified in a parent pom. Is there some way to require minimum plugin versions in a custom packaging or its LifecycleMapping? thanks david jencks On Mar 21, 2011, at 3:06 AM, Benjamin Bentmann wrote: David Jencks wrote: Any advice? Provide a standalone example project that allows others to reproduce/analyze the problem. Benjamin - 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
How do you get aether to traverse the entire dependency tree?
One of the nice side effects of moving the maven resolution code away from
apache is that people who work for companies with IP policies need additional
approval to look at the source to find out how it works. Since I don't have
such approval I'm really hoping for some advice.
I've been following the sample code at
http://aether.sonatype.org/using-aether-in-maven-plugins.html
http://www.sonatype.com/people/2011/01/how-to-use-aether-in-maven-plugins/#more-6838
I am working on a maven plugin that needs to traverse the entire dependency
tree starting from a project artifact. Aether is not finding the whole tree.
Why not? How do I make it?
To be more specific, aether is finding no children for an artifact that...
-- is only present in my local repo
-- is a custom packaging
-- the artifact for this custom packaging has a classifier
-- the type is not the same as the packaging name
I'll call this artifact A below.
i've made some spot checks for jars that are deployed to apache snapshot repo
or central and aether seems to be finding the children for these.
I think the relevant code is:
/**
* The entry point to Aether, i.e. the component doing all the work.
*
* @component
*/
private RepositorySystem repoSystem;
/**
* The current repository/network configuration of Maven.
*
* @parameter default-value=${repositorySystemSession}
* @readonly
*/
private RepositorySystemSession repoSession;
/**
* The project's remote repositories to use for the resolution of project
dependencies.
*
* @parameter default-value=${project.remoteProjectRepositories}
* @readonly
*/
private ListRemoteRepository projectRepos;
private DependencyNode getDependencyTree(Artifact artifact) throws
MojoExecutionException {
try {
Listorg.sonatype.aether.graph.Dependency managedArtifacts = new
ArrayListorg.sonatype.aether.graph.Dependency();
CollectRequest collectRequest = new CollectRequest(new
org.sonatype.aether.graph.Dependency(artifact, compile), managedArtifacts,
projectRepos);
CollectResult result = repoSystem.collectDependencies(repoSession,
collectRequest);
return result.getRoot();
} catch (DependencyCollectionException e) {
throw new MojoExecutionException(Cannot build project dependency
tree, e);
}
}
getDependencyTree when called on my project artifact returns a tree where the
node for A has no children. Furthermore calling getDependencyTree on A
directly also finds no children. On the other hand running this plugin on the
project for A does find the children of A (the dependencies listed in the pom
for A).
changing the dependency on A from
dependency
groupIdorg.apache.geronimo.features/groupId
artifactIdorg.apache.geronimo.jaxb-support/artifactId
typexml/type
classifierfeatures/classifier
version3.99.99-SNAPSHOT/version
/dependency
(xml is the primary artifact file extension)
to
dependency
groupIdorg.apache.geronimo.features/groupId
artifactIdorg.apache.geronimo.jaxb-support/artifactId
typefeature/type
classifierfeatures/classifier
version3.99.99-SNAPSHOT/version
/dependency
(feature is the packaging type)
causes a resolution error:
[ERROR] Failed to execute goal on project org.apache.geronimo.transaction.kar:
Could not resolve dependencies for project
org.apache.geronimo.features:org.apache.geronimo.transaction.kar:kar:3.99.99-SNAPSHOT:
Could not find artifact
org.apache.geronimo.features:org.apache.geronimo.jaxb-support:feature:features:3.99.99-SNAPSHOT
in nexus (http://localhost:8081/nexus/content/groups/public) - [Help 1]
Any advice?
thanks
david jencks
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Cleanup to SNAPSHOT version handling
I think I've seen some projects, although I don't recall where, that use .SNAPSHOT because then you get legal osgi bundle versions in require-bundle instructions in the maven-bundle-plugin. Presumably this could be fixed in the maven-bundle-plugin since it already converts -SNAPSHOT to .SNAPSHOT when generating the bundle's own osgi version. david jencks On Dec 10, 2010, at 9:18 AM, Benjamin Bentmann wrote: Hi, as part of MNG-4893 [0] an inconsistency in the way a version string is treated as a snapshot or release was detected. In short, the issue is about what suffix exactly marks a snapshot version. The current intention is to revise the logic such that the suffix -SNAPSHOT (note the leading hyphen) and not just SNAPSHOT is required to denote a snapshot. This mail is meant as a heads up for users that unintentionally use irregular SNAPSHOT versioning and allow them to adjust their builds. If changing the builds to use -SNAPSHOT isn't possible, we would like to hear the technical reasons for this. Thanks Benjamin [0] http://jira.codehaus.org/browse/MNG-4893 - 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
Can surefire create a single output file?
We are using surefire and would like to consolidate all the jUnit results into one XML file as opposed to one file per class. Is this possible? Our build server does not support reading multiple files. Thanks, Dave
Re: Auto apache version standard as an enforcer rule?
The BND tool used in the (misnamed) felix maven-bundle-plugin has, in recent versions not yet used in the maven-bundle plugin, some logic to determine whether an Import-Package constraint is uses or implements and decides which segment of the version number to increment based on that. might be useful... david jencks On Nov 9, 2010, at 4:58 AM, Jesse Glick wrote: On 11/08/2010 02:21 AM, Rex Hoffman wrote: project: java-version-delta By the way, you should look at https://sigtest.dev.java.net/ if you have not done so already. I'm not sure if the license feature set suits your needs but it would make a potentially useful alternate impl. This is the tool used by some of Oracle's teams to check (primarily binary) compatibility of Java APIs. My background: for netbeans.org API modules we run this tool to check for compatible incompatible changes among packages marked public. Currently we have an idiosyncratic Ant build (is there any other kind?) so comparisons are done against the modules as they existed in the last product release, but of course in a Maven setup we would use the policy you are proposing: x.y - x.(y+1) may have compatible but not incompatible changes, etc. The apache portable runtime version standard does want the name of a library to include it's major version number, so for ubuntu/debian xerces look like: libxerces2-java_2.9.0-1_all.deb Not sure this is applicable to most Java development. If you are using a container (such as OSGi) which supports class loader isolation, *and* this container permits multiple components with the same ID (but possibly different versions) to be loaded in parallel, then it is unnecessary. Containers with isolation but which enforce uniqueness on loaded IDs might benefit, so long as it really makes sense to load two copies of the component - true for plain old class libraries, not necessarily true for active components which might register services of some sort. Apps not using a container are unlikely to benefit since you could only use multiple versions of a library in case the package hierarchy was also renamed. Anyway, I agree that this is not likely something that an API compatibility plugin should address (a separate enforcer rule would suffice). the default would be to assume that a client of an artifact is not expected to implement [any interfaces] This seems like a poor default - directly contradicts the longstanding Java compatibility policy. (*) If anything, I would place the burden on API designers who publish interfaces (or abstract classes) they expect no one else to implement, despite there being no such enforcement from the Java language. (**) An annotation for this purpose makes some sense, but it would have to be hosted in a very generic place quite unrelated to a Maven plugin. In the short term, plugin configuration to exclude implements checking on certain types or packages may be a better workaround. (*) For binary compatibility it is permitted to add an interface method without breaking existing implementers, so long as this method is never called - but that condition is unlikely, since why would there be a method no one is calling? You cannot even check whether a given object implements a new method or not without using reflection. Better to just introduce a new interface (possibly extending the old one) when you want to change signatures. (**) If the API designer wants, it is possible to expose an abstract class which can be implemented only within the same component. JSR 294 would be very helpful here, but it is possible today so long as all the implementations are in the same package, *or* the component uses a format (such as OSGi bundle) which permits restrictions on the exported types or packages. In http://bitbucket.org/jglick/qualifiedpublic I have been playing with a more fine-grained system but for now it requires javac from JDK 7. - 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
Re: Dependency policies
maybe you could enhance that rule to do regexp matching on each maven coordinate component and implement your category concept using a naming convention? david jencks On Oct 1, 2010, at 10:51 AM, Alan D. Cabrera wrote: It's close but not exactly what I need. I don't want to maintain rules on artifacts. I want to maintain restrictions between categories of artifacts. Regards, Alan On Oct 1, 2010, at 10:22 AM, Rex Hoffman wrote: I haven't used it: but this, and profiles, should do the trick. http://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html I'm just trying to get some contributions in to maven (other enforcer rules) but still feel the need to say you probably should have asked this on the user mailing list. Rex On Fri, Oct 1, 2010 at 9:56 AM, Alan D. Cabrera l...@toolazydogs.com wrote: Is there some way to categorize jars and restrict the dependencies between categories of those jars? At least maybe reports dependency violations? For example let's say I have two categories, api and impl. Impl can depend on Api but not others' impl. Api can rely on Api. When I perform a build it would be nice if the build failed or at least an warning is reported. Regards, Alan - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Rex Hoffman (415) 273-9438 415-2REXGET http://www.e-hoffman.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
maven-remote-resources-plugin ignores offline?
I asked about this on the users list about a month ago and got no response. I think the maven-remote-resources-plugin has a problem. When I build for the first time in 24 hours with -o, I still get stuff like this: [INFO] --- maven-remote-resources-plugin:1.0:process (default) @ geronimo-jetty-web-cts --- [INFO] Setting property: classpath.resource.loader.class = 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'. [INFO] Setting property: velocimacro.messages.on = 'false'. [INFO] Setting property: resource.loader = 'classpath'. [INFO] Setting property: resource.manager.logwhenfound = 'false'. [INFO] snapshot org.apache.geronimo.modules:geronimo-naming-builder:3.0-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.geronimo:geronimo:3.0-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.openwebbeans:openwebbeans-web:1.0.0-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.xbean:xbean-asm-shaded:3.8-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.geronimo.modules:geronimo-jetty8-builder:3.0-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.geronimo.modules:geronimo-aries-builder:3.0-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.geronimo.plugins:aries:3.0-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.geronimo.configs:welcome-jetty:3.0-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.geronimo.plugins:welcome:3.0-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.geronimo.framework:shutdown:3.0-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.geronimo.modules:geronimo-persistence-jpa20-builder:3.0-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.geronimo.plugins:openjpa2:3.0-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.geronimo.configs:jsr88-war-configurer:3.0-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.geronimo.framework:geronimo-shell:3.0-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.geronimo.configs:connector-deployer-1_6:3.0-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.geronimo.framework:framework:3.0-SNAPSHOT: checking for updates from codehaus.snapshots [INFO] snapshot org.apache.geronimo.framework:framework:3.0-SNAPSHOT: checking for updates from apache.snapshots [INFO] snapshot org.apache.geronimo:geronimo:3.0-SNAPSHOT: checking for updates from codehaus.snapshots [INFO] snapshot org.apache.geronimo:geronimo:3.0-SNAPSHOT: checking for updates from apache.snapshots ... IIRC I get the same results with m-r-r-p v 1.1. When I don't have internet access, there's an extremely long delay (maybe a minute?) between each line. I get the same results with maven 2.2.1 and 3 beta 1. Does anyone else see this and/or think its a problem? So far I haven't located any of the code that might be responsible for this. thanks david jencks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Incompatibilities between maven 2.2.1 and 3.0.0-beta-1
I started trying to build geronimo trunk using maven 3 and ran into a couple inconsistencies so far in our maven plugins. I don't know if we were doing something unfortunate before I have no problem changing the geronimo code to something that will work on both mavens 1. We were calling org.apache.maven.artifact Artifact; //from dependencyNode.getRelatedArtifact() if not null, otherwise dependencyNode.getArtifact() artifact.getVersionRange().getRecommendedVersion().toString() on essentially every element in the unpruned dependency tree (our pruning rules are different from maven's). This no longer works. artifact.getVersionRange() is now null on, apparently, non-direct transitive dependencies. The only workaround I've come across is to put all the dependencies where this is actually called in the pom the plugin runs on. 2. Plugin plugin = (Plugin) project.getModel().getBuild().getPluginsAsMap().get(org.apache.geronimo.buildsupport:car-maven-plugin); plugin.getExecutions() has changed. I'm not exactly sure what it used to contain, but for a plugin that wasn't explicitly configured with an execution element in the pom it was either empty or had one element in it. Now it contains elements for every mojo in the plugin. I think I've figured out how to find the one I want, so this is not a big problem for me. On the other hand, the code here was originally to do my own merging of configurations between parent pom and child because what maven was doing for me didn't work (I don't remember the details). Has the merging been rewritten? Or, is there a way to get object trees for each unmerged configuration so I can do it in my plugin code? Although (2) is not really a problem for me I would like to know how to work around (1). thanks david jencks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Surefire-plugin and surefirebooter jars and Glassfish and EJB unit testing
ljnelson wrote: Now Ken Saks, spec author for EJB 3.1 is saying sure, whoops, Glassfish has a problem, it doesn't consult the *effective* classpath because it doesn't take into consideration Manifest.MF Class-Path entries. Fine. But *then *he says something WAY more troubling: that any classpath roots reachable by way of Surefire's booter jar's Manifest Class-Path entry aren't actually roots for new EJB modules. That is, the classpath defined by Manifest.MF Class-Path is somehow...special as regards scanning. I say: huh?! I bring this up here, because if he's right and that ends up being part of the spec, then the neat way that surefire deals with big classpaths could effectively break standardized EJB 3.1 unit/integration testing. That might lead to you wanting to change or otherwise mess with the way Surefire does classpath construction. Per spec you are also able to list the file paths of the jars you want scanned. So in the end you should be able to take that approach even if GlassFish can't find the jars on its own. The classes are there and loadable in the thread context classloader so if you explicitly point at the jars, all should be fine. In terms of Glassfish effectively changing the spec. If they want to limit their support to specific techniques for scanning and finding modules, that's their call. But it only affects their implementation and not the spec itself. The new Embedded EJB Container functionality in the spec is intentionally minimalistic so that vendors have adequate room figure out how to make it work with their architecture. This is just part of the expected challenges that vendors will face. -- View this message in context: http://old.nabble.com/Surefire-plugin-and-surefirebooter-jars-and-Glassfish-and-EJB-unit--testing-tp28184255p28185208.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Surefire and non-jar artifacts
Recall that a conformant rar file has all its classes in embedded jar
files, so putting the outside actual rar file on the classpath
doesn't give you access to any classes. If you put classes loose
inside a rar then a compliant j2ca container will probably ignore them.
On Feb 15, 2010, at 9:16 AM, Stephen Connolly wrote:
Hi,
So the lovely JCA resource adapters (a.k.a. rar files)...
In Maven 2.0.9, these were added to the classpath
What exactly was added to the classpath?
In Maven 2.2.1, these are no longer added to the classpath...
The former made testing resource adapters easy, but causes issues when
packaging a resource adapter in an EAR...
The later simplifies packaging RAR files inside an EAR (unless
possibly you want to try for a skinny RAR) but makes testing the code
that depends on the RAR more complex.
For example, using the lovely openejb, I now have to do:
plugin
artifactIdmaven-dependency-plugin/artifactId
executions
execution
phasegenerate-test-resources/phase
goals
goalcopy-dependencies/goal
/goals
configuration
includeTypesrar/includeTypes
stripVersiontrue/stripVersion
includeScopetest/includeScope
outputDirectory${project.build.directory}/test-dependencies/
outputDirectory
/configuration
/execution
/executions
/plugin
plugin
artifactIdmaven-surefire-plugin/artifactId
configuration
additionalClasspathElements
additionalClasspathElement${project.build.directory}/test-
dependencies/my-jca-impl.rar/additionalClasspathElement
/additionalClasspathElements
/configuration
/plugin
This looks to me as if its putting the rar on the classpath, not the
jars inside that contain the classes.
Which is just plain ugly...
My first thought was to have an
additionalClasspathDependencies
configuration in surefire... but I just know that it would be abused
like some mad crazy fool... and because it would not be taking part in
depMgmt, it would cause issues with releasing so that's not best
practice way at all then
My second thought is to have
additionalClasspathTypes
additionalClasspathType
typerar/type
includeTransitivetrue/includeTransitive
/additionalClasspathType
/additionalClasspathTypes
So what do people think?
So are you proposing that if you have a rar, war, or ear, including it
as a dependency will figure out all the jars inside, compute the
actual internal classpath, and add all these to the maven classpath?
I have not problem with this but it's unclear to me if that's what you
are asking for.
thanks
david jencks
-Stephen.
P.S.
I've rejected my first plan... if Jason to aproves I'll resurect
it... otherwise Plan 2 or 3 (TBD)
-
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
Re: [Result] [VOTE] Apache (parent POM) version 7
Any idea when another try might be feasible? I'm updating a bunch of project's builds, having the completely built-in source assembly would be pretty handy. many thanks david jencks On Dec 10, 2009, at 1:40 PM, John Casey wrote: I've withdrawn the tag for this vote. We can try again later with the newer plugin versions. -john David Jencks wrote: It looks to me as if this vote failed. I'd really appreciate it if someone would remove the apache-7 tag and roll back trunk to say version 7-SNAPSHOT so one doesn't have to search the mail archives to find out why the tag isn't represented at maven central. Concluding the vote thread might be good too :-) thanks david jencks On Nov 14, 2009, at 5:58 AM, Benjamin Bentmann wrote: Benjamin Bentmann wrote: John Casey wrote: https://repository.apache.org/content/repositories/orgapacheapache-001/org/apache/apache/7/ +1 I change my vote -1 after discovering that the version of the maven-javadoc-plugin being used by this POM, namely 2.6.1, is prone to fail during releases of multi-module projects [0]. Benjamin [0] http://jira.codehaus.org/browse/MJAVADOC-275 - 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
Re: [VOTE] Apache (parent POM) version 7
It looks to me as if this vote failed. I'd really appreciate it if someone would remove the apache-7 tag and roll back trunk to say version 7-SNAPSHOT so one doesn't have to search the mail archives to find out why the tag isn't represented at maven central. Concluding the vote thread might be good too :-) thanks david jencks On Nov 14, 2009, at 5:58 AM, Benjamin Bentmann wrote: Benjamin Bentmann wrote: John Casey wrote: https://repository.apache.org/content/repositories/orgapacheapache-001/org/apache/apache/7/ +1 I change my vote -1 after discovering that the version of the maven- javadoc-plugin being used by this POM, namely 2.6.1, is prone to fail during releases of multi-module projects [0]. Benjamin [0] http://jira.codehaus.org/browse/MJAVADOC-275 - 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
Re: Release plugin documentation request
Hi Dennis, Thanks for pointing out those pages. They indeed have the information I was asking for for those three goals. Might I suggest that these three pages are very clearly not examples but the basic usage guide for these three goals and would be much more visible linked from the usage page or better yet included in the goal explanation pages? thanks david jencks On Dec 6, 2009, at 1:23 PM, Dennis Lundberg wrote: Hi David Great to get some feedback on the docs. I think we have prepare, perform and branch covered pretty well with these pages: http://maven.apache.org/plugins/maven-release-plugin/examples/prepare-release.html http://maven.apache.org/plugins/maven-release-plugin/examples/perform-release.html http://maven.apache.org/plugins/maven-release-plugin/examples/branch.html So I guess we'd need two more covering rollback and clean. David Jencks wrote: I find that the release plugin docs don't give me an adequate idea of what to expect to happen in svn when I run release:prepare release:rollback release:perform release:branch After some experimentation I think I know what happens for some of these: release:prepare makes 3 svn commits - update current project to release version - create tag (from what? I have no idea) - update current project to next development version release:rollback, in an indeterminate number of commits, undoes anything committed since release:prepare was run for the first time in this release attempt. In particular if you tried to commit build fixes that only became evident during release:prepare, they will get undone. release:perform makes no svn changes release:branch I have no idea about. I suspect it would take about 15 minutes for one of the authors to update the docs with some accurate info along these lines and I doubt I would be the only one appreciating the effort. thanks david jencks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - 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
Release plugin documentation request
I find that the release plugin docs don't give me an adequate idea of what to expect to happen in svn when I run release:prepare release:rollback release:perform release:branch After some experimentation I think I know what happens for some of these: release:prepare makes 3 svn commits - update current project to release version - create tag (from what? I have no idea) - update current project to next development version release:rollback, in an indeterminate number of commits, undoes anything committed since release:prepare was run for the first time in this release attempt. In particular if you tried to commit build fixes that only became evident during release:prepare, they will get undone. release:perform makes no svn changes release:branch I have no idea about. I suspect it would take about 15 minutes for one of the authors to update the docs with some accurate info along these lines and I doubt I would be the only one appreciating the effort. thanks david jencks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
