2017-11-04 18:17 GMT+01:00 Stephen Connolly <stephen.alan.conno...@gmail.com>: > On Sat 4 Nov 2017 at 17:11, Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > >> My wishlist as a user would be: >> >> - incremental build (based on scm is fine) >> - some built in scripting (groovy based?) > > > I have a worry for groovy with Java 9+
Understand, here is the long version of that wish: 1. java -> groovy is very doable (compared to other language) so it is the natural language for maven IMHO 2. groovy will have to support Java 9 - to be honest I worry as much for a plain java lib than for groovy so guess it is 1-1 3. I'm happy to have a java scripting alternative (src/build/java) which is not available outside the scope of a plugin (= no inherited in compile or test scopes) > > And scripting is the path to the dark side of imperative builds... but > proposals welcome This is true but this is also mandatory today. There is a small alternative to that and I would be as happy if maven can do it: support mojo from the reactor (ie having a project with this layout: parent/[module1, my-maven-plugin]). If this works then no need of scripting but today you must release the mojo before using it in your build which imposes to use scripting. > > >> - plugin sorting from the pom (current rules are deterministic but too hard >> to use so defining a dependency between two executions in the same phase >> would be very handy - depends-on tag?) >> >> As a plugin developper: >> >> - programmatic component lookup api (it is deprecated at the moment) >> - ability to contribute dependencies for next plugins/phases >> (resolvedArtifacts) >> >> Le 4 nov. 2017 17:03, "Stephen Connolly" <stephen.alan.conno...@gmail.com> >> a écrit : >> >> > On 4 November 2017 at 07:30, Hervé BOUTEMY <herve.bout...@free.fr> >> wrote: >> > >> > > Le samedi 4 novembre 2017, 14:43:46 CET John Patrick a écrit : >> > > > I've got a few updates I feel would be useful for the next major >> > > version; >> > > > >> > > > 1) Packaging type generic 'archive', or specific zip or tar.gz >> > > > - maybe a user property to enable zip and/or tar.gz >> > > > >> > > > 2) Packaging type generic 'application', or specific rpm or deb >> > > > - in future could be extended for windows installers too >> > > > >> > > > Over the past 6 years I've mainly created jar, war or ear, but for >> > > > deployment the standard is bundle it up into a tar.gz or zip, along >> > > > with the ansible scripts or custom scripts. So I usually use pom >> > > > packaging then adding assembly plugin, just feels strange doing that >> > > > all the time and it might make it more simpler for everyone. >> > > do you have some demos of such packagings? >> > > >> > >> > This feels like plugin level functionality. I am unclear how this needs >> > core changes. Could you provide details where you feel we need to modify >> > core for this (or is it you want to be able to fetch some artifacts from >> > within the zip, iow a zip with the other artifacts embedded and we "reach >> > in"? >> > >> > >> > > >> > > > >> > > > 3) Checksum, switch to SHA3, drop md5 and sha1. If we care about >> > > > security, we should keep up to date with what is considered secure >> > > > still. >> > > -1 >> > > checksums are checksums, not security >> > > if you want security, don't look at checksums but at signatures >> > > >> > > This makes me think that we should find a way to show security (with >> > these >> > > signatures): I don't know precisely how, but that would definitely be >> > > useful >> > > >> > > > >> > > > 3) Debian style repo management. Instead of having a massive bucket >> of >> > > > artefacts, start having repo's either based upon java class version, >> > > > or maven major release version. Also split more than just release and >> > > > snapshot, maybe core, plugins, general... >> > > > >> > > > Not sure exactly the best solution, but as maven central has stuff >> > > > going back years and years. How much of the old stuff will be used >> for >> > > > new projects going forward. >> > > what's the objective? >> > > with Linux distributions, there are compatibility issues that require >> > > different artifacts, and an objective to keep distro on one CD/DVD >> > > But Java and central don't have such considerations >> > > >> > > > >> > > > Anyway, those are some of my thoughts, if their is a more formal way >> > > > of suggesting them let me know and I'll be happy to raise them >> > > > separately for consideration and maybe also do some pull requests for >> > > > them. >> > > I think the packaging ideas deserve some demos to see if something can >> be >> > > made >> > > generic enough >> > > >> > > Regards, >> > > >> > > Hervé >> > > >> > > > >> > > > John >> > > > >> > > > On 4 November 2017 at 13:18, Paul Hammant <p...@hammant.org> wrote: >> > > > >> > *3. More pluggable dependency resolver:* >> > > > >> >> > > > >> I am willing to let this be optional scope for now. May be yanked >> if >> > > too >> > > > >> risky or not ready in time >> > > > > >> > > > > I don't see how you can even make it optional without a pom >> specified >> > > way >> > > > > of saying "not maven central, this way/place instead" >> > > > >> > > > --------------------------------------------------------------------- >> > > > 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 >> > > >> > > >> > >> > -- > Sent from my phone --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
