maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Maven 4.0.0
Date Sat, 04 Nov 2017 17:17:23 GMT
On Sat 4 Nov 2017 at 17:11, Romain Manni-Bucau <rmannibucau@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.connolly@gmail.com>
> a écrit :
>
> > On 4 November 2017 at 07:30, Hervé BOUTEMY <herve.boutemy@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 <paul@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-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
-- 
Sent from my phone

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message