My wishlist as a user would be: - incremental build (based on scm is fine) - some built in scripting (groovy based?) - 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 > > > > >
