You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Robert Scholte <rf...@apache.org> on 2016/12/06 21:46:43 UTC
Re: Maven 3.4.0 Release
Hi,
what is the status on this? Can we expect a release this year?
I think the open issues are:
is maven-resolver ready to replace aether?
AFAIK some dependency management changes have been reverted, are all
others indeed bugfixes and safe to keep in this release?
Here are the current release notes:
Release Notes - Maven - Version 3.4.0
** Bug
* [MNG-4463] - Dependency management import should support version
ranges.
* [MNG-5359] - Declared execution in PluginMgmt gets bound to
lifecycle (regression)
* [MNG-5368] - UnsupportedOperationException thrown when version range
is not correct in dependencyManagement definitions
* [MNG-5387] - Add ability to replace an artifact in mid-build
* [MNG-5527] - Dependency management import should support relocations.
* [MNG-5538] - mvn start script causes cygwin warning
* [MNG-5567] - Zip files are not included in classpaths at all
* [MNG-5629] - ClosedChannelException from
DefaultUpdateCheckManager.read
* [MNG-5815] - "mvn.cmd" does not indicate failure properly when using
"&&"
* [MNG-5823] - mvnDebug doesn't work with M2_HOME with spaces -
missing quotes
* [MNG-5836] - logging config is overwritten by $M2_HOME/lib/ext/*.jar
* [MNG-5837] - Syntax error in bin/mvn on Solaris SPARC
* [MNG-5849] - maven can not be found when current directory is
drive/root at least on windows 7 64bit
* [MNG-5852] - "mvn" script invokes /bin/sh but requires /bin/bash
functions
* [MNG-5863] - default pom's release-profile should invoke source
plugin with goal "jar-no-fork" instead of "jar"
* [MNG-5868] - Adding serval times the same artifact via
MavenProjectHelper (attachArtifact) does not produce a failure
* [MNG-5935] - Optional true getting lost in managed dependencies when
transitive
* [MNG-5939] - Problem doing release when sources are generate as well
* [MNG-5958] - java.lang.String cannot be cast to
org.apache.maven.lifecycle.mapping.LifecyclePhase
* [MNG-5961] - Maven possibly not aware of log4j2
* [MNG-5962] - mvn fails when the current directory has spaces in
between
* [MNG-5963] - mvn.cmd does not return ERROR_CODE
* [MNG-5971] - Imported dependencies should be available to
inheritance processing
* [MNG-5981] - Plexus lifecycle could be activated too late during
overlapping parallel requests
* [MNG-5984] - Maven core extension resolution ignores repositories
from activeByDefault profiles in settings.xml
* [MNG-6022] - mvn.cmd fails if directory contains an ampersand (&)
* [MNG-6029] - Duplicate conditional and body in
MetadataResolutionResult.java
* [MNG-6041] - Option -l does not disable colorized output
* [MNG-6043] - Colorization is disabled too late in batch mode
* [MNG-6053] - Unsafe System Properties copy in
MavenRepositorySystemUtils, causing NPEs
* [MNG-6057] - Problem with CI friendly usage of ${..} reactor order
is changed
* [MNG-6079] - 3.4 regression: cannot override version of a
dependencyManagement in a submodule any more
* [MNG-6109] - PluginDescriptor doesn't read since value of parameter
* [MNG-6112] - Central repository in the 4.0.0 super POM should
declare update policy 'never'.
* [MNG-6114] - Elements from the global settings should be ordered
before elements from the user settings.
* [MNG-6117] - ${session.parallel} not correctly set
* [MNG-6127] - Fix plugin execution configuration interference
** Dependency upgrade
* [MNG-5967] - Dependency updates.
* [MNG-6110] - Upgrade Aether to Maven Resolver 1.2
** Improvement
* [MNG-4508] - No way to avoid adding artifactId to site urls
* [MNG-5457] - Show repository id when downloading or uploading
from/to a remote repository
* [MNG-5579] - Unify error output/check logic from shell and batch
scripts
* [MNG-5600] - Dependency management import should support exclusions.
* [MNG-5607] - Don't use M2_HOME in mvn shell/command scripts anymore
* [MNG-5883] - Silence unnecessary legacy local repository warning
* [MNG-5889] - .mvn directory should be picked when using --file
* [MNG-5896] - Download dependency POMs in parallel
* [MNG-5904] - Remove the whole Ant Build
* [MNG-5931] - Fixing documentation
* [MNG-5934] - String handling issues identified by PMD
* [MNG-5940] - Change the maven-source-plugin jar goal into
jar-no-fork in Maven Super POM
* [MNG-5946] - Fix links etc. in README.txt which is part of the
delivery
* [MNG-5951] - add an option to avoid path addition to inherited URLs
* [MNG-5968] - Default plugin version updates.
* [MNG-5975] - Use Java 7's SimpleDateFormat in
CLIReportingUtils#formatTimestamp
* [MNG-5977] - Improve output readability of our MavenTransferListener
implementations
* [MNG-5992] - Git passwords are exposed as the Super POM still uses
Maven Release Plugin 2.3.2
* [MNG-5993] - Confusing error message in case of missing/empty
artifactId and version in pluginManagement
* [MNG-6001] - Replace %HOME% with %USERPROFILE% in mvn.cmd
* [MNG-6003] - Drastically reduce JAVA_HOME discovery code
* [MNG-6014] - Removing ArtifactHandler for ejb3
* [MNG-6017] - Removing ArtifactHandler for par LifeCycle
* [MNG-6030] - ReactorModelCache do not used effectively after maven
version 3.0.5 which cause a large memory footprint
* [MNG-6032] - WARNING during build based on absolute path in
assembly-descriptor.
* [MNG-6035] - Upgrade animal-sniffer-maven-plugin to 1.15
* [MNG-6046] - upgrade JAnsi from 1.12 to 1.13
* [MNG-6049] - Add behavior to filter resolved version ranges of an
artifact
* [MNG-6059] - Important use cases not covered, as
child.inherit.append.path affects all children
* [MNG-6068] - Document default scope compile in XSD
* [MNG-6074] - Maven should produce an error if no model version has
been set in a POM file used to build an effective model.
* [MNG-6078] - Can't overwrite properties which have been defined in
.mvn/maven.config
* [MNG-6081] - Log refactoring - Method Invocation Replaced By Variable
* [MNG-6102] - Introduce ${maven.conf} in m2.conf
* [MNG-6115] - Add Jansi native library search path to our start
scripts
** New Feature
* [MNG-2478] - add "resources-filtered" filtered resource directories
to super POM
* [MNG-3507] - ANSI Color logging for improved output visibility.
* [MNG-5227] - Make 'optional' flag of a dependency manageable.
* [MNG-5878] - add support for module name != artifactId in every
calculated URLs (project, SCM, site): special project.directory property
* [MNG-6037] - add gossip slf4j provider support
* [MNG-6073] - Addition of a core extension point to the model builder
supporting model finalization.
* [MNG-6084] - Support JSR250 annotations
* [MNG-6093] - create a slf4j-simple provider extension that supports
level color rendering
** Task
* [MNG-5954] - Remove outdated
maven-embedder/src/main/resources/META-INF/MANIFEST.MF
* [MNG-6054] - Removal of super pom plugin management.
* [MNG-6075] - Increase the model validation level to the next minor
level version.
* [MNG-6096] - Deprecate DefaultArtifactVersion class
* [MNG-6106] - Remove maven.home setter from m2.conf
** Wish
* [MNG-2199] - Support version ranges in parent elements
* [MNG-6088] - after forked execution success, add an empty line
* [MNG-6092] - warn if prerequisites.maven is used for non-plugin
projects
* [MNG-6113] - Rename the 'Central Repository' to 'Maven Central
Repository' in the 4.0.0 super POM.
On Sun, 09 Oct 2016 13:58:29 +0200, Karl Heinz Marbaise
<kh...@gmx.de> wrote:
> Hi to all,
>
> I would like to know what prevents us currently from releasing Maven
> 3.4.0 ?
>
> Kind regards
> Karl Heinz Marbaise
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Michael Osipov <mi...@apache.org>.
Am 2016-12-10 um 13:39 schrieb Hervé BOUTEMY:
> I just tested the patch associated to MNG-6110 - Upgrade Aether to Maven
> Resolver 1.2, and it caused one failure in ITs
> testit(org.apache.maven.it.MavenITmng4721OptionalPluginDependencyTest) Time
> elapsed: 0.185 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
>
> Is it only me?
> Fixing MNG-6110 is the first step before doing more changes, IMHO
I will try later this day. This may be related to changes in resolution
by Christian.
Michael
> Le vendredi 9 décembre 2016, 11:56:01 CET Michael Osipov a écrit :
>> Am 2016-12-06 um 22:46 schrieb Robert Scholte:
>>> Hi,
>>>
>>> what is the status on this? Can we expect a release this year?
>>>
>>> I think the open issues are:
>>> is maven-resolver ready to replace aether?
>>> AFAIK some dependency management changes have been reverted, are all
>>> others indeed bugfixes and safe to keep in this release?
>>
>> There is basically Resolver left, one good improvement is MNG-5896 along
>> with the PR, but I cannot review it since I am not really familiar with
>> the Resolver code. If someone is able to review MRESOLVER-7, please do
>> and merge it. We could go on with Resolver 1.2 and continue with Maven
>> 3.4 release.
>>
>> Michael
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Christian Schulte <cs...@schulte.it>.
Corrected IT in this commit.
<https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=c3f03ac53f96c44f8272c8aa6ba27cdbbdb01395>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/14/16 um 01:05 schrieb Christian Schulte:
> That a direct optional dependency
That should read: That a transitive optional dependency...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/12/16 um 00:51 schrieb Igor Fedorenko:
> I'm traveling until next weekend and won't be able to review your changes
> properly until I'm back. I do want to stress that maven plugins are not
> dependencies, they are resolved the same way as projects.
Coming back to this. Currently plugins are resolved the same way as
dependencies. That a direct optional dependency was part of the
resolution result has been a bug in the resolver. Should I update the
core to really resolve plugins the same way as POMs? The easy part of
this would be this change:
+++
b/maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginDependenciesResolver.java
@@ -182,7 +182,7 @@ private DependencyNode resolveInternal( Plugin
plugin, Artifact pluginArtifact,
CollectRequest request = new CollectRequest();
request.setRequestContext( REPOSITORY_CONTEXT );
request.setRepositories( repositories );
- request.setRoot( new org.eclipse.aether.graph.Dependency(
pluginArtifact, null ) );
+ request.setRootArtifact( pluginArtifact );
for ( Dependency dependency : plugin.getDependencies() )
{
org.eclipse.aether.graph.Dependency pluginDep =
In addition, the plugin POM needs to be resolved in that class as well
and all dependencies from that POM would need to be added to the collect
request. That would make Maven resolve plugins the same way it resolves
projects. Yes or no?
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/17/16 um 05:17 schrieb Christian Schulte:
> Am 12/12/16 um 00:51 schrieb Igor Fedorenko:
>> I'm traveling until next weekend and won't be able to review your changes
>> properly until I'm back. I do want to stress that maven plugins are not
>> dependencies, they are resolved the same way as projects.
>
> Master does it that way now. I may need to revert an update to an IT
> tomorrow. Let's see. Please note that direct 'test' and 'provided'
> dependencies of a plugin are now resolved and can lead to different
> resolution results as before where they have not been resolved. So the
> conflict resolver sees them now and may decide differently. The issues I
> ran into this were all bugs in plugin POMs. Someone added 'commons-lang'
> as a 'test' dependency to a plugin although that dependency was a
> transitive dependency in 'compile' scope already, for example. That
> 'commons-lang' will now disappear completely from the plugin's classpath
> because it will be resolved (nearest wins) and then later get filtered
> out. You may need to tun Maven with -X and diff the resolution trees
> from the debug messages when running into problems.
>
I solved things like this like: Remove all 'test' and 'provided'
dependencies from a plugin's POM so they do not override any transitive
dependency from another scope and then verify no transitive dependency
gets resolved which was in the POM before.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/12/16 um 00:51 schrieb Igor Fedorenko:
> I'm traveling until next weekend and won't be able to review your changes
> properly until I'm back. I do want to stress that maven plugins are not
> dependencies, they are resolved the same way as projects.
Master does it that way now. I may need to revert an update to an IT
tomorrow. Let's see. Please note that direct 'test' and 'provided'
dependencies of a plugin are now resolved and can lead to different
resolution results as before where they have not been resolved. So the
conflict resolver sees them now and may decide differently. The issues I
ran into this were all bugs in plugin POMs. Someone added 'commons-lang'
as a 'test' dependency to a plugin although that dependency was a
transitive dependency in 'compile' scope already, for example. That
'commons-lang' will now disappear completely from the plugin's classpath
because it will be resolved (nearest wins) and then later get filtered
out. You may need to tun Maven with -X and diff the resolution trees
from the debug messages when running into problems.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/12/16 um 00:51 schrieb Igor Fedorenko:
> I'm traveling until next weekend and won't be able to review your changes
> properly until I'm back. I do want to stress that maven plugins are not
> dependencies, they are resolved the same way as projects.
Yes. I agree to that. It's not implemented that way in the core.
Currently they are resolved the same way as dependencies :-o . So the
core needs updating to resolve plugins the same way as projects (POMs).
If we agree to this, I'll change it.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Igor Fedorenko <ig...@ifedorenko.com>.
I'm traveling until next weekend and won't be able to review your changes
properly until I'm back. I do want to stress that maven plugins are not
dependencies, they are resolved the same way as projects.
--
Regards,
Igor
On December 11, 2016 1:59:39 PM Christian Schulte <cs...@schulte.it> wrote:
> Am 12/11/16 um 03:29 schrieb Igor Fedorenko:
>> Why do you say Dependency A is transitive? Maven plugin directly depends
>> on Dependency A, so I expect it to be present on the plugin classpath.
>> This is consistent with how project direct optional dependencies are
>> always present on classpath.
>
> Yes. That's the POM resolution case. The plugin resolution is performed
> exactly the same way dependency resolution is performed. See below. If
> what you say is the intented behaviour (plugins need to be resolved the
> same way as POMs) then the core needs to be updated to actually perform
> the resolution that way. I am glad you are coming up with this.
>
>>
>> Note that the project does not *depend* on the plugin. From dependency
>> resolution point of view, the plugin is standalone "top-level" entity at
>> the same level as the project.
>>
>
> That means plugins need to be resolved the same way as POMs. And that
> means direct 'test', 'provided' and 'optional' dependencies need to be
> resolved as well. Last time I updated the core to do exactly that, it
> lead to issues like:
>
> <https://issues.apache.org/jira/browse/MPLUGIN-296>
>
>
> Currently only 'optional' direct dependencies are resolved. And that is
> due to a bug.
>
> <https://issues.apache.org/jira/browse/MRESOLVER-8>
>
> Easy to spot. I'll revert the changes to 'ScopeDependencySelector' and
> 'OptionalDependencySelector' in a few hours locally and the tests in
> 'DefaultDependencyCollectorTest' need to still pass. If one of the tests
> starts failing, the fix to MRESOLVER-8 is correct. There is no reason
> for the two classes to behave differently. The 'ScopeDependencySelector'
> handles the POM resolution vs. dependency resolution case correctly but
> differently to the 'OptionalDependencySelector'. That can't be correct.
> There is no way to handle plugin resolution differently than dependency
> resolution. So either 'OptionalDependencySelector' behaves incorrectly
> for dependency resolution of incorrectly for plugin resolution.
>
> Maybe we'll need to update classes 'ScopeDependencySelector' and
> 'OptionalDependencySelector' to make the mode of operation (transitive
> vs. direct) a property we can set from the core to make plugin
> resolution behave the same way it did before the fix (filtering out
> direct 'test' and 'provided' dependencies but not direct 'optional'
> dependencies to make that IT lacking any kind of meaningful - why? -
> description pass). Let's see.
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/11/16 um 03:29 schrieb Igor Fedorenko:
> Why do you say Dependency A is transitive? Maven plugin directly depends
> on Dependency A, so I expect it to be present on the plugin classpath.
> This is consistent with how project direct optional dependencies are
> always present on classpath.
Yes. That's the POM resolution case. The plugin resolution is performed
exactly the same way dependency resolution is performed. See below. If
what you say is the intented behaviour (plugins need to be resolved the
same way as POMs) then the core needs to be updated to actually perform
the resolution that way. I am glad you are coming up with this.
>
> Note that the project does not *depend* on the plugin. From dependency
> resolution point of view, the plugin is standalone "top-level" entity at
> the same level as the project.
>
That means plugins need to be resolved the same way as POMs. And that
means direct 'test', 'provided' and 'optional' dependencies need to be
resolved as well. Last time I updated the core to do exactly that, it
lead to issues like:
<https://issues.apache.org/jira/browse/MPLUGIN-296>
Currently only 'optional' direct dependencies are resolved. And that is
due to a bug.
<https://issues.apache.org/jira/browse/MRESOLVER-8>
Easy to spot. I'll revert the changes to 'ScopeDependencySelector' and
'OptionalDependencySelector' in a few hours locally and the tests in
'DefaultDependencyCollectorTest' need to still pass. If one of the tests
starts failing, the fix to MRESOLVER-8 is correct. There is no reason
for the two classes to behave differently. The 'ScopeDependencySelector'
handles the POM resolution vs. dependency resolution case correctly but
differently to the 'OptionalDependencySelector'. That can't be correct.
There is no way to handle plugin resolution differently than dependency
resolution. So either 'OptionalDependencySelector' behaves incorrectly
for dependency resolution of incorrectly for plugin resolution.
Maybe we'll need to update classes 'ScopeDependencySelector' and
'OptionalDependencySelector' to make the mode of operation (transitive
vs. direct) a property we can set from the core to make plugin
resolution behave the same way it did before the fix (filtering out
direct 'test' and 'provided' dependencies but not direct 'optional'
dependencies to make that IT lacking any kind of meaningful - why? -
description pass). Let's see.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Igor Fedorenko <ig...@ifedorenko.com>.
Why do you say Dependency A is transitive? Maven plugin directly depends
on Dependency A, so I expect it to be present on the plugin classpath.
This is consistent with how project direct optional dependencies are
always present on classpath.
Note that the project does not *depend* on the plugin. From dependency
resolution point of view, the plugin is standalone "top-level" entity at
the same level as the project.
--
Regards,
Igor
On Sat, Dec 10, 2016, at 06:26 PM, Christian Schulte wrote:
> Am 12/10/16 um 13:39 schrieb Hervé BOUTEMY:
> > I just tested the patch associated to MNG-6110 - Upgrade Aether to Maven
> > Resolver 1.2, and it caused one failure in ITs
> > testit(org.apache.maven.it.MavenITmng4721OptionalPluginDependencyTest) Time
> > elapsed: 0.185 sec <<< FAILURE!
> > junit.framework.AssertionFailedError: expected:<1> but was:<0>
> >
> > Is it only me?
>
> No. If you take a look at MNG-4721, it's not quite clear what that test
> case is testing. I verified the resolver is behaving correctly. That is
> - it correctly does not resolve any plugin dependency with optional set
> to 'true'. Here is the difference:
>
> Maven with the Resolver < 1.2.0:
>
> maven-plugin
> |-> optional dependency A
> |-> optional dependency B
>
> Dependency A will be resolved, although an optional transitive
> dependency. Dependency B will not be resolved and that is correct,
> because it also is an optional transitive dependency.
>
> Maven with the Resolver >= 1.2.0:
>
> maven-plugin
> |-> optional dependency A
> |-> optional dependency B
>
> Dependency A is no longer resolved because it is a transitive optional
> dependency. That's the bugfix due to MRESOLVER-8. That IT should just be
> updated to no longer run with Maven 3.4+ and a new one created running
> with 3.4+ testing the correct behaviour. It only affects optional plugin
> dependency resolution which isn't quite right in the resolver < 1.2.0.
> Will do that.
>
> > Fixing MNG-6110 is the first step before doing more changes, IMHO
>
> I've just committed this to master now.
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/10/16 um 13:39 schrieb Herv BOUTEMY:
> I just tested the patch associated to MNG-6110 - Upgrade Aether to Maven
> Resolver 1.2, and it caused one failure in ITs
> testit(org.apache.maven.it.MavenITmng4721OptionalPluginDependencyTest) Time
> elapsed: 0.185 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
>
> Is it only me?
No. If you take a look at MNG-4721, it's not quite clear what that test
case is testing. I verified the resolver is behaving correctly. That is
- it correctly does not resolve any plugin dependency with optional set
to 'true'. Here is the difference:
Maven with the Resolver < 1.2.0:
maven-plugin
|-> optional dependency A
|-> optional dependency B
Dependency A will be resolved, although an optional transitive
dependency. Dependency B will not be resolved and that is correct,
because it also is an optional transitive dependency.
Maven with the Resolver >= 1.2.0:
maven-plugin
|-> optional dependency A
|-> optional dependency B
Dependency A is no longer resolved because it is a transitive optional
dependency. That's the bugfix due to MRESOLVER-8. That IT should just be
updated to no longer run with Maven 3.4+ and a new one created running
with 3.4+ testing the correct behaviour. It only affects optional plugin
dependency resolution which isn't quite right in the resolver < 1.2.0.
Will do that.
> Fixing MNG-6110 is the first step before doing more changes, IMHO
I've just committed this to master now.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/12/16 um 22:55 schrieb Michael Osipov:
> Am 2016-12-12 um 02:48 schrieb Christian Schulte:
>> Am 12/11/16 um 22:56 schrieb Michael Osipov:
>>> I just ran ITs with current master, only one IT fails:
>>
>> Should be fixed now.
>
> Are you certain about this? I cannot confirm.
> 723b942ad10ab471dfbc5d81ed1071891573dc01 fixes MNG-5227 IT but the IT
> failing ist for MNG-4347.
>
Still looking into it. Does not seem to be an issue with maven core but
the resolver. Currently reviewing all commits since
<https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=commit;h=4cf5f7a406b516a45d8bf15e7dfe3fb3849cb87b>
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/12/16 um 22:55 schrieb Michael Osipov:
> Am 2016-12-12 um 02:48 schrieb Christian Schulte:
>> Am 12/11/16 um 22:56 schrieb Michael Osipov:
>>> I just ran ITs with current master, only one IT fails:
>>
>> Should be fixed now.
>
> Are you certain about this? I cannot confirm.
> 723b942ad10ab471dfbc5d81ed1071891573dc01 fixes MNG-5227 IT but the IT
> failing ist for MNG-4347.
>
It's a bug in the core introduced a few releases ago and uncovered now
due to the changes to the import scope. Not sure the 'ModelResolver'
really should replace 'externalRepositories'. Will take some time
solving that. At least I know what's causing this.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Michael Osipov <mi...@apache.org>.
Am 2016-12-12 um 02:48 schrieb Christian Schulte:
> Am 12/11/16 um 22:56 schrieb Michael Osipov:
>> I just ran ITs with current master, only one IT fails:
>
> Should be fixed now.
Are you certain about this? I cannot confirm.
723b942ad10ab471dfbc5d81ed1071891573dc01 fixes MNG-5227 IT but the IT
failing ist for MNG-4347.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/11/16 um 22:56 schrieb Michael Osipov:
> I just ran ITs with current master, only one IT fails:
Should be fixed now.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Christian Schulte <cs...@schulte.it>.
Thanks. Noticed this myself yesterday. Wanted to wait for Jenkins to
finish all pending jobs. Haven't expected any IT to fail. Will have a look.
Am 12/11/16 um 22:56 schrieb Michael Osipov:
> Am 2016-12-10 um 16:06 schrieb Christian Schulte:
>> If it's happening just due to the upgrade of the resolver, then it's a
>> resolver bugfix the IT hasn't been updated to reflect. I discussed this
>> issue with Jason in december last year when upgrading the resolver to
>> 1.1 needed to be reverted.
>>
>> <https://github.com/jvanzyl/aether-core/commit/da9708bf7321e25c2a74dddb893539f735135a6d>
>>
>> Also part of:
>>
>> <https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=commit;h=1ee92862c67ec98564c4d8be1207355960f1dd5d>
>>
>> This was lacking test cases badly. I am the author of the corresponding
>> test cases in the resolver. A few months later I had to correct those
>> tests to match the 1.0.x behaviour exactly.
>>
>> <https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=commit;h=5907bd44682925d8ea795fcb63c39d268157a632>
>>
>> That IT would need to be updated to no longer run with Maven 3.4+ and a
>> new one needs to be created in parallel running with 3.4+, IMHO. The
>> bugfix also has an impact on how 'test' scope dependencies are resolved.
>> In short: If the scope of a transitive dependency is managed to 'test'
>> that dependency will no longer be resolved as the test scope is not
>> transitive.
>
> I just ran ITs with current master, only one IT fails:
>
> -------------------------------------------------------------------------------
> Tests run: 797, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> 1,306.697 sec <<< FAILURE! - in org.apache.maven.it.IntegrationTestSuite
> testit(org.apache.maven.it.MavenITmng4347ImportScopeWithSettingsProfilesTest)
> Time elapsed: 1.174 sec <<< ERROR!
> org.apache.maven.it.VerificationException: Exit code was non-zero: 1;
> command line and log =
> D:\Entwicklung\Programme\apache-maven-3.4.0-SNAPSHOT\bin\..\bin\mvn
> --global-settings
> D:\Entwicklung\Projekte\maven-integration-testing\core-it-suite\target\test-classes\settings.xml
> -s settings.xml -e --batch-mode
> -Dmaven.repo.local=C:\Users\mosipov\.m2\repository validate
> [INFO] Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building consumer 1
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Downloading:
> file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-4347/remote-repository/org/apache/maven/it/mng4347/dep-with-import/1/dep-with-import-1.pom
> [INFO] Downloaded:
> file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-4347/remote-repository/org/apache/maven/it/mng4347/dep-with-import/1/dep-with-import-1.pom
> (1.7 kB at 109 kB/s)
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 0.181 s
> [INFO] Finished at: 2016-12-11T22:37:08+01:00
> [INFO] Final Memory: 8M/241M
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] Failed to execute goal on project consumer: Could not resolve
> dependencies for project org.apache.maven.it.mng4347:consumer:jar:1:
> Failed to collect dependencies at
> org.apache.maven.it.mng4347:dep-with-import:jar:1: Failed to read
> artifact descriptor for
> org.apache.maven.it.mng4347:dep-with-import:jar:1: Could not find
> artifact org.apache.maven.it.mng4347:import-dep:pom:1-SNAPSHOT -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal on project consumer: Could not resolve dependencies for
> project org.apache.maven.it.mng4347:consumer:jar:1: Failed to collect
> dependencies at org.apache.maven.it.mng4347:dep-with-import:jar:1
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:249)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:145)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:247)
> ...
> Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Could
> not find artifact org.apache.maven.it.mng4347:import-dep:pom:1-SNAPSHOT
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:412)
> ... 42 more
>
> Michael
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Michael Osipov <mi...@apache.org>.
Am 2016-12-10 um 16:06 schrieb Christian Schulte:
> If it's happening just due to the upgrade of the resolver, then it's a
> resolver bugfix the IT hasn't been updated to reflect. I discussed this
> issue with Jason in december last year when upgrading the resolver to
> 1.1 needed to be reverted.
>
> <https://github.com/jvanzyl/aether-core/commit/da9708bf7321e25c2a74dddb893539f735135a6d>
>
> Also part of:
>
> <https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=commit;h=1ee92862c67ec98564c4d8be1207355960f1dd5d>
>
> This was lacking test cases badly. I am the author of the corresponding
> test cases in the resolver. A few months later I had to correct those
> tests to match the 1.0.x behaviour exactly.
>
> <https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=commit;h=5907bd44682925d8ea795fcb63c39d268157a632>
>
> That IT would need to be updated to no longer run with Maven 3.4+ and a
> new one needs to be created in parallel running with 3.4+, IMHO. The
> bugfix also has an impact on how 'test' scope dependencies are resolved.
> In short: If the scope of a transitive dependency is managed to 'test'
> that dependency will no longer be resolved as the test scope is not
> transitive.
I just ran ITs with current master, only one IT fails:
-------------------------------------------------------------------------------
Tests run: 797, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
1,306.697 sec <<< FAILURE! - in org.apache.maven.it.IntegrationTestSuite
testit(org.apache.maven.it.MavenITmng4347ImportScopeWithSettingsProfilesTest)
Time elapsed: 1.174 sec <<< ERROR!
org.apache.maven.it.VerificationException: Exit code was non-zero: 1;
command line and log =
D:\Entwicklung\Programme\apache-maven-3.4.0-SNAPSHOT\bin\..\bin\mvn
--global-settings
D:\Entwicklung\Projekte\maven-integration-testing\core-it-suite\target\test-classes\settings.xml
-s settings.xml -e --batch-mode
-Dmaven.repo.local=C:\Users\mosipov\.m2\repository validate
[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO]
[INFO]
------------------------------------------------------------------------
[INFO] Building consumer 1
[INFO]
------------------------------------------------------------------------
[INFO] Downloading:
file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-4347/remote-repository/org/apache/maven/it/mng4347/dep-with-import/1/dep-with-import-1.pom
[INFO] Downloaded:
file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-4347/remote-repository/org/apache/maven/it/mng4347/dep-with-import/1/dep-with-import-1.pom
(1.7 kB at 109 kB/s)
[INFO]
------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 0.181 s
[INFO] Finished at: 2016-12-11T22:37:08+01:00
[INFO] Final Memory: 8M/241M
[INFO]
------------------------------------------------------------------------
[ERROR] Failed to execute goal on project consumer: Could not resolve
dependencies for project org.apache.maven.it.mng4347:consumer:jar:1:
Failed to collect dependencies at
org.apache.maven.it.mng4347:dep-with-import:jar:1: Failed to read
artifact descriptor for
org.apache.maven.it.mng4347:dep-with-import:jar:1: Could not find
artifact org.apache.maven.it.mng4347:import-dep:pom:1-SNAPSHOT -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal on project consumer: Could not resolve dependencies for
project org.apache.maven.it.mng4347:consumer:jar:1: Failed to collect
dependencies at org.apache.maven.it.mng4347:dep-with-import:jar:1
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:249)
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:145)
at
org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:247)
...
Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Could
not find artifact org.apache.maven.it.mng4347:import-dep:pom:1-SNAPSHOT
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:412)
... 42 more
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/10/16 um 17:48 schrieb Michael Osipov:
> Can you create a proper branch with fixed ITs? I'd like to run those.
> From my point of view, we can release Resolver 1.2 and roll an RC for
> Maven 3.4.
Let's just switch maven master to the resolver snapshot and continue
from there on. That branch is useless for anyone not having updated
maven core to use the resolver snapshot. I am not sure the IT would need
to be updated. As far as I recall maven core needs to be updated to
reflect MRESOLVER-8. That would take just a few minutes.
+1 for releasing resolver 1.2.
-1 for releasing an RC without the import scope feature sorted out. See
my other mail. That needs to be clarified. Updating the model builder to
reflect any decision is a matter of a few minutes work.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Michael Osipov <mi...@apache.org>.
Am 2016-12-10 um 16:06 schrieb Christian Schulte:
> If it's happening just due to the upgrade of the resolver, then it's a
> resolver bugfix the IT hasn't been updated to reflect. I discussed this
> issue with Jason in december last year when upgrading the resolver to
> 1.1 needed to be reverted.
>
> <https://github.com/jvanzyl/aether-core/commit/da9708bf7321e25c2a74dddb893539f735135a6d>
>
> Also part of:
>
> <https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=commit;h=1ee92862c67ec98564c4d8be1207355960f1dd5d>
>
> This was lacking test cases badly. I am the author of the corresponding
> test cases in the resolver. A few months later I had to correct those
> tests to match the 1.0.x behaviour exactly.
>
> <https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=commit;h=5907bd44682925d8ea795fcb63c39d268157a632>
>
> That IT would need to be updated to no longer run with Maven 3.4+ and a
> new one needs to be created in parallel running with 3.4+, IMHO. The
> bugfix also has an impact on how 'test' scope dependencies are resolved.
> In short: If the scope of a transitive dependency is managed to 'test'
> that dependency will no longer be resolved as the test scope is not
> transitive.
+1
Can you create a proper branch with fixed ITs? I'd like to run those.
From my point of view, we can release Resolver 1.2 and roll an RC for
Maven 3.4.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Christian Schulte <cs...@schulte.it>.
If it's happening just due to the upgrade of the resolver, then it's a
resolver bugfix the IT hasn't been updated to reflect. I discussed this
issue with Jason in december last year when upgrading the resolver to
1.1 needed to be reverted.
<https://github.com/jvanzyl/aether-core/commit/da9708bf7321e25c2a74dddb893539f735135a6d>
Also part of:
<https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=commit;h=1ee92862c67ec98564c4d8be1207355960f1dd5d>
This was lacking test cases badly. I am the author of the corresponding
test cases in the resolver. A few months later I had to correct those
tests to match the 1.0.x behaviour exactly.
<https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=commit;h=5907bd44682925d8ea795fcb63c39d268157a632>
That IT would need to be updated to no longer run with Maven 3.4+ and a
new one needs to be created in parallel running with 3.4+, IMHO. The
bugfix also has an impact on how 'test' scope dependencies are resolved.
In short: If the scope of a transitive dependency is managed to 'test'
that dependency will no longer be resolved as the test scope is not
transitive.
Am 10.12.2016 um 13:39 schrieb Herv BOUTEMY:
> I just tested the patch associated to MNG-6110 - Upgrade Aether to Maven
> Resolver 1.2, and it caused one failure in ITs
> testit(org.apache.maven.it.MavenITmng4721OptionalPluginDependencyTest) Time
> elapsed: 0.185 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
>
> Is it only me?
> Fixing MNG-6110 is the first step before doing more changes, IMHO
>
> Regards,
>
> Herv
>
> Le vendredi 9 dcembre 2016, 11:56:01 CET Michael Osipov a crit :
>> Am 2016-12-06 um 22:46 schrieb Robert Scholte:
>>> Hi,
>>>
>>> what is the status on this? Can we expect a release this year?
>>>
>>> I think the open issues are:
>>> is maven-resolver ready to replace aether?
>>> AFAIK some dependency management changes have been reverted, are all
>>> others indeed bugfixes and safe to keep in this release?
>>
>> There is basically Resolver left, one good improvement is MNG-5896 along
>> with the PR, but I cannot review it since I am not really familiar with
>> the Resolver code. If someone is able to review MRESOLVER-7, please do
>> and merge it. We could go on with Resolver 1.2 and continue with Maven
>> 3.4 release.
>>
>> Michael
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Christian Schulte <cs...@schulte.it>.
Wait. That maybe a different story. MRESOLVER-8.
<https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=commitdiff;h=5907bd44682925d8ea795fcb63c39d268157a632>
The changes to 'OptionalDependencySelector' made it behave the same way
the 'ScopeDependencySelector' and other selectors are implemented. It's
a bit sad there have not been any test cases for this. The test cases
are testing the correct 1.0.x behaviour. That selector needed fixing to
behave the same way as the other selectors. That's what you get when you
cannot finish a task you started to work on a year ago. Hard to remember
where to catch up after having left things WIP for a year. The plugin
repository session in core may need to be reviewed and maybe need to be
changed to no longer make use of that optional selector to get that IT
pass. Maybe it's time to switch core to the resolver now and let Jenkins
start doing it's job. I will look into that IT once the core is using
the resolver snapshot finally. Makes no sense for everyone having to
update the POMs locally.
Am 10.12.2016 um 13:39 schrieb Herv BOUTEMY:
> I just tested the patch associated to MNG-6110 - Upgrade Aether to Maven
> Resolver 1.2, and it caused one failure in ITs
> testit(org.apache.maven.it.MavenITmng4721OptionalPluginDependencyTest) Time
> elapsed: 0.185 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
>
> Is it only me?
> Fixing MNG-6110 is the first step before doing more changes, IMHO
>
> Regards,
>
> Herv
>
> Le vendredi 9 dcembre 2016, 11:56:01 CET Michael Osipov a crit :
>> Am 2016-12-06 um 22:46 schrieb Robert Scholte:
>>> Hi,
>>>
>>> what is the status on this? Can we expect a release this year?
>>>
>>> I think the open issues are:
>>> is maven-resolver ready to replace aether?
>>> AFAIK some dependency management changes have been reverted, are all
>>> others indeed bugfixes and safe to keep in this release?
>>
>> There is basically Resolver left, one good improvement is MNG-5896 along
>> with the PR, but I cannot review it since I am not really familiar with
>> the Resolver code. If someone is able to review MRESOLVER-7, please do
>> and merge it. We could go on with Resolver 1.2 and continue with Maven
>> 3.4 release.
>>
>> Michael
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Hervé BOUTEMY <he...@free.fr>.
I just tested the patch associated to MNG-6110 - Upgrade Aether to Maven
Resolver 1.2, and it caused one failure in ITs
testit(org.apache.maven.it.MavenITmng4721OptionalPluginDependencyTest) Time
elapsed: 0.185 sec <<< FAILURE!
junit.framework.AssertionFailedError: expected:<1> but was:<0>
Is it only me?
Fixing MNG-6110 is the first step before doing more changes, IMHO
Regards,
Hervé
Le vendredi 9 décembre 2016, 11:56:01 CET Michael Osipov a écrit :
> Am 2016-12-06 um 22:46 schrieb Robert Scholte:
> > Hi,
> >
> > what is the status on this? Can we expect a release this year?
> >
> > I think the open issues are:
> > is maven-resolver ready to replace aether?
> > AFAIK some dependency management changes have been reverted, are all
> > others indeed bugfixes and safe to keep in this release?
>
> There is basically Resolver left, one good improvement is MNG-5896 along
> with the PR, but I cannot review it since I am not really familiar with
> the Resolver code. If someone is able to review MRESOLVER-7, please do
> and merge it. We could go on with Resolver 1.2 and continue with Maven
> 3.4 release.
>
> Michael
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Michael Osipov <mi...@apache.org>.
Am 2016-12-06 um 22:46 schrieb Robert Scholte:
> Hi,
>
> what is the status on this? Can we expect a release this year?
>
> I think the open issues are:
> is maven-resolver ready to replace aether?
> AFAIK some dependency management changes have been reverted, are all
> others indeed bugfixes and safe to keep in this release?
There is basically Resolver left, one good improvement is MNG-5896 along
with the PR, but I cannot review it since I am not really familiar with
the Resolver code. If someone is able to review MRESOLVER-7, please do
and merge it. We could go on with Resolver 1.2 and continue with Maven
3.4 release.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Hervé BOUTEMY <he...@free.fr>.
+1 also
Regards,
Hervé
Le lundi 19 décembre 2016, 20:36:48 CET Robert Scholte a écrit :
> +100
>
> On Mon, 19 Dec 2016 20:12:33 +0100, Stephen Connolly
>
> <st...@gmail.com> wrote:
> > We need to get the project back in the habit of releasing.
> >
> > My vote is the we rebuild master with a clean history. keep current
> > master
> > as a reference branch, and cherry-pick as we go.
> >
> > The aim should be kept tight in scope and focus on the aether replacement
> > only. Minimum change for aether replacement.
> >
> > Then we can start bringing in bug fixes.
> >
> > If we need to break things, we can go 3.6.x or 4.x.y I only request that
> > 5.0.0 be reserved for the first release with a modelVersion 5.0.0 pom
> > (which is what my proposals are aiming to help us flesh out... though my
> > proposals may not be selected by committers in the end, hopefully they
> > will
> > allow us to have a reasoned debate)
> >
> > Wdyt?
> >
> > On Mon 19 Dec 2016 at 17:41, Robert Scholte <rf...@apache.org> wrote:
> >> We're already trying to push a new release for quite some time. And it
> >>
> >> seems the discussion is not over yet.
> >>
> >> There are a lot of improvements which deserve a release, so personally
> >> I'd
> >>
> >> like to push the discussion to 3.5.0
> >>
> >>
> >>
> >> Robert
> >>
> >>
> >>
> >> On Mon, 19 Dec 2016 14:12:25 +0100, Stephane Nicoll
> >>
> >> <st...@gmail.com> wrote:
> >> > Isn't that postponing the discussion we're having here on those
> >> >
> >> > controversial changes? I'd rather give it an extra effort rather than
> >> >
> >> > pushing it back and loosing all the context once we have to tackle
> >>
> >> 3.5.
> >>
> >> > On Sun, Dec 18, 2016 at 10:02 PM, Stephen Connolly <
> >> >
> >> > stephen.alan.connolly@gmail.com> wrote:
> >> >> I like that plan, but let's call that 3.4.0 and let these other
> >>
> >> changes
> >>
> >> >> go
> >> >>
> >> >> for either 3.5.0
> >> >>
> >> >>
> >> >>
> >> >> Does someone want to take a stab at forking master from an earlier
> >>
> >> point
> >>
> >> >> (perhaps get infra to let us rewrite master back to the fork point
> >>
> >> and
> >>
> >> >> push
> >> >>
> >> >> the current state to a branch?)
> >> >>
> >> >>
> >> >>
> >> >> On Sun 18 Dec 2016 at 19:45, Igor Fedorenko <ig...@ifedorenko.com>
> >>
> >> wrote:
> >> >> > No, I meant just eclipse->apache move, not all changes that went
> >>
> >> into
> >>
> >> >> > maven-resolver. The idea is to have a release branch we can
> >>
> >> maintain
> >>
> >> >> > while things stabilize in master.
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> >
> >> >> >
> >> >> >
> >> >> > Regards,
> >> >> >
> >> >> >
> >> >> >
> >> >> > Igor
> >> >> >
> >> >> > On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
> >> >> > > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
> >> >> > > > I wonder if it makes sense to release 3.3.10 with just the new
> >> >>
> >> >> aether
> >> >>
> >> >> > > > and give 3.4 more time to bake on master.
> >> >> > >
> >> >> > > Changing a dependency with so many changes recently in a fix
> >> >>
> >> >> version?
> >> >>
> >> >> > > Doesn't sound right to me.
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > > M
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >>
> >> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > > For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >> ---------------------------------------------------------------------
> >>
> >> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> >
> >> >> >
> >> >> >
> >> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >>
> >> >> Sent from my phone
> >>
> >> ---------------------------------------------------------------------
> >>
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >>
> >> --
> >
> > Sent from my phone
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Manfred Moser <ma...@simpligility.com>.
Sure... but as close to be ready to release as possible. At a minimum passing ITs...
Gary Gregory wrote on 2016-12-19 11:39:
> On Mon, Dec 19, 2016 at 11:24 AM, Manfred Moser <ma...@simpligility.com>
> wrote:
>
>> Totally agree. Master should be ready to release all the time imho.
>> Nothing that isnt tested well and proven to at least pass all IT's should
>> be merged into master. Experimentation should happen in feature branches..
>>
>
> I think it's OK to have a master branch that is not ready to release at a
> moment's notice but it MUST be the case that all tests pass all the time.
>
> Gary
>
>
>>
>> Just my 2c.
>>
>> Manfred
>>
>> Stephen Connolly wrote on 2016-12-19 11:12:
>>
>> > We need to get the project back in the habit of releasing.
>> >
>> > My vote is the we rebuild master with a clean history. keep current
>> master
>> > as a reference branch, and cherry-pick as we go.
>> >
>> > The aim should be kept tight in scope and focus on the aether replacement
>> > only. Minimum change for aether replacement.
>> >
>> > Then we can start bringing in bug fixes.
>> >
>> > If we need to break things, we can go 3.6.x or 4.x.y I only request that
>> > 5.0.0 be reserved for the first release with a modelVersion 5.0.0 pom
>> > (which is what my proposals are aiming to help us flesh out... though my
>> > proposals may not be selected by committers in the end, hopefully they
>> will
>> > allow us to have a reasoned debate)
>> >
>> > Wdyt?
>> >
>> > On Mon 19 Dec 2016 at 17:41, Robert Scholte <rf...@apache.org>
>> wrote:
>> >
>> >> We're already trying to push a new release for quite some time. And it
>> >>
>> >> seems the discussion is not over yet.
>> >>
>> >> There are a lot of improvements which deserve a release, so personally
>> I'd
>> >>
>> >> like to push the discussion to 3.5.0
>> >>
>> >>
>> >>
>> >> Robert
>> >>
>> >>
>> >>
>> >> On Mon, 19 Dec 2016 14:12:25 +0100, Stephane Nicoll
>> >>
>> >> <st...@gmail.com> wrote:
>> >>
>> >>
>> >>
>> >> > Isn't that postponing the discussion we're having here on those
>> >>
>> >> > controversial changes? I'd rather give it an extra effort rather than
>> >>
>> >> > pushing it back and loosing all the context once we have to tackle
>> 3.5.
>> >>
>> >> >
>> >>
>> >> > On Sun, Dec 18, 2016 at 10:02 PM, Stephen Connolly <
>> >>
>> >> > stephen.alan.connolly@gmail.com> wrote:
>> >>
>> >> >
>> >>
>> >> >> I like that plan, but let's call that 3.4.0 and let these other
>> changes
>> >>
>> >> >> go
>> >>
>> >> >> for either 3.5.0
>> >>
>> >> >>
>> >>
>> >> >> Does someone want to take a stab at forking master from an earlier
>> point
>> >>
>> >> >> (perhaps get infra to let us rewrite master back to the fork point
>> and
>> >>
>> >> >> push
>> >>
>> >> >> the current state to a branch?)
>> >>
>> >> >>
>> >>
>> >> >> On Sun 18 Dec 2016 at 19:45, Igor Fedorenko <ig...@ifedorenko.com>
>> >> wrote:
>> >>
>> >> >>
>> >>
>> >> >> > No, I meant just eclipse->apache move, not all changes that went
>> into
>> >>
>> >> >> >
>> >>
>> >> >> > maven-resolver. The idea is to have a release branch we can
>> maintain
>> >>
>> >> >> >
>> >>
>> >> >> > while things stabilize in master.
>> >>
>> >> >> >
>> >>
>> >> >> >
>> >>
>> >> >> >
>> >>
>> >> >> > --
>> >>
>> >> >> >
>> >>
>> >> >> > Regards,
>> >>
>> >> >> >
>> >>
>> >> >> > Igor
>> >>
>> >> >> >
>> >>
>> >> >> >
>> >>
>> >> >> >
>> >>
>> >> >> > On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
>> >>
>> >> >> >
>> >>
>> >> >> > > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
>> >>
>> >> >> >
>> >>
>> >> >> > > > I wonder if it makes sense to release 3.3.10 with just the new
>> >>
>> >> >> aether
>> >>
>> >> >> >
>> >>
>> >> >> > > > and give 3.4 more time to bake on master.
>> >>
>> >> >> >
>> >>
>> >> >> > >
>> >>
>> >> >> >
>> >>
>> >> >> > > Changing a dependency with so many changes recently in a fix
>> >>
>> >> >> version?
>> >>
>> >> >> >
>> >>
>> >> >> > > Doesn't sound right to me.
>> >>
>> >> >> >
>> >>
>> >> >> > >
>> >>
>> >> >> >
>> >>
>> >> >> > > M
>> >>
>> >> >> >
>> >>
>> >> >> > >
>> >>
>> >> >> >
>> >>
>> >> >> > >
>> >>
>> >> >> >
>> >>
>> >> >> > >
>> >>
>> >> >> ------------------------------------------------------------
>> ---------
>> >>
>> >> >> >
>> >>
>> >> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>
>> >> >> >
>> >>
>> >> >> > > For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >> >> >
>> >>
>> >> >> > >
>> >>
>> >> >> >
>> >>
>> >> >> >
>> >>
>> >> >> >
>> >>
>> >> >> > ------------------------------------------------------------
>> ---------
>> >>
>> >> >> >
>> >>
>> >> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>
>> >> >> >
>> >>
>> >> >> > For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >> >> >
>> >>
>> >> >> >
>> >>
>> >> >> >
>> >>
>> >> >> > --
>> >>
>> >> >> Sent from my phone
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >>
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >>
>> >>
>> >> --
>> > Sent from my phone
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
> JUnit in Action, Second Edition
> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
> Spring Batch in Action
> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Dec 19, 2016 at 11:24 AM, Manfred Moser <ma...@simpligility.com>
wrote:
> Totally agree. Master should be ready to release all the time imho.
> Nothing that isnt tested well and proven to at least pass all IT's should
> be merged into master. Experimentation should happen in feature branches..
>
I think it's OK to have a master branch that is not ready to release at a
moment's notice but it MUST be the case that all tests pass all the time.
Gary
>
> Just my 2c.
>
> Manfred
>
> Stephen Connolly wrote on 2016-12-19 11:12:
>
> > We need to get the project back in the habit of releasing.
> >
> > My vote is the we rebuild master with a clean history. keep current
> master
> > as a reference branch, and cherry-pick as we go.
> >
> > The aim should be kept tight in scope and focus on the aether replacement
> > only. Minimum change for aether replacement.
> >
> > Then we can start bringing in bug fixes.
> >
> > If we need to break things, we can go 3.6.x or 4.x.y I only request that
> > 5.0.0 be reserved for the first release with a modelVersion 5.0.0 pom
> > (which is what my proposals are aiming to help us flesh out... though my
> > proposals may not be selected by committers in the end, hopefully they
> will
> > allow us to have a reasoned debate)
> >
> > Wdyt?
> >
> > On Mon 19 Dec 2016 at 17:41, Robert Scholte <rf...@apache.org>
> wrote:
> >
> >> We're already trying to push a new release for quite some time. And it
> >>
> >> seems the discussion is not over yet.
> >>
> >> There are a lot of improvements which deserve a release, so personally
> I'd
> >>
> >> like to push the discussion to 3.5.0
> >>
> >>
> >>
> >> Robert
> >>
> >>
> >>
> >> On Mon, 19 Dec 2016 14:12:25 +0100, Stephane Nicoll
> >>
> >> <st...@gmail.com> wrote:
> >>
> >>
> >>
> >> > Isn't that postponing the discussion we're having here on those
> >>
> >> > controversial changes? I'd rather give it an extra effort rather than
> >>
> >> > pushing it back and loosing all the context once we have to tackle
> 3.5.
> >>
> >> >
> >>
> >> > On Sun, Dec 18, 2016 at 10:02 PM, Stephen Connolly <
> >>
> >> > stephen.alan.connolly@gmail.com> wrote:
> >>
> >> >
> >>
> >> >> I like that plan, but let's call that 3.4.0 and let these other
> changes
> >>
> >> >> go
> >>
> >> >> for either 3.5.0
> >>
> >> >>
> >>
> >> >> Does someone want to take a stab at forking master from an earlier
> point
> >>
> >> >> (perhaps get infra to let us rewrite master back to the fork point
> and
> >>
> >> >> push
> >>
> >> >> the current state to a branch?)
> >>
> >> >>
> >>
> >> >> On Sun 18 Dec 2016 at 19:45, Igor Fedorenko <ig...@ifedorenko.com>
> >> wrote:
> >>
> >> >>
> >>
> >> >> > No, I meant just eclipse->apache move, not all changes that went
> into
> >>
> >> >> >
> >>
> >> >> > maven-resolver. The idea is to have a release branch we can
> maintain
> >>
> >> >> >
> >>
> >> >> > while things stabilize in master.
> >>
> >> >> >
> >>
> >> >> >
> >>
> >> >> >
> >>
> >> >> > --
> >>
> >> >> >
> >>
> >> >> > Regards,
> >>
> >> >> >
> >>
> >> >> > Igor
> >>
> >> >> >
> >>
> >> >> >
> >>
> >> >> >
> >>
> >> >> > On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
> >>
> >> >> >
> >>
> >> >> > > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
> >>
> >> >> >
> >>
> >> >> > > > I wonder if it makes sense to release 3.3.10 with just the new
> >>
> >> >> aether
> >>
> >> >> >
> >>
> >> >> > > > and give 3.4 more time to bake on master.
> >>
> >> >> >
> >>
> >> >> > >
> >>
> >> >> >
> >>
> >> >> > > Changing a dependency with so many changes recently in a fix
> >>
> >> >> version?
> >>
> >> >> >
> >>
> >> >> > > Doesn't sound right to me.
> >>
> >> >> >
> >>
> >> >> > >
> >>
> >> >> >
> >>
> >> >> > > M
> >>
> >> >> >
> >>
> >> >> > >
> >>
> >> >> >
> >>
> >> >> > >
> >>
> >> >> >
> >>
> >> >> > >
> >>
> >> >> ------------------------------------------------------------
> ---------
> >>
> >> >> >
> >>
> >> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>
> >> >> >
> >>
> >> >> > > For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >> >> >
> >>
> >> >> > >
> >>
> >> >> >
> >>
> >> >> >
> >>
> >> >> >
> >>
> >> >> > ------------------------------------------------------------
> ---------
> >>
> >> >> >
> >>
> >> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>
> >> >> >
> >>
> >> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >> >> >
> >>
> >> >> >
> >>
> >> >> >
> >>
> >> >> > --
> >>
> >> >> Sent from my phone
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >>
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >>
> >> --
> > Sent from my phone
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Maven 3.4.0 Release
Posted by Manfred Moser <ma...@simpligility.com>.
Totally agree. Master should be ready to release all the time imho. Nothing that isnt tested well and proven to at least pass all IT's should be merged into master. Experimentation should happen in feature branches..
Just my 2c.
Manfred
Stephen Connolly wrote on 2016-12-19 11:12:
> We need to get the project back in the habit of releasing.
>
> My vote is the we rebuild master with a clean history. keep current master
> as a reference branch, and cherry-pick as we go.
>
> The aim should be kept tight in scope and focus on the aether replacement
> only. Minimum change for aether replacement.
>
> Then we can start bringing in bug fixes.
>
> If we need to break things, we can go 3.6.x or 4.x.y I only request that
> 5.0.0 be reserved for the first release with a modelVersion 5.0.0 pom
> (which is what my proposals are aiming to help us flesh out... though my
> proposals may not be selected by committers in the end, hopefully they will
> allow us to have a reasoned debate)
>
> Wdyt?
>
> On Mon 19 Dec 2016 at 17:41, Robert Scholte <rf...@apache.org> wrote:
>
>> We're already trying to push a new release for quite some time. And it
>>
>> seems the discussion is not over yet.
>>
>> There are a lot of improvements which deserve a release, so personally I'd
>>
>> like to push the discussion to 3.5.0
>>
>>
>>
>> Robert
>>
>>
>>
>> On Mon, 19 Dec 2016 14:12:25 +0100, Stephane Nicoll
>>
>> <st...@gmail.com> wrote:
>>
>>
>>
>> > Isn't that postponing the discussion we're having here on those
>>
>> > controversial changes? I'd rather give it an extra effort rather than
>>
>> > pushing it back and loosing all the context once we have to tackle 3.5.
>>
>> >
>>
>> > On Sun, Dec 18, 2016 at 10:02 PM, Stephen Connolly <
>>
>> > stephen.alan.connolly@gmail.com> wrote:
>>
>> >
>>
>> >> I like that plan, but let's call that 3.4.0 and let these other changes
>>
>> >> go
>>
>> >> for either 3.5.0
>>
>> >>
>>
>> >> Does someone want to take a stab at forking master from an earlier point
>>
>> >> (perhaps get infra to let us rewrite master back to the fork point and
>>
>> >> push
>>
>> >> the current state to a branch?)
>>
>> >>
>>
>> >> On Sun 18 Dec 2016 at 19:45, Igor Fedorenko <ig...@ifedorenko.com>
>> wrote:
>>
>> >>
>>
>> >> > No, I meant just eclipse->apache move, not all changes that went into
>>
>> >> >
>>
>> >> > maven-resolver. The idea is to have a release branch we can maintain
>>
>> >> >
>>
>> >> > while things stabilize in master.
>>
>> >> >
>>
>> >> >
>>
>> >> >
>>
>> >> > --
>>
>> >> >
>>
>> >> > Regards,
>>
>> >> >
>>
>> >> > Igor
>>
>> >> >
>>
>> >> >
>>
>> >> >
>>
>> >> > On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
>>
>> >> >
>>
>> >> > > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
>>
>> >> >
>>
>> >> > > > I wonder if it makes sense to release 3.3.10 with just the new
>>
>> >> aether
>>
>> >> >
>>
>> >> > > > and give 3.4 more time to bake on master.
>>
>> >> >
>>
>> >> > >
>>
>> >> >
>>
>> >> > > Changing a dependency with so many changes recently in a fix
>>
>> >> version?
>>
>> >> >
>>
>> >> > > Doesn't sound right to me.
>>
>> >> >
>>
>> >> > >
>>
>> >> >
>>
>> >> > > M
>>
>> >> >
>>
>> >> > >
>>
>> >> >
>>
>> >> > >
>>
>> >> >
>>
>> >> > >
>>
>> >> ---------------------------------------------------------------------
>>
>> >> >
>>
>> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>
>> >> >
>>
>> >> > > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> >> >
>>
>> >> > >
>>
>> >> >
>>
>> >> >
>>
>> >> >
>>
>> >> > ---------------------------------------------------------------------
>>
>> >> >
>>
>> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>
>> >> >
>>
>> >> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> >> >
>>
>> >> >
>>
>> >> >
>>
>> >> > --
>>
>> >> Sent from my phone
>>
>>
>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>>
>> --
> Sent from my phone
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Dec 19, 2016 at 11:12 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> We need to get the project back in the habit of releasing.
>
+1!
Gary
>
> My vote is the we rebuild master with a clean history. keep current master
> as a reference branch, and cherry-pick as we go.
>
> The aim should be kept tight in scope and focus on the aether replacement
> only. Minimum change for aether replacement.
>
> Then we can start bringing in bug fixes.
>
> If we need to break things, we can go 3.6.x or 4.x.y I only request that
> 5.0.0 be reserved for the first release with a modelVersion 5.0.0 pom
> (which is what my proposals are aiming to help us flesh out... though my
> proposals may not be selected by committers in the end, hopefully they will
> allow us to have a reasoned debate)
>
> Wdyt?
>
> On Mon 19 Dec 2016 at 17:41, Robert Scholte <rf...@apache.org> wrote:
>
> > We're already trying to push a new release for quite some time. And it
> >
> > seems the discussion is not over yet.
> >
> > There are a lot of improvements which deserve a release, so personally
> I'd
> >
> > like to push the discussion to 3.5.0
> >
> >
> >
> > Robert
> >
> >
> >
> > On Mon, 19 Dec 2016 14:12:25 +0100, Stephane Nicoll
> >
> > <st...@gmail.com> wrote:
> >
> >
> >
> > > Isn't that postponing the discussion we're having here on those
> >
> > > controversial changes? I'd rather give it an extra effort rather than
> >
> > > pushing it back and loosing all the context once we have to tackle 3.5.
> >
> > >
> >
> > > On Sun, Dec 18, 2016 at 10:02 PM, Stephen Connolly <
> >
> > > stephen.alan.connolly@gmail.com> wrote:
> >
> > >
> >
> > >> I like that plan, but let's call that 3.4.0 and let these other
> changes
> >
> > >> go
> >
> > >> for either 3.5.0
> >
> > >>
> >
> > >> Does someone want to take a stab at forking master from an earlier
> point
> >
> > >> (perhaps get infra to let us rewrite master back to the fork point and
> >
> > >> push
> >
> > >> the current state to a branch?)
> >
> > >>
> >
> > >> On Sun 18 Dec 2016 at 19:45, Igor Fedorenko <ig...@ifedorenko.com>
> > wrote:
> >
> > >>
> >
> > >> > No, I meant just eclipse->apache move, not all changes that went
> into
> >
> > >> >
> >
> > >> > maven-resolver. The idea is to have a release branch we can maintain
> >
> > >> >
> >
> > >> > while things stabilize in master.
> >
> > >> >
> >
> > >> >
> >
> > >> >
> >
> > >> > --
> >
> > >> >
> >
> > >> > Regards,
> >
> > >> >
> >
> > >> > Igor
> >
> > >> >
> >
> > >> >
> >
> > >> >
> >
> > >> > On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
> >
> > >> >
> >
> > >> > > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
> >
> > >> >
> >
> > >> > > > I wonder if it makes sense to release 3.3.10 with just the new
> >
> > >> aether
> >
> > >> >
> >
> > >> > > > and give 3.4 more time to bake on master.
> >
> > >> >
> >
> > >> > >
> >
> > >> >
> >
> > >> > > Changing a dependency with so many changes recently in a fix
> >
> > >> version?
> >
> > >> >
> >
> > >> > > Doesn't sound right to me.
> >
> > >> >
> >
> > >> > >
> >
> > >> >
> >
> > >> > > M
> >
> > >> >
> >
> > >> > >
> >
> > >> >
> >
> > >> > >
> >
> > >> >
> >
> > >> > >
> >
> > >> ---------------------------------------------------------------------
> >
> > >> >
> >
> > >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >
> > >> >
> >
> > >> > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > >> >
> >
> > >> > >
> >
> > >> >
> >
> > >> >
> >
> > >> >
> >
> > >> > ------------------------------------------------------------
> ---------
> >
> > >> >
> >
> > >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >
> > >> >
> >
> > >> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > >> >
> >
> > >> >
> >
> > >> >
> >
> > >> > --
> >
> > >> Sent from my phone
> >
> >
> >
> > ---------------------------------------------------------------------
> >
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
> > --
> Sent from my phone
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Maven 3.4.0 Release
Posted by Robert Scholte <rf...@apache.org>.
+100
On Mon, 19 Dec 2016 20:12:33 +0100, Stephen Connolly
<st...@gmail.com> wrote:
> We need to get the project back in the habit of releasing.
>
> My vote is the we rebuild master with a clean history. keep current
> master
> as a reference branch, and cherry-pick as we go.
>
> The aim should be kept tight in scope and focus on the aether replacement
> only. Minimum change for aether replacement.
>
> Then we can start bringing in bug fixes.
>
> If we need to break things, we can go 3.6.x or 4.x.y I only request that
> 5.0.0 be reserved for the first release with a modelVersion 5.0.0 pom
> (which is what my proposals are aiming to help us flesh out... though my
> proposals may not be selected by committers in the end, hopefully they
> will
> allow us to have a reasoned debate)
>
> Wdyt?
>
> On Mon 19 Dec 2016 at 17:41, Robert Scholte <rf...@apache.org> wrote:
>
>> We're already trying to push a new release for quite some time. And it
>>
>> seems the discussion is not over yet.
>>
>> There are a lot of improvements which deserve a release, so personally
>> I'd
>>
>> like to push the discussion to 3.5.0
>>
>>
>>
>> Robert
>>
>>
>>
>> On Mon, 19 Dec 2016 14:12:25 +0100, Stephane Nicoll
>>
>> <st...@gmail.com> wrote:
>>
>>
>>
>> > Isn't that postponing the discussion we're having here on those
>>
>> > controversial changes? I'd rather give it an extra effort rather than
>>
>> > pushing it back and loosing all the context once we have to tackle
>> 3.5.
>>
>> >
>>
>> > On Sun, Dec 18, 2016 at 10:02 PM, Stephen Connolly <
>>
>> > stephen.alan.connolly@gmail.com> wrote:
>>
>> >
>>
>> >> I like that plan, but let's call that 3.4.0 and let these other
>> changes
>>
>> >> go
>>
>> >> for either 3.5.0
>>
>> >>
>>
>> >> Does someone want to take a stab at forking master from an earlier
>> point
>>
>> >> (perhaps get infra to let us rewrite master back to the fork point
>> and
>>
>> >> push
>>
>> >> the current state to a branch?)
>>
>> >>
>>
>> >> On Sun 18 Dec 2016 at 19:45, Igor Fedorenko <ig...@ifedorenko.com>
>> wrote:
>>
>> >>
>>
>> >> > No, I meant just eclipse->apache move, not all changes that went
>> into
>>
>> >> >
>>
>> >> > maven-resolver. The idea is to have a release branch we can
>> maintain
>>
>> >> >
>>
>> >> > while things stabilize in master.
>>
>> >> >
>>
>> >> >
>>
>> >> >
>>
>> >> > --
>>
>> >> >
>>
>> >> > Regards,
>>
>> >> >
>>
>> >> > Igor
>>
>> >> >
>>
>> >> >
>>
>> >> >
>>
>> >> > On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
>>
>> >> >
>>
>> >> > > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
>>
>> >> >
>>
>> >> > > > I wonder if it makes sense to release 3.3.10 with just the new
>>
>> >> aether
>>
>> >> >
>>
>> >> > > > and give 3.4 more time to bake on master.
>>
>> >> >
>>
>> >> > >
>>
>> >> >
>>
>> >> > > Changing a dependency with so many changes recently in a fix
>>
>> >> version?
>>
>> >> >
>>
>> >> > > Doesn't sound right to me.
>>
>> >> >
>>
>> >> > >
>>
>> >> >
>>
>> >> > > M
>>
>> >> >
>>
>> >> > >
>>
>> >> >
>>
>> >> > >
>>
>> >> >
>>
>> >> > >
>>
>> >> ---------------------------------------------------------------------
>>
>> >> >
>>
>> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>
>> >> >
>>
>> >> > > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> >> >
>>
>> >> > >
>>
>> >> >
>>
>> >> >
>>
>> >> >
>>
>> >> >
>> ---------------------------------------------------------------------
>>
>> >> >
>>
>> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>
>> >> >
>>
>> >> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> >> >
>>
>> >> >
>>
>> >> >
>>
>> >> > --
>>
>> >> Sent from my phone
>>
>>
>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>>
>> --
> Sent from my phone
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Stephen Connolly <st...@gmail.com>.
We need to get the project back in the habit of releasing.
My vote is the we rebuild master with a clean history. keep current master
as a reference branch, and cherry-pick as we go.
The aim should be kept tight in scope and focus on the aether replacement
only. Minimum change for aether replacement.
Then we can start bringing in bug fixes.
If we need to break things, we can go 3.6.x or 4.x.y I only request that
5.0.0 be reserved for the first release with a modelVersion 5.0.0 pom
(which is what my proposals are aiming to help us flesh out... though my
proposals may not be selected by committers in the end, hopefully they will
allow us to have a reasoned debate)
Wdyt?
On Mon 19 Dec 2016 at 17:41, Robert Scholte <rf...@apache.org> wrote:
> We're already trying to push a new release for quite some time. And it
>
> seems the discussion is not over yet.
>
> There are a lot of improvements which deserve a release, so personally I'd
>
> like to push the discussion to 3.5.0
>
>
>
> Robert
>
>
>
> On Mon, 19 Dec 2016 14:12:25 +0100, Stephane Nicoll
>
> <st...@gmail.com> wrote:
>
>
>
> > Isn't that postponing the discussion we're having here on those
>
> > controversial changes? I'd rather give it an extra effort rather than
>
> > pushing it back and loosing all the context once we have to tackle 3.5.
>
> >
>
> > On Sun, Dec 18, 2016 at 10:02 PM, Stephen Connolly <
>
> > stephen.alan.connolly@gmail.com> wrote:
>
> >
>
> >> I like that plan, but let's call that 3.4.0 and let these other changes
>
> >> go
>
> >> for either 3.5.0
>
> >>
>
> >> Does someone want to take a stab at forking master from an earlier point
>
> >> (perhaps get infra to let us rewrite master back to the fork point and
>
> >> push
>
> >> the current state to a branch?)
>
> >>
>
> >> On Sun 18 Dec 2016 at 19:45, Igor Fedorenko <ig...@ifedorenko.com>
> wrote:
>
> >>
>
> >> > No, I meant just eclipse->apache move, not all changes that went into
>
> >> >
>
> >> > maven-resolver. The idea is to have a release branch we can maintain
>
> >> >
>
> >> > while things stabilize in master.
>
> >> >
>
> >> >
>
> >> >
>
> >> > --
>
> >> >
>
> >> > Regards,
>
> >> >
>
> >> > Igor
>
> >> >
>
> >> >
>
> >> >
>
> >> > On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
>
> >> >
>
> >> > > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
>
> >> >
>
> >> > > > I wonder if it makes sense to release 3.3.10 with just the new
>
> >> aether
>
> >> >
>
> >> > > > and give 3.4 more time to bake on master.
>
> >> >
>
> >> > >
>
> >> >
>
> >> > > Changing a dependency with so many changes recently in a fix
>
> >> version?
>
> >> >
>
> >> > > Doesn't sound right to me.
>
> >> >
>
> >> > >
>
> >> >
>
> >> > > M
>
> >> >
>
> >> > >
>
> >> >
>
> >> > >
>
> >> >
>
> >> > >
>
> >> ---------------------------------------------------------------------
>
> >> >
>
> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> >> >
>
> >> > > For additional commands, e-mail: dev-help@maven.apache.org
>
> >> >
>
> >> > >
>
> >> >
>
> >> >
>
> >> >
>
> >> > ---------------------------------------------------------------------
>
> >> >
>
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> >> >
>
> >> > For additional commands, e-mail: dev-help@maven.apache.org
>
> >> >
>
> >> >
>
> >> >
>
> >> > --
>
> >> Sent from my phone
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> --
Sent from my phone
Re: Maven 3.4.0 Release
Posted by Robert Scholte <rf...@apache.org>.
We're already trying to push a new release for quite some time. And it
seems the discussion is not over yet.
There are a lot of improvements which deserve a release, so personally I'd
like to push the discussion to 3.5.0
Robert
On Mon, 19 Dec 2016 14:12:25 +0100, Stephane Nicoll
<st...@gmail.com> wrote:
> Isn't that postponing the discussion we're having here on those
> controversial changes? I'd rather give it an extra effort rather than
> pushing it back and loosing all the context once we have to tackle 3.5.
>
> On Sun, Dec 18, 2016 at 10:02 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> I like that plan, but let's call that 3.4.0 and let these other changes
>> go
>> for either 3.5.0
>>
>> Does someone want to take a stab at forking master from an earlier point
>> (perhaps get infra to let us rewrite master back to the fork point and
>> push
>> the current state to a branch?)
>>
>> On Sun 18 Dec 2016 at 19:45, Igor Fedorenko <ig...@ifedorenko.com> wrote:
>>
>> > No, I meant just eclipse->apache move, not all changes that went into
>> >
>> > maven-resolver. The idea is to have a release branch we can maintain
>> >
>> > while things stabilize in master.
>> >
>> >
>> >
>> > --
>> >
>> > Regards,
>> >
>> > Igor
>> >
>> >
>> >
>> > On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
>> >
>> > > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
>> >
>> > > > I wonder if it makes sense to release 3.3.10 with just the new
>> aether
>> >
>> > > > and give 3.4 more time to bake on master.
>> >
>> > >
>> >
>> > > Changing a dependency with so many changes recently in a fix
>> version?
>> >
>> > > Doesn't sound right to me.
>> >
>> > >
>> >
>> > > M
>> >
>> > >
>> >
>> > >
>> >
>> > >
>> ---------------------------------------------------------------------
>> >
>> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >
>> > > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> > >
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> >
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>> >
>> > --
>> Sent from my phone
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Stephane Nicoll <st...@gmail.com>.
Isn't that postponing the discussion we're having here on those
controversial changes? I'd rather give it an extra effort rather than
pushing it back and loosing all the context once we have to tackle 3.5.
On Sun, Dec 18, 2016 at 10:02 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> I like that plan, but let's call that 3.4.0 and let these other changes go
> for either 3.5.0
>
> Does someone want to take a stab at forking master from an earlier point
> (perhaps get infra to let us rewrite master back to the fork point and push
> the current state to a branch?)
>
> On Sun 18 Dec 2016 at 19:45, Igor Fedorenko <ig...@ifedorenko.com> wrote:
>
> > No, I meant just eclipse->apache move, not all changes that went into
> >
> > maven-resolver. The idea is to have a release branch we can maintain
> >
> > while things stabilize in master.
> >
> >
> >
> > --
> >
> > Regards,
> >
> > Igor
> >
> >
> >
> > On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
> >
> > > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
> >
> > > > I wonder if it makes sense to release 3.3.10 with just the new aether
> >
> > > > and give 3.4 more time to bake on master.
> >
> > >
> >
> > > Changing a dependency with so many changes recently in a fix version?
> >
> > > Doesn't sound right to me.
> >
> > >
> >
> > > M
> >
> > >
> >
> > >
> >
> > > ---------------------------------------------------------------------
> >
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >
> > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> >
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
> > --
> Sent from my phone
>
Re: Maven 3.4.0 Release
Posted by Stephen Connolly <st...@gmail.com>.
I like that plan, but let's call that 3.4.0 and let these other changes go
for either 3.5.0
Does someone want to take a stab at forking master from an earlier point
(perhaps get infra to let us rewrite master back to the fork point and push
the current state to a branch?)
On Sun 18 Dec 2016 at 19:45, Igor Fedorenko <ig...@ifedorenko.com> wrote:
> No, I meant just eclipse->apache move, not all changes that went into
>
> maven-resolver. The idea is to have a release branch we can maintain
>
> while things stabilize in master.
>
>
>
> --
>
> Regards,
>
> Igor
>
>
>
> On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
>
> > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
>
> > > I wonder if it makes sense to release 3.3.10 with just the new aether
>
> > > and give 3.4 more time to bake on master.
>
> >
>
> > Changing a dependency with so many changes recently in a fix version?
>
> > Doesn't sound right to me.
>
> >
>
> > M
>
> >
>
> >
>
> > ---------------------------------------------------------------------
>
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> >
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> --
Sent from my phone
Re: Maven 3.4.0 Release
Posted by Igor Fedorenko <ig...@ifedorenko.com>.
No, I meant just eclipse->apache move, not all changes that went into
maven-resolver. The idea is to have a release branch we can maintain
while things stabilize in master.
--
Regards,
Igor
On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
> Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
> > I wonder if it makes sense to release 3.3.10 with just the new aether
> > and give 3.4 more time to bake on master.
>
> Changing a dependency with so many changes recently in a fix version?
> Doesn't sound right to me.
>
> M
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Michael Osipov <mi...@apache.org>.
Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
> I wonder if it makes sense to release 3.3.10 with just the new aether
> and give 3.4 more time to bake on master.
Changing a dependency with so many changes recently in a fix version?
Doesn't sound right to me.
M
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Igor Fedorenko <ig...@ifedorenko.com>.
I wonder if it makes sense to release 3.3.10 with just the new aether
and give 3.4 more time to bake on master.
--
Regards,
Igor
On Sun, Dec 18, 2016, at 07:33 AM, Robert Scholte wrote:
> I did investigate some time in this request. The conclusion is that the
> discussion should be in the open and not in the private list of the Maven
> PMC.
>
> What I see are good intended changes, but the results are a chain of
> commits where every change fixes one thing but at the same time breaks a
> couple of other things.
>
> I really had hoped we'd reached a point where it was a matter of the last
> couple of changes to be able to push 3.4.0, but instead new changes are
> introduced and is changing the behavior of Maven a lot. Right now I don't
> have a good feeling about this release. Even worse, with every new
> attempt
> to continue this path by new commits will reduce my confidence in Maven
> 3.4.0
>
> To be able to push Maven 3.4.0 out of the door some critical decisions
> need to be made. I might need to call a vote on those options, need to
> find the rights wordings though.
>
> thanks,
> Robert
>
> On Sat, 10 Dec 2016 17:42:46 +0100, Michael Osipov <mi...@apache.org>
> wrote:
>
> > Am 2016-12-10 um 16:18 schrieb Christian Schulte:
> >> It would be cool if someone could answer the questions I raised in this
> >> <http://www.mail-archive.com/dev@maven.apache.org/msg111298.html>
> >> thread. I would still need to remove those system properties from the
> >> 'DefaultModelBuilder', for example.
> >>
> >> <http://www.mail-archive.com/dev@maven.apache.org/msg111325.html>
> >> <http://www.mail-archive.com/dev@maven.apache.org/msg111326.html>
> >>
> >> IMHO, introduce that damn 'include' scope in 3.4, and be done with it.
> >> We cannot change the 'import' scope behaviour for model version 4.0.0
> >> that way but most of the users using that 'import' scope find it useless
> >> sooner or later and will probably upgrade to use the 'include' scope
> >> sometime in the future, when that is available. Just someone answer the
> >> questions. Maybe discuss this at PMC level because the reporters
> >
> > +1 if PMCs having a problem making import scope work as advertised. I
> > still think is that if this is broken -- against the spec -- it must be
> > fixed.
> >
> > Michael
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Robert Scholte <rf...@apache.org>.
I did investigate some time in this request. The conclusion is that the
discussion should be in the open and not in the private list of the Maven
PMC.
What I see are good intended changes, but the results are a chain of
commits where every change fixes one thing but at the same time breaks a
couple of other things.
I really had hoped we'd reached a point where it was a matter of the last
couple of changes to be able to push 3.4.0, but instead new changes are
introduced and is changing the behavior of Maven a lot. Right now I don't
have a good feeling about this release. Even worse, with every new attempt
to continue this path by new commits will reduce my confidence in Maven
3.4.0
To be able to push Maven 3.4.0 out of the door some critical decisions
need to be made. I might need to call a vote on those options, need to
find the rights wordings though.
thanks,
Robert
On Sat, 10 Dec 2016 17:42:46 +0100, Michael Osipov <mi...@apache.org>
wrote:
> Am 2016-12-10 um 16:18 schrieb Christian Schulte:
>> It would be cool if someone could answer the questions I raised in this
>> <http://www.mail-archive.com/dev@maven.apache.org/msg111298.html>
>> thread. I would still need to remove those system properties from the
>> 'DefaultModelBuilder', for example.
>>
>> <http://www.mail-archive.com/dev@maven.apache.org/msg111325.html>
>> <http://www.mail-archive.com/dev@maven.apache.org/msg111326.html>
>>
>> IMHO, introduce that damn 'include' scope in 3.4, and be done with it.
>> We cannot change the 'import' scope behaviour for model version 4.0.0
>> that way but most of the users using that 'import' scope find it useless
>> sooner or later and will probably upgrade to use the 'include' scope
>> sometime in the future, when that is available. Just someone answer the
>> questions. Maybe discuss this at PMC level because the reporters
>
> +1 if PMCs having a problem making import scope work as advertised. I
> still think is that if this is broken -- against the spec -- it must be
> fixed.
>
> Michael
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Michael Osipov <mi...@apache.org>.
Am 2016-12-10 um 16:18 schrieb Christian Schulte:
> It would be cool if someone could answer the questions I raised in this
> <http://www.mail-archive.com/dev@maven.apache.org/msg111298.html>
> thread. I would still need to remove those system properties from the
> 'DefaultModelBuilder', for example.
>
> <http://www.mail-archive.com/dev@maven.apache.org/msg111325.html>
> <http://www.mail-archive.com/dev@maven.apache.org/msg111326.html>
>
> IMHO, introduce that damn 'include' scope in 3.4, and be done with it.
> We cannot change the 'import' scope behaviour for model version 4.0.0
> that way but most of the users using that 'import' scope find it useless
> sooner or later and will probably upgrade to use the 'include' scope
> sometime in the future, when that is available. Just someone answer the
> questions. Maybe discuss this at PMC level because the reporters
+1 if PMCs having a problem making import scope work as advertised. I
still think is that if this is broken -- against the spec -- it must be
fixed.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.4.0 Release
Posted by Christian Schulte <cs...@schulte.it>.
It would be cool if someone could answer the questions I raised in this
<http://www.mail-archive.com/dev@maven.apache.org/msg111298.html>
thread. I would still need to remove those system properties from the
'DefaultModelBuilder', for example.
<http://www.mail-archive.com/dev@maven.apache.org/msg111325.html>
<http://www.mail-archive.com/dev@maven.apache.org/msg111326.html>
IMHO, introduce that damn 'include' scope in 3.4, and be done with it.
We cannot change the 'import' scope behaviour for model version 4.0.0
that way but most of the users using that 'import' scope find it useless
sooner or later and will probably upgrade to use the 'include' scope
sometime in the future, when that is available. Just someone answer the
questions. Maybe discuss this at PMC level because the reporters
requesting to change the 'import' scope are PMC members themselves.
Am 06.12.2016 um 22:46 schrieb Robert Scholte:
> Hi,
>
> what is the status on this? Can we expect a release this year?
>
> I think the open issues are:
> is maven-resolver ready to replace aether?
> AFAIK some dependency management changes have been reverted, are all
> others indeed bugfixes and safe to keep in this release?
>
> Here are the current release notes:
>
>
> Release Notes - Maven - Version 3.4.0
>
> ** Bug
> * [MNG-4463] - Dependency management import should support version
> ranges.
> * [MNG-5359] - Declared execution in PluginMgmt gets bound to
> lifecycle (regression)
> * [MNG-5368] - UnsupportedOperationException thrown when version range
> is not correct in dependencyManagement definitions
> * [MNG-5387] - Add ability to replace an artifact in mid-build
> * [MNG-5527] - Dependency management import should support relocations.
> * [MNG-5538] - mvn start script causes cygwin warning
> * [MNG-5567] - Zip files are not included in classpaths at all
> * [MNG-5629] - ClosedChannelException from
> DefaultUpdateCheckManager.read
> * [MNG-5815] - "mvn.cmd" does not indicate failure properly when using
> "&&"
> * [MNG-5823] - mvnDebug doesn't work with M2_HOME with spaces -
> missing quotes
> * [MNG-5836] - logging config is overwritten by $M2_HOME/lib/ext/*.jar
> * [MNG-5837] - Syntax error in bin/mvn on Solaris SPARC
> * [MNG-5849] - maven can not be found when current directory is
> drive/root at least on windows 7 64bit
> * [MNG-5852] - "mvn" script invokes /bin/sh but requires /bin/bash
> functions
> * [MNG-5863] - default pom's release-profile should invoke source
> plugin with goal "jar-no-fork" instead of "jar"
> * [MNG-5868] - Adding serval times the same artifact via
> MavenProjectHelper (attachArtifact) does not produce a failure
> * [MNG-5935] - Optional true getting lost in managed dependencies when
> transitive
> * [MNG-5939] - Problem doing release when sources are generate as well
> * [MNG-5958] - java.lang.String cannot be cast to
> org.apache.maven.lifecycle.mapping.LifecyclePhase
> * [MNG-5961] - Maven possibly not aware of log4j2
> * [MNG-5962] - mvn fails when the current directory has spaces in
> between
> * [MNG-5963] - mvn.cmd does not return ERROR_CODE
> * [MNG-5971] - Imported dependencies should be available to
> inheritance processing
> * [MNG-5981] - Plexus lifecycle could be activated too late during
> overlapping parallel requests
> * [MNG-5984] - Maven core extension resolution ignores repositories
> from activeByDefault profiles in settings.xml
> * [MNG-6022] - mvn.cmd fails if directory contains an ampersand (&)
> * [MNG-6029] - Duplicate conditional and body in
> MetadataResolutionResult.java
> * [MNG-6041] - Option -l does not disable colorized output
> * [MNG-6043] - Colorization is disabled too late in batch mode
> * [MNG-6053] - Unsafe System Properties copy in
> MavenRepositorySystemUtils, causing NPEs
> * [MNG-6057] - Problem with CI friendly usage of ${..} reactor order
> is changed
> * [MNG-6079] - 3.4 regression: cannot override version of a
> dependencyManagement in a submodule any more
> * [MNG-6109] - PluginDescriptor doesn't read since value of parameter
> * [MNG-6112] - Central repository in the 4.0.0 super POM should
> declare update policy 'never'.
> * [MNG-6114] - Elements from the global settings should be ordered
> before elements from the user settings.
> * [MNG-6117] - ${session.parallel} not correctly set
> * [MNG-6127] - Fix plugin execution configuration interference
>
> ** Dependency upgrade
> * [MNG-5967] - Dependency updates.
> * [MNG-6110] - Upgrade Aether to Maven Resolver 1.2
>
> ** Improvement
> * [MNG-4508] - No way to avoid adding artifactId to site urls
> * [MNG-5457] - Show repository id when downloading or uploading
> from/to a remote repository
> * [MNG-5579] - Unify error output/check logic from shell and batch
> scripts
> * [MNG-5600] - Dependency management import should support exclusions.
> * [MNG-5607] - Don't use M2_HOME in mvn shell/command scripts anymore
> * [MNG-5883] - Silence unnecessary legacy local repository warning
> * [MNG-5889] - .mvn directory should be picked when using --file
> * [MNG-5896] - Download dependency POMs in parallel
> * [MNG-5904] - Remove the whole Ant Build
> * [MNG-5931] - Fixing documentation
> * [MNG-5934] - String handling issues identified by PMD
> * [MNG-5940] - Change the maven-source-plugin jar goal into
> jar-no-fork in Maven Super POM
> * [MNG-5946] - Fix links etc. in README.txt which is part of the
> delivery
> * [MNG-5951] - add an option to avoid path addition to inherited URLs
> * [MNG-5968] - Default plugin version updates.
> * [MNG-5975] - Use Java 7's SimpleDateFormat in
> CLIReportingUtils#formatTimestamp
> * [MNG-5977] - Improve output readability of our MavenTransferListener
> implementations
> * [MNG-5992] - Git passwords are exposed as the Super POM still uses
> Maven Release Plugin 2.3.2
> * [MNG-5993] - Confusing error message in case of missing/empty
> artifactId and version in pluginManagement
> * [MNG-6001] - Replace %HOME% with %USERPROFILE% in mvn.cmd
> * [MNG-6003] - Drastically reduce JAVA_HOME discovery code
> * [MNG-6014] - Removing ArtifactHandler for ejb3
> * [MNG-6017] - Removing ArtifactHandler for par LifeCycle
> * [MNG-6030] - ReactorModelCache do not used effectively after maven
> version 3.0.5 which cause a large memory footprint
> * [MNG-6032] - WARNING during build based on absolute path in
> assembly-descriptor.
> * [MNG-6035] - Upgrade animal-sniffer-maven-plugin to 1.15
> * [MNG-6046] - upgrade JAnsi from 1.12 to 1.13
> * [MNG-6049] - Add behavior to filter resolved version ranges of an
> artifact
> * [MNG-6059] - Important use cases not covered, as
> child.inherit.append.path affects all children
> * [MNG-6068] - Document default scope compile in XSD
> * [MNG-6074] - Maven should produce an error if no model version has
> been set in a POM file used to build an effective model.
> * [MNG-6078] - Can't overwrite properties which have been defined in
> .mvn/maven.config
> * [MNG-6081] - Log refactoring - Method Invocation Replaced By Variable
> * [MNG-6102] - Introduce ${maven.conf} in m2.conf
> * [MNG-6115] - Add Jansi native library search path to our start
> scripts
>
> ** New Feature
> * [MNG-2478] - add "resources-filtered" filtered resource directories
> to super POM
> * [MNG-3507] - ANSI Color logging for improved output visibility.
> * [MNG-5227] - Make 'optional' flag of a dependency manageable.
> * [MNG-5878] - add support for module name != artifactId in every
> calculated URLs (project, SCM, site): special project.directory property
> * [MNG-6037] - add gossip slf4j provider support
> * [MNG-6073] - Addition of a core extension point to the model builder
> supporting model finalization.
> * [MNG-6084] - Support JSR250 annotations
> * [MNG-6093] - create a slf4j-simple provider extension that supports
> level color rendering
>
> ** Task
> * [MNG-5954] - Remove outdated
> maven-embedder/src/main/resources/META-INF/MANIFEST.MF
> * [MNG-6054] - Removal of super pom plugin management.
> * [MNG-6075] - Increase the model validation level to the next minor
> level version.
> * [MNG-6096] - Deprecate DefaultArtifactVersion class
> * [MNG-6106] - Remove maven.home setter from m2.conf
>
> ** Wish
> * [MNG-2199] - Support version ranges in parent elements
> * [MNG-6088] - after forked execution success, add an empty line
> * [MNG-6092] - warn if prerequisites.maven is used for non-plugin
> projects
> * [MNG-6113] - Rename the 'Central Repository' to 'Maven Central
> Repository' in the 4.0.0 super POM.
>
>
>
> On Sun, 09 Oct 2016 13:58:29 +0200, Karl Heinz Marbaise
> <kh...@gmx.de> wrote:
>
>> Hi to all,
>>
>> I would like to know what prevents us currently from releasing Maven
>> 3.4.0 ?
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org