Re: Maven 4.0.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

Paul Hammant
To add to scope for Maven 4, IMO:

*1. <dependency> tag could have an optional <repo-list> arg:*

<dependency>
    <repo-list>my-team,mycorp</repo-list>
    <groupId>com.thoughtworks.xstream</groupId>
    <artifactId>xstream</artifactId>
    <version>1.4.10</version>
</dependency>


In the above, central is not checked at all.  my-team and my-corp are
defined elsewhere.

*2. GAV as a first class thing (optional):*

<dependency>
    <gav>com.thoughtworks.xstream:xstream:1.4.10</gav>
</dependency>

or

<dependency gav="com.thoughtworks.xstream:xstream:1.4.10"/>


For the first time ever people could do simple ack/ag/grep thru source
bases looking for things.

*3. More pluggable dependency resolver:*

I might want alternate places to source JARs from that are *not* HTTP
mounted system that match the Maven2 directory structure.

Like here - https://github.com/paul-hammant/xstream-jar/releases (and
associated blog entry -
https://paulhammant.com/2017/05/13/maven-central-as-multiple-git-repos/)

In particular I need to rework the jar as it is pulled into the local
~/.m2/repository cache - there's a root directory to remove.

- Paul
Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

stephenconnolly
On Sat 4 Nov 2017 at 12:50, Paul Hammant <[hidden email]> wrote:

> To add to scope for Maven 4, IMO:
>
> *1. <dependency> tag could have an optional <repo-list> arg:*
>
> <dependency>
>     <repo-list>my-team,mycorp</repo-list>
>     <groupId>com.thoughtworks.xstream</groupId>
>     <artifactId>xstream</artifactId>
>     <version>1.4.10</version>
> </dependency>


No. We are pushing pom model changes to 5.0.0 (as modelVersion 4.0.0 aligns
with Maven version)

Aim is to build a platform from which 5.0.0 can be launched


>
>
> In the above, central is not checked at all.  my-team and my-corp are
> defined elsewhere.
>
> *2. GAV as a first class thing (optional):*
>
> <dependency>
>     <gav>com.thoughtworks.xstream:xstream:1.4.10</gav>
> </dependency>
>
> or
>
> <dependency gav="com.thoughtworks.xstream:xstream:1.4.10"/>
>
>
> For the first time ever people could do simple ack/ag/grep thru source
> bases looking for things.


No, requires modelVersion bump. Out of scope for 4.0.0


>
> *3. More pluggable dependency resolver:*
>
> I might want alternate places to source JARs from that are *not* HTTP
> mounted system that match the Maven2 directory structure.
>
> Like here - https://github.com/paul-hammant/xstream-jar/releases (and
> associated blog entry -
> https://paulhammant.com/2017/05/13/maven-central-as-multiple-git-repos/)
>
> In particular I need to rework the jar as it is pulled into the local
> ~/.m2/repository cache - there's a root directory to remove.


I am willing to let this be optional scope for now. May be yanked if too
risky or not ready in time


>
> - Paul
>
--
Sent from my phone
Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

Paul Hammant
>
>
>
> >
> > *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"
Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

stephenconnolly
In reply to this post by Paul Hammant
On Sat 4 Nov 2017 at 12:52, Stephen Connolly <
[hidden email]> wrote:

> On Sat 4 Nov 2017 at 12:49, Michael Osipov <[hidden email]> wrote:
>
>> Am 2017-11-04 um 13:20 schrieb Stephen Connolly:
>> > The past two days, Hervé, Robert and I have been discussing our next
>> steps.
>> >
>> > I think we have a semi-consensus which I want to bring back to the list:
>> >
>> > We keep 3.5.x as a stable branch with critical bug fixes only
>> >
>> > We switch master to 4.0.0 and start to burn down a release scope.
>> >
>> > 4.0.0 will not change the pom modelVersion
>> >
>> > The 4.0.0 scope should probably be:
>> >
>> > Required:
>> > * drop Java 7, switch codebase to Java 8 idioms (while maintaining
>> binary
>> > api compatibility for plugins)
>>
>> Who is going to do this? I haven't even seen any Java 7 improvements
>> (NIO 2 and others) in core since 3.3. I doubt that core will we be
>> rewritten with Java 8 idioms.
>> Consider that we still have plugins running Maven 2.2.x which need more
>> attention first.
>
>
> We are going to ask the wider community to contribute PRs towards that
> goal, each PR limited to ~20 Lines of diff.
>

A diff this small on “obvious” (as in we’d be just as likely to come up
with the same or similar change if we looked at the method) changes does
not require a signed ICLA, just confirmation of grant in PR...

Should give a much lower barrier for getting started contributing


> We will need infrastructure to assure binary compatibility (like clirr
> used to do before it died) before we can start that effort.
>
> Aim is to find people willing to dive in and get them familiar with the
> code base by making many small low/no risk changes
>
>
>>
>> > * specify the classloader behaviour and fix impl to align with spec (may
>> > need a plugin flag to allow plugins to opt in to spec behaviour)
>> > * specify the extension spec
>> > * allow limited mutation of the runtime model (reducing transitive
>> > dependencies for consumers within the reactor, only for plugin goals
>> that
>> > declare intent) use case: shade plugin
>> > * better CI integration hooks
>> > * nice error message for newer pom modelVersion
>>
>> This looks quite reasonable to me.
>>
>> Michael
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>> --
> Sent from my phone
>
--
Sent from my phone
Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

Hervé BOUTEMY
In reply to this post by Paul Hammant
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?

>
> 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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

Romain Manni-Bucau
My wishlist as a user would be:

- incremental build (based on scm is fine)
- some built in scripting (groovy based?)
- 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" <[hidden email]>
a écrit :

> On 4 November 2017 at 07:30, Hervé BOUTEMY <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

Romain Manni-Bucau
2017-11-04 18:17 GMT+01:00 Stephen Connolly <[hidden email]>:

> On Sat 4 Nov 2017 at 17:11, Romain Manni-Bucau <[hidden email]>
> 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.

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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

rfscholte
On Sat, 04 Nov 2017 18:34:14 +0100, Romain Manni-Bucau  
<[hidden email]> wrote:

> 2017-11-04 18:17 GMT+01:00 Stephen Connolly  
> <[hidden email]>:
>> On Sat 4 Nov 2017 at 17:11, Romain Manni-Bucau <[hidden email]>
>> 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"  
>>> <[hidden email]>
>>> a écrit :
>>>
>>> > On 4 November 2017 at 07:30, Hervé BOUTEMY <[hidden email]>
>>> 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 <[hidden email]>  
>>> 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: [hidden email]
>>> > > > For additional commands, e-mail: [hidden email]
>>> > >
>>> > >
>>> > >
>>> > >  
>>> ---------------------------------------------------------------------
>>> > > To unsubscribe, e-mail: [hidden email]
>>> > > For additional commands, e-mail: [hidden email]
>>> > >
>>> > >
>>> >
>>>
>> --
>> Sent from my phone
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

Romain Manni-Bucau
In reply to this post by Paul Hammant
FYI opened https://github.com/apache/maven/pull/136 for the MNG-6302
(guess we can switch from thread to discuss it now?)

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn


2017-11-09 9:30 GMT+01:00 Jörg Schaible <[hidden email]>:

> Hi,
>
> one wish: Better integration with pom-less Tycho projects.
>
> Currently it is not possible to run Maven and use standard Maven-based
> and pom-less Tycho-based projects in one reactor if the Tycho projects
> have dependencies on the Maven-based projects.
>
> AFAICS the problem is that Polyglott is used to generate the temporary
> POMs out of the MANIFEST.MF on the fly, but the reactor-phase has already
> passed that calculates the build order.
>
> It would be nice to adjust Maven Core in a way that allows such
> extensions contribute to the build order.
>
> Cheers,
> Jörg
>
>
> Am Sat, 04 Nov 2017 12:20:18 +0000 schrieb Stephen Connolly:
>
>> The past two days, Hervé, Robert and I have been discussing our next
>> steps.
>>
>> I think we have a semi-consensus which I want to bring back to the list:
>>
>> We keep 3.5.x as a stable branch with critical bug fixes only
>>
>> We switch master to 4.0.0 and start to burn down a release scope.
>>
>> 4.0.0 will not change the pom modelVersion
>>
>> The 4.0.0 scope should probably be:
>>
>> Required:
>> * drop Java 7, switch codebase to Java 8 idioms (while maintaining
>> binary api compatibility for plugins)
>> * specify the classloader behaviour and fix impl to align with spec (may
>> need a plugin flag to allow plugins to opt in to spec behaviour)
>> * specify the extension spec * allow limited mutation of the runtime
>> model (reducing transitive dependencies for consumers within the
>> reactor, only for plugin goals that declare intent) use case: shade
>> plugin * better CI integration hooks * nice error message for newer pom
>> modelVersion
>>
>> Optional:
>> * (damn I forgot, maybe Robert remembers)
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

ChrisGWarp
In reply to this post by Paul Hammant
required:
 - *everything* in settings.xml can be put in a profile section in
settings.xml.

I often move around/between projects and having to redo mirrors section,
and unable to add servers into the profile section for clarity is a pain.

For me, it's just a matter of convienence.

On Sat, Nov 4, 2017 at 11:20 PM, Stephen Connolly <
[hidden email]> wrote:

> The past two days, Hervé, Robert and I have been discussing our next steps.
>
> I think we have a semi-consensus which I want to bring back to the list:
>
> We keep 3.5.x as a stable branch with critical bug fixes only
>
> We switch master to 4.0.0 and start to burn down a release scope.
>
> 4.0.0 will not change the pom modelVersion
>
> The 4.0.0 scope should probably be:
>
> Required:
> * drop Java 7, switch codebase to Java 8 idioms (while maintaining binary
> api compatibility for plugins)
> * specify the classloader behaviour and fix impl to align with spec (may
> need a plugin flag to allow plugins to opt in to spec behaviour)
> * specify the extension spec
> * allow limited mutation of the runtime model (reducing transitive
> dependencies for consumers within the reactor, only for plugin goals that
> declare intent) use case: shade plugin
> * better CI integration hooks
> * nice error message for newer pom modelVersion
>
> Optional:
> * (damn I forgot, maybe Robert remembers)
> --
> Sent from my phone
>
Reply | Threaded
Open this post in threaded view
|

Re: Maven 4.0.0

Mark Derricutt

On 12 Nov 2017, at 23:06, Stephen Connolly wrote:

That could end up duplicating the local repo cache... unless we default the
cache to ~/.m2/repository anyway... otoh a concurrency safe local repo
cache may mandate a new location... but double the downloads for inter-op
with older Maven installs on the same machine seems not so good to me.

If we're talking restructuring the local repo, I've long wanting to separate out locally "mvn install"'d items from those downloaded, essentially this would keep ( for the most part ) local SNAPSHOTs separate from anything downloaded.

I guess what I really want there is a local releases/snaphshots repo separation, often it's handy to just blow away all snapshots and rebuild into a known state. It does make for more complexity tho.


"The ease with which a change can be implemented has no relevance at all to whether it is the right change for the (Java) Platform for all time." — Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc (546 bytes) Download Attachment