Re: [DISCUSS] How to work with branches

[Elliot Metsger]

On Sun, Mar 19, 2017 at 6:56 PM, Fred Cooke  wrote:

> No need to cherry-pick, that should be a rare operation.
>
> Clean up the branch and prepare it for a fast forward with high quality
> commits, then just push it when it's ready and passes scrutiny and tests.
>

I agree, cherry picking is _not_ a normal operation.  There are plusses and
minuses to different merge strategies, but I don't really consider cherry
picking to be one of them.

As an aside, I'm not sure if this would be too much for Maven, but check
out git-flow [0], which provides conventions and rationale around git
branch management vis-a-vis "hotfixes", "release branches", "feature
branches" etc.  Whilst adopting the whole of git-flow may be more complex
than this project needs, it does offer a clear rationale and definition for
different kinds of branches, and it may provide some ideas as the Maven
developers investigate their own solutions.

[0] https://datasift.github.io/gitflow/IntroducingGitFlow.html



+1 on ugly masters. Last time I looked at the docker project the displayed
> history showed 15 or so merge commits and NO content commits. Useless.
>
> On 20 March 2017 at 11:46, Hervé BOUTEMY  wrote:
>
> > until now, target version was managed through Jira issue: I'm not
> convinced
> > putting the info in an additional place like branch name will help keep
> > info
> > in sync
> >
> > For the merge idea, the "target branch" concept seems too much for me: if
> > the
> > branch was automatically locally rebased on master, this would be simpler
> > and
> > sufficient IMHO
> >
> > And I completely dislike merge commits and remaining branches in master:
> > commits should be cherry picked and merge commit totally avoided IMHO.
> > Merge commits (and complex history retained from this practice) is a big
> > pain
> > point to me to have a clear master history
> >
> > Regards,
> >
> > Hervé
> >
> > Le dimanche 19 mars 2017, 17:34:21 CET Stephen Connolly a écrit :
> > > Unlike the other discuss threads, I think I have some extra context
> that
> > > means I am going to start from my proposal... or rather my requirements
> > and
> > > then proposal to solve those requirements.
> > >
> > > Requirements
> > > ===
> > >
> > > As a Release Manager,
> > >
> > > I cannot tell which branches on the CI server are targeted for the
> > release
> > > and which are "future work"
> > >
> > > I cannot tell who is responsible for which branches in order to know
> who
> > to
> > > ask w.r.t. their status
> > >
> > > As a PMC member tasked with reviewing commits
> > >
> > > I cannot keep track of all the many commits and rebases
> > >
> > > Proposal
> > > 
> > >
> > > 1. We should use a naming scheme for all branches. I am suggesting
> > > owner/targetBranch/mng- - this gives me the information about who
> > owns
> > > the branch and where the branch is targeted for.
> > >
> > > 2. We should have the Jenkinsfile build not just the head commit but
> the
> > > head commit merged to the target branch for any branch following the
> > naming
> > > scheme. We get the target branch from the naming scheme and by having
> the
> > > build verify that the branch can be merged without conflict onto the
> > target
> > > branch we remove the need for constant rebases
> > >
> > > 3. We merge branches with an explicit merge commit and stop using
> > > fast-forward merging only. Again this makes it easier to review and
> > allows
> > > the noisy branches to be quiet when looked at from the PoV of master
> > >
> > > This will not solve all the issues, but it would solve the pain points
> I
> > > have currently.
> > >
> > > Now if others have a different PoV or a counter-proposal, please speak
> > up!
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: [DISCUSS] How to work with branches

[Elliot Metsger]

Just two cents from a long-time list lurker:

First, congrats on all the work done so far!  Monumental effort, and a
well-deserved congratulations to everyone involved.

As a Release Manager,
>
> I cannot tell which branches on the CI server are targeted for the release
> and which are "future work"
>


IMHO, this is the job of the issue tracking system.  It is the authority on
what work is targeted for which release.  It is also the place where the
impact or nature of the work is tracked (bug, feature enhancement, etc.),
and whom is doing the work.  So I'm not sure that the CI server is the
place where you would go *first* to see what branches are targeting which
release.  Unfortunately, that process would first require searching the
issue tracking system for issues targeting a certain release, and then each
issue would have a link to the branch.

I see how a convention for naming branches could be helpful, but that seems
a bit complex and requires everyone to comply with multiple rules (rules
for the metadata required for an issue, which will have a link to the
branch, and then rules for how a branch should be named).

I cannot tell who is responsible for which branches in order to know who to
> ask w.r.t. their status
>

Right; I think that's the responsibility of the issue tracker.  It knows
what issues are being worked on for a release, and the release manager can
use the issue tracker to see what is in-progress, and directly ask the
developer who owns the issue.  No need to even look at the CI system.  But,
each issue should have a link to the branch being used for the work, which
could be used by the release manager if needed.

As a PMC member tasked with reviewing commits
>
> I cannot keep track of all the many commits and rebases
>

*If* the process is review then commit, a pull request would be opened by
the owner of a branch against "master" (or whatever the target branch is).
That is how a PMC member would know it is time to review a series of
commits.  The owner of the branch would be responsible for insuring that it
can apply cleanly to the target branch at any time.  For example, the owner
of the branch opens a PR.  It must apply cleanly to the target branch at
the time the PR is opened (i.e. the branch must be based on the tip of the
target).  If, prior to merging the PR, the target branch progresses, the
owner of the branch would need to rebase the branch and update the PR.

To me this seems like a clean separation of responsibilities.  The owner of
a branch indicates that their work is ready for merging by requesting a
PR.  It is the owner's responsibility to keep the PR current with respect
to the target branch.  The PMC member or release manager is notified of the
PR, and their responsibility is to perform a review, and either accept the
merge request or ask for more changes (asking for more changes could mean:
"please rebase this against the current tip of the target branch").

As PRs are accepted and merged into their target branches, the
corresponding issues in the tracking system are updated with this
information, and closed.

Having PRs that apply cleanly to the target branch also invites other
developers who may not bear official responsibility, to attempt to build
the branch and review the PR as well.  That is to say, cleanly applying PRs
may have more eyes on them during the review process.

Just my thoughts!


>
> Proposal
> 
>
> 1. We should use a naming scheme for all branches. I am suggesting
> owner/targetBranch/mng- - this gives me the information about who owns
> the branch and where the branch is targeted for.
>
> 2. We should have the Jenkinsfile build not just the head commit but the
> head commit merged to the target branch for any branch following the naming
> scheme. We get the target branch from the naming scheme and by having the
> build verify that the branch can be merged without conflict onto the target
> branch we remove the need for constant rebases
>
> 3. We merge branches with an explicit merge commit and stop using
> fast-forward merging only. Again this makes it easier to review and allows
> the noisy branches to be quiet when looked at from the PoV of master
>
> This will not solve all the issues, but it would solve the pain points I
> have currently.
>
> Now if others have a different PoV or a counter-proposal, please speak up!
>

Re: [DISCUSS] Planning process for 3.5.1

[Christian Schulte]

Am 03/19/17 um 12:43 schrieb Stephen Connolly:
> So planning for 3.5.0 was total chaos... but it seems to have worked.
> 
> How do we want to work for 3.5.1?

We need to answer all the other questions first (versioning, bug vs.
feature, branches, etc.). Question is: How to decide which commits/JIRA
issues will be merged to master for the next release?

Regards,
-- 
Christian


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

Re: [DISCUSS] Towards a common understanding of things

[Christian Schulte]

Am 03/20/17 um 01:47 schrieb Christian Schulte:
> Am 03/20/17 um 01:11 schrieb Stephen Connolly:
>> On Sun 19 Mar 2017 at 12:13, Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>>> We need to define:
>>>
>>> * what is a bug vs what is an rfe
>>>
>>> * what are the different severities for bugs and rfes
>>>
>>
>> S1: software is unusable, halts, crashes, or is inaccessible, resulting in
>> a critical impact on the operation. No workaround is available
>>
>> Examples:
>>
>> Maven crashes on OS-X
>> Maven goes into infinite loop when installing war artifacts
>>
>> S2: software operates but due to an error, its operation is severely
>> restricted. No workaround is available
>>
>> Examples:
>>
>> Maven deploys invalid/corrupt artifacts
>> Maven silently skips tests without asking
>> Maven ignores batch mode and auto-version submosules for a reactor with
>> more than 20 modules to release
>>
>> S3: software operates with limitations due to an error that is not critical
>> to the overall operation. For example, a workaround forces a user to use a
>> time-consuming procedure to operate the software, or removes a
>> non-essential feature.
>>
>> Examples:
>>
>> Maven has started to prompt with Y/N for each test to be run when
>> -DconfirmTests=false or when in batch mode.
>> Maven is stuck logging at debug level
>>
>> S4: software can be used with only slight inconvenience.
>>
>> Examples:
>>
>> Maven colour logging is broken.
>> Maven is prompting to start execution at the start of the reactor when not
>> in batch mode
>>
>> Wdyt
> 
> Based on that, what severity would be assigned to the following issues?
> This somehow lacks the "changes incorrect/unexpected/broken behaviour"
> category we hopefully do not have to use that often. Some real-world
> examples we can use to sort things out.
> 
> Bugs:
> -
> MRESOLVER-8
> MRESOLVER-9
> MNG-5359
> MNG-5984
> MNG-6114
> MNG-6164
> MNG-5227 (ModelBuilder part only - resolver does it since years)
> MNG-5935
> MNG-6135 (bug we discussed to death already)
> 
> RFEs:
> -
> MNG-4463 (or bug due to lack of support?)
> MNG-5527 (or bug due to lack of support?)
> MNG-5600 (or bug due to lack of support?)
> MNG-5971 (currently a new scope - include)
> MNG-5761+MRESOLVER-10 (or bug - current behaviour
> unexpected/inconsistent with site)
> 

Some of them available as pull requests already, in case you want to
review the changes.




Regards,
-- 
Christian


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

Re: [DISCUSS] Towards a common understanding of things

[Christian Schulte]

Am 03/20/17 um 01:11 schrieb Stephen Connolly:
> On Sun 19 Mar 2017 at 12:13, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
> 
>> We need to define:
>>
>> * what is a bug vs what is an rfe
>>
>> * what are the different severities for bugs and rfes
>>
> 
> S1: software is unusable, halts, crashes, or is inaccessible, resulting in
> a critical impact on the operation. No workaround is available
> 
> Examples:
> 
> Maven crashes on OS-X
> Maven goes into infinite loop when installing war artifacts
> 
> S2: software operates but due to an error, its operation is severely
> restricted. No workaround is available
> 
> Examples:
> 
> Maven deploys invalid/corrupt artifacts
> Maven silently skips tests without asking
> Maven ignores batch mode and auto-version submosules for a reactor with
> more than 20 modules to release
> 
> S3: software operates with limitations due to an error that is not critical
> to the overall operation. For example, a workaround forces a user to use a
> time-consuming procedure to operate the software, or removes a
> non-essential feature.
> 
> Examples:
> 
> Maven has started to prompt with Y/N for each test to be run when
> -DconfirmTests=false or when in batch mode.
> Maven is stuck logging at debug level
> 
> S4: software can be used with only slight inconvenience.
> 
> Examples:
> 
> Maven colour logging is broken.
> Maven is prompting to start execution at the start of the reactor when not
> in batch mode
> 
> Wdyt

Based on that, what severity would be assigned to the following issues?
This somehow lacks the "changes incorrect/unexpected/broken behaviour"
category we hopefully do not have to use that often. Some real-world
examples we can use to sort things out.

Bugs:
-
MRESOLVER-8
MRESOLVER-9
MNG-5359
MNG-5984
MNG-6114
MNG-6164
MNG-5227 (ModelBuilder part only - resolver does it since years)
MNG-5935
MNG-6135 (bug we discussed to death already)

RFEs:
-
MNG-4463 (or bug due to lack of support?)
MNG-5527 (or bug due to lack of support?)
MNG-5600 (or bug due to lack of support?)
MNG-5971 (currently a new scope - include)
MNG-5761+MRESOLVER-10 (or bug - current behaviour
unexpected/inconsistent with site)


Regards,
-- 
Christian


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

Re: [DISCUSS] How to work with branches

[Fred Cooke]

Sounds like the solution is for people to use a different remote that you
don't feel personally responsible for checking every commit in. And to fix
the email system.

Split emails for commits on master to everyone and a new list for other
branches.

As for Jenkins validating a merge, that's rubbish. A merge, or a rebase, is
a human operation, even when the tool can do it "cleanly"/automatically. To
ignore this is to introduce subtle issues and breakages.

On 20 March 2017 at 10:20, Stephen Connolly  wrote:

> On Sun 19 Mar 2017 at 20:05, Fred Cooke  wrote:
>
> > How are branches noisy? Promiscuous automated emails or some such?
>
>
> PMC (and committers too, but the buck stops at the PMC) are supposed to
> monitor the commits@m.a.o mailing list.
>
> Every time a branch is rebased... boom all the commits are emailed *again*
>
>
> >
> > Surely you don't need to look at all branches unless you've been asked to
> > pre-review something prior to fast-forward? Just the ones you're
> interested
> > in?
>
>
> Need to check for Apache license issues and other ill-defined criteria
>
>
> >
> > Naming scheme sounds sensible, however unless everyone is constantly
> > rebasing (or making a mess with merge) there's a solid chance they won't
> > merge cleanly (which is a human operation).
>
>
> This is why Jenkins will validate the merge cleanly so that the human has
> an easy merge
>
>
> >
> > Also, unless you're talking about maven itself with multiple supported
> > versions, there should be exactly one target branch for most stuff, so
> I'd
> > say reorder your pattern to reduce base-level "noise", eg
> > target/owner/ticket-purpose
>
>
> Perhaps, though then a lot of branches will start with "master/"
>
> Otoh it does make it easier to find all targeting master...
>
>
> > On 20 March 2017 at 06:34, Stephen Connolly <
> > stephen.alan.conno...@gmail.com
> > > wrote:
> >
> > > Unlike the other discuss threads, I think I have some extra context
> that
> > > means I am going to start from my proposal... or rather my requirements
> > and
> > > then proposal to solve those requirements.
> > >
> > > Requirements
> > > ===
> > >
> > > As a Release Manager,
> > >
> > > I cannot tell which branches on the CI server are targeted for the
> > release
> > > and which are "future work"
> > >
> > > I cannot tell who is responsible for which branches in order to know
> who
> > to
> > > ask w.r.t. their status
> > >
> > > As a PMC member tasked with reviewing commits
> > >
> > > I cannot keep track of all the many commits and rebases
> > >
> > > Proposal
> > > 
> > >
> > > 1. We should use a naming scheme for all branches. I am suggesting
> > > owner/targetBranch/mng- - this gives me the information about who
> > owns
> > > the branch and where the branch is targeted for.
> > >
> > > 2. We should have the Jenkinsfile build not just the head commit but
> the
> > > head commit merged to the target branch for any branch following the
> > naming
> > > scheme. We get the target branch from the naming scheme and by having
> the
> > > build verify that the branch can be merged without conflict onto the
> > target
> > > branch we remove the need for constant rebases
> > >
> > > 3. We merge branches with an explicit merge commit and stop using
> > > fast-forward merging only. Again this makes it easier to review and
> > allows
> > > the noisy branches to be quiet when looked at from the PoV of master
> > >
> > > This will not solve all the issues, but it would solve the pain points
> I
> > > have currently.
> > >
> > > Now if others have a different PoV or a counter-proposal, please speak
> > up!
> > >
> >
> --
> Sent from my phone
>

Re: [DISCUSS] Towards a common understanding of things

[Stephen Connolly]

On Sun 19 Mar 2017 at 12:13, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> We need to define:
>
> * what is a bug vs what is an rfe
>
> * what are the different severities for bugs and rfes
>

S1: software is unusable, halts, crashes, or is inaccessible, resulting in
a critical impact on the operation. No workaround is available

Examples:

Maven crashes on OS-X
Maven goes into infinite loop when installing war artifacts

S2: software operates but due to an error, its operation is severely
restricted. No workaround is available

Examples:

Maven deploys invalid/corrupt artifacts
Maven silently skips tests without asking
Maven ignores batch mode and auto-version submosules for a reactor with
more than 20 modules to release

S3: software operates with limitations due to an error that is not critical
to the overall operation. For example, a workaround forces a user to use a
time-consuming procedure to operate the software, or removes a
non-essential feature.

Examples:

Maven has started to prompt with Y/N for each test to be run when
-DconfirmTests=false or when in batch mode.
Maven is stuck logging at debug level

S4: software can be used with only slight inconvenience.

Examples:

Maven colour logging is broken.
Maven is prompting to start execution at the start of the reactor when not
in batch mode

Wdyt


> * what severity bugs block: an alpha, a beta, a full release
>
> * what do the different release types mean? (My take, alpha is not feature
> complete, beta is not free of bugs, rc is hopefully the real deal)
>
> * how do we decide when to bump major, minor and patch version numbers and
> what scope of changes should be allowed in a non-patch bump
> --
> Sent from my phone
>
-- 
Sent from my phone

Re: [DISCUSS] How to work with branches

[Stephen Connolly]

On Sun 19 Mar 2017 at 22:56, Fred Cooke  wrote:

> No need to cherry-pick, that should be a rare operation.
>
> Clean up the branch and prepare it for a fast forward with high quality
> commits, then just push it when it's ready and passes scrutiny and tests.
>
> +1 on ugly masters. Last time I looked at the docker project the displayed
> history showed 15 or so merge commits and NO content commits. Useless.


All depends on POV

I happen to prefer merge commits - but I would say that having gotten
correct --first-parent support added to more of the git CLI

Having looked at how people abuse git, I actually think we'd have a cleaner
history if we required merge commits and banned fast-forward commits.
Certainly keeps code review simpler..,

OTOH perhaps this is just a problem that can be solved by INFRA if we get
them to only notify for tags and protected branches


>
> On 20 March 2017 at 11:46, Hervé BOUTEMY  wrote:
>
> > until now, target version was managed through Jira issue: I'm not
> convinced
> > putting the info in an additional place like branch name will help keep
> > info
> > in sync
> >
> > For the merge idea, the "target branch" concept seems too much for me: if
> > the
> > branch was automatically locally rebased on master, this would be simpler
> > and
> > sufficient IMHO
> >
> > And I completely dislike merge commits and remaining branches in master:
> > commits should be cherry picked and merge commit totally avoided IMHO.
> > Merge commits (and complex history retained from this practice) is a big
> > pain
> > point to me to have a clear master history
> >
> > Regards,
> >
> > Hervé
> >
> > Le dimanche 19 mars 2017, 17:34:21 CET Stephen Connolly a écrit :
> > > Unlike the other discuss threads, I think I have some extra context
> that
> > > means I am going to start from my proposal... or rather my requirements
> > and
> > > then proposal to solve those requirements.
> > >
> > > Requirements
> > > ===
> > >
> > > As a Release Manager,
> > >
> > > I cannot tell which branches on the CI server are targeted for the
> > release
> > > and which are "future work"
> > >
> > > I cannot tell who is responsible for which branches in order to know
> who
> > to
> > > ask w.r.t. their status
> > >
> > > As a PMC member tasked with reviewing commits
> > >
> > > I cannot keep track of all the many commits and rebases
> > >
> > > Proposal
> > > 
> > >
> > > 1. We should use a naming scheme for all branches. I am suggesting
> > > owner/targetBranch/mng- - this gives me the information about who
> > owns
> > > the branch and where the branch is targeted for.
> > >
> > > 2. We should have the Jenkinsfile build not just the head commit but
> the
> > > head commit merged to the target branch for any branch following the
> > naming
> > > scheme. We get the target branch from the naming scheme and by having
> the
> > > build verify that the branch can be merged without conflict onto the
> > target
> > > branch we remove the need for constant rebases
> > >
> > > 3. We merge branches with an explicit merge commit and stop using
> > > fast-forward merging only. Again this makes it easier to review and
> > allows
> > > the noisy branches to be quiet when looked at from the PoV of master
> > >
> > > This will not solve all the issues, but it would solve the pain points
> I
> > > have currently.
> > >
> > > Now if others have a different PoV or a counter-proposal, please speak
> > up!
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
-- 
Sent from my phone

Re: [DISCUSS] How to work with branches

[Stephen Connolly]

On Sun 19 Mar 2017 at 23:38, Christian Schulte  wrote:

> Am 03/19/17 um 18:34 schrieb Stephen Connolly:
> > Unlike the other discuss threads, I think I have some extra context that
> > means I am going to start from my proposal... or rather my requirements
> and
> > then proposal to solve those requirements.
> >
> > Requirements
> > ===
> >
> > As a Release Manager,
> >
> > I cannot tell which branches on the CI server are targeted for the
> release
> > and which are "future work"
> >
> > I cannot tell who is responsible for which branches in order to know who
> to
> > ask w.r.t. their status
> >
> > As a PMC member tasked with reviewing commits
> >
> > I cannot keep track of all the many commits and rebases
> >
> > Proposal
> > 
> >
> > 1. We should use a naming scheme for all branches. I am suggesting
> > owner/targetBranch/mng- - this gives me the information about who
> owns
> > the branch and where the branch is targeted for.
>
> s/targetBranch/targetVersion/g
>

If it isn't targetBranch then we can only merge to master...

If that's what we want then:

1. We cannot have people pushing branches for fixes that cannot land on
master now (perhaps keep future work on GitHub)

2. No point in including a target branch or version just owner/mng-


> We currently have 3.5.0-SNAPSHOT on master. There is no way to create a
> branch for 3.5.1-SNAPSHOT today using that naming scheme. Today, master
> is at 3.5.0-SNAPSHOT, in one year master is at 3.6.0-SNAPSHOT. Creating
> a branch like schulte/master/MNG-6135 today, does not indicate the
> target version. The branch should be named schulte/3.6.0/MNG-6135. Not
> sure the name really is needed. Finding out about the author or
> committer is easy looking at the latest commits.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: [DISCUSS] How to work with branches

[Christian Schulte]

Am 03/19/17 um 18:34 schrieb Stephen Connolly:
> Unlike the other discuss threads, I think I have some extra context that
> means I am going to start from my proposal... or rather my requirements and
> then proposal to solve those requirements.
> 
> Requirements
> ===
> 
> As a Release Manager,
> 
> I cannot tell which branches on the CI server are targeted for the release
> and which are "future work"
> 
> I cannot tell who is responsible for which branches in order to know who to
> ask w.r.t. their status
> 
> As a PMC member tasked with reviewing commits
> 
> I cannot keep track of all the many commits and rebases
> 
> Proposal
> 
> 
> 1. We should use a naming scheme for all branches. I am suggesting
> owner/targetBranch/mng- - this gives me the information about who owns
> the branch and where the branch is targeted for.

s/targetBranch/targetVersion/g

We currently have 3.5.0-SNAPSHOT on master. There is no way to create a
branch for 3.5.1-SNAPSHOT today using that naming scheme. Today, master
is at 3.5.0-SNAPSHOT, in one year master is at 3.6.0-SNAPSHOT. Creating
a branch like schulte/master/MNG-6135 today, does not indicate the
target version. The branch should be named schulte/3.6.0/MNG-6135. Not
sure the name really is needed. Finding out about the author or
committer is easy looking at the latest commits.

Regards,
-- 
Christian


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

Re: [DISCUSS] Towards a common understanding of things

[Christian Schulte]

Am 03/19/17 um 23:32 schrieb Hervé BOUTEMY:
> for you, documentation is always right?
> That's the first time I see that documentation is more important and always 
> more accurate than how the tool works
> 
> If there is a discrepency between how the tool works and what is written in 
> documentation, there is work to be done to define what part has to be 
> improved 
> to match the other: I don't make any judgement on "fixing", just that the bug 
> is in the discrepency

That's what I meant with "when there is consensus the
documentation/specification is stating the intended/correct behaviour"
First thing to validate is the documentation/specification. If that is
accurate, work on fixing code can be started. If that is not accurate,
work on fixing the documentation can be started. Both bugs. Either in
code or in documentation. That's mainly what I did on the pre-reset
branches. Make the code match the documentation (site and javadoc) when
I was sure the documentation is describing the expected behaviour and
the reports in JIRA were backed by valid analysis or example projects
demonstrating things are misbehaving.

Regards,
-- 
Christian


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

[GitHub] maven-doxia pull request #2: Replace module-markdown pegdown parser to flexm...

[vsch]

GitHub user vsch opened a pull request:

https://github.com/apache/maven-doxia/pull/2

Replace module-markdown  pegdown parser to flexmark-java

Java language level for this module is 1.7

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/vsch/maven-doxia trunk

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-doxia/pull/2.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 #2


commit f9c314e38f1ca2a8b0eefb74892ec156cb84a9a1
Author: Vladimir Schneider 
Date:   2017-03-05T19:40:30Z

change to JDK1.7 and flexmark-java from pegdown

commit 1f34b747ff6c224473dfe4494910589b1b1a4f80
Author: Vladimir Schneider 
Date:   2017-03-07T03:32:12Z

bump up flexmark-java dependency to 0.17.2, fix for typographic quotes bug.

commit 3be80955883ad5f1b10e407dad2f25f8c86af345
Author: Vladimir Schneider 
Date:   2017-03-08T22:24:10Z

bump up flexmark-java dependency to 0.18.0, fix for typographic angle 
quotes bug.

commit e804a8d41e128683bf7d9257af19ebd9367e26a2
Author: Vladimir Schneider 
Date:   2017-03-08T22:57:26Z

add module build config for JDK 1.7

commit b381a749e9aeb0dac341a4882ad8dd85936de885
Author: Vladimir Schneider 
Date:   2017-03-11T22:22:31Z

build works. Tests fail. Current test framework is not designed for
human consumption. Not readable, usable or maintainable.

commit 295a9019dadfe1486a580a2db94bcc4934e3c1a0
Author: Vladimir Schneider 
Date:   2017-03-12T00:00:31Z

update flexmark-java dependency version to 0.18.2

commit c445b70d13dbb1ffebd2d71697ffa43b8f5fb2e4
Author: Hervé Boutemy 
Date:   2017-03-12T17:18:13Z

simplified configuration using maven.compiler.target property

commit 61faf2712658813fd8c9256084f71aeba1f6f01d
Author: Hervé Boutemy 
Date:   2017-03-12T17:32:29Z

added a notice for Java compatibility

commit fcab7ef1d8345c3957b261f8370c9014cf428bcc
Author: Vladimir Schneider 
Date:   2017-03-18T01:03:06Z

tests passing.

commit 3a094c5d883d3397e5b4adf8ec5e55c2fb55b89d
Author: Vladimir Schneider 
Date:   2017-03-19T23:03:42Z

tests passing. clirr exclusions added for doxia-module-markdown

commit 63a9e0de2d4012b5eacc965413017b379640822f
Author: Vladimir Schneider 
Date:   2017-03-19T23:05:21Z

Merge pull request #1 from hboutemy/trunk

little improvements




---
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: [DISCUSS] How to work with branches

[Stephen Connolly]

On Sun 19 Mar 2017 at 20:05, Fred Cooke  wrote:

> How are branches noisy? Promiscuous automated emails or some such?


PMC (and committers too, but the buck stops at the PMC) are supposed to
monitor the commits@m.a.o mailing list.

Every time a branch is rebased... boom all the commits are emailed *again*


>
> Surely you don't need to look at all branches unless you've been asked to
> pre-review something prior to fast-forward? Just the ones you're interested
> in?


Need to check for Apache license issues and other ill-defined criteria


>
> Naming scheme sounds sensible, however unless everyone is constantly
> rebasing (or making a mess with merge) there's a solid chance they won't
> merge cleanly (which is a human operation).


This is why Jenkins will validate the merge cleanly so that the human has
an easy merge


>
> Also, unless you're talking about maven itself with multiple supported
> versions, there should be exactly one target branch for most stuff, so I'd
> say reorder your pattern to reduce base-level "noise", eg
> target/owner/ticket-purpose


Perhaps, though then a lot of branches will start with "master/"

Otoh it does make it easier to find all targeting master...


> On 20 March 2017 at 06:34, Stephen Connolly <
> stephen.alan.conno...@gmail.com
> > wrote:
>
> > Unlike the other discuss threads, I think I have some extra context that
> > means I am going to start from my proposal... or rather my requirements
> and
> > then proposal to solve those requirements.
> >
> > Requirements
> > ===
> >
> > As a Release Manager,
> >
> > I cannot tell which branches on the CI server are targeted for the
> release
> > and which are "future work"
> >
> > I cannot tell who is responsible for which branches in order to know who
> to
> > ask w.r.t. their status
> >
> > As a PMC member tasked with reviewing commits
> >
> > I cannot keep track of all the many commits and rebases
> >
> > Proposal
> > 
> >
> > 1. We should use a naming scheme for all branches. I am suggesting
> > owner/targetBranch/mng- - this gives me the information about who
> owns
> > the branch and where the branch is targeted for.
> >
> > 2. We should have the Jenkinsfile build not just the head commit but the
> > head commit merged to the target branch for any branch following the
> naming
> > scheme. We get the target branch from the naming scheme and by having the
> > build verify that the branch can be merged without conflict onto the
> target
> > branch we remove the need for constant rebases
> >
> > 3. We merge branches with an explicit merge commit and stop using
> > fast-forward merging only. Again this makes it easier to review and
> allows
> > the noisy branches to be quiet when looked at from the PoV of master
> >
> > This will not solve all the issues, but it would solve the pain points I
> > have currently.
> >
> > Now if others have a different PoV or a counter-proposal, please speak
> up!
> >
>
-- 
Sent from my phone

Re: [DISCUSS] How to work with branches

[Fred Cooke]

No need to cherry-pick, that should be a rare operation.

Clean up the branch and prepare it for a fast forward with high quality
commits, then just push it when it's ready and passes scrutiny and tests.

+1 on ugly masters. Last time I looked at the docker project the displayed
history showed 15 or so merge commits and NO content commits. Useless.

On 20 March 2017 at 11:46, Hervé BOUTEMY  wrote:

> until now, target version was managed through Jira issue: I'm not convinced
> putting the info in an additional place like branch name will help keep
> info
> in sync
>
> For the merge idea, the "target branch" concept seems too much for me: if
> the
> branch was automatically locally rebased on master, this would be simpler
> and
> sufficient IMHO
>
> And I completely dislike merge commits and remaining branches in master:
> commits should be cherry picked and merge commit totally avoided IMHO.
> Merge commits (and complex history retained from this practice) is a big
> pain
> point to me to have a clear master history
>
> Regards,
>
> Hervé
>
> Le dimanche 19 mars 2017, 17:34:21 CET Stephen Connolly a écrit :
> > Unlike the other discuss threads, I think I have some extra context that
> > means I am going to start from my proposal... or rather my requirements
> and
> > then proposal to solve those requirements.
> >
> > Requirements
> > ===
> >
> > As a Release Manager,
> >
> > I cannot tell which branches on the CI server are targeted for the
> release
> > and which are "future work"
> >
> > I cannot tell who is responsible for which branches in order to know who
> to
> > ask w.r.t. their status
> >
> > As a PMC member tasked with reviewing commits
> >
> > I cannot keep track of all the many commits and rebases
> >
> > Proposal
> > 
> >
> > 1. We should use a naming scheme for all branches. I am suggesting
> > owner/targetBranch/mng- - this gives me the information about who
> owns
> > the branch and where the branch is targeted for.
> >
> > 2. We should have the Jenkinsfile build not just the head commit but the
> > head commit merged to the target branch for any branch following the
> naming
> > scheme. We get the target branch from the naming scheme and by having the
> > build verify that the branch can be merged without conflict onto the
> target
> > branch we remove the need for constant rebases
> >
> > 3. We merge branches with an explicit merge commit and stop using
> > fast-forward merging only. Again this makes it easier to review and
> allows
> > the noisy branches to be quiet when looked at from the PoV of master
> >
> > This will not solve all the issues, but it would solve the pain points I
> > have currently.
> >
> > Now if others have a different PoV or a counter-proposal, please speak
> up!
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven Resolver 1.1

[Hervé BOUTEMY]

I did some description enhancements in MNG-6182, stating clearly what is the 
change (even roughly, but more precisely than just telling "enhancement")

Please review MNG-6182 and do such factual description in MNG-6183

Regards,

Hervé

Le jeudi 16 mars 2017, 02:13:42 CET Christian Schulte a écrit :
> Am 03/15/17 um 23:31 schrieb Hervé BOUTEMY:
> > it would be great if MNG-6183 description included a sample debug message
> > before the change and after the change: I can't get what this change is
> > about really
> 
> Will update the issue.
> 
> > And of course, I don't get the next step with Resolver API...
> 
> Just read the Java comments I added in this commit starting with TODO:
> 
>  3192399237750c15f96fa021977dd83b>
> 
> The resolver just needs to provide a liddle bit more information to have
> those messages complete.
> 
> Regards,



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

Re: [DISCUSS] How to work with branches

[Hervé BOUTEMY]

until now, target version was managed through Jira issue: I'm not convinced 
putting the info in an additional place like branch name will help keep info 
in sync

For the merge idea, the "target branch" concept seems too much for me: if the 
branch was automatically locally rebased on master, this would be simpler and 
sufficient IMHO

And I completely dislike merge commits and remaining branches in master: 
commits should be cherry picked and merge commit totally avoided IMHO.
Merge commits (and complex history retained from this practice) is a big pain 
point to me to have a clear master history

Regards,

Hervé

Le dimanche 19 mars 2017, 17:34:21 CET Stephen Connolly a écrit :
> Unlike the other discuss threads, I think I have some extra context that
> means I am going to start from my proposal... or rather my requirements and
> then proposal to solve those requirements.
> 
> Requirements
> ===
> 
> As a Release Manager,
> 
> I cannot tell which branches on the CI server are targeted for the release
> and which are "future work"
> 
> I cannot tell who is responsible for which branches in order to know who to
> ask w.r.t. their status
> 
> As a PMC member tasked with reviewing commits
> 
> I cannot keep track of all the many commits and rebases
> 
> Proposal
> 
> 
> 1. We should use a naming scheme for all branches. I am suggesting
> owner/targetBranch/mng- - this gives me the information about who owns
> the branch and where the branch is targeted for.
> 
> 2. We should have the Jenkinsfile build not just the head commit but the
> head commit merged to the target branch for any branch following the naming
> scheme. We get the target branch from the naming scheme and by having the
> build verify that the branch can be merged without conflict onto the target
> branch we remove the need for constant rebases
> 
> 3. We merge branches with an explicit merge commit and stop using
> fast-forward merging only. Again this makes it easier to review and allows
> the noisy branches to be quiet when looked at from the PoV of master
> 
> This will not solve all the issues, but it would solve the pain points I
> have currently.
> 
> Now if others have a different PoV or a counter-proposal, please speak up!



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

Re: Maven Site / Report Plugins

[Hervé BOUTEMY]

That's the first time I see this part of the doc: defining an empty reportSet 
could remove a report plugin? I'm not convinced it ever worked.

to me, it is inconsistent with following documentation, associated to an IT:
http://maven.apache.org/plugins/maven-site-plugin/
maven-3.html#Inheritance_of_reports_for_Maven_3_before_3.0.4

Reports are additive: they were not in Maven 3.0 to 3.0.3, and it was 
identified as a bug.

Regards,

Hervé

Le dimanche 19 mars 2017, 11:28:06 CET Karl Heinz Marbaise a écrit :
> Hi,
> 
> currently I stumbled over a thing which I don't understand.
> 
> I have parent pom[1] which defines several parts of a site including
> some reports for example maven-changes-plugin with github-report..
> 
> Now I inherit from that parent pom and of course I can do a mvn site.
> 
> But now the important part.
> 
> I would like to deactive maven-changes-plugin in particular
> github-report...cause this test project does not has a github repo which
> will fail the mvn site build..
> 
> I have taken a look into the documentation[2] to find a way to deactive
> github-report or maven-changes-plugin at all...I tried to change
> maven-project-info-reports parts etc. but without any luck..
> 
> Does someone has a good hint how to do this ?
> 
> Kind regards
> Karl Heinz Marbaise
> 
> [1]: https://github.com/khmarbaise/smpp/blob/master/pom.xml
> [2]: http://maven.apache.org/pom.html#Reporting
> 
> -
> 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: [DISCUSS] Towards a common understanding of things

[Hervé BOUTEMY]

for you, documentation is always right?
That's the first time I see that documentation is more important and always 
more accurate than how the tool works

If there is a discrepency between how the tool works and what is written in 
documentation, there is work to be done to define what part has to be improved 
to match the other: I don't make any judgement on "fixing", just that the bug 
is in the discrepency

Regards,

Hervé

Le dimanche 19 mars 2017, 18:09:31 CET Christian Schulte a écrit :
> Am 19.03.2017 um 13:13 schrieb Stephen Connolly:
> > We need to define:
> > 
> > * what is a bug vs what is an rfe
> 
> I'll give it a try. Everything not working as documented/specified is a
> bug, when there is consensus the documentation/specification is stating
> the intended/correct behaviour. The design document on Maven
> fundamentals we have is the Maven site. That is what users are reading
> to learn Maven. There have been reports in JIRA telling us something
> does not behave as documented. That's bugs, IMHO. Means we should put
> more effort into that documentation and should never implement anything
> without documenting it on the site. The release notes are not the right
> place to do this.
> 
> 
> -
> 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 Site vs Reporting Plugin workflows?

[Hervé BOUTEMY]

as you can read in latest comments on MPDF-48, I prepared in MSHARED-628 
maven-reporting-exec code for execution of reports taken from  
section

Does it look clear to you now?

Regards,

Hervé

Le mercredi 15 mars 2017, 20:29:41 CET Alex O'Ree a écrit :
> Hervé thanks for the pointer. The Default Reporting Converter looks
> like it reads and normalizes content from the pom's various formats to
> the maven model. I don't see anything in that class that would
> indicate it converting into
> `org.apache.maven.reporting.exec.ReportPlugin` and injecting that into
> the maven site plugin (or any other mojo). I'm a bit new to maven
> plugin development. Again I'm doing this to try and revitalize the PDF
> plugin, which should basically do the same as the maven site plugin
> (convert markdown/etc to the output format and run the report
> plugins), only the output is to PDF instead.
> 
> On Wed, Mar 15, 2017 at 6:20 PM, Hervé BOUTEMY  
wrote:
> > Hi,
> > 
> > The change is explained here:
> > http://maven.apache.org/plugins/maven-site-plugin/maven-3.html
> > 
> > The injection is done in DefaultReportingConverter [1]
> > 
> > At the beginning, the dream was to remove  element from
> > pom.xml:
> > then we later found that we could not since this is the only place where
> > reporting plugin inheritance can happen (no inheritance in reportPlugin
> > parameter of maven-site-plugin).
> > 
> > Then this idea about  removal was abandonned, I took time to
> > document the strategy revert as much as possible. But I didn't take time
> > to do some cleanup: this parameter that is magically injected by Maven
> > core should probably be changed into a classical "${project.reporting}"
> > parameter default value.
> > 
> > Regards,
> > 
> > Hervé
> > 
> > [1] http://maven.apache.org/ref/3-LATEST/maven-model-builder/apidocs/org/
> > apache/maven/model/plugin/DefaultReportingConverter.html
> > 
> > Le mardi 14 mars 2017, 00:03:45 CET Alex O'Ree a écrit :
> >> Hi everyone, I'm trying to troubleshoot an issue with the PDF plugin,
> >> https://issues.apache.org/jira/browse/MPDF-62. Root cause seems to be
> >> 
> >> that the reportPlugins:
> >> @Parameter( readonly = true )
> >> private org.apache.maven.reporting.exec.ReportPlugin[] reportPlugins;
> >> 
> >> are not injected to the Mojo plugin and that at some point in time the
> >> behavior had changed. Does anyone know approximately when this
> >> occurred or what version the change was in effect?
> >> 
> >> Moving on, I also checked out the maven-site plugin as it performs the
> >> same task and found nearly identical code for the parts referring to
> >> the reporting plugins, except that when ran, the reportPlugins
> >> parameter is populated by maven. I'm not too sure what the delta is
> >> here nor do I know where to look, but if anyone has any clues or
> >> pointers to what could be wrong or areas to look at it, I'm all ears.
> >> Is there perhaps some resource file or magic string in play?
> >> 
> >> Related question, where does the parameter injection happen?
> >> 
> >> Finally, I also didn't find any other references to how the site
> >> plugin causes the report plugins to fire off. Is there any good
> >> resources that I can read up on the current workflow and/or
> >> architecture of all things related to report plugins and site
> >> generation?
> >> 
> >> Thanks!
> >> 
> >> -
> >> 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 git commit: [MNG-6069] Migrate to non deprecated parts of Commons CLI

[Stephen Connolly]

I think I have fixed this issue with

b424af57a56a4059763000b87bbe5e4331329b36

On 19 March 2017 at 20:24, Stephen Connolly  wrote:

> Tests are failing because system properties are not being parsed correctly
> with the new builder based options.
>
> It seems that we get for `-Drevision=1.3.0 -Dmaven.local.repo=/foo/bar`
> when on MavenCli line 1676 we get defStrs == { "revision", "1.3.0",
> "maven.local.repo", "/foo/bar"}
>
> This results in setting system properties:
>
> revision=true
> 1.3.0=true
> maven.local.repo=true
> /foo/bar=true
>
> So there's the reason why the tests are failing. I suspect the switch from
> GnuParser is the root cause... not sure what the non deprecated way to fix
> it is
>
> On 19 March 2017 at 18:36, Stephen Connolly  com> wrote:
>
>> If the tests are not working by Monday then it's out on its ear ;-)
>>
>> On Sun 19 Mar 2017 at 18:11, Karl Heinz Marbaise 
>> wrote:
>>
>>> Hi,
>>>
>>> I'm not sure if this for 3.5.0 beta or what ever we call it...at the
>>> moment the tests are not working...and I need to dive into it why are
>>> failing..it looks there are missing some dependencies..but I'm note sure
>>> about it...
>>>
>>> But it looks you have already decided what to do...
>>>
>>> Kind regards
>>> Karl Heinz Marbaise
>>>
>>> On 19/03/17 18:53, Stephen Connolly wrote:
>>> > Hervé and I were discussing this on IRC... perhaps we can merge this
>>> for
>>> > 3.5.0-beta-1 and if it causes issues then we can revert for 3.5.0
>>> >
>>> > As these are public static final String and char constants, it should
>>> not
>>> > break binary compatibility as javac inlines static final constants...
>>> it
>>> > may break compile compatibility, but that is OK.
>>> >
>>> > WDYT? If we have consensus then we'll merge tomorrow before I start the
>>> > release
>>> >
>>> > On 18 March 2017 at 18:12, Robert Scholte 
>>> wrote:
>>> >
>>> >> Are you *really* sure these public static final fields are only used
>>> here?
>>> >>
>>> >>
>>> >> On Sat, 18 Mar 2017 18:19:05 +0100,  wrote:
>>> >>
>>> >> Repository: maven
>>> >>> Updated Branches:
>>> >>>   refs/heads/MNG-6069 [created] b8efec709
>>> >>>
>>> >>>
>>> >>> [MNG-6069] Migrate to non deprecated parts of Commons CLI
>>> >>>
>>> >>>
>>> >>> Project: http://git-wip-us.apache.org/repos/asf/maven/repo
>>> >>> Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/b8efec70
>>> >>> Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/b8efec70
>>> >>> Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/b8efec70
>>> >>>
>>> >>> Branch: refs/heads/MNG-6069
>>> >>> Commit: b8efec709cce46358da2eaa3d1c288f16ab4c8a8
>>> >>> Parents: 55eeb32
>>> >>> Author: Karl Heinz Marbaise 
>>> >>> Authored: Sat Mar 18 18:18:27 2017 +0100
>>> >>> Committer: Karl Heinz Marbaise 
>>> >>> Committed: Sat Mar 18 18:18:27 2017 +0100
>>> >>>
>>> >>> 
>>> --
>>> >>>  .../java/org/apache/maven/cli/CLIManager.java   | 118
>>> >>> ++-
>>> >>>  1 file changed, 60 insertions(+), 58 deletions(-)
>>> >>> 
>>> --
>>> >>>
>>> >>>
>>> >>> http://git-wip-us.apache.org/repos/asf/maven/blob/b8efec70/m
>>> >>> aven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
>>> >>> 
>>> --
>>> >>> diff --git a/maven-embedder/src/main/java
>>> /org/apache/maven/cli/CLIManager.java
>>> >>> b/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
>>> >>> index a9038bf..20376d9 100644
>>> >>> --- a/maven-embedder/src/main/java/org/apache/maven/cli/CLIManag
>>> er.java
>>> >>> +++ b/maven-embedder/src/main/java/org/apache/maven/cli/CLIManag
>>> er.java
>>> >>> @@ -24,9 +24,9 @@ import java.io.PrintWriter;
>>> >>> import org.apache.commons.cli.CommandLine;
>>> >>>  import org.apache.commons.cli.CommandLineParser;
>>> >>> -import org.apache.commons.cli.GnuParser;
>>> >>> +import org.apache.commons.cli.DefaultParser;
>>> >>>  import org.apache.commons.cli.HelpFormatter;
>>> >>> -import org.apache.commons.cli.OptionBuilder;
>>> >>> +import org.apache.commons.cli.Option;
>>> >>>  import org.apache.commons.cli.Options;
>>> >>>  import org.apache.commons.cli.ParseException;
>>> >>> @@ -35,43 +35,43 @@ import org.apache.commons.cli.ParseException;
>>> >>>   */
>>> >>>  public class CLIManager
>>> >>>  {
>>> >>> -public static final char ALTERNATE_POM_FILE = 'f';
>>> >>> +public static final String ALTERNATE_POM_FILE = "f";
>>> >>> -public static final char BATCH_MODE = 'B';
>>> >>> +public static final String BATCH_MODE = "B";
>>> >>> -public static final char SET_SYSTEM_PROPERTY = 'D';
>>> >>> +public static final String SET_SYSTEM_PROPERTY = "D";
>>> >>> -public 

[GitHub] maven-indexer pull request #14: MINDEXER-100

[sesuncedu]

GitHub user sesuncedu opened a pull request:

https://github.com/apache/maven-indexer/pull/14

MINDEXER-100

Forward port changes from maven-indexer-5.x branch to master.
Minor fixes to pom.xml's and test resources. 
Manually set org.apache.maven.index.reader package version to 1.0.0 instead 
of default.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sesuncedu/maven-indexer MINDEXER-100

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-indexer/pull/14.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 #14


commit 3f85beae30e75e982d28dce11ba4c0121254fcf7
Author: Tamas Cservenak 
Date:   2015-10-30T23:10:13Z

MINDEXER-94: Temp file cleanup on errors

(cherry picked from commit 7a0e7ad)

commit 897a6b011945e13d5fdbf34ddcbb2c9d0a0ad345
Author: Tamas Cservenak 
Date:   2015-10-31T00:05:08Z

Add Idea iml files to rat exclude

(cherry picked from commit 0f17245)

commit d4fb8373171bc343e98cf3c7dbbc7bef37ca8cec
Author: Tamas Cservenak 
Date:   2015-10-31T00:15:45Z

MINDEXER-95: Suboptimal indexing execution in updater

(cherry picked from commit c193888)

(sesunc...@gmail.com:
Removed call to optimize in NexusIndexWriter.
Merged config setup in NexusIndexWriter.
Kept increased gzip block size in IndexDataReader.

commit 5645ce868e3aadbff44a6a86e44b6ce5b2549123
Author: Tamas Cservenak 
Date:   2015-10-31T00:29:30Z

MINDEXER-96: Indexer reader

(cherry picked from commit af8783d)

commit 2848b0d2b72b7c1a2ea2df695f9bbebfda53e184
Author: Tamas Cservenak 
Date:   2015-11-03T11:28:41Z

Added index writer, that writes single chunk for now

(cherry picked from commit b9c4d90)

commit 26cbb0df8d3f358a7456086e9a18ab774725461b
Author: Tamas Cservenak 
Date:   2015-11-03T13:23:32Z

MINDEXER-96: Indexer reader and writer

(cherry picked from commit 5c75bba)

commit db9ab5080495058f50ccb2dcdb4d197feddc8466
Author: Tamas Cservenak 
Date:   2015-11-03T15:38:26Z

INDEXER-96: Fix iterators

(cherry picked from commit be227e2)

commit 6c905500423a324750f8c5256e6bd69b0083c640
Author: Tamas Cservenak 
Date:   2015-11-05T09:53:26Z

Cleanup

(cherry picked from commit c3431b6)

commit 6fc7a9661f3c5349a74f2f7eedbd25bb2d4eb43c
Author: Tamas Cservenak 
Date:   2015-11-05T12:53:34Z

Make the reader an osgi bundle

(cherry picked from commit 4c5d1d6)

commit 732fdbf82efe9f9412cd8d47c13e7431af4b9728
Author: Tamas Cservenak 
Date:   2015-11-05T14:36:13Z

rename helper class to avoid name clash with other utilities

(cherry picked from commit 4333789)

commit 62cdc3bd3cc7b18c54ee5b02f92f43ac28bbbac0
Author: Tamas Cservenak 
Date:   2015-11-11T20:11:06Z

Fix classifier separator

(cherry picked from commit ea1205e)

commit b680ab2bbc798f378ac7a65c738e0c9a2fe81813
Author: Tamas Cservenak 
Date:   2015-11-12T10:30:50Z

Remove Transform, let user use any lib it wants to for iterable manipulation

Also, UTs got new TestUtils based on Guava

(cherry picked from commit e0570bf)

commit 4efc41f7310f61c23c1e7b91ce0055d581eb56f9
Author: Simon Spero 
Date:   2017-03-19T21:41:07Z

Minor build and test-resource fixes.




---
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: seconding MNG-6189: WARN if maven-site-plugin configuration contains reportPlugins element

[Hervé BOUTEMY]

merged to master

thank you

Hervé

Le dimanche 19 mars 2017, 16:35:14 CET Stephen Connolly a écrit :
> +1
> 
> On Sun 19 Mar 2017 at 16:21, Hervé BOUTEMY  wrote:
> > see https://issues.apache.org/jira/browse/MNG-6189 for more details on the
> > logic behind this warning.
> > 
> > It's only a warning, and there is an IT to check the result
> > 
> > I think it is safe and will help us continue cleaning users poms for
> > people
> > lost in stopped migration from  to  > plugin>
> > 
> > In addition, this will prepare maven-pdf-plugin work on the same topic
> > https://issues.apache.org/jira/browse/MPDF-48
> > 
> > 
> > Seconders?
> > 
> > notice: what is hard in our process now is to have people understand the
> > issue
> > before being merged, and understanding starts by finding interest in
> > taking
> > time to try to understand a topic that is not yours.
> > Is it bad? IMHO, no
> > But it is hard after having taken time to describe the issue, fix it, test
> > it,
> > to now have to convince explicitely others
> > 
> > Regards,
> > 
> > Hervé
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> > 
> > --
> 
> Sent from my phone



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

Re: maven git commit: [MNG-6069] Migrate to non deprecated parts of Commons CLI

[Stephen Connolly]

Tests are failing because system properties are not being parsed correctly
with the new builder based options.

It seems that we get for `-Drevision=1.3.0 -Dmaven.local.repo=/foo/bar`
when on MavenCli line 1676 we get defStrs == { "revision", "1.3.0",
"maven.local.repo", "/foo/bar"}

This results in setting system properties:

revision=true
1.3.0=true
maven.local.repo=true
/foo/bar=true

So there's the reason why the tests are failing. I suspect the switch from
GnuParser is the root cause... not sure what the non deprecated way to fix
it is

On 19 March 2017 at 18:36, Stephen Connolly  wrote:

> If the tests are not working by Monday then it's out on its ear ;-)
>
> On Sun 19 Mar 2017 at 18:11, Karl Heinz Marbaise 
> wrote:
>
>> Hi,
>>
>> I'm not sure if this for 3.5.0 beta or what ever we call it...at the
>> moment the tests are not working...and I need to dive into it why are
>> failing..it looks there are missing some dependencies..but I'm note sure
>> about it...
>>
>> But it looks you have already decided what to do...
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>> On 19/03/17 18:53, Stephen Connolly wrote:
>> > Hervé and I were discussing this on IRC... perhaps we can merge this for
>> > 3.5.0-beta-1 and if it causes issues then we can revert for 3.5.0
>> >
>> > As these are public static final String and char constants, it should
>> not
>> > break binary compatibility as javac inlines static final constants... it
>> > may break compile compatibility, but that is OK.
>> >
>> > WDYT? If we have consensus then we'll merge tomorrow before I start the
>> > release
>> >
>> > On 18 March 2017 at 18:12, Robert Scholte  wrote:
>> >
>> >> Are you *really* sure these public static final fields are only used
>> here?
>> >>
>> >>
>> >> On Sat, 18 Mar 2017 18:19:05 +0100,  wrote:
>> >>
>> >> Repository: maven
>> >>> Updated Branches:
>> >>>   refs/heads/MNG-6069 [created] b8efec709
>> >>>
>> >>>
>> >>> [MNG-6069] Migrate to non deprecated parts of Commons CLI
>> >>>
>> >>>
>> >>> Project: http://git-wip-us.apache.org/repos/asf/maven/repo
>> >>> Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/b8efec70
>> >>> Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/b8efec70
>> >>> Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/b8efec70
>> >>>
>> >>> Branch: refs/heads/MNG-6069
>> >>> Commit: b8efec709cce46358da2eaa3d1c288f16ab4c8a8
>> >>> Parents: 55eeb32
>> >>> Author: Karl Heinz Marbaise 
>> >>> Authored: Sat Mar 18 18:18:27 2017 +0100
>> >>> Committer: Karl Heinz Marbaise 
>> >>> Committed: Sat Mar 18 18:18:27 2017 +0100
>> >>>
>> >>> 
>> --
>> >>>  .../java/org/apache/maven/cli/CLIManager.java   | 118
>> >>> ++-
>> >>>  1 file changed, 60 insertions(+), 58 deletions(-)
>> >>> 
>> --
>> >>>
>> >>>
>> >>> http://git-wip-us.apache.org/repos/asf/maven/blob/b8efec70/m
>> >>> aven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
>> >>> 
>> --
>> >>> diff --git a/maven-embedder/src/main/java/org/apache/maven/cli/
>> CLIManager.java
>> >>> b/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
>> >>> index a9038bf..20376d9 100644
>> >>> --- a/maven-embedder/src/main/java/org/apache/maven/cli/
>> CLIManager.java
>> >>> +++ b/maven-embedder/src/main/java/org/apache/maven/cli/
>> CLIManager.java
>> >>> @@ -24,9 +24,9 @@ import java.io.PrintWriter;
>> >>> import org.apache.commons.cli.CommandLine;
>> >>>  import org.apache.commons.cli.CommandLineParser;
>> >>> -import org.apache.commons.cli.GnuParser;
>> >>> +import org.apache.commons.cli.DefaultParser;
>> >>>  import org.apache.commons.cli.HelpFormatter;
>> >>> -import org.apache.commons.cli.OptionBuilder;
>> >>> +import org.apache.commons.cli.Option;
>> >>>  import org.apache.commons.cli.Options;
>> >>>  import org.apache.commons.cli.ParseException;
>> >>> @@ -35,43 +35,43 @@ import org.apache.commons.cli.ParseException;
>> >>>   */
>> >>>  public class CLIManager
>> >>>  {
>> >>> -public static final char ALTERNATE_POM_FILE = 'f';
>> >>> +public static final String ALTERNATE_POM_FILE = "f";
>> >>> -public static final char BATCH_MODE = 'B';
>> >>> +public static final String BATCH_MODE = "B";
>> >>> -public static final char SET_SYSTEM_PROPERTY = 'D';
>> >>> +public static final String SET_SYSTEM_PROPERTY = "D";
>> >>> -public static final char OFFLINE = 'o';
>> >>> +public static final String OFFLINE = "o";
>> >>> -public static final char QUIET = 'q';
>> >>> +public static final String QUIET = "q";
>> >>> -public static final char DEBUG = 'X';
>> >>> +public static final String DEBUG = "X";
>> >>> -public static 

Re: [DISCUSS] How to work with branches

[Fred Cooke]

How are branches noisy? Promiscuous automated emails or some such?

Surely you don't need to look at all branches unless you've been asked to
pre-review something prior to fast-forward? Just the ones you're interested
in?

Naming scheme sounds sensible, however unless everyone is constantly
rebasing (or making a mess with merge) there's a solid chance they won't
merge cleanly (which is a human operation).

Also, unless you're talking about maven itself with multiple supported
versions, there should be exactly one target branch for most stuff, so I'd
say reorder your pattern to reduce base-level "noise", eg
target/owner/ticket-purpose

On 20 March 2017 at 06:34, Stephen Connolly  wrote:

> Unlike the other discuss threads, I think I have some extra context that
> means I am going to start from my proposal... or rather my requirements and
> then proposal to solve those requirements.
>
> Requirements
> ===
>
> As a Release Manager,
>
> I cannot tell which branches on the CI server are targeted for the release
> and which are "future work"
>
> I cannot tell who is responsible for which branches in order to know who to
> ask w.r.t. their status
>
> As a PMC member tasked with reviewing commits
>
> I cannot keep track of all the many commits and rebases
>
> Proposal
> 
>
> 1. We should use a naming scheme for all branches. I am suggesting
> owner/targetBranch/mng- - this gives me the information about who owns
> the branch and where the branch is targeted for.
>
> 2. We should have the Jenkinsfile build not just the head commit but the
> head commit merged to the target branch for any branch following the naming
> scheme. We get the target branch from the naming scheme and by having the
> build verify that the branch can be merged without conflict onto the target
> branch we remove the need for constant rebases
>
> 3. We merge branches with an explicit merge commit and stop using
> fast-forward merging only. Again this makes it easier to review and allows
> the noisy branches to be quiet when looked at from the PoV of master
>
> This will not solve all the issues, but it would solve the pain points I
> have currently.
>
> Now if others have a different PoV or a counter-proposal, please speak up!
>

Re: maven git commit: [MNG-6069] Migrate to non deprecated parts of Commons CLI

[Stephen Connolly]

If the tests are not working by Monday then it's out on its ear ;-)

On Sun 19 Mar 2017 at 18:11, Karl Heinz Marbaise  wrote:

> Hi,
>
> I'm not sure if this for 3.5.0 beta or what ever we call it...at the
> moment the tests are not working...and I need to dive into it why are
> failing..it looks there are missing some dependencies..but I'm note sure
> about it...
>
> But it looks you have already decided what to do...
>
> Kind regards
> Karl Heinz Marbaise
>
> On 19/03/17 18:53, Stephen Connolly wrote:
> > Hervé and I were discussing this on IRC... perhaps we can merge this for
> > 3.5.0-beta-1 and if it causes issues then we can revert for 3.5.0
> >
> > As these are public static final String and char constants, it should not
> > break binary compatibility as javac inlines static final constants... it
> > may break compile compatibility, but that is OK.
> >
> > WDYT? If we have consensus then we'll merge tomorrow before I start the
> > release
> >
> > On 18 March 2017 at 18:12, Robert Scholte  wrote:
> >
> >> Are you *really* sure these public static final fields are only used
> here?
> >>
> >>
> >> On Sat, 18 Mar 2017 18:19:05 +0100,  wrote:
> >>
> >> Repository: maven
> >>> Updated Branches:
> >>>   refs/heads/MNG-6069 [created] b8efec709
> >>>
> >>>
> >>> [MNG-6069] Migrate to non deprecated parts of Commons CLI
> >>>
> >>>
> >>> Project: http://git-wip-us.apache.org/repos/asf/maven/repo
> >>> Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/b8efec70
> >>> Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/b8efec70
> >>> Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/b8efec70
> >>>
> >>> Branch: refs/heads/MNG-6069
> >>> Commit: b8efec709cce46358da2eaa3d1c288f16ab4c8a8
> >>> Parents: 55eeb32
> >>> Author: Karl Heinz Marbaise 
> >>> Authored: Sat Mar 18 18:18:27 2017 +0100
> >>> Committer: Karl Heinz Marbaise 
> >>> Committed: Sat Mar 18 18:18:27 2017 +0100
> >>>
> >>> --
> >>>  .../java/org/apache/maven/cli/CLIManager.java   | 118
> >>> ++-
> >>>  1 file changed, 60 insertions(+), 58 deletions(-)
> >>> --
> >>>
> >>>
> >>> http://git-wip-us.apache.org/repos/asf/maven/blob/b8efec70/m
> >>> aven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
> >>> --
> >>> diff --git
> a/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
> >>> b/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
> >>> index a9038bf..20376d9 100644
> >>> --- a/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
> >>> +++ b/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
> >>> @@ -24,9 +24,9 @@ import java.io.PrintWriter;
> >>> import org.apache.commons.cli.CommandLine;
> >>>  import org.apache.commons.cli.CommandLineParser;
> >>> -import org.apache.commons.cli.GnuParser;
> >>> +import org.apache.commons.cli.DefaultParser;
> >>>  import org.apache.commons.cli.HelpFormatter;
> >>> -import org.apache.commons.cli.OptionBuilder;
> >>> +import org.apache.commons.cli.Option;
> >>>  import org.apache.commons.cli.Options;
> >>>  import org.apache.commons.cli.ParseException;
> >>> @@ -35,43 +35,43 @@ import org.apache.commons.cli.ParseException;
> >>>   */
> >>>  public class CLIManager
> >>>  {
> >>> -public static final char ALTERNATE_POM_FILE = 'f';
> >>> +public static final String ALTERNATE_POM_FILE = "f";
> >>> -public static final char BATCH_MODE = 'B';
> >>> +public static final String BATCH_MODE = "B";
> >>> -public static final char SET_SYSTEM_PROPERTY = 'D';
> >>> +public static final String SET_SYSTEM_PROPERTY = "D";
> >>> -public static final char OFFLINE = 'o';
> >>> +public static final String OFFLINE = "o";
> >>> -public static final char QUIET = 'q';
> >>> +public static final String QUIET = "q";
> >>> -public static final char DEBUG = 'X';
> >>> +public static final String DEBUG = "X";
> >>> -public static final char ERRORS = 'e';
> >>> +public static final String ERRORS = "e";
> >>> -public static final char HELP = 'h';
> >>> +public static final String HELP = "h";
> >>> -public static final char VERSION = 'v';
> >>> +public static final String VERSION = "v";
> >>> -public static final char SHOW_VERSION = 'V';
> >>> +public static final String SHOW_VERSION = "V";
> >>> -public static final char NON_RECURSIVE = 'N';
> >>> +public static final String NON_RECURSIVE = "N";
> >>> -public static final char UPDATE_SNAPSHOTS = 'U';
> >>> +public static final String UPDATE_SNAPSHOTS = "U";
> >>> -public static final char ACTIVATE_PROFILES = 'P';
> >>> +public static final String ACTIVATE_PROFILES = "P";
> >>> 

Re: maven git commit: [MNG-6069] Migrate to non deprecated parts of Commons CLI

[Karl Heinz Marbaise]

Hi,

I'm not sure if this for 3.5.0 beta or what ever we call it...at the 
moment the tests are not working...and I need to dive into it why are 
failing..it looks there are missing some dependencies..but I'm note sure 
about it...


But it looks you have already decided what to do...

Kind regards
Karl Heinz Marbaise

On 19/03/17 18:53, Stephen Connolly wrote:

Hervé and I were discussing this on IRC... perhaps we can merge this for
3.5.0-beta-1 and if it causes issues then we can revert for 3.5.0

As these are public static final String and char constants, it should not
break binary compatibility as javac inlines static final constants... it
may break compile compatibility, but that is OK.

WDYT? If we have consensus then we'll merge tomorrow before I start the
release

On 18 March 2017 at 18:12, Robert Scholte  wrote:


Are you *really* sure these public static final fields are only used here?


On Sat, 18 Mar 2017 18:19:05 +0100,  wrote:

Repository: maven

Updated Branches:
  refs/heads/MNG-6069 [created] b8efec709


[MNG-6069] Migrate to non deprecated parts of Commons CLI


Project: http://git-wip-us.apache.org/repos/asf/maven/repo
Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/b8efec70
Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/b8efec70
Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/b8efec70

Branch: refs/heads/MNG-6069
Commit: b8efec709cce46358da2eaa3d1c288f16ab4c8a8
Parents: 55eeb32
Author: Karl Heinz Marbaise 
Authored: Sat Mar 18 18:18:27 2017 +0100
Committer: Karl Heinz Marbaise 
Committed: Sat Mar 18 18:18:27 2017 +0100

--
 .../java/org/apache/maven/cli/CLIManager.java   | 118
++-
 1 file changed, 60 insertions(+), 58 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/maven/blob/b8efec70/m
aven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
--
diff --git a/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
b/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
index a9038bf..20376d9 100644
--- a/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
+++ b/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
@@ -24,9 +24,9 @@ import java.io.PrintWriter;
import org.apache.commons.cli.CommandLine;
 import org.apache.commons.cli.CommandLineParser;
-import org.apache.commons.cli.GnuParser;
+import org.apache.commons.cli.DefaultParser;
 import org.apache.commons.cli.HelpFormatter;
-import org.apache.commons.cli.OptionBuilder;
+import org.apache.commons.cli.Option;
 import org.apache.commons.cli.Options;
 import org.apache.commons.cli.ParseException;
@@ -35,43 +35,43 @@ import org.apache.commons.cli.ParseException;
  */
 public class CLIManager
 {
-public static final char ALTERNATE_POM_FILE = 'f';
+public static final String ALTERNATE_POM_FILE = "f";
-public static final char BATCH_MODE = 'B';
+public static final String BATCH_MODE = "B";
-public static final char SET_SYSTEM_PROPERTY = 'D';
+public static final String SET_SYSTEM_PROPERTY = "D";
-public static final char OFFLINE = 'o';
+public static final String OFFLINE = "o";
-public static final char QUIET = 'q';
+public static final String QUIET = "q";
-public static final char DEBUG = 'X';
+public static final String DEBUG = "X";
-public static final char ERRORS = 'e';
+public static final String ERRORS = "e";
-public static final char HELP = 'h';
+public static final String HELP = "h";
-public static final char VERSION = 'v';
+public static final String VERSION = "v";
-public static final char SHOW_VERSION = 'V';
+public static final String SHOW_VERSION = "V";
-public static final char NON_RECURSIVE = 'N';
+public static final String NON_RECURSIVE = "N";
-public static final char UPDATE_SNAPSHOTS = 'U';
+public static final String UPDATE_SNAPSHOTS = "U";
-public static final char ACTIVATE_PROFILES = 'P';
+public static final String ACTIVATE_PROFILES = "P";
public static final String SUPRESS_SNAPSHOT_UPDATES = "nsu";
-public static final char CHECKSUM_FAILURE_POLICY = 'C';
+public static final String CHECKSUM_FAILURE_POLICY = "C";
-public static final char CHECKSUM_WARNING_POLICY = 'c';
+public static final String CHECKSUM_WARNING_POLICY = "c";
-public static final char ALTERNATE_USER_SETTINGS = 's';
+public static final String ALTERNATE_USER_SETTINGS = "s";
public static final String ALTERNATE_GLOBAL_SETTINGS = "gs";
-public static final char ALTERNATE_USER_TOOLCHAINS = 't';
+public static final String ALTERNATE_USER_TOOLCHAINS = "t";
public static final String 

Re: maven git commit: [MNG-6069] Migrate to non deprecated parts of Commons CLI

[Stephen Connolly]

Hervé and I were discussing this on IRC... perhaps we can merge this for
3.5.0-beta-1 and if it causes issues then we can revert for 3.5.0

As these are public static final String and char constants, it should not
break binary compatibility as javac inlines static final constants... it
may break compile compatibility, but that is OK.

WDYT? If we have consensus then we'll merge tomorrow before I start the
release

On 18 March 2017 at 18:12, Robert Scholte  wrote:

> Are you *really* sure these public static final fields are only used here?
>
>
> On Sat, 18 Mar 2017 18:19:05 +0100,  wrote:
>
> Repository: maven
>> Updated Branches:
>>   refs/heads/MNG-6069 [created] b8efec709
>>
>>
>> [MNG-6069] Migrate to non deprecated parts of Commons CLI
>>
>>
>> Project: http://git-wip-us.apache.org/repos/asf/maven/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/b8efec70
>> Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/b8efec70
>> Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/b8efec70
>>
>> Branch: refs/heads/MNG-6069
>> Commit: b8efec709cce46358da2eaa3d1c288f16ab4c8a8
>> Parents: 55eeb32
>> Author: Karl Heinz Marbaise 
>> Authored: Sat Mar 18 18:18:27 2017 +0100
>> Committer: Karl Heinz Marbaise 
>> Committed: Sat Mar 18 18:18:27 2017 +0100
>>
>> --
>>  .../java/org/apache/maven/cli/CLIManager.java   | 118
>> ++-
>>  1 file changed, 60 insertions(+), 58 deletions(-)
>> --
>>
>>
>> http://git-wip-us.apache.org/repos/asf/maven/blob/b8efec70/m
>> aven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
>> --
>> diff --git 
>> a/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
>> b/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
>> index a9038bf..20376d9 100644
>> --- a/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
>> +++ b/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
>> @@ -24,9 +24,9 @@ import java.io.PrintWriter;
>> import org.apache.commons.cli.CommandLine;
>>  import org.apache.commons.cli.CommandLineParser;
>> -import org.apache.commons.cli.GnuParser;
>> +import org.apache.commons.cli.DefaultParser;
>>  import org.apache.commons.cli.HelpFormatter;
>> -import org.apache.commons.cli.OptionBuilder;
>> +import org.apache.commons.cli.Option;
>>  import org.apache.commons.cli.Options;
>>  import org.apache.commons.cli.ParseException;
>> @@ -35,43 +35,43 @@ import org.apache.commons.cli.ParseException;
>>   */
>>  public class CLIManager
>>  {
>> -public static final char ALTERNATE_POM_FILE = 'f';
>> +public static final String ALTERNATE_POM_FILE = "f";
>> -public static final char BATCH_MODE = 'B';
>> +public static final String BATCH_MODE = "B";
>> -public static final char SET_SYSTEM_PROPERTY = 'D';
>> +public static final String SET_SYSTEM_PROPERTY = "D";
>> -public static final char OFFLINE = 'o';
>> +public static final String OFFLINE = "o";
>> -public static final char QUIET = 'q';
>> +public static final String QUIET = "q";
>> -public static final char DEBUG = 'X';
>> +public static final String DEBUG = "X";
>> -public static final char ERRORS = 'e';
>> +public static final String ERRORS = "e";
>> -public static final char HELP = 'h';
>> +public static final String HELP = "h";
>> -public static final char VERSION = 'v';
>> +public static final String VERSION = "v";
>> -public static final char SHOW_VERSION = 'V';
>> +public static final String SHOW_VERSION = "V";
>> -public static final char NON_RECURSIVE = 'N';
>> +public static final String NON_RECURSIVE = "N";
>> -public static final char UPDATE_SNAPSHOTS = 'U';
>> +public static final String UPDATE_SNAPSHOTS = "U";
>> -public static final char ACTIVATE_PROFILES = 'P';
>> +public static final String ACTIVATE_PROFILES = "P";
>> public static final String SUPRESS_SNAPSHOT_UPDATES = "nsu";
>> -public static final char CHECKSUM_FAILURE_POLICY = 'C';
>> +public static final String CHECKSUM_FAILURE_POLICY = "C";
>> -public static final char CHECKSUM_WARNING_POLICY = 'c';
>> +public static final String CHECKSUM_WARNING_POLICY = "c";
>> -public static final char ALTERNATE_USER_SETTINGS = 's';
>> +public static final String ALTERNATE_USER_SETTINGS = "s";
>> public static final String ALTERNATE_GLOBAL_SETTINGS = "gs";
>> -public static final char ALTERNATE_USER_TOOLCHAINS = 't';
>> +public static final String ALTERNATE_USER_TOOLCHAINS = "t";
>> public static final String ALTERNATE_GLOBAL_TOOLCHAINS = "gt";
>> @@ -103,50 +103,52 @@ public class CLIManager
>> protected Options options;
>> -

[GitHub] maven-indexer issue #13: MINDEXER-97: Index/Store Extra OSGI Headers

[sesuncedu]

Github user sesuncedu commented on the issue:

https://github.com/apache/maven-indexer/pull/13
  
Also, if I do forward port, should I also try and forward port 
index-reader? 

And, if you are thinking of releasing 5.1.2, would you like me to do a more 
detailed  job of bundle making (e.g. extracting a pure api into a separate 
package, making the implementation private, adding per-package version numbers, 
and adding an activator to bind the implementation as a service). 

I'd also attach the bundle baseline task to the verify stage, even though 
it can't really do much till there's been a previous release to compare 
against. 


---
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

[DISCUSS] How to work with branches

[Stephen Connolly]

Unlike the other discuss threads, I think I have some extra context that
means I am going to start from my proposal... or rather my requirements and
then proposal to solve those requirements.

Requirements
===

As a Release Manager,

I cannot tell which branches on the CI server are targeted for the release
and which are "future work"

I cannot tell who is responsible for which branches in order to know who to
ask w.r.t. their status

As a PMC member tasked with reviewing commits

I cannot keep track of all the many commits and rebases

Proposal


1. We should use a naming scheme for all branches. I am suggesting
owner/targetBranch/mng- - this gives me the information about who owns
the branch and where the branch is targeted for.

2. We should have the Jenkinsfile build not just the head commit but the
head commit merged to the target branch for any branch following the naming
scheme. We get the target branch from the naming scheme and by having the
build verify that the branch can be merged without conflict onto the target
branch we remove the need for constant rebases

3. We merge branches with an explicit merge commit and stop using
fast-forward merging only. Again this makes it easier to review and allows
the noisy branches to be quiet when looked at from the PoV of master

This will not solve all the issues, but it would solve the pain points I
have currently.

Now if others have a different PoV or a counter-proposal, please speak up!

[GitHub] maven-indexer issue #13: MINDEXER-97: Index/Store Extra OSGI Headers

[sesuncedu]

Github user sesuncedu commented on the issue:

https://github.com/apache/maven-indexer/pull/13
  
Also, OSGI headers really need a custom analyzer, as they have their own 
nested organization and datatyping. It doesn't seem worth it for this change, 
but would be worth it for the next major if that were going to lucene 6 
(version number comparison + range searches could possibly be handled with a 
bit of trie-abuse. Qualifiers are the real headache, especially since maven and 
OSGI have different opinions about whether 5.0.0[.-]SNAPSHOT is in the range 
[4.3.0,5).   ) 


---
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: [DISCUSS] Towards a common understanding of things

[Christian Schulte]

Am 19.03.2017 um 13:13 schrieb Stephen Connolly:
> We need to define:
> 
> * what is a bug vs what is an rfe

I'll give it a try. Everything not working as documented/specified is a
bug, when there is consensus the documentation/specification is stating
the intended/correct behaviour. The design document on Maven
fundamentals we have is the Maven site. That is what users are reading
to learn Maven. There have been reports in JIRA telling us something
does not behave as documented. That's bugs, IMHO. Means we should put
more effort into that documentation and should never implement anything
without documenting it on the site. The release notes are not the right
place to do this.


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

[GitHub] maven-indexer issue #13: MINDEXER-97: Index/Store Extra OSGI Headers

[sesuncedu]

Github user sesuncedu commented on the issue:

https://github.com/apache/maven-indexer/pull/13
  
I have been consistently confused about which branch is live, so it would 
not surprise me either way ☺️. 
I had been working against main on some code to use the central index to 
build a database for use as an OSGI resolver. I noted the missing fields... 
after I'd done a whole bunch of defactoring to decouple index reading from the 
rest of the code D'oh! 

I can cross port these changes to master (well, not the index reader ones) 
:) My main goal is to get the extra fields into the index on central. I'd 
presume that 5.1.2 would be the smaller jump. 

Would it be possible to make a 5.1.2 release? And would it be possible to 
have  run it running on central in the near future?

 My primary concern if I were the admin would be the need to perform the 
sequential read of the entire bundle jar to generate the sha-256 checksum. It 
ought not be too significant a burden compared to the overall level of 
activity, but depending on what else is going on on the storage side, it might 
be annoying. 

I haven't checked  to see how full  reindexing is handled, and if a 
previously calculated SHA-256 could be fetched for less than the cost of the 
sequential read (lucene + cache + storage load / architecture = magic). 
Alternative would be to save SHA-256 hashes in a simple k/v store. 

 (now that full sha-1 has been broken, it is probably time to switch over 
to SHA-256, but that's a much more pervasive change). 



---
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: seconding MNG-6189: WARN if maven-site-plugin configuration contains reportPlugins element

[Stephen Connolly]

+1

On Sun 19 Mar 2017 at 16:21, Hervé BOUTEMY  wrote:

> see https://issues.apache.org/jira/browse/MNG-6189 for more details on the
> logic behind this warning.
>
> It's only a warning, and there is an IT to check the result
>
> I think it is safe and will help us continue cleaning users poms for people
> lost in stopped migration from  to  plugin>
>
> In addition, this will prepare maven-pdf-plugin work on the same topic
> https://issues.apache.org/jira/browse/MPDF-48
>
>
> Seconders?
>
> notice: what is hard in our process now is to have people understand the
> issue
> before being merged, and understanding starts by finding interest in taking
> time to try to understand a topic that is not yours.
> Is it bad? IMHO, no
> But it is hard after having taken time to describe the issue, fix it, test
> it,
> to now have to convince explicitely others
>
> Regards,
>
> Hervé
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

seconding MNG-6189: WARN if maven-site-plugin configuration contains reportPlugins element

[Hervé BOUTEMY]

see https://issues.apache.org/jira/browse/MNG-6189 for more details on the 
logic behind this warning.

It's only a warning, and there is an IT to check the result

I think it is safe and will help us continue cleaning users poms for people 
lost in stopped migration from  to 

In addition, this will prepare maven-pdf-plugin work on the same topic
https://issues.apache.org/jira/browse/MPDF-48


Seconders?

notice: what is hard in our process now is to have people understand the issue 
before being merged, and understanding starts by finding interest in taking 
time to try to understand a topic that is not yours.
Is it bad? IMHO, no
But it is hard after having taken time to describe the issue, fix it, test it, 
to now have to convince explicitely others

Regards,

Hervé

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

Re: [DISCUSS] Towards a common understanding of things

[Stephen Connolly]

Please let's keep this for the other thread I am trying to start off.

It's really related to how we work with branches and how we use CI

(But that is a more complex thread to kick off)

So let's keep this thread on topic please

On Sun 19 Mar 2017 at 15:59, Christian Schulte  wrote:

> Am 19.03.2017 um 13:13 schrieb Stephen Connolly:
> > We need to define:
> >
> > * what is a bug vs what is an rfe
> >
> > * what are the different severities for bugs and rfes
> >
> > * what severity bugs block: an alpha, a beta, a full release
> >
> > * what do the different release types mean? (My take, alpha is not
> feature
> > complete, beta is not free of bugs, rc is hopefully the real deal)
> >
> > * how do we decide when to bump major, minor and patch version numbers
> and
> > what scope of changes should be allowed in a non-patch bump
> >
>
> I'd like to add
>
> * how to commit to branches carrying the next release (master)? We are
> coming from everyone just commits to master as needed. Now everyone is
> creating branches and then merges that to master. Does not make much of
> a difference. What I do not like is that currently no one is testing
> things from branches of someone else. I am working with 3.5.0-SNAPSHOT
> (3.4.0-SNAPSHOT) locally for more than a year. A lot of testing no
> longer taking place the way we work with branches now. Maybe we should
> create a dedicated dev or snapshot branch everyone can merge to which
> then gets merged to master by some release manager when it's time to do.
> Process to create a release would be something like:
>
> - merge the snapshot/dev branch to master
> - release:prepare release:perform on master
> - merge the master branch with the next snapshot version back to the
> snapshot/dev branch
> - continue there until next release
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: [DISCUSS] Towards a common understanding of things

[Christian Schulte]

Am 19.03.2017 um 13:13 schrieb Stephen Connolly:
> We need to define:
> 
> * what is a bug vs what is an rfe
> 
> * what are the different severities for bugs and rfes
> 
> * what severity bugs block: an alpha, a beta, a full release
> 
> * what do the different release types mean? (My take, alpha is not feature
> complete, beta is not free of bugs, rc is hopefully the real deal)
> 
> * how do we decide when to bump major, minor and patch version numbers and
> what scope of changes should be allowed in a non-patch bump
> 

I'd like to add

* how to commit to branches carrying the next release (master)? We are
coming from everyone just commits to master as needed. Now everyone is
creating branches and then merges that to master. Does not make much of
a difference. What I do not like is that currently no one is testing
things from branches of someone else. I am working with 3.5.0-SNAPSHOT
(3.4.0-SNAPSHOT) locally for more than a year. A lot of testing no
longer taking place the way we work with branches now. Maybe we should
create a dedicated dev or snapshot branch everyone can merge to which
then gets merged to master by some release manager when it's time to do.
Process to create a release would be something like:

- merge the snapshot/dev branch to master
- release:prepare release:perform on master
- merge the master branch with the next snapshot version back to the
snapshot/dev branch
- continue there until next release

Regards,
-- 
Christian


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

Re: Distribution file permission issue with current master.

[Christian Schulte]

Am 19.03.2017 um 10:39 schrieb Hervé BOUTEMY:
> I updated parent pom, which brings a new m-assembly-p version that does not 
> have this bug

Thanks.

Regards,
-- 
Christian


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

Re: [SUMMARY] [DISCUSS] Retrospective on Maven 3.5.0-alpha-1

[Stephen Connolly]

Tibor,

Could you move this to its own thread.

Let's keep this retrospective thread closed. It's done it's job

Thanks in advance,

- Stephen
On Sun 19 Mar 2017 at 13:46, Tibor Digana  wrote:

> What marketing can we do in order to hire new developers?
> In my experience employees are still asking the same question "How much do
> they pay" ;-)
> I am still trying to explain that you are improving Maven used in your
> daily work.
>
> I do not want this great project to see dying. It's being widely used for
> long. Let's keep it alive even longer!
>
> On Sun, Mar 19, 2017 at 12:40 PM, stephenconnolly [via Maven] <
> ml-node+s40175n5902346...@n5.nabble.com> wrote:
>
> > On Sat 11 Mar 2017 at 21:56, Stephen Connolly <
> > [hidden email] >
> > wrote:
> >
> > Hi all,
> >
> > I think it is a good thing if we take stock of where we are and how we
> are
> > doing. I would really appreciate if everyone could take a few minutes to
> > respond with their top three of two areas:
> >
> > * What is working well
> >
> >
> > Seems we have some consensus here:
> >
> > * CI is working better (not perfect)
> >
> > * We are discussing changes before pushing them to master
> >
> > * Getting a release out the door
> >
> >
> > * What is not working well
> >
> >
> > Slightly harder to consolidate here, but there are some themes that I can
> > identify:
> >
> > * we need a better way to work with branches. There are traceability
> > issues
> > when looking at branches on the CI server. There are issues with
> > continuous
> > rebasing. There are questions about what is in flight for the next
> release
> > vs what is in flight for a future release. (I suspect this is all
> > intermingled and I'll start a thread to debate potential solutions
> > shortly)
> >
> > * we need a better process to scope changes for different target
> releases.
> > (The chaotic process for 3.5.0 was a one time attempt to deal with the
> > reality of the reset, so I never expected us to repeat it... but we still
> > need to come up with a process to plan what will be in each release)
> (I'll
> > start a thread shortly to see if we can come up with a process to use as
> > an
> > experiment for 3.5.1)
> >
> > * we need to agree on some common terminology. What is a bug, what is a
> > rfe, what is a breaking change. What is the severity of these things.
> What
> > severity issues affect different release types (alpha, beta, etc) How are
> > we versioning Maven and how does severity affect versioning. (I'll start
> a
> > thread on this shortly)
> >
> > * discussion threads that go on forever without coming to a conclusion.
> > (We
> > just need to have to remember to post a [SUMMARY] or call a [VOTE] to
> > close
> > them out... I shall lead by example here)
> >
> > * ubuntu and Windows are not enough OSes to test on (the PMC needs to
> > decide if we want to ask for budget to get such extra nodes... otherwise
> > this is out of our hands... Michael-O should start a discussion to see
> if:
> > 1. This is what the committers want and 2. To find out how much what we
> > want would cost and see about requesting off the board in our next
> budget)
> >
> > * how do we grow our community (I think we just have to get momentum
> going
> > and the contributions will come... the project has looked dead, who's
> > going
> > to contribute to a dead project... if anyone disagrees please start up a
> > discussion thread)
> >
> >
> > I'll consolidate the responses after 72h and see if there are any themes
> > that can be identified
> >
> > On the stuff that is not working well, I'll try and pick the three most
> > popular themes, we can then have a round of discussion on those three
> > themes to see if anyone has any ideas to improve those aspects of how we
> > work and hopefully we can have some votes to change things for the
> better.
> >
> > By the way, this is open to anyone in any way what so ever involved with
> > the Maven 3.5.0-alpha-1 effort (assuming you are paying attention to the
> > dev list ;-) )
> >
> > Thanks in advance for your time,
> >
> > -Stephen
> >
> > P.S. As alpha-2 is near, I'll probably wait until after 3.5.0 before I
> try
> > this again (assuming people like this idea)
> >
> > --
> > Sent from my phone
> >
> >
> > --
> > If you reply to this email, your message will be added to the discussion
> > below:
> > http://maven.40175.n5.nabble.com/SUMMARY-DISCUSS-
> > Retrospective-on-Maven-3-5-0-alpha-1-tp5902346.html
> > To start a new topic under Maven Developers, email
> > ml-node+s40175n142166...@n5.nabble.com
> > To unsubscribe from Maven Developers, click here
> > <
> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code=142166=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==
> >
> > .
> > NAML
> > <
> 

[GitHub] maven-indexer issue #13: MINDEXER-97: Index/Store Extra OSGI Headers

[carlspring]

Github user carlspring commented on the issue:

https://github.com/apache/maven-indexer/pull/13
  


Hi,

Shouldn't this be applied to the `master` branch and be included in `6.0` 
instead?

@cstamas : What do you think?

Cheers,

Martin





---
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: [SUMMARY] [DISCUSS] Retrospective on Maven 3.5.0-alpha-1

[Tibor Digana]

What marketing can we do in order to hire new developers?
In my experience employees are still asking the same question "How much do
they pay" ;-)
I am still trying to explain that you are improving Maven used in your
daily work.

I do not want this great project to see dying. It's being widely used for
long. Let's keep it alive even longer!

On Sun, Mar 19, 2017 at 12:40 PM, stephenconnolly [via Maven] <
ml-node+s40175n5902346...@n5.nabble.com> wrote:

> On Sat 11 Mar 2017 at 21:56, Stephen Connolly <
> [hidden email] >
> wrote:
>
> Hi all,
>
> I think it is a good thing if we take stock of where we are and how we are
> doing. I would really appreciate if everyone could take a few minutes to
> respond with their top three of two areas:
>
> * What is working well
>
>
> Seems we have some consensus here:
>
> * CI is working better (not perfect)
>
> * We are discussing changes before pushing them to master
>
> * Getting a release out the door
>
>
> * What is not working well
>
>
> Slightly harder to consolidate here, but there are some themes that I can
> identify:
>
> * we need a better way to work with branches. There are traceability
> issues
> when looking at branches on the CI server. There are issues with
> continuous
> rebasing. There are questions about what is in flight for the next release
> vs what is in flight for a future release. (I suspect this is all
> intermingled and I'll start a thread to debate potential solutions
> shortly)
>
> * we need a better process to scope changes for different target releases.
> (The chaotic process for 3.5.0 was a one time attempt to deal with the
> reality of the reset, so I never expected us to repeat it... but we still
> need to come up with a process to plan what will be in each release) (I'll
> start a thread shortly to see if we can come up with a process to use as
> an
> experiment for 3.5.1)
>
> * we need to agree on some common terminology. What is a bug, what is a
> rfe, what is a breaking change. What is the severity of these things. What
> severity issues affect different release types (alpha, beta, etc) How are
> we versioning Maven and how does severity affect versioning. (I'll start a
> thread on this shortly)
>
> * discussion threads that go on forever without coming to a conclusion.
> (We
> just need to have to remember to post a [SUMMARY] or call a [VOTE] to
> close
> them out... I shall lead by example here)
>
> * ubuntu and Windows are not enough OSes to test on (the PMC needs to
> decide if we want to ask for budget to get such extra nodes... otherwise
> this is out of our hands... Michael-O should start a discussion to see if:
> 1. This is what the committers want and 2. To find out how much what we
> want would cost and see about requesting off the board in our next budget)
>
> * how do we grow our community (I think we just have to get momentum going
> and the contributions will come... the project has looked dead, who's
> going
> to contribute to a dead project... if anyone disagrees please start up a
> discussion thread)
>
>
> I'll consolidate the responses after 72h and see if there are any themes
> that can be identified
>
> On the stuff that is not working well, I'll try and pick the three most
> popular themes, we can then have a round of discussion on those three
> themes to see if anyone has any ideas to improve those aspects of how we
> work and hopefully we can have some votes to change things for the better.
>
> By the way, this is open to anyone in any way what so ever involved with
> the Maven 3.5.0-alpha-1 effort (assuming you are paying attention to the
> dev list ;-) )
>
> Thanks in advance for your time,
>
> -Stephen
>
> P.S. As alpha-2 is near, I'll probably wait until after 3.5.0 before I try
> this again (assuming people like this idea)
>
> --
> Sent from my phone
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/SUMMARY-DISCUSS-
> Retrospective-on-Maven-3-5-0-alpha-1-tp5902346.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/Re-SUMMARY-DISCUSS-Retrospective-on-Maven-3-5-0-alpha-1-tp5902363.html
Sent from the Maven Developers mailing list archive at Nabble.com.

[DISCUSS] Towards a common understanding of things

[Stephen Connolly]

We need to define:

* what is a bug vs what is an rfe

* what are the different severities for bugs and rfes

* what severity bugs block: an alpha, a beta, a full release

* what do the different release types mean? (My take, alpha is not feature
complete, beta is not free of bugs, rc is hopefully the real deal)

* how do we decide when to bump major, minor and patch version numbers and
what scope of changes should be allowed in a non-patch bump
-- 
Sent from my phone

[GitHub] maven-indexer issue #13: MINDEXER-97: Index/Store Extra OSGI Headers

[balazs-zsoldos]

Github user balazs-zsoldos commented on the issue:

https://github.com/apache/maven-indexer/pull/13
  
+1


---
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

[DISCUSS] Planning process for 3.5.1

[Stephen Connolly]

So planning for 3.5.0 was total chaos... but it seems to have worked.

How do we want to work for 3.5.1?

(As usual, I have my own ideas but I will hold back until I see some
suggestions from others because we are a community and as release manager
for 3.5.1 my opinion might be too powerful and we could miss out on a
really great idea just because I've said my "slightly crappy idea" ;-) )
-- 
Sent from my phone

[SUMMARY] [DISCUSS] Retrospective on Maven 3.5.0-alpha-1

[Stephen Connolly]

On Sat 11 Mar 2017 at 21:56, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

Hi all,

I think it is a good thing if we take stock of where we are and how we are
doing. I would really appreciate if everyone could take a few minutes to
respond with their top three of two areas:

* What is working well


Seems we have some consensus here:

* CI is working better (not perfect)

* We are discussing changes before pushing them to master

* Getting a release out the door


* What is not working well


Slightly harder to consolidate here, but there are some themes that I can
identify:

* we need a better way to work with branches. There are traceability issues
when looking at branches on the CI server. There are issues with continuous
rebasing. There are questions about what is in flight for the next release
vs what is in flight for a future release. (I suspect this is all
intermingled and I'll start a thread to debate potential solutions shortly)

* we need a better process to scope changes for different target releases.
(The chaotic process for 3.5.0 was a one time attempt to deal with the
reality of the reset, so I never expected us to repeat it... but we still
need to come up with a process to plan what will be in each release) (I'll
start a thread shortly to see if we can come up with a process to use as an
experiment for 3.5.1)

* we need to agree on some common terminology. What is a bug, what is a
rfe, what is a breaking change. What is the severity of these things. What
severity issues affect different release types (alpha, beta, etc) How are
we versioning Maven and how does severity affect versioning. (I'll start a
thread on this shortly)

* discussion threads that go on forever without coming to a conclusion. (We
just need to have to remember to post a [SUMMARY] or call a [VOTE] to close
them out... I shall lead by example here)

* ubuntu and Windows are not enough OSes to test on (the PMC needs to
decide if we want to ask for budget to get such extra nodes... otherwise
this is out of our hands... Michael-O should start a discussion to see if:
1. This is what the committers want and 2. To find out how much what we
want would cost and see about requesting off the board in our next budget)

* how do we grow our community (I think we just have to get momentum going
and the contributions will come... the project has looked dead, who's going
to contribute to a dead project... if anyone disagrees please start up a
discussion thread)


I'll consolidate the responses after 72h and see if there are any themes
that can be identified

On the stuff that is not working well, I'll try and pick the three most
popular themes, we can then have a round of discussion on those three
themes to see if anyone has any ideas to improve those aspects of how we
work and hopefully we can have some votes to change things for the better.

By the way, this is open to anyone in any way what so ever involved with
the Maven 3.5.0-alpha-1 effort (assuming you are paying attention to the
dev list ;-) )

Thanks in advance for your time,

-Stephen

P.S. As alpha-2 is near, I'll probably wait until after 3.5.0 before I try
this again (assuming people like this idea)

-- 
Sent from my phone

Maven Site / Report Plugins

[Karl Heinz Marbaise]

Hi,

currently I stumbled over a thing which I don't understand.

I have parent pom[1] which defines several parts of a site including 
some reports for example maven-changes-plugin with github-report..


Now I inherit from that parent pom and of course I can do a mvn site.

But now the important part.

I would like to deactive maven-changes-plugin in particular 
github-report...cause this test project does not has a github repo which 
will fail the mvn site build..


I have taken a look into the documentation[2] to find a way to deactive 
github-report or maven-changes-plugin at all...I tried to change 
maven-project-info-reports parts etc. but without any luck..


Does someone has a good hint how to do this ?

Kind regards
Karl Heinz Marbaise

[1]: https://github.com/khmarbaise/smpp/blob/master/pom.xml
[2]: http://maven.apache.org/pom.html#Reporting

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

Re: Distribution file permission issue with current master.

[Hervé BOUTEMY]

yes, this is a critical bug

in fact, I didn't understand your initial report and didn't see that there was 
an issue with only the .zip distribution file (every other distribution -- that 
I tried -- does not have this issue, and this jansi-native directory is not 
different from other directory that are in our source tree)

I updated parent pom, which brings a new m-assembly-p version that does not 
have this bug

Regards,

Hervé

Le dimanche 19 mars 2017, 04:22:16 CET Christian Schulte a écrit :
> Am 03/15/17 um 23:37 schrieb Hervé BOUTEMY:
> > no issue for me on Linux
> > I don't understand what happens to you: I suppose this is once again
> > related to FreeBSD
> > I can't do anything for you
> 
> Upgrading the assembly plugin to 2.6 solves this. Should we consider
> upgrading the parent for alpha-2 from 27 to 30? Just the assembly
> plugin? We would be shipping a somehow broken zip file with current
> master due to some assembly plugin or plexus-archiver issue (I did not
> dig any deeper into this and just tried a more recent assembly plugin).
> 
> Regards,



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

Re: [08/17] maven git commit: [MNG-6182] ModelResolver interface enhancements.

[Stephen Connolly]

On Sun 19 Mar 2017 at 02:58, Christian Schulte  wrote:

> Branch name is MNG-6182
>
> <
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=shortlog;h=refs/heads/MNG-6182
> >
>
> Commit is
>
> <
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=4fc5e2180b3f230740778b7106b79c5a9cf8619f
> >


Brief look on my phone says that's ok

Will review more closely later


>
> Should I create a separate JIRA issue for this?
>

No need, tests are for the feature and we should not be adding features
without testing


> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone