- 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"
<[email protected]>
a écrit :
> On 4 November 2017 at 07:30, Hervé BOUTEMY <[email protected]>
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 <[email protected]>
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: [email protected]
> > > For additional commands, e-mail: [email protected]
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
>
