date:20160829

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 result is quite un-predictible

Nothing dependency tree involved here. It's done by the model builder
and just uses the highest version found.





Regards,
-- 
Christian



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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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


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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

2016-08-29 Thread Fred Cooke

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 of which would have a
> flat
> > tree that needs to be compared with and resolved against the others.
>
> As far as I understood the proposal, this is solely happening during
> build time backed by the build pom. The consumer pom is just a
> constant/final list (tree?) of dependencies the way it got resolved
> during building.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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 proposal, this is solely happening during
build time backed by the build pom. The consumer pom is just a
constant/final list (tree?) of dependencies the way it got resolved
during building.

Regards,
-- 
Christian


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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

2016-08-29 Thread 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. I can
see it speeding things up due to having all of the information for just the
declared number after that many downloads, but you can't have simple code
that just gets stuff. Not going to work.

Or am I blind?

On Tue, Aug 30, 2016 at 10:27 AM, 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. There will be no such relief
> in
> > the case of your proposal.
>
> It's not my proposal but I agree to what is proposed. This whole
> discussion started because users have requested to revert commits due to
> compatibility issues. They want to keep such "faulty" behaviour. If they
> want to fix it, they can deploy a new version using a more recent Maven
> version. The older Maven version will then also see this new behaviour.
> If the consumer pom contains the complete resolved dependency tree, the
> code interpreting that data is not much more than downloading some files
> from some repository. Yes. Repository information needs to be part of
> that consumer pom as well. So the resolved dependency tree including
> repository information from where to get the resolved artifacts. And we
> also need to find a way to handle version ranges.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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.

It's not my proposal but I agree to what is proposed. This whole
discussion started because users have requested to revert commits due to
compatibility issues. They want to keep such "faulty" behaviour. If they
want to fix it, they can deploy a new version using a more recent Maven
version. The older Maven version will then also see this new behaviour.
If the consumer pom contains the complete resolved dependency tree, the
code interpreting that data is not much more than downloading some files
from some repository. Yes. Repository information needs to be part of
that consumer pom as well. So the resolved dependency tree including
repository information from where to get the resolved artifacts. And we
also need to find a way to handle version ranges.

Regards,
-- 
Christian


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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

2016-08-29 Thread Paul Benedict

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 code, too. So please forgive me for being skeptical of
what's being proposed.

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.

Cheers,
Paul

On Mon, Aug 29, 2016 at 4:56 PM, Christian Schulte  wrote:

> 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 optimizations to build a leaner and more
> > efficient calculation.
>
> That's exactly what everyone is requesting. Once deployed, things are
> forever. We are asked to not change anything in Maven in a way leading
> to different build results than an older Maven version would produce
> when operating on the same pom again and again. That's the way out of
> it. The content of those consumer poms can change when using a more
> recent Maven version. Once deployed, all Maven versions always see the
> same result, even if the version in use would have generated a different
> consumer pom (containing new features/bug fixes).
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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 optimizations to build a leaner and more
> efficient calculation.

That's exactly what everyone is requesting. Once deployed, things are
forever. We are asked to not change anything in Maven in a way leading
to different build results than an older Maven version would produce
when operating on the same pom again and again. That's the way out of
it. The content of those consumer poms can change when using a more
recent Maven version. Once deployed, all Maven versions always see the
same result, even if the version in use would have generated a different
consumer pom (containing new features/bug fixes).

Regards,
-- 
Christian


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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

2016-08-29 Thread Paul Benedict

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 add all transitive dependencies to the consumer pom.
> This would hopefully remove the discussion what all the dependencies are,
> since they're already summed up.
> Stephen already started with a list of items which should be added the
> consumer-pom.
>

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 optimizations to build a leaner and more
efficient calculation.

By the time we have the first complete definitions, we should compare it
> with the experiences at Subversion.
>

The experiences at Subversion are relevant for producing the "consumer pom"
locally. I am arguing that Maven clients should automatically produce and
cache (install) the "consumer pom" as part of the download of the normal
build POM. You get the benefits you're advocating, plus the ones I am
mentioning.

Cheers,
Paul

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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 summed up.

+1

Question remains: How to handle version ranges? It's not possible to
deploy the resolution result as soon as version ranges need to be
supported. Deploying a version range with that consumer pom means the
consuming software needs to again resolve those ranges itself. Maybe
make version ranges a build time feature only? That way version ranges
would never get deployed in that consumer pom and would always get
resolved during building using the build pom.

Regards,
-- 
Christian


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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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 tools might not be interested
which is the reason why flatten == consumer for me.
Or you want to force the Maven of next generation to lookup
consumer-pom in order to again decrease the memory footprint?
The other tools and IDEs may have another expectations like simplified
dependencies resolution. From the IDE point of view why it should
extract runtime dependencies from build-pom if it could be already
provided in Maven Central.
For instance I use IntelliJ IDEA. Every time I change a version it's a
hell for the PC, all is frozen and project files are built internally.
Why not to help the IDE to provide only relevant information in order
to create internal project files.

On 8/29/16, Robert Scholte-6 [via Maven]
 wrote:
>
>
> 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, description, url, scm, issueManagement, dependencies,
>> depMgt, distributionManagement/relocation+repository.
>
> Hi Tibor,
>
> Based on these fields you're talking not talking about the
> consumer-pom/dom, but the flattened pom / reduced-deployment pom.
> And even in that case there are some fields which I doubt are interesting.
>
> I've had a lot of discussions about the flatten-maven-plugin what it must
> do and how it should work. It gave me a lot of extra insight about the
> pom, experience required to have a proper implementation of the
> reduced-deployment pom.
> Goal: minimize the content of the 4.0.0 pom to reduce memory usage.
>
> The consumer pom is a completely different beast.
> Goal: efficient dependency resolution.
>
> hopefully this makes it more clear,
> Robert
>
>>
>> Then how you want to cope with problem where a contributor want's to
>> introduce a new scope, e.g. only-compile or something else?
>>
>> Cheers
>> Tibor
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://maven.40175.n5.nabble.com/Re-POM-Model-version-4-1-0-in-3-4-0-SNAPSHOTs-tp5878254p5879296.html
>> Sent from the Maven Developers mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
>
>
> ___
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/Re-POM-Model-version-4-1-0-in-3-4-0-SNAPSHOTs-tp5878254p5879346.html
> To start a new topic under Maven Developers, email
> ml-node+s40175n142166...@n5.nabble.com
> To unsubscribe from Maven Developers, visit
> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code=142166=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==


-- 
Cheers
Tibor




--
View this message in context: 
http://maven.40175.n5.nabble.com/Re-POM-Model-version-4-1-0-in-3-4-0-SNAPSHOTs-tp5878254p5879364.html
Sent from the Maven Developers mailing list archive at Nabble.com.

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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 and in combination with XSLT it can be transformed to anything
we want/need to. We should find a good file extension for those files so
that a repository server can easily be setup to serve these files using
some kind of compression/chunked content/transfer encoding. Using .xml
probably is a bad idea.


Regards,
-- 
Christian


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

Re: [VOTE] Release Apache Maven Plugin Tools version 3.5


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]

thanks,
Robert

[1] http://svn.apache.org/viewvc?rev=1758298=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) 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.org/jira/secure/ReleaseNote.jspa?projectId=12317820=12331169=Text


There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317820%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC


Staging repo:
https://repository.apache.org/content/repositories/maven-1286
https://repository.apache.org/content/repositories/maven-1286/org/apache/maven/plugin-tools/maven-plugin-tools/3.5/maven-plugin-tools-3.5-source-release.zip


Source release checksum(s):
maven-plugin-tools-3.5-source-release.zip sha1:
1c36a5e66cd4f0305050559e98c9a06d45bf5a6b
Staging site:
https://maven.apache.org/plugin-tools-archives/plugin-tools-LATEST/index.html


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

Vote open for 72 hours.

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


-
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





___
If you reply to this email, your message will be added to the discussion
below:
http://maven.40175.n5.nabble.com/VOTE-Release-Apache-Maven-Plugin-Tools-version-3-5-tp5879028p5879335.html
To start a new topic under Maven Developers, email
ml-node+s40175n142166...@n5.nabble.com
To unsubscribe from Maven Developers, visit
http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code=142166=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==




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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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 would hopefully remove the discussion what all the dependencies are,  
since they're already summed up.
Stephen already started with a list of items which should be added the  
consumer-pom.
By the time we have the first complete definitions, we should compare it  
with the experiences at Subversion.

But that's a completely different discussion. We're actually still  
discussing: model 4.1.0 in Maven 3.4.0 or not?

thanks,
Robert

On Mon, 29 Aug 2016 22:15:16 +0200, Paul Benedict   
wrote:

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? The only way this ultimately gets solved is to have evolving
formats on each end... and a policy on what is, if anything,
forward-compatible. I called out Subversion as a solution to model. Both  
of
its formats (working copy and server) evolve. The most interesting  
aspect,

however, is the transformation of the server copy into a working copy. If
such a model was copied, then deploying a "consumer pom" would disappear  
as

a notion. Instead, clients would download the build POM (like now), but
then generate a "consumer pom" locally as their optimized "working copy"
for dependency management.

Cheers,
Paul

On Mon, Aug 29, 2016 at 1:33 PM, Robert Scholte 
wrote:

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 pom is also metadata for other tools, which are now very well  
capable

in parsing and processing the pom.
Once we split this, the build-pom will become a Maven specific file and  
we
can change it as often as we want (though we should try not to do so),  
as

long as the deploy-pom remains the same.

The introduced changes had no effect on the schema, but it did change  
the

behavior of dependency resolution.
I don't know every fixed bug/changed feature, but based on the responses
there are projects which depend on that bug/feature. Overall I don't  
have a
very good feeling about these changes, since I can't predict the  
impact. Do

we simply push them as bugfixes after more than 5 years?
I have more faith in the consumer-pom/dom, but that also requires  
talking

with third parties who depend on Central. I'm talking about artifact
repository vendors, IDE vendors and build tool vendors. Together we have
enough experience and should be able to come to a new and better schema.

cheers,
Robert

On Mon, 29 Aug 2016 01:32:12 +0200, Paul Benedict 
wrote:

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
graceful handling of new metadata; the 4.x line would be free to  
develop

new features. The two concerns are important enough that one code base
shouldn't try to handle both -- especially if there is desire to  
backport

graceful handling into even older releases as small point releases.

I am not sure there was any direct responses so I am raising the issue
again. Does anyone find this appealing? And if not, why not? This is  
the
direction I am advocating, but unless there is any traction on it, I  
don't

want to beat the drum on a dead idea. Thanks everyone.

Cheers,
Paul

On Sun, Aug 28, 2016 at 4:38 PM, Christian Schulte   
wrote:

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
 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 upgrade lets them solve issues they cannot solve in  
another

way.
>>
>> No issue with what 4.0.0 provides -> no need to upgrade (do not
upgrade)
>> Issue you cannot solve with 4.0.0 -> upgrade to x.y.z, if that
provides
>> the solution.
>>
>> Regards,
> my point is that a library producer creates a Maven requirement for

Re: [VOTE] Release Apache Maven Plugin Tools version 3.5

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=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) 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.org/jira/secure/ReleaseNote.jspa?projectId=12317820=12331169=Text
>>>
>>>
>>> There are still a couple of issues left in JIRA:
>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317820%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>>>
>>>
>>> Staging repo:
>>> https://repository.apache.org/content/repositories/maven-1286
>>> https://repository.apache.org/content/repositories/maven-1286/org/apache/maven/plugin-tools/maven-plugin-tools/3.5/maven-plugin-tools-3.5-source-release.zip
>>>
>>>
>>> Source release checksum(s):
>>> maven-plugin-tools-3.5-source-release.zip sha1:
>>> 1c36a5e66cd4f0305050559e98c9a06d45bf5a6b
>>> Staging site:
>>> https://maven.apache.org/plugin-tools-archives/plugin-tools-LATEST/index.html
>>>
>>>
>>> Guide to testing staged releases:
>>> https://maven.apache.org/guides/development/guide-testing-releases.html
>>>
>>> Vote open for 72 hours.
>>>
>>> [ ] +1
>>> [ ] +0
>>> [ ] -1
>>
>> -
>> 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
>
>
>
>
>
> ___
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/VOTE-Release-Apache-Maven-Plugin-Tools-version-3-5-tp5879028p5879335.html
> To start a new topic under Maven Developers, email
> ml-node+s40175n142166...@n5.nabble.com
> To unsubscribe from Maven Developers, visit
> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code=142166=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==


-- 
Cheers
Tibor




--
View this message in context: 
http://maven.40175.n5.nabble.com/VOTE-Release-Apache-Maven-Plugin-Tools-version-3-5-tp5879028p5879347.html
Sent from the Maven Developers mailing list archive at Nabble.com.

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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, description, url, scm, issueManagement, dependencies,
depMgt, distributionManagement/relocation+repository.

Hi Tibor,

Based on these fields you're talking not talking about the
consumer-pom/dom, but the flattened pom / reduced-deployment pom.
And even in that case there are some fields which I doubt are interesting.
I've had a lot of discussions about the flatten-maven-plugin what it must
do and how it should work. It gave me a lot of extra insight about the
pom, experience required to have a proper implementation of the
reduced-deployment pom.

Goal: minimize the content of the 4.0.0 pom to reduce memory usage.

The consumer pom is a completely different beast.
Goal: efficient dependency resolution.

hopefully this makes it more clear,
Robert

Then how you want to cope with problem where a contributor want's to
introduce a new scope, e.g. only-compile or something else?

Cheers
Tibor

--
View this message in context:
http://maven.40175.n5.nabble.com/Re-POM-Model-version-4-1-0-in-3-4-0-SNAPSHOTs-tp5878254p5879296.html

Sent from the Maven Developers mailing list archive at Nabble.com.

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

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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's keep it".

I think the biggest boost is in build-pom and not in deploy/consumer-pom.
For me deploy/consumer-pom is just a list of runtime dependencies as
the most important XML entries.

Sorry that I am not nice person to you in this thread. I don't use to
be like this.

-- 
Cheers
Tibor




--
View this message in context: 
http://maven.40175.n5.nabble.com/Re-POM-Model-version-4-1-0-in-3-4-0-SNAPSHOTs-tp5878254p5879339.html
Sent from the Maven Developers mailing list archive at Nabble.com.

Re: [VOTE] Release Apache Maven Plugin Tools version 3.5


Seems like the skin required more fixes, see r1758298[1]

thanks,
Robert

[1] http://svn.apache.org/viewvc?rev=1758298=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) 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.org/jira/secure/ReleaseNote.jspa?projectId=12317820=12331169=Text


There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317820%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC


Staging repo:
https://repository.apache.org/content/repositories/maven-1286
https://repository.apache.org/content/repositories/maven-1286/org/apache/maven/plugin-tools/maven-plugin-tools/3.5/maven-plugin-tools-3.5-source-release.zip


Source release checksum(s):
maven-plugin-tools-3.5-source-release.zip sha1:
1c36a5e66cd4f0305050559e98c9a06d45bf5a6b
Staging site:
https://maven.apache.org/plugin-tools-archives/plugin-tools-LATEST/index.html


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

Vote open for 72 hours.

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


-
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: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

2016-08-29 Thread Paul Benedict

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? The only way this ultimately gets solved is to have evolving
formats on each end... and a policy on what is, if anything,
forward-compatible. I called out Subversion as a solution to model. Both of
its formats (working copy and server) evolve. The most interesting aspect,
however, is the transformation of the server copy into a working copy. If
such a model was copied, then deploying a "consumer pom" would disappear as
a notion. Instead, clients would download the build POM (like now), but
then generate a "consumer pom" locally as their optimized "working copy"
for dependency management.

Cheers,
Paul

On Mon, Aug 29, 2016 at 1:33 PM, Robert Scholte 
wrote:

> 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 pom is also metadata for other tools, which are now very well capable
> in parsing and processing the pom.
> Once we split this, the build-pom will become a Maven specific file and we
> can change it as often as we want (though we should try not to do so), as
> long as the deploy-pom remains the same.
>
> The introduced changes had no effect on the schema, but it did change the
> behavior of dependency resolution.
> I don't know every fixed bug/changed feature, but based on the responses
> there are projects which depend on that bug/feature. Overall I don't have a
> very good feeling about these changes, since I can't predict the impact. Do
> we simply push them as bugfixes after more than 5 years?
> I have more faith in the consumer-pom/dom, but that also requires talking
> with third parties who depend on Central. I'm talking about artifact
> repository vendors, IDE vendors and build tool vendors. Together we have
> enough experience and should be able to come to a new and better schema.
>
> cheers,
> Robert
>
>
> On Mon, 29 Aug 2016 01:32:12 +0200, Paul Benedict 
> wrote:
>
> 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
>> graceful handling of new metadata; the 4.x line would be free to develop
>> new features. The two concerns are important enough that one code base
>> shouldn't try to handle both -- especially if there is desire to backport
>> graceful handling into even older releases as small point releases.
>>
>> I am not sure there was any direct responses so I am raising the issue
>> again. Does anyone find this appealing? And if not, why not? This is the
>> direction I am advocating, but unless there is any traction on it, I don't
>> want to beat the drum on a dead idea. Thanks everyone.
>>
>> Cheers,
>> Paul
>>
>> On Sun, Aug 28, 2016 at 4:38 PM, Christian Schulte  wrote:
>>
>> 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
>>>  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 upgrade lets them solve issues they cannot solve in another
>>> way.
>>> >>
>>> >> No issue with what 4.0.0 provides -> no need to upgrade (do not
>>> upgrade)
>>> >> Issue you cannot solve with 4.0.0 -> upgrade to x.y.z, if that
>>> provides
>>> >> the solution.
>>> >>
>>> >> Regards,
>>> > my point is that a library producer creates a Maven requirement for a
>>> library
>>> > consumer.
>>> >
>>> > I'll say it crude for us: Maven is the only tool that give library
>>> consumers
>>> > such issues. People using other build tools don't have this issue when
>>> using
>>> > central.
>>>
>>> Can you provide some links to source code of some other build tool which
>>> does the whole dependency resolution including import scope processing
>>> itself without re-using any Maven component? Have others really
>>> implemented the dependency resolution with exactly the same behaviour
>>> Maven has? For a build tool running on the Java VM, they would have
>>> re-used the 'maven-model-builder' or 'maven-aether-provider', I guess.
>>> That means they

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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 depMgt. The POM with packaging=pom may
contain depMgt.
This would lead to the situations where BOM files have depMgt but
typical POMs with binaries packaging won't have depMgt, this means two
XSD schemas.
And here we come up with BOM files.

Cheers
Tibor

On 8/29/16, Robert Scholte-6 [via Maven]
 wrote:
>
>
> 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 pom is also metadata for other tools, which are now very well capable
>
> in parsing and processing the pom.
> Once we split this, the build-pom will become a Maven specific file and we
>
> can change it as often as we want (though we should try not to do so), as
> long as the deploy-pom remains the same.
>
> The introduced changes had no effect on the schema, but it did change the
> behavior of dependency resolution.
> I don't know every fixed bug/changed feature, but based on the responses
> there are projects which depend on that bug/feature. Overall I don't have
> a very good feeling about these changes, since I can't predict the impact.
>
> Do we simply push them as bugfixes after more than 5 years?
> I have more faith in the consumer-pom/dom, but that also requires talking
> with third parties who depend on Central. I'm talking about artifact
> repository vendors, IDE vendors and build tool vendors. Together we have
> enough experience and should be able to come to a new and better schema.
>
> cheers,
> Robert
>
> On Mon, 29 Aug 2016 01:32:12 +0200, Paul Benedict 
> wrote:
>
>> 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
>> graceful handling of new metadata; the 4.x line would be free to develop
>> new features. The two concerns are important enough that one code base
>> shouldn't try to handle both -- especially if there is desire to backport
>> graceful handling into even older releases as small point releases.
>>
>> I am not sure there was any direct responses so I am raising the issue
>> again. Does anyone find this appealing? And if not, why not? This is the
>> direction I am advocating, but unless there is any traction on it, I
>> don't
>> want to beat the drum on a dead idea. Thanks everyone.
>>
>> Cheers,
>> Paul
>>
>> On Sun, Aug 28, 2016 at 4:38 PM, Christian Schulte  wrote:
>>
>>> 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
>>>  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 upgrade lets them solve issues they cannot solve in
>>> another
>>> way.
>>> >>
>>> >> No issue with what 4.0.0 provides -> no need to upgrade (do not
>>> upgrade)
>>> >> Issue you cannot solve with 4.0.0 -> upgrade to x.y.z, if that
>>> provides
>>> >> the solution.
>>> >>
>>> >> Regards,
>>> > my point is that a library producer creates a Maven requirement for a
>>> library
>>> > consumer.
>>> >
>>> > I'll say it crude for us: Maven is the only tool that give library
>>> consumers
>>> > such issues. People using other build tools don't have this issue when
>>> using
>>> > central.
>>>
>>> Can you provide some links to source code of some other build tool which
>>> does the whole dependency resolution including import scope processing
>>> itself without re-using any Maven component? Have others really
>>> implemented the dependency resolution with exactly the same behaviour
>>> Maven has? For a build tool running on the Java VM, they would have
>>> re-used the 'maven-model-builder' or 'maven-aether-provider', I guess.
>>> That means they would just need to upgrade to 'maven-aether-provider'
>>> 3.4 and be done with it.
>>>
>>> Regards,
>>> --
>>> Christian
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail:

Re: [VOTE] Release Apache Maven Plugin Tools version 3.5

+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=12331169=Text
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317820%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1286
> https://repository.apache.org/content/repositories/maven-1286/org/apache/maven/plugin-tools/maven-plugin-tools/3.5/maven-plugin-tools-3.5-source-release.zip
>
> Source release checksum(s):
> maven-plugin-tools-3.5-source-release.zip sha1:
> 1c36a5e66cd4f0305050559e98c9a06d45bf5a6b
> Staging site:
> https://maven.apache.org/plugin-tools-archives/plugin-tools-LATEST/index.html
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
>
>
> ___
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/VOTE-Release-Apache-Maven-Plugin-Tools-version-3-5-tp5879028.html
> To start a new topic under Maven Developers, email
> ml-node+s40175n142166...@n5.nabble.com
> To unsubscribe from Maven Developers, visit
> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code=142166=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==


-- 
Cheers
Tibor




--
View this message in context: 
http://maven.40175.n5.nabble.com/Re-VOTE-Release-Apache-Maven-Plugin-Tools-version-3-5-tp5879300.html
Sent from the Maven Developers mailing list archive at Nabble.com.

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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, distributionManagement/relocation+repository.

Then how you want to cope with problem where a contributor want's to
introduce a new scope, e.g. only-compile or something else?

Cheers
Tibor




--
View this message in context: 
http://maven.40175.n5.nabble.com/Re-POM-Model-version-4-1-0-in-3-4-0-SNAPSHOTs-tp5878254p5879296.html
Sent from the Maven Developers mailing list archive at Nabble.com.

Re: [VOTE] Release Apache Maven Plugin Tools version 3.5

2016-08-29 Thread Karl Heinz Marbaise


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.org/jira/secure/ReleaseNote.jspa?projectId=12317820=12331169=Text


There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317820%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC


Staging repo:
https://repository.apache.org/content/repositories/maven-1286
https://repository.apache.org/content/repositories/maven-1286/org/apache/maven/plugin-tools/maven-plugin-tools/3.5/maven-plugin-tools-3.5-source-release.zip


Source release checksum(s):
maven-plugin-tools-3.5-source-release.zip sha1:
1c36a5e66cd4f0305050559e98c9a06d45bf5a6b
Staging site:
https://maven.apache.org/plugin-tools-archives/plugin-tools-LATEST/index.html


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

Vote open for 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] Release Apache Maven Plugin Tools version 3.5


+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=12331169=Text

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317820%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1286
https://repository.apache.org/content/repositories/maven-1286/org/apache/maven/plugin-tools/maven-plugin-tools/3.5/maven-plugin-tools-3.5-source-release.zip

Source release checksum(s):
maven-plugin-tools-3.5-source-release.zip sha1:  
1c36a5e66cd4f0305050559e98c9a06d45bf5a6b

Staging site:
https://maven.apache.org/plugin-tools-archives/plugin-tools-LATEST/index.html

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

Vote open for 72 hours.

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

-
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: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

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 pom is also metadata for other tools, which are now very well capable  
in parsing and processing the pom.
Once we split this, the build-pom will become a Maven specific file and we  
can change it as often as we want (though we should try not to do so), as  
long as the deploy-pom remains the same.

The introduced changes had no effect on the schema, but it did change the  
behavior of dependency resolution.
I don't know every fixed bug/changed feature, but based on the responses  
there are projects which depend on that bug/feature. Overall I don't have  
a very good feeling about these changes, since I can't predict the impact.  
Do we simply push them as bugfixes after more than 5 years?
I have more faith in the consumer-pom/dom, but that also requires talking  
with third parties who depend on Central. I'm talking about artifact  
repository vendors, IDE vendors and build tool vendors. Together we have  
enough experience and should be able to come to a new and better schema.

cheers,
Robert

On Mon, 29 Aug 2016 01:32:12 +0200, Paul Benedict   
wrote:

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

graceful handling of new metadata; the 4.x line would be free to develop
new features. The two concerns are important enough that one code base
shouldn't try to handle both -- especially if there is desire to backport
graceful handling into even older releases as small point releases.

I am not sure there was any direct responses so I am raising the issue
again. Does anyone find this appealing? And if not, why not? This is the
direction I am advocating, but unless there is any traction on it, I  
don't

want to beat the drum on a dead idea. Thanks everyone.

Cheers,
Paul

On Sun, Aug 28, 2016 at 4:38 PM, Christian Schulte  wrote:

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
 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 upgrade lets them solve issues they cannot solve in  
another

way.
>>
>> No issue with what 4.0.0 provides -> no need to upgrade (do not  
upgrade)
>> Issue you cannot solve with 4.0.0 -> upgrade to x.y.z, if that  
provides

>> the solution.
>>
>> Regards,
> my point is that a library producer creates a Maven requirement for a
library
> consumer.
>
> I'll say it crude for us: Maven is the only tool that give library
consumers
> such issues. People using other build tools don't have this issue when
using
> central.

Can you provide some links to source code of some other build tool which
does the whole dependency resolution including import scope processing
itself without re-using any Maven component? Have others really
implemented the dependency resolution with exactly the same behaviour
Maven has? For a build tool running on the Java VM, they would have
re-used the 'maven-model-builder' or 'maven-aether-provider', I guess.
That means they would just need to upgrade to 'maven-aether-provider'
3.4 and be done with it.

Regards,
--
Christian

-
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

Questions about how to contribute to Plexus

2016-08-29 Thread Plamen Totev


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 contribute to the project and help it with the maintenance but not 
sure about what to do so I'll be very grateful if you could give me some 
directions where I can get more info or help.


Thanks,

Plamen Totev

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

Re: [GitHub] maven-surefire issue #114: Parallel runner should not drop away runners that...

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/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 if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Cheers
Tibor

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

RE: Help to submit fix in maven-changes-plugin

2016-08-29 Thread Mikael Petterson

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 fix in maven-changes-plugin

Mikael, your patch should appear in
https://github.com/apache/maven-plugins/pulls
Many people do this.
Please read tutorial on GitHub to push a new pull request.

On 8/28/16, Mikael Petterson [via Maven] 
 wrote:
>
>
> Hi,
>
> We are trying to use 2.12 of this plugin.
>
> I notice that the filter that we set in not applied at all.
>
> I found the following bug report:
>
> MCHANGES-373: It is not possible to use "filter" parameter
>
> I checked code and I can see that the jql query is missing the filter 
> parameter to be set in the builder.
> Easy fix.
>
> I checked out the code:
>
> https://github.com/apache/maven-plugins
>
> I changed the code.
>
> How can I submit a patch and integrate it and test it? Make a release 2.13.
> What is the process? Is there a guide?
>
> Br,
>
> //mikael
>
>
>
>
>
>
>
>
> ___
> If you reply to this email, your message will be added to the 
> discussion
> below:
> http://maven.40175.n5.nabble.com/Help-to-submit-fix-in-maven-changes-p
> lugin-tp5878947.html To start a new topic under Maven Developers, 
> email
> ml-node+s40175n142166...@n5.nabble.com
> To unsubscribe from Maven Developers, visit 
> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubs
> cribe_by_code=142166=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ
> 8LTI4OTQ5MjEwMg==


--
Cheers
Tibor




--
View this message in context: 
http://maven.40175.n5.nabble.com/Help-to-submit-fix-in-maven-changes-plugin-tp5878947p5878960.html
Sent from the Maven Developers mailing list archive at Nabble.com.

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

[GitHub] maven-plugins pull request #91: MCHANGES-373

2016-08-29 Thread mpet

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 changes as the patch at:

https://github.com/apache/maven-plugins/pull/91.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #91


commit 699dd3bf3649c150913a0dd1eda25966bc6f6f1c
Author: mike 
Date:   2016-08-29T11:39:24Z

MCHANGES-373




---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] maven-surefire issue #114: Parallel runner should not drop away runners that...

2016-08-29 Thread Fuud

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 if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: [SUREFIRE] Surefire provider for JUnit 5?