Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
MIME-Version: 1.0
In-Reply-To: <CA+nPnMzUP+A=2juJEXpvu2soAeG=s0QtcwWDs00hJ4F5rmTTfg@mail.gmail.com>
References: <CA+nPnMwEH9Z2myp71uaSrdcyLJRFrE-Vrt20191rd01h+Ufhjw@mail.gmail.com>
 <CA+298Ujp6dZLV1yNqbPBc4fWBDzozExcCm7F56Cn=E-9FaDa8A@mail.gmail.com>
 <CAH9u10ntmFBZcTh9YvAbEKgDuJN9Xd5xuepO4fiR5BKRquZBPg@mail.gmail.com>
 <1549856.He1MSBx3US@giga> <CA+nPnMzYGp2VEHTY0UXNSxaVvfCToZ+tmQDVcPzQVG6zbNsoHg@mail.gmail.com>
 <CACLE=7OtUW9Mmi5k8QQkfP3GbBguXJMFLrYVXqGy01bt_D4dYw@mail.gmail.com> <CA+nPnMzUP+A=2juJEXpvu2soAeG=s0QtcwWDs00hJ4F5rmTTfg@mail.gmail.com>
From: Romain Manni-Bucau <rmannibucau@gmail.com>
Date: Sat, 4 Nov 2017 18:34:14 +0100
Message-ID: <CACLE=7MYH5TywEZCDZhPQ=2Hbuan1ZLx9zrQuxx8PQ-VQ2GzXg@mail.gmail.com>
Subject: Re: Maven 4.0.0
To: Maven Developers List <dev@maven.apache.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
archived-at: Sat, 04 Nov 2017 17:34:46 -0000

2017-11-04 18:17 GMT+01:00 Stephen Connolly <stephen.alan.connolly@gmail.co=
m>:
> 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+

Understand, here is the long version of that wish:

1. java -> groovy is very doable (compared to other language) so it is
the natural language for maven IMHO
2. groovy will have to support Java 9 - to be honest I worry as much
for a plain java lib than for groovy so guess it is 1-1
3. I'm happy to have a java scripting alternative (src/build/java)
which is not available outside the scope of a plugin (=3D no inherited
in compile or test scopes)

>
> And scripting is the path to the dark side of imperative builds... but
> proposals welcome

This is true but this is also mandatory today. There is a small
alternative to that and I would be as happy if maven can do it:
support mojo from the reactor (ie having a project with this layout:
parent/[module1, my-maven-plugin]). If this works then no need of
scripting
but today you must release the mojo before using it in your build
which imposes to use scripting.

>
>
>> - plugin sorting from the pom (current rules are deterministic but too h=
ard
>> 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.co=
m>
>> a =C3=A9crit :
>>
>> > On 4 November 2017 at 07:30, Herv=C3=A9 BOUTEMY <herve.boutemy@free.fr=
>
>> wrote:
>> >
>> > > Le samedi 4 novembre 2017, 14:43:46 CET John Patrick a =C3=A9crit :
>> > > > 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, alon=
g
>> > > > with the ansible scripts or custom scripts. So I usually use pom
>> > > > packaging then adding assembly plugin, just feels strange doing th=
at
>> > > > 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 need=
s
>> > core changes. Could you provide details where you feel we need to modi=
fy
>> > core for this (or is it you want to be able to fetch some artifacts fr=
om
>> > within the zip, iow a zip with the other artifacts embedded and we "re=
ach
>> > 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 b=
e
>> > > useful
>> > >
>> > > >
>> > > > 3) Debian style repo management. Instead of having a massive bucke=
t
>> of
>> > > > artefacts, start having repo's either based upon java class versio=
n,
>> > > > 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 requir=
e
>> > > 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 w=
ay
>> > > > 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 c=
an
>> be
>> > > made
>> > > generic enough
>> > >
>> > > Regards,
>> > >
>> > > Herv=C3=A9
>> > >
>> > > >
>> > > > 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 yank=
ed
>> 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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org