date:20161231

Am 01/01/17 um 08:06 schrieb Christian Schulte:
> It's not even needed to change the plugin tools version any more. Only
> plugins having declared
> 
> 3.4
> 
> would get the correct resolution.

As of yesterday.

Happy new year everyone, BTW.


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

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 01/01/17 um 08:18 schrieb Christian Schulte:
> Once more I asked someone to test a snapshot and provided a link to
> Jenkins. That's where all those commits come from. I hope I'll get
> feedback on this one and that could again lead to commits. Doing this on
> a release branch - yes - I got that.

And you do want someone grabbing that snapshot to get all changes done
by all committers and not just some build of some personal branch which
is lacking all other development. Let master be the release branch but
let there be a branch all development of all committers is taking place.


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

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 01/01/17 um 07:52 schrieb Christian Schulte:
> Number of fixes to plugin POMs was lower than 10 commits. During all of
> this quite a few other bugs have been identified in the core, the ITs,
> the plugins, the plugin ITs, etc.

Last issue I created in JIRA due to this is:



Once more I asked someone to test a snapshot and provided a link to
Jenkins. That's where all those commits come from. I hope I'll get
feedback on this one and that could again lead to commits. Doing this on
a release branch - yes - I got that.


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

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 01/01/17 um 08:06 schrieb Christian Schulte:
> Am 01/01/17 um 07:52 schrieb Christian Schulte:
>> is uncovering bugs in the poms. Current master is passing all core ITs,
>> all plugin ITs and also can be used to build all plugins, if you
>> manually change to a different plugin tools release
>> (-DmavenPluginToolsVersion=3.3 or 3.5).
> 
> It's not even needed to change the plugin tools version any more. Only
> plugins having declared
> 
> 3.4
> 
> would get the correct resolution.

And all of our plugins already are working with that correct resolution
in place but are still resolved the old way, because they declare
prerequisites 2.0, 2.2.1 or 3.0. You can declare them prerequsisite 3.4
today and they'll work.


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

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 01/01/17 um 07:52 schrieb Christian Schulte:
> is uncovering bugs in the poms. Current master is passing all core ITs,
> all plugin ITs and also can be used to build all plugins, if you
> manually change to a different plugin tools release
> (-DmavenPluginToolsVersion=3.3 or 3.5).

It's not even needed to change the plugin tools version any more. Only
plugins having declared

3.4

would get the correct resolution. Everyhing else is resolved the way no
one knew about. There cannot be any plugin out there which has this in
the pom. You would not even notice things have changed as long as you do
not put such a prerequisite into the pom.


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

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 12/31/16 um 12:13 schrieb Guillaume Boué:
> 
> Having a vote on all changes to master sounds too much. I think it 
> should be up to the developers to always raise discussions whenever a 
> change would have impacts on existing ITs, or whenever a new feature is 
> considered to be added. Bug fixing should be able to be pushed easily; 

It's the bug fixing that has lead to resetting various master branches.
Someone grabs a recent snapshot, notices it does not work for him,
starts to bisect core although I stated multiple times that current core
is uncovering bugs in the poms. Current master is passing all core ITs,
all plugin ITs and also can be used to build all plugins, if you
manually change to a different plugin tools release
(-DmavenPluginToolsVersion=3.3 or 3.5). Download Maven 3.0-alpha-1 and
try it with that. Current master is a snapshot - that's pre alpha - and
is in a way better conditition than what got released as Maven 3 alpha,
beta and the first 3.0.x releases. We would have to release a few
plugins so that we can upgrade the default plugin version in the core to
those releases and we would then be ready to release that as 3.4.0.
Number of fixes to plugin POMs was lower than 10 commits. During all of
this quite a few other bugs have been identified in the core, the ITs,
the plugins, the plugin ITs, etc. All of this is fixed. We are now
resetting all of this only because there is no trust. Committing to
master means there must be consensus *before* things get committed. It
does not make sense to put any effort into fixing bugs if all this gets
you is requests to revert and endless discussions about everything.


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

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 12/31/16 um 17:36 schrieb Hervé BOUTEMY:
> looks like 1.1.0 was released without tagging the repo: no tag even in 
> Eclipse 
> git [1]. I hope it is a state that is in git, even without tag: if someone 
> can 
> define the git hash, it would be useful to add a tag, just for reference
> 
> I don't know who uses Aether 1.1.0.
> 
> And why are you saying that MRESOLVER-9 is released in 1.1.0?
> Code imported to Apache is the latest available at Eclipse, and I tagged it 
> [2]: and you committed MRESOLVER-9 yourself to Apache import [2] 2 a few 
> monthes after 1.1.0 release
> 

The 1.1.0 release came from this repository.



It has the bugfix to MRESOLVER-9. That are months before the import to
Apache and months before there has been a bugtracker in place etc. It
nearly took a year for such a fix to arive @Apache. And we are still not
going to ship it this decade.


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

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

What I marked FIX-3.6.0 could also be marked FIX-4.0.0. I cannot tell. I
would have made it part of 3.4.0 so better someone else decides that.


Am 01/01/17 um 05:42 schrieb Christian Schulte:
> Am 12/31/16 um 21:10 schrieb Stephen Connolly:
>> Here are the changes in current master since 3.3.9 (with some minor changes
>> omitted)
>>
>> Issue ID   Target Version   Summary
>>    ==   
>> MNG-1577   WONTFIX  dependencyManagement does not work for
>> transitive dependencies
>   ^
> FIX-3.6.0
> 
>> MNG-2199   WONTFIX  Support version ranges in parent elements
>   ^
> FIX-3.5.0
> 
>> MNG-4463   WONTFIX  Dependency management import should support
>> version ranges.
>   ^
> FIX-3.6.0
> 
>> MNG-5227   WONTFIX  The 'optional' flag of a dependency should
>> be manageable.
>   ^
> FIX-3.6.0
> 
>> MNG-5359   WONTFIX  Declared execution in PluginMgmt gets bound
>> to lifecycle (regression)
>   ^
> FIX-3.5.0
> 
>> MNG-5527   WONTFIX  Relocation does not work for imported poms
>   ^
> FIX-3.6.0
> 
>> MNG-5600   WONTFIX  Dependency management import should support
>> exclusions.
>   ^
> FIX-3.6.0
> 
>> MNG-5629   WONTFIX  ClosedChannelException from
>> DefaultUpdateCheckManager.read
>   ^
> FIX-3.5.0
> 
>> MNG-5761   WONTFIX  Dependency management is not transitive.
>   ^
> FIX-3.6.0
> 
>> MNG-5935   WONTFIX  Optional true getting lost in managed
>> dependencies when transitive
>   ^
> FIX-3.6.0
> 
>> MNG-5958   WONTFIX  restore binary compatibility of
>> Lifecycle.setPhases
>   ^
> FIX-3.5.0
> 
>> MNG-5971   WONTFIX  Imported dependencies should be available to
>> inheritance processing
>   ^
> FIX-3.6.0
> 
> 
>> MNG-6023   WONTFIX  Upgrade of slf4j-simple to a version later
>> than 1.7.16 blocked by upstream issue.
>   ^
> FIX-3.5.0
> 
> That's a duplicate to the "Dependency updates" JIRA issue.
> 
>> MNG-6049   WONTFIX  Add behavior to filter resolved version
>> ranges of an artifact
>   ^
> FIX-3.6.0
> 
> I am not sure about the solution to this one currently on master. It
> adds an interface we already have in the resolver but do not expose in
> Maven core. Maybe this needs re-thinking. Better solution would be to
> allow core extensions to provide various components for the
> "RepositorySystemSession". Setup of the repository system currently is
> done in a static method. This would need to be changed to support core
> extensions.
> 
>> MNG-6053   WONTFIX  guard against key without value
>   ^
> FIX-3.5.0
> 
>> MNG-6053   WONTFIX  prevent NPE when copying System Properties
>> in MavenRepositorySystemUtils
>   ^
> FIX-3.5.0
> 
>> MNG-6073   WONTFIX  Addition of a core extension point to the
>> model builder supporting model finalization.
>   ^
> FIX-3.6.0
> 
>> MNG-6074   WONTFIX  Maven should produce an error if no model
>> version has been set in a POM file used to
>> build an effective model.
>   ^
> FIX-3.5.0
> 
>> MNG-6075   WONTFIX  Increase the model validation level to the
>> next minor level version.
>   ^
> FIX-3.6.0
> 
>> MNG-6079   WONTFIX  3.4 regression: cannot override version of
>> a dependencyManagement in a submodule any
>> more
>   ^
> FIX-3.6.0
> 
>> MNG-6105   WONTFIX  properties.internal.SystemProperties
>> .addSystemProperties() is not really
>> thread-safe
>   ^
> FIX-3.5.0
> 
> Related to MNG-6053.
> 
>> MNG-6112   WONTFIX  Central repository in the 4.0.0 super POM
>> should declare update policy 'never'.
>   ^
> FIX-3.5.0
> 
>> MNG-6113   WONTFIX  Rename the 'Central Repository' to
>> 'Maven Central Repository' in the 4.0.0
>> super POM.
>   ^
> FIX-3.5.0
> 
>> MNG-6114   WONTFIX  Profiles from the global settings should be
>> ordered before profiles from the user
>> settings.
>   ^
> FIX-3.5.0
> 
>> MNG-6135   WONTFIX  Maven plugins and core extensions are not
>> dependencies, they should be resolved the
>   ^
> FIX-3.6.0
> 
>> MNG-   WONTFIX  Updated to ensure 'MavenProject.
>> getManagedVersionMap()' consistently
>> returns an immutable map.
>   ^

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

I think it would be easier if we just update the JIRA issues and set the
version the issue will be shipped in. We already have a 3.5.0 version
available. That will be the next Maven release? So we would need a 3.6.0
version and a 4.0.0 version and a 5.0.0 version. Let 4.0.0 be the next
major version in which all model version 4.0.0 features will be shipped.
Let version 5.0.0 be the next major version shipping model version
5.0.0. Let's also create corresponding branches in the repositories so
that exisiting commits can already be applied to theire final
destination ready to be merged into master sometime in the future.

Am 12/31/16 um 21:10 schrieb Stephen Connolly:
> Here are the changes in current master since 3.3.9 (with some minor changes
> omitted)
> 
> Issue ID   Target Version   Summary
>    ==   
> MNG-1577   WONTFIX  dependencyManagement does not work for
> transitive dependencies
> MNG-2199   WONTFIX  Support version ranges in parent elements
> MNG-2478   WONTFIX  add "resources-filtered" filtered resource
> directories to super POM
> MNG-3507   WONTFIX  added support for multi-lines error message
> with color
> MNG-3507   WONTFIX  ANSI Color logging for improved output
> visibility.
> MNG-3705   WONTFIX  fixed mojo execution id color display
> MNG-3825   WONTFIX  Dependencies with classifier should not
> always require a version.
> MNG-4345   WONTFIX  [regression] Plugin executions contributed
> by default lifecycle mapping execute after
> other plugin executions bound to the same
> phase"
> MNG-4347   WONTFIX  import-scoped dependencies of direct
> dependencies are not resolved using profile
> modifications from settings.xml
> MNG-4463   WONTFIX  Dependency management import should support
> version ranges.
> MNG-4645   WONTFIX  Move central repo definition out of Maven's
> core so it can be more easily changed.
> MNG-5227   WONTFIX  The 'optional' flag of a dependency should
> be manageable.
> MNG-5297   WONTFIX  improved explanations on prerequisites.maven
> in Maven 3
> MNG-5359   WONTFIX  Declared execution in PluginMgmt gets bound
> to lifecycle (regression)
> MNG-5368   WONTFIX  UnsupportedOperationException thrown when
> version range is not correct in
> dependencyManagement definitions
> MNG-5457   WONTFIX  Show repository id when downloading or
> uploading from/to a remote repository
> MNG-5527   WONTFIX  Relocation does not work for imported poms
> MNG-5538   WONTFIX  mvn start script causes cygwin warning
> MNG-5567   WONTFIX  Zip files are not included in classpaths at
> all
> MNG-5600   WONTFIX  Dependency management import should support
> exclusions.
> MNG-5607   WONTFIX  Don't use M2_HOME in mvn shell/command
> scripts anymore
> MNG-5629   WONTFIX  ClosedChannelException from
> DefaultUpdateCheckManager.read
> MNG-5639   WONTFIX  Support resolution of Import Scope POMs
> from Repo that contains a ${parameter}
> MNG-5639   WONTFIX  Support resolution of Import Scope POMs
> from Repo that contains a ${parameter}
> MNG-5661   WONTFIX  Make MavenProject instances immutable after
> initial construction
> MNG-5670   WONTFIX  guard against
> ConcurrentModificationException
> MNG-5761   WONTFIX  Dependency management is not transitive.
> MNG-5761   WONTFIX  Dependency management is not transitive.
> MNG-5761   WONTFIX  Dependency management is not transitive.
> MNG-5815   WONTFIX  "mvn.cmd" does not indicate failure
> properly when using "&&"
> MNG-5823   WONTFIX  mvnDebug doesn't work with M2_HOME with
> spaces - missing quotes
> MNG-5824   WONTFIX  Closes #49 because MNG-5824 has been
> implemented in other ways in the meantime.
> MNG-5836   WONTFIX  put $maven.home/conf/logging first in
> classpath to avoid extension jar overriding
> logging config
> MNG-5837   WONTFIX  "mvn" script invokes /bin/sh but

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

Am 12/31/16 um 21:10 schrieb Stephen Connolly:
> Here are the changes in current master since 3.3.9 (with some minor changes
> omitted)
> 
> Issue ID   Target Version   Summary
>    ==   
> MNG-1577   WONTFIX  dependencyManagement does not work for
> transitive dependencies
  ^
FIX-3.6.0

> MNG-2199   WONTFIX  Support version ranges in parent elements
  ^
FIX-3.5.0

> MNG-4463   WONTFIX  Dependency management import should support
> version ranges.
  ^
FIX-3.6.0

> MNG-5227   WONTFIX  The 'optional' flag of a dependency should
> be manageable.
  ^
FIX-3.6.0

> MNG-5359   WONTFIX  Declared execution in PluginMgmt gets bound
> to lifecycle (regression)
  ^
FIX-3.5.0

> MNG-5527   WONTFIX  Relocation does not work for imported poms
  ^
FIX-3.6.0

> MNG-5600   WONTFIX  Dependency management import should support
> exclusions.
  ^
FIX-3.6.0

> MNG-5629   WONTFIX  ClosedChannelException from
> DefaultUpdateCheckManager.read
  ^
FIX-3.5.0

> MNG-5761   WONTFIX  Dependency management is not transitive.
  ^
FIX-3.6.0

> MNG-5935   WONTFIX  Optional true getting lost in managed
> dependencies when transitive
  ^
FIX-3.6.0

> MNG-5958   WONTFIX  restore binary compatibility of
> Lifecycle.setPhases
  ^
FIX-3.5.0

> MNG-5971   WONTFIX  Imported dependencies should be available to
> inheritance processing
  ^
FIX-3.6.0


> MNG-6023   WONTFIX  Upgrade of slf4j-simple to a version later
> than 1.7.16 blocked by upstream issue.
  ^
FIX-3.5.0

That's a duplicate to the "Dependency updates" JIRA issue.

> MNG-6049   WONTFIX  Add behavior to filter resolved version
> ranges of an artifact
  ^
FIX-3.6.0

I am not sure about the solution to this one currently on master. It
adds an interface we already have in the resolver but do not expose in
Maven core. Maybe this needs re-thinking. Better solution would be to
allow core extensions to provide various components for the
"RepositorySystemSession". Setup of the repository system currently is
done in a static method. This would need to be changed to support core
extensions.

> MNG-6053   WONTFIX  guard against key without value
  ^
FIX-3.5.0

> MNG-6053   WONTFIX  prevent NPE when copying System Properties
> in MavenRepositorySystemUtils
  ^
FIX-3.5.0

> MNG-6073   WONTFIX  Addition of a core extension point to the
> model builder supporting model finalization.
  ^
FIX-3.6.0

> MNG-6074   WONTFIX  Maven should produce an error if no model
> version has been set in a POM file used to
> build an effective model.
  ^
FIX-3.5.0

> MNG-6075   WONTFIX  Increase the model validation level to the
> next minor level version.
  ^
FIX-3.6.0

> MNG-6079   WONTFIX  3.4 regression: cannot override version of
> a dependencyManagement in a submodule any
> more
  ^
FIX-3.6.0

> MNG-6105   WONTFIX  properties.internal.SystemProperties
> .addSystemProperties() is not really
> thread-safe
  ^
FIX-3.5.0

Related to MNG-6053.

> MNG-6112   WONTFIX  Central repository in the 4.0.0 super POM
> should declare update policy 'never'.
  ^
FIX-3.5.0

> MNG-6113   WONTFIX  Rename the 'Central Repository' to
> 'Maven Central Repository' in the 4.0.0
> super POM.
  ^
FIX-3.5.0

> MNG-6114   WONTFIX  Profiles from the global settings should be
> ordered before profiles from the user
> settings.
  ^
FIX-3.5.0

> MNG-6135   WONTFIX  Maven plugins and core extensions are not
> dependencies, they should be resolved the
  ^
FIX-3.6.0

> MNG-   WONTFIX  Updated to ensure 'MavenProject.
> getManagedVersionMap()' consistently
> returns an immutable map.
  ^
FIX-3.5.0

> MNG-   WONTFIX  Updated to ensure collections are immutable
> consistently.
  ^
FIX-3.5.0

> MNG-   WONTFIX  Updated to make the
> 'JavaDependencyContextRefiner' part of the
> dependency graph transformer lost in
> commit
>

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

Am 12/31/16 um 22:14 schrieb Stephen Connolly:
> FIX-3.5.0: MNG-5607, MNG-5815, MNG-5823, MNG-5824, MNG-5836, MNG-5837,
> MNG-5889, MNG-5904, MNG-5946, MNG-5963, MNG-5967, MNG-5968, MNG-6001,
> MNG-6003, MNG-6078

MNG-5968 will require updates to the ITs due to the maven-plugin-plugin
no longer supporting Javadoc without description.






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

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

I'd also like to add FIX-3.5.0: MNG-2199

It was working in Maven 3.2.2 but got broken the next release. This went
unnoticed because the ITs were not correct. Back then I did not notice
that Maven does not fail the build if it cannot resolve a parent but
just logs a warning. The ITs did not check for the warning but instead
verified the build does not fail. So there would be one commit to the
core fixing the parent version ranges and one commit to the ITs fixing
the ITs so that they start checking for the warning message in the log
instead of asserting a successfull build.


Am 12/31/16 um 21:10 schrieb Stephen Connolly:
> Here are the changes in current master since 3.3.9 (with some minor changes
> omitted)
> 
> Issue ID   Target Version   Summary
>    ==   
> MNG-1577   WONTFIX  dependencyManagement does not work for
> transitive dependencies
> MNG-2199   WONTFIX  Support version ranges in parent elements
> MNG-2478   WONTFIX  add "resources-filtered" filtered resource
> directories to super POM
> MNG-3507   WONTFIX  added support for multi-lines error message
> with color
> MNG-3507   WONTFIX  ANSI Color logging for improved output
> visibility.
> MNG-3705   WONTFIX  fixed mojo execution id color display
> MNG-3825   WONTFIX  Dependencies with classifier should not
> always require a version.
> MNG-4345   WONTFIX  [regression] Plugin executions contributed
> by default lifecycle mapping execute after
> other plugin executions bound to the same
> phase"
> MNG-4347   WONTFIX  import-scoped dependencies of direct
> dependencies are not resolved using profile
> modifications from settings.xml
> MNG-4463   WONTFIX  Dependency management import should support
> version ranges.
> MNG-4645   WONTFIX  Move central repo definition out of Maven's
> core so it can be more easily changed.
> MNG-5227   WONTFIX  The 'optional' flag of a dependency should
> be manageable.
> MNG-5297   WONTFIX  improved explanations on prerequisites.maven
> in Maven 3
> MNG-5359   WONTFIX  Declared execution in PluginMgmt gets bound
> to lifecycle (regression)
> MNG-5368   WONTFIX  UnsupportedOperationException thrown when
> version range is not correct in
> dependencyManagement definitions
> MNG-5457   WONTFIX  Show repository id when downloading or
> uploading from/to a remote repository
> MNG-5527   WONTFIX  Relocation does not work for imported poms
> MNG-5538   WONTFIX  mvn start script causes cygwin warning
> MNG-5567   WONTFIX  Zip files are not included in classpaths at
> all
> MNG-5600   WONTFIX  Dependency management import should support
> exclusions.
> MNG-5607   WONTFIX  Don't use M2_HOME in mvn shell/command
> scripts anymore
> MNG-5629   WONTFIX  ClosedChannelException from
> DefaultUpdateCheckManager.read
> MNG-5639   WONTFIX  Support resolution of Import Scope POMs
> from Repo that contains a ${parameter}
> MNG-5639   WONTFIX  Support resolution of Import Scope POMs
> from Repo that contains a ${parameter}
> MNG-5661   WONTFIX  Make MavenProject instances immutable after
> initial construction
> MNG-5670   WONTFIX  guard against
> ConcurrentModificationException
> MNG-5761   WONTFIX  Dependency management is not transitive.
> MNG-5761   WONTFIX  Dependency management is not transitive.
> MNG-5761   WONTFIX  Dependency management is not transitive.
> MNG-5815   WONTFIX  "mvn.cmd" does not indicate failure
> properly when using "&&"
> MNG-5823   WONTFIX  mvnDebug doesn't work with M2_HOME with
> spaces - missing quotes
> MNG-5824   WONTFIX  Closes #49 because MNG-5824 has been
> implemented in other ways in the meantime.
> MNG-5836   WONTFIX  put $maven.home/conf/logging first in
> classpath to avoid extension jar overriding
> logging config
> MNG-5837   WONTFIX  "mvn" script invokes /bin/sh but requires
>

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

Am 01/01/17 um 01:55 schrieb Michael Osipov:
> Undecided:
> MNG-5708: fixed by Christian's work

Should not be done in that release. Let's ship all bugfixes affecting
resolution together - not just one after the other. All or nothing. So
nothing.


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

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

2016-12-31 Thread Dan Tran

I would like to add MNG-6084   WONTFIX   Support JSR 250 @PreDestory and
@PostContruct


On Sat, Dec 31, 2016 at 5:17 PM, Michael Osipov  wrote:

> Am 2017-01-01 um 02:11 schrieb Anton Tanasenko:
>
>> FIX-3.5.0:
>> MNG-   WONTFIX  Add a ProjectArtifactsCache similar to
>> PluginArtifactsCache
>> That's actually a https://issues.apache.org/jira/browse/MNG-6025
>>
>
> JIRA adjusted, thank you. Stephen, please update your list with MNG-6025.
>
>
> 2017-01-01 2:55 GMT+02:00 Michael Osipov :
>>
>> I just went through the list my issues. Here is a safe list I would
>>> merge/cherry-pick into new master:
>>>
>>> FIX-3.5.0: MNG-5457, MNG-5567, MNG-5579, MNG-5607, MNG-5815, MNG-5954,
>>> MNG-5963, MNG-5975, MNG-5977, MNG-6001, MNG-6003, MNG-6029, MNG-6081,
>>> MNG-6102, MNG-6106, MNG-6115, MNG-6136, MNG-6137, MNG-6138
>>>
>>> To be transfered to someone else:
>>> MNG-6043 can be merged into Hervé's MNG-3507.
>>>
>>> Without issue id FIX-3.5.0:
>>> MNG-   WONTFIX  Added some docs in CLIReporting Utils
>>> NONERemove trailing whitespace
>>> MNG-   WONTFIX  Pass force=true to DefaultWagonManagerTest
>>> #testGetMissingJarForced()
>>> NONEFix checkstyle error
>>> NONEUse static final values instead of literals
>>> NONERemove non-existent m2 include in
>>> component.xml
>>> NONELanguage style improvements for commit
>>> 5dab4940c9a7d3b362bd2a8b078b183e4eb521bb
>>> MNG-   WONTFIX  Update Maven Dependency Plugin in Super POM
>>> to 2.10
>>> MNG-   WONTFIX  Removing redundant test
>>> MNG-   WONTFIX  Work around a rounding bug existed upto
>>> Java 7
>>> MNG-   WONTFIX  Remove ancient Subversion keywords
>>> MNG-   WONTFIX  Use the proper term for char U+002D (-)
>>> hyphen(-minus) instead of dash
>>>
>>> Some of them will be squashed into into closely related commits, will
>>> have
>>> tickets created or are so trivial that they will be applied directly.
>>>
>>> Drop: MNG-5976
>>>
>>> Undecided:
>>> MNG-5708: fixed by Christian's work
>>> MNG-6049: Maybe for Christian, I just pulled PR and IT
>>>
>>> Michael
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>>
>>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)


Am 2017-01-01 um 02:11 schrieb Anton Tanasenko:

FIX-3.5.0:
MNG-   WONTFIX  Add a ProjectArtifactsCache similar to
PluginArtifactsCache
That's actually a https://issues.apache.org/jira/browse/MNG-6025


JIRA adjusted, thank you. Stephen, please update your list with MNG-6025.


2017-01-01 2:55 GMT+02:00 Michael Osipov :


I just went through the list my issues. Here is a safe list I would
merge/cherry-pick into new master:

FIX-3.5.0: MNG-5457, MNG-5567, MNG-5579, MNG-5607, MNG-5815, MNG-5954,
MNG-5963, MNG-5975, MNG-5977, MNG-6001, MNG-6003, MNG-6029, MNG-6081,
MNG-6102, MNG-6106, MNG-6115, MNG-6136, MNG-6137, MNG-6138

To be transfered to someone else:
MNG-6043 can be merged into Hervé's MNG-3507.

Without issue id FIX-3.5.0:
MNG-   WONTFIX  Added some docs in CLIReporting Utils
NONERemove trailing whitespace
MNG-   WONTFIX  Pass force=true to DefaultWagonManagerTest
#testGetMissingJarForced()
NONEFix checkstyle error
NONEUse static final values instead of literals
NONERemove non-existent m2 include in component.xml
NONELanguage style improvements for commit
5dab4940c9a7d3b362bd2a8b078b183e4eb521bb
MNG-   WONTFIX  Update Maven Dependency Plugin in Super POM
to 2.10
MNG-   WONTFIX  Removing redundant test
MNG-   WONTFIX  Work around a rounding bug existed upto
Java 7
MNG-   WONTFIX  Remove ancient Subversion keywords
MNG-   WONTFIX  Use the proper term for char U+002D (-)
hyphen(-minus) instead of dash

Some of them will be squashed into into closely related commits, will have
tickets created or are so trivial that they will be applied directly.

Drop: MNG-5976

Undecided:
MNG-5708: fixed by Christian's work
MNG-6049: Maybe for Christian, I just pulled PR and IT

Michael



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









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

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

2016-12-31 Thread Anton Tanasenko

FIX-3.5.0:
MNG-   WONTFIX  Add a ProjectArtifactsCache similar to
PluginArtifactsCache
That's actually a https://issues.apache.org/jira/browse/MNG-6025

2017-01-01 2:55 GMT+02:00 Michael Osipov :

> I just went through the list my issues. Here is a safe list I would
> merge/cherry-pick into new master:
>
> FIX-3.5.0: MNG-5457, MNG-5567, MNG-5579, MNG-5607, MNG-5815, MNG-5954,
> MNG-5963, MNG-5975, MNG-5977, MNG-6001, MNG-6003, MNG-6029, MNG-6081,
> MNG-6102, MNG-6106, MNG-6115, MNG-6136, MNG-6137, MNG-6138
>
> To be transfered to someone else:
> MNG-6043 can be merged into Hervé's MNG-3507.
>
> Without issue id FIX-3.5.0:
> MNG-   WONTFIX  Added some docs in CLIReporting Utils
> NONERemove trailing whitespace
> MNG-   WONTFIX  Pass force=true to DefaultWagonManagerTest
> #testGetMissingJarForced()
> NONEFix checkstyle error
> NONEUse static final values instead of literals
> NONERemove non-existent m2 include in component.xml
> NONELanguage style improvements for commit
> 5dab4940c9a7d3b362bd2a8b078b183e4eb521bb
> MNG-   WONTFIX  Update Maven Dependency Plugin in Super POM
> to 2.10
> MNG-   WONTFIX  Removing redundant test
> MNG-   WONTFIX  Work around a rounding bug existed upto
> Java 7
> MNG-   WONTFIX  Remove ancient Subversion keywords
> MNG-   WONTFIX  Use the proper term for char U+002D (-)
> hyphen(-minus) instead of dash
>
> Some of them will be squashed into into closely related commits, will have
> tickets created or are so trivial that they will be applied directly.
>
> Drop: MNG-5976
>
> Undecided:
> MNG-5708: fixed by Christian's work
> MNG-6049: Maybe for Christian, I just pulled PR and IT
>
> Michael
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Regards,
Anton.

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

I just went through the list my issues. Here is a safe list I would 
merge/cherry-pick into new master:


FIX-3.5.0: MNG-5457, MNG-5567, MNG-5579, MNG-5607, MNG-5815, MNG-5954, 
MNG-5963, MNG-5975, MNG-5977, MNG-6001, MNG-6003, MNG-6029, MNG-6081,

MNG-6102, MNG-6106, MNG-6115, MNG-6136, MNG-6137, MNG-6138

To be transfered to someone else:
MNG-6043 can be merged into Hervé's MNG-3507.

Without issue id FIX-3.5.0:
MNG-   WONTFIX  Added some docs in CLIReporting Utils
NONERemove trailing whitespace
MNG-   WONTFIX  Pass force=true to DefaultWagonManagerTest
#testGetMissingJarForced()
NONEFix checkstyle error
NONEUse static final values instead of literals
NONERemove non-existent m2 include in component.xml
NONELanguage style improvements for commit 
5dab4940c9a7d3b362bd2a8b078b183e4eb521bb

MNG-   WONTFIX  Update Maven Dependency Plugin in Super POM
to 2.10
MNG-   WONTFIX  Removing redundant test
MNG-   WONTFIX  Work around a rounding bug existed upto
Java 7
MNG-   WONTFIX  Remove ancient Subversion keywords
MNG-   WONTFIX  Use the proper term for char U+002D (-)
hyphen(-minus) instead of dash

Some of them will be squashed into into closely related commits, will 
have tickets created or are so trivial that they will be applied directly.


Drop: MNG-5976

Undecided:
MNG-5708: fixed by Christian's work
MNG-6049: Maybe for Christian, I just pulled PR and IT

Michael


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

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

We need to figure out what is what. Also when making a proposal please
reply to the original message not previous proposals

On 31 December 2016 at 22:12, Guillaume Boué  wrote:

>
> Le 31/12/2016 à 22:14, Stephen Connolly a écrit :
>
>> FIX-3.5.0: MNG-5607, MNG-5815, MNG-5823, MNG-5824, MNG-5836, MNG-5837,
>> MNG-5889, MNG-5904, MNG-5946, MNG-5963, MNG-5967, MNG-5968, MNG-6001,
>> MNG-6003, MNG-6078
>>
>> I think colourised logging probably should be 3.5.x but I am open to the
>> idea of making it 3.5.0 as it *should* not affect the build behaviour.
>>
>> Do we have and seconders for the above?
>>
>
> I find the colorized logging really useful. Didn't encounter any issues
> with it (whether about build behaviour, or just visual behaviour) and it
> makes reading the logs in the console a lot easier. I'd mark this FIX-3.5.0
> (it spans a couple of JIRA issues, like MNG-3507, MNG-6041 and MNG-6046 at
> least).
>
>
>> Do we have anyone else proposing issues for 3.5.0?
>>
>
> MNG-5962, MNG-5958, MNG-6117.
>
> I noticed that some of those in the complete list of changes are marked as
> fixed for 3.3.9 or older versions on JIRA, like MNG-5923 or MNG-5670. Also
> noticed MNG-6070 which has a comment saying it shouldn't appear in release
> notes. Should they be removed from the list?
>
>
>> - Stephen
>>
>>
>> On Sat 31 Dec 2016 at 20:10, Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>> Here are the changes in current master since 3.3.9 (with some minor
>>> changes omitted)
>>>
>>> Issue ID   Target Version   Summary
>>>    ==   
>>> MNG-1577   WONTFIX  dependencyManagement does not work for
>>>  transitive dependencies
>>> MNG-2199   WONTFIX  Support version ranges in parent elements
>>> MNG-2478   WONTFIX  add "resources-filtered" filtered resource
>>>  directories to super POM
>>> MNG-3507   WONTFIX  added support for multi-lines error message
>>>  with color
>>> MNG-3507   WONTFIX  ANSI Color logging for improved output
>>>  visibility.
>>> MNG-3705   WONTFIX  fixed mojo execution id color display
>>> MNG-3825   WONTFIX  Dependencies with classifier should not
>>>  always require a version.
>>> MNG-4345   WONTFIX  [regression] Plugin executions contributed
>>>  by default lifecycle mapping execute after
>>>  other plugin executions bound to the same
>>>  phase"
>>> MNG-4347   WONTFIX  import-scoped dependencies of direct
>>>  dependencies are not resolved using profile
>>>  modifications from settings.xml
>>> MNG-4463   WONTFIX  Dependency management import should support
>>>  version ranges.
>>> MNG-4645   WONTFIX  Move central repo definition out of Maven's
>>>  core so it can be more easily changed.
>>> MNG-5227   WONTFIX  The 'optional' flag of a dependency should
>>>  be manageable.
>>> MNG-5297   WONTFIX  improved explanations on prerequisites.maven
>>>  in Maven 3
>>> MNG-5359   WONTFIX  Declared execution in PluginMgmt gets bound
>>>  to lifecycle (regression)
>>> MNG-5368   WONTFIX  UnsupportedOperationException thrown when
>>>  version range is not correct in
>>>  dependencyManagement definitions
>>> MNG-5457   WONTFIX  Show repository id when downloading or
>>>  uploading from/to a remote repository
>>> MNG-5527   WONTFIX  Relocation does not work for imported poms
>>> MNG-5538   WONTFIX  mvn start script causes cygwin warning
>>> MNG-5567   WONTFIX  Zip files are not included in classpaths at
>>>  all
>>> MNG-5600   WONTFIX  Dependency management import should support
>>>  exclusions.
>>> MNG-5607   WONTFIX  Don't use M2_HOME in mvn shell/command
>>>  scripts anymore
>>> MNG-5629   WONTFIX  ClosedChannelException from
>>>  DefaultUpdateCheckManager.read
>>> MNG-5639   WONTFIX  Support resolution of Import Scope POMs
>>>  from Repo that contains a ${parameter}
>>> MNG-5639   WONTFIX  Support resolution of Import Scope POMs
>>>  from Repo that contains a ${parameter}
>>> MNG-5661   WONTFIX  Make MavenProject instances immutable after
>>>  initial construction
>>> MNG-5670   WONTFIX  guard against
>>>

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

Here is the wiki page to track proposals

https://cwiki.apache.org/confluence/display/MAVEN/Roadmap+2017

On 31 December 2016 at 21:34, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Apache Proverb: If it doesn't happen on a mailing list then it is only a
> rumour!
>
> I will keep track and summarise on cwiki, but we need proposals and
> seconds on the ML
>
> -Stephen
>
> On Sat 31 Dec 2016 at 21:26, Michael Osipov  wrote:
>
>> Am 2016-12-31 um 21:10 schrieb Stephen Connolly:
>>
>> > Here are the changes in current master since 3.3.9 (with some minor
>> changes
>>
>> > omitted)
>>
>> >
>>
>> > Issue ID   Target Version   Summary
>>
>> >    ==   =
>> ===
>>
>> > MNG-1577   WONTFIX  dependencyManagement does not work for
>>
>> > transitive dependencies
>>
>> > MNG-2199   WONTFIX  Support version ranges in parent elements
>>
>> > MNG-2478   WONTFIX  add "resources-filtered" filtered resource
>>
>> > directories to super POM
>>
>> > MNG-3507   WONTFIX  added support for multi-lines error message
>>
>> > with color
>>
>> > MNG-3507   WONTFIX  ANSI Color logging for improved output
>>
>> > visibility.
>>
>> > MNG-3705   WONTFIX  fixed mojo execution id color display
>>
>> > MNG-3825   WONTFIX  Dependencies with classifier should not
>>
>> > always require a version.
>>
>> > MNG-4345   WONTFIX  [regression] Plugin executions contributed
>>
>> > by default lifecycle mapping execute after
>>
>> > other plugin executions bound to the same
>>
>> > phase"
>>
>> > MNG-4347   WONTFIX  import-scoped dependencies of direct
>>
>> > dependencies are not resolved using profile
>>
>> > modifications from settings.xml
>>
>> > MNG-4463   WONTFIX  Dependency management import should support
>>
>> > version ranges.
>>
>> > MNG-4645   WONTFIX  Move central repo definition out of Maven's
>>
>> > core so it can be more easily changed.
>>
>> > MNG-5227   WONTFIX  The 'optional' flag of a dependency should
>>
>> > be manageable.
>>
>> > MNG-5297   WONTFIX  improved explanations on prerequisites.maven
>>
>> > in Maven 3
>>
>> > MNG-5359   WONTFIX  Declared execution in PluginMgmt gets bound
>>
>> > to lifecycle (regression)
>>
>> > MNG-5368   WONTFIX  UnsupportedOperationException thrown when
>>
>> > version range is not correct in
>>
>> > dependencyManagement definitions
>>
>> > MNG-5457   WONTFIX  Show repository id when downloading or
>>
>> > uploading from/to a remote repository
>>
>> > MNG-5527   WONTFIX  Relocation does not work for imported poms
>>
>> > MNG-5538   WONTFIX  mvn start script causes cygwin warning
>>
>> > MNG-5567   WONTFIX  Zip files are not included in classpaths at
>>
>> > all
>>
>> > MNG-5600   WONTFIX  Dependency management import should support
>>
>> > exclusions.
>>
>> > MNG-5607   WONTFIX  Don't use M2_HOME in mvn shell/command
>>
>> > scripts anymore
>>
>> > MNG-5629   WONTFIX  ClosedChannelException from
>>
>> > DefaultUpdateCheckManager.read
>>
>> > MNG-5639   WONTFIX  Support resolution of Import Scope POMs
>>
>> > from Repo that contains a ${parameter}
>>
>> > MNG-5639   WONTFIX  Support resolution of Import Scope POMs
>>
>> > from Repo that contains a ${parameter}
>>
>> > MNG-5661   WONTFIX  Make MavenProject instances immutable after
>>
>> > initial construction
>>
>> > MNG-5670   WONTFIX  guard against
>>
>> > ConcurrentModificationException
>>
>> > MNG-5761   WONTFIX  Dependency management is not transitive.
>>
>> > MNG-5761   WONTFIX  Dependency management is not transitive.
>>
>> > MNG-5761   WONTFIX  Dependency management is not transitive.
>>
>> > MNG-5815   WONTFIX  "mvn.cmd" does not indicate failure
>>
>> > properly when using "&&"
>>
>> > MNG-5823   WONTFIX  mvnDebug doesn't work with M2_HOME with
>>
>> > spaces - missing quotes
>>
>> > MNG-5824   WONTFIX  Closes #49 because MNG-5824 has been
>>
>> > implemented in other ways in the meantime.
>>
>>

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)



Le 31/12/2016 à 22:14, Stephen Connolly a écrit :

FIX-3.5.0: MNG-5607, MNG-5815, MNG-5823, MNG-5824, MNG-5836, MNG-5837,
MNG-5889, MNG-5904, MNG-5946, MNG-5963, MNG-5967, MNG-5968, MNG-6001,
MNG-6003, MNG-6078

I think colourised logging probably should be 3.5.x but I am open to the
idea of making it 3.5.0 as it *should* not affect the build behaviour.

Do we have and seconders for the above?


I find the colorized logging really useful. Didn't encounter any issues 
with it (whether about build behaviour, or just visual behaviour) and it 
makes reading the logs in the console a lot easier. I'd mark this 
FIX-3.5.0 (it spans a couple of JIRA issues, like MNG-3507, MNG-6041 and 
MNG-6046 at least).




Do we have anyone else proposing issues for 3.5.0?


MNG-5962, MNG-5958, MNG-6117.

I noticed that some of those in the complete list of changes are marked 
as fixed for 3.3.9 or older versions on JIRA, like MNG-5923 or MNG-5670. 
Also noticed MNG-6070 which has a comment saying it shouldn't appear in 
release notes. Should they be removed from the list?


- Stephen


On Sat 31 Dec 2016 at 20:10, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:


Here are the changes in current master since 3.3.9 (with some minor
changes omitted)

Issue ID   Target Version   Summary
   ==   
MNG-1577   WONTFIX  dependencyManagement does not work for
 transitive dependencies
MNG-2199   WONTFIX  Support version ranges in parent elements
MNG-2478   WONTFIX  add "resources-filtered" filtered resource
 directories to super POM
MNG-3507   WONTFIX  added support for multi-lines error message
 with color
MNG-3507   WONTFIX  ANSI Color logging for improved output
 visibility.
MNG-3705   WONTFIX  fixed mojo execution id color display
MNG-3825   WONTFIX  Dependencies with classifier should not
 always require a version.
MNG-4345   WONTFIX  [regression] Plugin executions contributed
 by default lifecycle mapping execute after
 other plugin executions bound to the same
 phase"
MNG-4347   WONTFIX  import-scoped dependencies of direct
 dependencies are not resolved using profile
 modifications from settings.xml
MNG-4463   WONTFIX  Dependency management import should support
 version ranges.
MNG-4645   WONTFIX  Move central repo definition out of Maven's
 core so it can be more easily changed.
MNG-5227   WONTFIX  The 'optional' flag of a dependency should
 be manageable.
MNG-5297   WONTFIX  improved explanations on prerequisites.maven
 in Maven 3
MNG-5359   WONTFIX  Declared execution in PluginMgmt gets bound
 to lifecycle (regression)
MNG-5368   WONTFIX  UnsupportedOperationException thrown when
 version range is not correct in
 dependencyManagement definitions
MNG-5457   WONTFIX  Show repository id when downloading or
 uploading from/to a remote repository
MNG-5527   WONTFIX  Relocation does not work for imported poms
MNG-5538   WONTFIX  mvn start script causes cygwin warning
MNG-5567   WONTFIX  Zip files are not included in classpaths at
 all
MNG-5600   WONTFIX  Dependency management import should support
 exclusions.
MNG-5607   WONTFIX  Don't use M2_HOME in mvn shell/command
 scripts anymore
MNG-5629   WONTFIX  ClosedChannelException from
 DefaultUpdateCheckManager.read
MNG-5639   WONTFIX  Support resolution of Import Scope POMs
 from Repo that contains a ${parameter}
MNG-5639   WONTFIX  Support resolution of Import Scope POMs
 from Repo that contains a ${parameter}
MNG-5661   WONTFIX  Make MavenProject instances immutable after
 initial construction
MNG-5670   WONTFIX  guard against
 ConcurrentModificationException
MNG-5761   WONTFIX  Dependency management is not transitive.
MNG-5761   WONTFIX  Dependency management is not transitive.
MNG-5761   WONTFIX  Dependency management is not transitive.
MNG-5815   WONTFIX  "mvn.cmd" does not indicate failure
 properly when using "&&"
MNG-5823   WONTFIX  mvnDebug doesn't work with M2_HOME with
 spaces -

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

Christian, to avoid confusion, could you reply to the original message if
you are adding proposals... reply to proposals if you are seconding?

On 31 December 2016 at 21:31, Christian Schulte  wrote:

> Am 31.12.2016 um 22:14 schrieb Stephen Connolly:
> > FIX-3.5.0: MNG-5607, MNG-5815, MNG-5823, MNG-5824, MNG-5836, MNG-5837,
> > MNG-5889, MNG-5904, MNG-5946, MNG-5963, MNG-5967, MNG-5968, MNG-6001,
> > MNG-6003, MNG-6078
> >
> > I think colourised logging probably should be 3.5.x but I am open to the
> > idea of making it 3.5.0 as it *should* not affect the build behaviour.
> >
> > Do we have and seconders for the above?
> >
> > Do we have anyone else proposing issues for 3.5.0?
>
> FIX-3.5.0: MNG-6112,MNG-6113
>
> >
> > - Stephen
> >
> >
> > On Sat 31 Dec 2016 at 20:10, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> >> Here are the changes in current master since 3.3.9 (with some minor
> >> changes omitted)
> >>
> >> Issue ID   Target Version   Summary
> >>    ==   ==
> ==
> >> MNG-1577   WONTFIX  dependencyManagement does not work for
> >> transitive dependencies
> >> MNG-2199   WONTFIX  Support version ranges in parent elements
> >> MNG-2478   WONTFIX  add "resources-filtered" filtered resource
> >> directories to super POM
> >> MNG-3507   WONTFIX  added support for multi-lines error message
> >> with color
> >> MNG-3507   WONTFIX  ANSI Color logging for improved output
> >> visibility.
> >> MNG-3705   WONTFIX  fixed mojo execution id color display
> >> MNG-3825   WONTFIX  Dependencies with classifier should not
> >> always require a version.
> >> MNG-4345   WONTFIX  [regression] Plugin executions contributed
> >> by default lifecycle mapping execute after
> >> other plugin executions bound to the same
> >> phase"
> >> MNG-4347   WONTFIX  import-scoped dependencies of direct
> >> dependencies are not resolved using profile
> >> modifications from settings.xml
> >> MNG-4463   WONTFIX  Dependency management import should support
> >> version ranges.
> >> MNG-4645   WONTFIX  Move central repo definition out of Maven's
> >> core so it can be more easily changed.
> >> MNG-5227   WONTFIX  The 'optional' flag of a dependency should
> >> be manageable.
> >> MNG-5297   WONTFIX  improved explanations on prerequisites.maven
> >> in Maven 3
> >> MNG-5359   WONTFIX  Declared execution in PluginMgmt gets bound
> >> to lifecycle (regression)
> >> MNG-5368   WONTFIX  UnsupportedOperationException thrown when
> >> version range is not correct in
> >> dependencyManagement definitions
> >> MNG-5457   WONTFIX  Show repository id when downloading or
> >> uploading from/to a remote repository
> >> MNG-5527   WONTFIX  Relocation does not work for imported poms
> >> MNG-5538   WONTFIX  mvn start script causes cygwin warning
> >> MNG-5567   WONTFIX  Zip files are not included in classpaths at
> >> all
> >> MNG-5600   WONTFIX  Dependency management import should support
> >> exclusions.
> >> MNG-5607   WONTFIX  Don't use M2_HOME in mvn shell/command
> >> scripts anymore
> >> MNG-5629   WONTFIX  ClosedChannelException from
> >> DefaultUpdateCheckManager.read
> >> MNG-5639   WONTFIX  Support resolution of Import Scope POMs
> >> from Repo that contains a ${parameter}
> >> MNG-5639   WONTFIX  Support resolution of Import Scope POMs
> >> from Repo that contains a ${parameter}
> >> MNG-5661   WONTFIX  Make MavenProject instances immutable after
> >> initial construction
> >> MNG-5670   WONTFIX  guard against
> >> ConcurrentModificationException
> >> MNG-5761   WONTFIX  Dependency management is not transitive.
> >> MNG-5761   WONTFIX  Dependency management is not transitive.
> >> MNG-5761   WONTFIX  Dependency management is not transitive.
> >> MNG-5815   WONTFIX  "mvn.cmd" does not indicate failure
> >> properly when using "&&"
> >> MNG-5823   WONTFIX  mvnDebug doesn't work with M2_HOME with
> >> spaces - missing quotes
> >>

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

Apache Proverb: If it doesn't happen on a mailing list then it is only a
rumour!

I will keep track and summarise on cwiki, but we need proposals and seconds
on the ML

-Stephen

On Sat 31 Dec 2016 at 21:26, Michael Osipov  wrote:

> Am 2016-12-31 um 21:10 schrieb Stephen Connolly:
>
> > Here are the changes in current master since 3.3.9 (with some minor
> changes
>
> > omitted)
>
> >
>
> > Issue ID   Target Version   Summary
>
> >    ==   
>
> > MNG-1577   WONTFIX  dependencyManagement does not work for
>
> > transitive dependencies
>
> > MNG-2199   WONTFIX  Support version ranges in parent elements
>
> > MNG-2478   WONTFIX  add "resources-filtered" filtered resource
>
> > directories to super POM
>
> > MNG-3507   WONTFIX  added support for multi-lines error message
>
> > with color
>
> > MNG-3507   WONTFIX  ANSI Color logging for improved output
>
> > visibility.
>
> > MNG-3705   WONTFIX  fixed mojo execution id color display
>
> > MNG-3825   WONTFIX  Dependencies with classifier should not
>
> > always require a version.
>
> > MNG-4345   WONTFIX  [regression] Plugin executions contributed
>
> > by default lifecycle mapping execute after
>
> > other plugin executions bound to the same
>
> > phase"
>
> > MNG-4347   WONTFIX  import-scoped dependencies of direct
>
> > dependencies are not resolved using profile
>
> > modifications from settings.xml
>
> > MNG-4463   WONTFIX  Dependency management import should support
>
> > version ranges.
>
> > MNG-4645   WONTFIX  Move central repo definition out of Maven's
>
> > core so it can be more easily changed.
>
> > MNG-5227   WONTFIX  The 'optional' flag of a dependency should
>
> > be manageable.
>
> > MNG-5297   WONTFIX  improved explanations on prerequisites.maven
>
> > in Maven 3
>
> > MNG-5359   WONTFIX  Declared execution in PluginMgmt gets bound
>
> > to lifecycle (regression)
>
> > MNG-5368   WONTFIX  UnsupportedOperationException thrown when
>
> > version range is not correct in
>
> > dependencyManagement definitions
>
> > MNG-5457   WONTFIX  Show repository id when downloading or
>
> > uploading from/to a remote repository
>
> > MNG-5527   WONTFIX  Relocation does not work for imported poms
>
> > MNG-5538   WONTFIX  mvn start script causes cygwin warning
>
> > MNG-5567   WONTFIX  Zip files are not included in classpaths at
>
> > all
>
> > MNG-5600   WONTFIX  Dependency management import should support
>
> > exclusions.
>
> > MNG-5607   WONTFIX  Don't use M2_HOME in mvn shell/command
>
> > scripts anymore
>
> > MNG-5629   WONTFIX  ClosedChannelException from
>
> > DefaultUpdateCheckManager.read
>
> > MNG-5639   WONTFIX  Support resolution of Import Scope POMs
>
> > from Repo that contains a ${parameter}
>
> > MNG-5639   WONTFIX  Support resolution of Import Scope POMs
>
> > from Repo that contains a ${parameter}
>
> > MNG-5661   WONTFIX  Make MavenProject instances immutable after
>
> > initial construction
>
> > MNG-5670   WONTFIX  guard against
>
> > ConcurrentModificationException
>
> > MNG-5761   WONTFIX  Dependency management is not transitive.
>
> > MNG-5761   WONTFIX  Dependency management is not transitive.
>
> > MNG-5761   WONTFIX  Dependency management is not transitive.
>
> > MNG-5815   WONTFIX  "mvn.cmd" does not indicate failure
>
> > properly when using "&&"
>
> > MNG-5823   WONTFIX  mvnDebug doesn't work with M2_HOME with
>
> > spaces - missing quotes
>
> > MNG-5824   WONTFIX  Closes #49 because MNG-5824 has been
>
> > implemented in other ways in the meantime.
>
> > MNG-5836   WONTFIX  put $maven.home/conf/logging first in
>
> > classpath to avoid extension jar overriding
>
> > logging config
>
> > MNG-5837   WONTFIX  "mvn" script invokes /bin/sh but requires
>
> > /bin/bash functions Submitted by: Joseph
>
> >

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

Am 31.12.2016 um 22:14 schrieb Stephen Connolly:
> FIX-3.5.0: MNG-5607, MNG-5815, MNG-5823, MNG-5824, MNG-5836, MNG-5837,
> MNG-5889, MNG-5904, MNG-5946, MNG-5963, MNG-5967, MNG-5968, MNG-6001,
> MNG-6003, MNG-6078
> 
> I think colourised logging probably should be 3.5.x but I am open to the
> idea of making it 3.5.0 as it *should* not affect the build behaviour.
> 
> Do we have and seconders for the above?
> 
> Do we have anyone else proposing issues for 3.5.0?

FIX-3.5.0: MNG-6112,MNG-6113

> 
> - Stephen
> 
> 
> On Sat 31 Dec 2016 at 20:10, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
> 
>> Here are the changes in current master since 3.3.9 (with some minor
>> changes omitted)
>>
>> Issue ID   Target Version   Summary
>>    ==   
>> MNG-1577   WONTFIX  dependencyManagement does not work for
>> transitive dependencies
>> MNG-2199   WONTFIX  Support version ranges in parent elements
>> MNG-2478   WONTFIX  add "resources-filtered" filtered resource
>> directories to super POM
>> MNG-3507   WONTFIX  added support for multi-lines error message
>> with color
>> MNG-3507   WONTFIX  ANSI Color logging for improved output
>> visibility.
>> MNG-3705   WONTFIX  fixed mojo execution id color display
>> MNG-3825   WONTFIX  Dependencies with classifier should not
>> always require a version.
>> MNG-4345   WONTFIX  [regression] Plugin executions contributed
>> by default lifecycle mapping execute after
>> other plugin executions bound to the same
>> phase"
>> MNG-4347   WONTFIX  import-scoped dependencies of direct
>> dependencies are not resolved using profile
>> modifications from settings.xml
>> MNG-4463   WONTFIX  Dependency management import should support
>> version ranges.
>> MNG-4645   WONTFIX  Move central repo definition out of Maven's
>> core so it can be more easily changed.
>> MNG-5227   WONTFIX  The 'optional' flag of a dependency should
>> be manageable.
>> MNG-5297   WONTFIX  improved explanations on prerequisites.maven
>> in Maven 3
>> MNG-5359   WONTFIX  Declared execution in PluginMgmt gets bound
>> to lifecycle (regression)
>> MNG-5368   WONTFIX  UnsupportedOperationException thrown when
>> version range is not correct in
>> dependencyManagement definitions
>> MNG-5457   WONTFIX  Show repository id when downloading or
>> uploading from/to a remote repository
>> MNG-5527   WONTFIX  Relocation does not work for imported poms
>> MNG-5538   WONTFIX  mvn start script causes cygwin warning
>> MNG-5567   WONTFIX  Zip files are not included in classpaths at
>> all
>> MNG-5600   WONTFIX  Dependency management import should support
>> exclusions.
>> MNG-5607   WONTFIX  Don't use M2_HOME in mvn shell/command
>> scripts anymore
>> MNG-5629   WONTFIX  ClosedChannelException from
>> DefaultUpdateCheckManager.read
>> MNG-5639   WONTFIX  Support resolution of Import Scope POMs
>> from Repo that contains a ${parameter}
>> MNG-5639   WONTFIX  Support resolution of Import Scope POMs
>> from Repo that contains a ${parameter}
>> MNG-5661   WONTFIX  Make MavenProject instances immutable after
>> initial construction
>> MNG-5670   WONTFIX  guard against
>> ConcurrentModificationException
>> MNG-5761   WONTFIX  Dependency management is not transitive.
>> MNG-5761   WONTFIX  Dependency management is not transitive.
>> MNG-5761   WONTFIX  Dependency management is not transitive.
>> MNG-5815   WONTFIX  "mvn.cmd" does not indicate failure
>> properly when using "&&"
>> MNG-5823   WONTFIX  mvnDebug doesn't work with M2_HOME with
>> spaces - missing quotes
>> MNG-5824   WONTFIX  Closes #49 because MNG-5824 has been
>> implemented in other ways in the meantime.
>> MNG-5836   WONTFIX  put $maven.home/conf/logging first in
>> classpath to avoid extension jar overriding
>> logging config
>> MNG-5837   WONTFIX  "mvn" script invokes

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03


Am 2016-12-31 um 19:28 schrieb Stephen Connolly:

Well I think syncing patch versions is pointless but as consumers outside
of Maven are rare it might actually help to keep major.minor aligned... esp
if we are doing a reset of resolver (if we have a release of resolver
already cut)

If we have not cut a resolver release then I'm fine with starting resolver
at 1.0... but if we are dealing with having resolver releases with a
revert, we'll at least need to jump to 2.0...


+1 on the 2.0


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

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)


Am 2016-12-31 um 21:10 schrieb Stephen Connolly:

Here are the changes in current master since 3.3.9 (with some minor changes
omitted)

Issue ID   Target Version   Summary
   ==   
MNG-1577   WONTFIX  dependencyManagement does not work for
transitive dependencies
MNG-2199   WONTFIX  Support version ranges in parent elements
MNG-2478   WONTFIX  add "resources-filtered" filtered resource
directories to super POM
MNG-3507   WONTFIX  added support for multi-lines error message
with color
MNG-3507   WONTFIX  ANSI Color logging for improved output
visibility.
MNG-3705   WONTFIX  fixed mojo execution id color display
MNG-3825   WONTFIX  Dependencies with classifier should not
always require a version.
MNG-4345   WONTFIX  [regression] Plugin executions contributed
by default lifecycle mapping execute after
other plugin executions bound to the same
phase"
MNG-4347   WONTFIX  import-scoped dependencies of direct
dependencies are not resolved using profile
modifications from settings.xml
MNG-4463   WONTFIX  Dependency management import should support
version ranges.
MNG-4645   WONTFIX  Move central repo definition out of Maven's
core so it can be more easily changed.
MNG-5227   WONTFIX  The 'optional' flag of a dependency should
be manageable.
MNG-5297   WONTFIX  improved explanations on prerequisites.maven
in Maven 3
MNG-5359   WONTFIX  Declared execution in PluginMgmt gets bound
to lifecycle (regression)
MNG-5368   WONTFIX  UnsupportedOperationException thrown when
version range is not correct in
dependencyManagement definitions
MNG-5457   WONTFIX  Show repository id when downloading or
uploading from/to a remote repository
MNG-5527   WONTFIX  Relocation does not work for imported poms
MNG-5538   WONTFIX  mvn start script causes cygwin warning
MNG-5567   WONTFIX  Zip files are not included in classpaths at
all
MNG-5600   WONTFIX  Dependency management import should support
exclusions.
MNG-5607   WONTFIX  Don't use M2_HOME in mvn shell/command
scripts anymore
MNG-5629   WONTFIX  ClosedChannelException from
DefaultUpdateCheckManager.read
MNG-5639   WONTFIX  Support resolution of Import Scope POMs
from Repo that contains a ${parameter}
MNG-5639   WONTFIX  Support resolution of Import Scope POMs
from Repo that contains a ${parameter}
MNG-5661   WONTFIX  Make MavenProject instances immutable after
initial construction
MNG-5670   WONTFIX  guard against
ConcurrentModificationException
MNG-5761   WONTFIX  Dependency management is not transitive.
MNG-5761   WONTFIX  Dependency management is not transitive.
MNG-5761   WONTFIX  Dependency management is not transitive.
MNG-5815   WONTFIX  "mvn.cmd" does not indicate failure
properly when using "&&"
MNG-5823   WONTFIX  mvnDebug doesn't work with M2_HOME with
spaces - missing quotes
MNG-5824   WONTFIX  Closes #49 because MNG-5824 has been
implemented in other ways in the meantime.
MNG-5836   WONTFIX  put $maven.home/conf/logging first in
classpath to avoid extension jar overriding
logging config
MNG-5837   WONTFIX  "mvn" script invokes /bin/sh but requires
/bin/bash functions Submitted by: Joseph
Walton 
MNG-5868   WONTFIX  Adding serval times the same artifact via
MavenProjectHelper (attachArtifact) does not
produce a failure
MNG-5878   WONTFIX  added project.directory property to support
module name != artifactId in every
calculated URLs
MNG-5883   WONTFIX  Silence unnecessary legacy local repository
warning
MNG-5889   WONTFIX  adding logic that looks for the file argument
and starts the search for the .mvn directory

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

I'm not seeing any objections to the general idea.

On Tuesday I'll post a draft of the vote proposal to this thread... then if
everyone is happy (translation: nobody says "I'm not happy") I'll start the
vote on Wednesday 3rd... usual 72h but I'll probably wait for Monday 9th
Jan before closing (unless we have evidence of a lack of consensus after
72h)

Assuming the vote is successfully, I'll raise the INFRA tickets and we can
hopefully have an RC a couple of days later.

WDYT?

- Stephen
On Thu 29 Dec 2016 at 11:18, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On ASF infra, our master branch is supposed to be a protected branch and
> thus cannot be reset or force-pushed without an INFRA ticket.
>
> If we want to reset our master branch in order to clean out the history of
> the many changes and reverts to and fro etc, we thus need an INFRA ticket
> raised.
>
> INFRA should not act on such a ticket without the results of a vote of the
> committers that has at least three binding votes from the PMC (i.e. the
> majority of votes cast must be in favour and at least three PMC members
> must have voted in favour)
>
> Votes are a great way to *confirm* consensus, but a horrible way to build
> a community or establish consensus. We should only ever have a vote thread
> once the consensus seems to be established.
>
> To establish consensus we use a discuss thread.
>
> Please refrain from assigning blame, we want to grow our community not
> shrink it. The shorty endorphin rush you get from assigning blame or
> performing The Dance Of I Told You So™ will require repeated hits to
> maintain which will only lead to a more toxic community.
>
> We have not been good at maintaining our CI infrastructure:
>
> * As a consequence, some people have been developing on master rather than
> on branches in order to ensure that their development gets the benefit of
> the integration tests
>
> * This has lead to a lot of micro commits and effectively revert commits
> on master making it hard to track what actually has changed and what has
> actually been fixed.
>
> * Additionally `git blame` probably now could end up confusing people
> trying to understand the rationale for some changes
>
> We have not been good at maintaining our Integration tests:
>
> * As a consequence it has been hard to get our CI infrastructure working
> effectively
>
> * As a consequence, people have been forced to leverage a single branch
> for CI testing
>
> We have not been good at developing bigger changes in a branch
>
> etc.
>
> I could go on.
>
> My belief is that confidence in 3.4.0 has been eroded.
>
> I propose that we reset master back
> to 737de43e392fc15a0ce366db98d70aa18b3f6c03, with an analogous reset of
> master for the integration tests, and then immediately commit a dummy
> commit so that nobody accidentally does a fast-forward push.
>
> Then we can cherry pick the changes that were on the old master that we
> want to have in 3.4.0
>
> This will probably also involve:
>
> * Fixing the CI infrastructure (I favour using a pipeline multibranch
> project so that branch development is easier,
> https://builds.apache.org/job/maven-jenkinsfile/ is where I have been
> trying to prototype this... currently failing because "windows")
>
> * Switching to a culture of branch / PR development for all committers
>
> * Better providing rationale for changes, e.g. we need a succinct
> description of the actual regression between 2.x and 3.x in resolution of
> dependencies of plugins as well as actual easy to understand tests that
> demonstrate the behaviour *and* show that it is an actual regression
>
> * etc
>
> But the first step in that would be to reset master...
>
> So...
>
> Is 737de43e392fc15a0ce366db98d70aa18b3f6c03 the correct hash to reset to?
>
> What is the correct hash for the integration tests?
>
> Do we want to do this?
>
> What else should we change about our processes to prevent the need to do
> this again?
>
> Should we maybe just drop 3.4.x and jump to 3.5.x also in order to signal
> that this was a reboot version and any 3.4.x stuff is thus easy to detect
> and filter?
>
> Save your +1/-1's for actual vote threads, we need to establish a
> consensus first... then in a couple of days, if it looks like we have a
> consensus I will call a vote.
>
> -Stephen
>
-- 
Sent from my phone

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

FIX-3.5.0: MNG-5607, MNG-5815, MNG-5823, MNG-5824, MNG-5836, MNG-5837,
MNG-5889, MNG-5904, MNG-5946, MNG-5963, MNG-5967, MNG-5968, MNG-6001,
MNG-6003, MNG-6078

I think colourised logging probably should be 3.5.x but I am open to the
idea of making it 3.5.0 as it *should* not affect the build behaviour.

Do we have and seconders for the above?

Do we have anyone else proposing issues for 3.5.0?

- Stephen


On Sat 31 Dec 2016 at 20:10, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Here are the changes in current master since 3.3.9 (with some minor
> changes omitted)
>
> Issue ID   Target Version   Summary
>    ==   
> MNG-1577   WONTFIX  dependencyManagement does not work for
> transitive dependencies
> MNG-2199   WONTFIX  Support version ranges in parent elements
> MNG-2478   WONTFIX  add "resources-filtered" filtered resource
> directories to super POM
> MNG-3507   WONTFIX  added support for multi-lines error message
> with color
> MNG-3507   WONTFIX  ANSI Color logging for improved output
> visibility.
> MNG-3705   WONTFIX  fixed mojo execution id color display
> MNG-3825   WONTFIX  Dependencies with classifier should not
> always require a version.
> MNG-4345   WONTFIX  [regression] Plugin executions contributed
> by default lifecycle mapping execute after
> other plugin executions bound to the same
> phase"
> MNG-4347   WONTFIX  import-scoped dependencies of direct
> dependencies are not resolved using profile
> modifications from settings.xml
> MNG-4463   WONTFIX  Dependency management import should support
> version ranges.
> MNG-4645   WONTFIX  Move central repo definition out of Maven's
> core so it can be more easily changed.
> MNG-5227   WONTFIX  The 'optional' flag of a dependency should
> be manageable.
> MNG-5297   WONTFIX  improved explanations on prerequisites.maven
> in Maven 3
> MNG-5359   WONTFIX  Declared execution in PluginMgmt gets bound
> to lifecycle (regression)
> MNG-5368   WONTFIX  UnsupportedOperationException thrown when
> version range is not correct in
> dependencyManagement definitions
> MNG-5457   WONTFIX  Show repository id when downloading or
> uploading from/to a remote repository
> MNG-5527   WONTFIX  Relocation does not work for imported poms
> MNG-5538   WONTFIX  mvn start script causes cygwin warning
> MNG-5567   WONTFIX  Zip files are not included in classpaths at
> all
> MNG-5600   WONTFIX  Dependency management import should support
> exclusions.
> MNG-5607   WONTFIX  Don't use M2_HOME in mvn shell/command
> scripts anymore
> MNG-5629   WONTFIX  ClosedChannelException from
> DefaultUpdateCheckManager.read
> MNG-5639   WONTFIX  Support resolution of Import Scope POMs
> from Repo that contains a ${parameter}
> MNG-5639   WONTFIX  Support resolution of Import Scope POMs
> from Repo that contains a ${parameter}
> MNG-5661   WONTFIX  Make MavenProject instances immutable after
> initial construction
> MNG-5670   WONTFIX  guard against
> ConcurrentModificationException
> MNG-5761   WONTFIX  Dependency management is not transitive.
> MNG-5761   WONTFIX  Dependency management is not transitive.
> MNG-5761   WONTFIX  Dependency management is not transitive.
> MNG-5815   WONTFIX  "mvn.cmd" does not indicate failure
> properly when using "&&"
> MNG-5823   WONTFIX  mvnDebug doesn't work with M2_HOME with
> spaces - missing quotes
> MNG-5824   WONTFIX  Closes #49 because MNG-5824 has been
> implemented in other ways in the meantime.
> MNG-5836   WONTFIX  put $maven.home/conf/logging first in
> classpath to avoid extension jar overriding
> logging config
> MNG-5837   WONTFIX  "mvn" script invokes /bin/sh but requires
> /bin/bash functions Submitted by: Joseph
> Walton 
> MNG-5868   WONTFIX  Adding

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

I'm hoping that people step forward with suggestions and we build a
consensus

IMHO 3.5.0 should be absolute minimum content. Just the switch to resolver
and *maybe* the bug fixes on the launcher scripts and .mvn folder handling.
Aim would be to release 3.5.0 by mid-Jan

3.5.x is less of a rush, as I would hope for us to cut that say end of Feb
and start a 6 week cadence (assuming I can get a KT on how to release core
from JvZ)

3.6.x / 4.x.y really depends on what features we want to add

5.x.y will require at least my completion of my proposals and then some
debate... before we actually start to lock down what we really want to do
(remember my proposals are just *my* proposals... they have no weight other
than one committer saying "I think this is what we should do"). I am
writing my proposals because it is much easier to edit a draft (or write a
counter-proposal) than to start from a blank sheet of paper.

- Stephen

On Sat 31 Dec 2016 at 20:28, Robert Scholte  wrote:

>
>
>
>
>
>
> Thanks,
>
> what I'm missing is how people can provide there suggestions.
> E.g. a wiki table where everybody add his own column with preferred
> version?
> Or anonymous to somebody (you as initiator? me as chairman?) so people
> aren't driven by others choices.
> Or any other way.
> For the first 2 options you must specify a period to respond, I would
> expect at least a week due to the time of year.
>
> Robert
>
> On Sat, 31 Dec 2016 21:11:12 +0100, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> Robert, I posted the bug scrub to the dev list
>
> On 31 December 2016 at 19:19, Robert Scholte  wrote:
>
>
>
>
>
>
>
> I could do that. However, if that list results in a new discussion I'm not
> in the position to make a final statement anymore.
>
> Robert
>
> On Sat, 31 Dec 2016 17:27:18 +0100, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> Ok so we will need to do a scrub. Can somebody propose a draft scrub?
>
> Basically, go through the commits we have, identify the JIRA issues
> (creating new ones if necessary) and then produce a table with JIRA issue
> and then proposed version from the set: 3.5.0, 3.5.x, 3.6.x, 4.x.y, 5.x.y
> and WONTFIX
>
> We can then debate the table as a whole and decide the plan
>
> (Not sure if table should be on mailing list or a wiki page... but once we
> decide the plan we should apply the plan in JIRA)
>
> On Sat 31 Dec 2016 at 16:14, Hervé BOUTEMY  wrote:
>
> I think we won't avoid to pre-define a short list of issues that are
>
> controversial before working on code reset, to be sure we all agree, or
> either
>
> we'll work too much on branches with associated votes (which won't work
> given
>
> the amount of work to come), either there will be reverts because "this one
>
> requires branch work"
>
>
>
> Regards,
>
>
>
> Hervé
>
>
>
> Le jeudi 29 décembre 2016, 13:49:46 CET Robert Scholte a écrit :
>
> > thanks Stephen for picking this up.
>
> >
>
> > SHA-1: 737de43e392fc15a0ce366db98d70aa18b3f6c03
>
> > * [maven-release-plugin] prepare for next development iteration
>
> >
>
> > Yes, this is the hash I would expect to revert to.
>
> > Based on the date I would expect that maven-its should be reset to
>
> >
>
> > SHA-1: 94bd771c88cc96014ca0ddaa07ac6f778b3c7501
>
> > * [MNG-5840] Argh! tests added but not added to suite
>
> >
>
> > I like the idea of pushing to 3.5.0 to indicate there was something with
>
> > 3.4.x
>
> >
>
> > My worries are more about: how to manage which issues should be cherry
>
> > picked and who decides that list. Otherwise we might end up in the same
>
> > situation. E.g. do we have to do a vote on the branch (which might cover
>
> > multiple issues but which are related to the same topic) to decide if it
>
> > can be merged with the master?
>
> >
>
> > Robert
>
>
>
>
>
> --
> Sent from my phone
>
>
>
>
>
>
>
>
>
>
>
> --
Sent from my phone

Re: [VOTE] Releasing Wagon 2.11

Thanks for the analysis! Agree with dropping fsutil then; I committed 
the addition of the logs with it just so that we can have concrete 
numbers for comparison (the last build indicates there was no permission 
issues in using it, otherwise it wouldn't have timed out but just failed 
to find the file). NIO.2 requires Java 7 though, so looks like a good 
reason to try and update to it (and Jetty 9 in the process, as Olivier 
suggested), but maybe not for this version. That also makes me wonder if 
the NIO.2 SPARSE option doesn't implictly require special privileges on 
Windows (like it does for creating symbolic links).


In any case, the result of the Jenkins build with regard to the commit 
are here 
https://builds.apache.org/job/maven-wagon-jetty8-windows/org.apache.maven.wagon$wagon-http/3/consoleFull. 
The 4 Go test file was created instantly (30 milliseconds), and it timed 
out performing the first download; so the creation of the file isn't an 
issue. I was following the growing size of the download in the target 
directory as it happened and things didn't appear to work slowly.


The tests for wagon-http started at 11:47:28 and timed out after 
11:53:04 when doing the first download for HugeFileDownloadTest; this 
makes up for the 400 seconds (roughly 6-7 minutes) of the Surefire 
timeout. Another breakdown is seen here (oddly without 
HugeFileDownloadTest):


https://builds.apache.org/job/maven-wagon-jetty8-windows/org.apache.maven.wagon$wagon-http/3/testReport/org.apache.maven.wagon.providers.http/

All of this is actually caused by HttpsWagonTest, 
HttpsWagonPreemptiveTest and HugeFileDownloadTest taking each a bit more 
than 2 minutes. I don't think we can cut 
HugeFileDownloadTest 
below 2 minutes (with the sparse file created instantly, I see no room 
for improvements here), so focus should actually be made on those 2 
other tests.


Guillaume


Le 31/12/2016 à 16:51, Michael Osipov a écrit :

Am 2016-12-31 um 12:13 schrieb Guillaume Boué:

Do you think I can add a dummy log before the creation of the test file
(and add the timestamps to the logs of wagon-http), to see how much time
it takes on the Windows Server 2012? I'd like to see the breakdown of
what takes time on the Jenkins machine, perhaps there is nothing we can
do better (except increase the timeout to 500 or so...).


Let me share new findings before I get to the answers. I tested this 
branch on my machine at work which is part of an Active Directory 
domain, I am local admin. It is a regular, 2-core i5 machine with 12 
GiB RAM and medium-size HDD:


1. fsutil failed, domain policy requires elevated permissions to run 
fsutil in command prompt and you even see it because stderr/stdout of 
fsutil is swalled. I tried manually.

2. I have even raised the timeout to 800 seconds, it still fails.

Given this, I'd wouldn't really use fsutil. Rather NIO2 with 
StandardOption.SPARSE. This might work faster.


To your questions: go head and use SLF4J, it is already available. 
Print the log messages and you'll see how much creation really consumes.

I'd test this ony my machine at home and work.

Michael



Le 30/12/2016 à 22:46, Michael Osipov a écrit :

I just pushed another commit to the branch with your changes.
The job does not really work on Windows [1], it simply takes too long
to complete on the Windows Server 2012.

[1]
https://builds.apache.org/job/maven-wagon-jetty8-windows/2/org.apache.maven.wagon$wagon-http/console 




Am 2016-12-29 um 19:10 schrieb Guillaume Boué:
I have a Toshiba SSHD (MQ02ABD100H). I think the issue is that the 
Java
code should create a sparse file to have things faster. Using 
setLength
on a random access file probably does it depending on the OS and 
type of

drive, but it isn't creating one in my situation.

When run on Ubuntu, creating the test file is done practically 
instantly

whereas it takes 60 seconds on my Windows machine. Downloading takes
around 30 seconds in Ubuntu, whereas it takes 150 seconds in Windows.

I changed the method creating the test file (makeHugeFile) to:

if ( Os.isFamily( Os.FAMILY_WINDOWS ) )
{
Process p = new ProcessBuilder( "fsutil", "file",
"createnew", hugeFile.getAbsolutePath(),
String.valueOf(
HUGE_FILE_SIZE ) ).start();
p.waitFor();
}
else
{
RandomAccessFile ra = new RandomAccessFile(
hugeFile.getPath(), "rw" );
ra.setLength( HUGE_FILE_SIZE + 1 );
ra.seek( HUGE_FILE_SIZE );
ra.write( 1 );
ra.close();
}

This matches with the timings I get on Ubuntu (both for the

[DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

Here are the changes in current master since 3.3.9 (with some minor changes
omitted)

Issue ID   Target Version   Summary
   ==   
MNG-1577   WONTFIX  dependencyManagement does not work for
transitive dependencies
MNG-2199   WONTFIX  Support version ranges in parent elements
MNG-2478   WONTFIX  add "resources-filtered" filtered resource
directories to super POM
MNG-3507   WONTFIX  added support for multi-lines error message
with color
MNG-3507   WONTFIX  ANSI Color logging for improved output
visibility.
MNG-3705   WONTFIX  fixed mojo execution id color display
MNG-3825   WONTFIX  Dependencies with classifier should not
always require a version.
MNG-4345   WONTFIX  [regression] Plugin executions contributed
by default lifecycle mapping execute after
other plugin executions bound to the same
phase"
MNG-4347   WONTFIX  import-scoped dependencies of direct
dependencies are not resolved using profile
modifications from settings.xml
MNG-4463   WONTFIX  Dependency management import should support
version ranges.
MNG-4645   WONTFIX  Move central repo definition out of Maven's
core so it can be more easily changed.
MNG-5227   WONTFIX  The 'optional' flag of a dependency should
be manageable.
MNG-5297   WONTFIX  improved explanations on prerequisites.maven
in Maven 3
MNG-5359   WONTFIX  Declared execution in PluginMgmt gets bound
to lifecycle (regression)
MNG-5368   WONTFIX  UnsupportedOperationException thrown when
version range is not correct in
dependencyManagement definitions
MNG-5457   WONTFIX  Show repository id when downloading or
uploading from/to a remote repository
MNG-5527   WONTFIX  Relocation does not work for imported poms
MNG-5538   WONTFIX  mvn start script causes cygwin warning
MNG-5567   WONTFIX  Zip files are not included in classpaths at
all
MNG-5600   WONTFIX  Dependency management import should support
exclusions.
MNG-5607   WONTFIX  Don't use M2_HOME in mvn shell/command
scripts anymore
MNG-5629   WONTFIX  ClosedChannelException from
DefaultUpdateCheckManager.read
MNG-5639   WONTFIX  Support resolution of Import Scope POMs
from Repo that contains a ${parameter}
MNG-5639   WONTFIX  Support resolution of Import Scope POMs
from Repo that contains a ${parameter}
MNG-5661   WONTFIX  Make MavenProject instances immutable after
initial construction
MNG-5670   WONTFIX  guard against
ConcurrentModificationException
MNG-5761   WONTFIX  Dependency management is not transitive.
MNG-5761   WONTFIX  Dependency management is not transitive.
MNG-5761   WONTFIX  Dependency management is not transitive.
MNG-5815   WONTFIX  "mvn.cmd" does not indicate failure
properly when using "&&"
MNG-5823   WONTFIX  mvnDebug doesn't work with M2_HOME with
spaces - missing quotes
MNG-5824   WONTFIX  Closes #49 because MNG-5824 has been
implemented in other ways in the meantime.
MNG-5836   WONTFIX  put $maven.home/conf/logging first in
classpath to avoid extension jar overriding
logging config
MNG-5837   WONTFIX  "mvn" script invokes /bin/sh but requires
/bin/bash functions Submitted by: Joseph
Walton 
MNG-5868   WONTFIX  Adding serval times the same artifact via
MavenProjectHelper (attachArtifact) does not
produce a failure
MNG-5878   WONTFIX  added project.directory property to support
module name != artifactId in every
calculated URLs
MNG-5883   WONTFIX  Silence unnecessary legacy local repository
warning
MNG-5889   WONTFIX  adding logic that looks for the file argument
and starts the search for the .mvn directory
at the location of the

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Well I think syncing patch versions is pointless but as consumers outside
of Maven are rare it might actually help to keep major.minor aligned... esp
if we are doing a reset of resolver (if we have a release of resolver
already cut)

If we have not cut a resolver release then I'm fine with starting resolver
at 1.0... but if we are dealing with having resolver releases with a
revert, we'll at least need to jump to 2.0...

On Sat 31 Dec 2016 at 16:50, Robert Scholte  wrote:

> It is a separate component, just like wagon. Don't think there's a need to
>
> sync those versions.
>
>
>
> On Sat, 31 Dec 2016 17:48:25 +0100, Stephen Connolly
>
>  wrote:
>
>
>
> > I think we should also align our resolver release version on 3.5.0 if we
>
> > do
>
> > the reset... wdyt?
>
> >
>
> > On Sat 31 Dec 2016 at 16:37, Hervé BOUTEMY 
> wrote:
>
> >
>
> >> looks like 1.1.0 was released without tagging the repo: no tag even in
>
> >> Eclipse
>
> >>
>
> >> git [1]. I hope it is a state that is in git, even without tag: if
>
> >> someone
>
> >> can
>
> >>
>
> >> define the git hash, it would be useful to add a tag, just for reference
>
> >>
>
> >>
>
> >>
>
> >> I don't know who uses Aether 1.1.0.
>
> >>
>
> >>
>
> >>
>
> >> And why are you saying that MRESOLVER-9 is released in 1.1.0?
>
> >>
>
> >> Code imported to Apache is the latest available at Eclipse, and I
>
> >> tagged it
>
> >>
>
> >> [2]: and you committed MRESOLVER-9 yourself to Apache import [2] 2 a few
>
> >>
>
> >> monthes after 1.1.0 release
>
> >>
>
> >>
>
> >>
>
> >> Regards,
>
> >>
>
> >>
>
> >>
>
> >> Hervé
>
> >>
>
> >>
>
> >>
>
> >>
>
> >>
>
> >> [1] http://git.eclipse.org/c/aether/aether-core.git/refs/
>
> >>
>
> >>
>
> >>
>
> >> [2] https://git1-us-west.apache.org/repos/asf/maven-resolver/commit/
>
> >>
>
> >> 4cf5f7a406b516a45d8bf15e7dfe3fb3849cb87b
>
> >>
>
> >>
>
> >>
>
> >> [3] https://git-wip-us.apache.org/repos/asf/maven-resolver/commit/
>
> >>
>
> >> 1ee92862c67ec98564c4d8be1207355960f1dd5d
>
> >>
>
> >>
>
> >>
>
> >> Le vendredi 30 décembre 2016, 15:57:08 CET Christian Schulte a écrit :
>
> >>
>
> >> > Am 12/30/16 um 09:01 schrieb Robert Scholte:
>
> >>
>
> >> > > On Thu, 29 Dec 2016 18:57:56 +0100, Hervé BOUTEMY <
>
> >> herve.bout...@free.fr>
>
> >>
>
> >> > >
>
> >>
>
> >> > > wrote:
>
> >>
>
> >> > >> perhaps maven-resolver will require same reset
>
> >>
>
> >> > >
>
> >>
>
> >> > > +1
>
> >>
>
> >> > >
>
> >>
>
> >> > > IMO we forgot to do a release with the original Aether code with the
>
> >> new
>
> >>
>
> >> > > GAVs.
>
> >>
>
> >> >
>
> >>
>
> >> > Keep in mind that MRESOLVER-9 is already released in 1.1.0. I do not
>
> >>
>
> >> > know if that got committed to the repository imported to Apache.
>
> >>
>
> >> >
>
> >>
>
> >> > <
>
> >>
> http://repo.maven.apache.org/maven2/org/eclipse/aether/aether-impl/1.1.0/>
>
> >>
>
> >> >
>
> >>
>
> >> >
>
> >>
>
> >> > -
>
> >>
>
> >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> >>
>
> >> > For additional commands, e-mail: dev-h...@maven.apache.org
>
> >>
>
> >>
>
> >>
>
> >>
>
> >>
>
> >>
>
> >>
>
> >> -
>
> >>
>
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> >>
>
> >> For additional commands, e-mail: dev-h...@maven.apache.org
>
> >>
>
> >>
>
> >>
>
> >> --
>
> > Sent from my phone
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> --
Sent from my phone

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

2016-12-31 Thread Robert Scholte

It is a separate component, just like wagon. Don't think there's a need to  
sync those versions.


On Sat, 31 Dec 2016 17:48:25 +0100, Stephen Connolly  
 wrote:


I think we should also align our resolver release version on 3.5.0 if we  
do

the reset... wdyt?

On Sat 31 Dec 2016 at 16:37, Hervé BOUTEMY  wrote:


looks like 1.1.0 was released without tagging the repo: no tag even in
Eclipse

git [1]. I hope it is a state that is in git, even without tag: if  
someone

can

define the git hash, it would be useful to add a tag, just for reference



I don't know who uses Aether 1.1.0.



And why are you saying that MRESOLVER-9 is released in 1.1.0?

Code imported to Apache is the latest available at Eclipse, and I  
tagged it


[2]: and you committed MRESOLVER-9 yourself to Apache import [2] 2 a few

monthes after 1.1.0 release



Regards,



Hervé





[1] http://git.eclipse.org/c/aether/aether-core.git/refs/



[2] https://git1-us-west.apache.org/repos/asf/maven-resolver/commit/

4cf5f7a406b516a45d8bf15e7dfe3fb3849cb87b



[3] https://git-wip-us.apache.org/repos/asf/maven-resolver/commit/

1ee92862c67ec98564c4d8be1207355960f1dd5d



Le vendredi 30 décembre 2016, 15:57:08 CET Christian Schulte a écrit :

> Am 12/30/16 um 09:01 schrieb Robert Scholte:

> > On Thu, 29 Dec 2016 18:57:56 +0100, Hervé BOUTEMY <
herve.bout...@free.fr>

> >

> > wrote:

> >> perhaps maven-resolver will require same reset

> >

> > +1

> >

> > IMO we forgot to do a release with the original Aether code with the
new

> > GAVs.

>

> Keep in mind that MRESOLVER-9 is already released in 1.1.0. I do not

> know if that got committed to the repository imported to Apache.

>

> <
http://repo.maven.apache.org/maven2/org/eclipse/aether/aether-impl/1.1.0/>

>

>

> -

> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

> For additional commands, e-mail: dev-h...@maven.apache.org







-

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

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



--

Sent from my phone


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

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

I think we should also align our resolver release version on 3.5.0 if we do
the reset... wdyt?

On Sat 31 Dec 2016 at 16:37, Hervé BOUTEMY  wrote:

> looks like 1.1.0 was released without tagging the repo: no tag even in
> Eclipse
>
> git [1]. I hope it is a state that is in git, even without tag: if someone
> can
>
> define the git hash, it would be useful to add a tag, just for reference
>
>
>
> I don't know who uses Aether 1.1.0.
>
>
>
> And why are you saying that MRESOLVER-9 is released in 1.1.0?
>
> Code imported to Apache is the latest available at Eclipse, and I tagged it
>
> [2]: and you committed MRESOLVER-9 yourself to Apache import [2] 2 a few
>
> monthes after 1.1.0 release
>
>
>
> Regards,
>
>
>
> Hervé
>
>
>
>
>
> [1] http://git.eclipse.org/c/aether/aether-core.git/refs/
>
>
>
> [2] https://git1-us-west.apache.org/repos/asf/maven-resolver/commit/
>
> 4cf5f7a406b516a45d8bf15e7dfe3fb3849cb87b
>
>
>
> [3] https://git-wip-us.apache.org/repos/asf/maven-resolver/commit/
>
> 1ee92862c67ec98564c4d8be1207355960f1dd5d
>
>
>
> Le vendredi 30 décembre 2016, 15:57:08 CET Christian Schulte a écrit :
>
> > Am 12/30/16 um 09:01 schrieb Robert Scholte:
>
> > > On Thu, 29 Dec 2016 18:57:56 +0100, Hervé BOUTEMY <
> herve.bout...@free.fr>
>
> > >
>
> > > wrote:
>
> > >> perhaps maven-resolver will require same reset
>
> > >
>
> > > +1
>
> > >
>
> > > IMO we forgot to do a release with the original Aether code with the
> new
>
> > > GAVs.
>
> >
>
> > Keep in mind that MRESOLVER-9 is already released in 1.1.0. I do not
>
> > know if that got committed to the repository imported to Apache.
>
> >
>
> > <
> http://repo.maven.apache.org/maven2/org/eclipse/aether/aether-impl/1.1.0/>
>
> >
>
> >
>
> > -
>
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
>
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> --
Sent from my phone

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

2016-12-31 Thread Hervé BOUTEMY

looks like 1.1.0 was released without tagging the repo: no tag even in Eclipse 
git [1]. I hope it is a state that is in git, even without tag: if someone can 
define the git hash, it would be useful to add a tag, just for reference

I don't know who uses Aether 1.1.0.

And why are you saying that MRESOLVER-9 is released in 1.1.0?
Code imported to Apache is the latest available at Eclipse, and I tagged it 
[2]: and you committed MRESOLVER-9 yourself to Apache import [2] 2 a few 
monthes after 1.1.0 release

Regards,

Hervé

[1] http://git.eclipse.org/c/aether/aether-core.git/refs/

[2] https://git1-us-west.apache.org/repos/asf/maven-resolver/commit/
4cf5f7a406b516a45d8bf15e7dfe3fb3849cb87b

[3] https://git-wip-us.apache.org/repos/asf/maven-resolver/commit/
1ee92862c67ec98564c4d8be1207355960f1dd5d

Le vendredi 30 décembre 2016, 15:57:08 CET Christian Schulte a écrit :
> Am 12/30/16 um 09:01 schrieb Robert Scholte:
> > On Thu, 29 Dec 2016 18:57:56 +0100, Hervé BOUTEMY 
> > 
> > wrote:
> >> perhaps maven-resolver will require same reset
> > 
> > +1
> > 
> > IMO we forgot to do a release with the original Aether code with the new
> > GAVs.
> 
> Keep in mind that MRESOLVER-9 is already released in 1.1.0. I do not
> know if that got committed to the repository imported to Apache.
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org

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

Re: [VOTE] Releasing Wagon 2.11

Am 2016-12-31 um 12:13 schrieb Guillaume Boué:

Do you think I can add a dummy log before the creation of the test file
(and add the timestamps to the logs of wagon-http), to see how much time
it takes on the Windows Server 2012? I'd like to see the breakdown of
what takes time on the Jenkins machine, perhaps there is nothing we can
do better (except increase the timeout to 500 or so...).

Let me share new findings before I get to the answers. I tested this
branch on my machine at work which is part of an Active Directory
domain, I am local admin. It is a regular, 2-core i5 machine with 12 GiB
RAM and medium-size HDD:

1. fsutil failed, domain policy requires elevated permissions to run
fsutil in command prompt and you even see it because stderr/stdout of
fsutil is swalled. I tried manually.

2. I have even raised the timeout to 800 seconds, it still fails.

Given this, I'd wouldn't really use fsutil. Rather NIO2 with
StandardOption.SPARSE. This might work faster.

To your questions: go head and use SLF4J, it is already available. Print
the log messages and you'll see how much creation really consumes.

I'd test this ony my machine at home and work.

Michael

Le 30/12/2016 à 22:46, Michael Osipov a écrit :

I just pushed another commit to the branch with your changes.
The job does not really work on Windows [1], it simply takes too long
to complete on the Windows Server 2012.

[1]
https://builds.apache.org/job/maven-wagon-jetty8-windows/2/org.apache.maven.wagon$wagon-http/console

Am 2016-12-29 um 19:10 schrieb Guillaume Boué:

I have a Toshiba SSHD (MQ02ABD100H). I think the issue is that the Java
code should create a sparse file to have things faster. Using setLength
on a random access file probably does it depending on the OS and type of
drive, but it isn't creating one in my situation.

When run on Ubuntu, creating the test file is done practically instantly
whereas it takes 60 seconds on my Windows machine. Downloading takes
around 30 seconds in Ubuntu, whereas it takes 150 seconds in Windows.

I changed the method creating the test file (makeHugeFile) to:

if ( Os.isFamily( Os.FAMILY_WINDOWS ) )
{
Process p = new ProcessBuilder( "fsutil", "file",
"createnew", hugeFile.getAbsolutePath(),
String.valueOf(
HUGE_FILE_SIZE ) ).start();
p.waitFor();
}
else
{
RandomAccessFile ra = new RandomAccessFile(
hugeFile.getPath(), "rw" );
ra.setLength( HUGE_FILE_SIZE + 1 );
ra.seek( HUGE_FILE_SIZE );
ra.write( 1 );
ra.close();
}

This matches with the timings I get on Ubuntu (both for the creation of
the file, and the downloading via Wagon). I ran the build several times
with this change without any timeout issues. Can you test this change on
your side?

Side-note: I added "ra.close();" in the code above, because the random
access file wasn't closed otherwise, and then the file wasn't getting
deleted properly.

Guillaume

Le 29/12/2016 à 15:50, Michael Osipov a écrit :

Am 2016-12-29 um 12:24 schrieb Guillaume Boué:

I ran them at least 10 times, and there was the timeout issue each
time.
Yes, the timeout is Surefire waiting for the forked VM. I applied the
patch (I had done similar tries also) but I still have the issue on
Windows 10.

You'll find the logs attached. It seems that the download is really
advancing (inside target, I can see the file hugetxt slowly
growing), but is just taking a long time. Additionally, the test class
HugeFileDownloadTest is composed of 2 tests, downloading the same
file 2
times with different parameters: from the logs, it seems one of
them is
succeeding (taking 140 seconds of the 400 in total), and then it times
out performing the second.

Also, part of the issue is probably with the time it takes to
create the
4 Go test file that is later downloaded through Wagon (maybe it should
be done by calling the fsutil command when the test runs on Windows).
I'll try to do more timings when running the tests with Ubuntu and see
where the difference is.

Thanks for the analysis. I think the cheapest improvement we can do is
to create the file only once (setUp(), tearDown(). It is created for
each test again. I do not think that this is really necessary.

What type of disks do you have? This test passes on my machine within
70 seconds on a Samsung SSD.

I will apply the patch to the branch because those fixes are necessary
anyway.

Please keep me updated.

Michael

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

---
L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
https://www.avast.com/antivirus

-
To unsubscribe, e-mail:

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

2016-12-31 Thread Hervé BOUTEMY

good question.

Here are some options:
1. last release used in Maven 3.3.9, ie Aether 1.0.2.v20150114
sha1 8092eaecbd34bd7bf18f49cb8a99bd218fb6e30e [1], that is currently
HEAD of 1.0.x branch

2. code imported to Apache, that I tagged as aether-core-import in master
sha1 4cf5f7a406b516a45d8bf15e7dfe3fb3849cb87b [2], 1.1.0-SNAPSHOT
Notice that I don't precisely know what is different from 1.0.2.v20150114

3. the last commit before changes that go beyond gav partial updates (because 
changes were done before import vote was finished)
sha1 11a061b66fd15b8c3584f48afa69955d9392861e [3]


The biggest question is: what is the precise impact of 1.0.2 vs 1.1.0-
SNAPSHOT?
I personnally don't know

Regards,

Hervé


[1] https://git1-us-west.apache.org/repos/asf/maven-resolver/commit/
8092eaecbd34bd7bf18f49cb8a99bd218fb6e30e

[2]
https://git1-us-west.apache.org/repos/asf/maven-resolver/commit/
4cf5f7a406b516a45d8bf15e7dfe3fb3849cb87b

[3]
https://git1-us-west.apache.org/repos/asf/maven-resolver/commit/
11a061b66fd15b8c3584f48afa69955d9392861e

Le vendredi 30 décembre 2016, 13:54:58 CET Stephen Connolly a écrit :
> What hash do we want to reset resolved to?
> 
> (We will be *renaming* master in all cases so that the history is
> available... just not on master)
> 
> On Fri 30 Dec 2016 at 08:02, Robert Scholte  wrote:
> > On Thu, 29 Dec 2016 18:57:56 +0100, Hervé BOUTEMY 
> > 
> > wrote:
> > > perhaps maven-resolver will require same reset
> > 
> > +1
> > 
> > 
> > 
> > IMO we forgot to do a release with the original Aether code with the new
> > 
> > 
> > 
> > GAVs.
> > 
> > 
> > 
> > Robert
> > 
> > > and we'll need to define which convention to use on Jira when merging
> > > 
> > > code:
> > > 
> > > remove "Fix Version: 3.4.0" for example, to track what features have not
> > > 
> > > been
> > > 
> > > merged yet
> > > 
> > > 
> > > 
> > > Regards,
> > > 
> > > 
> > > 
> > > Hervé
> > > 
> > > Le jeudi 29 décembre 2016, 11:18:59 CET Stephen Connolly a écrit :
> > >> On ASF infra, our master branch is supposed to be a protected branch
> > >> and
> > >> 
> > >> thus cannot be reset or force-pushed without an INFRA ticket.
> > >> 
> > >> 
> > >> 
> > >> If we want to reset our master branch in order to clean out the history
> > >> 
> > >> of
> > >> 
> > >> the many changes and reverts to and fro etc, we thus need an INFRA
> > >> 
> > >> ticket
> > >> 
> > >> raised.
> > >> 
> > >> 
> > >> 
> > >> INFRA should not act on such a ticket without the results of a vote of
> > >> 
> > >> the
> > >> 
> > >> committers that has at least three binding votes from the PMC (i.e. the
> > >> 
> > >> majority of votes cast must be in favour and at least three PMC members
> > >> 
> > >> must have voted in favour)
> > >> 
> > >> 
> > >> 
> > >> Votes are a great way to *confirm* consensus, but a horrible way to
> > >> 
> > >> build a
> > >> 
> > >> community or establish consensus. We should only ever have a vote
> > >> thread
> > >> 
> > >> once the consensus seems to be established.
> > >> 
> > >> 
> > >> 
> > >> To establish consensus we use a discuss thread.
> > >> 
> > >> 
> > >> 
> > >> Please refrain from assigning blame, we want to grow our community not
> > >> 
> > >> shrink it. The shorty endorphin rush you get from assigning blame or
> > >> 
> > >> performing The Dance Of I Told You So™ will require repeated hits to
> > >> 
> > >> maintain which will only lead to a more toxic community.
> > >> 
> > >> 
> > >> 
> > >> We have not been good at maintaining our CI infrastructure:
> > >> 
> > >> 
> > >> 
> > >> * As a consequence, some people have been developing on master rather
> > >> 
> > >> than
> > >> 
> > >> on branches in order to ensure that their development gets the benefit
> > >> 
> > >> of
> > >> 
> > >> the integration tests
> > >> 
> > >> 
> > >> 
> > >> * This has lead to a lot of micro commits and effectively revert
> > >> 
> > >> commits on
> > >> 
> > >> master making it hard to track what actually has changed and what has
> > >> 
> > >> actually been fixed.
> > >> 
> > >> 
> > >> 
> > >> * Additionally `git blame` probably now could end up confusing people
> > >> 
> > >> trying to understand the rationale for some changes
> > >> 
> > >> 
> > >> 
> > >> We have not been good at maintaining our Integration tests:
> > >> 
> > >> 
> > >> 
> > >> * As a consequence it has been hard to get our CI infrastructure
> > >> working
> > >> 
> > >> effectively
> > >> 
> > >> 
> > >> 
> > >> * As a consequence, people have been forced to leverage a single branch
> > >> 
> > >> for
> > >> 
> > >> CI testing
> > >> 
> > >> 
> > >> 
> > >> We have not been good at developing bigger changes in a branch
> > >> 
> > >> 
> > >> 
> > >> etc.
> > >> 
> > >> 
> > >> 
> > >> I could go on.
> > >> 
> > >> 
> > >> 
> > >> My belief is that confidence in 3.4.0 has been eroded.
> > >> 
> > >> 
> > >> 
> > >> I propose that we reset master back
> > >> 
> > >> to

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

With pipeline multibranch we should be able to get the integration test
results as a GitHub status pushed back (perhaps even comments on JIRA)

Switching to pipeline multibranch should radically improve our CI
infrastructure

On Sat 31 Dec 2016 at 12:12, Tibor Digana 
wrote:

> Stephen,
>
>
>
> Maybe we should add an icon (green/red) of build status on the page [1].
>
> The same should appear on every pull request in GitHub Maven origin/master
>
> and branches.
>
> WDYT?
>
> [1] https://github.com/apache/maven-integration-testing
>
>
>
> T
>
>
>
> On Sat, Dec 31, 2016 at 1:07 PM, Stephen Connolly <
>
> stephen.alan.conno...@gmail.com> wrote:
>
>
>
> > On Saturday, 31 December 2016, Guillaume Boué  wrote:
>
> >
>
> > >
>
> > >
>
> > > Le 30/12/2016 à 09:01, Robert Scholte a écrit :
>
> > >
>
> > >> On Thu, 29 Dec 2016 18:57:56 +0100, Hervé BOUTEMY <
>
> > herve.bout...@free.fr>
>
> > >> wrote:
>
> > >>
>
> > >> perhaps maven-resolver will require same reset
>
> > >>>
>
> > >>
>
> > >> +1
>
> > >>
>
> > >> IMO we forgot to do a release with the original Aether code with the
> new
>
> > >> GAVs.
>
> > >>
>
> > >> Robert
>
> > >>
>
> > >>
>
> > >>> and we'll need to define which convention to use on Jira when merging
>
> > >>> code:
>
> > >>> remove "Fix Version: 3.4.0" for example, to track what features have
>
> > not
>
> > >>> been
>
> > >>> merged yet
>
> > >>>
>
> > >>> Regards,
>
> > >>>
>
> > >>> Hervé
>
> > >>>
>
> > >>> Le jeudi 29 décembre 2016, 11:18:59 CET Stephen Connolly a écrit :
>
> > >>>
>
> >  On ASF infra, our master branch is supposed to be a protected branch
>
> > and
>
> >  thus cannot be reset or force-pushed without an INFRA ticket.
>
> > 
>
> >  If we want to reset our master branch in order to clean out the
>
> > history
>
> >  of
>
> >  the many changes and reverts to and fro etc, we thus need an INFRA
>
> >  ticket
>
> >  raised.
>
> > 
>
> >  INFRA should not act on such a ticket without the results of a vote
> of
>
> >  the
>
> >  committers that has at least three binding votes from the PMC (i.e.
>
> > the
>
> >  majority of votes cast must be in favour and at least three PMC
>
> > members
>
> >  must have voted in favour)
>
> > 
>
> >  Votes are a great way to *confirm* consensus, but a horrible way to
>
> >  build a
>
> >  community or establish consensus. We should only ever have a vote
>
> > thread
>
> >  once the consensus seems to be established.
>
> > 
>
> >  To establish consensus we use a discuss thread.
>
> > 
>
> >  Please refrain from assigning blame, we want to grow our community
> not
>
> >  shrink it. The shorty endorphin rush you get from assigning blame or
>
> >  performing The Dance Of I Told You So™ will require repeated hits to
>
> >  maintain which will only lead to a more toxic community.
>
> > 
>
> >  We have not been good at maintaining our CI infrastructure:
>
> > 
>
> >  * As a consequence, some people have been developing on master
> rather
>
> >  than
>
> >  on branches in order to ensure that their development gets the
> benefit
>
> >  of
>
> >  the integration tests
>
> > 
>
> >  * This has lead to a lot of micro commits and effectively revert
>
> >  commits on
>
> >  master making it hard to track what actually has changed and what
> has
>
> >  actually been fixed.
>
> > 
>
> >  * Additionally `git blame` probably now could end up confusing
> people
>
> >  trying to understand the rationale for some changes
>
> > 
>
> >  We have not been good at maintaining our Integration tests:
>
> > 
>
> >  * As a consequence it has been hard to get our CI infrastructure
>
> > working
>
> >  effectively
>
> > 
>
> >  * As a consequence, people have been forced to leverage a single
>
> > branch
>
> >  for
>
> >  CI testing
>
> > 
>
> >  We have not been good at developing bigger changes in a branch
>
> > 
>
> >  etc.
>
> > 
>
> >  I could go on.
>
> > 
>
> >  My belief is that confidence in 3.4.0 has been eroded.
>
> > 
>
> >  I propose that we reset master back
>
> >  to 737de43e392fc15a0ce366db98d70aa18b3f6c03, with an analogous reset
>
> > of
>
> >  master for the integration tests, and then immediately commit a
> dummy
>
> >  commit so that nobody accidentally does a fast-forward push.
>
> > 
>
> >  Then we can cherry pick the changes that were on the old master that
>
> > we
>
> >  want to have in 3.4.0
>
> > 
>
> >  This will probably also involve:
>
> > 
>
> >  * Fixing the CI infrastructure (I favour using a pipeline
> multibranch
>
> >  project so that branch development is easier,
>
> >  https://builds.apache.org/job/maven-jenkinsfile/ is where I have
> been
>
> >  trying to prototype this... currently failing

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

2016-12-31 Thread Tibor Digana

Stephen,

Maybe we should add an icon (green/red) of build status on the page [1].
The same should appear on every pull request in GitHub Maven origin/master
and branches.
WDYT?
[1] https://github.com/apache/maven-integration-testing

T

On Sat, Dec 31, 2016 at 1:07 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On Saturday, 31 December 2016, Guillaume Boué  wrote:
>
> >
> >
> > Le 30/12/2016 à 09:01, Robert Scholte a écrit :
> >
> >> On Thu, 29 Dec 2016 18:57:56 +0100, Hervé BOUTEMY <
> herve.bout...@free.fr>
> >> wrote:
> >>
> >> perhaps maven-resolver will require same reset
> >>>
> >>
> >> +1
> >>
> >> IMO we forgot to do a release with the original Aether code with the new
> >> GAVs.
> >>
> >> Robert
> >>
> >>
> >>> and we'll need to define which convention to use on Jira when merging
> >>> code:
> >>> remove "Fix Version: 3.4.0" for example, to track what features have
> not
> >>> been
> >>> merged yet
> >>>
> >>> Regards,
> >>>
> >>> Hervé
> >>>
> >>> Le jeudi 29 décembre 2016, 11:18:59 CET Stephen Connolly a écrit :
> >>>
>  On ASF infra, our master branch is supposed to be a protected branch
> and
>  thus cannot be reset or force-pushed without an INFRA ticket.
> 
>  If we want to reset our master branch in order to clean out the
> history
>  of
>  the many changes and reverts to and fro etc, we thus need an INFRA
>  ticket
>  raised.
> 
>  INFRA should not act on such a ticket without the results of a vote of
>  the
>  committers that has at least three binding votes from the PMC (i.e.
> the
>  majority of votes cast must be in favour and at least three PMC
> members
>  must have voted in favour)
> 
>  Votes are a great way to *confirm* consensus, but a horrible way to
>  build a
>  community or establish consensus. We should only ever have a vote
> thread
>  once the consensus seems to be established.
> 
>  To establish consensus we use a discuss thread.
> 
>  Please refrain from assigning blame, we want to grow our community not
>  shrink it. The shorty endorphin rush you get from assigning blame or
>  performing The Dance Of I Told You So™ will require repeated hits to
>  maintain which will only lead to a more toxic community.
> 
>  We have not been good at maintaining our CI infrastructure:
> 
>  * As a consequence, some people have been developing on master rather
>  than
>  on branches in order to ensure that their development gets the benefit
>  of
>  the integration tests
> 
>  * This has lead to a lot of micro commits and effectively revert
>  commits on
>  master making it hard to track what actually has changed and what has
>  actually been fixed.
> 
>  * Additionally `git blame` probably now could end up confusing people
>  trying to understand the rationale for some changes
> 
>  We have not been good at maintaining our Integration tests:
> 
>  * As a consequence it has been hard to get our CI infrastructure
> working
>  effectively
> 
>  * As a consequence, people have been forced to leverage a single
> branch
>  for
>  CI testing
> 
>  We have not been good at developing bigger changes in a branch
> 
>  etc.
> 
>  I could go on.
> 
>  My belief is that confidence in 3.4.0 has been eroded.
> 
>  I propose that we reset master back
>  to 737de43e392fc15a0ce366db98d70aa18b3f6c03, with an analogous reset
> of
>  master for the integration tests, and then immediately commit a dummy
>  commit so that nobody accidentally does a fast-forward push.
> 
>  Then we can cherry pick the changes that were on the old master that
> we
>  want to have in 3.4.0
> 
>  This will probably also involve:
> 
>  * Fixing the CI infrastructure (I favour using a pipeline multibranch
>  project so that branch development is easier,
>  https://builds.apache.org/job/maven-jenkinsfile/ is where I have been
>  trying to prototype this... currently failing because "windows")
> 
>  * Switching to a culture of branch / PR development for all committers
> 
>  * Better providing rationale for changes, e.g. we need a succinct
>  description of the actual regression between 2.x and 3.x in resolution
>  of
>  dependencies of plugins as well as actual easy to understand tests
> that
>  demonstrate the behaviour *and* show that it is an actual regression
> 
>  * etc
> 
>  But the first step in that would be to reset master...
> 
>  So...
> 
>  Is 737de43e392fc15a0ce366db98d70aa18b3f6c03 the correct hash to reset
>  to?
> 
>  What is the correct hash for the integration tests?
> 
>  Do we want to do this?
> 
>  What else should we change about our processes to prevent the need to
> do
>  this again?
>

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

On Saturday, 31 December 2016, Guillaume Boué  wrote:

>
>
> Le 30/12/2016 à 09:01, Robert Scholte a écrit :
>
>> On Thu, 29 Dec 2016 18:57:56 +0100, Hervé BOUTEMY 
>> wrote:
>>
>> perhaps maven-resolver will require same reset
>>>
>>
>> +1
>>
>> IMO we forgot to do a release with the original Aether code with the new
>> GAVs.
>>
>> Robert
>>
>>
>>> and we'll need to define which convention to use on Jira when merging
>>> code:
>>> remove "Fix Version: 3.4.0" for example, to track what features have not
>>> been
>>> merged yet
>>>
>>> Regards,
>>>
>>> Hervé
>>>
>>> Le jeudi 29 décembre 2016, 11:18:59 CET Stephen Connolly a écrit :
>>>
 On ASF infra, our master branch is supposed to be a protected branch and
 thus cannot be reset or force-pushed without an INFRA ticket.

 If we want to reset our master branch in order to clean out the history
 of
 the many changes and reverts to and fro etc, we thus need an INFRA
 ticket
 raised.

 INFRA should not act on such a ticket without the results of a vote of
 the
 committers that has at least three binding votes from the PMC (i.e. the
 majority of votes cast must be in favour and at least three PMC members
 must have voted in favour)

 Votes are a great way to *confirm* consensus, but a horrible way to
 build a
 community or establish consensus. We should only ever have a vote thread
 once the consensus seems to be established.

 To establish consensus we use a discuss thread.

 Please refrain from assigning blame, we want to grow our community not
 shrink it. The shorty endorphin rush you get from assigning blame or
 performing The Dance Of I Told You So™ will require repeated hits to
 maintain which will only lead to a more toxic community.

 We have not been good at maintaining our CI infrastructure:

 * As a consequence, some people have been developing on master rather
 than
 on branches in order to ensure that their development gets the benefit
 of
 the integration tests

 * This has lead to a lot of micro commits and effectively revert
 commits on
 master making it hard to track what actually has changed and what has
 actually been fixed.

 * Additionally `git blame` probably now could end up confusing people
 trying to understand the rationale for some changes

 We have not been good at maintaining our Integration tests:

 * As a consequence it has been hard to get our CI infrastructure working
 effectively

 * As a consequence, people have been forced to leverage a single branch
 for
 CI testing

 We have not been good at developing bigger changes in a branch

 etc.

 I could go on.

 My belief is that confidence in 3.4.0 has been eroded.

 I propose that we reset master back
 to 737de43e392fc15a0ce366db98d70aa18b3f6c03, with an analogous reset of
 master for the integration tests, and then immediately commit a dummy
 commit so that nobody accidentally does a fast-forward push.

 Then we can cherry pick the changes that were on the old master that we
 want to have in 3.4.0

 This will probably also involve:

 * Fixing the CI infrastructure (I favour using a pipeline multibranch
 project so that branch development is easier,
 https://builds.apache.org/job/maven-jenkinsfile/ is where I have been
 trying to prototype this... currently failing because "windows")

 * Switching to a culture of branch / PR development for all committers

 * Better providing rationale for changes, e.g. we need a succinct
 description of the actual regression between 2.x and 3.x in resolution
 of
 dependencies of plugins as well as actual easy to understand tests that
 demonstrate the behaviour *and* show that it is an actual regression

 * etc

 But the first step in that would be to reset master...

 So...

 Is 737de43e392fc15a0ce366db98d70aa18b3f6c03 the correct hash to reset
 to?

 What is the correct hash for the integration tests?

 Do we want to do this?

 What else should we change about our processes to prevent the need to do
 this again?

>>>
> Having a vote on all changes to master sounds too much. I think it should
> be up to the developers to always raise discussions whenever a change would
> have impacts on existing ITs, or whenever a new feature is considered to be
> added. Bug fixing should be able to be pushed easily; only a commit message
> describing what the bug actually is, and how the fix is done should be
> necessary.

I don't think we are suggesting that.

I think we are probably looking at worst case switching the integration
tests repo from CTR to RTC

Though personally I think that is a bit too much. I think adding new

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03




Le 30/12/2016 à 09:01, Robert Scholte a écrit :
On Thu, 29 Dec 2016 18:57:56 +0100, Hervé BOUTEMY 
 wrote:



perhaps maven-resolver will require same reset


+1

IMO we forgot to do a release with the original Aether code with the 
new GAVs.


Robert



and we'll need to define which convention to use on Jira when merging 
code:
remove "Fix Version: 3.4.0" for example, to track what features have 
not been

merged yet

Regards,

Hervé

Le jeudi 29 décembre 2016, 11:18:59 CET Stephen Connolly a écrit :
On ASF infra, our master branch is supposed to be a protected branch 
and

thus cannot be reset or force-pushed without an INFRA ticket.

If we want to reset our master branch in order to clean out the 
history of
the many changes and reverts to and fro etc, we thus need an INFRA 
ticket

raised.

INFRA should not act on such a ticket without the results of a vote 
of the

committers that has at least three binding votes from the PMC (i.e. the
majority of votes cast must be in favour and at least three PMC members
must have voted in favour)

Votes are a great way to *confirm* consensus, but a horrible way to 
build a
community or establish consensus. We should only ever have a vote 
thread

once the consensus seems to be established.

To establish consensus we use a discuss thread.

Please refrain from assigning blame, we want to grow our community not
shrink it. The shorty endorphin rush you get from assigning blame or
performing The Dance Of I Told You So™ will require repeated hits to
maintain which will only lead to a more toxic community.

We have not been good at maintaining our CI infrastructure:

* As a consequence, some people have been developing on master 
rather than
on branches in order to ensure that their development gets the 
benefit of

the integration tests

* This has lead to a lot of micro commits and effectively revert 
commits on

master making it hard to track what actually has changed and what has
actually been fixed.

* Additionally `git blame` probably now could end up confusing people
trying to understand the rationale for some changes

We have not been good at maintaining our Integration tests:

* As a consequence it has been hard to get our CI infrastructure 
working

effectively

* As a consequence, people have been forced to leverage a single 
branch for

CI testing

We have not been good at developing bigger changes in a branch

etc.

I could go on.

My belief is that confidence in 3.4.0 has been eroded.

I propose that we reset master back
to 737de43e392fc15a0ce366db98d70aa18b3f6c03, with an analogous reset of
master for the integration tests, and then immediately commit a dummy
commit so that nobody accidentally does a fast-forward push.

Then we can cherry pick the changes that were on the old master that we
want to have in 3.4.0

This will probably also involve:

* Fixing the CI infrastructure (I favour using a pipeline multibranch
project so that branch development is easier,
https://builds.apache.org/job/maven-jenkinsfile/ is where I have been
trying to prototype this... currently failing because "windows")

* Switching to a culture of branch / PR development for all committers

* Better providing rationale for changes, e.g. we need a succinct
description of the actual regression between 2.x and 3.x in 
resolution of

dependencies of plugins as well as actual easy to understand tests that
demonstrate the behaviour *and* show that it is an actual regression

* etc

But the first step in that would be to reset master...

So...

Is 737de43e392fc15a0ce366db98d70aa18b3f6c03 the correct hash to 
reset to?


What is the correct hash for the integration tests?

Do we want to do this?

What else should we change about our processes to prevent the need 
to do

this again?


Having a vote on all changes to master sounds too much. I think it 
should be up to the developers to always raise discussions whenever a 
change would have impacts on existing ITs, or whenever a new feature is 
considered to be added. Bug fixing should be able to be pushed easily; 
only a commit message describing what the bug actually is, and how the 
fix is done should be necessary.


Commits should, as much as possible, represent a whole unit. That is, if 
it wouldn't make sense to revert to a given revision (because it 
represents some temporary dev state, or incomplete state), then probably 
that revision shouldn't exist. Tests ran on Jenkins should be a 
last-resort (or close to it) IMO: any change that is commited should be 
tested as passing, possibly on different OS (if the change looks like OS 
dependent) and different Maven versions for plugins (I personally test 
with 3.0.5, 3.3.9 and latest snapshot so that a wide range of versions 
are covered).




Should we maybe just drop 3.4.x and jump to 3.5.x also in order to 
signal
that this was a reboot version and any 3.4.x stuff is thus easy to 
detect

and filter?


What exactly would this scenario imply? If it is skipping

Re: [VOTE] Releasing Wagon 2.11

Do you think I can add a dummy log before the creation of the test file 
(and add the timestamps to the logs of wagon-http), to see how much time 
it takes on the Windows Server 2012? I'd like to see the breakdown of 
what takes time on the Jenkins machine, perhaps there is nothing we can 
do better (except increase the timeout to 500 or so...).


Guillaume


Le 30/12/2016 à 22:46, Michael Osipov a écrit :

I just pushed another commit to the branch with your changes.
The job does not really work on Windows [1], it simply takes too long 
to complete on the Windows Server 2012.


[1] 
https://builds.apache.org/job/maven-wagon-jetty8-windows/2/org.apache.maven.wagon$wagon-http/console


Am 2016-12-29 um 19:10 schrieb Guillaume Boué:

I have a Toshiba SSHD (MQ02ABD100H). I think the issue is that the Java
code should create a sparse file to have things faster. Using setLength
on a random access file probably does it depending on the OS and type of
drive, but it isn't creating one in my situation.

When run on Ubuntu, creating the test file is done practically instantly
whereas it takes 60 seconds on my Windows machine. Downloading takes
around 30 seconds in Ubuntu, whereas it takes 150 seconds in Windows.

I changed the method creating the test file (makeHugeFile) to:

if ( Os.isFamily( Os.FAMILY_WINDOWS ) )
{
Process p = new ProcessBuilder( "fsutil", "file",
"createnew", hugeFile.getAbsolutePath(),
String.valueOf(
HUGE_FILE_SIZE ) ).start();
p.waitFor();
}
else
{
RandomAccessFile ra = new RandomAccessFile(
hugeFile.getPath(), "rw" );
ra.setLength( HUGE_FILE_SIZE + 1 );
ra.seek( HUGE_FILE_SIZE );
ra.write( 1 );
ra.close();
}

This matches with the timings I get on Ubuntu (both for the creation of
the file, and the downloading via Wagon). I ran the build several times
with this change without any timeout issues. Can you test this change on
your side?

Side-note: I added "ra.close();" in the code above, because the random
access file wasn't closed otherwise, and then the file wasn't getting
deleted properly.

Guillaume

Le 29/12/2016 à 15:50, Michael Osipov a écrit :

Am 2016-12-29 um 12:24 schrieb Guillaume Boué:
I ran them at least 10 times, and there was the timeout issue each 
time.

Yes, the timeout is Surefire waiting for the forked VM. I applied the
patch (I had done similar tries also) but I still have the issue on
Windows 10.

You'll find the logs attached. It seems that the download is really
advancing (inside target, I can see the file hugetxt slowly
growing), but is just taking a long time. Additionally, the test class
HugeFileDownloadTest is composed of 2 tests, downloading the same 
file 2
times with different parameters: from the logs, it seems one of 
them is

succeeding (taking 140 seconds of the 400 in total), and then it times
out performing the second.

Also, part of the issue is probably with the time it takes to 
create the

4 Go test file that is later downloaded through Wagon (maybe it should
be done by calling the fsutil command when the test runs on Windows).
I'll try to do more timings when running the tests with Ubuntu and see
where the difference is.


Thanks for the analysis. I think the cheapest improvement we can do is
to create the file only once (setUp(), tearDown(). It is created for
each test again. I do not think that this is really necessary.

What type of disks do you have? This test passes on my machine within
70 seconds on a Samsung SSD.

I will apply the patch to the branch because those fixes are necessary
anyway.

Please keep me updated.

Michael


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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
https://www.avast.com/antivirus


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






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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

OT: how you can have a release with a majority of the PMC voting -1

1. The reasons for voting -1 must not relate to the responsibility
delegated by the board to the PMC with respect to the requirements of a
release

2. The majority of votes cast by committers + PMC must be in favour of the
release

3. At least 3 +1 votes from PMC members

4. A PMC member willing to stand up and perform the release finalisation
steps

5. The release manager declaring the vote as passed

Practically if the majority of the PMC is against the release on non-legal
grounds but the majority of the committers is in favour it would signal a
major crack in the *community* which would probably result in the board
getting involved if left festering. Also the release manager would probably
decide to cancel the vote where there is a significant minority against the
release... so it is highly unlikely that such a release would happen... but
it *could*!

On Sat 31 Dec 2016 at 08:58, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> You have misunderstood the Apache way, imho
>
> Votes are only to *confirm* consensus... and the consensus is of the
> *community* (ie everyone on the dev list who steps up to comment)
>
> When it comes to code changes, committers have a veto and the permission
> to commit, so no code changes can happen without the approval of interested
> committers.
>
> When it comes to releases, the PMC has been delegated certain legal
> responsibilities by the board, so you cannot have a release without 3x +1
> by the PMC (technically doesn't matter how much of the PMC votes -1 as long
> as the majority of votes cast by committers + PMC > 0 and you have at least
> 3x +1 by PMC members... but a release manager doing so could be frowned on)
>
>
> On Sat 31 Dec 2016 at 02:37, Christian Schulte  wrote:
>
> Am 12/31/16 um 03:27 schrieb Christian Schulte:
>
> > Am 12/29/16 um 13:49 schrieb Robert Scholte:
>
> >> My worries are more about: how to manage which issues should be cherry
>
> >> picked and who decides that list. Otherwise we might end up in the same
>
> >> situation. E.g. do we have to do a vote on the branch (which might cover
>
> >> multiple issues but which are related to the same topic) to decide if it
>
> >> can be merged with the master?
>
> >
>
> > This is what I have in mind. I know my commits. What I would do as soon
>
> > as master has been reset would be to squash my commits as much as
>
> > possible and then cast a vote on specific issues (for each single commit
>
> > to be merged into master) with the exception that no response means +1.
>
> > So instead of the whole PMC needing to agree, not responding means "+1".
>
> > That also would mean that if e.g. two PMC members vote -1, all others
>
> > implicitly have voted +1 if they did not respond otherwise. WDYT?
>
> >
>
>
>
> Adding to this: I do not have a deep understanding of the Apache way of
>
> things. Personally, I do not get the point why the users of the software
>
> cannot take part in any of those decisions. I just may not get the
>
> point, of course. Citizens are asked to vote on election day, for
>
> example. Here it's like a dictatorship of those with the power to do so
>
> deciding the future of all others. Don't get me wrong on this please.
>
> English is not my native language and I may not have found the proper
>
> words here.
>
>
>
>
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> --
> Sent from my phone
>
-- 
Sent from my phone

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

You have misunderstood the Apache way, imho

Votes are only to *confirm* consensus... and the consensus is of the
*community* (ie everyone on the dev list who steps up to comment)

When it comes to code changes, committers have a veto and the permission to
commit, so no code changes can happen without the approval of interested
committers.

When it comes to releases, the PMC has been delegated certain legal
responsibilities by the board, so you cannot have a release without 3x +1
by the PMC (technically doesn't matter how much of the PMC votes -1 as long
as the majority of votes cast by committers + PMC > 0 and you have at least
3x +1 by PMC members... but a release manager doing so could be frowned on)


On Sat 31 Dec 2016 at 02:37, Christian Schulte  wrote:

> Am 12/31/16 um 03:27 schrieb Christian Schulte:
>
> > Am 12/29/16 um 13:49 schrieb Robert Scholte:
>
> >> My worries are more about: how to manage which issues should be cherry
>
> >> picked and who decides that list. Otherwise we might end up in the same
>
> >> situation. E.g. do we have to do a vote on the branch (which might cover
>
> >> multiple issues but which are related to the same topic) to decide if it
>
> >> can be merged with the master?
>
> >
>
> > This is what I have in mind. I know my commits. What I would do as soon
>
> > as master has been reset would be to squash my commits as much as
>
> > possible and then cast a vote on specific issues (for each single commit
>
> > to be merged into master) with the exception that no response means +1.
>
> > So instead of the whole PMC needing to agree, not responding means "+1".
>
> > That also would mean that if e.g. two PMC members vote -1, all others
>
> > implicitly have voted +1 if they did not respond otherwise. WDYT?
>
> >
>
>
>
> Adding to this: I do not have a deep understanding of the Apache way of
>
> things. Personally, I do not get the point why the users of the software
>
> cannot take part in any of those decisions. I just may not get the
>
> point, of course. Citizens are asked to vote on election day, for
>
> example. Here it's like a dictatorship of those with the power to do so
>
> deciding the future of all others. Don't get me wrong on this please.
>
> English is not my native language and I may not have found the proper
>
> words here.
>
>
>
>
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> --
Sent from my phone

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03