Re: $PROJECT_NAME - Build # $BUILD_NUMBER - $BUILD_STATUS

[Stephen Connolly]

This is the Jenkinsfile project... I'll get the config right yet!

On Sun 1 Jan 2017 at 20:24, Apache Jenkins Server 
wrote:

The Apache Jenkins build system has built $PROJECT_NAME (build
#$BUILD_NUMBER)



Status: $BUILD_STATUS



Check console output at $BUILD_URL to view the results.

-- 
Sent from my phone

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

[Stephen Connolly]

You should be able to edit. If not ping Hervé

Yes there are changes between 3.2.x and 3.3.9, what we want from 3.5.0 is
to make the only behaviour change be a no-op for switching aether for
resolver... after that 3.5.1 can fix bugs

On Sun 1 Jan 2017 at 22:52, Christian Schulte  wrote:

> Am 01/01/17 um 16:09 schrieb Stephen Connolly:
>
> > If you want to know the current status check
>
> > https://cwiki.apache.org/confluence/display/MAVEN/Roadmap+2017
>
>
>
> Can I edit that page myself? User name is "schulte".


> Regarding the drop
>

> in replacement for 3.3.9: MNG-2199 was already working in Maven 3.2.2.
>
> Maven 3.3.9 isn't a drop in replacement for 3.2.2 itself so to say. I
>
> would propose MNG-2199 for the 3.6.0 scope then, however.
>
>
>
>
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> --
Sent from my phone

Re: Build failed in Jenkins: core-it-maven-3-win #1433

[Christian Schulte]

Really no one knows why that IT has started to fail sporadically on Windows?

Am 01/01/17 um 23:06 schrieb Apache Jenkins Server:
> See 
> 
> Changes:
> 
> [stephen.alan.connolly] hopefully the final Jenkinsfile fix
> 
> --
> [...truncated 11525 lines...]
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> [ERROR]   
> [ERROR]   The project org.apache.maven.its.mng3599:test:1.0-SNAPSHOT 
> (F:\ws\m3-its\core-integration-testing-trunk\core-it-suite\target\test-classes\mng-3599\pom.xml)
>  has 1 error
> [ERROR] Unresolveable build extension: Plugin 
> org.apache.maven.wagon:wagon-webdav-jackrabbit:2.0 or one of its dependencies 
> could not be resolved: Failed to read artifact descriptor for 
> org.apache.maven.wagon:wagon-webdav-jackrabbit:jar:2.0: Could not transfer 
> artifact org.apache.maven.wagon:wagon-webdav-jackrabbit:pom:2.0 from/to 
> test-mirror (dav://www.example.com/): Cannot access dav://www.example.com/ 
> with type default using the available connector factories: 
> BasicRepositoryConnectorFactory: Cannot access dav://www.example.com/ using 
> the registered transporter factories: WagonTransporterFactory: 
> java.util.NoSuchElementException
> [ERROR]   role: org.apache.maven.wagon.Wagon
> [ERROR]   roleHint: dav
> [ERROR] -> [Help 2]
> org.apache.maven.plugin.PluginManagerException: Plugin 
> org.apache.maven.wagon:wagon-webdav-jackrabbit:2.0 or one of its dependencies 
> could not be resolved: Failed to read artifact descriptor for 
> org.apache.maven.wagon:wagon-webdav-jackrabbit:jar:2.0
>   at 
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.setupExtensionsRealm(DefaultMavenPluginManager.java:844)
>   at 
> org.apache.maven.project.DefaultProjectBuildingHelper.createProjectRealm(DefaultProjectBuildingHelper.java:196)
>   at 
> org.apache.maven.project.DefaultModelBuildingListener.buildExtensionsAssembled(DefaultModelBuildingListener.java:99)
>   at 
> org.apache.maven.model.building.ModelBuildingEventCatapult$1.fire(ModelBuildingEventCatapult.java:44)
>   at 
> org.apache.maven.model.building.DefaultModelBuilder.fireEvent(DefaultModelBuilder.java:1720)
>   at 
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:523)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:579)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:370)
>   at 
> org.apache.maven.graph.DefaultGraphBuilder.collectProjects(DefaultGraphBuilder.java:419)
>   at 
> org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor(DefaultGraphBuilder.java:410)
>   at 
> org.apache.maven.graph.DefaultGraphBuilder.build(DefaultGraphBuilder.java:83)
>   at org.apache.maven.DefaultMaven.buildGraph(DefaultMaven.java:516)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:214)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:1019)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:316)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:219)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginResolutionException: Plugin 
> org.apache.maven.wagon:wagon-webdav-jackrabbit:2.0 or one of its dependencies 
> could not be resolved: Failed to read artifact descriptor for 
> org.apache.maven.wagon:wagon-webdav-jackrabbit:jar:2.0
>   at 
> org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolveInternal(DefaultPluginDependenciesResolver.java:381)
>   at 
> org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:134)
>   at 
> 

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

[Guillaume Boué]

OK, thanks for confirming this.


Le 01/01/2017 à 23:44, Christian Schulte a écrit :

Am 01/01/17 um 18:44 schrieb Guillaume Boué:

There is a commit about MRESOLVER-9 in tag 2.11 of Wagon:
https://git1-us-west.apache.org/repos/asf?p=maven-wagon.git;a=commit;h=f244ece2eee01500e4b1bc334b8dcd35b47f9422.
I'm unsure whether it is safe to use this tag if MRESOLVER-9 doesn't
make it in the resolver release after its reset.

Does not make a difference. Everything is resolved the same way as
before. It's just that the project can be build with MRESOLVER-9 in
place. It can be built the same way now even when MRESOLVER-9 is not
there.  Does not affect anything.


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




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


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

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

[Christian Schulte]

Am 01/01/17 um 16:09 schrieb Stephen Connolly:
> If you want to know the current status check
> https://cwiki.apache.org/confluence/display/MAVEN/Roadmap+2017

Can I edit that page myself? User name is "schulte". Regarding the drop
in replacement for 3.3.9: MNG-2199 was already working in Maven 3.2.2.
Maven 3.3.9 isn't a drop in replacement for 3.2.2 itself so to say. I
would propose MNG-2199 for the 3.6.0 scope then, however.



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

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

[Christian Schulte]

Am 01/01/17 um 18:44 schrieb Guillaume Boué:
> 
> There is a commit about MRESOLVER-9 in tag 2.11 of Wagon: 
> https://git1-us-west.apache.org/repos/asf?p=maven-wagon.git;a=commit;h=f244ece2eee01500e4b1bc334b8dcd35b47f9422.
>  
> I'm unsure whether it is safe to use this tag if MRESOLVER-9 doesn't 
> make it in the resolver release after its reset.

Does not make a difference. Everything is resolved the same way as
before. It's just that the project can be build with MRESOLVER-9 in
place. It can be built the same way now even when MRESOLVER-9 is not
there.  Does not affect anything.


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

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

[Hervé BOUTEMY]

Le dimanche 1 janvier 2017, 18:44:52 CET Guillaume Boué a écrit :
> This is the list of JIRA issues that targets colourised logging / are
> related to it:
> 
> MNG-3507  ANSI color logging for improved output visibility   This is 
> the
> root JIRA issue.
+1

> MNG-3705  Expression: ${executedProject} doesn't work in reports  SVN
> revisions d4d7f4763f34e2c23e590ce02551943a1cad84e5 and
> c6fb60b5482a12e3f94b74cd050ba46eddaa2423 are about it and actually
> target MNG-3507.
yes, this one was a typo :)

> MNG-6037  add gossip slf4j provider support   Note that the 
> colorization
> feature was removed from Gossip.
not really used any more: I don't know if anyone is interested

> MNG-6038
>   use Gossip slf4j provider as default logging, since it supports level
> colorization  WONTFIX
WONTFIX +1

> MNG-6041  Option -l does not disable colorized output Those are
> in-version fixes, to be squashed with MNG-3507.
+1

> MNG-6043  Colorization is disabled too late in batch mode
+1

> MNG-6046  upgrade JAnsi from 1.12 to 1.13
+1

> MNG-6093
>   create a slf4j-simple provider extension that supports level color
> rendering This supercedes MNG-6038 and adds colorization to the Slf4j
> Provider.
+1

> MNG-6115
>   Add Jansi native library search path to our start scripts   This 
> adds a
> system property to the launcher scripts. Should be safe to add alone
> without impacts.
+1
> 
> 
> Please add if I forgot some. I hope it'll make deciding whether the
> colorization feature, or parts of it, are added to 3.5.0 or later easier.
> 
> My personal take is that all of this could be integrated in 3.5.0 as it
> does not affect current 3.3.9 build behaviour (that I encountered, at
> least) and has a fair number of votes on JIRA.
+1

> The con of course is that
> it represents a complex addition.
not so complex: with the squash, it will look as simple as it is in the end :)

Regards,

Hervé

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



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

Re: Using the Maven API outside of a plugin?

[Stian Soiland-Reyes]

Hi, you may want to have look at Apache Taverna's plugin system which did
something similar. War story below..


We initially (2007) used Maven dependencies directly by parsing pom.xml
dependencies and using a set of repositories, but found this very fragile
because of versioning mismatches when upgrading anything; basically we
ended pulling down both the newer and older version of dependencies of the
main application, which might not match.

Back then it was even trickier to use Maven APIs outside Maven, so we
replicated our own pom.xml parsers and our own dependency tree resolution.
(Not a good idea!) We called this Raven..

In addition to having to play catch up with Maven (e.g. property expansion
within version strings) this infrastructure also ran into problems with
third party maven repositories for plugins being unreliable, but because we
had merged to a single list of repositories this affected installation of
all plugins and slowed down every startup. (We actually added blacklisting
of repos before Maven did :-))

While our first attempt, using our own "Raven" system assumed everything
was a plugin, meaning we could ship a minimal launcher and pom files, but
it would easily take 20 minutes on first launch to download everything. So
we had to "prewarm" our local repository - a naïve copy from .m2/repository
would also work.

We  introduced a distinction from the Application (the full base
application that the installer provides) and optional plugins, which then
must be compatible with the particular application version. This is more of
a Firefox+plugins style model which is probably what you need as well.


In the end we decided for a simpler OSGi based launcher where we have a
maven plugin that can generate a Taverna plugin description (it unrolls all
the transitive dependencies), which can then be installed from a single
site independent of Maven infrastructure. So now we don't use anything
Maven related at runtime, meaning you can also install plugins by dropping
a file into a folder.

Taverna Osgi has update support as well with pre-checking of compatibility,
to avoid upgrading yourself to an version-incompatible state.

We use it for a command line tool and a Swing-based workbench, with Swing
components to manage plugin install.

I'm afraid we don't have much documentation yet, see
https://taverna.incubator.apache.org/download/osgi/
and ask on dev@taverna if you (or anyone else) are interested !
https://taverna.incubator.apache.org/community/lists

On 1 Jan 2017 6:00 pm,  wrote:

> On 2017-01-01T17:37:26 +0100
> "Robert Scholte"  wrote:
>
> > Hi,
> >
> > doing this outside the context of Maven is probably hard to do. What you
> > at least need is the maven-artifact-resolver[1] (that's the project where
> > the development of Eclipses Aether[2] continues), though is has not been
> > released yet, so right now using Aether would be an option.
> > You'll also need a maven-aether-provider[3].
> > I would expect that with these projects you should be able to do your
> > stuff, although doing it with a custom maven-plugin is probably a lot
> > easier.
> >
> > Robert
> >
> > [1] https://maven.apache.org/components/resolver-archives/
> resolver-LATEST/
> > [2] http://www.eclipse.org/aether/
> > [3] http://maven.apache.org/ref/3.3.9/maven-aether-provider/
> >
>
> 'Ello.
>
> Thanks for these.
>
> I should elaborate what I'm trying to do.
>
> I'm writing a small game and the game is designed to support third
> party modification out of the box. What this means in practical terms
> is that the game ships with a simple launcher and a directory full of
> jar files and their associated Maven POMs. In the launcher, the user
> states that they want to run the game with any extra specified mod
> packages, and the launcher analyzes the local POM files of the packages
> to determine if all of the dependencies are met (and will fetch packages
> from our server or Maven Central if the dependencies aren't currently
> installed).
>
> So, there isn't actually a plugin as all of this is happening post
> "deployment".
>
> I'll have a go at a proof of concept with the links you've provided.
>
> M
>

Re: Using the Maven API outside of a plugin?

[Robert Scholte]

Someone pointed me once to https://github.com/nanosai/modrun which seems  
to match your requirements.

I haven't tried it.

Robert

On Sun, 01 Jan 2017 19:00:28 +0100,  wrote:


On 2017-01-01T17:37:26 +0100
"Robert Scholte"  wrote:


Hi,

doing this outside the context of Maven is probably hard to do. What you
at least need is the maven-artifact-resolver[1] (that's the project  
where

the development of Eclipses Aether[2] continues), though is has not been
released yet, so right now using Aether would be an option.
You'll also need a maven-aether-provider[3].
I would expect that with these projects you should be able to do your
stuff, although doing it with a custom maven-plugin is probably a lot
easier.

Robert

[1]  
https://maven.apache.org/components/resolver-archives/resolver-LATEST/

[2] http://www.eclipse.org/aether/
[3] http://maven.apache.org/ref/3.3.9/maven-aether-provider/



'Ello.

Thanks for these.

I should elaborate what I'm trying to do.

I'm writing a small game and the game is designed to support third
party modification out of the box. What this means in practical terms
is that the game ships with a simple launcher and a directory full of
jar files and their associated Maven POMs. In the launcher, the user
states that they want to run the game with any extra specified mod
packages, and the launcher analyzes the local POM files of the packages
to determine if all of the dependencies are met (and will fetch packages
from our server or Maven Central if the dependencies aren't currently
installed).

So, there isn't actually a plugin as all of this is happening post
"deployment".

I'll have a go at a proof of concept with the links you've provided.

M


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

Re: Using the Maven API outside of a plugin?

[org . apache . maven . user]

On 2017-01-01T17:37:26 +0100
"Robert Scholte"  wrote:

> Hi,
> 
> doing this outside the context of Maven is probably hard to do. What you  
> at least need is the maven-artifact-resolver[1] (that's the project where  
> the development of Eclipses Aether[2] continues), though is has not been  
> released yet, so right now using Aether would be an option.
> You'll also need a maven-aether-provider[3].
> I would expect that with these projects you should be able to do your  
> stuff, although doing it with a custom maven-plugin is probably a lot  
> easier.
> 
> Robert
> 
> [1] https://maven.apache.org/components/resolver-archives/resolver-LATEST/
> [2] http://www.eclipse.org/aether/
> [3] http://maven.apache.org/ref/3.3.9/maven-aether-provider/
> 

'Ello.

Thanks for these.

I should elaborate what I'm trying to do.

I'm writing a small game and the game is designed to support third
party modification out of the box. What this means in practical terms
is that the game ships with a simple launcher and a directory full of
jar files and their associated Maven POMs. In the launcher, the user
states that they want to run the game with any extra specified mod
packages, and the launcher analyzes the local POM files of the packages
to determine if all of the dependencies are met (and will fetch packages
from our server or Maven Central if the dependencies aren't currently
installed).

So, there isn't actually a plugin as all of this is happening post
"deployment".

I'll have a go at a proof of concept with the links you've provided.

M


pgp1Bpvckdgfd.pgp
Description: OpenPGP digital signature

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

[Guillaume Boué]

This is the list of JIRA issues that targets colourised logging / are
related to it:

MNG-3507ANSI color logging for improved output visibility   This is 
the
root JIRA issue.
MNG-3705Expression: ${executedProject} doesn't work in reports  SVN
revisions d4d7f4763f34e2c23e590ce02551943a1cad84e5 and
c6fb60b5482a12e3f94b74cd050ba46eddaa2423 are about it and actually
target MNG-3507.
MNG-6037add gossip slf4j provider support   Note that the 
colorization
feature was removed from Gossip.
MNG-6038
use Gossip slf4j provider as default logging, since it supports level
colorizationWONTFIX
MNG-6041Option -l does not disable colorized output Those are
in-version fixes, to be squashed with MNG-3507.
MNG-6043Colorization is disabled too late in batch mode
MNG-6046upgrade JAnsi from 1.12 to 1.13
MNG-6093
create a slf4j-simple provider extension that supports level color
rendering   This supercedes MNG-6038 and adds colorization to the Slf4j
Provider.
MNG-6115
Add Jansi native library search path to our start scripts   This 
adds a
system property to the launcher scripts. Should be safe to add alone
without impacts.


Please add if I forgot some. I hope it'll make deciding whether the
colorization feature, or parts of it, are added to 3.5.0 or later easier.

My personal take is that all of this could be integrated in 3.5.0 as it
does not affect current 3.3.9 build behaviour (that I encountered, at
least) and has a fair number of votes on JIRA. The con of course is that
it represents a complex addition.

Guillaume


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

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

[Guillaume Boué]

Le 01/01/2017 à 01:55, Michael Osipov a écrit :
I just went through the list my issues. Here is a safe list I would 
merge/cherry-pick into new master:


FIX-3.5.0: MNG-5457, 


Note: this is dependant upon MRESOLVER-2 (commit 
https://git1-us-west.apache.org/repos/asf?p=maven-resolver.git;a=commit;h=11b359e188f3b1d25bb6bda60195e7a47ca45bfc), 
so it depends if this makes it in the resolver release after its reset.


MNG-5567, 


This changes the classpath by adding ZIP files to it. I'd say this 
should be FIX-3.5.1 instead.



MNG-6106,


Seconded.


MNG-6136, MNG-6137


There is a commit about MRESOLVER-9 in tag 2.11 of Wagon: 
https://git1-us-west.apache.org/repos/asf?p=maven-wagon.git;a=commit;h=f244ece2eee01500e4b1bc334b8dcd35b47f9422. 
I'm unsure whether it is safe to use this tag if MRESOLVER-9 doesn't 
make it in the resolver release after its reset.




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

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

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

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


Drop: MNG-5976

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

Michael


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




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


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

Re: GitHub pull requests without JIRA issue

[Hervé BOUTEMY]

on "since these pages are managed via cms.apache.org/"
these pages are managed through svn, ie either edited locally or through CMS.
CMS is necessary only to build and publish the generated content

then for site, a PR is sufficient in general: will be integrated manually to svn

Regards,

Hervé

Le dimanche 1 janvier 2017, 17:21:30 CET Robert Scholte a écrit :
> Hi Mirko,
> 
> The JIRA for these pages is MNGSITE, but is often not required (tracking
> such changes don't really have value)
> A PR is hard, since these pages are managed via cms.apache.org/
> These changes have a small workflow and and can be published within
> minutes.
> 
> Robert
> 
> On Sun, 01 Jan 2017 16:37:20 +0100, Mirko Friedenhagen
> 
>  wrote:
> > Hello PMCs et al,
> > 
> > I commented on a PR on GitHub a while ago with a change to documentation
> > of
> > the Maven site plugin. This slipped through my fingers and now the
> > reporter
> > asked how to submit patches to the Apache Maven project.
> > 
> > I guess this is documented here (
> > https://maven.apache.org/guides/development/guide-helping.html), where it
> > says you have to create an issue in the issue tracker.
> > 
> > Is creating a JIRA issue necessary for small changes as well?
> > 
> > Or is a pull request sufficient?
> > 
> > Is there a difference between projects still in SVN  (no real git merge)
> > vs
> > GIT (real merge of a branch)
> > 
> > Sorry if this has been discussed before, at least I did not find the
> > discussion.
> > 
> > 
> > Regards
> > Mirko
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



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

Re: Using the Maven API outside of a plugin?

[Robert Scholte]

Hi,

doing this outside the context of Maven is probably hard to do. What you  
at least need is the maven-artifact-resolver[1] (that's the project where  
the development of Eclipses Aether[2] continues), though is has not been  
released yet, so right now using Aether would be an option.

You'll also need a maven-aether-provider[3].
I would expect that with these projects you should be able to do your  
stuff, although doing it with a custom maven-plugin is probably a lot  
easier.


Robert

[1] https://maven.apache.org/components/resolver-archives/resolver-LATEST/
[2] http://www.eclipse.org/aether/
[3] http://maven.apache.org/ref/3.3.9/maven-aether-provider/

On Sun, 01 Jan 2017 14:04:36 +0100,  wrote:


Apologies if this isn't an appropriate subject for this list. I tried
the user list and got no response. Perhaps it is more of a development
question...

Hello.

I'm writing a small program to analyze the dependencies of Maven
projects. There are numerous examples of how to do this from within a
Maven plugin, but I can't work out how to simply load a POM file and
derive a ProjectDependencyGraph from it outside of the context of a
plugin. How do I instantiate all of the required classes? As an
example, I believe I need to instantiate a MavenSession, but all of the
constructors of that class are deprecated...

Does anyone have any example code or documentation I can look at?

Even some pointers such as "these are the list of classes you need to
instantiate" would help.

M


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

Re: GitHub pull requests without JIRA issue

[Robert Scholte]

Hi Mirko,

The JIRA for these pages is MNGSITE, but is often not required (tracking  
such changes don't really have value)

A PR is hard, since these pages are managed via cms.apache.org/
These changes have a small workflow and and can be published within  
minutes.


Robert

On Sun, 01 Jan 2017 16:37:20 +0100, Mirko Friedenhagen  
 wrote:



Hello PMCs et al,

I commented on a PR on GitHub a while ago with a change to documentation  
of
the Maven site plugin. This slipped through my fingers and now the  
reporter

asked how to submit patches to the Apache Maven project.

I guess this is documented here (
https://maven.apache.org/guides/development/guide-helping.html), where it
says you have to create an issue in the issue tracker.

Is creating a JIRA issue necessary for small changes as well?

Or is a pull request sufficient?

Is there a difference between projects still in SVN  (no real git merge)  
vs

GIT (real merge of a branch)

Sorry if this has been discussed before, at least I did not find the
discussion.


Regards
Mirko


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

GitHub pull requests without JIRA issue

[Mirko Friedenhagen]

Hello PMCs et al,

I commented on a PR on GitHub a while ago with a change to documentation of
the Maven site plugin. This slipped through my fingers and now the reporter
asked how to submit patches to the Apache Maven project.

I guess this is documented here (
https://maven.apache.org/guides/development/guide-helping.html), where it
says you have to create an issue in the issue tracker.

Is creating a JIRA issue necessary for small changes as well?

Or is a pull request sufficient?

Is there a difference between projects still in SVN  (no real git merge) vs
GIT (real merge of a branch)

Sorry if this has been discussed before, at least I did not find the
discussion.


Regards
Mirko
-- 
Sent from my mobile

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

[Stephen Connolly]

If you want to know the current status check
https://cwiki.apache.org/confluence/display/MAVEN/Roadmap+2017

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

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

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

[Stephen Connolly]

On 1 January 2017 at 04:42, Christian Schulte  wrote:

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

-1: I propose FIX-3.5.1 as this makes it hard for 3.5.0 to be a drop in
behaviour replacement fort 3.3.9


>
> > MNG-4463   WONTFIX  Dependency management import should support
> > version ranges.
>   ^
> FIX-3.6.0
>
> > MNG-5227   WONTFIX  The 'optional' flag of a dependency should
> > be manageable.
>   ^
> FIX-3.6.0
>
> > MNG-5359   WONTFIX  Declared execution in PluginMgmt gets bound
> > to lifecycle (regression)
>   ^
> FIX-3.5.0
>

-1: I propose FIX-3.5.1 as this makes it hard for 3.5.0 to be a drop in
behaviour replacement for 3.3.9


> > MNG-5527   WONTFIX  Relocation does not work for imported poms
>   ^
> FIX-3.6.0
>
> > MNG-5600   WONTFIX  Dependency management import should support
> > exclusions.
>   ^
> FIX-3.6.0
>
> > MNG-5629   WONTFIX  ClosedChannelException from
> > DefaultUpdateCheckManager.read
>   ^
> FIX-3.5.0
>

I'll second


>
> > MNG-5761   WONTFIX  Dependency management is not transitive.
>   ^
> FIX-3.6.0
>
> > MNG-5935   WONTFIX  Optional true getting lost in managed
> > dependencies when transitive
>   ^
> FIX-3.6.0
>
> > MNG-5958   WONTFIX  restore binary compatibility of
> > Lifecycle.setPhases
>   ^
> FIX-3.5.0
>

Already marked as agreed


>
> > MNG-5971   WONTFIX  Imported dependencies should be available to
> > inheritance processing
>   ^
> FIX-3.6.0
>
>
> > MNG-6023   WONTFIX  Upgrade of slf4j-simple to a version later
> > than 1.7.16 blocked by upstream issue.
>   ^
> FIX-3.5.0
>

Explain why we need to update the slf4j dependency in 3.5.0 and not 3.5.1


>
> That's a duplicate to the "Dependency updates" JIRA issue.
>
> > MNG-6049   WONTFIX  Add behavior to filter resolved version
> > ranges of an artifact
>   ^
> FIX-3.6.0
>
> I am not sure about the solution to this one currently on master. It
> adds an interface we already have in the resolver but do not expose in
> Maven core. Maybe this needs re-thinking. Better solution would be to
> allow core extensions to provide various components for the
> "RepositorySystemSession". Setup of the repository system currently is
> done in a static method. This would need to be changed to support core
> extensions.
>
> > MNG-6053   WONTFIX  guard against key without value
>   ^
> FIX-3.5.0
>
> > MNG-6053   WONTFIX  prevent NPE when copying System Properties
> > in MavenRepositorySystemUtils
>   ^
> FIX-3.5.0
>

I'll second this one


>
> > MNG-6073   WONTFIX  Addition of a core extension point to the
> > model builder supporting model finalization.
>   ^
> FIX-3.6.0
>
> > MNG-6074   WONTFIX  Maven should produce an error if no model
> > version has been set in a POM file used to
> > build an effective model.
>   ^
> FIX-3.5.0
>

-1: I propose WONTFIX or FIX-3.6.0 if the issue is changed to outputting a
warning rather than an error


>
> > MNG-6075   WONTFIX  Increase the model validation level to the
> > next minor level version.
>   ^
> FIX-3.6.0
>
> > MNG-6079   WONTFIX  3.4 regression: cannot override version of
> > a dependencyManagement in a submodule any
> > more
>   ^
> FIX-3.6.0
>
> > MNG-6105   WONTFIX  properties.internal.SystemProperties
> > .addSystemProperties() is not really
> > thread-safe
>   ^
> FIX-3.5.0
>

I'll second


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

-1 for 3.5.0. I need to think some more about where this should land


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

-1 for 3.5.0. I need to think some more about where this should land


>
> > MNG-6114   

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

[Stephen Connolly]

On 1 January 2017 at 00:55, Michael Osipov  wrote:

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



> MNG-5457,


Should not affect behaviour: I'll second


> MNG-5567,


Affects behaviour, I recommend 3.5.1 but I will not object if others feel
3.5.0


> MNG-5579,


Note to self: This is a dup of MNG-6003


> MNG-5607,


I'd proposed this so marked as agreed unless we have an objector in the
next 3 days

MNG-5815,


I'd proposed this so marked as agreed unless we have an objector in the
next 3 days


> MNG-5954,


I'd second this for 3.5.1 but I'm not objecting if others feel it is low
risk to drop-in replacement with 3.3.9

MNG-5963,


Marked as agreed unless we have an objector in the next 3 days


> MNG-5975,


Should not affect behaviour: I'll second


> MNG-5977,


Should not affect behaviour: I'll second


> MNG-6001,


Marked as agreed unless we have an objector in the next 3 days


> MNG-6003,


Marked as agreed unless we have an objector in the next 3 days


> MNG-6029,


I'd second this for 3.5.1
I have concerns with introducing for 3.5.0 as it affects how the classpath
gets built and could cause behaviour differences between 3.3.9 and 3.5.0
(as it causes the test classpath to actually get resolved)

-1 for 3.5.0 but I am open to change my position


> MNG-6081,
>

Marked as agreed unless we have an objector in the next 3 days


> MNG-6102,


I'd second this for 3.5.1 but I'm not objecting if others feel it is low
risk to drop-in replacement with 3.3.9

MNG-6106,


I'd second this for 3.5.1 but I'm not objecting if others feel it is low
risk to drop-in replacement with 3.3.9


> MNG-6115,


We need to decide on colourised logs for 3.5.0 or 3.5.1


> MNG-6136,


I'd second this for 3.5.1 but I'm not objecting if others feel it is low
risk to drop-in replacement with 3.3.9


> MNG-6137,


I'd second this for 3.5.1 but I'm not objecting if others feel it is low
risk to drop-in replacement with 3.3.9


> MNG-6138
>

 Should not affect behaviour: I'll second


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

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

[Stephen Connolly]

MNG-5962: I'll second that one
MNG-5958: I think this one is debatable as it stops 3.5.0 from being a
drop-in behaviour replacement of 3.3.9, but I don't feel strongly enough to
push it to 3.5.1
MNG-6117: Ditto for 5958, you'll need somebody to second this one for
3.5.0. I'll second it for 3.5.1

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

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

Using the Maven API outside of a plugin?

[org . apache . maven . user]

Apologies if this isn't an appropriate subject for this list. I tried
the user list and got no response. Perhaps it is more of a development
question...

Hello.

I'm writing a small program to analyze the dependencies of Maven
projects. There are numerous examples of how to do this from within a
Maven plugin, but I can't work out how to simply load a POM file and
derive a ProjectDependencyGraph from it outside of the context of a
plugin. How do I instantiate all of the required classes? As an
example, I believe I need to instantiate a MavenSession, but all of the
constructors of that class are deprecated...

Does anyone have any example code or documentation I can look at?

Even some pointers such as "these are the list of classes you need to
instantiate" would help.

M


pgpVjUbMrtTLz.pgp
Description: OpenPGP digital signature

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

[Michael Osipov]

Am 2017-01-01 um 10:26 schrieb Stephen Connolly:

On 1 January 2017 at 00:55, Michael Osipov  wrote:


MNG-5963, MNG-6137



I couldn't find them in my list... note to self, double check... note to
michael, can you confirm


I distilled from your list, filtered git log and Jira roadmap.

* MNG-5963 is fixed and on agreed in your list.
* MNG-6137 is still open depends on MNG-6136 which is Wagon upgrade to 2.11.


Otherwise I have updated the wiki with your proposals (some of which were
seconds and moved  things into agreed (pending no objections from others in
the next 3 days)


Just checked, looks fine.

I will go on and create a few more tickets for the dandling stuff.

Michael

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

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

[Michael Osipov]

Am 2017-01-01 um 04:51 schrieb Christian Schulte:

Am 01/01/17 um 01:55 schrieb Michael Osipov:

Undecided:
MNG-5708: fixed by Christian's work


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


I do agree, you are the expert. Moving to FIX-3.6.0, FIX-4.0.0?

Michael


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

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

[Stephen Connolly]

We need to get a release that is *the same as 3.3.9 only with aether
swapped for resolver* first IMHO.

That was the original plan...

Then people started wanting to add bug fixes and lots of other stuff.

The point of a reset is to return to the original plan.

Bugs orthogonal to the aether->resolver change could be included... but
there is a risk we go a step too far

What we want to be able to say is: if you currently use 3.3.9 you can
upgrade with zero risk to 3.5.0

Then we start fixing bugs in 3.5.1, etc... but we have moved our *head*
users onto the 3.5.x line and can start bringing the others with us
On Sun 1 Jan 2017 at 08:04, Christian Schulte  wrote:

> Am 01/01/17 um 08:23 schrieb Christian Schulte:
>
> > Am 01/01/17 um 08:18 schrieb Christian Schulte:
>
> >> Once more I asked someone to test a snapshot and provided a link to
>
> >> Jenkins. That's where all those commits come from. I hope I'll get
>
> >> feedback on this one and that could again lead to commits. Doing this on
>
> >> a release branch - yes - I got that.
>
> >
>
> > And you do want someone grabbing that snapshot to get all changes done
>
> > by all committers and not just some build of some personal branch which
>
> > is lacking all other development. Let master be the release branch but
>
> > let there be a branch all development of all committers is taking place.
>
>
>
> Reverting things just to keep them the way they were instead of
>
> clarifying things and finding better solutions is the worst thing you
>
> can do, IMO.
>
>
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> --
Sent from my phone

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

[Stephen Connolly]

I thought you had said that it was a regression introduced in 3.0, so if
prerequisites is 2.x then you should resolve the "fixed" way as that was
the way of 2.x that you are *restoring*

The only reason for the bug reproduction on [3.0,3.4) is because people
developing against the 3.x versions might have used hacks to work around
the "bug" and hence need protection so that their "hacks" still work

On Sun 1 Jan 2017 at 07:11, Christian Schulte  wrote:

> Am 01/01/17 um 08:06 schrieb Christian Schulte:
>
> > Am 01/01/17 um 07:52 schrieb Christian Schulte:
>
> >> is uncovering bugs in the poms. Current master is passing all core ITs,
>
> >> all plugin ITs and also can be used to build all plugins, if you
>
> >> manually change to a different plugin tools release
>
> >> (-DmavenPluginToolsVersion=3.3 or 3.5).
>
> >
>
> > It's not even needed to change the plugin tools version any more. Only
>
> > plugins having declared
>
> >
>
> > 3.4
>
> >
>
> > would get the correct resolution.
>
>
>
> And all of our plugins already are working with that correct resolution
>
> in place but are still resolved the old way, because they declare
>
> prerequisites 2.0, 2.2.1 or 3.0. You can declare them prerequsisite 3.4
>
> today and they'll work.
>
>
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> --
Sent from my phone

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

[Stephen Connolly]

On 1 January 2017 at 00:55, Michael Osipov  wrote:

> MNG-5963, MNG-6137


I couldn't find them in my list... note to self, double check... note to
michael, can you confirm

Otherwise I have updated the wiki with your proposals (some of which were
seconds and moved  things into agreed (pending no objections from others in
the next 3 days)

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

[Stephen Connolly]

We cannot update the JIRA issues until after we do the reset

On 1 January 2017 at 04:51, Christian Schulte  wrote:

> I think it would be easier if we just update the JIRA issues and set the
> version the issue will be shipped in. We already have a 3.5.0 version
> available. That will be the next Maven release? So we would need a 3.6.0
> version and a 4.0.0 version and a 5.0.0 version. Let 4.0.0 be the next
> major version in which all model version 4.0.0 features will be shipped.
> Let version 5.0.0 be the next major version shipping model version
> 5.0.0. Let's also create corresponding branches in the repositories so
> that exisiting commits can already be applied to theire final
> destination ready to be merged into master sometime in the future.
>
> Am 12/31/16 um 21:10 schrieb Stephen Connolly:
> > Here are the changes in current master since 3.3.9 (with some minor
> changes
> > omitted)
> >
> > Issue ID   Target Version   Summary
> >    ==   
> > MNG-1577   WONTFIX  dependencyManagement does not work for
> > transitive dependencies
> > MNG-2199   WONTFIX  Support version ranges in parent elements
> > MNG-2478   WONTFIX  add "resources-filtered" filtered resource
> > directories to super POM
> > MNG-3507   WONTFIX  added support for multi-lines error message
> > with color
> > MNG-3507   WONTFIX  ANSI Color logging for improved output
> > visibility.
> > MNG-3705   WONTFIX  fixed mojo execution id color display
> > MNG-3825   WONTFIX  Dependencies with classifier should not
> > always require a version.
> > MNG-4345   WONTFIX  [regression] Plugin executions contributed
> > by default lifecycle mapping execute after
> > other plugin executions bound to the same
> > phase"
> > MNG-4347   WONTFIX  import-scoped dependencies of direct
> > dependencies are not resolved using profile
> > modifications from settings.xml
> > MNG-4463   WONTFIX  Dependency management import should support
> > version ranges.
> > MNG-4645   WONTFIX  Move central repo definition out of Maven's
> > core so it can be more easily changed.
> > MNG-5227   WONTFIX  The 'optional' flag of a dependency should
> > be manageable.
> > MNG-5297   WONTFIX  improved explanations on prerequisites.maven
> > in Maven 3
> > MNG-5359   WONTFIX  Declared execution in PluginMgmt gets bound
> > to lifecycle (regression)
> > MNG-5368   WONTFIX  UnsupportedOperationException thrown when
> > version range is not correct in
> > dependencyManagement definitions
> > MNG-5457   WONTFIX  Show repository id when downloading or
> > uploading from/to a remote repository
> > MNG-5527   WONTFIX  Relocation does not work for imported poms
> > MNG-5538   WONTFIX  mvn start script causes cygwin warning
> > MNG-5567   WONTFIX  Zip files are not included in classpaths at
> > all
> > MNG-5600   WONTFIX  Dependency management import should support
> > exclusions.
> > MNG-5607   WONTFIX  Don't use M2_HOME in mvn shell/command
> > scripts anymore
> > MNG-5629   WONTFIX  ClosedChannelException from
> > DefaultUpdateCheckManager.read
> > MNG-5639   WONTFIX  Support resolution of Import Scope POMs
> > from Repo that contains a ${parameter}
> > MNG-5639   WONTFIX  Support resolution of Import Scope POMs
> > from Repo that contains a ${parameter}
> > MNG-5661   WONTFIX  Make MavenProject instances immutable after
> > initial construction
> > MNG-5670   WONTFIX  guard against
> > ConcurrentModificationException
> > MNG-5761   WONTFIX  Dependency management is not transitive.
> > MNG-5761   WONTFIX  Dependency management is not transitive.
> > MNG-5761   WONTFIX  Dependency management is not transitive.
> > MNG-5815   WONTFIX  "mvn.cmd" does not indicate failure
> > properly when using "&&"
> > MNG-5823   WONTFIX  mvnDebug doesn't work with M2_HOME with
> > spaces - missing quotes
> > MNG-5824   WONTFIX  Closes #49 because MNG-5824 has been
> > 

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

[Christian Schulte]

Am 01/01/17 um 08:23 schrieb Christian Schulte:
> Am 01/01/17 um 08:18 schrieb Christian Schulte:
>> Once more I asked someone to test a snapshot and provided a link to
>> Jenkins. That's where all those commits come from. I hope I'll get
>> feedback on this one and that could again lead to commits. Doing this on
>> a release branch - yes - I got that.
> 
> And you do want someone grabbing that snapshot to get all changes done
> by all committers and not just some build of some personal branch which
> is lacking all other development. Let master be the release branch but
> let there be a branch all development of all committers is taking place.

Reverting things just to keep them the way they were instead of
clarifying things and finding better solutions is the worst thing you
can do, IMO.


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