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 16:03:49 GMT
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
>
>

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