Re: Docker image with initialized local cache saves 50 seconds in startup

[Romain Manni-Bucau]

Hi Tibor,

It has two issues:

1. It will not be the right plugin versions in 90% of the cases (except
demo ;))
2. It will miss all custom plugins

Now question is: what happens if you mount your local repo when running
docker? It works as expected. Means we could use a custom entrypoint
printing a warning banner if it is not done probably instead of incrasing
the image size without being sure to reach the original goal.

Wdyt?

Romain

Le mer. 30 oct. 2019 à 02:03, Tibor Digana  a
écrit :

> If you use Docker images with Maven with no mapping of cache to the
> volumes, you may notice that Maven downloads the plugins for the build
> lifecycle.
>
> This slows down the build because a lot of artifacts and plugins are
> initially downloaded.
> This takes 50 seconds which might be even longer than the productive build
> itself (compiler, package, ...).
>
> We discussed this topic with Herve and Karl at the Apache CON 2019 the last
> time.
>
> Sometime the presentations were funny because the audience had to wait a
> minute while the console was black where the Maven was downloading the
> plugins in the background.
> Nobody was sure what happened that time, whether the console hanged or the
> Cloud server hanged, or another issue happened with the network.
>
> I made a test and triggered the default lifecycle on Maven and I realized
> that the cache was really very little, cca 12 MB.
> So this little cache in the container would save 50 seconds which is the
> improvement we are discussing.
>
> From the use point of view, the user would use a new base image `
> 3.6.2-jdk-14-prefetched` which is my idea.
>
> There are multiple technical solutions (range of plugins, extra pom,
> internal Maven plugin versions, etc).
>
> We understood that the best idea would be to have the image with the cache
> in new Docker images produced by Carloss Sanchez.
>
> We are discussing this topic in [1] but we do not have a consensus on who
> will develop the Docker scripts and how.
>
> We can continue here and we can propose a solution.
>
> [1] https://github.com/carlossg/docker-maven/issues/130
>
>
> Cheers
> Tibor17
>

Re: [VOTE] JDK 8 Minimum Requirement for Maven 3.7.0

[Jesper Udby]

+1

 Jesper Udby

⁣Hent BlueMail til Android ​

Den 30. okt. 2019 02.34, fra 02.34, Manfred Moser  
skrev:
>+1
>
>or more ... haha
>
>Manfred
>
>Stephen Connolly wrote on 2019-10-29 16:23 (GMT -07:00):
>
>> +1
>>
>> On Tue 29 Oct 2019 at 20:11, Karl Heinz Marbaise 
>wrote:
>>
>>> Hi to all,
>>>
>>> based on the discusion this is the formal VOTE to lift the minimum
>of
>>> Maven Core with version 3.7.0 to JDK 8 minimum.
>>>
>>> Vote open for at least 72 hours.
>>>
>>> [ ] +1
>>> [ ] +0
>>> [ ] -1
>>>
>>>
>>> Kind regards
>>> Karl Heinz Marbaise
>>>
>>>
>-
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>> --
>> Sent from my phone
>>
>
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] JDK 8 Minimum Requirement for Maven 3.7.0

[Manfred Moser]

+1

or more ... haha

Manfred

Stephen Connolly wrote on 2019-10-29 16:23 (GMT -07:00):

> +1
> 
> On Tue 29 Oct 2019 at 20:11, Karl Heinz Marbaise  wrote:
> 
>> Hi to all,
>>
>> based on the discusion this is the formal VOTE to lift the minimum of
>> Maven Core with version 3.7.0 to JDK 8 minimum.
>>
>> Vote open for at least 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>> --
> Sent from my phone
> 


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

Docker image with initialized local cache saves 50 seconds in startup

[Tibor Digana]

If you use Docker images with Maven with no mapping of cache to the
volumes, you may notice that Maven downloads the plugins for the build
lifecycle.

This slows down the build because a lot of artifacts and plugins are
initially downloaded.
This takes 50 seconds which might be even longer than the productive build
itself (compiler, package, ...).

We discussed this topic with Herve and Karl at the Apache CON 2019 the last
time.

Sometime the presentations were funny because the audience had to wait a
minute while the console was black where the Maven was downloading the
plugins in the background.
Nobody was sure what happened that time, whether the console hanged or the
Cloud server hanged, or another issue happened with the network.

I made a test and triggered the default lifecycle on Maven and I realized
that the cache was really very little, cca 12 MB.
So this little cache in the container would save 50 seconds which is the
improvement we are discussing.

>From the use point of view, the user would use a new base image `
3.6.2-jdk-14-prefetched` which is my idea.

There are multiple technical solutions (range of plugins, extra pom,
internal Maven plugin versions, etc).

We understood that the best idea would be to have the image with the cache
in new Docker images produced by Carloss Sanchez.

We are discussing this topic in [1] but we do not have a consensus on who
will develop the Docker scripts and how.

We can continue here and we can propose a solution.

[1] https://github.com/carlossg/docker-maven/issues/130


Cheers
Tibor17

Re: [VOTE] JDK 8 Minimum Requirement for Maven 3.7.0

[Stephen Connolly]

+1

On Tue 29 Oct 2019 at 20:11, Karl Heinz Marbaise  wrote:

> Hi to all,
>
> based on the discusion this is the formal VOTE to lift the minimum of
> Maven Core with version 3.7.0 to JDK 8 minimum.
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: [VOTE] Release Apache Maven JAR Plugin version Y.Z

[Karl Heinz Marbaise]

Hi Hervé,

I think you meant: "[VOTE] Release Apache Maven Source Plugin Version
3.2.0"  didn't you ?

Kind regards
Karl Heinz Marbaise


On 29.10.19 22:55, Hervé BOUTEMY wrote:

Hi,

We solved 1 issue:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317526=12345503=Text

Staging repo:
https://repository.apache.org/content/repositories/maven-1533/
https://repository.apache.org/content/repositories/maven-1533/org/apache/maven/plugins/maven-jar-plugin/3.2.0/maven-jar-plugin-3.2.0-source-release.zip

Source release checksum(s):
maven-jar-plugin-3.2.0-source-release.zip sha512: 
b84da749dd6ca3a58173ad060a7406bee48ea02d78bc638fcc404c1c31c7c466d5d33890ab549a4edd99efcfebb8926a7955d647a398968c2b1c44393a3bef43

Staging site:
https://maven.apache.org/plugins-archives/maven-jar-plugin-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1


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

Re: [VOTE] JDK 8 Minimum Requirement for Maven 3.7.0

[Hervé BOUTEMY]

+1

Regards,

Hervé

Le mardi 29 octobre 2019, 21:11:33 CET Karl Heinz Marbaise a écrit :
> Hi to all,
> 
> based on the discusion this is the formal VOTE to lift the minimum of
> Maven Core with version 3.7.0 to JDK 8 minimum.
> 
> Vote open for at least 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> 
> Kind regards
> Karl Heinz Marbaise
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: Next Generation Integration Testing for Plugins/Core

[Romain Manni-Bucau]

Le mar. 29 oct. 2019 à 22:58, Karl Heinz Marbaise  a
écrit :

> Hi Romain,
>
> On 29.10.19 22:40, Romain Manni-Bucau wrote:
> > Hi Karl
> >
> > Not sure id do a MavenIT annotation - test is enough probably - but i
> > like jupiter style.
>
> MavenIT[1] annotation contains more information like global/local cache,
> the default goals which are used for the build, debugging or not (just
> to mention some; I think there will be more).
>
> Also so the MavenTest annotation is needed to define specific things for
> Maven like activeProfiles etc.
>
> [1]:
>
> https://github.com/khmarbaise/maven-it-extension/blob/master/src/main/java/org/apache/maven/jupiter/extension/MavenIT.java
>
> See also:
>
>
> https://github.com/khmarbaise/maven-it-extension/blob/master/src/test/java/org/apache/maven/jupiter/it/MavenIntegrationIT.java



You can alias @MavenTest for that no? This is what i had in mind. Like
@ShadeTest decorated with @MavenTest to set defaults.

So you reduce thz number of annotations.

That said it is not a blocker.


>
>
> >
> > Im less exited by assertj but it is probably a habit thing.
>
> I'm not sure if I see your issue with AssertJ. Have you used it? AssertJ
> brings clear expression and readable tests in general and gives me a
> simple way to create custom assertions to support special parts for a
> Maven build like Log file, project structure, target directory contents,
> content of archive files etc. ?
>
> like this:
>
>   assertThat(result)
> .project()
>   .hasTarget()
> .withEarFile()
>.containsOnlyOnce("META-INF/MANIFEST.MF");
>
> I've never seen a assertion framework which makes it possible to write
> tests in a more or less fluent way ...
>

I did use it a few and dropped it since it does not bring much i  most
cases.
Asserts stay simple and chaining them just hit autoformatting limitations
in general.
Also assertj had some dependency conflicts - fixed now IIRC.
So staying minimal was good.

The side note being: do you need it or can you back your dsl with jupiter
assertions? No strong need ;).


> What would be your choice?
>

Just an available model, fluent if you want, but no additional dep.
Default Assertions is enough for most cases, in particular with streams and
lambdas.


>
> >
> > Wonder if you evaluated to run in a fake filesystem like jimfs or so and
> > enable the pom+files to be defined on the test method?
>
> This is exactly where I have decided against at the moment cause
> construction of a full maven project with all it's pom file(s)
> directories source code etc. is based on the things I want to solve to
> complicated...we already have such things[2] also in plexus testcase you
> can do such things or more easier today just use mockito ...
>

Hmm, this is not comparable.
Mockito is like not writing tests, jimfs is launching a real build on a
fake in memory filesystem, no mocking for maven.


> Currently I have gone the path to have a convention where to find the
> projects which are used to be tested like maven-invoker-plugin already
> does ...and can also being executed manually within the directory
> without any change ...helps a lot in case error hunting ...
>
> Can you explain the hint about fake filesystem like jimfs a little bit
> more cause I don't know jimfs etc. and what you have in mind?
>

Jimfs is a FileSystem implementation so if maven uses java.nio.file api
then we can run on an in memory FS and configure it from any metamodel we
want.

It would be close to this sftp testing api
https://github.com/rmannibucau/rule-them-all/blob/master/src/test/java/com/github/rmannibucau/rules/test/sftp/TestSftpRule.java#L32



>
> [2]:
>
> https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/index.html
>
>  > > Goal would be to
> > not split setup and asserts (given and then colocalized, then being the
> > mvn exec).
>
> Maybe I misunderstand that? Can you give an example ?
>
> Kind regards
> Karl Heinz Marbaise
>
>
> >
> > Hope it makes sense.
>
>
> >
> > Le mar. 29 oct. 2019 à 21:47, Karl Heinz Marbaise  > > a écrit :
> >
> > Hi to all,
> >
> > I've invested some time to get a thing working in a different way
> which
> > nags me for a long time.
> >
> > Integration tests for maven plugins and for maven core...
> >
> > So created a prototype based on a JUnit Jupiter extension.
> >
> > The following is the JUnit Jupiter extension (currently very hacky
> code;
> > not intended to win a competition for good code!)
> >
> > https://github.com/khmarbaise/maven-it-extension
> >
> > which contains some documentation which is of course not ready yet...
> > but the implementation and usage (see maven-ear-plugin) gives me at
> the
> > moment already a very good impression how easy it can be to write
> > integration tests for a maven plugin etc.
> >
> > Example from the docs(not 100% working like that yet):
> >
> > @MavenIT
> > class FirstMavenIT {
> >
> >

[VOTE] Release Apache Maven Assembly Plugin version 3.2.0

[Hervé BOUTEMY]

Hi,

We solved 9 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317220=12344773=Text

Staging repo:
https://repository.apache.org/content/repositories/maven-1534/
https://repository.apache.org/content/repositories/maven-1534/org/apache/maven/plugins/maven-assembly-plugin/3.2.0/maven-assembly-plugin-3.2.0-source-release.zip

Source release checksum(s):
maven-assembly-plugin-3.2.0-source-release.zip sha512: 
23c1c79c51279232efc8dbeb697a6357257263c03356732d94b06f26ce219f44e650910ec7deb2ca8889449e669d40c47f7717ab6c1fb1e5ea6572cf643a5926

Staging site:
https://maven.apache.org/plugins-archives/maven-assembly-plugin-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1



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

[VOTE] Release Apache Maven JAR Plugin version Y.Z

[Hervé BOUTEMY]

Hi,

We solved 1 issue:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317526=12345503=Text

Staging repo:
https://repository.apache.org/content/repositories/maven-1533/
https://repository.apache.org/content/repositories/maven-1533/org/apache/maven/plugins/maven-jar-plugin/3.2.0/maven-jar-plugin-3.2.0-source-release.zip

Source release checksum(s):
maven-jar-plugin-3.2.0-source-release.zip sha512: 
b84da749dd6ca3a58173ad060a7406bee48ea02d78bc638fcc404c1c31c7c466d5d33890ab549a4edd99efcfebb8926a7955d647a398968c2b1c44393a3bef43

Staging site:
https://maven.apache.org/plugins-archives/maven-jar-plugin-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1



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

Re: Next Generation Integration Testing for Plugins/Core

[Karl Heinz Marbaise]

Hi Romain,

On 29.10.19 22:40, Romain Manni-Bucau wrote:

Hi Karl

Not sure id do a MavenIT annotation - test is enough probably - but i
like jupiter style.


MavenIT[1] annotation contains more information like global/local cache,
the default goals which are used for the build, debugging or not (just
to mention some; I think there will be more).

Also so the MavenTest annotation is needed to define specific things for
Maven like activeProfiles etc.

[1]:
https://github.com/khmarbaise/maven-it-extension/blob/master/src/main/java/org/apache/maven/jupiter/extension/MavenIT.java

See also:

https://github.com/khmarbaise/maven-it-extension/blob/master/src/test/java/org/apache/maven/jupiter/it/MavenIntegrationIT.java




Im less exited by assertj but it is probably a habit thing.


I'm not sure if I see your issue with AssertJ. Have you used it? AssertJ
brings clear expression and readable tests in general and gives me a
simple way to create custom assertions to support special parts for a
Maven build like Log file, project structure, target directory contents,
content of archive files etc. ?

like this:

 assertThat(result)
   .project()
 .hasTarget()
   .withEarFile()
  .containsOnlyOnce("META-INF/MANIFEST.MF");

I've never seen a assertion framework which makes it possible to write
tests in a more or less fluent way ...

What would be your choice?




Wonder if you evaluated to run in a fake filesystem like jimfs or so and
enable the pom+files to be defined on the test method?


This is exactly where I have decided against at the moment cause
construction of a full maven project with all it's pom file(s)
directories source code etc. is based on the things I want to solve to
complicated...we already have such things[2] also in plexus testcase you
can do such things or more easier today just use mockito ...

Currently I have gone the path to have a convention where to find the
projects which are used to be tested like maven-invoker-plugin already
does ...and can also being executed manually within the directory
without any change ...helps a lot in case error hunting ...

Can you explain the hint about fake filesystem like jimfs a little bit
more cause I don't know jimfs etc. and what you have in mind?


[2]:
https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/index.html

> > Goal would be to

not split setup and asserts (given and then colocalized, then being the
mvn exec).


Maybe I misunderstand that? Can you give an example ?

Kind regards
Karl Heinz Marbaise




Hope it makes sense.





Le mar. 29 oct. 2019 à 21:47, Karl Heinz Marbaise mailto:khmarba...@gmx.de>> a écrit :

Hi to all,

I've invested some time to get a thing working in a different way which
nags me for a long time.

Integration tests for maven plugins and for maven core...

So created a prototype based on a JUnit Jupiter extension.

The following is the JUnit Jupiter extension (currently very hacky code;
not intended to win a competition for good code!)

https://github.com/khmarbaise/maven-it-extension

which contains some documentation which is of course not ready yet...
but the implementation and usage (see maven-ear-plugin) gives me at the
moment already a very good impression how easy it can be to write
integration tests for a maven plugin etc.

Example from the docs(not 100% working like that yet):

@MavenIT
class FirstMavenIT {

    @MavenTest
    void the_first_test_case(MavenProjectResult result) {
      assertThat(result)
        .build()
          .isSuccessful()
        .and()
        .project()
          .hasTarget()
            .withEarFile()
              .containsOnlyOnce("META-INF/MANIFEST.MF")
          .log()
            .info().contains("Writing data to file")
        .cache()
            .withEarFile("G:A:V")
            .withPomFile("G:A:V")
            .withMetadata().contains("xxx");
    }
}


I created a branch "maven-it-extension" on Maven EAR Plugin which shows
that it can be used in combination with maven-invoker-plugin:install
goal and using maven-failsafe-plugin to run the tests for
maven-ear-plugin (some of them at the moment. Not migrated all of
them yet).

Example which already works:

https://github.com/apache/maven-ear-plugin/blob/maven-it-extension/src/test/java/org/apache/maven/plugins/ear/it/EARIT.java


WDYT ?

Kind regards
Karl Heinz Marbaise


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

Re: [VOTE] JDK 8 Minimum Requirement for Maven 3.7.0

[Romain Manni-Bucau]

Le mar. 29 oct. 2019 à 22:24, Tibor Digana  a
écrit :

> Karl, I am not happy with this short text because you did not say that we
> will turn the code to J8.
> There is a plugin automating this transformation.
> One man can do it in his private and that's it.
> Of course somebody has to execute performance tests.
>
> Without changing the code we would not be eligible for young Java
> contributors.
> The users can use JDK8-14 since we are not a blocker to use any JDK today
> but the topic should be about the code.
>

This is not fully true.
Typically today i took a j7 codebase and updated part of its API to j8 in
the area i was patching. This was great for my contribution and didnt need
to rewrite all the code.
New dev are not worse than us caude they know what are lambas, they will
understand loops and util classes so we dont need to worry about that, just
enabling them is already a huge step and not automating it but letting them
do is an opportunity for contributions.


> So, now it is a bit strange vote.
>
> On Tue, Oct 29, 2019 at 9:11 PM Karl Heinz Marbaise 
> wrote:
>
> > Hi to all,
> >
> > based on the discusion this is the formal VOTE to lift the minimum of
> > Maven Core with version 3.7.0 to JDK 8 minimum.
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: [VOTE] JDK 8 Minimum Requirement for Maven 3.7.0

[Tamás Cservenák]

+1

On Tue, Oct 29, 2019, 21:11 Karl Heinz Marbaise  wrote:

> Hi to all,
>
> based on the discusion this is the formal VOTE to lift the minimum of
> Maven Core with version 3.7.0 to JDK 8 minimum.
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Next Generation Integration Testing for Plugins/Core

[Romain Manni-Bucau]

Hi Karl

Not sure id do a MavenIT annotation - test is enough probably - but i like
jupiter style.

Im less exited by assertj but it is probably a habit thing.

Wonder if you evaluated to run in a fake filesystem like jimfs or so and
enable the pom+files to be defined on the test method? Goal would be to not
split setup and asserts (given and then colocalized, then being the mvn
exec).

Hope it makes sense.

Le mar. 29 oct. 2019 à 21:47, Karl Heinz Marbaise  a
écrit :

> Hi to all,
>
> I've invested some time to get a thing working in a different way which
> nags me for a long time.
>
> Integration tests for maven plugins and for maven core...
>
> So created a prototype based on a JUnit Jupiter extension.
>
> The following is the JUnit Jupiter extension (currently very hacky code;
> not intended to win a competition for good code!)
>
> https://github.com/khmarbaise/maven-it-extension
>
> which contains some documentation which is of course not ready yet...
> but the implementation and usage (see maven-ear-plugin) gives me at the
> moment already a very good impression how easy it can be to write
> integration tests for a maven plugin etc.
>
> Example from the docs(not 100% working like that yet):
>
> @MavenIT
> class FirstMavenIT {
>
>@MavenTest
>void the_first_test_case(MavenProjectResult result) {
>  assertThat(result)
>.build()
>  .isSuccessful()
>.and()
>.project()
>  .hasTarget()
>.withEarFile()
>  .containsOnlyOnce("META-INF/MANIFEST.MF")
>  .log()
>.info().contains("Writing data to file")
>.cache()
>.withEarFile("G:A:V")
>.withPomFile("G:A:V")
>.withMetadata().contains("xxx");
>}
> }
>
>
> I created a branch "maven-it-extension" on Maven EAR Plugin which shows
> that it can be used in combination with maven-invoker-plugin:install
> goal and using maven-failsafe-plugin to run the tests for
> maven-ear-plugin (some of them at the moment. Not migrated all of them
> yet).
>
> Example which already works:
>
> https://github.com/apache/maven-ear-plugin/blob/maven-it-extension/src/test/java/org/apache/maven/plugins/ear/it/EARIT.java
>
>
> WDYT ?
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

[VOTE] Release Apache Maven Source Plugin version 3.2.0

[Hervé BOUTEMY]

Hi,

We solved 2 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317924&=12345522=Text

Staging repo:
https://repository.apache.org/content/repositories/maven-1532/
https://repository.apache.org/content/repositories/maven-1532/org/apache/maven/plugins/maven-source-plugin/3.2.0/maven-source-plugin-3.2.0-source-release.zip

Source release checksum(s):
maven-source-plugin-3.2.0-source-release.zip sha512: 
2321599d28affd25b2821a14182383a1a3a31bb33344fae395805d3173e9cdcfd2b1c09608e73a160f054f9086ad56f2b11f4fe56117fddb34356d1b8e935780

Staging site:
https://maven.apache.org/plugins-archives/maven-source-plugin-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1



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

Re: [VOTE] JDK 8 Minimum Requirement for Maven 3.7.0

[Karl Heinz Marbaise]

Hi Tibor,

can we the keep discussion out of this thread cause it's a VOTE thread...


On 29.10.19 22:24, Tibor Digana wrote:

Karl, I am not happy with this short text because you did not say that we
will turn the code to J8.
There is a plugin automating this transformation.
One man can do it in his private and that's it.
Of course somebody has to execute performance tests.

Without changing the code we would not be eligible for young Java
contributors.
The users can use JDK8-14 since we are not a blocker to use any JDK today
but the topic should be about the code.

So, now it is a bit strange vote. >
On Tue, Oct 29, 2019 at 9:11 PM Karl Heinz Marbaise 
wrote:


Hi to all,

based on the discusion this is the formal VOTE to lift the minimum of
Maven Core with version 3.7.0 to JDK 8 minimum.

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1


Kind regards
Karl Heinz Marbaise



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

Re: [VOTE] JDK 8 Minimum Requirement for Maven 3.7.0

[Tibor Digana]

Karl, I am not happy with this short text because you did not say that we
will turn the code to J8.
There is a plugin automating this transformation.
One man can do it in his private and that's it.
Of course somebody has to execute performance tests.

Without changing the code we would not be eligible for young Java
contributors.
The users can use JDK8-14 since we are not a blocker to use any JDK today
but the topic should be about the code.

So, now it is a bit strange vote.

On Tue, Oct 29, 2019 at 9:11 PM Karl Heinz Marbaise 
wrote:

> Hi to all,
>
> based on the discusion this is the formal VOTE to lift the minimum of
> Maven Core with version 3.7.0 to JDK 8 minimum.
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] JDK 8 Minimum Requirement for Maven 3.7.0

[Mickael Istria]

+1 from m2e and Tycho POV. Both have already require Java 8 for several
versions anyways, so the target audience is definitely already away from
Java 7.

Re: [VOTE] JDK 8 Minimum Requirement for Maven 3.7.0

[Olivier Lamy]

+1

On Wed, 30 Oct 2019 at 6:11 am, Karl Heinz Marbaise 
wrote:

> Hi to all,
>
> based on the discusion this is the formal VOTE to lift the minimum of
> Maven Core with version 3.7.0 to JDK 8 minimum.
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: [VOTE] JDK 8 Minimum Requirement for Maven 3.7.0

[Michael Osipov]

Am 2019-10-29 um 21:11 schrieb Karl Heinz Marbaise:

Hi to all,

based on the discusion this is the formal VOTE to lift the minimum of
Maven Core with version 3.7.0 to JDK 8 minimum.

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1


We have a bus load of issues for 3.7.0 in JIRA. I'd rather move this to 
3.8.0 we can ultimately land after 3.8.0.


So from my POV, -1

Michael

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

Next Generation Integration Testing for Plugins/Core

[Karl Heinz Marbaise]

Hi to all,

I've invested some time to get a thing working in a different way which
nags me for a long time.

Integration tests for maven plugins and for maven core...

So created a prototype based on a JUnit Jupiter extension.

The following is the JUnit Jupiter extension (currently very hacky code;
not intended to win a competition for good code!)

https://github.com/khmarbaise/maven-it-extension

which contains some documentation which is of course not ready yet...
but the implementation and usage (see maven-ear-plugin) gives me at the
moment already a very good impression how easy it can be to write
integration tests for a maven plugin etc.

Example from the docs(not 100% working like that yet):

@MavenIT
class FirstMavenIT {

  @MavenTest
  void the_first_test_case(MavenProjectResult result) {
assertThat(result)
  .build()
.isSuccessful()
  .and()
  .project()
.hasTarget()
  .withEarFile()
.containsOnlyOnce("META-INF/MANIFEST.MF")
.log()
  .info().contains("Writing data to file")
  .cache()
  .withEarFile("G:A:V")
  .withPomFile("G:A:V")
  .withMetadata().contains("xxx");
  }
}


I created a branch "maven-it-extension" on Maven EAR Plugin which shows
that it can be used in combination with maven-invoker-plugin:install
goal and using maven-failsafe-plugin to run the tests for
maven-ear-plugin (some of them at the moment. Not migrated all of them yet).

Example which already works:
https://github.com/apache/maven-ear-plugin/blob/maven-it-extension/src/test/java/org/apache/maven/plugins/ear/it/EARIT.java


WDYT ?

Kind regards
Karl Heinz Marbaise

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

Re: [VOTE] JDK 8 Minimum Requirement for Maven 3.7.0

[Gary Gregory]

non-binding +1

Gary

On Tue, Oct 29, 2019 at 4:11 PM Karl Heinz Marbaise 
wrote:

> Hi to all,
>
> based on the discusion this is the formal VOTE to lift the minimum of
> Maven Core with version 3.7.0 to JDK 8 minimum.
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] JDK 8 Minimum Requirement for Maven 3.7.0

[Francois Papon]

+1 (non-binding)

regards,

François
fpa...@apache.org

Le 29/10/2019 à 21:11, Karl Heinz Marbaise a écrit :
> Hi to all,
>
> based on the discusion this is the formal VOTE to lift the minimum of
> Maven Core with version 3.7.0 to JDK 8 minimum.
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

Re: [VOTE] JDK 8 Minimum Requirement for Maven 3.7.0

[Enrico Olivelli]

+1

Enrico

Il mar 29 ott 2019, 21:18 Romain Manni-Bucau  ha
scritto:

> +1 (non binding)
>
> Le mar. 29 oct. 2019 à 21:12, Karl Heinz Marbaise  a
> écrit :
>
> > Hi,
> >
> > +1 from me.
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > On 29.10.19 21:11, Karl Heinz Marbaise wrote:
> > > Hi to all,
> > >
> > > based on the discusion this is the formal VOTE to lift the minimum of
> > > Maven Core with version 3.7.0 to JDK 8 minimum.
> > >
> > > Vote open for at least 72 hours.
> > >
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > >
> > >
> > > Kind regards
> > > Karl Heinz Marbaise
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: [VOTE] JDK 8 Minimum Requirement for Maven 3.7.0

[Romain Manni-Bucau]

+1 (non binding)

Le mar. 29 oct. 2019 à 21:12, Karl Heinz Marbaise  a
écrit :

> Hi,
>
> +1 from me.
>
> Kind regards
> Karl Heinz Marbaise
>
> On 29.10.19 21:11, Karl Heinz Marbaise wrote:
> > Hi to all,
> >
> > based on the discusion this is the formal VOTE to lift the minimum of
> > Maven Core with version 3.7.0 to JDK 8 minimum.
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> >
> > Kind regards
> > Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] JDK 8 Minimum Requirement for Maven 3.7.0

[Karl Heinz Marbaise]

Hi,

+1 from me.

Kind regards
Karl Heinz Marbaise

On 29.10.19 21:11, Karl Heinz Marbaise wrote:

Hi to all,

based on the discusion this is the formal VOTE to lift the minimum of
Maven Core with version 3.7.0 to JDK 8 minimum.

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1


Kind regards
Karl Heinz Marbaise


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

[VOTE] JDK 8 Minimum Requirement for Maven 3.7.0

[Karl Heinz Marbaise]

Hi to all,

based on the discusion this is the formal VOTE to lift the minimum of
Maven Core with version 3.7.0 to JDK 8 minimum.

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1


Kind regards
Karl Heinz Marbaise

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

RE: Maven EAR Plugin 3.0.2

[abrarov]

Hi Karl,

> I will take a look within the next two weeks so I can create a new release ...

That would be great. Thank you.

Regards,
Marat Abrarov.


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

Re: Re: [DISCUSS] Maven 3.7.0

[Romain Manni-Bucau]

Sdkman is also a good option (and avoids binaries in sources)

That said, cant plugin check out they work?
It does not sound hard to check java version/parameters/... and validate
that when creating a mojo, isnt it?


Le mar. 29 oct. 2019 à 19:46, Robert Scholte  a
écrit :

> One of the fundamental features of Maven is Convention Over Configuration,
> in other words: define defaults where possible, but make it possible to
> change these values.
> However, "default" can be explained differently, either as constant
> (forever) or as a predefined value within a certain context.
>
> A lot of projects don't lock their plugins and up until Maven 2.0.9 the
> LATEST version was used. This could mean that with any new plugin release
> builds could break without any changes in their own codebase. Because of
> that Maven started defining default versions for the most common plugins.
> These defaults have been the same for a long time to prevent situations as
> before Maven 2.0.9
> Upgrading plugin defaults in Maven will break builds, because project
> actually rely on these defaults, intended or not.
>
> We should have a good answer when things do break. Some options:
> - figure out the problematic plugins and lock their version
> - stay on Maven 3.6.3 to have the combinations of plugin versions that do
> work together.
>
> Assuming most developers only have 1 version of Maven on their machine,
> both these answer aren't nice. And even with multiple Maven versions,
> switching between them isn't that nice.
> There is one other solution that will help in this case: make sure the
> project is being build with Maven version X.
> Such solution already exists, but most users are not aware of it and
> expect it to be part of Maven itself (as with Gradle): it is called the
> Maven Wrapper.
> I'm already negotiating about the codebase and IP, hopefully we'll have
> positive results soon.
>
> To me the upgrades of plugin defaults must be combined with the
> introduction of the Maven Wrapper as part of Maven core to have the least
> amount of issues.
>
> Robert
> On 29-10-2019 14:00:49, Michael Osipov <1983-01...@gmx.net> wrote:
> Why not have 3.7.0 plugin updates and other non-technical stuff, have it
> parallely maintained for some time and move with Maven 3.8.0 to Java 8
> next year?!
>
> Does that sound like a plan? I'd be happy with that. I'd also expect
> an announcement on dev@, announce@ and users@.
>
> Michael
>
> > Gesendet: Dienstag, 29. Oktober 2019 um 13:49 Uhr
> > Von: "Stephen Connolly"
> > An: "Maven Developers List"
> > Betreff: Re: [DISCUSS] Maven 3.7.0
> >
> > On Tue, 29 Oct 2019 at 12:47, Stephen Connolly <>
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > We already have a version policy:
> > >
> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
> > >
> >
> > (while that page says draft, the proposal was on-list in 2014 and just
> > converted into a wiki page afterwards - hence why the examples use 2014
> > dates)
> >
> >
> > > > The development line of Maven core should require a minimum JRE
> version
> > > that is no older than 18 months after the end of Oracle's public
> updates
> > > for that JRE version at the time that the first version of the
> development
> > > line was released, but may require a higher minimum JRE version if
> other
> > > requirements dictate a higher JRE version.
> > >
> > > End of public updates for Java 8 from Oracle was January 2019, thus if
> we
> > > cut a new minor version we would be Java 8 but not Java 7.
> > >
> > >
> > > On Tue, 29 Oct 2019 at 12:28, Tibor Digana wrote:
> > >
> > >> Stephen, we are in loop.
> > >> Of course I know these technical things.
> > >> But I am saying, and I am not alone (Michael Osipov too), that I agree
> > >> with
> > >> sources 1.8, but there must be1. the Vote with milestones regarding
> Maven
> > >> and another Vote regarding plugins, and 2. written list of pros/cons
> > >> regarding J8 and 3. developer guideline for J8 (for devs, consultants,
> > >> another professions as well in the team).
> > >> You know, with video calls, all these public emails would be gone
> within
> > >> one or two hours, I am sure!
> > >> I am also sure that we will have another code preferences and
> therefore we
> > >> should have some guideline. For instance, I like to have clear OOP in
> the
> > >> public class/interfaces and Lambda in private code. And there are a
> lot of
> > >> stuff, like parallel streams ala thread pool of non-daemon threads,
> > >> performance of streams (when, how stream is constructed, etc), Date
> Time
> > >> API is new as well.
> > >>
> > >> No benefit for the community with J7 sources but yes with J8 code.
> Believe
> > >> me, this is true. Michael mentioned that as well.
> > >>
> > >
> > > Not true. Java 8 bytecode adds additional metadata that speeds up
> > > classloading (but only when the class graph is all Java 8)
> > >
> > >
> > >>
> > >> It is also true that we have a lot of bugs, and it is true 

Re: Did you see dependabot?

[Tibor Digana]

I have received dependabot right now and merged.
https://github.com/Tibor17/surefire-tcp-connector/pull/1
Of course, my code is written just for fun and no legal issues are my
problem.

On Tue, Oct 29, 2019 at 7:49 PM Paul Hammant  wrote:

> Here's an interesting co-incidence. A chg I donated to Google's Cloud bits
> and pieces -
>
> https://github.com/GoogleCloudPlatform/google-cloud-datastore/pull/205/files
> *required
> and received* a CLA.
>
> @elharo just marked it as not needed, which is quite correct as this lib
> has been succeeded by something else.  *Humans quality controlling bot
> actions :)*
>

Re: Did you see dependabot?

[Paul Hammant]

Here's an interesting co-incidence. A chg I donated to Google's Cloud bits
and pieces -
https://github.com/GoogleCloudPlatform/google-cloud-datastore/pull/205/files
*required
and received* a CLA.

@elharo just marked it as not needed, which is quite correct as this lib
has been succeeded by something else.  *Humans quality controlling bot
actions :)*

Re: Re: [DISCUSS] Maven 3.7.0

[Robert Scholte]

One of the fundamental features of Maven is Convention Over Configuration, in 
other words: define defaults where possible, but make it possible to change 
these values.
However, "default" can be explained differently, either as constant (forever) 
or as a predefined value within a certain context.

A lot of projects don't lock their plugins and up until Maven 2.0.9 the LATEST 
version was used. This could mean that with any new plugin release builds could 
break without any changes in their own codebase. Because of that Maven started 
defining default versions for the most common plugins.
These defaults have been the same for a long time to prevent situations as 
before Maven 2.0.9
Upgrading plugin defaults in Maven will break builds, because project actually 
rely on these defaults, intended or not.

We should have a good answer when things do break. Some options:
- figure out the problematic plugins and lock their version
- stay on Maven 3.6.3 to have the combinations of plugin versions that do work 
together.

Assuming most developers only have 1 version of Maven on their machine, both 
these answer aren't nice. And even with multiple Maven versions, switching 
between them isn't that nice.
There is one other solution that will help in this case: make sure the project 
is being build with Maven version X.
Such solution already exists, but most users are not aware of it and expect it 
to be part of Maven itself (as with Gradle): it is called the Maven Wrapper.
I'm already negotiating about the codebase and IP, hopefully we'll have 
positive results soon.

To me the upgrades of plugin defaults must be combined with the introduction of 
the Maven Wrapper as part of Maven core to have the least amount of issues.

Robert 
On 29-10-2019 14:00:49, Michael Osipov <1983-01...@gmx.net> wrote:
Why not have 3.7.0 plugin updates and other non-technical stuff, have it
parallely maintained for some time and move with Maven 3.8.0 to Java 8 next 
year?!

Does that sound like a plan? I'd be happy with that. I'd also expect
an announcement on dev@, announce@ and users@.

Michael

> Gesendet: Dienstag, 29. Oktober 2019 um 13:49 Uhr
> Von: "Stephen Connolly"
> An: "Maven Developers List"
> Betreff: Re: [DISCUSS] Maven 3.7.0
>
> On Tue, 29 Oct 2019 at 12:47, Stephen Connolly <>
> stephen.alan.conno...@gmail.com> wrote:
>
> > We already have a version policy:
> > https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
> >
>
> (while that page says draft, the proposal was on-list in 2014 and just
> converted into a wiki page afterwards - hence why the examples use 2014
> dates)
>
>
> > > The development line of Maven core should require a minimum JRE version
> > that is no older than 18 months after the end of Oracle's public updates
> > for that JRE version at the time that the first version of the development
> > line was released, but may require a higher minimum JRE version if other
> > requirements dictate a higher JRE version.
> >
> > End of public updates for Java 8 from Oracle was January 2019, thus if we
> > cut a new minor version we would be Java 8 but not Java 7.
> >
> >
> > On Tue, 29 Oct 2019 at 12:28, Tibor Digana wrote:
> >
> >> Stephen, we are in loop.
> >> Of course I know these technical things.
> >> But I am saying, and I am not alone (Michael Osipov too), that I agree
> >> with
> >> sources 1.8, but there must be1. the Vote with milestones regarding Maven
> >> and another Vote regarding plugins, and 2. written list of pros/cons
> >> regarding J8 and 3. developer guideline for J8 (for devs, consultants,
> >> another professions as well in the team).
> >> You know, with video calls, all these public emails would be gone within
> >> one or two hours, I am sure!
> >> I am also sure that we will have another code preferences and therefore we
> >> should have some guideline. For instance, I like to have clear OOP in the
> >> public class/interfaces and Lambda in private code. And there are a lot of
> >> stuff, like parallel streams ala thread pool of non-daemon threads,
> >> performance of streams (when, how stream is constructed, etc), Date Time
> >> API is new as well.
> >>
> >> No benefit for the community with J7 sources but yes with J8 code. Believe
> >> me, this is true. Michael mentioned that as well.
> >>
> >
> > Not true. Java 8 bytecode adds additional metadata that speeds up
> > classloading (but only when the class graph is all Java 8)
> >
> >
> >>
> >> It is also true that we have a lot of bugs, and it is true that Maven
> >> needs
> >> to have breakthrough features like reproducible build and User POM, Docker
> >> prefetched cache, etc.
> >> I have no argument against these things. The only problem that I have and
> >> Michael has is the way how this is managed but it is the only trivial
> >> problem that we can solve between us.
> >>
> >>
> >>
> >>
> >>
> >> On Tue, Oct 29, 2019 at 1:04 PM Stephen Connolly <>
> >> stephen.alan.conno...@gmail.com> wrote:
> >>
> >> > You cannot 

Re: Maven EAR Plugin 3.0.2

[Karl Heinz Marbaise]

Hi,

On 29.10.19 17:10, abra...@gmail.com wrote:

Hi community,

Does anybody know plans on release of Maven EAR Plugin (3.0.2+, i.e. next
version)? If there is an open resource where release plan / schedule can be
found then I appreciate if smbd could point it.



First to say. This is an open source project so we have not schedules etc.

But what I can say is: I will take a look within the next two weeks so I
can create a new release ...

Would that help?

Kind regards
Karl Heinz Marbaise


Thank you.

Regards,
Marat Abrarov.


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

Re: Did you see dependabot?

[Paul Hammant]

I think you agree that the thesis has no bearing on the actions that
Dependabot recommends.

Worked Dependabot example
https://github.com/jbehave/jbehave-tutorial/pull/19/files (I consumed this
one for the JBehave team).

^ That was not copyrightable. It is not *original expression*, if it was
and Dependabot beat me to an upgrade, and did not also grant me a copyright
for the same, I would be legally prevented from effecting the same upgrade
be retyping the same two-character change. Patch upgrades like this are in
the "obvious" and "could not be done any other way" that are decades old as
considered dilemmas and well and truly answered in law. The alternative
would be skip 1.4.6 as an upgrade and wait for 1.4.7 - hoping to beat
dependabot to the punch??



On Tue, Oct 29, 2019 at 4:19 PM Martijn Dashorst 
wrote:

> The conclusion of the paper itself is 3 pages (no paragraphs, so it
> might be written by an AI ;-).
>
> - Dutch (and international) copyright law don't require a copyright
> holder to be human
> - so the work itself needs to be evaluated, two criteria that factor
> into this; requirement of reflecting an original expression and the
> carrying of a personal imprint
> - original expression is feasible for AIs (according to author)
>
> The author lost me at the reasoning for "personal imprint".
>
> Martijn
>
> On Tue, Oct 29, 2019 at 11:18 AM Paul Hammant  wrote:
> >
> > Summary ?
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Did you see dependabot?

[Martijn Dashorst]

The conclusion of the paper itself is 3 pages (no paragraphs, so it
might be written by an AI ;-).

- Dutch (and international) copyright law don't require a copyright
holder to be human
- so the work itself needs to be evaluated, two criteria that factor
into this; requirement of reflecting an original expression and the
carrying of a personal imprint
- original expression is feasible for AIs (according to author)

The author lost me at the reasoning for "personal imprint".

Martijn

On Tue, Oct 29, 2019 at 11:18 AM Paul Hammant  wrote:
>
> Summary ?



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

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

Maven EAR Plugin 3.0.2

[abrarov]

Hi community,

Does anybody know plans on release of Maven EAR Plugin (3.0.2+, i.e. next
version)? If there is an open resource where release plan / schedule can be
found then I appreciate if smbd could point it.

Thank you.

Regards,
Marat Abrarov.


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

Re: Re: [DISCUSS] Maven 3.7.0

[Romain Manni-Bucau]

Le mar. 29 oct. 2019 à 14:24, Enrico Olivelli  a
écrit :

> Il giorno mar 29 ott 2019 alle ore 14:22 Stephen Connolly <
> stephen.alan.conno...@gmail.com> ha scritto:
>
> > Because maintaining Java 7 is a barrier to new contributors. It is tricky
> > enough to get Java 8 set up for some developers. Every version we support
> > adds complexity for contributors. Personally, I think we should be
> thinking
> > about dropping even Java 8 if we wait until next year and just follow the
> > latest LTS line... but I am happy to keep with Java 8 as a baseline for
> > now. Java 7 is only supported for a limited number of environments right
> > now, whereas Java 8 has multiple vendors supporting it against multiple
> > platforms at least until mid 2023.
> >
> > We hold back the entire community if we stick on a base version for too
> > long.
> >
>
> totally true !
>
> We should only move to "target/source" 8, we do not need to change the code
> (lamdas), we can do it whenever we want
>


+1

If it helps these figures tend to encourage to make java 8 the mainstream
for maven as well:
1. https://snyk.io/blog/jvm-ecosystem-report-2018/
2. https://www.infoq.com/articles/java-jvm-trends-2019/
3. https://www.jetbrains.com/lp/devecosystem-2019/java/


>
> Enrico
>
>
>
> >
> > On Tue, 29 Oct 2019 at 13:00, Michael Osipov <1983-01...@gmx.net> wrote:
> >
> > > Why not have 3.7.0 plugin updates and other non-technical stuff, have
> it
> > > parallely maintained for some time and move with Maven 3.8.0 to Java 8
> > > next year?!
> > >
> > > Does that sound like a plan? I'd be happy with that. I'd also expect
> > > an announcement on dev@, announce@ and users@.
> > >
> > > Michael
> > >
> > > > Gesendet: Dienstag, 29. Oktober 2019 um 13:49 Uhr
> > > > Von: "Stephen Connolly" 
> > > > An: "Maven Developers List" 
> > > > Betreff: Re: [DISCUSS] Maven 3.7.0
> > > >
> > > > On Tue, 29 Oct 2019 at 12:47, Stephen Connolly <
> > > > stephen.alan.conno...@gmail.com> wrote:
> > > >
> > > > > We already have a version policy:
> > > > >
> > >
> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
> > > > >
> > > >
> > > > (while that page says draft, the proposal was on-list in 2014 and
> just
> > > > converted into a wiki page afterwards - hence why the examples use
> 2014
> > > > dates)
> > > >
> > > >
> > > > > > The development line of Maven core should require a minimum JRE
> > > version
> > > > > that is no older than 18 months after the end of Oracle's public
> > > updates
> > > > > for that JRE version at the time that the first version of the
> > > development
> > > > > line was released, but may require a higher minimum JRE version if
> > > other
> > > > > requirements dictate a higher JRE version.
> > > > >
> > > > > End of public updates for Java 8 from Oracle was January 2019, thus
> > if
> > > we
> > > > > cut a new minor version we would be Java 8 but not Java 7.
> > > > >
> > > > >
> > > > > On Tue, 29 Oct 2019 at 12:28, Tibor Digana  >
> > > wrote:
> > > > >
> > > > >> Stephen, we are in loop.
> > > > >> Of course I know these technical things.
> > > > >> But I am saying, and I am not alone (Michael Osipov too), that I
> > agree
> > > > >> with
> > > > >> sources 1.8, but there must be1.  the Vote with milestones
> regarding
> > > Maven
> > > > >> and another Vote regarding plugins, and 2. written list of
> pros/cons
> > > > >> regarding J8 and 3. developer guideline for J8 (for devs,
> > consultants,
> > > > >> another professions as well in the team).
> > > > >> You know, with video calls, all these public emails would be gone
> > > within
> > > > >> one or two hours, I am sure!
> > > > >> I am also sure that we will have another code preferences and
> > > therefore we
> > > > >> should have some guideline. For instance, I like to have clear OOP
> > in
> > > the
> > > > >> public class/interfaces and Lambda in private code. And there are
> a
> > > lot of
> > > > >> stuff, like parallel streams ala thread pool of non-daemon
> threads,
> > > > >> performance of streams (when, how stream is constructed, etc),
> Date
> > > Time
> > > > >> API is new as well.
> > > > >>
> > > > >> No benefit for the community with J7 sources but yes with J8 code.
> > > Believe
> > > > >> me, this is true. Michael mentioned that as well.
> > > > >>
> > > > >
> > > > > Not true. Java 8 bytecode adds additional metadata that speeds up
> > > > > classloading (but only when the class graph is all Java 8)
> > > > >
> > > > >
> > > > >>
> > > > >> It is also true that we have a lot of bugs, and it is true that
> > Maven
> > > > >> needs
> > > > >> to have breakthrough features like reproducible build and User
> POM,
> > > Docker
> > > > >> prefetched cache, etc.
> > > > >> I have no argument against these things. The only problem that I
> > have
> > > and
> > > > >> Michael has is the way how this is managed but it is the only
> > trivial
> > > > >> problem that we can solve between us.
> > > > >>
> > > > >>
> > > > >>
> > > > >>

Re: Re: [DISCUSS] Maven 3.7.0

[Enrico Olivelli]

Il giorno mar 29 ott 2019 alle ore 14:22 Stephen Connolly <
stephen.alan.conno...@gmail.com> ha scritto:

> Because maintaining Java 7 is a barrier to new contributors. It is tricky
> enough to get Java 8 set up for some developers. Every version we support
> adds complexity for contributors. Personally, I think we should be thinking
> about dropping even Java 8 if we wait until next year and just follow the
> latest LTS line... but I am happy to keep with Java 8 as a baseline for
> now. Java 7 is only supported for a limited number of environments right
> now, whereas Java 8 has multiple vendors supporting it against multiple
> platforms at least until mid 2023.
>
> We hold back the entire community if we stick on a base version for too
> long.
>

totally true !

We should only move to "target/source" 8, we do not need to change the code
(lamdas), we can do it whenever we want

Enrico



>
> On Tue, 29 Oct 2019 at 13:00, Michael Osipov <1983-01...@gmx.net> wrote:
>
> > Why not have 3.7.0 plugin updates and other non-technical stuff, have it
> > parallely maintained for some time and move with Maven 3.8.0 to Java 8
> > next year?!
> >
> > Does that sound like a plan? I'd be happy with that. I'd also expect
> > an announcement on dev@, announce@ and users@.
> >
> > Michael
> >
> > > Gesendet: Dienstag, 29. Oktober 2019 um 13:49 Uhr
> > > Von: "Stephen Connolly" 
> > > An: "Maven Developers List" 
> > > Betreff: Re: [DISCUSS] Maven 3.7.0
> > >
> > > On Tue, 29 Oct 2019 at 12:47, Stephen Connolly <
> > > stephen.alan.conno...@gmail.com> wrote:
> > >
> > > > We already have a version policy:
> > > >
> > https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
> > > >
> > >
> > > (while that page says draft, the proposal was on-list in 2014 and just
> > > converted into a wiki page afterwards - hence why the examples use 2014
> > > dates)
> > >
> > >
> > > > > The development line of Maven core should require a minimum JRE
> > version
> > > > that is no older than 18 months after the end of Oracle's public
> > updates
> > > > for that JRE version at the time that the first version of the
> > development
> > > > line was released, but may require a higher minimum JRE version if
> > other
> > > > requirements dictate a higher JRE version.
> > > >
> > > > End of public updates for Java 8 from Oracle was January 2019, thus
> if
> > we
> > > > cut a new minor version we would be Java 8 but not Java 7.
> > > >
> > > >
> > > > On Tue, 29 Oct 2019 at 12:28, Tibor Digana 
> > wrote:
> > > >
> > > >> Stephen, we are in loop.
> > > >> Of course I know these technical things.
> > > >> But I am saying, and I am not alone (Michael Osipov too), that I
> agree
> > > >> with
> > > >> sources 1.8, but there must be1.  the Vote with milestones regarding
> > Maven
> > > >> and another Vote regarding plugins, and 2. written list of pros/cons
> > > >> regarding J8 and 3. developer guideline for J8 (for devs,
> consultants,
> > > >> another professions as well in the team).
> > > >> You know, with video calls, all these public emails would be gone
> > within
> > > >> one or two hours, I am sure!
> > > >> I am also sure that we will have another code preferences and
> > therefore we
> > > >> should have some guideline. For instance, I like to have clear OOP
> in
> > the
> > > >> public class/interfaces and Lambda in private code. And there are a
> > lot of
> > > >> stuff, like parallel streams ala thread pool of non-daemon threads,
> > > >> performance of streams (when, how stream is constructed, etc), Date
> > Time
> > > >> API is new as well.
> > > >>
> > > >> No benefit for the community with J7 sources but yes with J8 code.
> > Believe
> > > >> me, this is true. Michael mentioned that as well.
> > > >>
> > > >
> > > > Not true. Java 8 bytecode adds additional metadata that speeds up
> > > > classloading (but only when the class graph is all Java 8)
> > > >
> > > >
> > > >>
> > > >> It is also true that we have a lot of bugs, and it is true that
> Maven
> > > >> needs
> > > >> to have breakthrough features like reproducible build and User POM,
> > Docker
> > > >> prefetched cache, etc.
> > > >> I have no argument against these things. The only problem that I
> have
> > and
> > > >> Michael has is the way how this is managed but it is the only
> trivial
> > > >> problem that we can solve between us.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> On Tue, Oct 29, 2019 at 1:04 PM Stephen Connolly <
> > > >> stephen.alan.conno...@gmail.com> wrote:
> > > >>
> > > >> > You cannot have Java 8 sources produce Java 7 bytecode with the
> > Java 8's
> > > >> > javac.
> > > >> >
> > > >> > -target must be >= -source
> > > >> >
> > > >> > So to say:
> > > >> >
> > > >> > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
> > > >> >
> > > >> > Is not possible, you'll get something like:
> > > >> >
> > > >> > $ javac Test -source 1.8 -target 1.7
> > > >> > javac: source release 1.8 requires target release 1.8

Re: Re: Re: [DISCUSS] Maven 3.7.0

[Michael Osipov]

I would absolutely not want to drop Java 8 before 2023 or later for the
same vendor support you have mentioned.

It is a good baseline for the years for now. Always consider that provide
a build tool and not a cutting-edge Spring Boot application.

Michael

> Gesendet: Dienstag, 29. Oktober 2019 um 14:21 Uhr
> Von: "Stephen Connolly" 
> An: "Maven Developers List" 
> Betreff: Re: Re: [DISCUSS] Maven 3.7.0
>
> Because maintaining Java 7 is a barrier to new contributors. It is tricky
> enough to get Java 8 set up for some developers. Every version we support
> adds complexity for contributors. Personally, I think we should be thinking
> about dropping even Java 8 if we wait until next year and just follow the
> latest LTS line... but I am happy to keep with Java 8 as a baseline for
> now. Java 7 is only supported for a limited number of environments right
> now, whereas Java 8 has multiple vendors supporting it against multiple
> platforms at least until mid 2023.
> 
> We hold back the entire community if we stick on a base version for too
> long.
> 
> On Tue, 29 Oct 2019 at 13:00, Michael Osipov <1983-01...@gmx.net> wrote:
> 
> > Why not have 3.7.0 plugin updates and other non-technical stuff, have it
> > parallely maintained for some time and move with Maven 3.8.0 to Java 8
> > next year?!
> >
> > Does that sound like a plan? I'd be happy with that. I'd also expect
> > an announcement on dev@, announce@ and users@.
> >
> > Michael
> >
> > > Gesendet: Dienstag, 29. Oktober 2019 um 13:49 Uhr
> > > Von: "Stephen Connolly" 
> > > An: "Maven Developers List" 
> > > Betreff: Re: [DISCUSS] Maven 3.7.0
> > >
> > > On Tue, 29 Oct 2019 at 12:47, Stephen Connolly <
> > > stephen.alan.conno...@gmail.com> wrote:
> > >
> > > > We already have a version policy:
> > > >
> > https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
> > > >
> > >
> > > (while that page says draft, the proposal was on-list in 2014 and just
> > > converted into a wiki page afterwards - hence why the examples use 2014
> > > dates)
> > >
> > >
> > > > > The development line of Maven core should require a minimum JRE
> > version
> > > > that is no older than 18 months after the end of Oracle's public
> > updates
> > > > for that JRE version at the time that the first version of the
> > development
> > > > line was released, but may require a higher minimum JRE version if
> > other
> > > > requirements dictate a higher JRE version.
> > > >
> > > > End of public updates for Java 8 from Oracle was January 2019, thus if
> > we
> > > > cut a new minor version we would be Java 8 but not Java 7.
> > > >
> > > >
> > > > On Tue, 29 Oct 2019 at 12:28, Tibor Digana 
> > wrote:
> > > >
> > > >> Stephen, we are in loop.
> > > >> Of course I know these technical things.
> > > >> But I am saying, and I am not alone (Michael Osipov too), that I agree
> > > >> with
> > > >> sources 1.8, but there must be1.  the Vote with milestones regarding
> > Maven
> > > >> and another Vote regarding plugins, and 2. written list of pros/cons
> > > >> regarding J8 and 3. developer guideline for J8 (for devs, consultants,
> > > >> another professions as well in the team).
> > > >> You know, with video calls, all these public emails would be gone
> > within
> > > >> one or two hours, I am sure!
> > > >> I am also sure that we will have another code preferences and
> > therefore we
> > > >> should have some guideline. For instance, I like to have clear OOP in
> > the
> > > >> public class/interfaces and Lambda in private code. And there are a
> > lot of
> > > >> stuff, like parallel streams ala thread pool of non-daemon threads,
> > > >> performance of streams (when, how stream is constructed, etc), Date
> > Time
> > > >> API is new as well.
> > > >>
> > > >> No benefit for the community with J7 sources but yes with J8 code.
> > Believe
> > > >> me, this is true. Michael mentioned that as well.
> > > >>
> > > >
> > > > Not true. Java 8 bytecode adds additional metadata that speeds up
> > > > classloading (but only when the class graph is all Java 8)
> > > >
> > > >
> > > >>
> > > >> It is also true that we have a lot of bugs, and it is true that Maven
> > > >> needs
> > > >> to have breakthrough features like reproducible build and User POM,
> > Docker
> > > >> prefetched cache, etc.
> > > >> I have no argument against these things. The only problem that I have
> > and
> > > >> Michael has is the way how this is managed but it is the only trivial
> > > >> problem that we can solve between us.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> On Tue, Oct 29, 2019 at 1:04 PM Stephen Connolly <
> > > >> stephen.alan.conno...@gmail.com> wrote:
> > > >>
> > > >> > You cannot have Java 8 sources produce Java 7 bytecode with the
> > Java 8's
> > > >> > javac.
> > > >> >
> > > >> > -target must be >= -source
> > > >> >
> > > >> > So to say:
> > > >> >
> > > >> > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
> > > >> >
> > > >> > Is not possible, 

Re: Re: [DISCUSS] Maven 3.7.0

[Stephen Connolly]

Because maintaining Java 7 is a barrier to new contributors. It is tricky
enough to get Java 8 set up for some developers. Every version we support
adds complexity for contributors. Personally, I think we should be thinking
about dropping even Java 8 if we wait until next year and just follow the
latest LTS line... but I am happy to keep with Java 8 as a baseline for
now. Java 7 is only supported for a limited number of environments right
now, whereas Java 8 has multiple vendors supporting it against multiple
platforms at least until mid 2023.

We hold back the entire community if we stick on a base version for too
long.

On Tue, 29 Oct 2019 at 13:00, Michael Osipov <1983-01...@gmx.net> wrote:

> Why not have 3.7.0 plugin updates and other non-technical stuff, have it
> parallely maintained for some time and move with Maven 3.8.0 to Java 8
> next year?!
>
> Does that sound like a plan? I'd be happy with that. I'd also expect
> an announcement on dev@, announce@ and users@.
>
> Michael
>
> > Gesendet: Dienstag, 29. Oktober 2019 um 13:49 Uhr
> > Von: "Stephen Connolly" 
> > An: "Maven Developers List" 
> > Betreff: Re: [DISCUSS] Maven 3.7.0
> >
> > On Tue, 29 Oct 2019 at 12:47, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > We already have a version policy:
> > >
> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
> > >
> >
> > (while that page says draft, the proposal was on-list in 2014 and just
> > converted into a wiki page afterwards - hence why the examples use 2014
> > dates)
> >
> >
> > > > The development line of Maven core should require a minimum JRE
> version
> > > that is no older than 18 months after the end of Oracle's public
> updates
> > > for that JRE version at the time that the first version of the
> development
> > > line was released, but may require a higher minimum JRE version if
> other
> > > requirements dictate a higher JRE version.
> > >
> > > End of public updates for Java 8 from Oracle was January 2019, thus if
> we
> > > cut a new minor version we would be Java 8 but not Java 7.
> > >
> > >
> > > On Tue, 29 Oct 2019 at 12:28, Tibor Digana 
> wrote:
> > >
> > >> Stephen, we are in loop.
> > >> Of course I know these technical things.
> > >> But I am saying, and I am not alone (Michael Osipov too), that I agree
> > >> with
> > >> sources 1.8, but there must be1.  the Vote with milestones regarding
> Maven
> > >> and another Vote regarding plugins, and 2. written list of pros/cons
> > >> regarding J8 and 3. developer guideline for J8 (for devs, consultants,
> > >> another professions as well in the team).
> > >> You know, with video calls, all these public emails would be gone
> within
> > >> one or two hours, I am sure!
> > >> I am also sure that we will have another code preferences and
> therefore we
> > >> should have some guideline. For instance, I like to have clear OOP in
> the
> > >> public class/interfaces and Lambda in private code. And there are a
> lot of
> > >> stuff, like parallel streams ala thread pool of non-daemon threads,
> > >> performance of streams (when, how stream is constructed, etc), Date
> Time
> > >> API is new as well.
> > >>
> > >> No benefit for the community with J7 sources but yes with J8 code.
> Believe
> > >> me, this is true. Michael mentioned that as well.
> > >>
> > >
> > > Not true. Java 8 bytecode adds additional metadata that speeds up
> > > classloading (but only when the class graph is all Java 8)
> > >
> > >
> > >>
> > >> It is also true that we have a lot of bugs, and it is true that Maven
> > >> needs
> > >> to have breakthrough features like reproducible build and User POM,
> Docker
> > >> prefetched cache, etc.
> > >> I have no argument against these things. The only problem that I have
> and
> > >> Michael has is the way how this is managed but it is the only trivial
> > >> problem that we can solve between us.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Tue, Oct 29, 2019 at 1:04 PM Stephen Connolly <
> > >> stephen.alan.conno...@gmail.com> wrote:
> > >>
> > >> > You cannot have Java 8 sources produce Java 7 bytecode with the
> Java 8's
> > >> > javac.
> > >> >
> > >> > -target must be >= -source
> > >> >
> > >> > So to say:
> > >> >
> > >> > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
> > >> >
> > >> > Is not possible, you'll get something like:
> > >> >
> > >> > $ javac Test -source 1.8 -target 1.7
> > >> > javac: source release 1.8 requires target release 1.8
> > >> >
> > >> > While we could use something like
> > >> https://github.com/luontola/retrolambda
> > >> > its usage is not without significant risks. You really need to be
> very
> > >> > careful in how you use it, and the effort is IMHO far exceeding the
> > >> risk.
> > >> > Much better to just say Maven 3.7.0 is requires the runtime JVM be
> Java
> > >> 8+,
> > >> > use toolchains if you need to compile or unit tests with older JDKs.
> > >> >
> > >> > We have agreed before that upgrading the Maven 

Re: Re: [DISCUSS] Maven 3.7.0

[Michael Osipov]

Why not have 3.7.0 plugin updates and other non-technical stuff, have it
parallely maintained for some time and move with Maven 3.8.0 to Java 8 next 
year?!

Does that sound like a plan? I'd be happy with that. I'd also expect
an announcement on dev@, announce@ and users@.

Michael

> Gesendet: Dienstag, 29. Oktober 2019 um 13:49 Uhr
> Von: "Stephen Connolly" 
> An: "Maven Developers List" 
> Betreff: Re: [DISCUSS] Maven 3.7.0
>
> On Tue, 29 Oct 2019 at 12:47, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
> 
> > We already have a version policy:
> > https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
> >
> 
> (while that page says draft, the proposal was on-list in 2014 and just
> converted into a wiki page afterwards - hence why the examples use 2014
> dates)
> 
> 
> > > The development line of Maven core should require a minimum JRE version
> > that is no older than 18 months after the end of Oracle's public updates
> > for that JRE version at the time that the first version of the development
> > line was released, but may require a higher minimum JRE version if other
> > requirements dictate a higher JRE version.
> >
> > End of public updates for Java 8 from Oracle was January 2019, thus if we
> > cut a new minor version we would be Java 8 but not Java 7.
> >
> >
> > On Tue, 29 Oct 2019 at 12:28, Tibor Digana  wrote:
> >
> >> Stephen, we are in loop.
> >> Of course I know these technical things.
> >> But I am saying, and I am not alone (Michael Osipov too), that I agree
> >> with
> >> sources 1.8, but there must be1.  the Vote with milestones regarding Maven
> >> and another Vote regarding plugins, and 2. written list of pros/cons
> >> regarding J8 and 3. developer guideline for J8 (for devs, consultants,
> >> another professions as well in the team).
> >> You know, with video calls, all these public emails would be gone within
> >> one or two hours, I am sure!
> >> I am also sure that we will have another code preferences and therefore we
> >> should have some guideline. For instance, I like to have clear OOP in the
> >> public class/interfaces and Lambda in private code. And there are a lot of
> >> stuff, like parallel streams ala thread pool of non-daemon threads,
> >> performance of streams (when, how stream is constructed, etc), Date Time
> >> API is new as well.
> >>
> >> No benefit for the community with J7 sources but yes with J8 code. Believe
> >> me, this is true. Michael mentioned that as well.
> >>
> >
> > Not true. Java 8 bytecode adds additional metadata that speeds up
> > classloading (but only when the class graph is all Java 8)
> >
> >
> >>
> >> It is also true that we have a lot of bugs, and it is true that Maven
> >> needs
> >> to have breakthrough features like reproducible build and User POM, Docker
> >> prefetched cache, etc.
> >> I have no argument against these things. The only problem that I have and
> >> Michael has is the way how this is managed but it is the only trivial
> >> problem that we can solve between us.
> >>
> >>
> >>
> >>
> >>
> >> On Tue, Oct 29, 2019 at 1:04 PM Stephen Connolly <
> >> stephen.alan.conno...@gmail.com> wrote:
> >>
> >> > You cannot have Java 8 sources produce Java 7 bytecode with the Java 8's
> >> > javac.
> >> >
> >> > -target must be >= -source
> >> >
> >> > So to say:
> >> >
> >> > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
> >> >
> >> > Is not possible, you'll get something like:
> >> >
> >> > $ javac Test -source 1.8 -target 1.7
> >> > javac: source release 1.8 requires target release 1.8
> >> >
> >> > While we could use something like
> >> https://github.com/luontola/retrolambda
> >> > its usage is not without significant risks. You really need to be very
> >> > careful in how you use it, and the effort is IMHO far exceeding the
> >> risk.
> >> > Much better to just say Maven 3.7.0 is requires the runtime JVM be Java
> >> 8+,
> >> > use toolchains if you need to compile or unit tests with older JDKs.
> >> >
> >> > We have agreed before that upgrading the Maven minor or major version
> >> would
> >> > affect the JREs that Maven can run on. Basically following a one and one
> >> > back for Oracle supported JDKs, thus 3.7.0 per that policy would be
> >> forced
> >> > to Java 8 as minimum anyway in other words, our users should be
> >> > expecting us to go Java 8 as baseline.
> >> >
> >> > On Tue, 29 Oct 2019 at 10:28, Tibor Digana 
> >> wrote:
> >> >
> >> > > Stephen, what issue with current toolchain you mean?
> >> > >
> >> > > On Tue, Oct 29, 2019 at 11:11 AM Stephen Connolly <
> >> > > stephen.alan.conno...@gmail.com> wrote:
> >> > >
> >> > > > On Tue, 29 Oct 2019 at 08:02, Tibor Digana 
> >> > > wrote:
> >> > > >
> >> > > > > Robert, I saw the code. The class has a method which returns
> >> Lambda
> >> > > > > function. The whole class was designed with OOP. The OOP is a good
> >> > > thing
> >> > > > > which you should follow and follow this approach and not to return
> >> > 

Re: [DISCUSS] Maven 3.7.0

[Stephen Connolly]

On Tue, 29 Oct 2019 at 12:49, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On Tue, 29 Oct 2019 at 12:47, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> We already have a version policy:
>> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
>>
>
> (while that page says draft, the proposal was on-list in 2014 and just
> converted into a wiki page afterwards - hence why the examples use 2014
> dates)
>

https://lists.apache.org/thread.html/41a693d0e5787fa8af33ab0724a95c3ed0374fe2d860c2357a5565a9@1392995450@%3Cdev.maven.apache.org%3E


>
>> > The development line of Maven core should require a minimum JRE version
>> that is no older than 18 months after the end of Oracle's public updates
>> for that JRE version at the time that the first version of the development
>> line was released, but may require a higher minimum JRE version if other
>> requirements dictate a higher JRE version.
>>
>> End of public updates for Java 8 from Oracle was January 2019, thus if we
>> cut a new minor version we would be Java 8 but not Java 7.
>>
>>
>> On Tue, 29 Oct 2019 at 12:28, Tibor Digana 
>> wrote:
>>
>>> Stephen, we are in loop.
>>> Of course I know these technical things.
>>> But I am saying, and I am not alone (Michael Osipov too), that I agree
>>> with
>>> sources 1.8, but there must be1.  the Vote with milestones regarding
>>> Maven
>>> and another Vote regarding plugins, and 2. written list of pros/cons
>>> regarding J8 and 3. developer guideline for J8 (for devs, consultants,
>>> another professions as well in the team).
>>> You know, with video calls, all these public emails would be gone within
>>> one or two hours, I am sure!
>>> I am also sure that we will have another code preferences and therefore
>>> we
>>> should have some guideline. For instance, I like to have clear OOP in the
>>> public class/interfaces and Lambda in private code. And there are a lot
>>> of
>>> stuff, like parallel streams ala thread pool of non-daemon threads,
>>> performance of streams (when, how stream is constructed, etc), Date Time
>>> API is new as well.
>>>
>>> No benefit for the community with J7 sources but yes with J8 code.
>>> Believe
>>> me, this is true. Michael mentioned that as well.
>>>
>>
>> Not true. Java 8 bytecode adds additional metadata that speeds up
>> classloading (but only when the class graph is all Java 8)
>>
>>
>>>
>>> It is also true that we have a lot of bugs, and it is true that Maven
>>> needs
>>> to have breakthrough features like reproducible build and User POM,
>>> Docker
>>> prefetched cache, etc.
>>> I have no argument against these things. The only problem that I have and
>>> Michael has is the way how this is managed but it is the only trivial
>>> problem that we can solve between us.
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Oct 29, 2019 at 1:04 PM Stephen Connolly <
>>> stephen.alan.conno...@gmail.com> wrote:
>>>
>>> > You cannot have Java 8 sources produce Java 7 bytecode with the Java
>>> 8's
>>> > javac.
>>> >
>>> > -target must be >= -source
>>> >
>>> > So to say:
>>> >
>>> > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
>>> >
>>> > Is not possible, you'll get something like:
>>> >
>>> > $ javac Test -source 1.8 -target 1.7
>>> > javac: source release 1.8 requires target release 1.8
>>> >
>>> > While we could use something like
>>> https://github.com/luontola/retrolambda
>>> > its usage is not without significant risks. You really need to be very
>>> > careful in how you use it, and the effort is IMHO far exceeding the
>>> risk.
>>> > Much better to just say Maven 3.7.0 is requires the runtime JVM be
>>> Java 8+,
>>> > use toolchains if you need to compile or unit tests with older JDKs.
>>> >
>>> > We have agreed before that upgrading the Maven minor or major version
>>> would
>>> > affect the JREs that Maven can run on. Basically following a one and
>>> one
>>> > back for Oracle supported JDKs, thus 3.7.0 per that policy would be
>>> forced
>>> > to Java 8 as minimum anyway in other words, our users should be
>>> > expecting us to go Java 8 as baseline.
>>> >
>>> > On Tue, 29 Oct 2019 at 10:28, Tibor Digana 
>>> wrote:
>>> >
>>> > > Stephen, what issue with current toolchain you mean?
>>> > >
>>> > > On Tue, Oct 29, 2019 at 11:11 AM Stephen Connolly <
>>> > > stephen.alan.conno...@gmail.com> wrote:
>>> > >
>>> > > > On Tue, 29 Oct 2019 at 08:02, Tibor Digana >> >
>>> > > wrote:
>>> > > >
>>> > > > > Robert, I saw the code. The class has a method which returns
>>> Lambda
>>> > > > > function. The whole class was designed with OOP. The OOP is a
>>> good
>>> > > thing
>>> > > > > which you should follow and follow this approach and not to
>>> return
>>> > the
>>> > > > > labda function. Basically it is a precedense created in the PR
>>> saying
>>> > > > that
>>> > > > > now J8 has to be used in the bytecode.
>>> > > > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
>>> > > > >
>>> > > >
>>> > > > That is not 

Re: [DISCUSS] Maven 3.7.0

[Stephen Connolly]

On Tue, 29 Oct 2019 at 12:47, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> We already have a version policy:
> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
>

(while that page says draft, the proposal was on-list in 2014 and just
converted into a wiki page afterwards - hence why the examples use 2014
dates)


> > The development line of Maven core should require a minimum JRE version
> that is no older than 18 months after the end of Oracle's public updates
> for that JRE version at the time that the first version of the development
> line was released, but may require a higher minimum JRE version if other
> requirements dictate a higher JRE version.
>
> End of public updates for Java 8 from Oracle was January 2019, thus if we
> cut a new minor version we would be Java 8 but not Java 7.
>
>
> On Tue, 29 Oct 2019 at 12:28, Tibor Digana  wrote:
>
>> Stephen, we are in loop.
>> Of course I know these technical things.
>> But I am saying, and I am not alone (Michael Osipov too), that I agree
>> with
>> sources 1.8, but there must be1.  the Vote with milestones regarding Maven
>> and another Vote regarding plugins, and 2. written list of pros/cons
>> regarding J8 and 3. developer guideline for J8 (for devs, consultants,
>> another professions as well in the team).
>> You know, with video calls, all these public emails would be gone within
>> one or two hours, I am sure!
>> I am also sure that we will have another code preferences and therefore we
>> should have some guideline. For instance, I like to have clear OOP in the
>> public class/interfaces and Lambda in private code. And there are a lot of
>> stuff, like parallel streams ala thread pool of non-daemon threads,
>> performance of streams (when, how stream is constructed, etc), Date Time
>> API is new as well.
>>
>> No benefit for the community with J7 sources but yes with J8 code. Believe
>> me, this is true. Michael mentioned that as well.
>>
>
> Not true. Java 8 bytecode adds additional metadata that speeds up
> classloading (but only when the class graph is all Java 8)
>
>
>>
>> It is also true that we have a lot of bugs, and it is true that Maven
>> needs
>> to have breakthrough features like reproducible build and User POM, Docker
>> prefetched cache, etc.
>> I have no argument against these things. The only problem that I have and
>> Michael has is the way how this is managed but it is the only trivial
>> problem that we can solve between us.
>>
>>
>>
>>
>>
>> On Tue, Oct 29, 2019 at 1:04 PM Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>> > You cannot have Java 8 sources produce Java 7 bytecode with the Java 8's
>> > javac.
>> >
>> > -target must be >= -source
>> >
>> > So to say:
>> >
>> > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
>> >
>> > Is not possible, you'll get something like:
>> >
>> > $ javac Test -source 1.8 -target 1.7
>> > javac: source release 1.8 requires target release 1.8
>> >
>> > While we could use something like
>> https://github.com/luontola/retrolambda
>> > its usage is not without significant risks. You really need to be very
>> > careful in how you use it, and the effort is IMHO far exceeding the
>> risk.
>> > Much better to just say Maven 3.7.0 is requires the runtime JVM be Java
>> 8+,
>> > use toolchains if you need to compile or unit tests with older JDKs.
>> >
>> > We have agreed before that upgrading the Maven minor or major version
>> would
>> > affect the JREs that Maven can run on. Basically following a one and one
>> > back for Oracle supported JDKs, thus 3.7.0 per that policy would be
>> forced
>> > to Java 8 as minimum anyway in other words, our users should be
>> > expecting us to go Java 8 as baseline.
>> >
>> > On Tue, 29 Oct 2019 at 10:28, Tibor Digana 
>> wrote:
>> >
>> > > Stephen, what issue with current toolchain you mean?
>> > >
>> > > On Tue, Oct 29, 2019 at 11:11 AM Stephen Connolly <
>> > > stephen.alan.conno...@gmail.com> wrote:
>> > >
>> > > > On Tue, 29 Oct 2019 at 08:02, Tibor Digana 
>> > > wrote:
>> > > >
>> > > > > Robert, I saw the code. The class has a method which returns
>> Lambda
>> > > > > function. The whole class was designed with OOP. The OOP is a good
>> > > thing
>> > > > > which you should follow and follow this approach and not to return
>> > the
>> > > > > labda function. Basically it is a precedense created in the PR
>> saying
>> > > > that
>> > > > > now J8 has to be used in the bytecode.
>> > > > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
>> > > > >
>> > > >
>> > > > That is not possible using the current toolchains. Let's just go
>> with
>> > > Java
>> > > > 8. There seems no good reason to hold back
>> > > >
>> > > >
>> > > > >
>> > > > > On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte <
>> rfscho...@apache.org
>> > >
>> > > > > wrote:
>> > > > >
>> > > > > > The outcome is quite clear to me. There no clear 'No' to add
>> this
>> > > > > > build/consumer feature 

Re: [DISCUSS] Maven 3.7.0

[Stephen Connolly]

We already have a version policy:
https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy

> The development line of Maven core should require a minimum JRE version
that is no older than 18 months after the end of Oracle's public updates
for that JRE version at the time that the first version of the development
line was released, but may require a higher minimum JRE version if other
requirements dictate a higher JRE version.

End of public updates for Java 8 from Oracle was January 2019, thus if we
cut a new minor version we would be Java 8 but not Java 7.


On Tue, 29 Oct 2019 at 12:28, Tibor Digana  wrote:

> Stephen, we are in loop.
> Of course I know these technical things.
> But I am saying, and I am not alone (Michael Osipov too), that I agree with
> sources 1.8, but there must be1.  the Vote with milestones regarding Maven
> and another Vote regarding plugins, and 2. written list of pros/cons
> regarding J8 and 3. developer guideline for J8 (for devs, consultants,
> another professions as well in the team).
> You know, with video calls, all these public emails would be gone within
> one or two hours, I am sure!
> I am also sure that we will have another code preferences and therefore we
> should have some guideline. For instance, I like to have clear OOP in the
> public class/interfaces and Lambda in private code. And there are a lot of
> stuff, like parallel streams ala thread pool of non-daemon threads,
> performance of streams (when, how stream is constructed, etc), Date Time
> API is new as well.
>
> No benefit for the community with J7 sources but yes with J8 code. Believe
> me, this is true. Michael mentioned that as well.
>

Not true. Java 8 bytecode adds additional metadata that speeds up
classloading (but only when the class graph is all Java 8)


>
> It is also true that we have a lot of bugs, and it is true that Maven needs
> to have breakthrough features like reproducible build and User POM, Docker
> prefetched cache, etc.
> I have no argument against these things. The only problem that I have and
> Michael has is the way how this is managed but it is the only trivial
> problem that we can solve between us.
>
>
>
>
>
> On Tue, Oct 29, 2019 at 1:04 PM Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > You cannot have Java 8 sources produce Java 7 bytecode with the Java 8's
> > javac.
> >
> > -target must be >= -source
> >
> > So to say:
> >
> > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
> >
> > Is not possible, you'll get something like:
> >
> > $ javac Test -source 1.8 -target 1.7
> > javac: source release 1.8 requires target release 1.8
> >
> > While we could use something like
> https://github.com/luontola/retrolambda
> > its usage is not without significant risks. You really need to be very
> > careful in how you use it, and the effort is IMHO far exceeding the risk.
> > Much better to just say Maven 3.7.0 is requires the runtime JVM be Java
> 8+,
> > use toolchains if you need to compile or unit tests with older JDKs.
> >
> > We have agreed before that upgrading the Maven minor or major version
> would
> > affect the JREs that Maven can run on. Basically following a one and one
> > back for Oracle supported JDKs, thus 3.7.0 per that policy would be
> forced
> > to Java 8 as minimum anyway in other words, our users should be
> > expecting us to go Java 8 as baseline.
> >
> > On Tue, 29 Oct 2019 at 10:28, Tibor Digana 
> wrote:
> >
> > > Stephen, what issue with current toolchain you mean?
> > >
> > > On Tue, Oct 29, 2019 at 11:11 AM Stephen Connolly <
> > > stephen.alan.conno...@gmail.com> wrote:
> > >
> > > > On Tue, 29 Oct 2019 at 08:02, Tibor Digana 
> > > wrote:
> > > >
> > > > > Robert, I saw the code. The class has a method which returns Lambda
> > > > > function. The whole class was designed with OOP. The OOP is a good
> > > thing
> > > > > which you should follow and follow this approach and not to return
> > the
> > > > > labda function. Basically it is a precedense created in the PR
> saying
> > > > that
> > > > > now J8 has to be used in the bytecode.
> > > > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
> > > > >
> > > >
> > > > That is not possible using the current toolchains. Let's just go with
> > > Java
> > > > 8. There seems no good reason to hold back
> > > >
> > > >
> > > > >
> > > > > On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte <
> rfscho...@apache.org
> > >
> > > > > wrote:
> > > > >
> > > > > > The outcome is quite clear to me. There no clear 'No' to add this
> > > > > > build/consumer feature into 3.7.0, so we'll add it which implies
> we
> > > > must
> > > > > > move to Java 8 due to new APIs with Java 8 class signatures.
> > > > > >
> > > > > > But first we need to deliver a 3.6.3 regression release.
> > > > > >
> > > > > > Robert
> > > > > >
> > > > > > On 29-10-2019 05:53:25, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > > > > wrote:
> > > > > > +1, the risk is more or 

Re: [DISCUSS] Maven 3.7.0

[Tibor Digana]

Stephen, we are in loop.
Of course I know these technical things.
But I am saying, and I am not alone (Michael Osipov too), that I agree with
sources 1.8, but there must be1.  the Vote with milestones regarding Maven
and another Vote regarding plugins, and 2. written list of pros/cons
regarding J8 and 3. developer guideline for J8 (for devs, consultants,
another professions as well in the team).
You know, with video calls, all these public emails would be gone within
one or two hours, I am sure!
I am also sure that we will have another code preferences and therefore we
should have some guideline. For instance, I like to have clear OOP in the
public class/interfaces and Lambda in private code. And there are a lot of
stuff, like parallel streams ala thread pool of non-daemon threads,
performance of streams (when, how stream is constructed, etc), Date Time
API is new as well.

No benefit for the community with J7 sources but yes with J8 code. Believe
me, this is true. Michael mentioned that as well.

It is also true that we have a lot of bugs, and it is true that Maven needs
to have breakthrough features like reproducible build and User POM, Docker
prefetched cache, etc.
I have no argument against these things. The only problem that I have and
Michael has is the way how this is managed but it is the only trivial
problem that we can solve between us.





On Tue, Oct 29, 2019 at 1:04 PM Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> You cannot have Java 8 sources produce Java 7 bytecode with the Java 8's
> javac.
>
> -target must be >= -source
>
> So to say:
>
> > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
>
> Is not possible, you'll get something like:
>
> $ javac Test -source 1.8 -target 1.7
> javac: source release 1.8 requires target release 1.8
>
> While we could use something like https://github.com/luontola/retrolambda
> its usage is not without significant risks. You really need to be very
> careful in how you use it, and the effort is IMHO far exceeding the risk.
> Much better to just say Maven 3.7.0 is requires the runtime JVM be Java 8+,
> use toolchains if you need to compile or unit tests with older JDKs.
>
> We have agreed before that upgrading the Maven minor or major version would
> affect the JREs that Maven can run on. Basically following a one and one
> back for Oracle supported JDKs, thus 3.7.0 per that policy would be forced
> to Java 8 as minimum anyway in other words, our users should be
> expecting us to go Java 8 as baseline.
>
> On Tue, 29 Oct 2019 at 10:28, Tibor Digana  wrote:
>
> > Stephen, what issue with current toolchain you mean?
> >
> > On Tue, Oct 29, 2019 at 11:11 AM Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > On Tue, 29 Oct 2019 at 08:02, Tibor Digana 
> > wrote:
> > >
> > > > Robert, I saw the code. The class has a method which returns Lambda
> > > > function. The whole class was designed with OOP. The OOP is a good
> > thing
> > > > which you should follow and follow this approach and not to return
> the
> > > > labda function. Basically it is a precedense created in the PR saying
> > > that
> > > > now J8 has to be used in the bytecode.
> > > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
> > > >
> > >
> > > That is not possible using the current toolchains. Let's just go with
> > Java
> > > 8. There seems no good reason to hold back
> > >
> > >
> > > >
> > > > On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte  >
> > > > wrote:
> > > >
> > > > > The outcome is quite clear to me. There no clear 'No' to add this
> > > > > build/consumer feature into 3.7.0, so we'll add it which implies we
> > > must
> > > > > move to Java 8 due to new APIs with Java 8 class signatures.
> > > > >
> > > > > But first we need to deliver a 3.6.3 regression release.
> > > > >
> > > > > Robert
> > > > >
> > > > > On 29-10-2019 05:53:25, Romain Manni-Bucau 
> > > > wrote:
> > > > > +1, the risk is more or less 0 since we can still use branches for
> > > > > potential fixes for "old" projects using frozen java and maven
> > versions
> > > > > anyway
> > > > >
> > > > > Guess we can even be very precautionous doing 1. an upgrade to
> > bytecode
> > > > > version without any code change (to change the major version in
> > > > bytecode),
> > > > > 2. a M1 to let users test it if some still doubt.
> > > > >
> > > > > Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit :
> > > > >
> > > > > > so what is the status of this?
> > > > > > will we discuss in 2025 about being able to use java 8 apis or do
> > we
> > > > have
> > > > > > to wait 2030?
> > > > > > Sorry to be sarcastic but not moving forward it's certainly a
> > reason
> > > > why
> > > > > we
> > > > > > do not have more people participating in the project
> > > > > > It is so frustrating to be stuck with old apis...
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote:
> > > > > >
> > > > > > > I have to fully 

Re: [DISCUSS] Maven 3.7.0

[Stephen Connolly]

You cannot have Java 8 sources produce Java 7 bytecode with the Java 8's
javac.

-target must be >= -source

So to say:

> So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!

Is not possible, you'll get something like:

$ javac Test -source 1.8 -target 1.7
javac: source release 1.8 requires target release 1.8

While we could use something like https://github.com/luontola/retrolambda
its usage is not without significant risks. You really need to be very
careful in how you use it, and the effort is IMHO far exceeding the risk.
Much better to just say Maven 3.7.0 is requires the runtime JVM be Java 8+,
use toolchains if you need to compile or unit tests with older JDKs.

We have agreed before that upgrading the Maven minor or major version would
affect the JREs that Maven can run on. Basically following a one and one
back for Oracle supported JDKs, thus 3.7.0 per that policy would be forced
to Java 8 as minimum anyway in other words, our users should be
expecting us to go Java 8 as baseline.

On Tue, 29 Oct 2019 at 10:28, Tibor Digana  wrote:

> Stephen, what issue with current toolchain you mean?
>
> On Tue, Oct 29, 2019 at 11:11 AM Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > On Tue, 29 Oct 2019 at 08:02, Tibor Digana 
> wrote:
> >
> > > Robert, I saw the code. The class has a method which returns Lambda
> > > function. The whole class was designed with OOP. The OOP is a good
> thing
> > > which you should follow and follow this approach and not to return the
> > > labda function. Basically it is a precedense created in the PR saying
> > that
> > > now J8 has to be used in the bytecode.
> > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
> > >
> >
> > That is not possible using the current toolchains. Let's just go with
> Java
> > 8. There seems no good reason to hold back
> >
> >
> > >
> > > On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte 
> > > wrote:
> > >
> > > > The outcome is quite clear to me. There no clear 'No' to add this
> > > > build/consumer feature into 3.7.0, so we'll add it which implies we
> > must
> > > > move to Java 8 due to new APIs with Java 8 class signatures.
> > > >
> > > > But first we need to deliver a 3.6.3 regression release.
> > > >
> > > > Robert
> > > >
> > > > On 29-10-2019 05:53:25, Romain Manni-Bucau 
> > > wrote:
> > > > +1, the risk is more or less 0 since we can still use branches for
> > > > potential fixes for "old" projects using frozen java and maven
> versions
> > > > anyway
> > > >
> > > > Guess we can even be very precautionous doing 1. an upgrade to
> bytecode
> > > > version without any code change (to change the major version in
> > > bytecode),
> > > > 2. a M1 to let users test it if some still doubt.
> > > >
> > > > Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit :
> > > >
> > > > > so what is the status of this?
> > > > > will we discuss in 2025 about being able to use java 8 apis or do
> we
> > > have
> > > > > to wait 2030?
> > > > > Sorry to be sarcastic but not moving forward it's certainly a
> reason
> > > why
> > > > we
> > > > > do not have more people participating in the project
> > > > > It is so frustrating to be stuck with old apis...
> > > > >
> > > > >
> > > > >
> > > > > On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote:
> > > > >
> > > > > > I have to fully agree on Michael Osipov. This discussion is
> > > > > > contraproductive from the time perspective.
> > > > > > He explained the situation in Maven very clearly that we have
> over
> > > 1800
> > > > > > bugs and here we are talking about javac compiler version which
> > does
> > > > not
> > > > > > fix these bugs.
> > > > > > We know that our community is quite big but we also know that we
> > have
> > > > > only
> > > > > > few several developers who regularily provides fixes for the bug
> > and
> > > > they
> > > > > > do it for free!
> > > > > > So my advice is to leave these talks alone about technology lobby
> > > (seen
> > > > > on
> > > > > > ML from outside as well) and rather concentrate on the bug. We
> have
> > > > seen
> > > > > > that the users/contributors handled performance issues and fixed
> > them
> > > > > which
> > > > > > means that these contributors got very good proficiency level!
> > > > > >
> > > > > > On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <>
> > > > > ashitkin.a...@gmail.com
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Totally disagree on the point. Writing java7 code after 8 makes
> > you
> > > > > feel
> > > > > > > suffering - because instead of expressive stream based
> operations
> > > and
> > > > > > > lambdas you write pointless iterators and copy collections.
> > > > > > > It is purely subjective opinion that lambdas make code less
> > > readable
> > > > -
> > > > > at
> > > > > > > least there is an absolutely opposite opinion
> > > > > > >
> > > > > > > Thank you
> > > > > > > Aleks
> > > > > > >
> > > > > > > On 2019/10/03 12:47:35, Paul Hammant wrote:
> > > > > 

Re: [DISCUSS] Maven 3.7.0

[Tibor Digana]

Stephen, what issue with current toolchain you mean?

On Tue, Oct 29, 2019 at 11:11 AM Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On Tue, 29 Oct 2019 at 08:02, Tibor Digana  wrote:
>
> > Robert, I saw the code. The class has a method which returns Lambda
> > function. The whole class was designed with OOP. The OOP is a good thing
> > which you should follow and follow this approach and not to return the
> > labda function. Basically it is a precedense created in the PR saying
> that
> > now J8 has to be used in the bytecode.
> > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
> >
>
> That is not possible using the current toolchains. Let's just go with Java
> 8. There seems no good reason to hold back
>
>
> >
> > On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte 
> > wrote:
> >
> > > The outcome is quite clear to me. There no clear 'No' to add this
> > > build/consumer feature into 3.7.0, so we'll add it which implies we
> must
> > > move to Java 8 due to new APIs with Java 8 class signatures.
> > >
> > > But first we need to deliver a 3.6.3 regression release.
> > >
> > > Robert
> > >
> > > On 29-10-2019 05:53:25, Romain Manni-Bucau 
> > wrote:
> > > +1, the risk is more or less 0 since we can still use branches for
> > > potential fixes for "old" projects using frozen java and maven versions
> > > anyway
> > >
> > > Guess we can even be very precautionous doing 1. an upgrade to bytecode
> > > version without any code change (to change the major version in
> > bytecode),
> > > 2. a M1 to let users test it if some still doubt.
> > >
> > > Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit :
> > >
> > > > so what is the status of this?
> > > > will we discuss in 2025 about being able to use java 8 apis or do we
> > have
> > > > to wait 2030?
> > > > Sorry to be sarcastic but not moving forward it's certainly a reason
> > why
> > > we
> > > > do not have more people participating in the project
> > > > It is so frustrating to be stuck with old apis...
> > > >
> > > >
> > > >
> > > > On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote:
> > > >
> > > > > I have to fully agree on Michael Osipov. This discussion is
> > > > > contraproductive from the time perspective.
> > > > > He explained the situation in Maven very clearly that we have over
> > 1800
> > > > > bugs and here we are talking about javac compiler version which
> does
> > > not
> > > > > fix these bugs.
> > > > > We know that our community is quite big but we also know that we
> have
> > > > only
> > > > > few several developers who regularily provides fixes for the bug
> and
> > > they
> > > > > do it for free!
> > > > > So my advice is to leave these talks alone about technology lobby
> > (seen
> > > > on
> > > > > ML from outside as well) and rather concentrate on the bug. We have
> > > seen
> > > > > that the users/contributors handled performance issues and fixed
> them
> > > > which
> > > > > means that these contributors got very good proficiency level!
> > > > >
> > > > > On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <>
> > > > ashitkin.a...@gmail.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > Totally disagree on the point. Writing java7 code after 8 makes
> you
> > > > feel
> > > > > > suffering - because instead of expressive stream based operations
> > and
> > > > > > lambdas you write pointless iterators and copy collections.
> > > > > > It is purely subjective opinion that lambdas make code less
> > readable
> > > -
> > > > at
> > > > > > least there is an absolutely opposite opinion
> > > > > >
> > > > > > Thank you
> > > > > > Aleks
> > > > > >
> > > > > > On 2019/10/03 12:47:35, Paul Hammant wrote:
> > > > > > > Who codes for 18 months before discovering that qa/prod are not
> > > > > > compatible,
> > > > > > > anymore? Especially if Google ship a use-this-Pom starter.
> > > > > > >
> > > > > > > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty Harold <>
> > > > > elh...@ibiblio.org
> > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Theoretically that would work. In practice though, every
> > project
> > > > I've
> > > > > > > > seen convert to Java 8 rapidly starts adding lambdas that
> make
> > > the
> > > > > > > > code more obfuscated for no good reason and soon introduces
> > hard
> > > > > > > > dependencies on Java 8, intentionally or otherwise. At a bare
> > > > > minimum,
> > > > > > > > a CI environment that runs Java 7 is required.
> > > > > > > >
> > > > > > > > On Thu, Oct 3, 2019 at 8:25 AM Paul Hammant
> > > > > wrote:
> > > > > > > > >
> > > > > > > > > Would jdk 8 for maven itself and a target of 7 for the
> > compiler
> > > > > > (etc) for
> > > > > > > > > maven-using projects be ok?
> > > > > > > > >
> > > > > > > > > On Thu, Oct 3, 2019 at 1:15 PM Elliotte Rusty Harold <>
> > > > > > elh...@ibiblio.org
> > > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Strong -1 on Java 8 as the minimum version. Google Cloud
> > > > Platform

Re: Did you see dependabot?

[Paul Hammant]

Summary ?

Re: Did you see dependabot?

[Martijn Dashorst]

On Sat, Oct 19, 2019 at 8:51 PM Enrico Olivelli  wrote:
>
> I see value in it.
> But from a legal point of viewthere is no human who sends the PR, so in
> theory we cannot accept such patches, can we?

I'm not a lawyer, nor a scientist, but this paper sounds like a
compelling read on this subject:

http://arno.uvt.nl/show.cgi?fid=145318

Martijn

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

Re: [DISCUSS] Maven 3.7.0

[Stephen Connolly]

On Tue, 29 Oct 2019 at 08:02, Tibor Digana  wrote:

> Robert, I saw the code. The class has a method which returns Lambda
> function. The whole class was designed with OOP. The OOP is a good thing
> which you should follow and follow this approach and not to return the
> labda function. Basically it is a precedense created in the PR saying that
> now J8 has to be used in the bytecode.
> So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
>

That is not possible using the current toolchains. Let's just go with Java
8. There seems no good reason to hold back


>
> On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte 
> wrote:
>
> > The outcome is quite clear to me. There no clear 'No' to add this
> > build/consumer feature into 3.7.0, so we'll add it which implies we must
> > move to Java 8 due to new APIs with Java 8 class signatures.
> >
> > But first we need to deliver a 3.6.3 regression release.
> >
> > Robert
> >
> > On 29-10-2019 05:53:25, Romain Manni-Bucau 
> wrote:
> > +1, the risk is more or less 0 since we can still use branches for
> > potential fixes for "old" projects using frozen java and maven versions
> > anyway
> >
> > Guess we can even be very precautionous doing 1. an upgrade to bytecode
> > version without any code change (to change the major version in
> bytecode),
> > 2. a M1 to let users test it if some still doubt.
> >
> > Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit :
> >
> > > so what is the status of this?
> > > will we discuss in 2025 about being able to use java 8 apis or do we
> have
> > > to wait 2030?
> > > Sorry to be sarcastic but not moving forward it's certainly a reason
> why
> > we
> > > do not have more people participating in the project
> > > It is so frustrating to be stuck with old apis...
> > >
> > >
> > >
> > > On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote:
> > >
> > > > I have to fully agree on Michael Osipov. This discussion is
> > > > contraproductive from the time perspective.
> > > > He explained the situation in Maven very clearly that we have over
> 1800
> > > > bugs and here we are talking about javac compiler version which does
> > not
> > > > fix these bugs.
> > > > We know that our community is quite big but we also know that we have
> > > only
> > > > few several developers who regularily provides fixes for the bug and
> > they
> > > > do it for free!
> > > > So my advice is to leave these talks alone about technology lobby
> (seen
> > > on
> > > > ML from outside as well) and rather concentrate on the bug. We have
> > seen
> > > > that the users/contributors handled performance issues and fixed them
> > > which
> > > > means that these contributors got very good proficiency level!
> > > >
> > > > On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <>
> > > ashitkin.a...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Totally disagree on the point. Writing java7 code after 8 makes you
> > > feel
> > > > > suffering - because instead of expressive stream based operations
> and
> > > > > lambdas you write pointless iterators and copy collections.
> > > > > It is purely subjective opinion that lambdas make code less
> readable
> > -
> > > at
> > > > > least there is an absolutely opposite opinion
> > > > >
> > > > > Thank you
> > > > > Aleks
> > > > >
> > > > > On 2019/10/03 12:47:35, Paul Hammant wrote:
> > > > > > Who codes for 18 months before discovering that qa/prod are not
> > > > > compatible,
> > > > > > anymore? Especially if Google ship a use-this-Pom starter.
> > > > > >
> > > > > > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty Harold <>
> > > > elh...@ibiblio.org
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Theoretically that would work. In practice though, every
> project
> > > I've
> > > > > > > seen convert to Java 8 rapidly starts adding lambdas that make
> > the
> > > > > > > code more obfuscated for no good reason and soon introduces
> hard
> > > > > > > dependencies on Java 8, intentionally or otherwise. At a bare
> > > > minimum,
> > > > > > > a CI environment that runs Java 7 is required.
> > > > > > >
> > > > > > > On Thu, Oct 3, 2019 at 8:25 AM Paul Hammant
> > > > wrote:
> > > > > > > >
> > > > > > > > Would jdk 8 for maven itself and a target of 7 for the
> compiler
> > > > > (etc) for
> > > > > > > > maven-using projects be ok?
> > > > > > > >
> > > > > > > > On Thu, Oct 3, 2019 at 1:15 PM Elliotte Rusty Harold <>
> > > > > elh...@ibiblio.org
> > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Strong -1 on Java 8 as the minimum version. Google Cloud
> > > Platform
> > > > > has
> > > > > > > > > lots of products and customers that still require Java 7.
> If
> > > > Maven
> > > > > > > > > requires Java 8, we'd have to stick to the latest of
> > whichever
> > > > > release
> > > > > > > > > does support Java 7 for at least a year and I'm guessing
> > > longer.
> > > > > > > > >
> > > > > > > > > On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte <>
> > > > > 

Re: [DISCUSS] Maven 3.7.0

[Romain Manni-Bucau]

@Tibor: the design comes from a time functional programming was not
mainstream and quite cumbersome with java, let's embrace current way of
doing and move forward otherwise we can go to attic ;).

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



Le mar. 29 oct. 2019 à 09:02, Tibor Digana  a
écrit :

> Robert, I saw the code. The class has a method which returns Lambda
> function. The whole class was designed with OOP. The OOP is a good thing
> which you should follow and follow this approach and not to return the
> labda function. Basically it is a precedense created in the PR saying that
> now J8 has to be used in the bytecode.
> So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
>
> On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte 
> wrote:
>
> > The outcome is quite clear to me. There no clear 'No' to add this
> > build/consumer feature into 3.7.0, so we'll add it which implies we must
> > move to Java 8 due to new APIs with Java 8 class signatures.
> >
> > But first we need to deliver a 3.6.3 regression release.
> >
> > Robert
> >
> > On 29-10-2019 05:53:25, Romain Manni-Bucau 
> wrote:
> > +1, the risk is more or less 0 since we can still use branches for
> > potential fixes for "old" projects using frozen java and maven versions
> > anyway
> >
> > Guess we can even be very precautionous doing 1. an upgrade to bytecode
> > version without any code change (to change the major version in
> bytecode),
> > 2. a M1 to let users test it if some still doubt.
> >
> > Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit :
> >
> > > so what is the status of this?
> > > will we discuss in 2025 about being able to use java 8 apis or do we
> have
> > > to wait 2030?
> > > Sorry to be sarcastic but not moving forward it's certainly a reason
> why
> > we
> > > do not have more people participating in the project
> > > It is so frustrating to be stuck with old apis...
> > >
> > >
> > >
> > > On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote:
> > >
> > > > I have to fully agree on Michael Osipov. This discussion is
> > > > contraproductive from the time perspective.
> > > > He explained the situation in Maven very clearly that we have over
> 1800
> > > > bugs and here we are talking about javac compiler version which does
> > not
> > > > fix these bugs.
> > > > We know that our community is quite big but we also know that we have
> > > only
> > > > few several developers who regularily provides fixes for the bug and
> > they
> > > > do it for free!
> > > > So my advice is to leave these talks alone about technology lobby
> (seen
> > > on
> > > > ML from outside as well) and rather concentrate on the bug. We have
> > seen
> > > > that the users/contributors handled performance issues and fixed them
> > > which
> > > > means that these contributors got very good proficiency level!
> > > >
> > > > On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <>
> > > ashitkin.a...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Totally disagree on the point. Writing java7 code after 8 makes you
> > > feel
> > > > > suffering - because instead of expressive stream based operations
> and
> > > > > lambdas you write pointless iterators and copy collections.
> > > > > It is purely subjective opinion that lambdas make code less
> readable
> > -
> > > at
> > > > > least there is an absolutely opposite opinion
> > > > >
> > > > > Thank you
> > > > > Aleks
> > > > >
> > > > > On 2019/10/03 12:47:35, Paul Hammant wrote:
> > > > > > Who codes for 18 months before discovering that qa/prod are not
> > > > > compatible,
> > > > > > anymore? Especially if Google ship a use-this-Pom starter.
> > > > > >
> > > > > > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty Harold <>
> > > > elh...@ibiblio.org
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Theoretically that would work. In practice though, every
> project
> > > I've
> > > > > > > seen convert to Java 8 rapidly starts adding lambdas that make
> > the
> > > > > > > code more obfuscated for no good reason and soon introduces
> hard
> > > > > > > dependencies on Java 8, intentionally or otherwise. At a bare
> > > > minimum,
> > > > > > > a CI environment that runs Java 7 is required.
> > > > > > >
> > > > > > > On Thu, Oct 3, 2019 at 8:25 AM Paul Hammant
> > > > wrote:
> > > > > > > >
> > > > > > > > Would jdk 8 for maven itself and a target of 7 for the
> compiler
> > > > > (etc) for
> > > > > > > > maven-using projects be ok?
> > > > > > > >
> > > > > > > > On Thu, Oct 3, 2019 at 1:15 PM Elliotte Rusty Harold <>
> > > > > elh...@ibiblio.org
> > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Strong -1 on Java 8 as the minimum version. Google Cloud
> > > Platform
> 

Re: [DISCUSS] Maven 3.7.0

[Tibor Digana]

Robert, I saw the code. The class has a method which returns Lambda
function. The whole class was designed with OOP. The OOP is a good thing
which you should follow and follow this approach and not to return the
labda function. Basically it is a precedense created in the PR saying that
now J8 has to be used in the bytecode.
So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!

On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte  wrote:

> The outcome is quite clear to me. There no clear 'No' to add this
> build/consumer feature into 3.7.0, so we'll add it which implies we must
> move to Java 8 due to new APIs with Java 8 class signatures.
>
> But first we need to deliver a 3.6.3 regression release.
>
> Robert
>
> On 29-10-2019 05:53:25, Romain Manni-Bucau  wrote:
> +1, the risk is more or less 0 since we can still use branches for
> potential fixes for "old" projects using frozen java and maven versions
> anyway
>
> Guess we can even be very precautionous doing 1. an upgrade to bytecode
> version without any code change (to change the major version in bytecode),
> 2. a M1 to let users test it if some still doubt.
>
> Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit :
>
> > so what is the status of this?
> > will we discuss in 2025 about being able to use java 8 apis or do we have
> > to wait 2030?
> > Sorry to be sarcastic but not moving forward it's certainly a reason why
> we
> > do not have more people participating in the project
> > It is so frustrating to be stuck with old apis...
> >
> >
> >
> > On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote:
> >
> > > I have to fully agree on Michael Osipov. This discussion is
> > > contraproductive from the time perspective.
> > > He explained the situation in Maven very clearly that we have over 1800
> > > bugs and here we are talking about javac compiler version which does
> not
> > > fix these bugs.
> > > We know that our community is quite big but we also know that we have
> > only
> > > few several developers who regularily provides fixes for the bug and
> they
> > > do it for free!
> > > So my advice is to leave these talks alone about technology lobby (seen
> > on
> > > ML from outside as well) and rather concentrate on the bug. We have
> seen
> > > that the users/contributors handled performance issues and fixed them
> > which
> > > means that these contributors got very good proficiency level!
> > >
> > > On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <>
> > ashitkin.a...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Totally disagree on the point. Writing java7 code after 8 makes you
> > feel
> > > > suffering - because instead of expressive stream based operations and
> > > > lambdas you write pointless iterators and copy collections.
> > > > It is purely subjective opinion that lambdas make code less readable
> -
> > at
> > > > least there is an absolutely opposite opinion
> > > >
> > > > Thank you
> > > > Aleks
> > > >
> > > > On 2019/10/03 12:47:35, Paul Hammant wrote:
> > > > > Who codes for 18 months before discovering that qa/prod are not
> > > > compatible,
> > > > > anymore? Especially if Google ship a use-this-Pom starter.
> > > > >
> > > > > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty Harold <>
> > > elh...@ibiblio.org
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Theoretically that would work. In practice though, every project
> > I've
> > > > > > seen convert to Java 8 rapidly starts adding lambdas that make
> the
> > > > > > code more obfuscated for no good reason and soon introduces hard
> > > > > > dependencies on Java 8, intentionally or otherwise. At a bare
> > > minimum,
> > > > > > a CI environment that runs Java 7 is required.
> > > > > >
> > > > > > On Thu, Oct 3, 2019 at 8:25 AM Paul Hammant
> > > wrote:
> > > > > > >
> > > > > > > Would jdk 8 for maven itself and a target of 7 for the compiler
> > > > (etc) for
> > > > > > > maven-using projects be ok?
> > > > > > >
> > > > > > > On Thu, Oct 3, 2019 at 1:15 PM Elliotte Rusty Harold <>
> > > > elh...@ibiblio.org
> > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Strong -1 on Java 8 as the minimum version. Google Cloud
> > Platform
> > > > has
> > > > > > > > lots of products and customers that still require Java 7. If
> > > Maven
> > > > > > > > requires Java 8, we'd have to stick to the latest of
> whichever
> > > > release
> > > > > > > > does support Java 7 for at least a year and I'm guessing
> > longer.
> > > > > > > >
> > > > > > > > On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte <>
> > > > rfscho...@apache.org>
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > TLDR; introduce maven.experimental.buildconsumer and push
> > Java
> > > > > > > > requirement
> > > > > > > > > to Java 8
> > > > > > > > >
> > > > > > > > > now that Maven 3.6.2 is out for a couple of weeks, it seems
> > > like
> > > > we
> > > > > > > > didn't
> > > > > > > > > face real regressions.
> > > > > > > > > The only one 

Re: [DISCUSS] Maven 3.7.0

[Robert Scholte]

The outcome is quite clear to me. There no clear 'No' to add this 
build/consumer feature into 3.7.0, so we'll add it which implies we must move 
to Java 8 due to new APIs with Java 8 class signatures.

But first we need to deliver a 3.6.3 regression release.

Robert

On 29-10-2019 05:53:25, Romain Manni-Bucau  wrote:
+1, the risk is more or less 0 since we can still use branches for
potential fixes for "old" projects using frozen java and maven versions
anyway

Guess we can even be very precautionous doing 1. an upgrade to bytecode
version without any code change (to change the major version in bytecode),
2. a M1 to let users test it if some still doubt.

Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit :

> so what is the status of this?
> will we discuss in 2025 about being able to use java 8 apis or do we have
> to wait 2030?
> Sorry to be sarcastic but not moving forward it's certainly a reason why we
> do not have more people participating in the project
> It is so frustrating to be stuck with old apis...
>
>
>
> On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote:
>
> > I have to fully agree on Michael Osipov. This discussion is
> > contraproductive from the time perspective.
> > He explained the situation in Maven very clearly that we have over 1800
> > bugs and here we are talking about javac compiler version which does not
> > fix these bugs.
> > We know that our community is quite big but we also know that we have
> only
> > few several developers who regularily provides fixes for the bug and they
> > do it for free!
> > So my advice is to leave these talks alone about technology lobby (seen
> on
> > ML from outside as well) and rather concentrate on the bug. We have seen
> > that the users/contributors handled performance issues and fixed them
> which
> > means that these contributors got very good proficiency level!
> >
> > On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <>
> ashitkin.a...@gmail.com
> > >
> > wrote:
> >
> > > Totally disagree on the point. Writing java7 code after 8 makes you
> feel
> > > suffering - because instead of expressive stream based operations and
> > > lambdas you write pointless iterators and copy collections.
> > > It is purely subjective opinion that lambdas make code less readable -
> at
> > > least there is an absolutely opposite opinion
> > >
> > > Thank you
> > > Aleks
> > >
> > > On 2019/10/03 12:47:35, Paul Hammant wrote:
> > > > Who codes for 18 months before discovering that qa/prod are not
> > > compatible,
> > > > anymore? Especially if Google ship a use-this-Pom starter.
> > > >
> > > > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty Harold <>
> > elh...@ibiblio.org
> > > >
> > > > wrote:
> > > >
> > > > > Theoretically that would work. In practice though, every project
> I've
> > > > > seen convert to Java 8 rapidly starts adding lambdas that make the
> > > > > code more obfuscated for no good reason and soon introduces hard
> > > > > dependencies on Java 8, intentionally or otherwise. At a bare
> > minimum,
> > > > > a CI environment that runs Java 7 is required.
> > > > >
> > > > > On Thu, Oct 3, 2019 at 8:25 AM Paul Hammant
> > wrote:
> > > > > >
> > > > > > Would jdk 8 for maven itself and a target of 7 for the compiler
> > > (etc) for
> > > > > > maven-using projects be ok?
> > > > > >
> > > > > > On Thu, Oct 3, 2019 at 1:15 PM Elliotte Rusty Harold <>
> > > elh...@ibiblio.org
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Strong -1 on Java 8 as the minimum version. Google Cloud
> Platform
> > > has
> > > > > > > lots of products and customers that still require Java 7. If
> > Maven
> > > > > > > requires Java 8, we'd have to stick to the latest of whichever
> > > release
> > > > > > > does support Java 7 for at least a year and I'm guessing
> longer.
> > > > > > >
> > > > > > > On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte <>
> > > rfscho...@apache.org>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > TLDR; introduce maven.experimental.buildconsumer and push
> Java
> > > > > > > requirement
> > > > > > > > to Java 8
> > > > > > > >
> > > > > > > > now that Maven 3.6.2 is out for a couple of weeks, it seems
> > like
> > > we
> > > > > > > didn't
> > > > > > > > face real regressions.
> > > > > > > > The only one might be tricky is the issue related to Tycho.
> > > > > > > >
> > > > > > > > However, I think we're ready to push Maven to the next level.
> > > > > > > >
> > > > > > > > For those actively reading this list, they should recognize
> the
> > > need
> > > > > for
> > > > > > > > splitting up the pom as it is on the local system versus the
> > pom
> > > > > being
> > > > > > > > uploaded. Once we truly control this mechanism we can think
> of
> > > > > > > > improvements on model 5.0.0 and new fileformats.
> > > > > > > >
> > > > > > > > I've created and implemented MNG-6656[1]. It also contains a
> > zip
> > > > > with an
> > > > > > > > example (original, patched, README) to