Hi Karl Heinz,
On Tue, 23 Aug 2016 21:51:11 +0200
Karl Heinz Marbaise wrote:
> Hi Björn,
>
> On 23/08/16 08:25, Björn Höfling wrote:
> > I want to build maven without haven _ANY_ maven/plugin binary. How
> > can I do that?
>
> First you can do that only till Maven 3.3.9 starting with Maven 3.4
Le mercredi 24 août 2016 18:41:59 Fred Cooke a écrit :
> Fair call re embedded pom, however it's quite convenient to just browse to
> it and read.
>
> I've occasionally gone looking for details from poms of artefacts and found
> a mess and missing stuff, and been annoyed. It probably wasn't gradle
Fair call re embedded pom, however it's quite convenient to just browse to
it and read.
I've occasionally gone looking for details from poms of artefacts and found
a mess and missing stuff, and been annoyed. It probably wasn't gradle's
fault, though. Just a sloppy author. If I'm honest I wouldn't
Le mercredi 24 août 2016 14:04:12 Fred Cooke a écrit :
> That should have separation between builder Pom and consumer Pom. For
> packaging=pom we deploy the builder Pom using classifier=build
> *for all other packaging a we do not deploy the builder Pom*.
>
> I don't like the sound of this. The de
No problem. I will change logic and i will run my test. Unfortunately
JDK9 cannot be used in Jenkins because java compiler 1.5 is
unsupported by jigsaw jdk however in plugin 3.0 it would be just fine.
Checking module-info.class that exists makes sense to me.
Cheers
Tibor
On Tue, Aug 23, 2016 at 2
Le mercredi 24 août 2016 11:29:26 Fred Cooke a écrit :
> Someone nailed it when they said it'd be two big decisions, one for JRE one
> for MVN.
>
> But here's the reality: People are just going to grab and use "the latest",
> whatever it is.
>
> What does that mean? We'll probably start seeing de
Le mardi 23 août 2016 22:52:18 Christian Schulte a écrit :
> Am 08/23/16 um 22:33 schrieb Hervé BOUTEMY:
> > yes, people providing libraries have this big choice to do: when to
> > upgrade
> > minimum JRE version for consumers.
> >
> > yes, we can add them another new big decision to take: when to
Le mercredi 24 août 2016 00:45:28 Christian Schulte a écrit :
> Am 08/24/16 um 00:40 schrieb Christian Schulte:
> > Am 08/23/16 um 22:33 schrieb Hervé BOUTEMY:
> >> yes, people providing libraries have this big choice to do: when to
> >> upgrade
> >> minimum JRE version for consumers.
> >>
> >> ye
Le mardi 23 août 2016 23:25:30 Christian Schulte a écrit :
> Am 08/23/16 um 23:17 schrieb Paul Benedict:
> > Truthfully, I must say a lot of this conversation sounds much like
> > Subversion's client/server architecture:
> >
> > *) The server has a Repository Format version = "build POM"
> > *) Th
That should have separation between builder Pom and consumer Pom. For
packaging=pom we deploy the builder Pom using classifier=build
*for all other packaging a we do not deploy the builder Pom*.
I don't like the sound of this. The deployed artefacts should include the
exact POM in use to build the
On Tuesday 23 August 2016, Paul Benedict wrote:
> On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte > wrote:
>
> > Am 08/24/16 um 00:08 schrieb Paul Benedict:
> > > POM and a future major version POM? I am hinting at a strategy for
> > forward
> > > compatibility.
> >
> > Is forward compatibili
Someone nailed it when they said it'd be two big decisions, one for JRE one
for MVN.
But here's the reality: People are just going to grab and use "the latest",
whatever it is.
What does that mean? We'll probably start seeing dependencies we can't
consume, but want to, and otherwise could.
A goo
Am 08/24/16 um 00:57 schrieb Paul Benedict:
> escape hatch here. If a client can't understand what's being specified,
> then what else can be done but fail?
That's what caught my attention as well. Is there anyone around knowing
about any kind of software which can handle forward compatiblity in a
On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte wrote:
> Am 08/24/16 um 00:08 schrieb Paul Benedict:
> > POM and a future major version POM? I am hinting at a strategy for
> forward
> > compatibility.
>
> Is forward compatibility really needed/required?
>
I honestly don't know, which is why I
Am 08/24/16 um 00:40 schrieb Christian Schulte:
> Am 08/23/16 um 22:33 schrieb Hervé BOUTEMY:
>> yes, people providing libraries have this big choice to do: when to upgrade
>> minimum JRE version for consumers.
>>
>> yes, we can add them another new big decision to take: when to upgrade
>> minium
Am 08/23/16 um 22:33 schrieb Hervé BOUTEMY:
> yes, people providing libraries have this big choice to do: when to upgrade
> minimum JRE version for consumers.
>
> yes, we can add them another new big decision to take: when to upgrade minium
> Maven version to consume the library?
When that upgr
Am 08/24/16 um 00:08 schrieb Paul Benedict:
> POM and a future major version POM? I am hinting at a strategy for forward
> compatibility.
Is forward compatibility really needed/required? Java developers would
not mind, if the classfiles they produce cannot be used with an older
JRE. Are we really
If to "blow up" is unacceptable, then what is the documented way for a
Maven client to deal with a it doesn't fully support?
Keyword here is *fully* support. Minus tags and values specific to the
4.1.0 POM schema, a high-percentage of the configuration should be
parseable by an older client. Perha
Am 08/23/16 um 01:12 schrieb Stephen Connolly:
> On Monday 22 August 2016, Christian Schulte wrote:
>> That won't scale. What is to note here is that the XML schema or
>> anything syntax does not change between 4.0.0 and 4.1.0. It's just that
>> Maven 3.4 performs the dependency management import
Am 08/23/16 um 23:17 schrieb Paul Benedict:
> Truthfully, I must say a lot of this conversation sounds much like
> Subversion's client/server architecture:
>
> *) The server has a Repository Format version = "build POM"
> *) The clients create a Working Copy version on checkout = "consumer POM"
>
Truthfully, I must say a lot of this conversation sounds much like
Subversion's client/server architecture:
*) The server has a Repository Format version = "build POM"
*) The clients create a Working Copy version on checkout = "consumer POM"
*) Two distinct schema series
*) A client that understan
Hi,
based on different request I cancel the VOTE...
Kind regards
Karl Heinz Marbaise
On 22/08/16 22:01, Karl Heinz Marbaise wrote:
Hi,
We solved 32 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318121&version=12331760
There are still a couple of issues left in J
Am 08/23/16 um 22:52 schrieb Christian Schulte:
> future-proofness, this would need to be reverted as well. Does not solve
> the version range issue, however. This is what makes it impossible to
> deploy a pre-resolved dependency tree to the repository. So maybe that
> is the major issue we need to
Am 08/23/16 um 22:33 schrieb Hervé BOUTEMY:
> yes, people providing libraries have this big choice to do: when to upgrade
> minimum JRE version for consumers.
>
> yes, we can add them another new big decision to take: when to upgrade minium
> Maven version to consume the library?
>
> but with c
Le 23 août 2016 22:08, "Karl Heinz Marbaise" a écrit :
>
> Hi Romains,
>
>
> On 23/08/16 09:56, Romain Manni-Bucau wrote:
>>
>> Hi guys,
>>
>> just saw m-w-p 3.0.0 vote was on the list without
>> https://issues.apache.org/jira/browse/MWAR-262
>
>
> Yes...
>
>
>>
>> When I asked about that some mon
yes, people providing libraries have this big choice to do: when to upgrade
minimum JRE version for consumers.
yes, we can add them another new big decision to take: when to upgrade minium
Maven version to consume the library?
but with consumer pom vs build pom, we should be able to avoid this
Le 23 août 2016 22:10, "Karl Heinz Marbaise" a écrit :
>
> Hi Romain,
>
>
> On 23/08/16 10:22, Romain Manni-Bucau wrote:
>>
>> +1, created another thread about this one (title: "Maven war plugin 3.x:
>> can it finally include MWAR-262?", but not yet moderated I think).
>
>
> The DEV list is only m
Hi Romain,
On 23/08/16 10:22, Romain Manni-Bucau wrote:
+1, created another thread about this one (title: "Maven war plugin 3.x:
can it finally include MWAR-262?", but not yet moderated I think).
The DEV list is only moderated in that way for first time posters...
not every post...
Kind rega
Hi Romains,
On 23/08/16 09:56, Romain Manni-Bucau wrote:
Hi guys,
just saw m-w-p 3.0.0 vote was on the list without
https://issues.apache.org/jira/browse/MWAR-262
Yes...
When I asked about that some months ago the feedback was "not for a minor"
but for 3.0.0 I don't see why it couldn't hav
Hi Björn,
On 23/08/16 08:25, Björn Höfling wrote:
I want to build maven without haven _ANY_ maven/plugin binary. How can
I do that?
First you can do that only till Maven 3.3.9 starting with Maven 3.4.0
you need Maven 3.3.9 to build Maven 3.4.0...Details [1].
The question is why do you want
Github user justinharringa commented on the issue:
https://github.com/apache/maven-surefire/pull/110
Cool. Thanks for the update @Tibor17! :)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have t
+1: here is mine; tested in my project @ MVN 3.2.1 Java 1.8
+1: to MWAR-262 in 3.0.0. Yes it toggles behavior of the config parameter
thus it's a chance to have it in 3.0.
Agree that setting failOnMissingWebXml or permanently creating web.xml must
be really annoying.
On Mon, Aug 22, 2016 at 10:01
Christian, I argue this is a matter of perspective in regards to "solve".
There are two things to solve:
1) Introducing new functionality with POM 4.1/5.0
2) Introducing acceptable responsiveness to the new POM by older tools
Point #1 can be introduced in whatever version of Maven, that is true,
Am 23.08.2016 um 15:53 schrieb Paul Benedict:
> I advise to not introduce any new POM version in the 3.x series. Please do
> that in Maven 4.0 where you can blue sky ideas and green field the
> development. Let the 3.x series be the place to shakeout compatibility
> concerns in gracefully handling
Github user kgyrtkirk closed the pull request at:
https://github.com/apache/maven-surefire/pull/113
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feat
Am 23.08.2016 um 15:53 schrieb Paul Benedict:
> I advise to not introduce any new POM version in the 3.x series. Please do
> that in Maven 4.0 where you can blue sky ideas and green field the
> development.
And how would we solve the issue at hand in Maven 4? We increase the
model version in Maven
Personally I think a change of default value should go in into 3.0.0 rather
than 3.0.1. We have a great oportunity here with v3.0.0 to fix these types
of changes.
/Anders
On Tue, Aug 23, 2016 at 10:22 AM, Romain Manni-Bucau
wrote:
> +1, created another thread about this one (title: "Maven war p
I advise to not introduce any new POM version in the 3.x series. Please do
that in Maven 4.0 where you can blue sky ideas and green field the
development. Let the 3.x series be the place to shakeout compatibility
concerns in gracefully handling the new POM version (like appropriate
warnings and err
All other cases check the Java runtime instead the forked instance, that's
much easier.
The -Xpatch is only interesting if target/classes/module-info.class
exists. So I'd go for that strategy. In fact, that's what the
maven-compiler-plugin will do too to decide if it should use classpath or
Am 08/23/16 um 01:12 schrieb Stephen Connolly:
> On Monday 22 August 2016, Christian Schulte wrote:
>> That won't scale. What is to note here is that the XML schema or
>> anything syntax does not change between 4.0.0 and 4.1.0. It's just that
>> Maven 3.4 performs the dependency management import
I want to obtain java.specification.version from forked JVM started from
Toolchain.
I need to know if the JDK is Jigsaw 9 or lower.
Robert gave me advise to run "java -version" and parse the string but the
problem is that it is VM version and not the specification version of Java
language, and mayb
I want to obtain java.specification.version from forked JVM started from
Toolchain.
I need to know if the JDK is Jigsaw 9 or lower.
Robert gave me advise to run "java -version" and parse the string but the
problem is that it is VM version and not the specification version of Java
language, and mayb
Github user jimma closed the pull request at:
https://github.com/apache/maven-surefire/pull/81
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature i
Github user jimma commented on the issue:
https://github.com/apache/maven-surefire/pull/81
@Tibor17 Thank you.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishe
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/81
@jimma Thank you for contributing! The pull request was merged with master
branch. You can close PR.
---
If your project is set up for it, you can reply to this email and have your
reply appe
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/81
@jimma yes, it's very good work. Thx.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
+1, created another thread about this one (title: "Maven war plugin 3.x:
can it finally include MWAR-262?", but not yet moderated I think). Not
seeing an issue to do it in 3.0.1 and not prevent 3.0.0 but it is quite
important to do it since the default is needed since > 16 years and it is
very pain
Github user jimma commented on the issue:
https://github.com/apache/maven-surefire/pull/81
@Tibor17 Test is added. Is it surefire-integration-tests a good place to
add ?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. I
Sorry to be a party pooper but is there any way we could include MWAR-262
still?
Thanks,
S.
On Mon, Aug 22, 2016 at 10:01 PM, Karl Heinz Marbaise
wrote:
> Hi,
>
> We solved 32 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
> ctId=12318121&version=12331760
>
> There are s
Hi guys,
just saw m-w-p 3.0.0 vote was on the list without
https://issues.apache.org/jira/browse/MWAR-262
When I asked about that some months ago the feedback was "not for a minor"
but for 3.0.0 I don't see why it couldn't have been done. Here is how I see
it:
- changing it now will not break ex
GitHub user jimma reopened a pull request:
https://github.com/apache/maven-surefire/pull/81
Create better report for AssumptionFailure
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/jimma/maven-surefire master
Alternatively you
Github user jimma closed the pull request at:
https://github.com/apache/maven-surefire/pull/115
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
+1 non-binding
/Anders
On Mon, Aug 22, 2016 at 10:01 PM, Karl Heinz Marbaise
wrote:
> Hi,
>
> We solved 32 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
> ctId=12318121&version=12331760
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jir
GitHub user jimma opened a pull request:
https://github.com/apache/maven-surefire/pull/115
[SUREFIRE-1272]:Create better report for AssumptionFailure
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/jimma/maven-surefire master
Al
Github user jimma closed the pull request at:
https://github.com/apache/maven-surefire/pull/81
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature i
55 matches
Mail list logo