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+ And scripting is the path to the dark side of imperative builds... but proposals welcome > - 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
