Re: Future of Ivy and IvyDE
I agree with what Stefan notes in his mail. Some years back when I started contributing to Ivy, I realized that the documentation (formal or informal) related to the internal implementation details of Ivy is non-existent. Sometimes I had to select a file, go over its commit history then go read all JIRAs that were part of those commit logs and even then, a lot of the information was either missing or outdated. At that time, I used to use Ivy in some of our projects, so I could keep refreshing with the code base and relate to it, so that whenever I had to fix a bug or add something, I had the previous collected knowledge of the Ivy code already fresh (to some extent) in my mind. It's now been some years since I have used Ivy and I no longer have the Ivy codebase knowledge in my mind. Like Stefan noted, these recent vulnerability fixes took the Ant team a lot of time and energy to fix because of these issues. Personally, I don't expect myself to have the ability to continue contributing to Ivy. As for IvyDE, on the development front, it has seen no movement. I am not even sure if it builds with the current Eclipse versions. I hadn't contributed to it, but I remember that when releasing Ivy 2.5.0, it was struggle to update the IvyDE update site. -Jaikiran On 22/08/23 9:32 pm, Stefan Bodewig wrote: Hi all before I get to the actual content of this mail: * I'm cross-posting to three lists but I ask you to keep responses to dev@ant only (and join the list if necessary) if you want to respond. * what I write is my personal opinion and not shared by the PMC as a whole. The people on the PMC know I'd be writing a mail like this sooner or later, though. * this is a discussion, not a vote. phew I'm not quite sure what I hope to achieve with this email, but I'd like to share my thoughts - and raise the awareness of an elephant being in the room. Over the past year we've had three security vulnerabilities discovered in Ivy and it took us much too long to get them fixed. The reason for this is there are no people left around who are familiar with the Ivy code base. Most of the remaining developers around Ant are not even users of Ivy - I know I am not and have never been. When it comes to IvyDE things are probably even worse as nobody of us uses Eclipse, either. But then again I've not managed to create an Eclipse update site for the last two Ivy releases so maybe nobody is using IvyDE anymore anyway. At least *I* don't see myself digging deeper into the Ivy code base in order to fix non-critical bugs. And even for the critical ones I feel we are not doing an adequate job. To me it looks as if Ivy and in particilar IvyDE are no longer really supported by the Ant project. TBH I'm not quite sure what to do about this. Even if people stepped up to maintain Ivy, the rest of the Ant devs would probably be unable to verify the changes they want to make. At least I certainly am not willing to review bigger PRs/patches to a code base I don't understand well. Personally I believe we should send IvyDE to the Apache Attic immediately, and this likely should be the destination for Ivy sooner or later as well. In the case of Ivy we know there are people who depend on it (hi, Groovy folks) so maybe we should give a date in the future until which we are providing security bug fixes to give people time to move off. There may be the need for a dependency management system inside of Ant, I'm not sure. If so, then this should be driven by people who feel the actual need IMO. There may already be alternatives to Ivy I am not aware of. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [**EXTERNAL**] RE: Future of Ivy and IvyDE
I'd like to second the first two opinions regarding Ant and Ivy. I can't say that I'm very familiar with Maven, but from what I know, Ivy is way superior to it (in my opinion, of course). At the expense of being more complex, it is terser, customizable and, generally, more capable. I've used it professionally and personally and am really hopeful it would not be sacked. I also use IveDE (yes, Eclipse!) and like it quite a lot. That said, if Ivy continues to live on, it will be pretty simple to use just it (no IvyDE). Sadly, to paraphrase the old adage - fashion over function... Regards, Vladimir On Tue, Aug 22, 2023 at 10:29 AM D'Anjou, Martin wrote: > Hi, > > I'd like to say that we're seriously considering migrating our dependency > management from Gradle to Ivy because of the lack of branch support in > Gradle's dependency management, and because we can't find a way to modify > Gradle's dependency management without also changing its core. We can > create a custom resolver in Ivy that supports our branch scenarios, and > apparently without touching its core. > > So I hope Ivy has a future. > > Martin > > -Original Message- > From: s.an...@infass.com.INVALID > Sent: Tuesday, August 22, 2023 12:45 PM > To: ivy-u...@ant.apache.org; dev@ant.apache.org > Cc: u...@ant.apache.org > Subject: [**EXTERNAL**] RE: Future of Ivy and IvyDE > > Hi, > > I can't really discuss how many developers use Ivy and how it is difficult > to maintain this project if there is not enough maintainers... > > But I can give hints about our usage in our companies: > * We love "ant", it's for us a clear language syntax that can achieve our > build processes like we want (and we have a good expertise about it) > * We had need to move on more modern way to handle dependencies > * We use ivy for that > * We have a tight integration inside our custom CI chain and in our IDE. > We didn't use IvyDE > > For sure, we know that "ant" is an older daddy inside the building tools > area > > Ivy have their caveats but we are able to integrate it nicely inside our > build chain. > We can have 2 orientations: > * Move to another build tool and don't use anymore ant > * Move to another dependency tool usable by ant (at this date, I'm not > sure, we have real alternative to Ivy) > * Continue to use Ant + Ivy as long as we can > > What I can say : we appreciate the couple of ant + ivy and if possible we > would love to continue to use them ! > > Sébastien. > > > > -Message d'origine- > De : Stefan Bodewig Envoyé : mardi 22 août 2023 > 18:02 À : dev@ant.apache.org Cc : u...@ant.apache.org; > ivy-u...@ant.apache.org Objet : Future of Ivy and IvyDE > > Hi all > > before I get to the actual content of this mail: > > * I'm cross-posting to three lists but I ask you to keep responses to > dev@ant only (and join the list if necessary) if you want to respond. > > * what I write is my personal opinion and not shared by the PMC as a > whole. The people on the PMC know I'd be writing a mail like this > sooner or later, though. > > * this is a discussion, not a vote. > > phew > > I'm not quite sure what I hope to achieve with this email, but I'd like to > share my thoughts - and raise the awareness of an elephant being in the > room. > > Over the past year we've had three security vulnerabilities discovered in > Ivy and it took us much too long to get them fixed. The reason for this is > there are no people left around who are familiar with the Ivy code base. > Most of the remaining developers around Ant are not even users of Ivy - I > know I am not and have never been. > > When it comes to IvyDE things are probably even worse as nobody of us uses > Eclipse, either. But then again I've not managed to create an Eclipse > update site for the last two Ivy releases so maybe nobody is using IvyDE > anymore anyway. > > At least *I* don't see myself digging deeper into the Ivy code base in > order to fix non-critical bugs. And even for the critical ones I feel we > are not doing an adequate job. To me it looks as if Ivy and in particilar > IvyDE are no longer really supported by the Ant project. > > TBH I'm not quite sure what to do about this. Even if people stepped up to > maintain Ivy, the rest of the Ant devs would probably be unable to verify > the changes they want to make. At least I certainly am not willing to > review bigger PRs/patches to a code base I don't understand well. > > Personally I believe we should send IvyDE to the Apache Attic immediately, > and this likely should be the destination for Ivy sooner or later as well. > In the case of Ivy we know there are people who depend on it (hi, Groovy > folks) so maybe we should give a date in the future until which we are > providing security bug fixes to give people time to move off. > > There may be the need for a dependency management system inside of Ant, > I'm not sure. If so, then this should be driven by people who feel the > actual need IMO. There may already be
Re: Future of Ivy and IvyDE
Hi all:
IMO, it would be a shame to lose Ivy as a much simpler alternative to Maven.
It works well and I think there is very much still room for a dependency
management tool that focuses on just that and not all the other things
that Maven does. I am thankful for your work on it, Stefan.
I can confirm that in the not very distant past there were multiple
people (including myself) who submitted pull requests for Ivy to both
make improvements as well as address bugs. They were left to rot for far
too long. It was frustrating to me that even a very simple patch
required both a debate on its utility and then navigating pedantries on
the coding approach before then taking nearly two years to get merged
and incorporated into a release. I feel that people who were trying to
get started maintaining Ivy, like myself, were simply put off by
unresponsive committers. Absolutely I understand there is a lacking in
capacity of people to verify changes but the situation, at least with
me, felt like simple gatekeeping.
For users of Eclipse IDE, IvyDE is wonderful and works as advertised.
I've been using it successfully since 2010 or so and pretty much
considered it "finished". But given the lack of development on it over
the years though, I am actually surprised it's still functional in
current IDE releases and I've wondered when it will finally break. I
have looked at the IvyDE code in the past, it's not that much really,
and at one point I tried (rather half-heartedly) to get an IDE
development environment prepared and then just gave up...mostly because
developing for Eclipse was too much of a big moving target for me, and
also the code abstractions in place for such a modular and flexible IDE
were tough for me to follow concretely.
I would really appreciate an update site for Ivy though as I've wondered
how I can upgrade my IDE, easily, to use Ivy 2.5.{1,2}.
It would be great if the existing update site for IvyDE [0] could at
least be updated for the artifacts we have. There would very probably be
no issues with IvyDE 2.2.0 working just fine using the latest Ivy
release version.
I agree that it seems Ivy and IvyDE are not being supported adequately
by the Ant project.
And I wish that weren't the case because they are excellent tools.
Not sure what I hope to achieve either with my message above, but I felt
compelled to respond as a user who has appreciated Ivy and IvyDE for a
long time. Maybe I'm the only one left!
Jason
[0] |https://downloads.apache.org/ant/ivyde/updatesite/
RE: [**EXTERNAL**] RE: Future of Ivy and IvyDE
Hi, I'd like to say that we're seriously considering migrating our dependency management from Gradle to Ivy because of the lack of branch support in Gradle's dependency management, and because we can't find a way to modify Gradle's dependency management without also changing its core. We can create a custom resolver in Ivy that supports our branch scenarios, and apparently without touching its core. So I hope Ivy has a future. Martin -Original Message- From: s.an...@infass.com.INVALID Sent: Tuesday, August 22, 2023 12:45 PM To: ivy-u...@ant.apache.org; dev@ant.apache.org Cc: u...@ant.apache.org Subject: [**EXTERNAL**] RE: Future of Ivy and IvyDE Hi, I can't really discuss how many developers use Ivy and how it is difficult to maintain this project if there is not enough maintainers... But I can give hints about our usage in our companies: * We love "ant", it's for us a clear language syntax that can achieve our build processes like we want (and we have a good expertise about it) * We had need to move on more modern way to handle dependencies * We use ivy for that * We have a tight integration inside our custom CI chain and in our IDE. We didn't use IvyDE For sure, we know that "ant" is an older daddy inside the building tools area Ivy have their caveats but we are able to integrate it nicely inside our build chain. We can have 2 orientations: * Move to another build tool and don't use anymore ant * Move to another dependency tool usable by ant (at this date, I'm not sure, we have real alternative to Ivy) * Continue to use Ant + Ivy as long as we can What I can say : we appreciate the couple of ant + ivy and if possible we would love to continue to use them ! Sébastien. -Message d'origine- De : Stefan Bodewig Envoyé : mardi 22 août 2023 18:02 À : dev@ant.apache.org Cc : u...@ant.apache.org; ivy-u...@ant.apache.org Objet : Future of Ivy and IvyDE Hi all before I get to the actual content of this mail: * I'm cross-posting to three lists but I ask you to keep responses to dev@ant only (and join the list if necessary) if you want to respond. * what I write is my personal opinion and not shared by the PMC as a whole. The people on the PMC know I'd be writing a mail like this sooner or later, though. * this is a discussion, not a vote. phew I'm not quite sure what I hope to achieve with this email, but I'd like to share my thoughts - and raise the awareness of an elephant being in the room. Over the past year we've had three security vulnerabilities discovered in Ivy and it took us much too long to get them fixed. The reason for this is there are no people left around who are familiar with the Ivy code base. Most of the remaining developers around Ant are not even users of Ivy - I know I am not and have never been. When it comes to IvyDE things are probably even worse as nobody of us uses Eclipse, either. But then again I've not managed to create an Eclipse update site for the last two Ivy releases so maybe nobody is using IvyDE anymore anyway. At least *I* don't see myself digging deeper into the Ivy code base in order to fix non-critical bugs. And even for the critical ones I feel we are not doing an adequate job. To me it looks as if Ivy and in particilar IvyDE are no longer really supported by the Ant project. TBH I'm not quite sure what to do about this. Even if people stepped up to maintain Ivy, the rest of the Ant devs would probably be unable to verify the changes they want to make. At least I certainly am not willing to review bigger PRs/patches to a code base I don't understand well. Personally I believe we should send IvyDE to the Apache Attic immediately, and this likely should be the destination for Ivy sooner or later as well. In the case of Ivy we know there are people who depend on it (hi, Groovy folks) so maybe we should give a date in the future until which we are providing security bug fixes to give people time to move off. There may be the need for a dependency management system inside of Ant, I'm not sure. If so, then this should be driven by people who feel the actual need IMO. There may already be alternatives to Ivy I am not aware of. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
RE: Future of Ivy and IvyDE
Hi, I can't really discuss how many developers use Ivy and how it is difficult to maintain this project if there is not enough maintainers... But I can give hints about our usage in our companies: * We love "ant", it's for us a clear language syntax that can achieve our build processes like we want (and we have a good expertise about it) * We had need to move on more modern way to handle dependencies * We use ivy for that * We have a tight integration inside our custom CI chain and in our IDE. We didn't use IvyDE For sure, we know that "ant" is an older daddy inside the building tools area Ivy have their caveats but we are able to integrate it nicely inside our build chain. We can have 2 orientations: * Move to another build tool and dont use anymore ant * Move to another dependency tool usable by ant (at this date, I'm not sure, we have real alternative to Ivy) * Continue to use Ant + Ivy as long as we can What I can say : we appreciate the couple of ant + ivy and if possible we would love to continue to use them ! Sébastien. -Message d'origine- De : Stefan Bodewig Envoyé : mardi 22 août 2023 18:02 À : dev@ant.apache.org Cc : u...@ant.apache.org; ivy-u...@ant.apache.org Objet : Future of Ivy and IvyDE Hi all before I get to the actual content of this mail: * I'm cross-posting to three lists but I ask you to keep responses to dev@ant only (and join the list if necessary) if you want to respond. * what I write is my personal opinion and not shared by the PMC as a whole. The people on the PMC know I'd be writing a mail like this sooner or later, though. * this is a discussion, not a vote. phew I'm not quite sure what I hope to achieve with this email, but I'd like to share my thoughts - and raise the awareness of an elephant being in the room. Over the past year we've had three security vulnerabilities discovered in Ivy and it took us much too long to get them fixed. The reason for this is there are no people left around who are familiar with the Ivy code base. Most of the remaining developers around Ant are not even users of Ivy - I know I am not and have never been. When it comes to IvyDE things are probably even worse as nobody of us uses Eclipse, either. But then again I've not managed to create an Eclipse update site for the last two Ivy releases so maybe nobody is using IvyDE anymore anyway. At least *I* don't see myself digging deeper into the Ivy code base in order to fix non-critical bugs. And even for the critical ones I feel we are not doing an adequate job. To me it looks as if Ivy and in particilar IvyDE are no longer really supported by the Ant project. TBH I'm not quite sure what to do about this. Even if people stepped up to maintain Ivy, the rest of the Ant devs would probably be unable to verify the changes they want to make. At least I certainly am not willing to review bigger PRs/patches to a code base I don't understand well. Personally I believe we should send IvyDE to the Apache Attic immediately, and this likely should be the destination for Ivy sooner or later as well. In the case of Ivy we know there are people who depend on it (hi, Groovy folks) so maybe we should give a date in the future until which we are providing security bug fixes to give people time to move off. There may be the need for a dependency management system inside of Ant, I'm not sure. If so, then this should be driven by people who feel the actual need IMO. There may already be alternatives to Ivy I am not aware of. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Future of Ivy and IvyDE
Hi all before I get to the actual content of this mail: * I'm cross-posting to three lists but I ask you to keep responses to dev@ant only (and join the list if necessary) if you want to respond. * what I write is my personal opinion and not shared by the PMC as a whole. The people on the PMC know I'd be writing a mail like this sooner or later, though. * this is a discussion, not a vote. phew I'm not quite sure what I hope to achieve with this email, but I'd like to share my thoughts - and raise the awareness of an elephant being in the room. Over the past year we've had three security vulnerabilities discovered in Ivy and it took us much too long to get them fixed. The reason for this is there are no people left around who are familiar with the Ivy code base. Most of the remaining developers around Ant are not even users of Ivy - I know I am not and have never been. When it comes to IvyDE things are probably even worse as nobody of us uses Eclipse, either. But then again I've not managed to create an Eclipse update site for the last two Ivy releases so maybe nobody is using IvyDE anymore anyway. At least *I* don't see myself digging deeper into the Ivy code base in order to fix non-critical bugs. And even for the critical ones I feel we are not doing an adequate job. To me it looks as if Ivy and in particilar IvyDE are no longer really supported by the Ant project. TBH I'm not quite sure what to do about this. Even if people stepped up to maintain Ivy, the rest of the Ant devs would probably be unable to verify the changes they want to make. At least I certainly am not willing to review bigger PRs/patches to a code base I don't understand well. Personally I believe we should send IvyDE to the Apache Attic immediately, and this likely should be the destination for Ivy sooner or later as well. In the case of Ivy we know there are people who depend on it (hi, Groovy folks) so maybe we should give a date in the future until which we are providing security bug fixes to give people time to move off. There may be the need for a dependency management system inside of Ant, I'm not sure. If so, then this should be driven by people who feel the actual need IMO. There may already be alternatives to Ivy I am not aware of. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
JDK 21 Release Candidates & JVM Language Summit
Greetings! JDK 21 is now in the Release Candidate Phase so everything is on track for the Java 21 GA release on September 19th! If you haven't done so, please start testing your project(s) using JDK 22 Early-Access builds and let us know the results. In other news, the JVM Language Summit took place a few days ago in Santa Clara (California). During this unique gathering of Java architects and OpenJDK developers, key updates were shared and discussed, ex. where Valhalla stands today, the new Class-File API, an update on Leyden and Valhalla, Project Panama, the challenges of Virtual Threads, continuation internals, etc. We have started to publish the JVMLS 2023 videos so make sure to keep an eye on this evolving JVMLS playlist [1] to understand where the Java platform is heading to. ## JDK 21 Early-Access Builds Per the JDK 21 schedule [2], we are now in the Release-Candidate Phase. The overall feature set [3] is frozen, no further JEPs will be targeted to this release. ### JEPs integrated to JDK 21: - 430: String Templates (Preview) - 431: Sequenced Collections - 439: Generational ZGC - 440: Record Patterns - 441: Pattern Matching for switch - 442: Foreign Function & Memory API (3rd Preview) - 443: Unnamed Patterns and Variables (Preview) - 444: Virtual Threads - 445: Unnamed Classes and Instance Main Methods (Preview) - 446: Scoped Values (Preview) - 448: Vector API (6th Incubator) - 449: Deprecate the Windows 32-bit x86 Port for Removal - 451: Prepare to Disallow the Dynamic Loading of Agents - 452: Key Encapsulation Mechanism API - 453: Structured Concurrency (Preview) The first JDK 21 Release Candidate builds (builds 35) are available [4]. Those builds are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes [5] and the Javadocs [6] are also available. [1] https://www.youtube.com/playlist?list=PLX8CzqL3ArzW90jKUCf4H6xCKpStxsOzp [2] https://openjdk.org/projects/jdk/21/#Schedule [3] https://openjdk.org/projects/jdk/21/#Features [4] https://jdk.java.net/21/ [5] https://jdk.java.net/21/release-notes [6] https://download.java.net/java/early_access/jdk21/docs/api/ ## JDK 22 Early-Access Builds The latest Early-Access builds 11 are available [7], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [8]. ### Changes in recent JDK 22 builds (b8-b11) that may be of interest: Note that this is only a curated list of changes, make sure to check [9] for additional changes. - JDK-8314209: Wrong @since tag for RandomGenerator::equiDoubles [Reported by JaCoCo] - JDK-8312489: Increase Default Value of the System Property jdk.jar.maxSignatureFileSize - JDK-8312433: HttpClient request fails due to connection being considered … - JDK-8313307: java/util/Formatter/Padding.java fails on some Locales - JDK-8312821: Javac accepts char literal as template - JDK-8313251: Add NativeLibraryLoad event - JDK-8313809: String template fails with java.lang.StringIndexOutOfBoundsE… - JDK-8312984: javac may crash on a record pattern with too few components - JDK-8310033: Clarify return value of Java Time compareTo methods - JDK-8302017: Allocate BadPaddingException only if it will be thrown - JDK-8310913: Move ReferencedKeyMap to jdk.internal so it may be shared - JDK-8313251: Add NativeLibraryLoad event to provide more detail about shared lib/dll loads - JDK-8311653: Modify -XshowSettings launcher behavior - JDK-8306441: Two phase segmented heap dump - JDK-8311981: JVM May Hang When Using Generational ZGC if a VM Handshake Stalls on Memory - JDK-8308850: Change JVM options with small ranges that get -Wconversion warnings to 32 bits [7] https://jdk.java.net/22/ [8] https://jdk.java.net/22/release-notes [9] https://github.com/openjdk/jdk/compare/jdk-22%2B8...jdk-22%2B11 ## JavaFX 21 & 22 Early-Access Builds These are early-access builds of the JavaFX Runtime, built from openjdk/jfx [10]. They allow JavaFX application developers to build and test their applications with JavaFX 21 or 22 on the latest JDK. The latest builds 29 (2023/8/7) of JavaFX 21 are now available [11]. The early-access builds 5 (2023/8/18) of the JavaFX 22 Runtime which is designed to work with JDK 22 are also available [12]. These early-access builds are provided under the GNU General Public License, version 2, with the Classpath Exception. Please send the feedback on the openjfx-dev mailing list [13]. [10] https://github.com/openjdk/jfx [11] https://jdk.java.net/javafx21/ [12] https://jdk.java.net/javafx22/ [13] http://mail.openjdk.org/mailman/listinfo/openjfx-dev ## Topics of Interest: JDK 21: G1/Parallel/Serial GC improvements https://tschatzl.github.io/2023/08/04/jdk21-g1-parallel-gc-changes.html To Java 21 and Beyond! https://inside.java/2023/08/08/to-java21-and-beyond/ Strengthen your Java App's Defenses with Key Encapsulation Mechanism API https://inside.java/2023/08/03/newscast-54/ JVMLS
