Re: moving GitHub issue notifications to issues@maven.a.o

[Uwe Barthel]

+1 (non binding)

-- 
bart...@x-reizend.de


> On 21. Oct 2017, at 12:22, Hervé BOUTEMY  wrote:
> 
> Currently, comments are sent to dev@maven.a.o
> 
> For our classical official Jira issue tracker, notifications are sent to 
> issues@maven.a.o
> 
> If nobody objects (72h as usual), I'll ask infra to switch GitHub issue 
> notifications to isseus@maven.a.o
> 
> Regards,
> 
> Hervé
> 
> -
> 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: [DISCUSSION] finishing Aether import: help find a new name

[Uwe Barthel]

everybody ok for:
- name: "Artifact Resolver"
- groupId: org.apache.maven.resolver
- artifactId: resolver(-*)


Why not more formal like:
-name: Maven Artifact Resolver
-groupId: org.apache.maven.[artifact | resolver]
-artifactId: artifact-resolver

-- barthel



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

Re: [DISCUSSION] finishing Aether import: help find a new name

[Uwe Barthel]

Hi,


Eclipse owns the Aether name. We cannot use the name Aether.


And the Eclipse Foundation doesn't like to provide that name to the ASF 
(only the name without the eclipse namespace)?


Aethel means over the AIR.

WDYT about org.Apache.maven.air: _A_rtifact _I_inqui_R_e. Inquire is more 
general than resolve?


-- barthel



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

Re: [DISCUSSION] finishing Aether import: help find a new name

[Uwe Barthel]

Hi,

I know Aether is one of the catchy non telling name.
But, why not leave Aether with new Maven namespace like org.apache.maven.aether?

-- barthel


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

Re: Aether

[Uwe Barthel]

Hi Gary,

> What is the background story for Aether moving to and from Maven.
@see: 
https://projects.eclipse.org/projects/technology.aether/reviews/termination-review

-- barthel


> On 24 Jun 2016, at 19:38, Gary Gregory <garydgreg...@gmail.com> wrote:
> 
> Hi,
> 
> What is the background story for Aether moving to and from Maven.
> 
> Gary
> On Jun 24, 2016 10:16 AM, "Hervé BOUTEMY" <herve.bout...@free.fr> wrote:
> 
>> Hi,
>> 
>> We are working with Eclipse foundation on trademark topics: for the moment,
>> it's not yet time to work on code.
>> We'll keep everybody informed when this step is done
>> 
>> Regards,
>> 
>> Hervé
>> 
>> Le jeudi 23 juin 2016 22:35:25 Uwe Barthel a écrit :
>>> Hi,
>>> 
>>> I would like to contribute to bring Aether to Apache Maven.
>>> The repositories  git.apache.org, github.com) are available.
>>> The clearance is running.
>>> 
>>> What are the next steps?
>>> The item (https://issues.apache.org/jira/browse/MNG-6006) contains less
>>> information.
>>> 
>>> -- barthel
>>> 
>>> 
>>> 
>>> -
>>> 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
>> 
>> 


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

Aether

[Uwe Barthel]

Hi,

I would like to contribute to bring Aether to Apache Maven.
The repositories  git.apache.org, github.com) are available.
The clearance is running.

What are the next steps?
The item (https://issues.apache.org/jira/browse/MNG-6006) contains less 
information.

-- barthel



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

Re: Roadmap Maven 3.4.0

[Uwe Barthel]

Hi Michael,

> I have made several comments. Please review and update otherwise I cannot 
> proceed on the merge.
I take a look.
Thats a lot of auto formatting things.
It’s quite difficult to manage these over different projects in Netbeans.
I'll fix that.

> Additionally, I am waiting for an answer to my question:
> The PR looks good as it does not change the default behavior. Though, I do 
> not understand how it is supposed to solve the problem because your default 
> impl of VersionRangeResultFilter does nothing. Are you going to add your 
> custom implementation to {maven.home}/lib/ext?
That's Right.
Over the years there were more than one and opposing views how is the right 
solution for resolving version range.
This PR give the possibility to use a strategy you like.
The default implementation must not be changed to give this PR a change to 
merge (see comments at the PR).

The custom implementation could be placed in {maven.home}/lib/ext or maybe also 
as extension in .mvn/ per project.

> Even if I would merge, the issue wouldn't be resolved. Is that correct?
More or less.
Now it provides an API to add a filter you like.
It could be the solution for this issue while we would not change the default 
behaviour or provide different strategies in Maven core.
Adding a documentation and an example on this issue and everyone might 
implement a solution he likes/needs.

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

Re: maven git commit: [MNG-3507] keep green for success: INFO in blue (DEBUG is cyan)

[Uwe Barthel]

Hi,

> DEBUG/INFO/WARNING/ERROR schemes I'm thinking at:
> 1. bold cyan/bold green/bold yellow/bold red (initial)
> 2. bold cyan/bold blue/bold yellow/bold red (current)
> 3. cyan/blue/bold yellow/bold red (idea to have INFO less visible)

I prefer to use the standard console color (customised by user) for INFO 
instead of assign a fix color on that.
Most of the time the output is like I want and the bold yellow/red are 
eye-catcher.

Personally, I don't need a custom color for DEBUG.
If  maven run in DEBUG mode almost 90% of the output is colored.
And if this color ist different to my own customized console color it's maybe 
unconfortable for me to read.

My suggestion:

DEBUG/INFO: leave as is, maybe make DEBUG bold but don’t change the color.
WARNING: bold yellow
ERROR: bold red

Regards,
-- barthel


> On 15 Jun 2016, at 08:19, Hervé BOUTEMY  wrote:
> 
> Sorry guys, I did this while looking at a soccer match :) , not on my main 
> computer, then without communicating...
> 
> This one is a little bit like the Jenkins debate on the green vs blue bullet: 
> this time, this was a remark on MNG-3507 that bold green on every INFO was 
> too 
> much... Then I found that bold Cyan DEBUG + bold Blue INFO was not a bad idea.
> But I have no strong opinion: this was a test, before we get too much habit 
> with the initial implemented colors.
> 
> 
> On making colors configurable:
> - log level color configuration would be feasible, since only the logger has 
> to implement it: but I don't expect much value, since it's only about 
> DEBUG/INFO/WARNING/ERROR, then does it really deserve added complexity?
> - message level color configuration would be more complex, since this would 
> require an API to be used by plugins: for this one, I strongly think we 
> should 
> at least wait a little bit before trying (and I'm not yet convinced this will 
> be useful)
> 
> 
> Perhaps we should make tests on log level color and publish results to 
> compare 
> on the Wiki with screenshots. IMHO, for each configuration we'd need 
> screenshots in misc configurations to check our main targets:
> - Linux vs Windows vs OSX
> - white background vs black background
> - success default vs success -X vs failure (perhaps prepare a reference build)
> 
> DEBUG/INFO/WARNING/ERROR schemes I'm thinking at:
> 1. bold cyan/bold green/bold yellow/bold red (initial)
> 2. bold cyan/bold blue/bold yellow/bold red (current)
> 3. cyan/blue/bold yellow/bold red (idea to have INFO less visible)
> 
> Ready to work with me on that?
> (and that could prepare some documentation on our color scheme)
> 
> Regards,
> 
> Hervé
> 
> Le mercredi 15 juin 2016 08:03:58 Olivier Lamy a écrit :
>> On 15 June 2016 at 05:25,  wrote:
>>> Repository: maven
>>> 
>>> Updated Branches:
>>>  refs/heads/master ecdb0bc2b -> e7a783db1
>>> 
>>> [MNG-3507] keep green for success: INFO in blue (DEBUG is cyan)
>>> 
>>> Project: http://git-wip-us.apache.org/repos/asf/maven/repo
>>> Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/e7a783db
>>> Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/e7a783db
>>> Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/e7a783db
>>> 
>>> Branch: refs/heads/master
>>> Commit: e7a783db1f577a340a91f6c958f1b9319c52c176
>>> Parents: ecdb0bc
>>> Author: Hervé Boutemy 
>>> Authored: Tue Jun 14 21:25:02 2016 +0200
>>> Committer: Hervé Boutemy 
>>> Committed: Tue Jun 14 21:25:02 2016 +0200
>>> 
>>> --
>>> 
>>> .../org/apache/maven/cli/logging/impl/gossip/ColorRenderer.java| 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>> 
>>> --
>>> 
>>> 
>>> 
>>> http://git-wip-us.apache.org/repos/asf/maven/blob/e7a783db/maven-embedder/
>>> src/main/java/org/apache/maven/cli/logging/impl/gossip/ColorRenderer.java
>>> --
>>> diff --git
>>> a/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/gossip/Co
>>> lorRenderer.java
>>> b/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/gossip/C
>>> olorRenderer.java index 7cc..52e0489 100644
>>> ---
>>> a/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/gossip/Co
>>> lorRenderer.java +++
>>> b/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/gossip/Co
>>> lorRenderer.java @@ -50,7 +50,7 @@ extends
>>> com.planet57.gossip.render.PatternRenderer> 
>>> break;
>>> 
>>> case INFO:
>>> -buff.append( ansi().bold().fgGreen().a( level.name()
>>> ).reset() );
>>> +buff.append( ansi().bold().fgBlue().a( level.name()
>>> ).reset() );
>> 
>> What about having color configurable? Ask few people they will all have
>> different opinions about the color to use.
>> So to avoid all of complains and jira issue 

Re: Roadmap Maven 3.4.0

[Uwe Barthel]

Hi Paul,

> You can find the JIRA Maven Roadmap here:
> https://issues.apache.org/jira/browse/MNG/?selectedTab=com.atlassian.jira.jira-projects-plugin:roadmap-panel


Thanks for the link that I already know.
I meant a roadmap in terms of a timeline.

Is the number of items already fixed?

-- barthel


> On 14 Jun 2016, at 22:55, Paul Benedict <pbened...@apache.org> wrote:
> 
> You can find the JIRA Maven Roadmap here:
> https://issues.apache.org/jira/browse/MNG/?selectedTab=com.atlassian.jira.jira-projects-plugin:roadmap-panel
> 
> 
> Cheers,
> Paul
> 
> On Tue, Jun 14, 2016 at 3:46 PM, Uwe Barthel <bart...@x-reizend.de> wrote:
> 
>> Hi,
>> 
>> Is there a clear roadmap for version 3.4.0?
>> 
>> I ask, because these PRs: https://github.com/apache/maven/pull/70
>> (integration tests:
>> https://github.com/apache/maven-integration-testing/pull/14) for Item
>> https://issues.apache.org/jira/browse/MNG-3092.
>> 
>> This item lives around NINE years and these PRs are open since October
>> 2015.
>> Michael O. and Jason have looked at the PR and, in my opinion, reviewed
>> for a merge.
>> This branch has no conflicts with the base branch.
>> 
>> Please give a clear statement as to whether the solution is accepted or
>> not.
>> So I've the chance to close these PRs.
>> 
>> Are there any other open PRs for 3.4.0, where I might be able to help with
>> a review?
>> 
>> -- barthel
>> 
>> 
>> 
>> -
>> 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

Roadmap Maven 3.4.0

[Uwe Barthel]

Hi,

Is there a clear roadmap for version 3.4.0?

I ask, because these PRs: https://github.com/apache/maven/pull/70 (integration 
tests: https://github.com/apache/maven-integration-testing/pull/14) for Item 
https://issues.apache.org/jira/browse/MNG-3092.

This item lives around NINE years and these PRs are open since October 2015.
Michael O. and Jason have looked at the PR and, in my opinion, reviewed for a 
merge.
This branch has no conflicts with the base branch.

Please give a clear statement as to whether the solution is accepted or not.
So I've the chance to close these PRs.

Are there any other open PRs for 3.4.0, where I might be able to help with a 
review?

-- barthel



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

Re: Massive number of failing ITs

[Uwe Barthel]

Hi Jason,

I tried the gist bash script.

First of all I’ve to change the patchUrl:
——8<—8<——snipp——8<—8<——
[…]
#patchUrl=${repository}/pull/${pr}.patch
patchUrl=https://patch-diff.githubusercontent.com/raw/apache/maven/pull/${pr}.patch
[…]
——8<—8<——snipp——8<—8<——
otherwise the content of the patch file is a HTML redirect message.

Running the script without patching any PR (#git am --signoff < ../${pr}.patch) 
ends successful.

——8<—8<——snipp——8<—8<——
[…]
[INFO] Maven ITs .. SUCCESS [08:50 min]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 11:16 min
[INFO] Finished at: 2016-05-19T23:33:07+02:00
[INFO] Final Memory: 94M/743M
[INFO] 
[…]
——8<—8<——snipp——8<—8<——

-- barthel


> On 19 May 2016, at 22:27, Jason van Zyl  wrote:
> 
> This is what I wrote for people trying to contribute to core:
> 
> http://takari.io/2014/06/01/contributing-to-maven-core.html
> 
> And what I use to smoke test contributed PRs:
> 
> https://gist.github.com/jvanzyl/16da25976f8ad27293fa
> 
>> On May 19, 2016, at 3:00 PM, Karl Heinz Marbaise  wrote:
>> 
>> Hi Jason,
>> 
>> i would like to know more details about that setup cause i'm thinking for a 
>> longer time to make a setup of the IT environment via Docker etc. this would 
>> mean having a consistent and reproducible environment for
>> running the it's...
>> 
>> Kind regards
>> Karl Heinz
>> 
>> On 5/19/16 1:29 PM, Jason van Zyl wrote:
>>> Igor, Anton, and myself between OS X, Linux and Windows have 40 IT failures 
>>> in Maven master right now.
>>> I’ve had the same setup for 8 years, Igor and Anton have consistent
>>> setups as well.
>>> I’m not sure if people aren’t running the integration tests
>>> or what but it’s pretty sad. It’s not a small number of ITs that
>>> are failing. I’d really like to not have to git bisect back to a
>>> working state so if you’ve been making changes to core please
>>> run the ITs locally and double check what you’ve done.
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
> 
> Thanks,
> 
> Jason
> 
> --
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
> 
> 
> 
> -
> 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: Massive number of failing ITs

[Uwe Barthel]

Hi Jason,

I tried to reproduce the IT failure at master.

Fetched https://github.com/apache/maven - master - last commit: 
4b35102f0e3302e15a80d3ddb756463601b9217a
Fetched https://github.com/apache/maven-integration-testing - master - last 
commit: af138c8a75a0b1a852510b27ed2c469992cde69a

——8<—8<——snipp——8<—8<——
$ 
PATH=/Users/barthel/sources/github.com/apache/apache-maven-3.4.x-SNAPSHOT/bin/:${PATH}
 mvn -version

Apache Maven 3.4.0-SNAPSHOT (4b35102f0e3302e15a80d3ddb756463601b9217a; 
2016-05-19T20:35:50+02:00)
Maven home: /Users/barthel/sources/github.com/apache/apache-maven-3.4.x-SNAPSHOT
Java version: 1.8.0_31, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "Mac OS X", version: "10.11.5", arch: "x86_64", family: "Unix"
——8<—8<——snipp——8<—8<——

——8<—8<——snipp——8<—8<——
$ 
PATH=/Users/barthel/sources/github.com/apache/apache-maven-3.4.x-SNAPSHOT/bin/:${PATH}
 ./run-its.sh

[…]
INFO] 
[INFO] 
[INFO] Building Maven Core ITs 2.1-SNAPSHOT
[INFO] 
[INFO] 
[…]
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ core-it-suite ---
[INFO] Surefire report directory: 
/Users/barthel/sources/github.com/apache/maven-integration-testing/core-it-suite/target/surefire-reports

---
 T E S T S
---
Running integration tests for Maven 3.4.0-SNAPSHOT
using Maven executable: 
/Users/barthel/sources/github.com/apache/apache-maven-3.4.x-SNAPSHOT/bin/mvn
Running org.apache.maven.it.IntegrationTestSuite
Running integration tests for Maven 3.4.0-SNAPSHOT
using Maven executable: 
/Users/barthel/sources/github.com/apache/apache-maven-3.4.x-SNAPSHOT/bin/mvn
Bootstrap(Bootstrap)OK (9.3 s)
mng5971HierarchicalImportScope(InheritanceProcessing)...OK (0.5 s)
[…]
[INFO] Maven ITs .. SUCCESS [06:33 min]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 07:39 min
[INFO] Finished at: 2016-05-19T21:15:46+02:00
[INFO] Final Memory: 89M/732M
[INFO] 
——8<—8<——snipp——8<—8<——

Is github.com not up to date or what’s wrong?

-- barthel


> On 19 May 2016, at 13:29, Jason van Zyl  wrote:
> 
> Igor, Anton, and myself between OS X, Linux and Windows have 40 IT failures 
> in Maven master right now. I’ve had the same setup for 8 years, Igor and 
> Anton have consistent setups as well. I’m not sure if people aren’t running 
> the integration tests or what but it’s pretty sad. It’s not a small number of 
> ITs that are failing. I’d really like to not have to git bisect back to a 
> working state so if you’ve been making changes to core please run the ITs 
> locally and double check what you’ve done.
> 
> Thanks,
> 
> Jason
> 
> --
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
> 
> 
> 
> -
> 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: Maven Core - Release 3.4.0?

[Uwe Barthel]

* MNG-3092: https://github.com/apache/maven/pull/70

-- barthel

> On 07 May 2016, at 20:05, Karl Heinz Marbaise  wrote:
> 
> Hi to all,
> 
> based on the number issues which have been fixed in the current 3.4.0...
> 
> I would like to ask if there are objections to make a new release within the 
> next 2 or 3 weeks...except we have very important fixes to do?..
> 
> Are there things missing ?
> 
> As a preparation to the above i would start the release notes for 3.4.0 here:
> 
> https://github.com/khmarbaise/maven-release-notes
> 
> Supplementals etc. via mailing list or as PR's...are always welcome...
> 
> Kind regards
> Karl Heinz Marbaise
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


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

Re: Maven Release Plugin And A BOM

[Uwe Barthel]

Hi Petar,

I found a very old enforcer rule at smartics and asked them to provide 
these as OS.

They did it two weeks ago at github under Apache Software License. :-)

Take a look at https://github.com/smartics/smartics-enforcer-rules

-- barthel



On May 3, 2016 4:25:55 PM Petar Tahchiev  wrote:


Hi Robert,

thank you for your comment. The idea behind the property was that I also
give the BOM to my clients and they declare it as their parent. So now if
they want to use a newer version of the platform, all they have to do
is redeclare the property  to be 1.2 or 1.5 or whatever
they want. Otherwise they will have to re-declare the whole dependency.

Now that I think about it I was wrong - if my clients want to update the
platform version all they have to do is update version of the parent BOM.

I still think though that this is a bug.


2016-05-03 16:17 GMT+02:00 Robert Patrick :


Why bother with the custom property?  Do this instead and the release
plugin is happy:

com.mycompany
my-bom
1.0-SNAPSHOT


   
  com.mycompany
  platform
  ${project.version}
  




-Original Message-
From: Petar Tahchiev [mailto:paranoia...@gmail.com]
Sent: Tuesday, May 03, 2016 9:10 AM
To: Maven Developers List
Subject: Maven Release Plugin And A BOM

Hi guys,

I have a question regarding the release plugin. In my project I have a BOM
in which I declare a property and a dependencyManagement section:

com.mycompany
my-bom
1.0-SNAPSHOT


1.0-SNAPSHOT



   
  com.mycompany
  platform
  ${platform.version}
  



and I also have 3 different projects that declare this BOM as their parent.
All of these projects have the same version number (1.0-SNAPSHOT) and when
I make a release I always release all of them. This is how it looks like:
1) I change platform.version property to 1.0, commit, push and release the
bom.
2) I try to release first of my other projects and now the release plugin
is asking me to resolve the version of the BOM. Ok, fair enough, I resolve
it to 1.0 but then it asks me again to resolve the version of
com.mycompany:platform. This clearly is a bug right? I have changed it to
1.0 before so it is no longer a SNAPSHOT???
If you think this is a problem, I will submit it in the JIRA and try to
fix it. I'm just not sure if it's a bug or maybe it's a known issue, or
maybe that's how it is supposed to be.

--
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

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





--
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611




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

Re: [VOTE] Retire Maven Application Skin, Maven Classic Skin, Maven Stylus Skin

[Uwe Barthel]

+1

-- Uwe




On December 24, 2015 23:34:47 "Michael Osipov" <1983-01...@gmx.net> wrote:


Hi,

as previously suggested, it makes sense to retire those skins because
they haven't been updated for a long time and we don't have the resources
to maintain them properly [1].

Last releases:
Maven Application Skin: 2012-01-18
Maven Classic Skin: 2012-01-18
Maven Stylus Skin: 2012-07-30

I therefore propose that we retire these skins.

If this vote is successful I will make one final release of the skin, making
it clear on the skin site that it has been retired. After that the source code
will be moved into the "retired" area in our Subversion repository.

The process for retiring a skin is described here:
http://maven.apache.org/developers/retirement-plan-plugins.html
(Though these aren't plugins, the process is universal)

The vote is open for 72 hours.

[ ] +1 Yes, it's about time
[ ] -1 No, because...

I would ask kindly those who have already cast their vote to revote to make it
"official".

[1] 
http://mail-archives.apache.org/mod_mbox/maven-dev/201512.mbox/%3Ctrinity-8ab6577c-ab69-4f9f-86e6-533e0b309a94-1450902628141%403capp-gmx-bs54%3E


Michael

-
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: Retiring Maven Skins

[Uwe Barthel]

Hi Michael,

+2

-- Uwe
bart...@x-reizend.de


> On 23 Dec 2015, at 21:30, Michael Osipov <1983-01...@gmx.net> wrote:
> 
> Hi folks,
> 
> Hervé is quite busy right now preparing Doxia (Sitetools) 1.7 along with Maven
> Site Plugin 3.5. I have several tickets on my own I'd like to fix. Some of 
> these
> changes will have impact on the skins we provide, they need to be adapted.
> 
> If you take a close look at our skins [1], they haven't been updated for 
> years.
> Active improvements happen on the Fluido Skin only.
> Given the fact that probably no one will work on them and none of them have 
> been
> changed for HTML5, I'd like to retire most of the skins and keep at most two 
> active.
> That would ultimately mean that only those two will be updated for 1.7/3.5 
> and later
> for HTML5.
> 
> My proposal:
> 
> Retire: Maven Application Skin, Maven Classic Skin, Maven Stylus Skin
> Active: Maven Default Skin, Maven Fluido Skin
> 
> Please share you opinion, if we agree I will start vote and retire them.
> 
> Michael
> 
> 
> [1] https://maven.apache.org/skins
> 
> -
> 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: Updating the default versions for maven-compiler-plugin

[Uwe Barthel]

-1

Many commercial projects still require Java 1.6.

mit freundlichen Grüßen
--
Uwe Barthel <bart...@x-reizend.de>



On November 6, 2015 1:57:04 PM Attila-Mihály Balázs <dify@gmail.com> wrote:


Hello,

Given that we're almost in 2015, what do people think about updating the
default source / target for maven-compiler-plugin to 1.8? (And also on
the site:
https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-source-and-target.html).

If there is interest, I'm happy to submit a patch!

Cheers,
Attila Balazs (Grey Panther)

-
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: Question concerning maven-filtering component

[Uwe Barthel]

> -/**
> - * @plexus.requirement
> - */
> +@Component
> private BuildContext buildContext;

Use @Requirement instead of @Component.

mit freundlichen Grüßen
Uwe Barthel
-- 
bart...@x-reizend.de


> On 04 Nov 2015, at 22:33, Karl Heinz Marbaise <khmarba...@gmx.de> wrote:
> 
> Hi,
> currently i'm trying to upgrade the maven-filtering component from xdoclet to 
> annotation based usage...
> 
> For example:
> 
> - * @plexus.component 
> role="org.apache.maven.shared.filtering.MavenResourcesFiltering" 
> role-hint="default"
>  */
> +@org.codehaus.plexus.component.annotations.Component(role=MavenResourcesFiltering.class,
>  hint= "default")
> public class DefaultMavenResourcesFiltering
> extends AbstractLogEnabled
> implements MavenResourcesFiltering, Initializable
> @@ -58,9 +59,7 @@
> 
> private List defaultNonFilteredFileExtensions;
> 
> -/**
> - * @plexus.requirement
> - */
> +@Component
> private BuildContext buildContext;
> 
> // 
> Index: 
> src/test/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFilteringTest.java
> 
> 
> The problem i have at the moment that many test failing with the following 
> message:
> DefaultMavenResourcesFilteringTest.testAddingTokens:336 » NullPointer
>  DefaultMavenResourcesFilteringTest.testEdgeCases:792 » NullPointer
>  DefaultMavenResourcesFilteringTest.testEmptyDirectories:652 » NullPointer
>  DefaultMavenResourcesFilteringTest.testExcludeOneFile:527 » NullPointer
>  DefaultMavenResourcesFilteringTest.testFilterFileName:844 » NullPointer
>  DefaultMavenResourcesFilteringTest.testIncludeOneFile:448 » NullPointer
>  DefaultMavenResourcesFilteringTest.testIncludeOneFileAndDirectory:485 » 
> NullPointer
>  DefaultMavenResourcesFilteringTest.testMSHARED81:726 » NullPointer
>  DefaultMavenResourcesFilteringTest.testNoFiltering:363 » NullPointer
>  DefaultMavenResourcesFilteringTest.testSessionFiltering:124 » NullPointer
>  DefaultMavenResourcesFilteringTest.testSimpleFiltering:93 » NullPointer
> 
> which looks like the lookup in the tests does not work as expected...
> 
> Does someone has an idea/hint what i'm doing wrong?
> 
> Kind regards
> Karl Heinz Marbaise
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


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

Re: Maven Release Version Policy

[Uwe Barthel]

> ok, then what could be done is only a check afterwards that the version 
> chosen 
> by the user is consistent with measures on code evolutions
So we are back on version policy I think.
Only check and stop the release based on the policy.

> another idea: perhaps we should have the API propose multiple versions 
> instead 
> of only one. This would help people understand that the API is only about 
> guessing a natural "next" version, but there are multiple good answers and 
> the 
> right one is really depending on what the user wants to do at current time 
> (going to next major version or minor version?)
This could/should be a part of the version policy implementation.
The release plugin itself only reacts on the result of the version policy.

The package based approach of OSGi (bundle-maven-plugin) will be also 
interesting in use with Jigsaw (Java 9 modules).
OSGi makes a bit easier with the separation/declaration of public and private 
packages.

The first idea for POJ (Plain Old Java) could be to configure the more public 
part as API (like the bundle-maven-plugin also does) or use the whole artifact 
as API instead. This approach is as strict but clean as possible. But maybe 
this behaviour is too strict, so it could be a part of a 'strict server' 
version policy implementation.

mit freundlichen Grüßen
Uwe Barthel
-- 
bart...@x-reizend.de


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

[MNG-3092] merge/commit buddy needed

[Uwe Barthel]

My PR for “Adds version range result filter behaviour” 
(https://github.com/apache/maven/pull/70) is ready for merging and needs a 
willing committer to merge into master.

Please take a look and leave a comment if I could support the merging somehow.

mit freundlichen Grüßen
Uwe Barthel
-- 
bart...@x-reizend.de



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

Re: Maven Release Version Policy

[Uwe Barthel]

Hi,

I’m with Jason to move Maven forward to use (strict) semver as default version 
strategy.

I understand the 'cloudbee' strategy as a more exotic way.
But I'm interested in more than one strategy, configurable via plugin or 
providing by default plugin.

mit freundlichen Grüßen
Uwe Barthel
-- 
bart...@x-reizend.de

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

Re: Maven Release Version Policy

[Uwe Barthel]

> I'm not sure "strict semver" can be automated: functional change can't be 
> easily detected if there is no API change

The bundle-maven-plugin behaviour is a good base to discuss about I think.

mit freundlichen Grüßen
Uwe Barthel
-- 
bart...@x-reizend.de


> On 31 Oct 2015, at 12:32, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
> 
> I'm not sure "strict semver" can be automated: functional change can't be 
> easily detected if there is no API change
> 
> semver is a great buzzword, but we should try to explain more precisely what 
> can be automated in the plugin to try to follow the buzzword
> 
> Regards,
> 
> Hervé
> 
> Le samedi 31 octobre 2015 12:14:09 Uwe Barthel a écrit :
>> Hi,
>> 
>> I’m with Jason to move Maven forward to use (strict) semver as default
>> version strategy.
>> 
>> I understand the 'cloudbee' strategy as a more exotic way.
>> But I'm interested in more than one strategy, configurable via plugin or
>> providing by default plugin.
>> 
>> mit freundlichen Grüßen
>> Uwe Barthel
> 
> 
> -
> 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: Maven Release Version Policy

[Uwe Barthel]

> great: what is the bundle-maven-plugin feature you're talking about?
The ‘baseline’[1] goal.
It based on the BND Tool[2] (by Peter Kriens), gets the previous release (!) 
and check the difference between the byte code.
Following semver, any new method (new feature) requires a new minor change. 
Changes in Interfaces or method signatures are incompatible and forces a major 
change.
It is a bit more complex but not rocket science. :-)

[1] 
http://svn.apache.org/repos/asf/felix/releases/maven-bundle-plugin-3.0.0/doc/site/baseline-mojo.html
[2] http://www.aqute.biz/Bnd/Versioning

mit freundlichen Grüßen
Uwe Barthel
-- 
bart...@x-reizend.de


> On 31 Oct 2015, at 13:26, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
> 
> great: what is the bundle-maven-plugin feature you're talking about?
> 
> Regards,
> 
> Hervé
> 
> Le samedi 31 octobre 2015 13:18:35 Uwe Barthel a écrit :
>>> I'm not sure "strict semver" can be automated: functional change can't be
>>> easily detected if there is no API change
>> 
>> The bundle-maven-plugin behaviour is a good base to discuss about I think.
>> 
>> mit freundlichen Grüßen
>> Uwe Barthel
>> 
>>> On 31 Oct 2015, at 12:32, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
>>> 
>>> I'm not sure "strict semver" can be automated: functional change can't be
>>> easily detected if there is no API change
>>> 
>>> semver is a great buzzword, but we should try to explain more precisely
>>> what can be automated in the plugin to try to follow the buzzword
>>> 
>>> Regards,
>>> 
>>> Hervé
>>> 
>>> Le samedi 31 octobre 2015 12:14:09 Uwe Barthel a écrit :
>>>> Hi,
>>>> 
>>>> I’m with Jason to move Maven forward to use (strict) semver as default
>>>> version strategy.
>>>> 
>>>> I understand the 'cloudbee' strategy as a more exotic way.
>>>> But I'm interested in more than one strategy, configurable via plugin or
>>>> providing by default plugin.
>>>> 
>>>> mit freundlichen Grüßen
>>>> Uwe Barthel
>>> 
>>> -
>>> 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
> 
> 
> -
> 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: Maven Release Version Policy

[Uwe Barthel]

> by that you mean you expect a version policy implementation that runs a 
> bytecode check against previous version (like clirr) then chooses to increase 
> major minor or patch digit?

Why not. But not choose automatically instead of warning or break the release.

I’m use the bundle-maven-plugin (baseline) for similar behaviour at build time.
But it is strong bundled on OSGi version philosophy.

mit freundlichen Grüßen
Uwe Barthel
-- 
bart...@x-reizend.de


> On 31 Oct 2015, at 12:28, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
> 
> by that you mean you expect a version policy implementation that runs a 
> bytecode check against previous version (like clirr) then chooses to increase 
> major minor or patch digit?
> 
> Regards,
> 
> Hervé
> 
> Le vendredi 30 octobre 2015 07:33:45 Jason van Zyl a écrit :
>> I would prefer to move toward standard semver and identify where we’re not
>> strictly adhering. Is it strict semver?
>>> On Oct 30, 2015, at 5:16 AM, Stephen Connolly
>>> <stephen.alan.conno...@gmail.com> wrote:
>>> 
>>> Hey, so...
>>> 
>>> Do we want to accept this implementation I knocked together:
>>> https://github.com/CloudBees-community/cloudbees-maven-release-version-pol
>>> icy
>>> 
>>> If not I'm fine leaving it where it is... but I can get it donated to
>>> the ASF if there is interest
>>> 
>>> -Stephen
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>> Thanks,
>> 
>> Jason
>> 
>> --
>> Jason van Zyl
>> Founder, Takari and Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> -
>> 
>> the course of true love never did run smooth ...
>> 
>> -- Shakespeare
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> -
>> 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
> 


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

Re: MNG-5899 Project models are no longer mutable in reactor

[Uwe Barthel]

On October 27, 2015 4:08:11 PM Jason van Zyl  wrote:

So I think we have then opportunity to model this correctly and we have 
something similar already in a WAR. We have a handler that clips all 
transitive dependencies. There would be a bit more work but if we make a 
separate packaging, build out the classpath correctly during the build we 
can probably eliminate the need for the dependency reduced POMs as we don't 
need it for WARs. Again, obviously not the same but I think this is the 
route to go.


jvz


But, isn't the underplaying change is a major change?
It compromise/breaks the actual API.

May it could be possible in Maven 3.4 or 4, but not in 3.3.x.

Just my 2 cents.

-- barthel



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

Re: [VOTE] Release Apache Maven Shade Plugin version 2.4.2 (Take 2)

[Uwe Barthel]

+1 (non binding) 

checksum [x]
Java 5 [x]

mit freundlichen Grüßen
Uwe Barthel
-- 
bart...@x-reizend.de


> On 24 Oct 2015, at 12:48, Karl Heinz Marbaise <khmarba...@gmx.de> wrote:
> 
> Hi,
> 
> We solved 7 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12333008
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHADE%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1226
> https://repository.apache.org/content/repositories/maven-1225/org/apache/maven/plugins/maven-shade-plugin/2.4.2/maven-shade-plugin-2.4.2-source-release.zip
> 
> Source release checksum(s):
> maven-shade-plugin-2.4.2-source-release.zip sha1: 
> 8bcc97553cbac68142ee7bf8c7ce2fb9af678a42
> 
> Staging site:
> http://maven.apache.org/plugins-archives/maven-shade-plugin-LATEST/
> 
> 
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> Kind regards
> Karl Heinz Marbaise
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


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

Re: [VOTE] Release Apache Maven Shade Plugin version 2.4.2

[Uwe Barthel]

-1: for me. (non binding)

In respect of http://semver.org/ I suggest the version 2.5.0.
The Java version change is a minimum minor change.

-- barthel

> On 20 Oct 2015, at 23:47, Tibor Digana  wrote:
> 
> +1: from me
> 
> No blocker from my side. Actually Java 5 is already archaic.
> I guess many users love Java 6+ nowadays.
> 
> 
> 
> 
> On Tue, Oct 20, 2015 at 11:26 PM, Karl Heinz Marbaise-3 [via Maven] <
> ml-node+s40175n5849846...@n5.nabble.com> wrote:
> 
>> Hi Tibor,
>> 
>> On 10/20/15 11:12 PM, Tibor Digana wrote:
>>> @Karl Because of maven-parent:27 this plugin is built with J2SE 6.0 = 50
>>> (0x32 hex)
>>> The previous version 2.4.1 was @ Java 5.
>> 
>> Unfortunately you are correct...(really good catch)...
>> 
>>> What is intended with this release?
>> 
>> It was not intended, cause no related issue is part of the release
>> notes...
>> 
>> So the question is: Blocker for the release from your point of view?
>> 
>> 
>> Kind regards
>> Karl Heinz Marbaise
>> 
>>> 
>>> On Fri, Oct 16, 2015 at 11:37 AM, Karl Heinz Marbaise <[hidden email]
>> >
>>> wrote:
>>> 
 Hi,
 
 We solved 6 issues:
 
 
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12333008
 
 There are still a couple of issues left in JIRA:
 
 
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHADE%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC
 
 Staging repo:
 https://repository.apache.org/content/repositories/maven-1224
 
 
>> https://repository.apache.org/content/repositories/maven-1224/org/apache/maven/plugins/maven-shade-plugin/2.4.2/maven-shade-plugin-2.4.2-source-release.zip
 
 Source release checksum(s):
 maven-shade-plugin-2.4.2-source-release.zip sha1:
 a42917c7e6cfa08e122afdd209dc9b8394de2d42
 
 Staging site:
 http://maven.apache.org/plugins-archives/maven-shade-plugin-LATEST/
 
 
 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html
 
 Vote open for 72 hours.
 
 [ ] +1
 [ ] +0
 [ ] -1
 
 Kind regards
 Karl Heinz Marbaise
>> 
>> -
>> To unsubscribe, e-mail: [hidden email]
>> 
>> For additional commands, e-mail: [hidden email]
>> 
>> 
>> 
>> 
>> --
>> 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-Shade-Plugin-version-2-4-2-tp5849239p5849846.html
>> To start a new topic under Maven Developers, email
>> ml-node+s40175n142166...@n5.nabble.com
>> To unsubscribe from Maven Developers, click here
>> 
>> .
>> NAML
>> 
>> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://maven.40175.n5.nabble.com/VOTE-Release-Apache-Maven-Shade-Plugin-version-2-4-2-tp5849239p5849850.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