Re: What to do with the 6 issues left as 3.5.0-candidates?

[Christian Schulte]

Am 03/25/17 um 07:17 schrieb Hervé BOUTEMY:
> MNG-6112 is harder to estimate side effects IMHO
> and since this has been available for a long time, I'm really not satisfied 
> that it has been integrated *after vote for 3.0.5-beta-1 started* (and in 
> addition without any discussion)

Issue has been mentioned by Michael Osipov somewhen during development
of 3.4.0 in MNG-4645. I just created a separate issue in JIRA for it.
There has been a discussion. There also has been an in depth search
starting from GIT back to the initial commit in subversion by me
documented in MNG-4645.



> 
>  I'd say punt to 3.5.1: benefit is not worth the risk for now (we lived for 
> years with that, we can stay with it for a couple of months to have wider 
> tests)

Last time I looked at it, Maven never updated release versions. Commit
is just making this explicit in the repository declaration. This
sentence "There are still 10  issues left in JIRA for 3.5.0," in the
vote email for beta-1 made me look at the list. I thought we already
agreed to these issues for 3.5.0 and just wanted to close the remaining
issues assigned to me.

Regards,
-- 
Christian


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

Re: What to do with the 6 issues left as 3.5.0-candidates?

[Christian Schulte]

We really need Solaris and OSX Jenkins build nodes :-)


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

Re: What to do with the 6 issues left as 3.5.0-candidates?

[Christian Schulte]

Am 03/25/17 um 01:30 schrieb Christian Schulte:
> Am 03/24/17 um 23:28 schrieb Stephen Connolly:
>> Keep in mind that AIUI we aim to be BourneShell compatible in which case $(
>> ) is not available
> 
> Thanks for pointing this out. Our launchers have this in the first line:
> 
> #!/bin/sh
> 
> /bin/sh should be a POSIX compatible shell. On the BSDs, OSX and Solaris
> (IIRC) this is some kind of ksh. The man page on OpenBSD explicitly
> states this:
> 
> This version of sh is actually ksh in disguise. As such, it also
> supports the features described in ksh(1). This manual page describes
> only the parts relevant to a POSIX compliant sh. If portability is a
> concern, use only those features described in this page.
> 
> They provide different man pages for sh and ksh although /bin/sh is ksh.
> 
> http://man.openbsd.org/sh
> http://man.openbsd.org/ksh
> 
> Can you provide a link to some BourneShell man page (a real one, not
> bash)? We should fix the launchers in 3.5.0 once and for all.
> 
> Currently reading the "Shell & Utilities" volume from here:
> 
> <http://pubs.opengroup.org/onlinepubs/9699919799/>
> 
> This is what we should be compatible to. Did not find anything about
> "readlink" in there so we should not be using it and find a compliant
> solution.
> 
> Regards,
> 

Seems we really should be using "`pwd -P`" as you suggested.

<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pwd.html>


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

Re: What to do with the 6 issues left as 3.5.0-candidates?

[Christian Schulte]

Am 03/24/17 um 23:28 schrieb Stephen Connolly:
> Keep in mind that AIUI we aim to be BourneShell compatible in which case $(
> ) is not available

Thanks for pointing this out. Our launchers have this in the first line:

#!/bin/sh

/bin/sh should be a POSIX compatible shell. On the BSDs, OSX and Solaris
(IIRC) this is some kind of ksh. The man page on OpenBSD explicitly
states this:

This version of sh is actually ksh in disguise. As such, it also
supports the features described in ksh(1). This manual page describes
only the parts relevant to a POSIX compliant sh. If portability is a
concern, use only those features described in this page.

They provide different man pages for sh and ksh although /bin/sh is ksh.

http://man.openbsd.org/sh
http://man.openbsd.org/ksh

Can you provide a link to some BourneShell man page (a real one, not
bash)? We should fix the launchers in 3.5.0 once and for all.

Currently reading the "Shell & Utilities" volume from here:



This is what we should be compatible to. Did not find anything about
"readlink" in there so we should not be using it and find a compliant
solution.

Regards,
-- 
Christian


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

Re: What to do with the 6 issues left as 3.5.0-candidates?

[Christian Schulte]

Am 03/24/17 um 22:51 schrieb Stephen Connolly:
> I am concerned that there are some quoting issues in mvn.
> 
> In some cases we use var=`command` and in others we use var="`command`"
> 
> Additionally we have a mixture of backtick and $(...) style. My
> understanding is that the backticks are for older shells...
> but if that is the case we should use backticks consistently
> 
> line 64: saveddir=`pwd`
> should be? saveddir="`pwd`"
> 
> line 66: MAVEN_HOME=`dirname "$PRG"`/..
> should be? MAVEN_HOME="`dirname "$PRG"`/.."
> 
> line 69: MAVEN_HOME=`cd "$MAVEN_HOME" && pwd`
> should be? MAVEN_HOME="`cd "$MAVEN_HOME" && pwd`"
> 
> line 105: CLASSWORLDS_JAR=`echo
> "${MAVEN_HOME}"/boot/plexus-classworlds-*.jar`
> should be? CLASSWORLDS_JAR="`echo
> "${MAVEN_HOME}"/boot/plexus-classworlds-*.jar`"
> 
> line 128:  basedir=$wdir
> should be?  basedir="$wdir"
> 
> line 145: basedir=$(dirname "$(readlink -f "${arg}")")
> should be? basedir="$(dirname "$(readlink -f "${arg}")")"
> (or perhaps)basedir="$(cd "$(dirname "${arg}")" && pwd -P)"
> 
> line 178:  MAVEN_PROJECTBASEDIR=`cygpath --path --windows
> "$MAVEN_PROJECTBASEDIR"`
> should be?  MAVEN_PROJECTBASEDIR="`cygpath --path --windows
> "$MAVEN_PROJECTBASEDIR"`"
> 
> /me got tired looking at the file after this point in time!
>

According to the "Expansion" section from the sh man page
() the double quotes should be there to
disable field splitting.

[...]
Command expansion has a command executed in a subshell and the results
output in its place.  The basic format is:

$(command)

  or

`command`

The results are subject to field splitting and pathname expansion; no
other form of expansion happens.  If command is contained within double
quotes, field splitting does not happen either.  Within backquotes, a
backslash is treated literally unless it follows a dollar sign,
backquote, or another backslash.  Commands can be nested, though the
backquoted version requires backslashes before the backquotes. If
command is run in a subshell in the bracketed version, the syntax is
identical to that of arithmetic expansion. In that case the shell
attempts arithmetic expansion first, then attempts command substitution
if that fails.  Or a non-ambiguous version can be used:

$( (command) )

Arithmetic expansion works similarly, with an arithmetic expression
being evaluated and substituted. The format is:

$((expression))

Where expression is an integer, parameter name, or array reference,
optionally combined with any of the operators described below, listed
and grouped according to precedence:
[...]

Regards,
-- 
Christian


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

Re: What to do with the 6 issues left as 3.5.0-candidates?

[Christian Schulte]

Am 03/24/17 um 11:45 schrieb Stephen Connolly:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.5.0-candidate%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> 
> Here is my opinions:
> 
> https://issues.apache.org/jira/browse/MNG-6168 - If this is available and
> ready quickly (i.e. in the next week), we can review the changes and assess
> the risk

Branch is here:


Commit is here:


Will merge to master, as soon as the build job succeeds. It's just
updates to use the try-with-resources statement instead of
try-catch-finally with IOUtil.close.

Regards,
-- 
Christian


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

Re: [VOTE] Release Apache Maven 3.5.0-beta-1

[Christian Schulte]

Am 03/24/17 um 16:54 schrieb Karl Heinz Marbaise:
> Hi,
> 
> On 24/03/17 02:17, Hervé BOUTEMY wrote:
>> we have absolutely no OSX user building Maven core ITs on his personal
>> computer?
>> seriously?
>> Or is there no core IT that shows the issue? then it has to be discovered by
>> hand?
> 
> I can test today evening or tomorrow...on my Mac..

You'd need to find an alternative to "readlink -f" on OSX. There are
solutions available on stackoverflow. Nothing of this can be done
without being able to test.

> If this helps?

Indeed. Thanks.

Regards,
-- 
Christian


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

Re: [VOTE] Release Apache Maven 3.5.0-beta-1

[Christian Schulte]

Am 03/23/17 um 19:20 schrieb Christian Schulte:
> Am 03/23/17 um 10:08 schrieb Stephen Connolly:
>> Hervé do you think this ordering issue is serious enough to drop and run a
>> beta-2?
>>
>> IMHO no as it is just a beta and we can add it as a known issue in the
>> release notes.
> 
> Unrelated to this issue there has been another report regarding the
> launcher scripts: MNG-6191
> 
> We maybe should do a -beta-2 before the final release with this fixed as
> well.
> 
> Seems "readlink" does not support the "-f" option on OSX. Can someone
> with a OSX installation take a look please? The launcher scripts are in
> scope for 3.5.0.
> 
> Regards,
> 

This would not have happened with an OSX Jenkins build node, BTW.


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

Re: [VOTE] Release Apache Maven 3.5.0-beta-1

[Christian Schulte]

Am 03/23/17 um 10:08 schrieb Stephen Connolly:
> Hervé do you think this ordering issue is serious enough to drop and run a
> beta-2?
> 
> IMHO no as it is just a beta and we can add it as a known issue in the
> release notes.

Unrelated to this issue there has been another report regarding the
launcher scripts: MNG-6191

We maybe should do a -beta-2 before the final release with this fixed as
well.

Seems "readlink" does not support the "-f" option on OSX. Can someone
with a OSX installation take a look please? The launcher scripts are in
scope for 3.5.0.

Regards,
-- 
Christian


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

Re: [2/2] maven git commit: [MNG-6113] Rename the 'Central Repository' to 'Maven Central Repository' in the 4.0.0 super POM.

[Christian Schulte]

Am 03/21/17 um 19:44 schrieb Hervé BOUTEMY:
> -1
> 
> see MNG-5164

Thanks for pointing this out. I closed the issue "Won't Fix" and flagged
it a duplicate of MNG-5164. Branch is dropped. This would have went
unnoticed into the 3.4.0 release :-).

Regards,
-- 
Christian


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

Re: maven-3.x-jenkinsfile/MNG-6112 - build #1 - null

[Christian Schulte]

Am 03/21/17 um 03:57 schrieb Apache Jenkins Server:
> See https://builds.apache.org/job/maven-3.x-jenkinsfile/job/MNG-6112/1/
> 

Seems "null" does not always indicate a successful build. Can someone
take a look at this please and maybe update the Jenkinsfile to have a
subject indicating failures properly. This build job failed, right?

Regards,
-- 
Christian


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

Re: @since 3.5.0-alpha-2

[Christian Schulte]

Am 03/20/17 um 20:25 schrieb Stephen Connolly:
> Hervé requested to go straight to beta.
> 
> Since tags should be for the official release not alphas or betas imho

Ok. I'll update some since tags to 3.5.0 before the next release. No
need for a JIRA issue, right?

Regards,
-- 
Christian


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

@since 3.5.0-alpha-2

[Christian Schulte]

There will be no alpha-2? Should I update those @since tags to match the
new beta-1 name? Maybe something to add to the other discussions.

Regards,
-- 
Christian

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

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.

<https://github.com/apache/maven-resolver/pull/4>
<https://github.com/apache/maven/pull/107>

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

[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

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

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: Distribution file permission issue with current master.

[Christian Schulte]

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


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

[Christian Schulte]

Branch name is MNG-6182



Commit is



Should I create a separate JIRA issue for this?

Regards,
-- 
Christian


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

[Christian Schulte]

Am 03/18/17 um 14:04 schrieb Stephen Connolly:
> Given that these new methods actually have implementations, could we see
> about having at least a unit test of the new code - since it will not be
> covered by any test.

There would be an integration test for the code. Since nothing uses it,
no way to add anything to the ITs.

> 
> If we have no test and no usage, then we could realistically replace the
> implementations with `throw new UnsupportedOperationsException("Not
> implemented yet");` which would defeat the claimed purpose on the JIRA of
> making this code available to IDE integrators.

Throwing an UnsupportedOperationException would be an option. Reverting
the commit also would be an option.

> So I think to make "live" code available, we need at least a sanity check
> of the new code with a unit test or two... nothing fancy.

Just tell me what I should do.

a) revert the commit and postpone to 3.6.0.
b) remove the implementation and throw an UnsupportedOperationException

I do not know how the public Maven API has been versioned in the past.
The method will be needed to add support for dependency management
*import* version ranges to the model builder. If we would add this in
3.5.1, we would add methods to an interface of Maven's public API in a
patch release. No one would expect this to happen. We have done this in
the past. Just take a look at the history of the 'ModelResolver'
interface. This is something we should try to avoid to happen as much as
possible.

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 03/18/17 um 20:33 schrieb Christian Schulte:
> Am 03/18/17 um 20:33 schrieb Christian Schulte:
>> 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
>>
>> I am having the same issue on Jenkins with Linux, BTW. Seems the "unzip"
>> command cannot handle our ZIPs correctly. Using the "jar" command, the
>> permissions are as expected.
>>
>> <https://builds.apache.org/view/Maven%20Master%20Release%20Status/job/maven-master-release-status-test-doxia-linux/14/console>
>>
>> + xargs -0 rm -rf
>> rm: cannot remove
>> '/home/jenkins/jenkins-slave/workspace/maven-master-release-status-test-doxia-linux/apache-maven-dist/lib/jansi-native':
>> Permission denied
>> Build step 'Execute shell' marked build as failure
>>
>> In the assembly descriptor, the jansi related files are the only ones
>> having the file mode set. Can we just remove this from the descriptors
>> until we know what is going on?
>>
>> Regards,
>>
> 
> Talking about
> 
> $ unzip
> UnZip 6.00 of 20 April 2009, by Info-ZIP.  Maintained by C. Spieler.  Send
> bug reports using http://www.info-zip.org/zip-bug.html; see README for
> details.

This is the output of zipinfo:

Note this line with incorrect permissions.

d-  2.0 unx0 b- stor 17-Mar-15 03:06
apache-maven-3.5.0-SNAPSHOT/lib/jansi-native/


Archive:  apache-maven-3.5.0-SNAPSHOT-bin.zip
Zip file size: 8693301 bytes, number of entries: 112
drwxr-xr-x  2.0 unx0 b- stor 17-Mar-15 03:07
apache-maven-3.5.0-SNAPSHOT/
drwxr-xr-x  2.0 unx0 b- stor 17-Mar-15 03:07
apache-maven-3.5.0-SNAPSHOT/boot/
-rw-r--r--  2.0 unx52684 bl defN 16-Oct-11 01:19
apache-maven-3.5.0-SNAPSHOT/boot/plexus-classworlds-2.5.2.jar
drwxr-xr-x  2.0 unx0 b- stor 17-Mar-15 03:07
apache-maven-3.5.0-SNAPSHOT/lib/
-rw-r--r--  2.0 unx98054 bl defN 17-Mar-15 03:06
apache-maven-3.5.0-SNAPSHOT/lib/maven-embedder-3.5.0-SNAPSHOT.jar
-rw-r--r--  2.0 unx44619 bl defN 17-Mar-15 03:04
apache-maven-3.5.0-SNAPSHOT/lib/maven-settings-3.5.0-SNAPSHOT.jar
-rw-r--r--  2.0 unx   247351 bl defN 16-Oct-06 02:24
apache-maven-3.5.0-SNAPSHOT/lib/plexus-utils-3.0.24.jar
-rw-r--r--  2.0 unx   624267 bl defN 17-Mar-15 03:05
apache-maven-3.5.0-SNAPSHOT/lib/maven-core-3.5.0-SNAPSHOT.jar
-rw-r--r--  2.0 unx   165047 bl defN 17-Mar-15 03:03
apache-maven-3.5.0-SNAPSHOT/lib/maven-model-3.5.0-SNAPSHOT.jar
-rw-r--r--  2.0 unx   479881 bl defN 16-Nov-14 03:30
apache-maven-3.5.0-SNAPSHOT/lib/commons-lang3-3.5.jar
-rw-r--r--  2.0 unx42885 bl defN 17-Mar-15 03:04
apache-maven-3.5.0-SNAPSHOT/lib/maven-settings-builder-3.5.0-SNAPSHOT.jar
-rw-r--r--  2.0 unx14915 bl defN 17-Mar-15 03:03
apache-maven-3.5.0-SNAPSHOT/lib/maven-builder-support-3.5.0-SNAPSHOT.jar
-rw-r--r--  2.0 unx78876 bl defN 16-Nov-12 21:28
apache-maven-3.5.0-SNAPSHOT/lib/plexus-interpolation-1.24.jar
-rw-r--r--  2.0 unx 4288 bl defN 16-Oct-18 16:44
apache-maven-3.5.0-SNAPSHOT/lib/plexus-component-annotations-1.7.1.jar
-rw-r--r--  2.0 unx27703 bl defN 16-Oct-09 00:16
apache-maven-3.5.0-SNAPSHOT/lib/plexus-sec-dispatcher-1.4.jar
-rw-r--r--  2.0 unx13350 bl defN 16-Oct-11 23:26
apache-maven-3.5.0-SNAPSHOT/lib/plexus-cipher-1.7.jar
-rw-r--r--  2.0 unx27514 bl defN 17-Mar-15 03:04
apache-maven-3.5.0-SNAPSHOT/lib/maven-repository-metadata-3.5.0-SNAPSHOT.jar
-rw-r--r--  2.0 unx55032 bl defN 17-Mar-15 03:03
apache-maven-3.5.0-SNAPSHOT/lib/maven-artifact-3.5.0-SNAPSHOT.jar
-rw-r--r--  2.0 unx47816 bl defN 17-Mar-15 03:03
apache-maven-3.5.0-SNAPSHOT/lib/maven-plugin-api-3.5.0-SNAPSHOT.jar
-rw-r--r--  2.0 unx   205307 bl defN 16-Oct-11 01:19
apache-maven-3.5.0-SNAPSHOT/lib/org.eclipse.sisu.plexus-0.3.3.jar
-rw-r--r--  2.0 unx44908 bl defN 16-Oct-11 01:19
apache-maven-3.5.0-SNAPSHOT/lib/cdi-api-1.0.jar
-rw-r--r--  2.0 unx 5848 bl defN 16-Oct-11 01:19
apache-maven-3.5.0-SNAPSHOT/lib/jsr250-api-1.0.jar
-rw-r--r--  2.0 unx 2497 bl defN 16-Oct-11 01:19
apache-maven-3.5.0-SNAPSHOT/lib/javax.inject-1.jar
-rw-r--r--  2.0 unx   379175 bl defN 16-Oct-11 01:19
apache-maven-3.5.0-SNAPSHOT/lib/org.eclipse.sisu.inject-0.3.3.jar
-rw-r--r--  2.0 unx   178539 bl defN 17-Mar-15 03:04
apache-maven-3.5.0-SNAPSHOT/lib/maven-model-builder-3.5.0-SNAPSHOT.jar
-rw-r--r--  2.0 unx  2442625 bl defN 16-Nov-14 03:32
apache-maven-3.5.0-SNAPSHOT/lib/guava-20.0.jar
-rw-r--r--  2.0 unx68322 bl defN 17-Mar-15 03:04
apache-maven-3.5.0-SNAPSHOT/lib/maven-resolver-provider-3.5.0-SNAPSHOT.jar
-rw-r--r--  2.0 unx   146422 bl defN 17-Feb-04 23:48
apache-maven-3.5.0-SNAPSHOT/lib/maven-resolver-api-1.0.3.jar
-rw-r--r--  2.0 unx35583 bl defN 17-Feb-04 23:48
ap

Re: Distribution file permission issue with current master.

[Christian Schulte]

Am 03/18/17 um 20:33 schrieb Christian Schulte:
> 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
> 
> I am having the same issue on Jenkins with Linux, BTW. Seems the "unzip"
> command cannot handle our ZIPs correctly. Using the "jar" command, the
> permissions are as expected.
> 
> <https://builds.apache.org/view/Maven%20Master%20Release%20Status/job/maven-master-release-status-test-doxia-linux/14/console>
> 
> + xargs -0 rm -rf
> rm: cannot remove
> '/home/jenkins/jenkins-slave/workspace/maven-master-release-status-test-doxia-linux/apache-maven-dist/lib/jansi-native':
> Permission denied
> Build step 'Execute shell' marked build as failure
> 
> In the assembly descriptor, the jansi related files are the only ones
> having the file mode set. Can we just remove this from the descriptors
> until we know what is going on?
> 
> Regards,
> 

Talking about

$ unzip
UnZip 6.00 of 20 April 2009, by Info-ZIP.  Maintained by C. Spieler.  Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for
details.



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

I am having the same issue on Jenkins with Linux, BTW. Seems the "unzip"
command cannot handle our ZIPs correctly. Using the "jar" command, the
permissions are as expected.



+ xargs -0 rm -rf
rm: cannot remove
'/home/jenkins/jenkins-slave/workspace/maven-master-release-status-test-doxia-linux/apache-maven-dist/lib/jansi-native':
Permission denied
Build step 'Execute shell' marked build as failure

In the assembly descriptor, the jansi related files are the only ones
having the file mode set. Can we just remove this from the descriptors
until we know what is going on?

Regards,
-- 
Christian


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

Re: Maven Resolver 1.1

[Christian Schulte]

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:



The resolver just needs to provide a liddle bit more information to have
those messages complete.

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

Thanks for taking a look. It's happening with the zip distribution only.
It's not happening using the tar distribution. Will take a look at the
assembly plugin for what is going on.

Regards,
-- 
Christian


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

Re: Release build failing with current master (was Re: [PING] The GIT master branch of Maven has unreleased changes that do not pass a release build)

[Christian Schulte]

Am 03/15/17 um 23:00 schrieb Robert Scholte:
> The javadoc-fix is easy, but the result of modello-maven-plugin:1.9.0:xdoc  
> now causes issues because html4 is not the same as balanced xml. Need to  
> think about how to fix this.
> Maybe this commit should be reverted.

Cannot tell. Stephen? Can we upgrade/fix the modello plugin before
alpha-2? The Maven release will be done using JDK 7, IIRC. I just wanted
to start a release status build with current master to see how the other
codebases behave but could not.



Regards,
-- 
Christian


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

Re: Release build failing with current master (was Re: [PING] The GIT master branch of Maven has unreleased changes that do not pass a release build)

[Christian Schulte]

Am 03/15/17 um 22:30 schrieb Robert Scholte:
> ok, so that argument should be moved to a java8 activated profile.

Can you do this, please?

Regards,
-- 
Christian


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

Re: Release build failing with current master (was Re: [PING] The GIT master branch of Maven has unreleased changes that do not pass a release build)

[Christian Schulte]

Am 03/15/17 um 21:50 schrieb Michael Osipov:
> Am 2017-03-15 um 21:39 schrieb Christian Schulte:
>> Hi,
>>
>> this is a real issue. A release build using JDK 7 with current master is
>> not possible. See
>>
>> <https://builds.apache.org/view/Maven%20Master%20Release%20Status/job/maven-master-release-status-build/235/consoleFull>
>>
>> Exit code: 1 - javadoc: error - invalid flag: -Xdoclint:none
> 
> doclint should actually be in a profile for Java 8+. Confusing that it 
> didn't fail earlier...

<https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=587317b0095fc5d51041fed9e5b4786246a29a7b#patch3>


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

Release build failing with current master (was Re: [PING] The GIT master branch of Maven has unreleased changes that do not pass a release build)

[Christian Schulte]

Hi,

this is a real issue. A release build using JDK 7 with current master is
not possible. See



Exit code: 1 - javadoc: error - invalid flag: -Xdoclint:none

Regards,
-- 
Christian


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

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

[Christian Schulte]

Am 03/14/17 um 01:27 schrieb Jeff Jensen:
>> The date of the commit is not the date it got committed to master, but the
> date it got committed to some branch, no longer existing after the commit.
> If this is the way GIT works, so be it. I just don't like it. It could not
> be more confusing.
> 
> A couple of thoughts in case they help you.
> 
> 1. Git has "author date" and "commit date" for each commit.
> * author date is the original date of the first commit, never changes.
> * commit date is the last time the commit was modified (e.g. amended,
> committed to a branch).
> Each date is useful, depending on the situation investigating.

Yes. It is lacking information about when a commit got added to a
specific branch. Create a branch of master, work on it for a few months,
then merge it back to master. Information about when the months old
commits have been merged to master is missing. Maybe I am just using the
tool incorrectly. Currently I am creating a branch from master to work
on using 'git pull --rebase origin/master' followed by a fast-forward
push to master using 'git push origin branchname:master'. That way the
commits appear in order. If I would do 'git merge' the months old
commits appear at a months old place in time on master with possibly
other commits done in between by others mixed in. This is what 'man
git-merge' tells me is the way things are supposed to be. I am not even
sure I got that correctly.

> 
> To help with the date displays, which git client(s) do you use?

git and gitk.

> Please ask for more git help if you like.  Many people on the list know it
> well, and happy to help your productivity.

Thanks for the clarifications.

Regards,
-- 
Christian


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

Distribution file permission issue with current master (attachment).

[Christian Schulte]

$ rm -rf apache-maven-3.5.0-SNAPSHOT
rm: apache-maven-3.5.0-SNAPSHOT/lib/jansi-native: Permission denied
rm: apache-maven-3.5.0-SNAPSHOT/lib: Directory not empty
rm: apache-maven-3.5.0-SNAPSHOT: Directory not empty
$ find apache-maven-3.5.0-SNAPSHOT
apache-maven-3.5.0-SNAPSHOT
apache-maven-3.5.0-SNAPSHOT/lib
apache-maven-3.5.0-SNAPSHOT/lib/jansi-native
find: apache-maven-3.5.0-SNAPSHOT/lib/jansi-native: Permission denied
$ ls -lah apache-maven-3.5.0-SNAPSHOT
total 16
drwxr-xr-x   3 schulte  schulte   512B Mar 14 22:26 .
drwxr-xr-x  29 schulte  schulte   1.0K Mar 14 22:28 ..
drwxr-xr-x   3 schulte  schulte   3.0K Mar 14 22:26 lib
$ ls -lah apache-maven-3.5.0-SNAPSHOT/lib
total 16
drwxr-xr-x  3 schulte  schulte   3.0K Mar 14 22:26 .
drwxr-xr-x  3 schulte  schulte   512B Mar 14 22:26 ..
d-  7 schulte  schulte   512B Mar 14 22:22 jansi-native
$ ls -lah apache-maven-3.5.0-SNAPSHOT/lib/jansi-native
ls: jansi-native: Permission denied
$ ^D


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

Distribution file permission issue with current master.

[Christian Schulte]

Hi,

see the attachment. After unzipping the binary distribution, I cannot
delete it anymore without updating file permissions.

Regards,
-- 
Christian


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

Re: Timeline for 3.5.0-alpha-2 / MNG-6057

[Christian Schulte]

Am 03/14/17 um 21:24 schrieb Stephen Connolly:
> Not so easy. Was attempted before and hit issues with gpg signing.

Can you remember what issues that were? It will sign the temporary pom
java.io.File the same way the install plugin will install that and the
deploy plugin will deploy that. Completely transparent to the plugins.
Only issue I see could be with release:prepare. It would get the
temporary file as it's input and then maybe would update the wrong files
on disk. Either the causing issue is that the in-memory model with the
version expressions interpolated does not exist as a java.io.File
anywhere so that plugins processing the model based on java.io.File
could get confused or the causing issue is the plugins not processing
the in-memory effective model but the raw java.io.File.

> 
> Not in scope for 3.5.0

Ok.

Regards,
-- 
Christian


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

Re: Maven Resolver 1.1

[Christian Schulte]

Am 03/14/17 um 21:24 schrieb Christian Schulte:
> Hi,
> 
> are there any plans to release another Maven Resolver 1.0.x? Can I
> update the POMs to 1.1-SNAPSHOT? See the comments I added in this
> commit:
> <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=da03d6b03192399237750c15f96fa021977dd83b>
> 
> I would need to add some methods to the Resolver API to add support for
> those messages. This would require a bump of the minor version.
> 

FTR, I would stand up to be the release manager of that 1.1 release. The
scope would be log messages only! IIRC, Michael Osipov needs to add
methods to the public API to support repository IDs in log messages. I
need to add methods to the public API to support dependency management
debug log messages. That'd be the scope of the Maven Resolver 1.1.
Nothing else.

Regards,
-- 
Christian



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

Maven Resolver 1.1

[Christian Schulte]

Hi,

are there any plans to release another Maven Resolver 1.0.x? Can I
update the POMs to 1.1-SNAPSHOT? See the comments I added in this
commit:


I would need to add some methods to the Resolver API to add support for
those messages. This would require a bump of the minor version.

Regards,
-- 
Christian

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

Re: Timeline for 3.5.0-alpha-2 / MNG-6057

[Christian Schulte]

Am 12.03.2017 um 15:36 schrieb Karl Heinz Marbaise:
> Hi,
> 
> So after I finalized the implementation which seemed to be ok for 
> now...the IT's are currently not working based on particular reason 
> (explanations later).
> 
> I would like to know the opinion of the Maven DEV's about this:
> 
> The following scenario:
> 
> This feature has been introduced in Maven 3.2.1 but with some issues 
> (ordering in reactor etc.).
> 
> By using this branch MNG-6057 (MNG-6090, MNG-5895) you can use things 
> like ${revision}, ${sha1} and/or ${changelist} in your version tag of 
> your pom.
> This means you can define the revision by simply using it for the whole 
> multi module build (also for a single project) and you can defined a 
> revision of your artifacts by simply using a property in your pom file 
> (only a single one). Take a look at an example[1].
> 
> You can build everything. It is also possible to overwrite the revision 
> via command line like this: mvn clean package -Drevision=2.4.5 or using 
> .mvn/maven.config file..for this instead of using the pom file property.
> 
> The only thing which is cirtical from my point of view if you will do an 
> mvn install or mvn deploy...

Looking at those changes, I think the solution to this is very
straightforward. We could easily serialize the raw model with just the
interpolated versions to a temporary file and continue with that. Would
this work? Just a few lines of code FIX-3.5.0 without the need of the
flatten-maven-plugin for anything. We just serialize a temporary
deleteOnExit pom and make the core provide that file instead of the
original one.

Regards,
-- 
Christian


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

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

[Christian Schulte]

Am 03/11/17 um 22:56 schrieb Stephen Connolly:
> 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

The Jenkins support has improved greatly. For me it's very cool to have
the ITs run on Java 7+8 - Linux+Windows. Too few operating systems.
Solaris is a must have. OS X would be nice to have. FreeBSD or OpenBSD
also nice to have.

> * What is not working well

Turns out I just will never become a GIT fan. What works best for me has
been Subversion on the server and GIT locally using git-svn. Very clean
history on the Subversion server side because you can clean up commits
locally (squash, reword, etc.) before committing to the Subversion
repository. I find it quite hard to follow the commit history in GIT.
The date of the commit is not the date it got committed to master, but
the date it got committed to some branch, no longer existing after the
commit. If this is the way GIT works, so be it. I just don't like it. It
could not be more confusing.

Regards,
-- 
Christian


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

Contributing Javadoc (was Re: [DISCUSS] Retrospective on Maven 3.5.0-alpha-1)

[Christian Schulte]

Am 03/13/17 um 23:22 schrieb Laird Nelson:
> On Mon, Mar 13, 2017 at 2:26 PM Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
> 
> Gentle reminder. If you can see this thread, you are entitled to
> contribute. This thread is about discovering where the Maven project can
> improve how we work in order to grow our community.
> 
> I'll bite.  (I can see the dev list, but I don't think I have commit
> privileges.)
> 
> One of the ways that I would like to contribute is to improve Javadoc
> throughout the core of Maven.  Even documenting simple things—like what the
> difference between an artifact and a dependency is—could go a long ways
> towards improving Maven's standing in the world.  What would be the best
> way to do this?

Just create corresponding issues in JIRA and either attach patch files
there or add links to Github pull requests there. Can be any public git
repository. The apache repositories are synced to Github just for
convenience.

Regards,
-- 
Christian


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

Re: Timeline for 3.5.0-alpha-2 / MNG-6057

[Christian Schulte]

Am 03/13/17 um 08:33 schrieb Hervé BOUTEMY:
>> The flatten-maven-plugin solution appears to me like a workaround for
>> some missing support in Maven core. Also a good reason to split build
>> pom from deployed pom. Maybe all of this better be postponed to model
>> version 5.0.0?
> splitting build pom from deployed (or consumer) pom IMHO is:
> 1. not a workaround
> 2. exactly what we need *before* working on model 5.0.0

I did not object to anything. I am just wondering how compatible that is
to that "the model version 4.0.0 ship has sailed" statement. If a pom
gets deployed to central using a version expression, no one can consume
such a project. The warnings about "version must be a constant" were
there for a reason. Allowing just a few expressions is not different to
allowing all kinds of expressions. We could allow expressions in
versions like in Maven 2 again and make that a supported feature, if
Maven core can deal with it correctly (by never allowing anything like
that to appear in any repository).

Regards,
-- 
Christian


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

Re: Timeline for 3.5.0-alpha-2 / MNG-6057

[Christian Schulte]

Am 03/12/17 um 15:36 schrieb Karl Heinz Marbaise:
> Hi,
> 
> So after I finalized the implementation which seemed to be ok for 
> now...the IT's are currently not working based on particular reason 
> (explanations later).
> 
> I would like to know the opinion of the Maven DEV's about this:
> 
> The following scenario:
> 
> This feature has been introduced in Maven 3.2.1 but with some issues 
> (ordering in reactor etc.).
> 
> By using this branch MNG-6057 (MNG-6090, MNG-5895) you can use things 
> like ${revision}, ${sha1} and/or ${changelist} in your version tag of 
> your pom.
> This means you can define the revision by simply using it for the whole 
> multi module build (also for a single project) and you can defined a 
> revision of your artifacts by simply using a property in your pom file 
> (only a single one). Take a look at an example[1].
> 
> You can build everything. It is also possible to overwrite the revision 
> via command line like this: mvn clean package -Drevision=2.4.5 or using 
> .mvn/maven.config file..for this instead of using the pom file property.
> 
> The only thing which is cirtical from my point of view if you will do an 
> mvn install or mvn deploy...
> 
> The problem is simply that at the moment the pom's which will be 
> installed into local cache or in a remote repository having the 
> ${revision} etc. in their version tag and the placeholders 
> revision,sha1,changelist are not being replaced with the current literal 
> version.

This is a very long standing issue. Quite a lot of people gave up on
some "feature" because it lead to non-deployable projects.

> 
> This can be solved by using the flatten-maven-plugin (I think this 
> should be integrated into Maven itself in the furture maybe in Maven 
> 3.6.0?? but this is a different story.).
> 
> If you take this change you can define the version of your build 
> artifacts either by command line or with a single property which several 
> people asked for...which would make it very convenient to build 
> different branches by using different versions ...etc.
> 
> This leaves some questions from my side:
> 
> 1. How can I use the flatten-maven-plugin inside the IT's ? (It looks 
> like I oversight something here).
> 
> 2. WDYT about? Should I postpone that and improve the solution?

I would go for improving this until everything has landed in Maven core
and Maven gets the job done automatically without anyone having to setup
some special plugins changing the in memory effective model temporarily.
The flatten-maven-plugin solution appears to me like a workaround for
some missing support in Maven core. Also a good reason to split build
pom from deployed pom. Maybe all of this better be postponed to model
version 5.0.0?

> 3. Should I integrate the current state into the current 3.5.0-alpha-2 ?

Commit it now, and you will never have a chance to improve the solution
later. Once released, it's nearly impossible to even fix a simple bug
;-) If it got released with Maven 3.3.9, things already are messed up
and I wonder how this could get released when even simple bugfixes were
reverted lately.

Regards,
-- 
Christian


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

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

[Christian Schulte]

Am 03/10/17 um 23:33 schrieb Christian Schulte:
> Am 03/10/17 um 20:16 schrieb Robert Scholte:
>> On Fri, 10 Mar 2017 16:47:45 +0100, Christian Schulte   
>> wrote:
>>
>>> Am 03/10/17 um 10:42 schrieb Robert Scholte:
>>>> Having a closer look at this commit, I actually don't like the idea that
>>>> ModelResolver now supports versionRanges.
>>>> IMO the version should always be specific *before* resolving the model.
>>>> IIUC correctly this is required to supported version-ranges for managed
>>>> dependencies, and that is also something I wonder if we want that.
>>>>
>>>> Please let us reconsider this commit.
>>>
>>> You do notice the parent resolution is part of that interface since
>>> Maven 3.2.2? I just added the same logic for dependencies to support
>>> version ranges in dependency management import declarations. Version
>>> ranges are supported everywhere but dependency management _import_
>>> declarations. We already agreed that this is a bug fix and this would
>>> have been part of Maven 3.4.0, if we would not have dropped it due to
>>> the resolver changes. MNG-4463 has been reported in JIRA 23/Nov/09
>>> 09:39! It's tiresome to discuss things committed in 2014 now. See the
>>> 'ModelResolver' interface from Maven 3.2.2. It already contains that
>>> logic for 'Parent' model objects.
>>>
>>> <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=045bd1503b70738ffd0fa08e336574107aded801>
>>>
>>> The new method in 3.5.0 for 'Dependency' model objects will only be used
>>> to support version ranges in dependency management _import_ declarations
>>> coming in 3.5.1.
>>>
>>> <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=d0911ac57dccb758435cdfd3495121ec9f0ae1b4>
>>>
>>> Regards,
>>
>> MNG-4463 is marked for 3.5.1, not for 3.5.0, so this would *not* the the  
>> moment to commit it.
> 
> Did you read the description of MNG-6182? There is a good reason not to
> enhance a public API in a patch release. Just take a look at the history
> of the ModelResolver interface. It changed in incompatible ways between
> releases. I'd like this to be stable again in the next feature release.
> That is 3.5.0 - not 3.5.1. That interface is just an adapter (the
> maven-model-builder module does not depend on the resolver). I would not
> want to add yet another adapter interface instead of enhancing the
> existing one. It's *the* moment to commit this. That's why I added a
> method not used by anything at the moment. Maven 3.5.0 still is a
> drop-in replacement that way. No one needs to update an implementation.
> This will change as soon as something starts to call the new method in
> 3.5.1, of course. Just as we add dependencies to Maven 3.0.0 in the
> plugins ourselves instead of - say - Maven 3.3.9, I'd like others to be
> able to depend on Maven 3.5.0 to compile against that API instead of
> 3.5.x. I am repeating the description of MNG-6182 already. I know the
> Netbeans IDE is implementing the ModelResolver interface. No one would
> expect that interface to change between 3.5.0 and 3.5.1 in a way that
> you get a compile time error when compiling against 3.5.1 instead of 3.5.0.
> 
>>
>> Let's first push 3.5.0 and give everybody the change to dive into the  
>> complexity of dependency resolution once we start with 3.5.1
> 
> What complexity are you talking about? Someone using version ranges in a
> dependency management import declaration will not do this without
> intention. Maven currently fails the build with an error message. Just
> like mentioned in the description of MNG-4463. No one expects a public
> API to be enhanced between 3.5.0 and 3.5.1. Are we really discussing the
> addition of a new method *not used anywhere*? When in doubt, we should
> start a vote on this.
> 
> Regards,
> 

And for the very same reason I am currently reviewing this commit

<https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=1d6af709bca616f82db79009d2ebfc8da7724569>

so that the changes to the public APIs can be part of 3.5.0 in the same
way. Add deprecations to old methods, add new methods but do not change
anything else by just not calling the new methods and keep things
unchanged. I am very sure we want to ship a stable 3.5.0 API.


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

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

[Christian Schulte]

Am 03/10/17 um 20:16 schrieb Robert Scholte:
> On Fri, 10 Mar 2017 16:47:45 +0100, Christian Schulte   
> wrote:
> 
>> Am 03/10/17 um 10:42 schrieb Robert Scholte:
>>> Having a closer look at this commit, I actually don't like the idea that
>>> ModelResolver now supports versionRanges.
>>> IMO the version should always be specific *before* resolving the model.
>>> IIUC correctly this is required to supported version-ranges for managed
>>> dependencies, and that is also something I wonder if we want that.
>>>
>>> Please let us reconsider this commit.
>>
>> You do notice the parent resolution is part of that interface since
>> Maven 3.2.2? I just added the same logic for dependencies to support
>> version ranges in dependency management import declarations. Version
>> ranges are supported everywhere but dependency management _import_
>> declarations. We already agreed that this is a bug fix and this would
>> have been part of Maven 3.4.0, if we would not have dropped it due to
>> the resolver changes. MNG-4463 has been reported in JIRA 23/Nov/09
>> 09:39! It's tiresome to discuss things committed in 2014 now. See the
>> 'ModelResolver' interface from Maven 3.2.2. It already contains that
>> logic for 'Parent' model objects.
>>
>> <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=045bd1503b70738ffd0fa08e336574107aded801>
>>
>> The new method in 3.5.0 for 'Dependency' model objects will only be used
>> to support version ranges in dependency management _import_ declarations
>> coming in 3.5.1.
>>
>> <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=d0911ac57dccb758435cdfd3495121ec9f0ae1b4>
>>
>> Regards,
> 
> MNG-4463 is marked for 3.5.1, not for 3.5.0, so this would *not* the the  
> moment to commit it.

Did you read the description of MNG-6182? There is a good reason not to
enhance a public API in a patch release. Just take a look at the history
of the ModelResolver interface. It changed in incompatible ways between
releases. I'd like this to be stable again in the next feature release.
That is 3.5.0 - not 3.5.1. That interface is just an adapter (the
maven-model-builder module does not depend on the resolver). I would not
want to add yet another adapter interface instead of enhancing the
existing one. It's *the* moment to commit this. That's why I added a
method not used by anything at the moment. Maven 3.5.0 still is a
drop-in replacement that way. No one needs to update an implementation.
This will change as soon as something starts to call the new method in
3.5.1, of course. Just as we add dependencies to Maven 3.0.0 in the
plugins ourselves instead of - say - Maven 3.3.9, I'd like others to be
able to depend on Maven 3.5.0 to compile against that API instead of
3.5.x. I am repeating the description of MNG-6182 already. I know the
Netbeans IDE is implementing the ModelResolver interface. No one would
expect that interface to change between 3.5.0 and 3.5.1 in a way that
you get a compile time error when compiling against 3.5.1 instead of 3.5.0.

> 
> Let's first push 3.5.0 and give everybody the change to dive into the  
> complexity of dependency resolution once we start with 3.5.1

What complexity are you talking about? Someone using version ranges in a
dependency management import declaration will not do this without
intention. Maven currently fails the build with an error message. Just
like mentioned in the description of MNG-4463. No one expects a public
API to be enhanced between 3.5.0 and 3.5.1. Are we really discussing the
addition of a new method *not used anywhere*? When in doubt, we should
start a vote on this.

Regards,
-- 
Christian


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

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

[Christian Schulte]

Am 03/10/17 um 10:42 schrieb Robert Scholte:
> Having a closer look at this commit, I actually don't like the idea that  
> ModelResolver now supports versionRanges.
> IMO the version should always be specific *before* resolving the model.
> IIUC correctly this is required to supported version-ranges for managed  
> dependencies, and that is also something I wonder if we want that.
> 
> Please let us reconsider this commit.

You do notice the parent resolution is part of that interface since
Maven 3.2.2? I just added the same logic for dependencies to support
version ranges in dependency management import declarations. Version
ranges are supported everywhere but dependency management _import_
declarations. We already agreed that this is a bug fix and this would
have been part of Maven 3.4.0, if we would not have dropped it due to
the resolver changes. MNG-4463 has been reported in JIRA 23/Nov/09
09:39! It's tiresome to discuss things committed in 2014 now. See the
'ModelResolver' interface from Maven 3.2.2. It already contains that
logic for 'Parent' model objects.



The new method in 3.5.0 for 'Dependency' model objects will only be used
to support version ranges in dependency management _import_ declarations
coming in 3.5.1.



Regards,
-- 
Christian


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

Re: Timeline for 3.5.0-alpha-2

[Christian Schulte]

Am 03/10/17 um 00:29 schrieb Stephen Connolly:
> How are we doing?
> 
> Are we ready to freeze?

Nothing left to do on my side. There are a couple of issues in JIRA
flagged "in progress" for -alpha-2. Not sure about them.


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

[IT MNG-6173] (was Re: Timeline for 3.5.0-alpha-2)

[Christian Schulte]

Am 03/04/17 um 14:56 schrieb Stephen Connolly:
> We are still in alpha, so bugs with severity S1-S3 are eligible (and S4
> with a risk assessment)
> Severity is something like this (but as a project we probably need to
> define the categories for Maven core)
> 
> S1: blows up for everyone, no workaround
> S2: blows up under certain circumstances, no workaround. Also feature does
> not work, no workaround.
> S3: blows up but there is a workaround. Most other bugs
> S4: cosmetic issues

Seems to be S2 for at least the flatten-maven-plugin. The reporter
updated the description in JIRA mentioning this. Branch MNG-6173 created
in the core and IT repository. I only updated the range in the IT to
read [3.5.0-alpha-1 instead of just [3.5.0.

Regards,
-- 
Christian


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

Re: Timeline for 3.5.0-alpha-2

[Christian Schulte]

Am 03/04/17 um 18:54 schrieb Hervé BOUTEMY:
> I have one question, which is recurring for every issue: what is the impact?
> 
> I understand the logic: it should fix a bug (that is told introduced in Maven 
> 3.3.1), and the bug is explained by the logic behind the javadoc.
> But no pointer to any code using this method, and that shows that Maven 3.3.1 
> does not work any more, when previous version were ok.
> Then what is explained here as a bugfix could cause issues for others.
> 
> I'm -1 unless I have some details on the impact

Please see the linked issues. The reporter did a great job finding out
about when the issue got introduced. His findings are consistent with



and his analysis also is consistent with



What impact the changes have, I cannot tell. That's why we should take
this to JIRA.


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

Re: Timeline for 3.5.0-alpha-2

[Christian Schulte]

Am 03/04/17 um 18:54 schrieb Hervé BOUTEMY:
> I have one question, which is recurring for every issue: what is the impact?
> 
> I understand the logic: it should fix a bug (that is told introduced in Maven 
> 3.3.1), and the bug is explained by the logic behind the javadoc.
> But no pointer to any code using this method, and that shows that Maven 3.3.1 
> does not work any more, when previous version were ok.
> Then what is explained here as a bugfix could cause issues for others.
> 
> I'm -1 unless I have some details on the impact
> 
> Regards,
> 
> Hervé

I added this to the JIRA issue. I do not know if the reporter is
following dev@. This better be discussed in JIRA then, so that the
reporter can easily take part in the discussion.



Regards,
-- 
Christian


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

Re: Timeline for 3.5.0-alpha-2

[Christian Schulte]

Am 03/02/17 um 22:55 schrieb Stephen Connolly:
> I'd like to declare feature freeze for alpha-2 on March 9th.
> 
> If a feature does not land in alpha-2 it will not be in beta-1 (i.e. Only bug 
> fixes or rip out features that are causing S1/S2 issues will be in the diff 
> from alpha-2 to beta-1)
> 
> I am aiming beta-2 approx 2 weeks after alpha-2 and the GA approx 2 weeks 
> after that.

Should we include



FIX-3.5.0? It has just been reported. It also has an IT pull request. If
no one objects, I'll create a branch and later merge it to master.

Regards,
-- 
Christian


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

Re: [DISCUSS] 3.5.0 alpha/beta's on Central

[Christian Schulte]

Am 02/26/17 um 13:03 schrieb Stephen Connolly:
> Even if we had a -1 as long as I have the binding votes *as release
> manager* it would be my call whether to release or not.
> 
> Now *personally* I much rather release with consensus, but any committer
> can step up to be release manager for any of our components, so I would
> prefer if we can agree our current position (which we can agree to change
> in the future if needed) and just run with that.
> 
> For me:
> 
> * alpha is also about saying "we are not closed to adding something else
> before beta... but we will think hard on any proposed additions"
> 
> * beta is about saying "only important bug fixes... or really low risk bug
> fixes after careful evaluation"
> 
> * RC is "last chance to find showstoppers only"... if no showstopper then
> we drop and cut the release for real
> 

We should document that somewhere. I am used to some different meaning.

alpha:
Development not finished yet. More commits to come. Everything can
happen. It's just a label external entities can refer to in a stable way
(like in JIRA - instead of having to refer to e.g. the snapshot from
yesterday 3 hours after commit xyz). The classifier could as well be an
SCM id (like -alpha-svnrevision or -alpha-uglygithash).

beta:
Development is finished. Seeking for testing. Developers will only fix
bugs, if there are any. Just the final steps needed to get things ready
for release.

RC:
Same meaning Stephen described. The RC already is the final release.
When the SCM allows it, you normally rename the RC tag removing the RC
and just rebuild that for the final release. This is what you will be
paying for. Point of no return. Nothing can be removed afterwards - just
deprecations or additions to come in the next development cycle. Seeking
for a major review/final testing.

Regards,
-- 
Christian


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

Re: [DISCUSS] 3.5.0 alpha/beta's on Central

[Christian Schulte]

Am 02/25/17 um 22:55 schrieb Karl Heinz Marbaise:
> Hi,
> 
> based on the started discussion about either to bring 3.5.0-alpha-1 to 
> Central or not I would suggest to discuss in a separate thread and 
> prevent using the VOTE's threads for that (as Stephen already mentioned).
> 
> Using Central:
>   o Everybody can use it and make tests on it.
> 
> Using an other repository:
>   o Which one?
> 
> Using only dist area? Or something different?
> 
> WDY?
> 
> Based on earlier releases which had been in Central with alpha's:
> 
> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.maven%22%20AND%20a%3A%22apache-maven%22
> 

It's just a matter of naming, IMHO.

3.5.0-RC1
  Should not be deployed to central - just made available for testing.

3.5.0-alpha-1
  A complete release which happens to be classified "alpha".

Back when Maven 2 got released, almost all plugins were classified alpha
or beta.

If we want to ensure no one is embedding an alpha release and then not
upgrade to the non-alpha release, we maybe should log a warning upon
execution (This is an alpha release bla bla bla) and remove that warning
before releasing 3.5.0.

Regards,
-- 
Christian


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

Re: [VOTE] Release Apache Maven 3.5.0-alpha-1

[Christian Schulte]

Am 02/25/17 um 17:25 schrieb Tibor Digana:
>>> There are two commits for MNG-6078 part of -alpha-1.
> 
> This was caused by system property duplicates in surefire ITs.
> It is already fixed in a branch SUREFIRE_SYSPROP_DUPLICATES.

If something works with 3.3.9 but not 3.5.0, we need to fix it in Maven.
I think this is what Stephen did. No need to "fix" surefire ITs, if they
were working with 3.3.9 before. 3.5.0 would not be a drop in replacement
anymore that way.

Regards,
-- 
Christian


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

Re: [VOTE] Release Apache Maven 3.5.0-alpha-1

[Christian Schulte]

Am 02/25/17 um 14:40 schrieb Tibor Digana:
> @Stephen
> @Michael-O
> What changed in Maven after Michael used his snapshot version of
> Maven-3.5.0-SNAPSHOT?
> Michael said that surefire failed with ForkModeIT and he tested Surefire's
> commits from HEAD to 502d18442113b4c6c72630dca5842e1eb287b8b0.
> I followed more deeply in the commits of Surefire project but my snapshot
> version of Maven-3.5.0-SNAPSHOT still failed till January 16th, 2015.
> Then I decided to use this Maven release of Alpha-1 and ForkModeIT passed.
> 

There are two commits for MNG-6078 part of -alpha-1.

Regards,
-- 
Christian


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

Re: [VOTE] Release Apache Maven 3.5.0-alpha-1

[Christian Schulte]

Am 02/24/17 um 21:03 schrieb Stephen Connolly:
> To reflect the practice we should use for these going forward

+1

I should have included -alpha-0 in those ranges right from the start.

Regards,
-- 
Christian


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

Re: maven-integration-testing git commit: 3.5.0-alpha-1 < 3.5.0

[Christian Schulte]

Am 02/24/17 um 20:48 schrieb steph...@apache.org:
> Repository: maven-integration-testing
> Updated Branches:
>   refs/heads/master 3883e005e -> c4cd8cf3b
> 
> 
> 3.5.0-alpha-1 < 3.5.0

Thanks.


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

Re: [VOTE] Release Apache Maven 3.5.0-alpha-1

[Christian Schulte]

Am 02/24/17 um 18:34 schrieb Robert Scholte:
> When running the maven-its, I get this failing test. I think the cause is  
> an invalid version range, right?

Are you really running the IT master branch? There have been no commits
to maven master without a successful IT run before. I wonder how this
could have slipped through.

Regards,
-- 
Christian


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

Escaping rules for filtering.

[Christian Schulte]

Hi,

during testing various projects to build from inside a directory "Spaces
& Special Char" I stumbled upon an issue also reported by users over the
years. I'd like to know the status on this. Do we plan to implement any
kind of escaping rules for filtering? Based on what? File extension?
MIME type? For example: When using ${project.build.directory} in an XML
file, any XML special characters need to be escaped to not create an
illegal XML file. Same for properties files as well. They do not support
UTF-8 and should be encoded appropriately. Has this already been
discussed somewhere?

Regards,
-- 
Christian

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

Re: [VOTE] Release Apache Maven 3.5.0-alpha-1

[Christian Schulte]

Can we have this patch included? I wanted to commit this to master
yesterday when the build job succeeded. This is just pending the Jenkins
update to get the job succeed. I would just merge it to master now.





So that we do not need to re-open MNG-5889 or even create a new issue.
Otherwise

+1

No objections to get a release out.

Regards,
-- 
Christian


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

Re: Recent issues found in Surefire master/Maven Clean Plugin 3.0.0 with Maven master

[Christian Schulte]

Am 02/23/17 um 19:20 schrieb Michael Osipov:
> So guys,
> 
> I took a different approach to provide Tibor more information about the 
> failures. First of all, I added another platform for the test which is 
> exotic: HP-UX 11.31. The VM comes directly from HPE which is a 
> repackaged Oracle JVM.

Good to have some System V in the mix.


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

Re: maven-3.x-jenkinsfile/master - build #54 - null

[Christian Schulte]

Am 02/23/17 um 09:07 schrieb Stephen Connolly:
> Yes. Infra updated some Jenkins plugins and now the Windows path is too
> long.
> 
> I need them to upgrade to branch-api 2.0.7 (released yesterday) and set a
> system property to resolve the issue

Good to know. I updated various build jobs of the "Maven Master Release
Status" view meanwhile to perform the checkout into a directory called
"Spaces & Special Char". Currently looking into the archetype repository
why this starts to fail. Others may fail due to this as well. We'll see.


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

Re: maven-3.x-jenkinsfile/master - build #54 - null

[Christian Schulte]

Am 02/23/17 um 06:18 schrieb Apache Jenkins Server:
> See https://builds.apache.org/job/maven-3.x-jenkinsfile/job/master/54/
> 

Turns out the "null" in the subject does not indicate a successful
build. Maven master currently does not build successfully.

Regards,
-- 
Christian


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

Re: Launcher script issues in 3.5.0.

[Christian Schulte]

Am 02/23/17 um 04:21 schrieb Igor Fedorenko:
> On all platforms .mvn/ search is expected to start with directory
> specified by -f parameter and keep doing "cd .." until it files .mvn/
> subdirectory or hits the filesystem root.

What if I put a .mvn directory at the file system root? Will that become
the default for everything when there is no other .mvn found before?

> The idea is to use .mvn/ subdirectory as a marker of multimodule project
> basedir. The build can be started from any submodule, but multimodule
> project basedir will be always the same.

That's how I understood it as well. If it does not stop anywhere but the
drive root, this will lead to invalid project base directories as soon
as someone adds a .mvn directory somewhere inappropriate. I am not using
that feature myself, so just wanted to be sure. The patch does not
change the logic in any way. Just makes it work for directory names like
"Spaces & Special Char". I'll merge it, if no one objects.

Regards,
-- 
Christian


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

Re: Launcher script issues in 3.5.0.

[Christian Schulte]

Both issues seem to be related to MNG-5889. MNG-5889 branch created. If
no one objects, I'll merge it to master when the build job completed
successfully on Jenkins. Otherwise consider the MNG-5889 branch yours.
Note: I just noticed that the Windows launcher does not stop searching
for the .mvn directory at the directory given by the -f option. Search
does not stop until the drive root has been reached (like C:). I am not
sure this is intended.

Regards,
-- 
Christian


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

Re: Build of maven-dependency-analyzer fails on Windows.

[Christian Schulte]

Am 02/20/17 um 18:28 schrieb Robert Scholte:
> On Mon, 20 Feb 2017 02:17:12 +0100, Christian Schulte   
> wrote:
> 
>> Am 02/20/17 um 01:53 schrieb Christian Schulte:
>>> Hi,
>>>
>>> I cannot build 'maven-dependency-analyzer' trunk on Windows. Is there
>>> some dependency I could upgrade to get this going? This is what I am
>>> doing locally:
>>>
>>> svn checkout /repos/asf/maven/shared/trunk/maven-dependency-analyzer
>>> cd maven-dependency-analyzer
>>> mvn verify -Papache-snapshots,run-its
>>>
>>> Jenkins build job is here:
>>>
>>> <https://builds.apache.org/view/Maven%20Master%20Release%20Status/job/maven-master-release-status-test-shared-windows/>
>>>
>>> Regards,
>>>
>>
>> Seems we cannot rename the mvn.bat file to mvn.cmd. Can someone clarify
>> this, please. Is it "just" our invoker relying on this?
> 
> Effective pom says maven-invoker-plugin-2.0.0 is used, which is aware of  
> both mvn.bat and mvn.cmd
> 
> Robert

Can you build the shared trunk on Windows using 3.5.0-SNAPSHOT? I am
running into issues related to something not finding the mvn.bat file. I
manually copied the mvn.cmd to mvn.bat and things started to work.

Regards,
-- 
Christian


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

Re: Launcher script issues in 3.5.0.

[Christian Schulte]

Please see the attachment. Can someone please review this and apply the
patches. Both launchers - Windows and Unix - should support directory
names like "Spaces & Special Char" with this patch applied. I do not
know what JIRA issue corresponds to these changes.

Regards,
-- 
Christian

diff --git a/apache-maven/src/bin/mvn b/apache-maven/src/bin/mvn
index 95a407d..cfb39b0 100755
--- a/apache-maven/src/bin/mvn
+++ b/apache-maven/src/bin/mvn
@@ -141,9 +141,9 @@ find_file_argument_basedir() {
   found_file_switch=0
   for arg in "$@"; do
 if [ ${found_file_switch} -eq 1 ]; then
-  if [ -f ${arg} ]; then
-basedir=$(dirname $(readlink -f "${arg}"))
-if [ ! -d ${basedir} ]; then
+  if [ -f "${arg}" ]; then
+basedir=$(dirname "$(readlink -f "${arg}")")
+if [ ! -d "${basedir}" ]; then
   echo "Directory ${basedir} extracted from the -f/--file command-line argument ${arg} does not exist" >&2
   exit 1
 fi
diff --git a/apache-maven/src/bin/mvn.cmd b/apache-maven/src/bin/mvn.cmd
index e527188..c86662b 100644
--- a/apache-maven/src/bin/mvn.cmd
+++ b/apache-maven/src/bin/mvn.cmd
@@ -120,7 +120,7 @@ if not exist "%FILE_ARG%" (
   echo POM file %FILE_ARG% specified the -f/--file command-line argument does not exist >&2
   goto error
 )
-call :get_directory_from_file %FILE_ARG%
+call :get_directory_from_file "%FILE_ARG%"
 if not exist "%POM_DIR%" (
   echo Directory %POM_DIR% extracted from the -f/--file command-line argument %FILE_ARG% does not exist >&2
   goto error


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

Re: Launcher script issues in 3.5.0.

[Christian Schulte]

See the attached patch. This should make the Unix launcher support
directory names like "Spaces & Special Char". At least here:

SH_VERSION='@(#)PD KSH v5.2.14 99/07/13.2'

Can someone review and apply this patch please. Thanks.

Regards,
-- 
Christian

diff --git a/apache-maven/src/bin/mvn b/apache-maven/src/bin/mvn
index 95a407d..cfb39b0 100755
--- a/apache-maven/src/bin/mvn
+++ b/apache-maven/src/bin/mvn
@@ -141,9 +141,9 @@ find_file_argument_basedir() {
   found_file_switch=0
   for arg in "$@"; do
 if [ ${found_file_switch} -eq 1 ]; then
-  if [ -f ${arg} ]; then
-basedir=$(dirname $(readlink -f "${arg}"))
-if [ ! -d ${basedir} ]; then
+  if [ -f "${arg}" ]; then
+basedir=$(dirname "$(readlink -f "${arg}")")
+if [ ! -d "${basedir}" ]; then
   echo "Directory ${basedir} extracted from the -f/--file command-line argument ${arg} does not exist" >&2
   exit 1
 fi


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

Launcher script issues in 3.5.0.

[Christian Schulte]

Hi,

our launchers (both Unix and Windows) still seem to be broken for
directory names like "Spaces & Special Char".

pwd
/home/schulte
$ mvn -version
Apache Maven 3.5.0-SNAPSHOT (e6217a455547e5b3bcac310be18daf2a333cd5d1;
2017-02-21T01:24:24+01:00)
Maven home: /home/schulte/Applications/apache-maven-3.5.0-SNAPSHOT
Java version: 1.7.0_80, vendor: Oracle Corporation
Java home: /usr/local/jdk-1.7.0/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "openbsd", version: "6.0", arch: "amd64", family: "unix"

$ env LANG=C mvn -f "/tmp/Spaces\ \&\ Special\
Char/maven-invoker-plugin/pom.xml" clean

/home/schulte/Applications/apache-maven-3.5.0-SNAPSHOT/bin/mvn[171]: [:
\&\: unexpected operator/operand
POM file /tmp/Spaces\ \&\ Special\ Char/maven-invoker-plugin/pom.xml
specified with the -f/--file command line argument does not exist
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-readable POM /tmp/Spaces\ \&\ Special\
Char/maven-invoker-plugin/pom.xml: /tmp/Spaces\ \&\ Special\
Char/maven-invoker-plugin/pom.xml (No such file or directory) @


$ env LANG=C mvn -f /tmp/Spaces\ \&\ Special\
Char/maven-invoker-plugin/pom.xml clean

/home/schulte/Applications/apache-maven-3.5.0-SNAPSHOT/bin/mvn[171]: [:
&: unexpected operator/operand
POM file /tmp/Spaces & Special Char/maven-invoker-plugin/pom.xml
specified with the -f/--file command line argument does not exist
[INFO] Scanning for projects...
[INFO]
[INFO]

[INFO] Building Apache Maven Invoker Plugin 3.0.0-SNAPSHOT
[INFO]

[INFO]
[INFO] --- maven-clean-plugin:3.0.0:clean (default-clean) @
maven-invoker-plugin ---

Something similar is happening on Windows. On Unix, the mvn launcher
fails as soon as it is used in a directory like "Spaces & Special Char".
On Windows this works. So on Windows only the -f option is affected. Can
someone take a look, please?

Just checkout some project into a directory with a name like "Spaces &
Special Char" and try to execute Maven from inside that directory and
from outside that directory using the -f option pointing to the pom
inside that directory. It won't work on Unix and Windows. I somehow lost
track on all those launcher related issues for 3.5.0 but this should
work with 3.5.0.

Regards,
-- 
Christian

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

Re: Fwd: How to name modules, automatic and otherwise

[Christian Schulte]

Am 02/19/17 um 04:38 schrieb Hervé BOUTEMY:
> then I'm not sure checking rules on what is inside an artifact while 
> publishing in Central is the right thing to do: we don't do it currently 
> (checking that package names are consistent with groupId), then I feel we 
> should not do it either for module info

If we would have checked that, there would not be this "redundant class
files on class path coming from different coordinates" issue.

> 
> it's just a basic convention for normal cases, that will be applied more than 
> 90% of time: and there will be less than 10% of time where discrepency will 
> happen, due to some special cases in code life
> As usual

Issue with the module names is the same as with the package or
classnames. They can be deployed to different coordinates and then
produce conflicts later when consumed. If we can avoid this with module
names, we should.

Regards,
-- 
Christian


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

Re: Recent issues found in Surefire master/Maven Clean Plugin 3.0.0 with Maven master

[Christian Schulte]

Am 02/20/17 um 01:10 schrieb Tibor Digana:
> Can somebody explore what is different between these two surefire builds
> (failed and successful) and why?:
> https://builds.apache.org/view/Maven%20Master%20Release%20Status/

This one is run with current Maven master using JDK 7.

> https://builds.apache.org/job/maven-surefire/

This one is run with Maven 3.2.1 using JDK 8.

You should be able to log into Jenkins using your apache id. If this
does not work for you, ping someone to setup the correct permissions.

Regards,
-- 
Christian


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

Re: Recent issues found in Surefire master/Maven Clean Plugin 3.0.0 with Maven master

[Christian Schulte]

Am 02/20/17 um 01:10 schrieb Tibor Digana:
> I meant this build which is in good conditions
> https://builds.apache.org/view/Maven%20Master%20Release%20Status/job/maven-master-release-status-test-surefire-linux/30/console
> 
> Can somebody explore what is different between these two surefire builds
> (failed and successful) and why?:
> https://builds.apache.org/view/Maven%20Master%20Release%20Status/
> https://builds.apache.org/job/maven-surefire/

Please see the attached patch. System.out and System.err do buffering
internally in Java. System.exit seems to not flush/close those streams
internally. I really think we just need to close System.in/System.err
manually everywhere before exiting to get the buffers flushed correctly.

Regards,
-- 
Christian

diff --git a/surefire-booter/src/main/java/org/apache/maven/surefire/booter/ForkedBooter.java b/surefire-booter/src/main/java/org/apache/maven/surefire/booter/ForkedBooter.java
index b76df2f..7b9ec7d 100644
--- a/surefire-booter/src/main/java/org/apache/maven/surefire/booter/ForkedBooter.java
+++ b/surefire-booter/src/main/java/org/apache/maven/surefire/booter/ForkedBooter.java
@@ -243,6 +243,8 @@ private static void exit( int returnCode, Shutdown shutdownType, CommandReader r
 reader.stop();
 }
 launchLastDitchDaemonShutdownThread( returnCode );
+System.out.close();
+System.err.close();
 System.exit( returnCode );
 case DEFAULT:
 // refers to shutdown=testset, but not used now, keeping reader open


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

Re: Build of maven-dependency-analyzer fails on Windows.

[Christian Schulte]

Am 02/20/17 um 01:53 schrieb Christian Schulte:
> Hi,
> 
> I cannot build 'maven-dependency-analyzer' trunk on Windows. Is there
> some dependency I could upgrade to get this going? This is what I am
> doing locally:
> 
> svn checkout /repos/asf/maven/shared/trunk/maven-dependency-analyzer
> cd maven-dependency-analyzer
> mvn verify -Papache-snapshots,run-its
> 
> Jenkins build job is here:
> 
> <https://builds.apache.org/view/Maven%20Master%20Release%20Status/job/maven-master-release-status-test-shared-windows/>
> 
> Regards,
> 

Seems we cannot rename the mvn.bat file to mvn.cmd. Can someone clarify
this, please. Is it "just" our invoker relying on this?

Regards,
-- 
Christian


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

Build of maven-dependency-analyzer fails on Windows.

[Christian Schulte]

Hi,

I cannot build 'maven-dependency-analyzer' trunk on Windows. Is there
some dependency I could upgrade to get this going? This is what I am
doing locally:

svn checkout /repos/asf/maven/shared/trunk/maven-dependency-analyzer
cd maven-dependency-analyzer
mvn verify -Papache-snapshots,run-its

Jenkins build job is here:



Regards,
-- 
Christian

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

Re: Recent issues found in Surefire master/Maven Clean Plugin 3.0.0 with Maven master

[Christian Schulte]

Am 02/20/17 um 01:10 schrieb Tibor Digana:
> I meant this build which is in good conditions
> https://builds.apache.org/view/Maven%20Master%20Release%20Status/job/maven-master-release-status-test-surefire-linux/30/console

This points to a console with IT failures. That build never succeeded on
Jenkins. There had been issues with the setup of those jobs. That should
be solved. It does not show the issues we are seeing on the BSDs. That's
what I am referring to with "is only reproducible on *BSD." Here is a
build job showing the issue exists on those others OSes as well.



>From the maven-assembly-plugin:

[INFO] Building:
projects\descriptor-refs\jar-with-dependencies\deps-unpacked-to-root-dir\pom.xml
[INFO] ..FAILED (7.6 s)

You need to log into Jenkins to see the build.log from the workspace.
That build.log contained that "Did not properly say good bye." message
from surefire. I just restarted that job due to this, so that build.log
will have disappeared already. It should run successfully. There are no
plugin ITs failing on windows. Reading the Surefire FAQ on this issue,
it states that this may happen when something runs out of resources etc.
This led to pull request
. Although real
resource leaks, I doubt it's the OS running out of resources producing
that message.

Regards,
-- 
Christian


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

Re: Recent issues found in Surefire master/Maven Clean Plugin 3.0.0 with Maven master

[Christian Schulte]

Am 02/19/17 um 23:58 schrieb Tibor Digana:
> and they are getting really nervous. So we have to make a release and later
> we will finish fix for FreeBSD. I am still facing native problem with
> reliably streaming data over standard output streams with subprocess.
> We with Kristian Roselvold were thinking of introducing extensions for
> Surefire in Version 3.0. It seems we will do it in 2.x but not in this
> version because we are already running one year without release.

No objections to cutting releases or to anything else. There is one
thing to note here. @Michael: Please correct me if I am wrong. This is
not a FreeBSD or OpenBSD only issue. It is happening on Windows and
Linux as well. It's fully reproducible on OpenBSD and - as it seems - on
FreeBSD as well. Those BSDs happen to be using the same JDK port from here:



I doubt this port is to blame, because this issue exists with the
Jenkins build jobs as well (Ubuntu and Windows). It's good to have a
setup around where things like this are reproducible.

Regards,
-- 
Christian


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

Re: Recent issues found in Surefire master/Maven Clean Plugin 3.0.0 with Maven master

[Christian Schulte]

Am 19.02.2017 um 21:10 schrieb Michael Osipov:
> Am 2017-02-19 um 19:54 schrieb Christian Schulte:
>> Am 02/19/17 um 19:52 schrieb Christian Schulte:
>>> Am 02/19/17 um 19:47 schrieb Christian Schulte:
>>>> Am 02/19/17 um 13:06 schrieb Michael Osipov:
>>>>> Socket give you, of course, a lot of control, but they also impose an
>>>>> overhead compares to named pipes (mkfifo, CreateNamePipe).
>>>>>
>>>>> I think our biggest problem is that stdout is subject to buffering
>>>>> issues and in case if System#exit() status Z is the buffer, never
>>>>> written out.
>>>>> Surefire thinks that the crashed.
>>>>
>>>> Not sure I understand the issue at hand completely. If the code calling
>>>> "exit" is in Surefire and the code consuming the stdout/stderr streams
>>>> also is in Surefire, there is a solution to this. Can we just close the
>>>> stdio streams before calling exit? Would that be possible? Just add
>>>> System.out.close(), System.err.close() and System.in.close() before the
>>>> call to System.exit(). This could solve it. Will look up posix
>>>> documentation on this now. We maybe are just running into an issue where
>>>> the BSDs get it right and others are not strictly posix compliant.
>>>> Getting someone to test this on OSX would be interesting (kernel or
>>>> userland issue). This could even be a bug in the VM (not platform
>>>> independent).
>>>>
>>>> Regards,
>>>>
>>>
>>> Quoting from here:
>>>
>>> <http://man.openbsd.org/OpenBSD-current/man3/stdio.3>
>>>
>>> "A file is disassociated from a stream by “closing” it. Output streams
>>> are flushed (any unwritten buffer contents are transferred to the host
>>> environment) before the stream is disassociated from the file."
>>>
>>> BUGs section has a hint about buffering as well.
>>>
>>> Regards,
>>>
>>
>> Well. It's mentioned there explicitly:
>>
>> "If the main function returns to its original caller, or the exit(3)
>> function is called, all open files are closed (hence all output streams
>> are flushed) before program termination. Other methods of program
>> termination may not close files properly and hence buffered output may
>> be lost. In particular, _exit(2) does not flush stdio files. Neither
>> does an exit due to a signal. Buffers are flushed by abort(3), as
>> required by POSIX, although in previous implementations they were not."
> 
> This is the same content as for FreeBSD and I think this is likely the 
> case here. BSDs strictly adhere to the standards, other implementations 
> like GNU/Linux might be sloppier.
> 
> Using stderr could be a solution. At best, we would have setbuf(STDOUT, 
> NULL) from without Java, but this requires native code :-(

The buffering of System.in/out/err is controlled solely by the OS and
the VM does not do anything to make this behave consistently across
OSes? The VM isn't platform independent in that area then. If you can
present a native solution on how to make the VM more platform
independent in that area, time to file a bug against the JDK
<https://bugs.openjdk.java.net>, IMHO. Does not solve our issue now,
though. Means we need to find a solution for Surefire which is neither a
hack nor a workaround which will hit us again in the future. Maybe
System.in/out/err cannot be used reliably for what we are using it for.

Regards,
-- 
Christian


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

Re: Recent issues found in Surefire master/Maven Clean Plugin 3.0.0 with Maven master

[Christian Schulte]

"Initially, the standard error stream is unbuffered; "

Maybe just use System.err instead of System.out to avoid any buffering,
if there is no other solution.


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

Re: Recent issues found in Surefire master/Maven Clean Plugin 3.0.0 with Maven master

[Christian Schulte]

Am 02/19/17 um 19:52 schrieb Christian Schulte:
> Am 02/19/17 um 19:47 schrieb Christian Schulte:
>> Am 02/19/17 um 13:06 schrieb Michael Osipov:
>>> Socket give you, of course, a lot of control, but they also impose an 
>>> overhead compares to named pipes (mkfifo, CreateNamePipe).
>>>
>>> I think our biggest problem is that stdout is subject to buffering 
>>> issues and in case if System#exit() status Z is the buffer, never 
>>> written out.
>>> Surefire thinks that the crashed.
>>
>> Not sure I understand the issue at hand completely. If the code calling
>> "exit" is in Surefire and the code consuming the stdout/stderr streams
>> also is in Surefire, there is a solution to this. Can we just close the
>> stdio streams before calling exit? Would that be possible? Just add
>> System.out.close(), System.err.close() and System.in.close() before the
>> call to System.exit(). This could solve it. Will look up posix
>> documentation on this now. We maybe are just running into an issue where
>> the BSDs get it right and others are not strictly posix compliant.
>> Getting someone to test this on OSX would be interesting (kernel or
>> userland issue). This could even be a bug in the VM (not platform
>> independent).
>>
>> Regards,
>>
> 
> Quoting from here:
> 
> <http://man.openbsd.org/OpenBSD-current/man3/stdio.3>
> 
> "A file is disassociated from a stream by “closing” it. Output streams
> are flushed (any unwritten buffer contents are transferred to the host
> environment) before the stream is disassociated from the file."
> 
> BUGs section has a hint about buffering as well.
> 
> Regards,
> 

Well. It's mentioned there explicitly:

"If the main function returns to its original caller, or the exit(3)
function is called, all open files are closed (hence all output streams
are flushed) before program termination. Other methods of program
termination may not close files properly and hence buffered output may
be lost. In particular, _exit(2) does not flush stdio files. Neither
does an exit due to a signal. Buffers are flushed by abort(3), as
required by POSIX, although in previous implementations they were not."



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

Re: Recent issues found in Surefire master/Maven Clean Plugin 3.0.0 with Maven master

[Christian Schulte]

Am 02/19/17 um 19:47 schrieb Christian Schulte:
> Am 02/19/17 um 13:06 schrieb Michael Osipov:
>> Socket give you, of course, a lot of control, but they also impose an 
>> overhead compares to named pipes (mkfifo, CreateNamePipe).
>>
>> I think our biggest problem is that stdout is subject to buffering 
>> issues and in case if System#exit() status Z is the buffer, never 
>> written out.
>> Surefire thinks that the crashed.
> 
> Not sure I understand the issue at hand completely. If the code calling
> "exit" is in Surefire and the code consuming the stdout/stderr streams
> also is in Surefire, there is a solution to this. Can we just close the
> stdio streams before calling exit? Would that be possible? Just add
> System.out.close(), System.err.close() and System.in.close() before the
> call to System.exit(). This could solve it. Will look up posix
> documentation on this now. We maybe are just running into an issue where
> the BSDs get it right and others are not strictly posix compliant.
> Getting someone to test this on OSX would be interesting (kernel or
> userland issue). This could even be a bug in the VM (not platform
> independent).
> 
> Regards,
> 

Quoting from here:

<http://man.openbsd.org/OpenBSD-current/man3/stdio.3>

"A file is disassociated from a stream by “closing” it. Output streams
are flushed (any unwritten buffer contents are transferred to the host
environment) before the stream is disassociated from the file."

BUGs section has a hint about buffering as well.

Regards,
-- 
Christian


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

Re: Recent issues found in Surefire master/Maven Clean Plugin 3.0.0 with Maven master

[Christian Schulte]

Am 02/19/17 um 13:06 schrieb Michael Osipov:
> Socket give you, of course, a lot of control, but they also impose an 
> overhead compares to named pipes (mkfifo, CreateNamePipe).
> 
> I think our biggest problem is that stdout is subject to buffering 
> issues and in case if System#exit() status Z is the buffer, never 
> written out.
> Surefire thinks that the crashed.

Not sure I understand the issue at hand completely. If the code calling
"exit" is in Surefire and the code consuming the stdout/stderr streams
also is in Surefire, there is a solution to this. Can we just close the
stdio streams before calling exit? Would that be possible? Just add
System.out.close(), System.err.close() and System.in.close() before the
call to System.exit(). This could solve it. Will look up posix
documentation on this now. We maybe are just running into an issue where
the BSDs get it right and others are not strictly posix compliant.
Getting someone to test this on OSX would be interesting (kernel or
userland issue). This could even be a bug in the VM (not platform
independent).

Regards,
-- 
Christian


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

Re: Fwd: How to name modules, automatic and otherwise

[Christian Schulte]

Am 02/18/17 um 12:25 schrieb Robert Scholte:
> The idea from Hervé and Rémi is about having a publish rule in Central if  
> you want to publish a modular jar there which will prevent module name  
> collisions.
> Because the groupId is already owned by a specific organisation, you could  
> use them as well as "namespace"/prefix of the modular name to ensure that  
> within Central modular names are unique.
> 
> However, this collides with the idea from Mark who says that it should be  
> possible to move a modulename from one organisation to another. That  
> should only effect the GA, not the module name.

Like we did with the resolver. Changed the coordinates but did not
change package names and class names. So the module name should not
change as well. This means the coordinates are nothing to consider for
the module names but package names and class names (the content - not
the coordinates).

Regards,
-- 
Christian



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

Re: Recent issues found in Surefire master/Maven Clean Plugin 3.0.0 with Maven master

[Christian Schulte]

Am 02/17/17 um 21:48 schrieb Michael Osipov:
> Hi folks,
> 
> Christian Schulte asked me a couple of days ago wether I am able to 
> build Surefire master with Maven master. It was constantly failing for 
> him on his OpenBSD machines. Since I have several real servers with 
> FreeBSD 10.3-STABLE at hand I did run all Surefire ITs and I was able to 
> reproduce it. Our entire test infrastructure wasn't unfortunately!
> 
> @Tibor: correct me if something is wrong or missing!
> 
> After several days of heavy testing, thread dumps and log file analysis 
> with Tibor Digana and various Maven combinations (3.3.9, master, 
> MNG-6169, MNG-6169 + MCLEAN 3.0.0) we figured out that there are several 
> serious bugs in Surefire master, Maven Shared Utils 0.9/3.1.0 and likely 
> Maven Clean Plugin 3.0.0.
> 
> Since crucial parts of Surefire rely on native code in the JVM (forks, 
> streams), our code was not robust enough.
> 
> As of today we have found:
> 
> * Missing flushes in streams caused forked VM to be apparently 
> non-responsive
> * TestNG tests mostly failed due to duplicate contradicting properties 
> passed to forked VMs
> * Uninitialized/too early attributes made daemon threads to kill forked VMs
> * Code or dependency change from MCLEAN 2.6.1 to 3.0.0 cause repeated 
> failures of a handful ITs
> @Karl Heinz: were you able to figure out something here?
> 
> Issues in JIRA are pending...
> 
> Everyone's invited to take a look at the log output as well as the 
> target directory of surefire-integration-tests and contribute:
> http://home.apache.org/~michaelo/maven/surefire/. The filenames should 
> be pretty much self-explanatory.
> 
> My big question is: how can we improve our test infrastructure? Can we 
> raise with INFRA to get at least one FreeBSD and Solaris node for 
> Jenkins? I consider coverage on Windows and Ubuntu way to small, we do 
> not even have a CentOS node. Surefire ITs and Maven ITs are paramount 
> for us, we should treat them as such!
> 
> Michael

Does any of your findings solve the following already? This is what
makes the Jenkins build jobs appear unreliable. It's sending out an
email about a failed job and all you see is something like the following
sporadically. I am having the same issue locally sporadically.

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test
(default-test) on project child2: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test failed: The
forked VM terminated without saying properly goodbye. VM crash or
System.exit called ? -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test
(default-test) on project child2: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test failed: The
forked VM terminated without saying properly goodbye. VM crash or
System.exit called ?

Regards,
-- 
Christian


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

Re: I think we are ready for 3.5.0-alpha-1

[Christian Schulte]

Am 02/18/17 um 11:41 schrieb Stephen Connolly:
> We need help testing on Solaris 10/11 if anyone has access to such a system

On a SPARC machine, if possible, please.


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

Re: [ANN] feature freeze Maven core 3.5.0

[Christian Schulte]

Am 02/18/17 um 12:25 schrieb Stephen Connolly:
> Bug fixes only. Let's shake down towards the release.

+1

Currently trying to make Jenkins build almost all Maven codebases
automatically daily with Maven master. Setup isn't finished yet, though.



There are plugin IT failures on windows only. That's what I am currently
looking into.

Regards,
-- 
Christian


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

Re: I think we are ready for 3.5.0-alpha-1

[Christian Schulte]

Am 02/17/17 um 19:18 schrieb Stephen Connolly:
> Would it help yet to cut an alpha and start tracking bugs?
> 
> I am starting to be concerned that the collective of volunteers are on a
> death march with no end in site... so I am seeking ways to identify an end
> where we can cut 3.5.0 and start on 3.5.1
> 
> I don't want to be here in 2-3 weeks and still not even a 3.5.0-alpha-1
> that users could start testing

Maybe we should start concentrating on the issues we already know of,
fix those, and then start cutting releases. If you take a look at the
following build jobs, there are issues we would need to fix before
releasing anything to the users. There may still be issues with the
setup of those jobs. Currently the results are not build job related, IMHO.



Regards,
-- 
Christian


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

Re: I think we are ready for 3.5.0-alpha-1

[Christian Schulte]

Am 02/14/17 um 20:25 schrieb Michael Osipov:
> Who seconds MNG-6150 Javadoc improvements for 3.5.0 for FIX-3.5.0? 
> Functional changes, passes all tests.

+1



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

Re: Build Maven offline

[Christian Schulte]

Am 02/13/17 um 17:47 schrieb Guo Yunhe:
>> Don't. Don't do the same as done here: 
>> https://www.rpmfind.net/linux/RPM/fedora/25/s390x/m/maven-3.3.9-6.fc25.noarch.html
>>
>> The completely disassembled your tarball and build Maven theirselves. This 
>> is a non-canoncial build which we are likely not going to support! The 
>> modifications to this aren't known to us. Rather untar our offical tarball 
>> and rebuilt your package.
>>
>> Though, you have to grab the tarball from the Internet somehow.
>>
>> Michael
> 
> I know what you worry about. But the packaging system doesn't allow internet 
> download and compiled binary usually. I have to build it from source somehow.

It does not need to download the sources from somewhere? Others just
fetch the binary distribution and build a package from that. No need to
compile anything [1]. Only things you could patch are the configuration
files (like the global default settings.xml) that way. If you really
need to modify Maven sources, it's better to  present the modifications
here so that we can find a solution we can ship in the binary distribution.

[1] 

Regards,
-- 
Christian


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

Re: [PING] The GIT master branch of Maven has unreleased changes that do not pass plugin integration tests on Windows

[Christian Schulte]

This is the result of a plugins build on Windows using current Maven
3.5.0-SNAPSHOT master.

Am 02/12/17 um 23:44 schrieb Apache Jenkins Server:
> This is an automated email to notify the Maven developer list that there are 
> unreleased changes in the GIT master branch of Maven that have passed a 
> release build not passing plugin integration tests on Windows.
> 
> 
> 
> Please review the following build job for any issues with changes to the 
> Maven master branch.
> 
> 
> 
> -Jenkins
> 


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

Re: [PING] The GIT master branch of Maven has unreleased changes that do not pass plugin integration tests on Linux

[Christian Schulte]

This is the result of a plugins build on linux using current Maven
3.5.0-SNAPSHOT master.

Am 02/12/17 um 23:19 schrieb Apache Jenkins Server:
> This is an automated email to notify the Maven developer list that there are 
> unreleased changes in the GIT master branch of Maven that have passed a 
> release build not passing plugin integration tests on Linux.
> 
> 
> 
> Please review the following build job for any issues with changes to the 
> Maven master branch.
> 
> 
> 
> -Jenkins
> 


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

Re: [PING] The GIT master branch of Maven has unreleased changes that do not pass plugin integration tests on Windows

[Christian Schulte]

This is the result of a Surefire build on Windows using current Maven
3.5.0-SNAPSHOT master.

Am 02/12/17 um 23:16 schrieb Apache Jenkins Server:
> This is an automated email to notify the Maven developer list that there are 
> unreleased changes in the GIT master branch of Maven that have passed a 
> release build not passing a surefire build on Windows including integration 
> tests.
> 
> 
> 
> Please review the following build job for any issues with changes to the 
> Maven master branch.
> 
> 
> 
> -Jenkins
> 


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

Re: [PING] The GIT master branch of Maven has unreleased changes that do not pass a surefire build including integration tests on Linux

[Christian Schulte]

This is the result of a Surefire build on linux using current Maven
3.5.0-SNAPSHOT master.

Am 02/12/17 um 22:51 schrieb Apache Jenkins Server:
> This is an automated email to notify the Maven developer list that there are 
> unreleased changes in the GIT master branch of Maven that have passed a 
> release build not passing a surefire build on Linux including integration 
> tests.
> 
> 
> 
> Please review the following build job for any issues with changes to the 
> Maven master branch.
> 
> 
> 
> -Jenkins
> 


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

Re: I think we are ready for 3.5.0-alpha-1

[Christian Schulte]

Build has run. Results are: Core ITs ran successfully. Plugin ITs
failed. Surefire build failed. Workspaces are here:



Apache Maven Remote Resources Plugin ... FAILURE

/bin/sh: 1: mvn: not found

Maybe a launcher issue?



Same on Windows.

'mvn' is not recognized as an internal or external command,
operable program or batch file.

I'll take a look tomorrow.



Looking at the console output, this pretty much looks the same as what I
am getting locally:





Windows seems to be affected as well. Console output is here:



The easiest way to trigger all those jobs is to start the following
build job:



This will trigger all the other build jobs in correct order.

Note: I setup those jobs during working on the pre-reset-master branch
when I noticed that it's not enough to just run the core ITs. Those jobs
never succeeded since I created them. That's what I was working on
before resetting the branches. I would not have exepected those jobs to
fail after the reset.

The maven-master-release-status job is setup to run once a week. It is
this job sending those [PING] subject mails every now and then. When all
jobs succeed, it would (hopefully) send a mail stating that master is in
a releaseable state.

Regards,
-- 
Christian


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

Re: I think we are ready for 3.5.0-alpha-1

[Christian Schulte]

Am 12.02.2017 um 20:54 schrieb Tibor Digana:
> There is build process for surefire
> https://builds.apache.org/view/Maven/job/maven-master-release-status-test-surefire-linux
> with Jenkins file.
> This particular build fails with test
> 
> Surefire141PluggableProvidersIT
> 
> It is only one and different from your local build result.
> 
> I asked Stephen to enable Workspace, because I need to have files from
> target folders for analysis to understand what is going on the machine.
> Stephen told me that I should trigger rebuild. So I did and launched "Build
> with Parameters" but the build failed not running Maven build, however
> Workspace appears now.
> 
> How can I force trigger the build?

This is my amateur trial and error pseudo-pipeline setup. You can
trigger that "pipeline" by starting an initial build job here. This will
trigger all the other jobs.



I just started a build. If you login to Jenkins, you should be able to
access the different workspaces. Maybe a permission issue. Just login
and the workspace should be there.

Regards,
-- 
Christian


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

Re: I think we are ready for 3.5.0-alpha-1

[Christian Schulte]

I never checked different Maven versions or Surefire tags. Only the
pre-reset-master branch for a few weeks (3.4.0-SNAPSHOT back then) and
now with current Maven master (3.5.0-SNAPSHOT). The only changes to the
Maven core which could have an impact to multi-threading behaviour can
be some dependency upgrade introducing issues. We maybe just need to
find out which dependency upgrade introduces the issues. Plexus comes to
mind.


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

Re: I think we are ready for 3.5.0-alpha-1

[Christian Schulte]

@Stephen: Are there any Jenkins jobs left running the plugin ITs with
current Maven master? Surefire has it's own git repository. Do we have
some Jenkins job for this as well? It's important to run all those ITs
(plugins from subversion and the ones with theire own repository) with
what we are going to release as 3.5.0 before releasing it.

Regards,
-- 
Christian


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

Re: I think we are ready for 3.5.0-alpha-1

[Christian Schulte]

This is what happens when building (mvn verify -X -l surefire.log) the
2.19.1 tag with current Maven master.

Failed tests:
testForkModeOncePerThreadSingleThread(org.apache.maven.surefire.its.ForkModeTestNGIT):
pid 1 didn't match pid 2 expected:<[18462]@t60.schulte.it test...> but
was:<[55738]@t60.schulte.it test...>

testForkModeOncePerThreadTwoThreads(org.apache.maven.surefire.its.ForkModeTestNGIT):
number of different pids is not as expected expected:<2> but was:<3>

testSecurityManager(org.apache.maven.surefire.its.jiras.Surefire34SecurityManagerIT):
wrong number of errors expected:<1> but was:<0>

shouldNotBeVerbose(org.apache.maven.surefire.its.CheckTestNgReportTestIT):
log pattern does not match nTimes(..)

testForkModeOncePerThreadSingleThread(org.apache.maven.surefire.its.ForkModeIT):
pid 1 didn't match pid 2 expected:<[48251]@t60.schulte.it test...> but
was:<[52396]@t60.schulte.it test...>

testForkModeOncePerThreadTwoThreads(org.apache.maven.surefire.its.ForkModeIT):
number of different pids is not as expected expected:<2> but was:<3>

I'll send the log file in a separate private mail. It's nearly 1MB of
size (gzipped).

Regards,
-- 
Christian



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

Re: I think we are ready for 3.5.0-alpha-1

[Christian Schulte]

Am 02/12/17 um 11:29 schrieb Michael Osipov:
> Am 2017-02-12 um 06:53 schrieb Tibor Digana:
>> What surefire tag exactly?
> 
> I know understand what he wants now, use Maven 3.3.9/3.5.0-SNAPSHOT and 
> build 2.12.4 and 2.19.1 (default-bindings.xml) on FreeBSD with OpenJDK 7.

Yes. Just 2.19.1. Can you build that tag on FreeBSD successfully. I am
getting IT failures. That's why I started to look into surefire. Haven't
checked 2.12.4, though. Will do that now.


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

Re: I think we are ready for 3.5.0-alpha-1

[Christian Schulte]

Am 02/12/17 um 00:59 schrieb Michael Osipov:
> Am 2017-02-12 um 00:49 schrieb Christian Schulte:
>> Am 02/11/17 um 23:03 schrieb Michael Osipov:
>>> The lifecylce plugins have been moved to MNG-6169. MPLUGIN has been
>>> retained with 3.3 because there were failures. One IT is failing,
>>> MNG-5572. I am looking into the cause right now.
>>
>> Out of curiosity. @Michael: Do you have a FreeBSD box or something else
>> BSD at hand? Can you build the surefire tag of that version locally
>> without any issues? I am getting IT failures on OpenBSD here. On Jenkins
>> nothing is failing. Would be interesting how that looks on FreeBSD.
> 
> Yes, sure. FreeBSD is my main Unix test platform. So you want me to run 
> ITs with MNG-6169, is that right?

No. A surefire build of the tag corresponding to the version in core.
That build will run various surefire related ITs. Can you build that
surefire tag successfully?


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