Re: Maven intern projects
I think the next step is to create a simple proposal document we can discuss and iterate on. Looks like https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=5964567 might be the right place to do this? On Mon, Apr 13, 2020 at 1:43 PM Markus KARG wrote: > > What users finally expect is to have multirelease JAR building being a Maven > native functionality. This means, it should be as-easy-as putting code in > these folders: > > src/main/java/9/ > src/main/java/ > src/main/java/11/ > > then perform > > mvn clean package > > to get a multi-release jar -- without *any* special switches, config, or > POM.xml tweaking, and *all* maven-*-plugins will perform the necessary steps > on their own (e. g. compiler runs multiple times as the compiler plugins > knows this is needed when it sees /java/number/ folders). > > -Markus > > -Ursprüngliche Nachricht- > Von: Elliotte Rusty Harold [mailto:elh...@ibiblio.org] > Gesendet: Montag, 13. April 2020 19:02 > An: Maven Developers List > Betreff: Re: Maven intern projects > > On Mon, Apr 13, 2020 at 11:50 AM Robert Scholte wrote: > > > > Just to be clear: Multirelease jars is a JDK 9+ feature. With Maven it is > > possible to make them, to test them and to run them. But they are pretty > > hard to maintain. > > So I would prefer NOT to try make Multirelease Jars of our libraries, > > unless there's a very good reason. > > Yes, that's what I was thinking. Have we documented anywhere how to > make multirelease jars with Maven? My impression from googling was > that this doesn't work yet, but I guess that's not true? > > What improvements could we make to improve the workflow for multimodule > builds? > > > If there is one thing that should be solved, but requires a lot of time, it > > is support of ServicesLoaders > > https://issues.apache.org/jira/browse/MNG-6275 > > > > Thanks. I'll look at that. > > I did a review pass through the issue tracker. So far these are the > ones I've found that look like they might make parts of plausible > intern level projects: > > https://issues.apache.org/jira/browse/MDEP-644?jql=labels%20%3D%20intern > > -- > Elliotte Rusty Harold > elh...@ibiblio.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 > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: Maven intern projects
> -Original Message- > From: Markus KARG > Sent: Monday, April 13, 2020 1:44 PM > > What users finally expect is to have multirelease JAR building being a Maven > native > functionality. This means, it should be as-easy-as putting code in these > folders: > > src/main/java/9/ > src/main/java/ > src/main/java/11/ JEP 238 does not require any specific source folder organization. Please do not step on the contents of the /java/ folder. You can accomplish the same with /java/ | /java.9/ | /java.11/ . Doing so will break many, many assumptions those have made in many, many existing packages. In fact, for those already having large multi release source trees, having POM properties to specify the java version source folders would be handy. > > then perform > > mvn clean package > > to get a multi-release jar -- without *any* special switches, config, or > POM.xml tweaking, > and *all* maven-*-plugins will perform the necessary steps on their own (e. > g. compiler > runs multiple times as the compiler plugins knows this is needed when it sees > /java/number/ folders). I concur, strongly, otherwise. > > -Markus -Jason - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven intern projects
On Mon, Apr 13, 2020 at 11:50 AM Robert Scholte wrote: > > Just to be clear: Multirelease jars is a JDK 9+ feature. With Maven it is > possible to make them, to test them and to run them. But they are pretty hard > to maintain. > So I would prefer NOT to try make Multirelease Jars of our libraries, unless > there's a very good reason. Yes, that's what I was thinking. Have we documented anywhere how to make multirelease jars with Maven? My impression from googling was that this doesn't work yet, but I guess that's not true? What improvements could we make to improve the workflow for multimodule builds? > If there is one thing that should be solved, but requires a lot of time, it > is support of ServicesLoaders > https://issues.apache.org/jira/browse/MNG-6275 > Thanks. I'll look at that. I did a review pass through the issue tracker. So far these are the ones I've found that look like they might make parts of plausible intern level projects: https://issues.apache.org/jira/browse/MDEP-644?jql=labels%20%3D%20intern -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven intern projects
Just to be clear: Multirelease jars is a JDK 9+ feature. With Maven it is possible to make them, to test them and to run them. But they are pretty hard to maintain. So I would prefer NOT to try make Multirelease Jars of our libraries, unless there's a very good reason. The next version of Maven will require Java 8, so that already makes a lot of improvements available. If there is one thing that should be solved, but requires a lot of time, it is support of ServicesLoaders https://issues.apache.org/jira/browse/MNG-6275 especially with the modular system more libraries have defined services and it would be great if plugins could use those via the serviceloader factory or via guice. I should be able to find other interesting issues. Robert On 13-4-2020 16:41:40, Elliotte Rusty Harold wrote: On Fri, Apr 10, 2020 at 1:17 PM Markus KARG wrote: > Having said this, it would be a really great feature to get an easy-to-use > solution for creating multi-version-JARs. > This is probably the best idea so far. (Google specifically does not want interns working on refactoring or maintenance work. New feature development only.) Looking around I found this which appears to be a few notes on the subject, but not more: https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html So I gather we don't have any multirelease support in maven yet, and I don't think any is under way. That might be tractable for an intern team provided they started with a clear design of what the input and the output look like. Output is defined by the Java specs. For input, we'd need to understand the source layout for multi-release jars. E.g. src main java java9 java14 or what exactly. We would also need to know how the pom.xml is going to change to support this. If the maintainers think we can develop, agree on, and commit to a specification for multirelease support in Maven within the next month, then this could work. Does that sound useful and feasible? -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven intern projects
On Fri, Apr 10, 2020 at 1:17 PM Markus KARG wrote: > Having said this, it would be a really great feature to get an easy-to-use > solution for creating multi-version-JARs. > This is probably the best idea so far. (Google specifically does not want interns working on refactoring or maintenance work. New feature development only.) Looking around I found this which appears to be a few notes on the subject, but not more: https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html So I gather we don't have any multirelease support in maven yet, and I don't think any is under way. That might be tractable for an intern team provided they started with a clear design of what the input and the output look like. Output is defined by the Java specs. For input, we'd need to understand the source layout for multi-release jars. E.g. src main java java9 java14 or what exactly. We would also need to know how the pom.xml is going to change to support this. If the maintainers think we can develop, agree on, and commit to a specification for multirelease support in Maven within the next month, then this could work. Does that sound useful and feasible? -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven intern projects
Am 2020-04-10 um 16:12 schrieb Elliotte Rusty Harold: Due to external developments, I am suddenly able to recruit, fund, and manage as many as five interns, probably undergraduates, to work on open source projects such as Maven and its plugins for 12 weeks this summer. My management chain has a particular interest in reproducible builds, so if there's work to be done on that, it would be a really easy sell. However I can probably get approval for any useful project that can plausibly be accomplished by a junior/senior CS major in 12 weeks. We do like these to be feature projects, not simply refactoring or maintenance. If anyone has a good idea, or would simply like to point me to particular issues in Jira that sound like good projects, let me know and I can start the bureaucratic wheels turning on my end. As long as the feature being proposed already has general agreement that it's a good idea, I'll be able to do pretty much all the legwork for managing the project(s). It shouldn't require any noticeable time from other maintainers. I have at least three points one can work on: * Review, upgrade, skim Doxia for Velocity 2.2 along with other reporting modules. The code base is old. * We have a lot of code overlap with Codehaus and Apache Commons. Stuff implemented many many times. The goal would be to analyze a duplicate spots and see how they can be reduced/consolidated. Karl and me have already talked about. You should contact him about this. * There is some stuff one can work on Wagon, but I would keep this if no one can fill a remaining void. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven intern projects
nice! on Reproducible Builds for Maven, we're pretty finished: - few plugins still need to support reproducible output: m-shade-p in vote, remains m-war-p, Felix bundle:bundle - on making our sub-projects builds reproducible [1], only 2 sub-project are not yet finished, waiting for previous plugins releases I would have loved to have such help one year ago :) Something ambitious could be the important next step = report for any project if his dependencies are reproducible or not: reproducible-central [2] is part of a proof of concept for that, that requires much improvements. This will require to define what trust model to apply: in reproducible-central, I personally commit content, provide a recipe that I tell you I applied: should you trust me? did I not cheat sometimes, for personal reasons? am I not the only one on the planet being able to reproduce? This topic could be really nice, but not easy, solutions are not precisely defined. And it goes beyond Maven but to any build tool. Helping any project that uses Maven (or other if possible) to make their build reproducible could be useful to have more reproducible JVM artifacts in the wild. Another more oriented topic would be to work on maven-shade-plugin: while working on reproducibility, this plugin seems to require some love Regards, Hervé [1] https://github.com/jvm-repo-rebuild/reproducible-maven-HEAD [2] https://github.com/jvm-repo-rebuild/reproducible-central Le vendredi 10 avril 2020, 16:12:45 CEST Elliotte Rusty Harold a écrit : > Due to external developments, I am suddenly able to recruit, fund, and > manage as many as five interns, probably undergraduates, to work on > open source projects such as Maven and its plugins for 12 weeks this > summer. > > My management chain has a particular interest in reproducible builds, > so if there's work to be done on that, it would be a really easy sell. > However I can probably get approval for any useful project that can > plausibly be accomplished by a junior/senior CS major in 12 weeks. We > do like these to be feature projects, not simply refactoring or > maintenance. > > If anyone has a good idea, or would simply like to point me to > particular issues in Jira that sound like good projects, let me know > and I can start the bureaucratic wheels turning on my end. As long as > the feature being proposed already has general agreement that it's a > good idea, I'll be able to do pretty much all the legwork for managing > the project(s). It shouldn't require any noticeable time from other > maintainers. > > Let me know if you have any ideas. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven intern projects
My wishlist: Maven Central web (https://search.maven.org/) to show the health of artifacts. For example, the health includes how much their dependencies are up-to-date, presence of license element in pom.xml, and so on. I recently found pub.dev (Dart/Flutter repo system) has such tab for every package: Example https://pub.dev/packages/tuple#-analysis-tab- The health page encourages library maintainers to update their libraries in a timely and recommended manner. On Fri, Apr 10, 2020 at 10:13 AM Elliotte Rusty Harold wrote: > Due to external developments, I am suddenly able to recruit, fund, and > manage as many as five interns, probably undergraduates, to work on > open source projects such as Maven and its plugins for 12 weeks this > summer. > > My management chain has a particular interest in reproducible builds, > so if there's work to be done on that, it would be a really easy sell. > However I can probably get approval for any useful project that can > plausibly be accomplished by a junior/senior CS major in 12 weeks. We > do like these to be feature projects, not simply refactoring or > maintenance. > > If anyone has a good idea, or would simply like to point me to > particular issues in Jira that sound like good projects, let me know > and I can start the bureaucratic wheels turning on my end. As long as > the feature being proposed already has general agreement that it's a > good idea, I'll be able to do pretty much all the legwork for managing > the project(s). It shouldn't require any noticeable time from other > maintainers. > > Let me know if you have any ideas. > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Regards, Tomo -- Regards, Tomo
