+1
Regards,
Hervé
Le samedi 27 août 2016 00:40:42 Robert Scholte a écrit :
> Hi,
>
> We solved 16 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317820&ve
> rsion=12331169&styleName=Text
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.
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
yes, I should be able to do so.
Robert
On Mon, 29 Aug 2016 22:49:49 +0200, Tibor Digana
wrote:
You can still change the deployed site within this vote without
restarting it.
On 8/29/16, Robert Scholte-6 [via Maven]
wrote:
Seems like the skin required more fixes, see r1758298[1]
tha
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
You can still change the deployed site within this vote without restarting it.
On 8/29/16, Robert Scholte-6 [via Maven]
wrote:
>
>
> Seems like the skin required more fixes, see r1758298[1]
>
> thanks,
> Robert
>
> [1] http://svn.apache.org/viewvc?rev=1758298&view=rev
>
> On Mon, 29 Aug 2016 21:0
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'
Seems like the skin required more fixes, see r1758298[1]
thanks,
Robert
[1] http://svn.apache.org/viewvc?rev=1758298&view=rev
On Mon, 29 Aug 2016 21:05:58 +0200, Karl Heinz Marbaise
wrote:
Hi,
+1 from me.
Just one question:
The site has a different logo on the right site (top right) th
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
+1: here is mine :)
Let's cut the version.
On 8/28/16, rfscholte [via Maven]
wrote:
>
>
> Hi,
>
> We solved 16 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317820&version=12331169&styleName=Text
>
> There are still a couple of issues left in JIRA:
> https://issues.
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
Hi,
+1 from me.
Just one question:
The site has a different logo on the right site (top right) than other
pages like https://maven.apache.org/plugins/maven-jar-plugin/ ?
Kind regards
Karl Heinz Marbaise
On 27/08/16 00:40, Robert Scholte wrote:
Hi,
We solved 16 issues:
https://issues.apache
+1
On Sat, 27 Aug 2016 00:40:42 +0200, Robert Scholte
wrote:
Hi,
We solved 16 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317820&version=12331169&styleName=Text
There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=proje
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
Hi,
Recently I was granted write access to the plexus-io and plexus-archiver
GitHub repositories. I'm not sure where I can found any guides for
contributors. Also I can't found the plexus project mail list - not sure
where to write if I have questions related to the project. I would love
to c
I am sure the code had a reason but currently sorry I have not
answered since I have being preparing fixes for bugs and feature which
are really big.
I keep in mind that I should come back soon.
On 8/29/16, Fuud wrote:
> Github user Fuud commented on the issue:
>
> https://github.com/apache/m
Hi,
I have now created a pull request for it:
https://github.com/apache/maven-plugins/pull/91
What will happen now?
Br,
//mikael
-Original Message-
From: Tibor Digana [mailto:tibordig...@apache.org]
Sent: den 28 augusti 2016 11:09
To: dev@maven.apache.org
Subject: Re: Help to submit
GitHub user mpet opened a pull request:
https://github.com/apache/maven-plugins/pull/91
MCHANGES-373
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/mpet/maven-plugins MCHANGES-373
Alternatively you can review and apply these ch
Github user Fuud commented on the issue:
https://github.com/apache/maven-surefire/pull/114
any updates?
---
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
Hi Benedikt,
I found out that JUNit 5 was release with ALPHA version in Maven Central.
I guess there is no need to rush in Surefire yet.
The JUnit team should contribute in JUnit code line in the artifact
project org.junit.surefire-junit5 and test that provider. AFter the it
is stable with non-alp
32 matches
Mail list logo
