On Friday 2 September 2016, Robert Scholte wrote:
> On Wed, 31 Aug 2016 22:51:20 +0200, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> On Wednesday 31 August 2016, Robert Scholte wrote:
>>
>> On Wed, 31 Aug 2016 19:35:02 +0200, Stephen Connolly <
>>> stephen.alan.conno...@gmail
On Wed, 31 Aug 2016 22:51:20 +0200, Stephen Connolly
wrote:
On Wednesday 31 August 2016, Robert Scholte wrote:
On Wed, 31 Aug 2016 19:35:02 +0200, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
On Wednesday 31 August 2016, Christian Schulte wrote:
Am 08/31/16 um 18:39 schri
On Thursday 1 September 2016, Christian Schulte wrote:
> Am 08/31/16 um 22:51 schrieb Stephen Connolly:
> > So for the tests-jar.., that would have a declared dependency on the
> > regular .jar and provide the tree for the test-runtime scope... It may
> even
> > be that there are therefore closer
Am 08/31/16 um 22:51 schrieb Stephen Connolly:
> So for the tests-jar.., that would have a declared dependency on the
> regular .jar and provide the tree for the test-runtime scope... It may even
> be that there are therefore closer overrides of the main artifact's
> dependencies in the test jar's
On Wednesday 31 August 2016, Robert Scholte wrote:
> On Wed, 31 Aug 2016 19:35:02 +0200, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> On Wednesday 31 August 2016, Christian Schulte wrote:
>>
>> Am 08/31/16 um 18:39 schrieb Christian Schulte:
>>> > Am 08/31/16 um 07:52 schrieb
On Wed, 31 Aug 2016 19:35:02 +0200, Stephen Connolly
wrote:
On Wednesday 31 August 2016, Christian Schulte wrote:
Am 08/31/16 um 18:39 schrieb Christian Schulte:
> Am 08/31/16 um 07:52 schrieb Stephen Connolly:
>> I've been thinking about what to call the "consumer Pom"...
>>
>> I think th
Am 08/31/16 um 19:35 schrieb Stephen Connolly:
> On Wednesday 31 August 2016, Christian Schulte wrote:
>>
>>
>> public interface DependencyTreeProvider
>> {
>>
>> DependencyNode getDependencyTree( String logicalScopeName )
>> throws IOException;
>>
>> }
>
>
> Not `String logicalScopeName`
On Wednesday 31 August 2016, Christian Schulte wrote:
> Am 08/31/16 um 18:39 schrieb Christian Schulte:
> > Am 08/31/16 um 07:52 schrieb Stephen Connolly:
> >> I've been thinking about what to call the "consumer Pom"...
> >>
> >> I think this is actually not a project object model, but the projec
Am 08/31/16 um 18:39 schrieb Christian Schulte:
> Am 08/31/16 um 07:52 schrieb Stephen Connolly:
>> I've been thinking about what to call the "consumer Pom"...
>>
>> I think this is actually not a project object model, but the project
>> dependency trees
>>
>> It should list each side artifact and
Am 08/31/16 um 07:52 schrieb Stephen Connolly:
> I've been thinking about what to call the "consumer Pom"...
>
> I think this is actually not a project object model, but the project
> dependency trees
>
> It should list each side artifact and their dependency trees...
>
> So for example:
>
> *
On Wed, 31 Aug 2016 07:52:20 +0200, Stephen Connolly
wrote:
I've been thinking about what to call the "consumer Pom"...
I think this is actually not a project object model, but the project
dependency trees
It should list each side artifact and their dependency trees...
So for example:
* t
I've been thinking about what to call the "consumer Pom"...
I think this is actually not a project object model, but the project
dependency trees
It should list each side artifact and their dependency trees...
So for example:
* the java doc artifacts should depend on the corresponding dependenc
On 29 August 2016 at 23:27, Christian Schulte wrote:
> Am 08/30/16 um 00:16 schrieb Paul Benedict:
> > I see a deployed faulty "consumer pom" to be more more harmful than
> > generating it locally on demand. At least with the local one I can
> upgrade
> > my client to fix a dependency calculation
Am 08/24/16 um 08:23 schrieb Hervé BOUTEMY:
> I don't like classical dependencies version ranges, but the idea of such
> feature for imports looks even worse: the dirty dependency tree will be
> really
> huge, I imagine. And if the content of imported pom changes in the ganre, I
> fear the resu
Am 08/30/16 um 00:51 schrieb Fred Cooke:
> Yes, presumably to be consumed in another build, right? :-)
Another build, an application launcher, etc. I fail to see the
interpolation issue here. What functionality would be lost?
Regards,
--
Christian
--
Yes, presumably to be consumed in another build, right? :-)
On Tue, Aug 30, 2016 at 10:45 AM, Christian Schulte wrote:
> Am 08/30/16 um 00:33 schrieb Fred Cooke:
> > I fail to see how any such flattening can do away with interpolation.
> Your
> > typical nonlib project has say 5-100 deps, each o
Am 08/30/16 um 00:33 schrieb Fred Cooke:
> I fail to see how any such flattening can do away with interpolation. Your
> typical nonlib project has say 5-100 deps, each of which would have a flat
> tree that needs to be compared with and resolved against the others.
As far as I understood the propo
I fail to see how any such flattening can do away with interpolation. Your
typical nonlib project has say 5-100 deps, each of which would have a flat
tree that needs to be compared with and resolved against the others. I can
see it speeding things up due to having all of the information for just th
Am 08/30/16 um 00:16 schrieb Paul Benedict:
> I see a deployed faulty "consumer pom" to be more more harmful than
> generating it locally on demand. At least with the local one I can upgrade
> my client to fix a dependency calculation. There will be no such relief in
> the case of your proposal.
I
Christian, I could argue that's not much different than today. The
"consumer pom" -- no matter how much you distill or flatten it -- will
still require processing. Data is useless without an interpretation. A
Maven client will still have to have to process it, and there will likely
be bugs in that
Am 08/29/16 um 23:35 schrieb Paul Benedict:
> Robert, I am mostly in agreement here. However, the big downside to
> deploying the calculations is that they are forever. Furthermore, deploying
> the "consumer pom" takes away the ability for a newer Maven client with
> resolution bug fixes and/or opt
On Mon, Aug 29, 2016 at 4:07 PM, Robert Scholte
wrote:
> I think that all the fields of a dependency are quite complete. Based on
> the issues I see with moving forward with Aether is that the (complex)
> dependency resolution is done inside Maven. The idea is to not calculate
> this anymore, but
Am 08/29/16 um 23:07 schrieb Robert Scholte:
> dependency resolution is done inside Maven. The idea is to not calculate
> this anymore, but add all transitive dependencies to the consumer pom.
> This would hopefully remove the discussion what all the dependencies are,
> since they're already su
I am using flatten-maven-plugin.
What is the goal for consumer-pom?
My answer is runtime dependencies in general, but we must not forget
the facts that scm, jira is addon which let me to contact the team.
Why you want to deploy both consumer and ordinal POM?
Messy isn't it? And therefore existing t
Am 08/29/16 um 22:48 schrieb Robert Scholte:
> The consumer pom is a completely different beast.
> Goal: efficient dependency resolution.
+1
Stephen has pointed out that using XML for this is the best solution we
can offer, because XML can be handled easily with almost any programming
language an
I think that all the fields of a dependency are quite complete. Based on
the issues I see with moving forward with Aether is that the (complex)
dependency resolution is done inside Maven. The idea is to not calculate
this anymore, but add all transitive dependencies to the consumer pom.
This
On Mon, 29 Aug 2016 21:29:36 +0200, Tibor Digana
wrote:
Hi Robert,
Hm, sep.of.concern, this discussion does not have the end. We should
start another more concrete.
Let's list all first-level items of consumer POM I would need to have
in my case and we will see where we go:
parent, name, des
I am sceptical about somebody would be interested in another schema
(handling new one) than the one used with POM.
I think we are too inside in ourselves.
Imaging the developers or companies using Maven nowadays, or IDEs,
easily they would say "no difference, the POM works for me so no issue
- let'
Robert, I am not sure that a consumer-pom will ultimately provide any
relief to the problem at hand. Eventually -- even if it is some point very
distant in the future -- the consumer-pom will also need to evolve so the
same problem will rear its head: how do you read a POM of a future model
version
Sorry that I reply to consumer POM again, I want to fix my previous
email, the parent in consumer POM is not needed from my point of view
because I would naturally consider all POMs in Maven Central as
totally resolved with their dependencies against scope=runtime and
independent of parent and depM
Hi Robert,
Hm, sep.of.concern, this discussion does not have the end. We should
start another more concrete.
Let's list all first-level items of consumer POM I would need to have
in my case and we will see where we go:
parent, name, description, url, scm, issueManagement, dependencies,
depMgt, dis
We're missing separations of concerns with the pom. Right now it contains
all the information to build the project and all the dependency
information. Once deployed only the latter is roughly of any interest. As
long as the build-pom is also the deploy-pom, we cannot change a lot since
this
Am 08/24/16 um 09:22 schrieb Stephen Connolly:
> I think we probably need to rethink version ranges. What I'd like is to let
> the consumer Pom treat version ranges more as guidance rather than hard
> requirements. It's a pain if you depend transitiveky on Foo:[1.0] but need
> Foo:[1.0.1,1.1) for t
Last week, I communicated my thoughts on why POM model 4.1.0 should not be
introduced in the 3.x series. I said that I believed that forcing two
separate lines of development would best be beneficial to the overall code
base (which is big!!!). The benefit, so I think, is that 3.x would focus on
gra
Am 08/24/16 um 08:15 schrieb Hervé BOUTEMY:
> 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
m
We should probably add repository info too.
Right now dependencies are searched in every repository if it is not
found. Not very efficient if you now where it should look.
I still like this related
article:"http://blog.sonatype.com/2012/02/public-service-announcement-your-build-is-leaking-and-
yes, we'll need to find clear terms for each concept: I now understand what
you meant by consumer pom, which is not what I meant :)
there are 2 ideas:
- publishing classical Maven pom without build information (pom generated by
flatten plugin or alike), to be able to add new build features in
+1
Le dimanche 28 août 2016 12:57:52 Robert Scholte a écrit :
> Hi Tibor,
>
> There's no need to hurry to for Maven-4.0.0 just because of the
> modelVersion. Maven2 was already using it, we may assume that users
> already know about this.
> I'd really prefer to stay on 3.x and go to 5.x once we'v
Hi Tibor,
There's no need to hurry to for Maven-4.0.0 just because of the
modelVersion. Maven2 was already using it, we may assume that users
already know about this.
I'd really prefer to stay on 3.x and go to 5.x once we've extended the
model to version 5.0.0. (I don't mind skipping 4.x if
@Jason
@all
Can you tell me why we want to release Maven 3.4.0 and not Maven 4.0.0?
I guess Maven 4.0.x may finalize Model Version 4.0.0 era.
Do you have other plans with Maven 4.x?
Back to modelVersion and consumer POM. The consumer pom is a subset of
normal POM. Keep using consumer POM with curr
Hi Robert, as I am reading your comments, I see the situation is not
be so tragic :)
What about to let m-deploy-p and m-release-p to decide on modelVersion
of consumer project as the minimum version. If for instance a new
scope value is available in of your project POM, then
the plugin would decid
I supposed to align Maven 4.x with model version 4.0, and then
Maven 5.x with model version 5.0.
I supposed to directly release Maven 4.0.0 instead of 3.4.0.
Why we have to control model version and support it if the XSD
schemaLocation is already defined:
http://maven.apache.org/xsd/maven-4.0.0.x
On 26 Aug 2016, at 22:07, Tibor Digana wrote:
> One or two years ago I watched mvn dev hangouts videos with Jason and
Were they really that long ago? Wow. I was actually thinking about them the
other day, wondering when/why they petered out, I ended up having to stop
joining due to timezone is
One or two years ago I watched mvn dev hangouts videos with Jason and
Karl and others and there we mentioned the need for BOM. I understood
that BOM is similar to dependencyManagement different from typical
POM. In the video they wanted to solve some problem with dependencies
resolutions.
Do we sti
The current pom will still be there, always, consumer pom is an extra file
for more effective artifact resolution. So yes, that's why I suggested
consumer dom to ensure it is not confused with the current pom.
Robert
On Thu, 25 Aug 2016 20:16:08 +0200, Chas Honton wrote:
I use the current
I use the current Pom to automate checking license policy and checking owasp
database for known security flaws. The scm and website metadata is also very
useful. Automated download of source for debugging is essential. As a consumer,
I don't want to lose these abilities.
Chas
> On Aug 25, 20
So content:
* list/tree of dependencies
* list/tree of provides
* list/tree of requires
* repeat same for side artifacts
For a jar the "requires" will basically be "java:runtime:9.0" to indicate
that it was compiled with -target 9.0
For say a .net DLL the requires may be more complex
For say a
Is it really correct to call a dependency-only (more of less) file a POM if
it ceases to contain project information? A project is (or should be!)
synonymous with a build. Is that why someone referred to it as a DOM? A DOM
makes way more sense to me than overloading the usage of POM and calling it
For both the flattened-pom and consumer-pom the idea is to remove build
related information. Most of it is only used during build.
The question is: is there other information which should be added?
e.g. In case of JARs: the major version number of the class file format
being used. Is it intere
On Thu, 25 Aug 2016 18:30:50 +0200, Stephen Connolly
wrote:
On Thursday 25 August 2016, Robert Scholte wrote:
On Thu, 25 Aug 2016 01:10:36 +0200, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
On 24 August 2016 at 04:50, Robert Scholte wrote:
I realized last ApacheCon that
On Thursday 25 August 2016, Robert Scholte wrote:
> On Thu, 25 Aug 2016 01:10:36 +0200, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> On 24 August 2016 at 04:50, Robert Scholte wrote:
>>
>> I realized last ApacheCon that I wasn't clear about my definiton of the
>>> consumer-po
The only (minor?) issue I have with the term "consumer POM" is that it
implies one type of consumption. What is the kind of consumption we're
addressing -- is it merely the GAV and dependencies?
Cheers,
Paul
On Thu, Aug 25, 2016 at 3:34 AM, Robert Scholte
wrote:
> On Thu, 25 Aug 2016 01:10:36 +
On Thu, 25 Aug 2016 01:10:36 +0200, Stephen Connolly
wrote:
On 24 August 2016 at 04:50, Robert Scholte wrote:
I realized last ApacheCon that I wasn't clear about my definiton of the
consumer-pom.
I don't think it should be a flattened pom with only the dependency
information. Instead it sh
On Thu, 25 Aug 2016 08:00:14 +0200, Hervé BOUTEMY
wrote:
Le mercredi 24 août 2016 13:50:33 Robert Scholte a écrit :
I realized last ApacheCon that I wasn't clear about my definiton of the
consumer-pom.
I don't think it should be a flattened pom with only the dependency
information. Instead i
Le mercredi 24 août 2016 13:50:33 Robert Scholte a écrit :
> I realized last ApacheCon that I wasn't clear about my definiton of the
> consumer-pom.
> I don't think it should be a flattened pom with only the dependency
> information. Instead it shouldn't be a pom (matching the pom.xsd) at all.
IMH
On 24 August 2016 at 04:50, Robert Scholte wrote:
> I realized last ApacheCon that I wasn't clear about my definiton of the
> consumer-pom.
> I don't think it should be a flattened pom with only the dependency
> information. Instead it shouldn't be a pom (matching the pom.xsd) at all.
>
I am no
Am 08/24/16 um 08:23 schrieb Hervé BOUTEMY:
> version ranges: I hate version ranges... :)
> notice: what is the issue with version ranges? the generated consumer pom can
> contain version ranges, since it is a long-standing feature
It would be really cool if the whole dependency resolution could
I realized last ApacheCon that I wasn't clear about my definiton of the
consumer-pom.
I don't think it should be a flattened pom with only the dependency
information. Instead it shouldn't be a pom (matching the pom.xsd) at all.
Maybe it should be called something like consumer-dom (dependency
On Wed, Aug 24, 2016 at 11:08 AM, Martijn Dashorst <
martijn.dasho...@gmail.com> wrote:
> On Wed, Aug 24, 2016 at 8:41 AM, Fred Cooke wrote:
> > Fair call re embedded pom, however it's quite convenient to just browse
> to
> > it and read.
> I'd like to vent another opinion: the build pom makes it
On Wed, Aug 24, 2016 at 8:41 AM, Fred Cooke wrote:
> Fair call re embedded pom, however it's quite convenient to just browse to
> it and read.
I'd like to vent another opinion: the build pom makes it hard to grok
the information I need as a consumer of a library. I really don't need
to wade throu
The consumer Pom is for machine to machine, it should be human readable
because that is nice, but intent is never human generated.
Switching to this separation allows us to be more radical in the changes to
the build Pom.
The only reason we deploy packaging Pom's build Pom is for inheritance. If
I still find it a bit off that the original real POM won't always be
directly available anymore.
Other tools create fake POMs because they *have* to - there's no other
option.
I feel like some fidelity would be lost. Diffability would be lost (from a
scenario where there's nothing to diff).
Unre
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
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
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
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
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
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
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
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
On Monday 22 August 2016, Karl Heinz Marbaise wrote:
> Hi Stephen,
> On 23/08/16 01:12, Stephen Connolly wrote:
>
>> On Monday 22 August 2016, Christian Schulte wrote:
>>
>> Am 08/22/16 um 09:08 schrieb Stephen Connolly:
>>>
This is why I said that the v5 pom (which v4.1 is... just under a
when we put "build-pom vs consumer-pom" in place, we don't need to publish
build poms in the repository: the repository is here only to consume already-
built artifacts as dependencies, then with their consumer pom, then without
newer Maven version prerequisites (= what we want: let people consum
Hi Stephen,
On 23/08/16 01:12, Stephen Connolly wrote:
On Monday 22 August 2016, Christian Schulte wrote:
Am 08/22/16 um 09:08 schrieb Stephen Connolly:
This is why I said that the v5 pom (which v4.1 is... just under a
different
name) would have to be deployed separately with a *best effort
On Monday 22 August 2016, Christian Schulte wrote:
> Am 08/22/16 um 09:08 schrieb Stephen Connolly:
> > This is why I said that the v5 pom (which v4.1 is... just under a
> different
> > name) would have to be deployed separately with a *best effort*
> translation
> > down to the 4.0.0 model deplo
Am 08/22/16 um 09:08 schrieb Stephen Connolly:
> This is why I said that the v5 pom (which v4.1 is... just under a different
> name) would have to be deployed separately with a *best effort* translation
> down to the 4.0.0 model deployed at the standard coordinates.
>
> The problem then becomes th
This is why I said that the v5 pom (which v4.1 is... just under a different
name) would have to be deployed separately with a *best effort* translation
down to the 4.0.0 model deployed at the standard coordinates.
The problem then becomes that we are deploying now two poms for everything,
a 4.0.0
Am 08/21/16 um 17:19 schrieb Karl Heinz Marbaise:
> So using a new POM Model version (4.1.0) and now I will deploy it to
> Maven Central. This means that only Maven 3.4+ can read and handle that.
> Older Maven versions will simply fail with this new version.
Those older Maven versions would sile
Am 21.08.2016 um 17:19 schrieb Karl Heinz Marbaise:
We need to find a better way for those things...May be this is exactly a
sitution to control the behaviour via a feature flag to change this. So
anybody can decide to use the new (correct) behaviour or keep the old
behaviour...(which could be de
Hi,
first changing the discussion to the dev list:
On 21/08/16 14:36, Robert Scholte wrote:
Hi,
Keep in mind that Maven is not the only tool/application using the pom.xml.
Some of them probably never check the xsd or the modelVersion, so we
need to be very carefull with this.
If we introduce a
On Fri, Jul 22, 2016 at 8:28 AM, Karl Heinz Marbaise
wrote:
> Hi Gary,
>
> On 7/21/16 5:08 AM, Gary Gregory wrote:
>
>> Hi,
>>
>> If you guys want to keep posting 3.4.0 snapshots I'll be happy to test
>> while working on Log4j2, Commons, and HttpCompon
Hi Gary,
On 7/21/16 5:08 AM, Gary Gregory wrote:
Hi,
If you guys want to keep posting 3.4.0 snapshots I'll be happy to test
while working on Log4j2, Commons, and HttpComponents.
This is great that you offer you help...
And I have created a new SNAPSHOT for 3.4.0. See users/dev list..
1 - 100 of 101 matches
Mail list logo
