maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte" <rfscho...@apache.org>
Subject Re: Maven 4.0.0
Date Sat, 04 Nov 2017 21:35:35 GMT
On Sat, 04 Nov 2017 18:34:14 +0100, Romain Manni-Bucau  
<rmannibucau@gmail.com> wrote:

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

sounds like https://issues.apache.org/jira/browse/MNG-6118
right?

>
>>
>>
>>> - 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
>
> ---------------------------------------------------------------------
> 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
View raw message