Re: JIRA issues for dependency upgrades

Hi, On 27.04.20 17:10, Michael Osipov wrote: Am 2020-04-27 um 16:20 schrieb Elliotte Rusty Harold: Does the community have an consensus on whether to file JIRA tickets for minor dependency upgrades that don't require large code changes? I've been getting conflicting advice about this in code

Re: JIRA issues for dependency upgrades

Am 2020-04-27 um 16:20 schrieb Elliotte Rusty Harold: Does the community have an consensus on whether to file JIRA tickets for minor dependency upgrades that don't require large code changes? I've been getting conflicting advice about this in code reviews. Here's what our docs currently say,

Re: [jira] [Updated] (MSHARED-841) Upgrade Commons Collections to 4.2

On 2019-10-19 23:55, Sylwester Lachiewicz wrote: I always read the release notes very carefully and I don't mind seeing individual JIRA's per upgrade, even if does increase the length of the release notes. I guess others only want to see features and possibly bug fixes. Personally I like

Re: [jira] [Updated] (MSHARED-841) Upgrade Commons Collections to 4.2

Yes Robert, thank you for the suggestions - more changes of this type will be combined. Sylwester sob., 19 paź 2019 o 22:32 Robert Scholte napisał(a): > Maybe it is me, be I don't think having a separate jira issue for every > updated dependency adds value. > It makes the release notes

Re: [jira] [Updated] (MSHARED-841) Upgrade Commons Collections to 4.2

Maybe it is me, be I don't think having a separate jira issue for every updated dependency adds value. It makes the release notes unnecessary long (in a time where people already are bad readers). As a user I expect dependency updates to be part of every release. 1 Jira item would be good

Re: [jira] [Commented] (MNG-6691) Maven protocol specification

Just fyi, am aware of 3+2 oss solutions out there (the +2 are the trimmed ones) On Sat, Jul 6, 2019, 00:26 dzikoysk (JIRA) wrote: > > [ > https://issues.apache.org/jira/browse/MNG-6691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879546#comment-16879546 > ] > >

Re: [jira] [Created] (MPOM-215) Create a new parent POM to lock down plugins versions of default lifecycle bindings

work done: you can see the SNAPSHOT result at https://maven.apache.org/pom-archives/default-plugins-LATEST/ the source is currently in a maven-studies branch: https://github.com/apache/maven-studies/tree/maven-default-plugins The is the question of what version to choose and when to release

Re: [jira] [Created] (MPOM-215) Create a new parent POM to lock down plugins versions of default lifecycle bindings

ok ok, stupid me :) Le mardi 15 janvier 2019, 17:16:57 CET Stephen Connolly a écrit : > false in the executions? > > On Tue, 15 Jan 2019 at 16:04, Hervé BOUTEMY wrote: > > initial content published, as a branch in maven-studies [1] > > > > I have a few issues that currently will block any

Re: [jira] [Created] (MPOM-215) Create a new parent POM to lock down plugins versions of default lifecycle bindings

On Tue, 15 Jan 2019 17:04:27 +0100, Hervé BOUTEMY wrote: Currently, packaging plugins do nothing in general, since it's Maven core that does the job: It was a long time ago that we started this. So I guess that we started moving the configuration to the packaging-plugins, in order to

Re: [jira] [Created] (MPOM-215) Create a new parent POM to lock down plugins versions of default lifecycle bindings

false in the executions? On Tue, 15 Jan 2019 at 16:04, Hervé BOUTEMY wrote: > initial content published, as a branch in maven-studies [1] > > I have a few issues that currently will block any release: > 1. how to configure release plugin without leaking into future projects > that > will

Re: [jira] [Created] (MPOM-215) Create a new parent POM to lock down plugins versions of default lifecycle bindings

initial content published, as a branch in maven-studies [1] I have a few issues that currently will block any release: 1. how to configure release plugin without leaking into future projects that will inherit? 2. how to configure invoker also to be able to create ITs to check that it works as

Re: [jira] [Created] (MPOM-215) Create a new parent POM to lock down plugins versions of default lifecycle bindings

Introducing a new parent might help for some, but not for everybody. If you already have a parent specified, you can't use this. And Maven doesn't support mixins (yet). We need to document how plugins are controlled. These are probably all variants I can think of - pom.xml - via packaging-plugin

Re: jira contributor status?

Hi Robert! Would you mind if we continue the review on MJAVADOC-444? Per the guidance on that page you mentioned, I'd like to avoid sending multiple messages here and I have questions about the need and form for tests in this specific case. If you don't mind, I'd quote your response from here

Re: jira contributor status?

hi Sean, thank you for the patch, which already makes you a contributor. To be able to apply patches you need to be a Maven committer. If you want to become a committer, please read the Guide Commmitter School[1] In case of your patch for MJAVADOC-444, you have to focus on #2 and further.

Re: [jira] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9

Is there a way to disable this hack? I am trying to build the glassfish-corba project , which defines its own version of classes in the javax.rmi.CORBA package, and having --add-modules java.se.ee on the command line means that those classes aren’t

Re: [jira] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9

2017-09-29 10:41 GMT+02:00 Alan Bateman : > On 29/09/2017 08:57, Enrico Olivelli wrote: > >> : >> >> 2) dealing with modules like java.sql which as not in java.base ( >> http://download.java.net/java/jdk9/docs/api/java.base-summary.html) >> Currently I have no solution as

Re: [jira] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9

On 29/09/2017 08:57, Enrico Olivelli wrote: : 2) dealing with modules like java.sql which as not in java.base (http://download.java.net/java/jdk9/docs/api/java.base-summary.html) Currently I have no solution as there is no official maven dependency for java.sql package You shouldn't need to

Re: [jira] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9

Robert, Tibor, I agree with Robert that the tweak about adding --add-modules java.se.ee has really limited effect as I pointed out in another private email thread, actually the hack does not work with more than one forked JVM. My proposal is to drop that fix and document how to deal with changes

Re: [jira] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9

Hi Tibor, moving this to the dev-list, I don't think JIRA is the right place for this kind of discussions. bq. This is not a regression and not a bug in Surefire. Sorry, I don't agree with you. The Java8 project provided by Stéphane works with 2.20.0, but not with 2.20.1, so for me this

Re: [jira] [Commented] (MNG-6275) ServiceLoaderFactory can't find implementations via ClassRealm

Sorry, didn't mean to request a rollback, was merely trying to highlight areas likely affected by the change. -- Regards, Igor On Thu, Aug 24, 2017, at 12:33 PM, Robert Scholte wrote: > Hi Igor, > > moving this to dev-list. > I've asked an explanation of the Java developers team. They confirm

Re: [jira] [Commented] (MNG-6275) ServiceLoaderFactory can't find implementations via ClassRealm

Hi Igor, moving this to dev-list. I've asked an explanation of the Java developers team. They confirm that they've made a more clear separation of boot-, system- and application-classloader. They wondered why we put "null" there in the first place, because in general the boot classloader

Re: [jira] [Commented] (MRELEASE-594) release:prepare should stop when there is snapshots in dependencies management

keeps returning on the watchlist... created https://issues.apache.org/jira/browse/INFRA-13342 Robert On Mon, 16 Jan 2017 13:18:49 +0100, Robert Scholte wrote: I've removed this address from the watchlist Robert On Mon, 16 Jan 2017 13:17:26 +0100,

Re: [jira] [Commented] (MRELEASE-594) release:prepare should stop when there is snapshots in dependencies management

I've removed this address from the watchlist Robert On Mon, 16 Jan 2017 13:17:26 +0100, postmas...@wuerttembergische.de (JIRA) wrote: [

Re: [jira] [Created] (MPOM-152) Upgrade maven-checkstyle-plugin to 2.17.

There might be a corner-case here. I remember an issue about this upgrade, a dependency onmaven-shared-resourcesneeded to be added: https://issues.apache.org/jira/browse/MCHECKSTYLE-327?focusedCommentId=15383006=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15383006

Re: [jira] [Commented] (MPH-120) Migrate plugin to Maven 3.0

Am 2016-11-12 um 18:55 schrieb Guillaume Boué: Hi, Since the plugin was migrated to Maven 3, would it be possible to rename the current 2.2.1 version in JIRA to 3.0.0? This way, I can close this issue with the right fix version. Done! Le 11/11/2016 à 18:33, Hudson (JIRA) a écrit : [

Re: [jira] [Commented] (MPH-120) Migrate plugin to Maven 3.0

Hi, Since the plugin was migrated to Maven 3, would it be possible to rename the current 2.2.1 version in JIRA to 3.0.0? This way, I can close this issue with the right fix version. Thanks, Guillaume Le 11/11/2016 à 18:33, Hudson (JIRA) a écrit : [

Re: [jira] [Created] (MNG-6111) incorrect text in help:describe for cmd

Thanks Karl Heinz! Le 11/11/2016 à 17:15, Karl Heinz Marbaise a écrit : Hi Guillaume, Done so https://issues.apache.org/jira/browse/MPH-121 Kind regards Karl Heinz Marbaise On 11/11/16 16:55, Guillaume Boué wrote: This issue is for the Maven Help Plugin. Can someone move it to the MPH

Re: [jira] [Created] (MNG-6111) incorrect text in help:describe for cmd

Hi Guillaume, Done so https://issues.apache.org/jira/browse/MPH-121 Kind regards Karl Heinz Marbaise On 11/11/16 16:55, Guillaume Boué wrote: This issue is for the Maven Help Plugin. Can someone move it to the MPH JIRA? Thanks, Guillaume Le 11/11/2016 à 13:23, aaa (JIRA) a écrit : aaa

Re: [jira] [Created] (MNG-6111) incorrect text in help:describe for cmd

This issue is for the Maven Help Plugin. Can someone move it to the MPH JIRA? Thanks, Guillaume Le 11/11/2016 à 13:23, aaa (JIRA) a écrit : aaa created MNG-6111: Summary: incorrect text in help:describe for cmd Key: MNG-6111

Re: [jira] [Created] (MRESOLVER-4) Use Commons Lang's Validate to intercept invalid input

Am 10/16/16 um 23:51 schrieb Stephen Connolly: > Let's just go for Java 7... this is linked to core... if you are stuck on > an older Java likely you can't upgrade Maven anyway +1 - To unsubscribe, e-mail:

Re: [jira] [Created] (MRESOLVER-4) Use Commons Lang's Validate to intercept invalid input

Let's just go for Java 7... this is linked to core... if you are stuck on an older Java likely you can't upgrade Maven anyway On Sunday 16 October 2016, Christian Schulte wrote: > Am 10/16/16 um 22:51 schrieb Michael Osipov: > > Am 2016-10-16 um 22:48 schrieb Christian Schulte:

Re: [jira] [Created] (MRESOLVER-4) Use Commons Lang's Validate to intercept invalid input

Am 10/16/16 um 22:51 schrieb Michael Osipov: > Am 2016-10-16 um 22:48 schrieb Christian Schulte: >> Will the resolver be upgraded to Java 7? I would use 'java.util.Objects' >> then. > > I have the very same idea. I wouldn't mind using j.u.Objects instead of > o.a.c.l4.Validate. > > Is there any

Re: [jira] [Created] (MRESOLVER-4) Use Commons Lang's Validate to intercept invalid input

Am 2016-10-16 um 22:48 schrieb Christian Schulte: Will the resolver be upgraded to Java 7? I would use 'java.util.Objects' then. I have the very same idea. I wouldn't mind using j.u.Objects instead of o.a.c.l4.Validate. Is there any compelling reason not to switch to Java 7? NIO2 and

Re: [jira] [Created] (MRESOLVER-4) Use Commons Lang's Validate to intercept invalid input

Will the resolver be upgraded to Java 7? I would use 'java.util.Objects' then. Am 10/16/16 um 22:30 schrieb Michael Osipov (JIRA): > Michael Osipov created MRESOLVER-4: > -- > > Summary: Use Commons Lang's Validate to intercept invalid input >

Re: [jira] [Created] (MINSTALL-128) Replace usage of the deprecated ArtifactFactory

Hi Guillaume, the code duplication was based on the first steps I had done to move the general cases to the shared component...and it's good that you cleaned up the code in maven-install-plugin... Kind regards Karl Heinz On 08/10/16 22:06, Guillaume Boué (JIRA) wrote: Guillaume Boué

Re: [jira] [Commented] (MSHARED-594) NullPointerException is thrown when trying to install a project without POM file

Hi Buillaume, On 08/10/16 22:08, Guillaume Boué wrote: Hi, It is allowed by install:install-file when you set generatePom=false. It would install for example a JAR without any POM. It is true that you won't be able to depend on the artifact as-is... perhaps we should force generatePom=true

Re: [jira] [Commented] (MSHARED-594) NullPointerException is thrown when trying to install a project without POM file

Hi, It is allowed by install:install-file when you set generatePom=false. It would install for example a JAR without any POM. It is true that you won't be able to depend on the artifact as-is... perhaps we should force generatePom=true then? This was a corner-case that I hit for

Re: [jira] [Commented] (MSHARED-594) NullPointerException is thrown when trying to install a project without POM file

Hi Guillaume, On 08/10/16 20:30, Guillaume Boué (JIRA) wrote: When creating in-memory Maven projects with the {{ProjectBuilder}}, > it could not have a POM file: the intent is that > it only has attached artifacts and only those should get installed. Maybe I misunderstand a thing here...

Re: [jira] [Commented] (MECLIPSE-295) Eclipse plugin fails due to missing org.apache.maven.plugins:maven-eclipse-plugin:pom:test

Hi, https://issues.apache.org/jira/browse/INFRA-12591 User is blocked.. Kind regards Karl Heinz Marbaise On 09/09/16 19:34, Karl Heinz Marbaise wrote: Hi Guillaume, Done so... thanks for the hints...I thought I cought them all... If you find more just post here and I will delete them. I

Re: [jira] [Commented] (MECLIPSE-295) Eclipse plugin fails due to missing org.apache.maven.plugins:maven-eclipse-plugin:pom:test

Hi Guillaume, Done so... thanks for the hints...I thought I cought them all... If you find more just post here and I will delete them. I have already filed in a ticket for INFRA to block this user... Kind regards Karl Heinz On 09/09/16 19:03, Guillaume Boué wrote: Could someone with the

Re: [jira] [Updated] (MNG-6070) Default profile in settings.xml must not use an id possibly already in use.

Am 07/23/16 um 20:31 schrieb Karl Heinz Marbaise: > Hi Christian, > > Ok first activation problem looks like being solved I've retested this > with my example project...Thanks for fixing that... > > > But what is unclear to me why during the run information from another > profile in

Re: [jira] [Updated] (MNG-6070) Default profile in settings.xml must not use an id possibly already in use.

Am 07/23/16 um 20:31 schrieb Karl Heinz Marbaise: > Hi Christian, > > Ok first activation problem looks like being solved I've retested this > with my example project...Thanks for fixing that... > > > But what is unclear to me why during the run information from another > profile in

Re: [jira] [Updated] (MNG-6070) Default profile in settings.xml must not use an id possibly already in use.

Hi Christian, Ok first activation problem looks like being solved I've retested this with my example project...Thanks for fixing that... But what is unclear to me why during the run information from another profile in particular the one which is defined in the parent of my

Re: [jira] [Created] (MNG-6059) Important use cases not covered, as child.inherit.append.path affects all children

Wouldn't it be better to re-open MNG-5951? Does not make much sense to release 3.4 introducing this when there already is a ticket telling us it does not fit the needs. Regards, Am 07/07/16 um 12:14 schrieb Andreas Sewe (JIRA): > Andreas Sewe created MNG-6059: > -

Re: [jira] [Commented] (MNG-5987) Document the algorithm calculating the order of plugin executions.

Hi, regarding the last MNG-5987 comments. Could this be done for 3.4? Regards. Am 06/30/16 um 21:05 schrieb Christopher Tubbs (JIRA): > > [ > https://issues.apache.org/jira/browse/MNG-5987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357659#comment-15357659 > ]

Re: [jira] Michael Osipov mentioned you (JIRA)

On Sunday 17 April 2016, Stephen Connolly wrote: > So the following is not of concern to the maven project - as we do not > ship a JRE - but anyone who does ship a JRE cannot do so and ship the > annotations *claimed* to be JSR-305 Now it could very easily

Re: [jira] Michael Osipov mentioned you (JIRA)

So the following is not of concern to the maven project - as we do not ship a JRE - but anyone who does ship a JRE cannot do so and ship the annotations *claimed* to be JSR-305 This is because the JRE binary license specifically contains a clause mandating that you do not add or redefine classes

Re: [jira] [Closed] (MWAR-350) Add Skip Parameter to Skip the process

Op Tue, 26 Jan 2016 14:29:15 +0100 schreef Paul Benedict : I'm more curious of the growth of "skip" parameters of plugins. Do they exist really to skip the plugin, or are they really representative of the desire to skip an entire phase? On Jan 25, 2016 7:24 PM,

Re: [jira] [Reopened] (MNG-5227) The 'optional' flag of a dependency should be manageable.

MNG-5959 - Different wording, same use case. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org

Re: [jira] [Reopened] (MNG-5227) The 'optional' flag of a dependency should be manageable.

I believe what Christian is asserting is that if you so choose to manage the optional flag because that’s how you use a particular dependency within your multi-module application build that it should be retained. It may very well be that a set of modules need an optional dependency to compile

Re: [jira] [Reopened] (MNG-5227) The 'optional' flag of a dependency should be manageable.

Hi, What interested me is that is seems to be the intention to NOT manage the optional flag.[1] Why would you set the optional flag when using dependency management? this just means, that if you want to use this dependency, you explicitly need to set the optional to false? That doesn't feel

Re: [jira] [Reopened] (MNG-5227) The 'optional' flag of a dependency should be manageable.

Am 01/29/16 um 11:50 schrieb Robert Scholte: Hi, What interested me is that is seems to be the intention to NOT manage the optional flag.[1] It's one of those issues flagged a regression in Maven 3 which hasn't been. Maven 2 just did not have support for it. It got removed for Maven 3.0 in

Re: [jira] [Reopened] (MNG-5227) The 'optional' flag of a dependency should be manageable.

Can someone please take a look at this? MNG-5227 is already checked in (with IT) and I would not want to revert it. It is triggering a bug in Aether I just reported and provided a patch for. How to procceed? Am 01/28/16 um 17:37 schrieb Christian Schulte (JIRA): [

Re: [jira] [Closed] (MWAR-350) Add Skip Parameter to Skip the process

On Tue, Jan 26, 2016 at 8:29 AM Paul Benedict wrote: > I'm more curious of the growth of "skip" parameters of plugins. Do they > exist really to skip the plugin, or are they really representative of the > desire to skip an entire phase? > > [snip] I frequently disable a

Re: [jira] [Closed] (MWAR-350) Add Skip Parameter to Skip the process

Hi, My opinon on that is that you do not need to build actual wars(neither jar btw) at all when you are developping within Eclipse. Jetty and tomcat can run on exploded was strucure, and most others servers have some eclipse tooling. With a combination of eclipse configuration mecanism,(launch

Re: [jira] [Closed] (MWAR-350) Add Skip Parameter to Skip the process

I'm more curious of the growth of "skip" parameters of plugins. Do they exist really to skip the plugin, or are they really representative of the desire to skip an entire phase? On Jan 25, 2016 7:24 PM, "Christopher" wrote: > On Mon, Jan 25, 2016 at 2:51 PM, Robert Scholte

Re: [jira] [Closed] (MWAR-350) Add Skip Parameter to Skip the process

Am 2016-01-26 um 12:05 schrieb Adrien Rivard: Hi, My opinon on that is that you do not need to build actual wars(neither jar btw) at all when you are developping within Eclipse. Jetty and tomcat can run on exploded was strucure, and most others servers have some eclipse tooling. With a

Re: [jira] [Closed] (MWAR-350) Add Skip Parameter to Skip the process

Hi, I really wonder why it is useful to add a skip-parameter to the packaging plugin? The goal for every Maven project is to end up with some (packaged) artifact, right? A skip-parameter because a lot of other plugins have it as well is IMHO not a good reason, so what would be a valid

Re: [jira] [Closed] (MWAR-350) Add Skip Parameter to Skip the process

There are cases where one could use a profile to build a custom assembly of the war (say, like with jetty runner to run under a given paas), and attaching just the relevant classes / assets, thus saving time. -- -- Aldrin Leal, / http://about.me/aldrinleal On Mon, Jan 25,

Re: [jira] [Closed] (MWAR-350) Add Skip Parameter to Skip the process

UAT module which is war for easy overlay of the main WAR module but without double-pushing your (fat) war into the upstream repository? On Mon, Jan 25, 2016 at 2:51 PM, Robert Scholte wrote: > Hi, > > I really wonder why it is useful to add a skip-parameter to the packaging

Re: [jira] [Closed] (MWAR-350) Add Skip Parameter to Skip the process

Op Mon, 25 Jan 2016 20:55:09 +0100 schreef jieryn : UAT module which is war for easy overlay of the main WAR module but without double-pushing your (fat) war into the upstream repository? Both install:install and deploy:deploy have skip parameters for that reason. AFAIK

Re: [jira] [Closed] (MWAR-350) Add Skip Parameter to Skip the process

Op Mon, 25 Jan 2016 20:54:20 +0100 schreef Aldrin Leal : There are cases where one could use a profile to build a custom assembly of the war (say, like with jetty runner to run under a given paas), and attaching just the relevant classes / assets, thus saving time.

Re: [jira] [Closed] (MWAR-350) Add Skip Parameter to Skip the process

2016-01-25 21:39 GMT+01:00 Robert Scholte : > Op Mon, 25 Jan 2016 21:05:58 +0100 schreef Romain Manni-Bucau < > rmannibu...@gmail.com>: > > Nothing prevents to build 2 or more wars with slightly different resources. >> Being able to skip one would be useful. >> > > That

Re: [jira] [Closed] (MWAR-350) Add Skip Parameter to Skip the process

Am 2016-01-25 um 20:51 schrieb Robert Scholte: Hi, I really wonder why it is useful to add a skip-parameter to the packaging plugin? The goal for every Maven project is to end up with some (packaged) artifact, right? A skip-parameter because a lot of other plugins have it as well is IMHO not a

Re: [jira] [Closed] (MWAR-350) Add Skip Parameter to Skip the process

Nothing prevents to build 2 or more wars with slightly different resources. Being able to skip one would be useful. Le 25 janv. 2016 20:58, "Robert Scholte" a écrit : > Op Mon, 25 Jan 2016 20:55:09 +0100 schreef jieryn : > > UAT module which is war for

Re: [jira] [Closed] (MWAR-350) Add Skip Parameter to Skip the process

On Mon, Jan 25, 2016 at 2:51 PM, Robert Scholte wrote: > Hi, > > I really wonder why it is useful to add a skip-parameter to the packaging > plugin? The goal for every Maven project is to end up with some (packaged) > artifact, right? > A skip-parameter because a lot of

Re: [jira] [Commented] (MNG-5878) Subversion SCM module URLs incorrectly build when module name != artifactId

it was, I removed it Regards, Hervé Le jeudi 27 août 2015 09:42:40 Karl Heinz Marbaise a écrit : Hi, is this jira issue on a watcher for Dev list ? Kind regards Karl Heinz On 8/27/15 4:39 AM, Jason van Zyl (JIRA) wrote: [

Re: [jira] [Commented] (MNG-5878) Subversion SCM module URLs incorrectly build when module name != artifactId

Hi, is this jira issue on a watcher for Dev list ? Kind regards Karl Heinz On 8/27/15 4:39 AM, Jason van Zyl (JIRA) wrote: [ https://issues.apache.org/jira/browse/MNG-5878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14715970#comment-14715970 ]

Re: [jira] [Moved] (MNG-5878) Subversion SCM module URLs incorrectly build when module name != artifactId

On 27 August 2015 at 05:02, Hervé Boutemy (JIRA) j...@apache.org wrote: Say you have this project structure: {noformat} / |-- module1 |-- module2 {noformat} and artifactIds are named: {noformat} my-parent |-- my-module1 |-- my-module2 {noformat} Prefix {{my-}}

Re: [jira] [Moved] (MNG-5878) Subversion SCM module URLs incorrectly build when module name != artifactId

Le jeudi 27 août 2015 06:36:09 Barrie Treloar a écrit : On 27 August 2015 at 05:02, Hervé Boutemy (JIRA) j...@apache.org wrote: Say you have this project structure: {noformat} / |-- module1 |-- module2 {noformat} and artifactIds are named: {noformat}

Re: JIRA Issues

I think I'm the culprit: I was not following issues@m.a.o and tried to add maven-dev list as watcher of some issues but now that I'm subscribed to issues@m.a.o, I see that it was a bad idea I'll remove maven-dev from watchers, sorry Regards, Hervé Le samedi 15 août 2015 10:37:40 Karl Heinz

Re: JIRA Issues

Hi Hervé, On 8/15/15 10:50 PM, Hervé BOUTEMY wrote: I think I'm the culprit: I was not following issues@m.a.o and tried to add maven-dev list as watcher of some issues but now that I'm subscribed to issues@m.a.o, I see that it was a bad idea I'll remove maven-dev from watchers, sorry No

Re: [jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)

@maven.apache.org Envoyé: Mercredi 12 Août 2015 02:31:33 Objet: Re: [jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git) This is pretty much required whenever one uses a VCS which is not Subversion. Everything in Maven having

Re: [jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)

This is pretty much required whenever one uses a VCS which is not Subversion. Everything in Maven having to do with SCMs is very subversion-centric in that: 1. By default, maven appends module names (not artifactIDs) to parent projects's SCM URLs to form the SCM URL of a child. This does

Re: Jira Permissions

@maven.apache.org, Petar Tahchiev paranoia...@gmail.com Cc: Brian Fox bri...@infinity.nu Envoyé: Vendredi 7 Août 2015 10:05:36 Objet: Re: Jira Permissions Hi Peter, since the Maven project has such a large number of Jira projects, they've asked us to nominate someone to do it on their behalf. So Brian

Re: Jira Permissions

Hi Peter, since the Maven project has such a large number of Jira projects, they've asked us to nominate someone to do it on their behalf. So Brian Fox is the one who is assigned to do this. Right now he's for a week on tour for Sonatype in Europe, so give it a bit more time. thanks,

Re: Jira access for new committer

Added simpligility to maven-dev On Wed, Jun 24, 2015 at 12:38 AM, Barrie Treloar baerr...@gmail.com wrote: I've pinged Brian to have a look. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands,

Re: Jira access for new committer

Thanks Brian. That worked and allowed me to close my first issue after fixing it ;-) Brian Fox wrote on 24.06.2015 04:31: Added simpligility to maven-dev On Wed, Jun 24, 2015 at 12:38 AM, Barrie Treloar baerr...@gmail.com wrote: I've pinged Brian to have a look.

Re: Jira access for new committer

On 24 June 2015 at 07:27, Manfred Moser manf...@simpligility.com wrote: Hello all, Thanks to your support I am now a new committer and would like to get the ball rolling. I have subscribed to all the mailing lists and followed the various ASF committer/developer docs. I have also done my

Re: Jira access for new committer

Barrie Treloar wrote on 23.06.2015 20:25: On 24 June 2015 at 07:27, Manfred Moser manf...@simpligility.com wrote: Now that we are on Apache infrastructure any instructions that existed will be out of date and needing some love and attention. Fair enough. Thing is .. I did not even find

Re: Jira access for new committer

On 24 June 2015 at 07:27, Manfred Moser manf...@simpligility.com wrote: Anyone know what I have to do to either get the simpligility account configured with more access rights (adding some roles) so I can manage manage JIRA issue for site, plugins, core and so on or otherwise how to access an

Re: Jira access for new committer

I've pinged Brian to have a look.

Re: [jira] [Commented] (MINVOKER-187) Cloned IT project must be writable

I am a bit surprised the proposed fix does the trick; I thought perforce checked out *every file* read only ? Kristian 2015-06-19 17:22 GMT+02:00 Karl Heinz Marbaise (JIRA) j...@apache.org: [

Re: [jira] [Commented] (MINVOKER-187) Cloned IT project must be writable

Perforce checks out fiel with only, maven invoker 1.10 copy file over to target and keep the permission intact ( not with 1.9), and test file sine some test modified the readonly file btw, the fix uses java 6 API -Dan On Fri, Jun 19, 2015 at 10:08 AM, Kristian Rosenvold

Re: Jira codehaus redirect rules

I'm going to do something similar for Mojohaus now... On Thu, Jun 4, 2015 at 8:43 AM, Olivier Lamy ol...@apache.org wrote: all done. Olivier On 4 June 2015 at 15:22, Hervé BOUTEMY herve.bout...@free.fr wrote: Hi, the full list is here: https://issues.apache.org/jira/browse/INFRA-9116

Re: Jira codehaus redirect rules

all done. Olivier On 4 June 2015 at 15:22, Hervé BOUTEMY herve.bout...@free.fr wrote: Hi, the full list is here: https://issues.apache.org/jira/browse/INFRA-9116 Regards, Hervé Le mardi 2 juin 2015 22:02:35 Olivier Lamy a écrit : Hi, There is a redirect file for jira @ codehaus

Re: Jira codehaus redirect rules

I've created a pull request for all Maven releated JIRA projects that are now hosted at ASF: https://github.com/codehaus/redirector/pull/8 On Thu, Jun 4, 2015 at 7:22 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Hi, the full list is here: https://issues.apache.org/jira/browse/INFRA-9116

Re: Jira codehaus redirect rules

Hi, the full list is here: https://issues.apache.org/jira/browse/INFRA-9116 Regards, Hervé Le mardi 2 juin 2015 22:02:35 Olivier Lamy a écrit : Hi, There is a redirect file for jira @ codehaus See https://github.com/codehaus/redirector/blob/master/includes/jira.codehaus.or g.inc ATM

Re: [jira] (MSTAGE-10) Adds support for non-CommandExecutor Wagon implementations

Hi, On 2/2/15 10:15 AM, Michael Osipov wrote: Hi Karl Heinz, I am aware of the retirement plan. If i take a look into some of jira's it does not look like you are aware of the procedure, cause you have closed issues with the comment: Project has been retired, closing as won't fix. which

Re: [jira] (MSTAGE-10) Adds support for non-CommandExecutor Wagon implementations

Hi Michael, If you like to prepare a list of plugins which should be retired it's a good idea but this should be shared on the DEV list before changing the JIRA in that way... furthermore only mark retired project in Jira AFTER the project has VOTEd accordingly... Apart from that i'm

Re: Re: [jira] (MSTAGE-10) Adds support for non-CommandExecutor Wagon implementations

Hi Karl Heinz, I am aware of the retirement plan. This is the procedure I will go. Anyawy, I will post the list first to figure out which plugins are really dead. Sorry on my part. Michael Hi Michael, If you like to prepare a list of plugins which should be retired it's a good idea but

Re: [jira] (MSTAGE-10) Adds support for non-CommandExecutor Wagon implementations

Project retired?? Where is the vote for that? I'm using it sometimes so I will be very happy to not see it retired... Cheers Olivier On 1 February 2015 at 09:08, Michael Osipov (JIRA) j...@codehaus.org wrote: [

Re: [jira] (MSTAGE-10) Adds support for non-CommandExecutor Wagon implementations

Am 2015-02-02 um 03:35 schrieb Olivier Lamy: Project retired?? Where is the vote for that? I'm using it sometimes so I will be very happy to not see it retired... Salut Olivier, I have performed a cleanup on JIRA in the last couple of days. Moreover, I have prepared a list of projects I'd

Re: JIRA projects for Maven

Sounds nice. Presumably, we can retain JIRA admin privileges for the current CodeHaus projects after the move to ASF JIRA? Or maybe create anew? I have/require admin privs for the Plugin Projects I'm stewarding on the CodeHaus JIRA, but am pretty certain I have no admin privs on the ASF JIRA.

Re: JIRA projects for Maven

The JIRA projects for the mojo plugins will stay with mojo at codehaus. The move is only for the ASF hosted code related projects On 8 January 2015 at 11:29, Lennart Jörelid lennart.jore...@gmail.com wrote: Sounds nice. Presumably, we can retain JIRA admin privileges for the current CodeHaus

Re: JIRA projects for Maven

On 8 January 2015 at 06:40, Hervé BOUTEMY herve.bout...@free.fr wrote: Le mercredi 7 janvier 2015 08:52:07 Tony Stevenson a écrit : On 7 January 2015 at 07:20, Hervé BOUTEMY herve.bout...@free.fr wrote: ok who can prepare a little VM with Jira 6.3.4? Can infra? We cab, but it wont be

Re: JIRA projects for Maven

I got Ben to agree to taking a trial dump this weekend. He will send Hervé the details of the dump. Hervé can then see what is involved in doing the migration. If Hervé feels that the migration is something that can be handled, then we can schedule with Ben to lock all the projects, do the

Re: JIRA projects for Maven

Great! Thank you Stephen, this is a good plan: I'll get the trial dump and share the results of importing it on my local machine. Regards, Hervé Le jeudi 8 janvier 2015 10:00:37 Stephen Connolly a écrit : FYI the last dump (2 years ago) was 1.2G... so Hervé you are in for a big download!

Re: JIRA projects for Maven

here is the precise list of Jira projects we'll migrate: https://github.com/khmarbaise/jira-asf-migration/blob/master/project.list Regards, Hervé Le jeudi 8 janvier 2015 11:42:54 Stephen Connolly a écrit : The JIRA projects for the mojo plugins will stay with mojo at codehaus. The move is

Re: JIRA projects for Maven

On 7 January 2015 at 08:52, Tony Stevenson t...@pc-tony.com wrote: On 7 January 2015 at 07:20, Hervé BOUTEMY herve.bout...@free.fr wrote: ok who can prepare a little VM with Jira 6.3.4? Can infra? We cab, but it wont be soon. We are extremely busy right now. I'd imagine it would be a

  1   2   3   4   5   6   7   8   9   >