Re: Maven Security, @Component and MNG-4384

[Chris Graham]

Thanks all, I will investigate!

On Mon, Jun 24, 2019 at 10:12 PM Romain Manni-Bucau 
wrote:

> Here is what i'm using:
>
>  @Parameter(property = "myplugin.repository")
>  private String repository;
>
>  @Parameter(defaultValue = "${session}", readonly = true)
>  private MavenSession session;
>
>  @Component
>  private SettingsDecrypter settingsDecrypter;
>
>  void someMethod() {
>  Server credentials =
> session.getSettings().getServer(repository);
>  if (credentials != null) {
>  credentials =
>  ofNullable(settingsDecrypter.decrypt(new
> DefaultSettingsDecryptionRequest(credentials)))
>
>  .map(SettingsDecryptionResult::getServer) // can be null if it does not
> need decryption
>  .orElse(credentials);
>  }
> }
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le lun. 24 juin 2019 à 12:34, Martin Gainty  a écrit
> :
>
> >   
> >   server001
> >   my_login
> >   my_password
> >   ${user.home}/.ssh/id_dsa
> >   some_passphrase
> >   664
> >   775
> >   
> > 
> >
> > from ${MAVEN_HOME}/conf/settings.xml
> >
> >
> >
> https://maven.apache.org/ref/3.3.9/maven-settings-builder/apidocs/org/apache/maven/settings/crypto/SettingsDecryptionRequest.html#setServers(java.util.List)
> >
> > so your
> > org.apache.maven.settings.crypto.SettingsDecryptionRequest.setServers
> needs
> > to gather up
> > the list of server ids from {MAVEN_HOME}/conf/settings.xml
> >
> > not so clear as javadoc is missing from maven-settings-builder
> > site..romain can you post this info on
> > http://maven.apache.org/ref/3.6.1/maven-settings-builder/
> >
> > ?
> > thanks
> >
> > 
> > From: Romain Manni-Bucau 
> > Sent: Monday, June 24, 2019 1:11 AM
> > To: Maven Developers List
> > Subject: Re: Maven Security, @Component and MNG-4384
> >
> > Hi
> >
> > Did you have a look to
> org.apache.maven.settings.crypto.SettingsDecrypter?
> >
> > It can be injected as a component then you can call decrypt on it
> passing a
> > request to the method. You get a new null server if it is not encrypted
> or
> > the new server with everything in clear.
> >
> > Would that work better for you?
> >
> > Romain
> >
> > Le lun. 24 juin 2019 à 03:31, Chris Graham  a
> écrit
> > :
> >
> > > Hi everyone,
> > >
> > > I need to add the ability to load users, passwords etc in a 3rd party
> > > plugin.
> > >
> > > It currently requires a userid and password in the 
> > section
> > > of the pom (ugh), ideally, I'd like to look them up from the 
> > > section of settings.xml, and even better yet, make use of being able to
> > > decrypt passwords.
> > >
> > > So I did what we all do, and go and look to see what has been done
> > before,
> > > and I came across this:
> > >
> > >
> > >
> >
> /maven-scm/maven-scm-plugin/src/main/java/org/apache/maven/scm/plugin/AbstractScmMojo.java:
> > >
> > > /**
> > >  * When this plugin requires Maven 3.0 as minimum, this component
> can
> > > be removed and o.a.m.s.c.SettingsDecrypter be
> > >  * used instead.
> > >  */
> > > @Component( hint = "mng-4384" )
> > > private SecDispatcher secDispatcher;
> > >
> > > and:
> > >
> > >
> > >
> >
> /maven-scm/maven-scm-plugin/src/main/resources/META-INF/plexus/components.xml:
> > >
> > > 
> > >   
> > > 
> > >
> > >
> org.sonatype.plexus.components.sec.dispatcher.SecDispatcher
> > >   mng-4384
> > >
> > >
> > >
> >
> org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher
> > >   
> > > 
> > >
>  org.sonatype.plexus.components.cipher.PlexusCipher
> > >   mng-4384
> > >   _cipher
> > > 
> > >   
> > >   
> > >
> > > <_configuration-file>~/.m2/settings-security.xml
> > >   
> > > 
> > > 
> > >   org.sonatype.plexus.components.cipher.PlexusCipher
> > >   mng-4384
> > >
> > >
> > >
> >
> org.sonatype.plexus.components.cipher.DefaultPlexusCipher
> > > 
> > >   
> > > 
> > >
> > > So, I'm left with the question, what is the current, correct way of
> > > accessing userids, passwords (encrypted or not)?
> > >
> > > I could simply, copy the same approach, but I'd prefer not too, as
> it's a
> > > good opportunity 'to do it right'.
> > >
> > > Any suggestions?
> > >
> > > Would we then consider updating the existing maven plugins to support
> > this?
> > >
> > > @Stephen, sounds like a good idea for a blog entry? ;)
> > >
> >
>

Maven Security, @Component and MNG-4384

[Chris Graham]

Hi everyone,

I need to add the ability to load users, passwords etc in a 3rd party
plugin.

It currently requires a userid and password in the  section
of the pom (ugh), ideally, I'd like to look them up from the 
section of settings.xml, and even better yet, make use of being able to
decrypt passwords.

So I did what we all do, and go and look to see what has been done before,
and I came across this:

/maven-scm/maven-scm-plugin/src/main/java/org/apache/maven/scm/plugin/AbstractScmMojo.java:

/**
 * When this plugin requires Maven 3.0 as minimum, this component can
be removed and o.a.m.s.c.SettingsDecrypter be
 * used instead.
 */
@Component( hint = "mng-4384" )
private SecDispatcher secDispatcher;

and:

/maven-scm/maven-scm-plugin/src/main/resources/META-INF/plexus/components.xml:


  


org.sonatype.plexus.components.sec.dispatcher.SecDispatcher
  mng-4384

org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher
  

  org.sonatype.plexus.components.cipher.PlexusCipher
  mng-4384
  _cipher

  
  

<_configuration-file>~/.m2/settings-security.xml
  


  org.sonatype.plexus.components.cipher.PlexusCipher
  mng-4384

org.sonatype.plexus.components.cipher.DefaultPlexusCipher

  


So, I'm left with the question, what is the current, correct way of
accessing userids, passwords (encrypted or not)?

I could simply, copy the same approach, but I'd prefer not too, as it's a
good opportunity 'to do it right'.

Any suggestions?

Would we then consider updating the existing maven plugins to support this?

@Stephen, sounds like a good idea for a blog entry? ;)

Re: Building Javadocs and site on CI

[Chris Graham]

I am used to running mvn clean install site on my Jenkins build jobs and then 
let the Jenkins checkstyle, find bugs etc plugins display the results/trends 
over builds.

And I thought the ASF Jenkins used to have this feature.

Are there any plans to restore this?

Also, I attempted to build all of the asf maven tepid yesterday, under JDK 7, 
and some failed, e.g. Surefire needed JDK 8.

Have we moved from a minimum of JDK 7?



Sent from my iPhone

> On 30 Dec 2018, at 9:47 pm, Robert Scholte  wrote:
> 
>> On Sat, 29 Dec 2018 13:12:36 +0100, Hervé BOUTEMY  
>> wrote:
>> 
>> Le samedi 29 décembre 2018, 11:29:53 CET Robert Scholte a écrit :
>>> I've already introduces the concept of "plans"[1][2], which also include
>>> 'site' for documentation and 'release' to verify if the project is
>>> releasable (should probably change that name to prevent confusion).
>> +1 to change the name of "release" to something like "check-release"
> 
> or release-dryRun
> 
>> 
>>> The jobs are getting more stable, so we might give it a try soon. Just
>>> need to be aware that the 'site' plan doesn't seem to work for multimodule
>>> projects yet. Better fix that first.
>> why doesn't it work? what does "don't work" mean? fail?
>> 
>> I just see "site:stage" missing to have multi-module assembled: would not
>> cause any harm for non-multi-modules
> 
> That might be the reason, I'll add that.
> 
>> 
>> additional question: once the site is build on Jenkins, can it be browsed?
> 
> I guess so.
> 
> Once INFRA-17514 is fixed I'll enable the site-plan too.
> 
> thanks,
> Robert
> 
> [1] https://issues.apache.org/jira/browse/INFRA-17514
> 
>> 
>> Regards,
>> 
>> Hervé
>> 
>>> 
>>> thanks,
>>> Robert
>>> 
>>> [1]
>>> https://gitbox.apache.org/repos/asf?p=maven-jenkins-lib.git;a=blob;f=vars/as
>>> fMavenTlpPlgnBuild.groovy;h=6502fe80819c873757e339a0f1b3186fd14303b9;hb=HEAD
>>> #l63 [2]
>>> https://gitbox.apache.org/repos/asf?p=maven-jenkins-lib.git;a=blob;f=vars/as
>>> fMavenTlpPlgnBuild.groovy;h=6502fe80819c873757e339a0f1b3186fd14303b9;hb=HEAD
>>> #l132
>>> 
>>> 
>>> On Sat, 29 Dec 2018 09:14:27 +0100, Enrico Olivelli 
>>> 
>>> wrote:
>>> > Hi guys,
>>> > I am trying to release Maven Assembly Plugin and I see that there are
>>> > a few showstoppers due to javadocs and site generation.
>>> > Isn't it possible to run  "javadoc:javadoc site" on CI ?
>>> >
>>> > This way we won't commit broken/unreleasable stuff
>>> >
>>> > Enrico
>>> >
>>> > -
>>> > 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
>> 
>> 
>> 
>> 
>> 
>> -
>> 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
> 

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

maven site generation: mvn clean install site

[Chris Graham]

Hi everyone,

I was doing some work on maven-release and I ran 'mvn clean install site'
on it (as I usually do), and the build fails with a velocity parsing error.

The fix was simple: upgrade fluido-skins from 1.3.1 to 1.7 in site.xml.

Looking at the jenkins build jobs, it looks like the site command is not
being run anymore (and the checkstyle etc reports are also not being run).
Apologies for playing catch up, but, did I miss something?

What is the expected state of the site output?

What is/is not meant to be run and reported upon via the site command?

TIA.

-Chris

Jenkins URL's

[Chris Graham]

Hi Everyone,

I've finally managed to get back to some maven dev work! :)

In looking through the pom's I can see that some of the links for Jira and
Jenkins are broken.

Have the jenkins servers and jobs finally established a final URL?

For example, the maven-release plugin:

current git value:

  
Jenkins
https://builds.apache.org/job/maven-release/
  

current jenkins value (proposed change):

  
Jenkins
https://builds.apache.org/job/maven-box/job/maven-release/
  

Some of the other plugins also use a view as well.

I'm happy to go through them all and update to what is necessary, but I
need to know if the current URL's are going to remain stable.

-Chris

Re: Build vs Consumer POM study

[Chris Graham]

If I've read through (and understood !!!) this thread correctly, then I'd
like to add this:

As the discussions reflect the mature (read: wierd and wonderful!) ways
that Maven is being used, then it is looking like more and more edge cases
are coming up (eg, profiles), and that would appear to reduce the need for
(ie increase the complexity) a consumer pom.

Personally, I am not convinced that it is a good idea. Keep the pom, work
with what you need and ignore the bits that you don't. Only the developer
of the module will really want to read  section, the rest of us
consume it and just list it as a depency.

We are adding complexity (and certainly a lot of potential confusion!), and
adding complexity is rarely a good thing as it just tends to break more
things.


On Wed, Apr 18, 2018 at 3:47 AM, Jörg Schaible 
wrote:

> Hi Mirko,
>
> On Tue, 17 Apr 2018 04:44:57 + Mirko Friedenhagen wrote:
>
> > Hello Jörg,
> >
> > I understand your problem, however this is quite specific. AFAIK
> > currently profiles are *not* evaluated while resolving imported
> > dependencies, only those inherited, so this would be a very drastic
> > change.
>
> Well, the import scope is special anyway, but I agree, that dependency
> resolution should not make a
> difference if you use this compared to a "normal" (transitive) dependency.
>
> > For your eclipse example: maybe put OS specific stuff in modules and
> > mark them as optional while importing?
>
> If SWT is not optional, your user's might be quite surprised if it had
> been declared optional. But I do not like
> this situation also.
>
> Cheers,
> Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven 4.0.0

[Chris Graham]

One more: Better support for classifiers. ideally be able to reference them
via a {$project.classifier} type of construct, esp so I can use/reference
them in assemble transformations.

This might be able to be done without bumping to V4 though.



On Sun, Nov 12, 2017 at 6:41 PM, Chris Graham  wrote:

> required:
>  - *everything* in settings.xml can be put in a profile section in
> settings.xml.
>
> I often move around/between projects and having to redo mirrors section,
> and unable to add servers into the profile section for clarity is a pain.
>
> For me, it's just a matter of convienence.
>
> On Sat, Nov 4, 2017 at 11:20 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> The past two days, Hervé, Robert and I have been discussing our next
>> steps.
>>
>> I think we have a semi-consensus which I want to bring back to the list:
>>
>> We keep 3.5.x as a stable branch with critical bug fixes only
>>
>> We switch master to 4.0.0 and start to burn down a release scope.
>>
>> 4.0.0 will not change the pom modelVersion
>>
>> The 4.0.0 scope should probably be:
>>
>> Required:
>> * drop Java 7, switch codebase to Java 8 idioms (while maintaining binary
>> api compatibility for plugins)
>> * specify the classloader behaviour and fix impl to align with spec (may
>> need a plugin flag to allow plugins to opt in to spec behaviour)
>> * specify the extension spec
>> * allow limited mutation of the runtime model (reducing transitive
>> dependencies for consumers within the reactor, only for plugin goals that
>> declare intent) use case: shade plugin
>> * better CI integration hooks
>> * nice error message for newer pom modelVersion
>>
>> Optional:
>> * (damn I forgot, maybe Robert remembers)
>> --
>> Sent from my phone
>>
>
>

Re: Maven 4.0.0

[Chris Graham]

required:
 - *everything* in settings.xml can be put in a profile section in
settings.xml.

I often move around/between projects and having to redo mirrors section,
and unable to add servers into the profile section for clarity is a pain.

For me, it's just a matter of convienence.

On Sat, Nov 4, 2017 at 11:20 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> The past two days, Hervé, Robert and I have been discussing our next steps.
>
> I think we have a semi-consensus which I want to bring back to the list:
>
> We keep 3.5.x as a stable branch with critical bug fixes only
>
> We switch master to 4.0.0 and start to burn down a release scope.
>
> 4.0.0 will not change the pom modelVersion
>
> The 4.0.0 scope should probably be:
>
> Required:
> * drop Java 7, switch codebase to Java 8 idioms (while maintaining binary
> api compatibility for plugins)
> * specify the classloader behaviour and fix impl to align with spec (may
> need a plugin flag to allow plugins to opt in to spec behaviour)
> * specify the extension spec
> * allow limited mutation of the runtime model (reducing transitive
> dependencies for consumers within the reactor, only for plugin goals that
> declare intent) use case: shade plugin
> * better CI integration hooks
> * nice error message for newer pom modelVersion
>
> Optional:
> * (damn I forgot, maybe Robert remembers)
> --
> Sent from my phone
>

Re: Question...concerning classifier

[Chris Graham]

That is pretty much what I'd come up with too. Thanks!

Sent from my iPad

> On 7 Sep 2017, at 6:25 pm, Stephen Connolly  
> wrote:
> 
> Classifieds are limited to the same character set as s and
> s for the same reason that they will form part of the filename.
> 
>> On Thu 7 Sep 2017 at 08:26, Chris Graham  wrote:
>> 
>> Hi Karl,
>> 
>> Did you ever find what you were looking for?
>> 
>> I came across this in a search on classifiers as I want to be able to
>> access them as a part of a filter/transformation when the assemble plugin
>> does it's job.
>> 
>> I am finding that classifiers are not well documented their usage at all!
>> :-(
>> 
>> Sent from my iPhone
>> 
>>> On 29 Dec 2015, at 5:33 am, Karl Heinz Marbaise 
>> wrote:
>>> 
>>> Hi Tibor,
>>> 
>>>> On 12/28/15 7:22 PM, Tibor Digana wrote:
>>>> Hm, classifiers in plugins, not really used at all. Dependencies yes. I
>>>> guess classifier is more overhead and evil than benefit.
>>> 
>>> If you build for several environments than you need classifiers (e.g.
>> with maven-assembly-plugin), maven-jar-plugin (test-jar, jar),
>> maven-deploy-plugin, maven-source-plugin, maven-javadoc-plugin..just
>> mention some examples.. etc...i wouldn't call it evil...
>>> 
>>>> I remember Maven docu talked about classifier jdk1.5 as an example and
>>>> maybe environment specifics, but I guess it was the only examples in the
>>>> tutorial.
>>> 
>>> Yes that's what i know of as well...
>>> 
>>>> Regarding valid characters in classifier - no idea if any exists.
>>> 
>>> Exactly that's what i'm searching for...
>>> 
>>> 
>>>> 
>>>> On Mon, Dec 28, 2015 at 7:12 PM, Karl Heinz Marbaise >>> <mailto:khmarba...@gmx.de>> wrote:
>>>> 
>>>>   Hi,
>>>> 
>>>>   during my implementations i have come to the conclusion if someone
>>>>   sets a classifier for the execution of a plugin...it would be useful
>>>>   to check the validity of the classifier...
>>>> 
>>>>   Based on that i started to search but unfortunately i didn't found a
>>>>   definition etc. documentation how a valid classifier looks like or
>>>>   the inverse what it does not allowed to be..
>>>> 
>>>>   So does someone know of any kind of definition how a valid
>>>>   classifier looks like? Some kind of reference ?
>>>> 
>>>>   Kind regards
>>>>   Karl Heinz Marbaise
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>> --
> Sent from my phone

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

Re: Question...concerning classifier

[Chris Graham]

Hi Karl,

Did you ever find what you were looking for?

I came across this in a search on classifiers as I want to be able to access 
them as a part of a filter/transformation when the assemble plugin does it's 
job.

I am finding that classifiers are not well documented their usage at all! :-(

Sent from my iPhone

> On 29 Dec 2015, at 5:33 am, Karl Heinz Marbaise  wrote:
> 
> Hi Tibor,
> 
>> On 12/28/15 7:22 PM, Tibor Digana wrote:
>> Hm, classifiers in plugins, not really used at all. Dependencies yes. I
>> guess classifier is more overhead and evil than benefit.
> 
> If you build for several environments than you need classifiers (e.g. with 
> maven-assembly-plugin), maven-jar-plugin (test-jar, jar), 
> maven-deploy-plugin, maven-source-plugin, maven-javadoc-plugin..just mention 
> some examples.. etc...i wouldn't call it evil...
> 
>> I remember Maven docu talked about classifier jdk1.5 as an example and
>> maybe environment specifics, but I guess it was the only examples in the
>> tutorial.
> 
> Yes that's what i know of as well...
> 
>> Regarding valid characters in classifier - no idea if any exists.
> 
> Exactly that's what i'm searching for...
> 
> 
>> 
>> On Mon, Dec 28, 2015 at 7:12 PM, Karl Heinz Marbaise > > wrote:
>> 
>>Hi,
>> 
>>during my implementations i have come to the conclusion if someone
>>sets a classifier for the execution of a plugin...it would be useful
>>to check the validity of the classifier...
>> 
>>Based on that i started to search but unfortunately i didn't found a
>>definition etc. documentation how a valid classifier looks like or
>>the inverse what it does not allowed to be..
>> 
>>So does someone know of any kind of definition how a valid
>>classifier looks like? Some kind of reference ?
>> 
>>Kind regards
>>Karl Heinz Marbaise
> 
> -
> 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

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

[Chris Graham (JIRA)]

[ 
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14698029#comment-14698029
 ] 

Chris Graham edited comment on MPIR-234 at 8/15/15 2:16 AM:


>> It should not be displayed, or inferred from any other (ie sub module) 
>> location.
>If you are looking at a module's site and you have to go changing it, you want 
>to know how to check out that module.

Perhaps I was not clear, or you missed my point.

Which is: In some SCM's checking out a sub module, it is impossible. It's an 
all or nothing operation, not a cherry picking one.

>So there should be a "Source Repository" for sub-modules.

No there should not. Or, at best, it is only meaningful for those SCM's that 
can support it.

All you are doing in your example is cloning the entire repo [you cann't 
not] and then checking out (-b) the branch. How is this a sub module?



was (Author: chrisgwarp):
>> It should not be displayed, or inferred from any other (ie sub module) 
>> location.
>If you are looking at a module's site and you have to go changing it, you want 
>to know how to check out that module.

Perhaps I was not clear, or you missed by point.

Which is: In some SCM's checking out a sub module, it is impossible. It's an 
all or nothing operation, not a cherry picking one.

>So there should be a "Source Repository" for sub-modules.

No there should not. Or, at best, it is only meaningful for those SCM's that 
can support it.

All you are doing in your example is cloning the entire repo [you cann't 
not] and then checking out (-b) the branch. How is this a sub module?


> SCM-link in site of multimodule projects should not append module name by 
> default (at least for git)
> 
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
>  Issue Type: Bug
>  Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see 
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex) 
> which uses git on github as {{scm}}. While rendering the site, MPIR will by 
> default add the name of the module to the SCM-URLs in source-repository.html. 
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see 
> https://github.com/mfriedenhagen/multi-module-sample/core/, 
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and 
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for 
> the core module. All these URLs are invalid. For SVN this could be assumed to 
> be the right behaviour, for git and probably other SCMs this is not true. As 
> a workaround I have to reconfigure the scm section (see 
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
>  in the modules like this:
> {code:xml}
> 
>   ${project.parent.scm.connection}
>   
> ${project.parent.scm.developerConnection}
>   ${project.parent.scm.url}
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

[Chris Graham (JIRA)]

[ 
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14698032#comment-14698032
 ] 

Chris Graham commented on MPIR-234:
---

+1

Making the URL's longer just increases the complexity of the existing parsing 
code (which in some cases, is already complex enough).

Add more elements.

And if your going to do that, I'd say that it's time to start looking at SCM 
API 2.0 and making it MORE abstracted (not less).

It's not all about Git...



> SCM-link in site of multimodule projects should not append module name by 
> default (at least for git)
> 
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
>  Issue Type: Bug
>  Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see 
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex) 
> which uses git on github as {{scm}}. While rendering the site, MPIR will by 
> default add the name of the module to the SCM-URLs in source-repository.html. 
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see 
> https://github.com/mfriedenhagen/multi-module-sample/core/, 
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and 
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for 
> the core module. All these URLs are invalid. For SVN this could be assumed to 
> be the right behaviour, for git and probably other SCMs this is not true. As 
> a workaround I have to reconfigure the scm section (see 
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
>  in the modules like this:
> {code:xml}
> 
>   ${project.parent.scm.connection}
>   
> ${project.parent.scm.developerConnection}
>   ${project.parent.scm.url}
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

[Chris Graham (JIRA)]

[ 
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14698029#comment-14698029
 ] 

Chris Graham commented on MPIR-234:
---

>> It should not be displayed, or inferred from any other (ie sub module) 
>> location.
>If you are looking at a module's site and you have to go changing it, you want 
>to know how to check out that module.

Perhaps I was not clear, or you missed by point.

Which is: In some SCM's checking out a sub module, it is impossible. It's an 
all or nothing operation, not a cherry picking one.

>So there should be a "Source Repository" for sub-modules.

No there should not. Or, at best, it is only meaningful for those SCM's that 
can support it.

All you are doing in your example is cloning the entire repo [you cann't 
not] and then checking out (-b) the branch. How is this a sub module?


> SCM-link in site of multimodule projects should not append module name by 
> default (at least for git)
> 
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
>  Issue Type: Bug
>  Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see 
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex) 
> which uses git on github as {{scm}}. While rendering the site, MPIR will by 
> default add the name of the module to the SCM-URLs in source-repository.html. 
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see 
> https://github.com/mfriedenhagen/multi-module-sample/core/, 
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and 
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for 
> the core module. All these URLs are invalid. For SVN this could be assumed to 
> be the right behaviour, for git and probably other SCMs this is not true. As 
> a workaround I have to reconfigure the scm section (see 
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
>  in the modules like this:
> {code:xml}
> 
>   ${project.parent.scm.connection}
>   
> ${project.parent.scm.developerConnection}
>   ${project.parent.scm.url}
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

[Chris Graham (JIRA)]

[ 
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14696274#comment-14696274
 ] 

Chris Graham commented on MPIR-234:
---

"So the question becomes what do we put on the Source Repository page for a 
module without an explicit  section."

We don't. Either N/A or See Root SCM URL. 

This has just really driven it home for me: In SCM's like RTC/Clearcase/Accurev 
(and a flattened Git), the concept of a SCM URL for a submodule makes no sense 
at all. It is not possible. When you check out from these, it is an all or 
nothing approach. You can not cherry pick the bits you want.

So, from my SCM agnostic POV, the poms SCM section is only of value (and valid) 
in a a root (release) pom. It should not be displayed, or inferred from any 
other (ie sub module) location.


> SCM-link in site of multimodule projects should not append module name by 
> default (at least for git)
> 
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
>  Issue Type: Bug
>  Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see 
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex) 
> which uses git on github as {{scm}}. While rendering the site, MPIR will by 
> default add the name of the module to the SCM-URLs in source-repository.html. 
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see 
> https://github.com/mfriedenhagen/multi-module-sample/core/, 
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and 
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for 
> the core module. All these URLs are invalid. For SVN this could be assumed to 
> be the right behaviour, for git and probably other SCMs this is not true. As 
> a workaround I have to reconfigure the scm section (see 
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
>  in the modules like this:
> {code:xml}
> 
>   ${project.parent.scm.connection}
>   
> ${project.parent.scm.developerConnection}
>   ${project.parent.scm.url}
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

[Chris Graham (JIRA)]

[ 
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14696261#comment-14696261
 ] 

Chris Graham commented on MPIR-234:
---

"it's a general contract that should be enforcer for every supported scm 
(http://maven.apache.org/scm/scms-overview.html ): scm url should support going 
from a parent to a child Maven module by adding the path to the url"

One that made perfect sense in the CVS/SVN days, and these core concepts have 
been etched in stone in the Maven & SCM thinking. However, this is not always 
possible with all SCM's. 

The base assumption above, does not always hold true for Accurev, ClearCase, 
RTC, and depending on how you set it up, possibly even Git.

Git can be nested, with a root pom (and blah statements), or 
flattened (and ../blah statements). If flattened, the 
assumption above does not told true.


> SCM-link in site of multimodule projects should not append module name by 
> default (at least for git)
> 
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
>  Issue Type: Bug
>  Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see 
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex) 
> which uses git on github as {{scm}}. While rendering the site, MPIR will by 
> default add the name of the module to the SCM-URLs in source-repository.html. 
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see 
> https://github.com/mfriedenhagen/multi-module-sample/core/, 
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and 
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for 
> the core module. All these URLs are invalid. For SVN this could be assumed to 
> be the right behaviour, for git and probably other SCMs this is not true. As 
> a workaround I have to reconfigure the scm section (see 
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
>  in the modules like this:
> {code:xml}
> 
>   ${project.parent.scm.connection}
>   
> ${project.parent.scm.developerConnection}
>   ${project.parent.scm.url}
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

[Chris Graham (JIRA)]

[ 
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14696247#comment-14696247
 ] 

Chris Graham commented on MPIR-234:
---

I see a general drift towards a Git centric discussion, which is understandable 
as most of us use it. However, the entire Maven (and particularly the SCM APIs) 
implementation (and therefore thinking) are meant to be SCM agnostic.

As for Flattened/Nested. Let me try to explain (I was rushed). When you perform 
a release with MRP, you perform a tagging operation. With SVN, it's a path 
within the repo. We only tag our own bit. In Git, the entire repo is tagged, 
and in RTC, the Component has a Snapshot taken. In SVN you can check out just a 
path into your WC - you can even cherry pick from where and create your own 
working structure. This falls down as the MRP can not reconstruct this, hand 
made, cherry picked dir structure; it can only check out one point, and thus 
lends itself to a nest structure (if not enforces it). In Git, you clone and 
entire repo, and in RTC/Clearcase you load an entire Component. RTC, like Git, 
can have multiple folders worth (I think of them as eclipse projects - as 
that's the space I work in - esp with RTC) available. In Git, it's easy (and 
makes sense to) have a root pom and nested modules, an a dir format supported 
by the MRP. In RTC, it's impossible to do with the Eclipse client to place a 
pom.xml in the root of a component (although it is not forbidden from the 
underlying SCM impl, it may be possible from the SCM command line). It really 
wants one or more folders (ie eclipse projects) in the root level of a 
Component. When you check them out (SCM load in rtc terms) you get all of the 
projects/folders into the one check out dir. This is kind of forced by the 
eclipse client as it looks for .project files when it checks out. So you end up 
with a flattened structure. In all of the RTC examples I've work with, esp when 
working with the MRP and the RTC SCM integration, I've always nested the 
projects and manually created links in Eclipse. Most RTC based devs either do 
not know a) you can actually do this, or b) do not want too. There is no 
Project Set Support for RTC SCM in eclipse (although it's been requested). Does 
that all make sense or have I actually made things worse?

In terms of "ignore scm section" that was more a reference to the 
help:effective-pom comment, where the scm section of the pom is output in all 
pom's not just the root one. I thought that the discussion may have been 
heading in the direction of actually using the scm sections in non root poms, 
as I seem to remember that there is/was a request to actually implement using 
the sub module poms (non root ones) scm section, so you'd perform multiple 
check out operations (to make the hand crafted, cherry picked option listed 
above. This is not a thing that I am a fan of.

My point here, is that I don't think that the scm section should exist, or be 
used, or displayed for anything other than the root pom.



> SCM-link in site of multimodule projects should not append module name by 
> default (at least for git)
> 
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
>  Issue Type: Bug
>  Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see 
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex) 
> which uses git on github as {{scm}}. While rendering the site, MPIR will by 
> default add the name of the module to the SCM-URLs in source-repository.html. 
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see 
> https://github.com/mfriedenhagen/multi-module-sample/core/, 
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and 
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for 
> the core module. All these URLs are invalid. For SVN this could be assumed to 
> be the right behaviour, for git and probably other SCMs this is not true. As 
> a workaround I have to reconfigure the scm section (see 
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
>  in the modules like this:
> {code:xml}
> 
>   ${project.parent.scm.connection}
>   
> ${project.parent.scm.developerConnection}
>   ${project.parent.scm.url}
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

[Chris Graham (JIRA)]

[ 
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14679583#comment-14679583
 ] 

Chris Graham commented on MPIR-234:
---

Just too add some more fuel to the fire. :)

Jazz, like Git, ClearCase etc, can be used in a nested or flattened structure. 
There would have to be an option to set it or not.

As another comment, shouldn't the SCM section actually be removed/ignored from 
sub modules anyway?


> SCM-link in site of multimodule projects should not append module name by 
> default (at least for git)
> 
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
>  Issue Type: Bug
>  Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see 
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex) 
> which uses git on github as {{scm}}. While rendering the site, MPIR will by 
> default add the name of the module to the SCM-URLs in source-repository.html. 
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see 
> https://github.com/mfriedenhagen/multi-module-sample/core/, 
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and 
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for 
> the core module. All these URLs are invalid. For SVN this could be assumed to 
> be the right behaviour, for git and probably other SCMs this is not true. As 
> a workaround I have to reconfigure the scm section (see 
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
>  in the modules like this:
> {code:xml}
> 
>   ${project.parent.scm.connection}
>   
> ${project.parent.scm.developerConnection}
>   ${project.parent.scm.url}
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Full migration to Git

[Chris Graham]

Sent from my iPad

> On 2 Jun 2015, at 12:16 am, Jason van Zyl  wrote:
> 
> I think we have that PoC with Mojo moving to Github no? Baptiste, was this an 
> issue?
> 
> I think it will just be easier to do it all from Git. I don’t think we’re 
> going to lose anything in the translation directly from SVN to Git with the 
> maturity of the tools.
> 
> But do you agree with the general plan. Get it all to Git and then we’ll 
> collectively figure it out. I really don’t see it being an issue given how 
> much Git knowledge we have between us all and the Mojo migration to Github.
> 

No.

What's the rush?

We have the time to figure it out, communicate a plan, understand it and then 
implement it.

Personally, I can't ever see a retrospective cleanup happening.

We have the time and opportunity to do it right, why would we not take it?

-Chris

>> On Jun 1, 2015, at 8:13 AM, Kristian Rosenvold 
>>  wrote:
>> 
>> The real problem here is maven-shared and maven-plugins, which need to be
>> rewritten quite heavily.
>> 
>> The existing git mirrors may be used as a starting point for filtering
>> operations, but I suspect retaining history is going to be quite a lot of
>> work when splitting the repos.
>> 
>> We should not defer this operation like you suggest, we really need a proof
>> of concept filtering first.
>> 
>> Kristian
>> 
>> 
>> 2015-06-01 14:06 GMT+02:00 Jason van Zyl :
>> 
>>> Maybe it best then to have everything mirrored to Git, if there are any
>>> repos that are not. Turn off SVN and do any partitioning once everything is
>>> on the Git side?
>>> 
>>> Anyone have any objections to this general plan of action:
>>> 
>>> 1) Mirror anything to Git that isn’t
>>> 2) Make all the Git repos the primary
>>> 3) Do any separation or refactoring once in Git to avoid any dealings with
>>> SVN
>>> 
 On Jun 1, 2015, at 7:53 AM, Olivier Lamy  wrote:
 
 On 1 June 2015 at 21:37, Jason van Zyl  wrote:
 
> Great, you should update the document. I’ll move on to the enforcer
>>> then.
> 
> Did you have explicit instructions for the tools you used for the
> migration that others can use?
 
 nothing special as such repo are already mirrored to git: git://
 git.apache.org/maven-enforcer.git then
 https://github.com/apache/maven-enforcer
 
 so it's just a matter of turning off the svn enforcer path then make the
 git mirror as primary
 
 
> 
>> On Jun 1, 2015, at 7:22 AM, Olivier Lamy  wrote:
>> 
>> AFAIK I already did the indexer migration in git:
>> http://markmail.org/message/je4wmxk5ss4b2cmk
>> 
>> It's here:
>>> https://git1-us-west.apache.org/repos/asf?p=maven-indexer.git;a=summary
>> 
>> Cheers
>> Olivier
>> 
>>> On 1 June 2015 at 21:07, Jason van Zyl  wrote:
>>> 
>>> Tamas and I volunteer to tackle the indexer, and will ask Baptiste for
>>> some help and work on the plugins repos as that fields the most
>>> contributions.
>>> 
 On May 29, 2015, at 7:23 AM, Jason van Zyl  wrote:
 
 I think it's time for a full migration of all our repositories to
>>> Git.
> I
>>> just see the email with Dennis struggling to merge a simple pull
>>> request
>>> and I think it's just time to switch completely. I think someone
>>> already
>>> started a list and we should just move through it. Personally I find
> SVN is
>>> just a huge hindrance at this point, especially for contributors.
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder, Takari and Apache Maven
 http://twitter.com/jvanzyl
 http://twitter.com/takari_io
 -
 
 The most dangerous risk: spending your life not doing what you want
>>> on
>>> the bet you can buy yourself freedom to do it later.
 
 -- Randy Komisar
 
 
 
 
 
 
 
 
 
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
>>> 
>>> Thanks,
>>> 
>>> Jason
>>> 
>>> --
>>> Jason van Zyl
>>> Founder, Takari and Apache Maven
>>> http://twitter.com/jvanzyl
>>> http://twitter.com/takari_io
>>> -
>>> 
>>> happiness is like a butterfly: the more you chase it, the more it will
>>> elude you, but if you turn your attention to other things, it will
>>> come
>>> and sit softly on your shoulder ...
>>> 
>>> -- Thoreau
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>

Re: Full migration to Git

[Chris Graham]

+1.

Sent from my iPad

> On 1 Jun 2015, at 6:08 pm, Arnaud Héritier  wrote:
> 
> For me it should be one per plugin, shared component.
> Everything which has its own release lifecycle must have its own repo
> 
>> On Mon, Jun 1, 2015 at 10:04 AM, Chris Graham  wrote:
>> 
>> So how are we planning to calve up the migration?
>> 
>> A repo per trunk?
>> An all in one blob?
>> A mixture, if so, split along what lines?
>> 
>> -Chris
>> 
>>> On Sun, May 31, 2015 at 6:57 PM, Jason van Zyl  wrote:
>>> 
>>> Great, thanks Baptiste.
>>> 
>>>> On May 31, 2015, at 4:36 AM, Baptiste Mathus 
>> wrote:
>>>> 
>>>> See https://github.com/mojohaus/convert-to-git for MojoHaus
>> (previously
>>>> Mojo@Codehaus).
>>>> Though a bit rough a the main script being a bit oriented towards the
>>> Mojo
>>>> SVN, it has no real specificities wrt SVN->Git migration, so it should
>> be
>>>> at least a good starting point.
>>>> 
>>>> I can privide help, or help anyone wanting to try and use it, and
>>> document
>>>> what needs be. Just tell me.
>>>> 
>>>> Cheers
>>>> 
>>>> 2015-05-31 6:26 GMT+02:00 Barrie Treloar :
>>>> 
>>>>>> On 31 May 2015 at 08:18, Jason van Zyl  wrote:
>>>>>> 
>>>>>> I’m sure those responsible for the migration of the Mojo project
>>> monorepo
>>>>>> into the separated repos will help us.
>>>>> 
>>>>> 
>>>>> I ask because I'm going to be facing the same thing at work soon-ish,
>> so
>>>>> there is a good chance of finding some capacity during work hours to
>>> help
>>>>> out with this migration to gain some skillz.
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Baptiste  MATHUS - http://batmat.net
>>>> Sauvez un arbre,
>>>> Mangez un castor !
>>> 
>>> Thanks,
>>> 
>>> Jason
>>> 
>>> --
>>> Jason van Zyl
>>> Founder, Takari and Apache Maven
>>> http://twitter.com/jvanzyl
>>> http://twitter.com/takari_io
>>> -
>>> 
>>> Simplex sigillum veri. (Simplicity is the seal of truth.)
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>> 
>>> 
>> 
> 
> 
> 
> -- 
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier

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

Re: Full migration to Git

[Chris Graham]

So how are we planning to calve up the migration?

A repo per trunk?
An all in one blob?
A mixture, if so, split along what lines?

-Chris

On Sun, May 31, 2015 at 6:57 PM, Jason van Zyl  wrote:

> Great, thanks Baptiste.
>
> > On May 31, 2015, at 4:36 AM, Baptiste Mathus  wrote:
> >
> > See https://github.com/mojohaus/convert-to-git for MojoHaus (previously
> > Mojo@Codehaus).
> > Though a bit rough a the main script being a bit oriented towards the
> Mojo
> > SVN, it has no real specificities wrt SVN->Git migration, so it should be
> > at least a good starting point.
> >
> > I can privide help, or help anyone wanting to try and use it, and
> document
> > what needs be. Just tell me.
> >
> > Cheers
> >
> > 2015-05-31 6:26 GMT+02:00 Barrie Treloar :
> >
> >> On 31 May 2015 at 08:18, Jason van Zyl  wrote:
> >>
> >>> I’m sure those responsible for the migration of the Mojo project
> monorepo
> >>> into the separated repos will help us.
> >>
> >>
> >> I ask because I'm going to be facing the same thing at work soon-ish, so
> >> there is a good chance of finding some capacity during work hours to
> help
> >> out with this migration to gain some skillz.
> >>
> >
> >
> >
> > --
> > Baptiste  MATHUS - http://batmat.net
> > Sauvez un arbre,
> > Mangez un castor !
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
>
> Simplex sigillum veri. (Simplicity is the seal of truth.)
>
>
>
>
>
>
>
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

SCM: ClearCase tests failing on Windows

[Chris Graham]

Hi All.

I'm getting these (this is one of three) failures when being built on
windows:

ClearCaseEditCommandTest.testCommand:41->ScmTestCase.assertCommandLine:367
expected:<...C "cleartool co -nc [C:\Documents and
Settings\admin\workspace\maven-scm\maven-scm-providers\maven-scm-provider-clearcase\test.java]">

 but was:<...C "cleartool co -nc ["C:\Documents and
Settings\admin\workspace\maven-scm\maven-scm-providers\maven-scm-provider-clearcase\test.java"]">


It is because this test routine:

public class ClearCaseEditCommandTest
extends ScmTestCase
{
public void testCommand()
throws Exception
{
File file = new File( "test.java" );
ScmFileSet scmFileSet = new ScmFileSet( getWorkingDirectory(), file
);
Commandline commandLine = ClearCaseEditCommand.createCommandLine(
new DefaultLog(), scmFileSet );
assertCommandLine( "cleartool co -nc " + file.getAbsolutePath(),
getWorkingDirectory(), commandLine );
}
}


does not expect file.getAbsolutePath() to quote the path, whereas the
commandLine.toString() eventually calls:

getCommandLine() -> getRawCommandLine() -> StringUtils.quoteAndEscape()

The space in the path triggers the quoting in quoteAndEscape() , and so the
test fails.

Now that I understand the mechanics of this, am I the only one seeing this?

What has been done in the past to fix them? I've got enough on with the
jazz provider at the moment, I'd rather not add too it!

Suggestions as to how best to proceed would be greatly appreciated.

-Chris

Re: Re : ASF Jira Issues

[Chris Graham]

Do we have a guide as to when to Resolve as opposed to Close an issue?

In my case, I've got one that is not a bug in the SCM provider, but in the
release plugin (tracked by MRELEASE-904). What do I do with the SCM-725
issue?

I've resolved it for the moment, but do I only close it when/if 904 has
been resolved/closed?



On Wed, Apr 22, 2015 at 10:41 PM,  wrote:

> I checked SCM configuration: permissions were ok, but not roles
> I fixed roles to match common configuration, ie committers =
> maven-developers, PMC = maven- administrators
>
> Regards,
>
> Hervé
> - Mail d'origine -
> De: Chris Graham 
> À: Maven Developers List 
> Envoyé: Wed, 22 Apr 2015 13:41:21 +0200 (CEST)
> Objet: ASF Jira Issues
>
> Hi All.
>
> I can see that I'm a member of jira-users and maven-developers in the ASF
> jira.
>
> I'd like to assign some work to myself, but I do not seem to be able too.
>
> How does one do that?
>
> -Chris
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Re : ASF Jira Issues

[Chris Graham]

Ah! Now I'm good!
Thanks!
-Chris

On Wed, Apr 22, 2015 at 10:41 PM,  wrote:

> I checked SCM configuration: permissions were ok, but not roles
> I fixed roles to match common configuration, ie committers =
> maven-developers, PMC = maven- administrators
>
> Regards,
>
> Hervé
> - Mail d'origine -
> De: Chris Graham 
> À: Maven Developers List 
> Envoyé: Wed, 22 Apr 2015 13:41:21 +0200 (CEST)
> Objet: ASF Jira Issues
>
> Hi All.
>
> I can see that I'm a member of jira-users and maven-developers in the ASF
> jira.
>
> I'd like to assign some work to myself, but I do not seem to be able too.
>
> How does one do that?
>
> -Chris
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

ASF Jira Issues

[Chris Graham]

Hi All.

I can see that I'm a member of jira-users and maven-developers in the ASF
jira.

I'd like to assign some work to myself, but I do not seem to be able too.

How does one do that?

-Chris

Re: svn tagging fails in release:prepare ???

[Chris Graham]

If you add some tests, please make sure that can still release from branches, 
as all of my corporate work was like that.

There were some circumstances when a release would go nuts, and the URL in the 
SCM section of the Pom was not left as trunk or branches, but the tag itself.

Is that what happened here?

-Chris

Sent from my iPhone

On 22/04/2015, at 3:21 PM, Kristian Rosenvold  
wrote:

> Thanks a lot Adrien, that seemed to fix it !
> 
> I'll see if I can add a test for this to the release plugin itself.
> 
> Kristian
> 
> 
> 2015-04-21 22:24 GMT+02:00 Adrien Rivard :
>> Looks like to me it is trying to copy the tag to the tag.
>> SCM url should contains "trunk" before starting the release. It is
>> currently wrong, not sure if it was the case before though your first
>> release though.
>> 
>> 
>> 
>> On Tue, Apr 21, 2015 at 9:09 PM, Robert Scholte 
>> wrote:
>> 
>>> different versions of svn clients? svn version of sources not in sync with
>>> client?
>>> 
>>> Op Tue, 21 Apr 2015 19:58:31 +0200 schreef Kristian Rosenvold <
>>> kristian.rosenv...@gmail.com>:
>>> 
>>> 
>>> I have
 
 140.211.11.105  svn.apache.org in /etc/hosts, which should solve /that/
 problem.
 
 I'm particularly wondering about this part of the message, is this
 some kind of internal svn uri ?
 
 [ERROR] svn: E160013:
 
 '/repos/asf/!svn/rvr/1675172/maven/plugins/tags/maven-assembly-plugin-2.5.4'
 
 
 2015-04-21 19:55 GMT+02:00 Robert Scholte :
 
> European timing issue?
> http://www.apache.org/dev/publishing-maven-artifacts.html#dev-env
> 
> 
> Op Tue, 21 Apr 2015 19:51:59 +0200 schreef Kristian Rosenvold
> :
> 
> I'm trying to tag assembly-plugin, but get the following error - any
>> ideas
>> ?
>> 
>> [INFO] Executing: /bin/sh -c cd
>> /home/release15/trunk/maven-assembly-plugin && svn --non-interactive
>> copy --file /tmp/maven-scm-1432262679.commit --parents --revision
>> 1675172
>> 
>> https://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-plugin-2.5.4
>> 
>> 
>> https://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-plugin-2.5.4
>> 
>> [INFO] Working directory: /home/release15/trunk/maven-assembly-plugin
>> 
>> [INFO]
>> 
>> 
>> [INFO] BUILD FAILURE
>> 
>> [INFO]
>> 
>> 
>> [INFO] Total time: 35.675s
>> 
>> [INFO] Finished at: Tue Apr 21 19:48:47 CEST 2015
>> 
>> [INFO] Final Memory: 18M/309M
>> 
>> [INFO]
>> 
>> 
>> [WARNING] The requested profile "nexus" could not be activated because
>> it does not exist.
>> 
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare
>> (default-cli) on project maven-assembly-plugin: Unable to tag SCM
>> 
>> [ERROR] Provider message:
>> 
>> [ERROR] The svn tag command failed.
>> 
>> [ERROR] Command output:
>> 
>> [ERROR] svn: E160013:
>> 
>> 
>> '/repos/asf/!svn/rvr/1675172/maven/plugins/tags/maven-assembly-plugin-2.5.4'
>> path not found
>> 
>> [ERROR] -> [Help 1]
>> 
>> [ERROR]
>> 
>> -
>> 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
> 
> 
 -
 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
>>> 
>>> 
>> 
>> 
>> --
>> Adrien Rivard
> 
> -
> 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: Building SCM 1.9.5-SNAPSHOT

[Chris Graham]

gin:2.17'. A required class is
missing: javax.annotation.Nonnull


I'm kind of lost.

Anders has been able to confirm that it is buildable, but he is using a
slightly different commit (one that I can not find).

Can anyone shed any light on what's going on?

TIA,

-Chris
Hervé BOUTEMYApr 1
Hi, No such problem here. Can you try with an Oracle JDK, please? Since
this ...
Raphael AckermannApr 1
Default clone doesn't get you master branch but some old and outdated
branch
Chris Graham 

Apr 1

to Maven
I will try to find an oracle one. Anders did manage to try the IBM one, and
it worked... :(
Chris Graham 

Apr 1

to Maven
Hi Raphael!

Thanks for that. I thought that I was on master, but I'll double check!

Appreciate (from everyone) the help.
Anders HammarApr 1
As I'm being mentioned here I'd like to clarify: I'm able to build with an
IB...
Chris Graham 

Apr 1

to Maven
Heh. I was tired. For some reason, I was looking at the end of the hash,
not the beginning. Doh!

Brain fade. :-)

-Chris

Sent from my iPhone
Chris Graham 

Apr 2

to Maven
Hey All.

I've tried updating to a sun VM. The same error as with the IBM JDK.

This is with wiping the entire local repo.

I've even also explicity included the exclusion of target/**

[INFO] Exclude: target/**

[INFO] 57 implicit excludes (use -debug for more details).
[INFO] Exclude: .gitignore
[INFO] Exclude: README.txt
[INFO] Exclude: *.sh
[INFO] Exclude: .git/**
[INFO] Exclude: .idea/**
[INFO] Exclude: **/generated-sources/**
[INFO] Exclude: **/.gitattributes
[INFO] Exclude: src/main/resources/repository/**
[INFO] Exclude: **/src/main/resources/tck-repository/**
[INFO] Exclude: src/test/resources/**
[INFO] Exclude: src/test/repository/**
[INFO] Exclude: src/test/tck-repository/**
[INFO] Exclude: src/main/resources/tck/**
[INFO] Exclude: .java-version
[INFO] Exclude: .repository/**
[INFO] Exclude: target/**
[INFO] Exclude: DEPENDENCIES
[INFO] 4341 resources included (use -debug for more details)
[INFO] Rat check: Summary of files. Unapproved: 1745 unknown: 1745
generated: 0 approved: 1305 licence.
[INFO]

[INFO] Reactor Summary:
[INFO]
[INFO] Maven SCM . FAILURE
[1:04.421s]
[INFO] Maven SCM API . SKIPPED
[INFO] Maven SCM Managers  SKIPPED
[INFO] Maven SCM Manager for Plexus .. SKIPPED
[INFO] Maven SCM Test  SKIPPED
[INFO] Maven SCM Providers ... SKIPPED
[INFO] Maven SCM AccuRev Provider  SKIPPED
[INFO] Maven SCM Bazaar Provider . SKIPPED
[INFO] Maven SCM Clearcase Provider .. SKIPPED
[INFO] Maven SCM CVS Provider - Parent ... SKIPPED
[INFO] Maven SCM CVS Provider TCK tests .. SKIPPED
[INFO] Maven SCM CVS Provider - Common library ... SKIPPED
[INFO] Maven SCM CVS Provider - CVS Executable Impl. . SKIPPED
[INFO] Maven SCM CVS Provider - CVS Java Impl. ... SKIPPED
[INFO] Maven SCM Mercurial (Hg) Provider . SKIPPED
[INFO] Maven SCM Git Provider - Parent ... SKIPPED
[INFO] Maven SCM Git Provider - Common library ... SKIPPED
[INFO] Maven SCM Git Provider TCK Tests .. SKIPPED
[INFO] Maven SCM Git Provider - Git Executable Impl. . SKIPPED
[INFO] Maven SCM Git Provider - JGit Impl. ... SKIPPED
[INFO] Maven SCM Local Provider .. SKIPPED
[INFO] Maven SCM Perforce Provider ... SKIPPED
[INFO] Maven SCM Starteam Provider ... SKIPPED
[INFO] Maven SCM Subversion Provider - Parent  SKIPPED
[INFO] Maven SCM Subversion Provider - Common library  SKIPPED
[INFO] Maven SCM Subversion Provider TCK Tests ... SKIPPED
[INFO] Maven SCM Subversion Provider - SVN Executable Impl.  SKIPPED
[INFO] Maven SCM Synergy Provider  SKIPPED
[INFO] Maven SCM Visual Source Safe Provider . SKIPPED
[INFO] Maven SCM TFS Provider  SKIPPED
[INFO] Maven SCM MKS Integrity Provider .. SKIPPED
[INFO] Maven SCM Jazz/Rational Team Concert Provider . SKIPPED
[INFO] Maven SCM Standard Providers .. SKIPPED
[INFO] Maven SCM Client .. SKIPPED
[INFO] Maven SCM Plugin .. SKIPPED
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 1:08.515s
[INFO] Finished at: Thu Apr 02 12:08:10 EST 2015
[INFO] Final Memory: 12M/47M
[INFO]

[ERROR] Failed to execut

IBM RAM (Rational Asset Manager) as a Maven repo mgr

[Chris Graham]

Ha! I was not aware of this, but evidently you can.

Anyone know of anyone who has used it as such?

I might see if I've got a VM to play with...

http://www-01.ibm.com/support/knowledgecenter/SSUS84_7.5.1/com.ibm.ram.doc/topics/c_maven_library.html

-Chris

Re: release-plugin: push changes after perform for DCVS

[Chris Graham]

troactive push is actually going to
help, in fact, I think that it's more than likely to complicate matters.
Eg, what happens to duplicate tags on separate repos if someone should
accidently attempt to push them later on? (might be a bad example)

Just my experience.

-Chris


>
> Regards Mirko
> --
> http://illegalstateexception.blogspot.com/
> https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
> https://bitbucket.org/mfriedenhagen/
>
>
> On Mon, Apr 13, 2015 at 3:48 AM, Chris Graham 
> wrote:
> > I'm not actually sure of what problem you're trying to solve here.
> >
> > On Sat, Apr 11, 2015 at 6:49 AM, Mirko Friedenhagen <
> > mfriedenha...@apache.org> wrote:
> >
> >> Hello,
> >>
> >> we now have pushChanges and localCheckout in the release:prepare goal.
> >> IMO pushing commits and tags after a successful release:perform or
> >> release:stage would be a good thing then, as this will probably
> >> succeed most of the times.
> >>
> >>
> > I have a real problem with the word 'probably' here. As there will always
> > be times when that is not the case, when things fail. Sometimes on a
> > permanent basis, sometimes a temporary failure.
> >
> > What appears to be the case here, is that we've come up with a proposed
> > solution to a problem that I have no clear idea about. Can someone please
> > elaborate?
> >
> >
> >
> >> What do you think about something like pushChangesAfterPerform?
> >>
> >> -
> >> 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: release-plugin: push changes after perform for DCVS

[Chris Graham]

I'm not actually sure of what problem you're trying to solve here.

On Sat, Apr 11, 2015 at 6:49 AM, Mirko Friedenhagen <
mfriedenha...@apache.org> wrote:

> Hello,
>
> we now have pushChanges and localCheckout in the release:prepare goal.
> IMO pushing commits and tags after a successful release:perform or
> release:stage would be a good thing then, as this will probably
> succeed most of the times.
>
>
I have a real problem with the word 'probably' here. As there will always
be times when that is not the case, when things fail. Sometimes on a
permanent basis, sometimes a temporary failure.

What appears to be the case here, is that we've come up with a proposed
solution to a problem that I have no clear idea about. Can someone please
elaborate?



> What do you think about something like pushChangesAfterPerform?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: release-plugin: push changes after perform for DCVS

[Chris Graham]

On Sat, Apr 11, 2015 at 7:06 PM, Mirko Friedenhagen  wrote:

> Stephen,
>
> this does sound even more reasonable. release.properties is deleted at the
> end of perform, so the goal could only rely on information in the pom.
>
>
Doesn't release:clean effectively do that?



> Regards
> Mirko
> --
> Sent from my mobile
> On Apr 11, 2015 9:40 AM, "Stephen Connolly" <
> stephen.alan.conno...@gmail.com>
> wrote:
>
> > I could see value in a release:finalize goal that is a no-op for non-DCVS
> > but does a push changes for DCVS
> >
> > It would mean that you could go
> >
> > mvn release:prepare release:perform release:finalize
> >
> > in one command to close it all out
> >
> > On 10 April 2015 at 22:36, Robert Scholte  wrote:
> >
> > > Hmmm, no so sure about that.
> > > The whole concept is that 'prepare' should do all the scm actions.
> > > 'perform' should only do a checkout from the tag and run 'mvn deploy'.
> > > There should be as less as possible actions after uploading the
> artifacts
> > > to a repository manager.
> > > Did you ever face issues with deploying the site (well, I did... it's
> not
> > > nice but I know the workarounds)
> > >
> > > the maven-release-plugin is already quite complex, we should try to
> keep
> > > the chances of a failing release as low as possible.
> > >
> > > Robert
> > >
> > >
> > > Op Fri, 10 Apr 2015 22:49:44 +0200 schreef Mirko Friedenhagen <
> > > mfriedenha...@apache.org>:
> > >
> > >
> > >  Hello,
> > >>
> > >> we now have pushChanges and localCheckout in the release:prepare goal.
> > >> IMO pushing commits and tags after a successful release:perform or
> > >> release:stage would be a good thing then, as this will probably
> > >> succeed most of the times.
> > >>
> > >> What do you think about something like pushChangesAfterPerform?
> > >>
> > >> -
> > >> 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: svn commit: r1672232 - /maven/pom/trunk/maven/pom.xml

[Chris Graham]

On Thu, Apr 9, 2015 at 5:06 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Welcome on board Chris...
>
>
Thanks (to all)!


> Though this doesean that the committer school has graduated all
> participants ;-)
>
>
Muahahahahaha! :)

I'll be good. I just really want to work on the bits that I can do best,
and obviously effect me the most, namely the SCM bits and Release Plugin.

-Chris


> On Thursday, April 9, 2015,  wrote:
>
> > Author: chrisgwarp
> > Date: Thu Apr  9 02:28:56 2015
> > New Revision: 1672232
> >
> > URL: http://svn.apache.org/r1672232
> > Log:
> > Changed: Added chrisgwarp (self) as a committer.
> >
> > Modified:
> > maven/pom/trunk/maven/pom.xml
> >
> > Modified: maven/pom/trunk/maven/pom.xml
> > URL:
> >
> http://svn.apache.org/viewvc/maven/pom/trunk/maven/pom.xml?rev=1672232&r1=1672231&r2=1672232&view=diff
> >
> >
> ==
> > --- maven/pom/trunk/maven/pom.xml (original)
> > +++ maven/pom/trunk/maven/pom.xml Thu Apr  9 02:28:56 2015
> > @@ -512,6 +512,15 @@ under the License.
> >
> >+1
> >  
> > +
> > +  chrisgwarp
> > +  Chris Graham
> > +  chrisgw...@apache.org 
> > +  
> > +Committer
> > +  
> > +  Australia/Melbourne
> > +
> >  
> >
> >  
> >
> >
> >
>
> --
> Sent from my phone
>

Re: Building SCM 1.9.5-SNAPSHOT

[Chris Graham]

Hi Hervé

I modified prepare.groovy to include the consumeProcessOutput() line. Works
like a charm! Thanks!

I'm not sure why it's only occurring with me, but... shrug.

I'll include the change with my work.

Now that I can get started! :))

-Chris


On Thu, Apr 2, 2015 at 5:01 PM, Hervé BOUTEMY  wrote:

> typical of process output consumption problems
>
> see http://groovy-lang.org/groovy-dev-kit.html#process-management for
> description and solution:
> Because some native platforms only provide limited buffer size for
> standard input and output streams, failure to promptly write the input
> stream
> or read the output stream of the subprocess may cause the subprocess to
> block,
> and even deadlock
> Because of this, Groovy provides some additional helper methods which make
> stream handling for processes easier.
>
> Here is how to gobble all of the output (including the error stream output)
> from your process:
>
> def p = "rm -f foo.tmp".execute([], tmpDir)
> p.consumeProcessOutput()
> p.waitFor()
>
> Notice that in your case, once the process output is consumed to avoid
> deadlock, I suppose you'll discover unexpected the stderr content that
> cause
> the issue :)
>
> Regards,
>
> Hervé
>
> Le jeudi 2 avril 2015 14:03:33 Chris Graham a écrit :
> > This is nuts!
> >
> > Has anyone else ever had the scm build hang at this point:
> >
> > [INFO] [invoker:run {execution: integration-test}]
> > [INFO] Building: scm-741-validate-scm-url-matches-working-copy\pom.xml
> > [INFO] run script prepare.groovy
> >
> > Looking at the process tree, it's called "svn.exe --version". The build
> > only continues once I kill svn.
> >
> > On Thu, Apr 2, 2015 at 1:48 PM, Chris Graham 
> wrote:
> > > Is there a rat cache? The resultant failures are referencing files in
> the
> > > target dir that do not exist. For the moment, I've had to exclude
> > > everything, and I'll sort it out later.
> > >
> > > On Thu, Apr 2, 2015 at 1:41 PM, Chris Graham 
> wrote:
> > >> Hey!
> > >>
> > >> Still with IBM? I'm not. :( I've been out of work since my contract
> was
> > >> ended (from the US. not locally) on Nov 28th.
> > >>
> > >> Dockerise, now what does that mean?
> > >>
> > >> On Thu, Apr 2, 2015 at 1:40 PM, jieryn  wrote:
> > >>> Please dockerize all maven developer environments.
> > >>>
> > >>> On Wed, Apr 1, 2015 at 10:26 PM, Chris Graham 
> > >>>
> > >>> wrote:
> > >>> > Another different version, another different set of issues to
> solve.
> > >>> >
> > >>> > [INFO] --- apache-rat-plugin:0.11:check (rat-check) @ maven-scm ---
> > >>> > [INFO] 57 implicit excludes (use -debug for more details).
> > >>> > [INFO] Exclude: .gitignore
> > >>> > [INFO] Exclude: README.txt
> > >>> > [INFO] Exclude: *.sh
> > >>> > [INFO] Exclude: .git/**
> > >>> > [INFO] Exclude: .idea/**
> > >>> > [INFO] Exclude: **/generated-sources/**
> > >>> > [INFO] Exclude: **/.gitattributes
> > >>> > [INFO] Exclude: src/main/resources/repository/**
> > >>> > [INFO] Exclude: **/src/main/resources/tck-repository/**
> > >>> > [INFO] Exclude: src/test/resources/**
> > >>> > [INFO] Exclude: src/test/repository/**
> > >>> > [INFO] Exclude: src/test/tck-repository/**
> > >>> > [INFO] Exclude: src/main/resources/tck/**
> > >>> > [INFO] Exclude: .java-version
> > >>> > [INFO] Exclude: .repository/**
> > >>> > [INFO] Exclude: target/**
> > >>> > [INFO] Exclude: DEPENDENCIES
> > >>> > [INFO] 4341 resources included (use -debug for more details)
> > >>> > Warning:  org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser:
> Property
> > >>>
> > >>> '
> > >>>
> > >>> > http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit'
> is not
> > >>> > recognized.
> > >>> >
> > >>> > Compiler warnings:
> > >>> >   WARNING:  'org.apache.xerces.jaxp.SAXParserImpl: Property '
> > >>> >
> > >>> > http://javax.xml.XMLConstants/property/accessExternalDTD' is not
> > >>> > recognized.'
> > >>>

Re: Building SCM 1.9.5-SNAPSHOT

[Chris Graham]

On 02/04/2015, at 5:15 PM, Karl Heinz Marbaise  wrote:

> Hi Chris,
> 
> I assume you are callling Maven from the root of SCM git repository via
> 
Yes, from the root.

> mvn clean package

Yes, this or 

mvn clean install (mostly)

> or
> 
> mvn -Prun-its clean verify
> 
> What you can try is to use:
> 
> mvn clean package -Drat.ignoreErrors=true
> 

Good to know! I've currently included an exclude of ** :-) brute force but it 
works. :-)

What worries me though us that the generated rat.txt file contains references 
to files in /target that do not exist due to the mvn clean.

> which Maven Version do you use? (Can we first check to Maven 3.0.5)
> 

2.2.1 and 3.0.4.

> Furthermore i would suggest to do a:
> 
> mvn -X clean package >mvn.log
> 

I'm away until Saturday night, so I will do when I get back.

> and past the log file to pastebin etc. so that some has a chance to take a 
> look at it...
> 

Will do.

> BTW: I assume that you directly working on console?
> 
Yes. Initially I was in the RTC eclipse client (3.5).

Had the same errors there.

But since then I've been using the command line exclusively.

Thanks for your thoughts. I will given them all a go when I'm back in front of 
the VM. :-)

-Chris

> Kind regards
> Karl Heinz Marbaise
> 
> 
> On 4/2/15 3:11 AM, Chris Graham wrote:
>> Hey All.
>> 
>> I've tried updating to a sun VM. The same error as with the IBM JDK.
>> 
>> This is with wiping the entire local repo.
>> 
>> I've even also explicity included the exclusion of target/**
>> 
>> [INFO] Exclude: target/**
>> 
>> [INFO] 57 implicit excludes (use -debug for more details).
>> [INFO] Exclude: .gitignore
>> [INFO] Exclude: README.txt
>> [INFO] Exclude: *.sh
>> [INFO] Exclude: .git/**
>> [INFO] Exclude: .idea/**
>> [INFO] Exclude: **/generated-sources/**
>> [INFO] Exclude: **/.gitattributes
>> [INFO] Exclude: src/main/resources/repository/**
>> [INFO] Exclude: **/src/main/resources/tck-repository/**
>> [INFO] Exclude: src/test/resources/**
>> [INFO] Exclude: src/test/repository/**
>> [INFO] Exclude: src/test/tck-repository/**
>> [INFO] Exclude: src/main/resources/tck/**
>> [INFO] Exclude: .java-version
>> [INFO] Exclude: .repository/**
>> [INFO] Exclude: target/**
>> [INFO] Exclude: DEPENDENCIES
>> [INFO] 4341 resources included (use -debug for more details)
>> [INFO] Rat check: Summary of files. Unapproved: 1745 unknown: 1745
>> generated: 0 approved: 1305 licence.
>> [INFO]
>> 
>> [INFO] Reactor Summary:
>> [INFO]
>> [INFO] Maven SCM . FAILURE
>> [1:04.421s]
>> [INFO] Maven SCM API . SKIPPED
>> [INFO] Maven SCM Managers  SKIPPED
>> [INFO] Maven SCM Manager for Plexus .. SKIPPED
>> [INFO] Maven SCM Test  SKIPPED
>> [INFO] Maven SCM Providers ... SKIPPED
>> [INFO] Maven SCM AccuRev Provider  SKIPPED
>> [INFO] Maven SCM Bazaar Provider . SKIPPED
>> [INFO] Maven SCM Clearcase Provider .. SKIPPED
>> [INFO] Maven SCM CVS Provider - Parent ... SKIPPED
>> [INFO] Maven SCM CVS Provider TCK tests .. SKIPPED
>> [INFO] Maven SCM CVS Provider - Common library ... SKIPPED
>> [INFO] Maven SCM CVS Provider - CVS Executable Impl. . SKIPPED
>> [INFO] Maven SCM CVS Provider - CVS Java Impl. ... SKIPPED
>> [INFO] Maven SCM Mercurial (Hg) Provider . SKIPPED
>> [INFO] Maven SCM Git Provider - Parent ... SKIPPED
>> [INFO] Maven SCM Git Provider - Common library ... SKIPPED
>> [INFO] Maven SCM Git Provider TCK Tests .. SKIPPED
>> [INFO] Maven SCM Git Provider - Git Executable Impl. . SKIPPED
>> [INFO] Maven SCM Git Provider - JGit Impl. ... SKIPPED
>> [INFO] Maven SCM Local Provider .. SKIPPED
>> [INFO] Maven SCM Perforce Provider ... SKIPPED
>> [INFO] Maven SCM Starteam Provider ... SKIPPED
>> [INFO] Maven SCM Subversion Provider - Parent  SKIPPED
>> [INFO] Maven SCM Subversion Provider - Common library  SKIPPED
>> [INFO] Maven SCM Subversion Provider TCK Tests ... SKIPPED
>> [INFO] Maven SCM Subversion Provider - SVN Executable Impl.  SKIPPED
>> [INFO] Ma

Re: Building SCM 1.9.5-SNAPSHOT

[Chris Graham]

This is nuts!

Has anyone else ever had the scm build hang at this point:

[INFO] [invoker:run {execution: integration-test}]
[INFO] Building: scm-741-validate-scm-url-matches-working-copy\pom.xml
[INFO] run script prepare.groovy

Looking at the process tree, it's called "svn.exe --version". The build
only continues once I kill svn.



On Thu, Apr 2, 2015 at 1:48 PM, Chris Graham  wrote:

> Is there a rat cache? The resultant failures are referencing files in the
> target dir that do not exist. For the moment, I've had to exclude
> everything, and I'll sort it out later.
>
>
> On Thu, Apr 2, 2015 at 1:41 PM, Chris Graham  wrote:
>
>> Hey!
>>
>> Still with IBM? I'm not. :( I've been out of work since my contract was
>> ended (from the US. not locally) on Nov 28th.
>>
>> Dockerise, now what does that mean?
>>
>>
>>
>> On Thu, Apr 2, 2015 at 1:40 PM, jieryn  wrote:
>>
>>> Please dockerize all maven developer environments.
>>>
>>> On Wed, Apr 1, 2015 at 10:26 PM, Chris Graham 
>>> wrote:
>>> > Another different version, another different set of issues to solve.
>>> >
>>> > [INFO] --- apache-rat-plugin:0.11:check (rat-check) @ maven-scm ---
>>> > [INFO] 57 implicit excludes (use -debug for more details).
>>> > [INFO] Exclude: .gitignore
>>> > [INFO] Exclude: README.txt
>>> > [INFO] Exclude: *.sh
>>> > [INFO] Exclude: .git/**
>>> > [INFO] Exclude: .idea/**
>>> > [INFO] Exclude: **/generated-sources/**
>>> > [INFO] Exclude: **/.gitattributes
>>> > [INFO] Exclude: src/main/resources/repository/**
>>> > [INFO] Exclude: **/src/main/resources/tck-repository/**
>>> > [INFO] Exclude: src/test/resources/**
>>> > [INFO] Exclude: src/test/repository/**
>>> > [INFO] Exclude: src/test/tck-repository/**
>>> > [INFO] Exclude: src/main/resources/tck/**
>>> > [INFO] Exclude: .java-version
>>> > [INFO] Exclude: .repository/**
>>> > [INFO] Exclude: target/**
>>> > [INFO] Exclude: DEPENDENCIES
>>> > [INFO] 4341 resources included (use -debug for more details)
>>> > Warning:  org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser: Property
>>> '
>>> > http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit' is not
>>> > recognized.
>>> > Compiler warnings:
>>> >   WARNING:  'org.apache.xerces.jaxp.SAXParserImpl: Property '
>>> > http://javax.xml.XMLConstants/property/accessExternalDTD' is not
>>> > recognized.'
>>> > Warning:  org.apache.xerces.parsers.SAXParser: Feature '
>>> > http://javax.xml.XMLConstants/feature/secure-processing' is not
>>> recognized.
>>> > Warning:  org.apache.xerces.parsers.SAXParser: Property '
>>> > http://javax.xml.XMLConstants/property/accessExternalDTD' is not
>>> recognized.
>>> > Warning:  org.apache.xerces.parsers.SAXParser: Property '
>>> > http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit' is not
>>> > recognized.
>>> > [INFO] Rat check: Summary of files. Unapproved: 1745 unknown: 1745
>>> > generated: 0 approved: 1305 licence.
>>> > [INFO]
>>> >
>>> 
>>> > [INFO] Reactor Summary:
>>> > [INFO]
>>> > [INFO] Maven SCM . FAILURE
>>> [38.306s]
>>> > [INFO] Maven SCM API . SKIPPED
>>> > [INFO] Maven SCM Managers  SKIPPED
>>> > [INFO] Maven SCM Manager for Plexus .. SKIPPED
>>> > [INFO] Maven SCM Test  SKIPPED
>>> > [INFO] Maven SCM Providers ... SKIPPED
>>> > [INFO] Maven SCM AccuRev Provider  SKIPPED
>>> > [INFO] Maven SCM Bazaar Provider . SKIPPED
>>> > [INFO] Maven SCM Clearcase Provider .. SKIPPED
>>> > [INFO] Maven SCM CVS Provider - Parent ... SKIPPED
>>> > [INFO] Maven SCM CVS Provider TCK tests .. SKIPPED
>>> > [INFO] Maven SCM CVS Provider - Common library ... SKIPPED
>>> > [INFO] Maven SCM CVS Provider - CVS Executable Impl. . SKIPPED
>>> > [INFO] Maven SCM CVS Provider - CVS Java Impl. ...

Re: Building SCM 1.9.5-SNAPSHOT

[Chris Graham]

Is there a rat cache? The resultant failures are referencing files in the
target dir that do not exist. For the moment, I've had to exclude
everything, and I'll sort it out later.


On Thu, Apr 2, 2015 at 1:41 PM, Chris Graham  wrote:

> Hey!
>
> Still with IBM? I'm not. :( I've been out of work since my contract was
> ended (from the US. not locally) on Nov 28th.
>
> Dockerise, now what does that mean?
>
>
>
> On Thu, Apr 2, 2015 at 1:40 PM, jieryn  wrote:
>
>> Please dockerize all maven developer environments.
>>
>> On Wed, Apr 1, 2015 at 10:26 PM, Chris Graham 
>> wrote:
>> > Another different version, another different set of issues to solve.
>> >
>> > [INFO] --- apache-rat-plugin:0.11:check (rat-check) @ maven-scm ---
>> > [INFO] 57 implicit excludes (use -debug for more details).
>> > [INFO] Exclude: .gitignore
>> > [INFO] Exclude: README.txt
>> > [INFO] Exclude: *.sh
>> > [INFO] Exclude: .git/**
>> > [INFO] Exclude: .idea/**
>> > [INFO] Exclude: **/generated-sources/**
>> > [INFO] Exclude: **/.gitattributes
>> > [INFO] Exclude: src/main/resources/repository/**
>> > [INFO] Exclude: **/src/main/resources/tck-repository/**
>> > [INFO] Exclude: src/test/resources/**
>> > [INFO] Exclude: src/test/repository/**
>> > [INFO] Exclude: src/test/tck-repository/**
>> > [INFO] Exclude: src/main/resources/tck/**
>> > [INFO] Exclude: .java-version
>> > [INFO] Exclude: .repository/**
>> > [INFO] Exclude: target/**
>> > [INFO] Exclude: DEPENDENCIES
>> > [INFO] 4341 resources included (use -debug for more details)
>> > Warning:  org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser: Property '
>> > http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit' is not
>> > recognized.
>> > Compiler warnings:
>> >   WARNING:  'org.apache.xerces.jaxp.SAXParserImpl: Property '
>> > http://javax.xml.XMLConstants/property/accessExternalDTD' is not
>> > recognized.'
>> > Warning:  org.apache.xerces.parsers.SAXParser: Feature '
>> > http://javax.xml.XMLConstants/feature/secure-processing' is not
>> recognized.
>> > Warning:  org.apache.xerces.parsers.SAXParser: Property '
>> > http://javax.xml.XMLConstants/property/accessExternalDTD' is not
>> recognized.
>> > Warning:  org.apache.xerces.parsers.SAXParser: Property '
>> > http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit' is not
>> > recognized.
>> > [INFO] Rat check: Summary of files. Unapproved: 1745 unknown: 1745
>> > generated: 0 approved: 1305 licence.
>> > [INFO]
>> > 
>> > [INFO] Reactor Summary:
>> > [INFO]
>> > [INFO] Maven SCM . FAILURE
>> [38.306s]
>> > [INFO] Maven SCM API . SKIPPED
>> > [INFO] Maven SCM Managers  SKIPPED
>> > [INFO] Maven SCM Manager for Plexus .. SKIPPED
>> > [INFO] Maven SCM Test  SKIPPED
>> > [INFO] Maven SCM Providers ... SKIPPED
>> > [INFO] Maven SCM AccuRev Provider  SKIPPED
>> > [INFO] Maven SCM Bazaar Provider . SKIPPED
>> > [INFO] Maven SCM Clearcase Provider .. SKIPPED
>> > [INFO] Maven SCM CVS Provider - Parent ... SKIPPED
>> > [INFO] Maven SCM CVS Provider TCK tests .. SKIPPED
>> > [INFO] Maven SCM CVS Provider - Common library ... SKIPPED
>> > [INFO] Maven SCM CVS Provider - CVS Executable Impl. . SKIPPED
>> > [INFO] Maven SCM CVS Provider - CVS Java Impl. ... SKIPPED
>> > [INFO] Maven SCM Mercurial (Hg) Provider . SKIPPED
>> > [INFO] Maven SCM Git Provider - Parent ... SKIPPED
>> > [INFO] Maven SCM Git Provider - Common library ... SKIPPED
>> > [INFO] Maven SCM Git Provider TCK Tests .. SKIPPED
>> > [INFO] Maven SCM Git Provider - Git Executable Impl. . SKIPPED
>> > [INFO] Maven SCM Git Provider - JGit Impl. ... SKIPPED
>> > [INFO] Maven SCM Local Provider .. SKIPPED
>> > [INFO] Maven SCM Perforce Provider ... SKIPPED
>> > [INFO] Maven SCM Starteam Provider ... SKIPPED
>> &

Re: Building SCM 1.9.5-SNAPSHOT

[Chris Graham]

Hey!

Still with IBM? I'm not. :( I've been out of work since my contract was
ended (from the US. not locally) on Nov 28th.

Dockerise, now what does that mean?



On Thu, Apr 2, 2015 at 1:40 PM, jieryn  wrote:

> Please dockerize all maven developer environments.
>
> On Wed, Apr 1, 2015 at 10:26 PM, Chris Graham 
> wrote:
> > Another different version, another different set of issues to solve.
> >
> > [INFO] --- apache-rat-plugin:0.11:check (rat-check) @ maven-scm ---
> > [INFO] 57 implicit excludes (use -debug for more details).
> > [INFO] Exclude: .gitignore
> > [INFO] Exclude: README.txt
> > [INFO] Exclude: *.sh
> > [INFO] Exclude: .git/**
> > [INFO] Exclude: .idea/**
> > [INFO] Exclude: **/generated-sources/**
> > [INFO] Exclude: **/.gitattributes
> > [INFO] Exclude: src/main/resources/repository/**
> > [INFO] Exclude: **/src/main/resources/tck-repository/**
> > [INFO] Exclude: src/test/resources/**
> > [INFO] Exclude: src/test/repository/**
> > [INFO] Exclude: src/test/tck-repository/**
> > [INFO] Exclude: src/main/resources/tck/**
> > [INFO] Exclude: .java-version
> > [INFO] Exclude: .repository/**
> > [INFO] Exclude: target/**
> > [INFO] Exclude: DEPENDENCIES
> > [INFO] 4341 resources included (use -debug for more details)
> > Warning:  org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser: Property '
> > http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit' is not
> > recognized.
> > Compiler warnings:
> >   WARNING:  'org.apache.xerces.jaxp.SAXParserImpl: Property '
> > http://javax.xml.XMLConstants/property/accessExternalDTD' is not
> > recognized.'
> > Warning:  org.apache.xerces.parsers.SAXParser: Feature '
> > http://javax.xml.XMLConstants/feature/secure-processing' is not
> recognized.
> > Warning:  org.apache.xerces.parsers.SAXParser: Property '
> > http://javax.xml.XMLConstants/property/accessExternalDTD' is not
> recognized.
> > Warning:  org.apache.xerces.parsers.SAXParser: Property '
> > http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit' is not
> > recognized.
> > [INFO] Rat check: Summary of files. Unapproved: 1745 unknown: 1745
> > generated: 0 approved: 1305 licence.
> > [INFO]
> > 
> > [INFO] Reactor Summary:
> > [INFO]
> > [INFO] Maven SCM . FAILURE
> [38.306s]
> > [INFO] Maven SCM API . SKIPPED
> > [INFO] Maven SCM Managers  SKIPPED
> > [INFO] Maven SCM Manager for Plexus .. SKIPPED
> > [INFO] Maven SCM Test  SKIPPED
> > [INFO] Maven SCM Providers ... SKIPPED
> > [INFO] Maven SCM AccuRev Provider  SKIPPED
> > [INFO] Maven SCM Bazaar Provider . SKIPPED
> > [INFO] Maven SCM Clearcase Provider .. SKIPPED
> > [INFO] Maven SCM CVS Provider - Parent ... SKIPPED
> > [INFO] Maven SCM CVS Provider TCK tests .. SKIPPED
> > [INFO] Maven SCM CVS Provider - Common library ... SKIPPED
> > [INFO] Maven SCM CVS Provider - CVS Executable Impl. . SKIPPED
> > [INFO] Maven SCM CVS Provider - CVS Java Impl. ... SKIPPED
> > [INFO] Maven SCM Mercurial (Hg) Provider . SKIPPED
> > [INFO] Maven SCM Git Provider - Parent ... SKIPPED
> > [INFO] Maven SCM Git Provider - Common library ... SKIPPED
> > [INFO] Maven SCM Git Provider TCK Tests .. SKIPPED
> > [INFO] Maven SCM Git Provider - Git Executable Impl. . SKIPPED
> > [INFO] Maven SCM Git Provider - JGit Impl. ... SKIPPED
> > [INFO] Maven SCM Local Provider .. SKIPPED
> > [INFO] Maven SCM Perforce Provider ... SKIPPED
> > [INFO] Maven SCM Starteam Provider ... SKIPPED
> > [INFO] Maven SCM Subversion Provider - Parent  SKIPPED
> > [INFO] Maven SCM Subversion Provider - Common library  SKIPPED
> > [INFO] Maven SCM Subversion Provider TCK Tests ... SKIPPED
> > [INFO] Maven SCM Subversion Provider - SVN Executable Impl.  SKIPPED
> > [INFO] Maven SCM Synergy Provider  SKIPPED
> > [INFO] Maven SCM Visual Source Safe Provider . SKIPPED
> > [INFO] Maven SCM TFS Provider  SKIPPED
> > [INFO] Maven SCM MKS Integrity Provider 

Re: Building SCM 1.9.5-SNAPSHOT

[Chris Graham]

nformation about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
C:\CALMData\Workspaces\RTC\Deb\maven-scm>

Same error, kinda, but with different warnings.

C:\CALMData\Workspaces\RTC\Deb\maven-scm>mvn --version
Apache Maven 3.0.4 (r1232337; 2012-01-17 19:44:56+1100)
Maven home: C:\apache-maven-3.0.4\bin\..
Java version: 1.7.0_75, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_75\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows xp", version: "5.1", arch: "x86", family: "windows"
C:\CALMData\Workspaces\RTC\Deb\maven-scm>



On Thu, Apr 2, 2015 at 12:11 PM, Chris Graham  wrote:

> Hey All.
>
> I've tried updating to a sun VM. The same error as with the IBM JDK.
>
> This is with wiping the entire local repo.
>
> I've even also explicity included the exclusion of target/**
>
> [INFO] Exclude: target/**
>
> [INFO] 57 implicit excludes (use -debug for more details).
> [INFO] Exclude: .gitignore
> [INFO] Exclude: README.txt
> [INFO] Exclude: *.sh
> [INFO] Exclude: .git/**
> [INFO] Exclude: .idea/**
> [INFO] Exclude: **/generated-sources/**
> [INFO] Exclude: **/.gitattributes
> [INFO] Exclude: src/main/resources/repository/**
> [INFO] Exclude: **/src/main/resources/tck-repository/**
> [INFO] Exclude: src/test/resources/**
> [INFO] Exclude: src/test/repository/**
> [INFO] Exclude: src/test/tck-repository/**
> [INFO] Exclude: src/main/resources/tck/**
> [INFO] Exclude: .java-version
> [INFO] Exclude: .repository/**
> [INFO] Exclude: target/**
> [INFO] Exclude: DEPENDENCIES
> [INFO] 4341 resources included (use -debug for more details)
> [INFO] Rat check: Summary of files. Unapproved: 1745 unknown: 1745
> generated: 0 approved: 1305 licence.
> [INFO]
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Maven SCM . FAILURE
> [1:04.421s]
> [INFO] Maven SCM API . SKIPPED
> [INFO] Maven SCM Managers  SKIPPED
> [INFO] Maven SCM Manager for Plexus .. SKIPPED
> [INFO] Maven SCM Test  SKIPPED
> [INFO] Maven SCM Providers ... SKIPPED
> [INFO] Maven SCM AccuRev Provider  SKIPPED
> [INFO] Maven SCM Bazaar Provider . SKIPPED
> [INFO] Maven SCM Clearcase Provider .. SKIPPED
> [INFO] Maven SCM CVS Provider - Parent ... SKIPPED
> [INFO] Maven SCM CVS Provider TCK tests .. SKIPPED
> [INFO] Maven SCM CVS Provider - Common library ... SKIPPED
> [INFO] Maven SCM CVS Provider - CVS Executable Impl. . SKIPPED
> [INFO] Maven SCM CVS Provider - CVS Java Impl. ... SKIPPED
> [INFO] Maven SCM Mercurial (Hg) Provider . SKIPPED
> [INFO] Maven SCM Git Provider - Parent ... SKIPPED
> [INFO] Maven SCM Git Provider - Common library ... SKIPPED
> [INFO] Maven SCM Git Provider TCK Tests .. SKIPPED
> [INFO] Maven SCM Git Provider - Git Executable Impl. . SKIPPED
> [INFO] Maven SCM Git Provider - JGit Impl. ... SKIPPED
> [INFO] Maven SCM Local Provider .. SKIPPED
> [INFO] Maven SCM Perforce Provider ... SKIPPED
> [INFO] Maven SCM Starteam Provider ... SKIPPED
> [INFO] Maven SCM Subversion Provider - Parent  SKIPPED
> [INFO] Maven SCM Subversion Provider - Common library  SKIPPED
> [INFO] Maven SCM Subversion Provider TCK Tests ... SKIPPED
> [INFO] Maven SCM Subversion Provider - SVN Executable Impl.  SKIPPED
> [INFO] Maven SCM Synergy Provider  SKIPPED
> [INFO] Maven SCM Visual Source Safe Provider . SKIPPED
> [INFO] Maven SCM TFS Provider  SKIPPED
> [INFO] Maven SCM MKS Integrity Provider .. SKIPPED
> [INFO] Maven SCM Jazz/Rational Team Concert Provider . SKIPPED
> [INFO] Maven SCM Standard Providers .. SKIPPED
> [INFO] Maven SCM Client .. SKIPPED
> [INFO] Maven SCM Plugin .. SKIPPED
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time: 1:08.515s
> [INFO] Finished at: Thu Apr 02 12:08:10 EST 2015
> [INFO] Final Memory: 12M/47M
> [INFO]
> ---

Re: Building SCM 1.9.5-SNAPSHOT

[Chris Graham]

gt;


C:\CALMData\Workspaces\RTC\Deb\maven-scm>git log

commit 4a4f362655a301c5112be633b31c2860644ba06f
Author: Herv Boutemy 
Date:   Tue Mar 31 01:44:43 2015 +0200

changed svnpubsub url from /content to /components

Can anyone else replicate this failure or confirm that it's working (and
what's different to my setup?)

In the interim, I'll try java 7 as well.


On Wed, Apr 1, 2015 at 5:23 PM, Chris Graham  wrote:

> Heh. I was tired. For some reason, I was looking at the end of the hash,
> not the beginning. Doh!
>
> Brain fade. :-)
>
> -Chris
>
> Sent from my iPhone
>
> On 01/04/2015, at 5:03 PM, Anders Hammar  wrote:
>
> > As I'm being mentioned here I'd like to clarify:
> >
> > I'm able to build with an IBM JDK 1.6 (included with WAS 8.0.0.10) on
> > Windows 7. Some of the unit tests and int tests fail though, very likely
> > due to the fact that I'm currently behind a corp firewall/proxy.
> >
> > Chris is on Windows XP I believe, and is possibly using a slightly
> > different version of the IBM JDK 1.6. I think we were building from the
> > same git commit (master, current HEAD,
> > 4a4f362655a301c5112be633b31c2860644ba06f) though.
> >
> > Chris: git commits are identified by SHA-1 check sums, which is
> > unambiguous. Most of the time though, it's enough to specify the "short
> > SHA-1" to identify a specific commit. That's what I did in our private
> > thread where I stated "4a4f36", which is in fact the same commit you were
> > seeing with "git log" ("4a4f362655a301c5112be633b31c2860644ba06f").
> >
> > /Anders
> >
> > On Wed, Apr 1, 2015 at 5:15 AM, Chris Graham 
> wrote:
> >
> >> Hi Raphael!
> >>
> >> Thanks for that. I thought that I was on master, but I'll double check!
> >>
> >> Appreciate (from everyone) the help.
> >>
> >> -Chris
> >>
> >> On Wed, Apr 1, 2015 at 8:24 AM, Raphael Ackermann <
> >> raphael.ackerm...@gmail.com> wrote:
> >>
> >>> Default clone doesn't get you master branch but some old and outdated
> >>> branch. Had same problem with rat check.
> >>> Switching to master made it pass.
> >>>
> >>> On Tue, Mar 31, 2015, 22:23 Chris Graham  wrote:
> >>>
> >>>> Hi All.
> >>>>
> >>>> I've forked the apache scm repo on github and cloned it locally.
> >>>>
> >>>> I'm simply trying to build it, before I start making any changes at
> >> all.
> >>>>
> >>>> I've run into several issues, something is truly not right here, but I
> >>> can
> >>>> not quite work out what.
> >>>>
> >>>> At the moment, either under 2.2.1 or 3.0.4, I'm getting a RAT failure.
> >>>> Using IBM 1.6 JDK on XP.
> >>>>
> >>>> [ERROR] Failed to execute goal
> >>> org.apache.rat:apache-rat-plugin:0.11:check
> >>>> (rat-check) on project maven-scm: Too many files with unapproved
> >> license:
> >>>> 1745 See RAT report in: C:\CALMData\Workspa
> >>>> ces\RTC\Deb\maven-scm\target\rat.txt -> [Help 1]
> >>>> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> >> execute
> >>>> goal org.apache.rat:apache-rat-plugin:0.11:check (rat-check) on
> project
> >>>> maven-scm: Too many files with unapproved lice
> >>>> nse: 1745 See RAT report in:
> >>>> C:\CALMData\Workspaces\RTC\Deb\maven-scm\target\rat.txt
> >>>>at
> >>>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> >>>> MojoExecutor.java:213)
> >>>>at
> >>>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> >>>> MojoExecutor.java:153)
> >>>>at
> >>>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> >>>> MojoExecutor.java:145)
> >>>>at
> >>>>
> >> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(
> >>>> LifecycleModuleBuilder.java:84)
> >>>>at
> >>>>
> >> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(
> >>>> LifecycleModuleBuilder.java:59)
> >>>>at
> >>>>
> >>
> org.apache.maven.lifecycle.internal.LifecycleStarter.sing

Re: [VOTE] Release Apache Maven SCM version 1.9.4

[Chris Graham]

As in committer? 

How does one achieve such karma? :-)

-Chris

Sent from my iPhone

On 01/04/2015, at 7:58 AM, Hervé BOUTEMY  wrote:

> Hi Chris,
> 
> Issue modification requires developer role karma [1]
> 
> Regards,
> 
> Hervé
> 
> [1] http://xircles.codehaus.org/projects/maven/members
> 
> Le mardi 31 mars 2015 19:31:46 Chris Graham a écrit :
>> Hi Karl.
>> 
>> Sorry dude, no can do. I don't have the authority to do much at all in Jira
>> (other than create/comment).
>> 
>> Is it possible for someone to assign me sufficient authority to be able to
>> perform these jira tasks myself:
>> 
>> https://jira.codehaus.org/browse/SCM-724
>> https://jira.codehaus.org/browse/SCM-725
>> https://jira.codehaus.org/browse/SCM-774
>> https://jira.codehaus.org/browse/SCM-775
>> https://jira.codehaus.org/browse/SCM-790
>> https://jira.codehaus.org/browse/SCM-795
>> https://jira.codehaus.org/browse/SCM-796
>> 
>> Thanks!
>> 
>> -Chris
>> 
>> 
>> On Tue, Mar 31, 2015 at 4:57 AM, Karl Heinz Marbaise 
>> 
>> wrote:
>>> Hi Chris,
>>> 
>>> could you please assign those jira's to new release i've created
>>> 1.9.5.
>>> 
>>> Thanks..
>>> Kind regards
>>> Karl Heinz Marbaise
>>> 
>>> On 3/30/15 7:42 PM, Karl Heinz Marbaise wrote:
>>>> Hi Chris,
>>>> 
>>>> On 3/30/15 12:10 PM, Chris Graham wrote:
>>>>> Argh. I was going to have a few more fixed (hopefully by the end of the
>>>>> week). Are you happy to rerun a 1.9.5 in such a short period of time?
>>>> 
>>>> If they are important what i assumealways..why not...what should
>>>> us prevent...
>>>> 
>>>> 
>>>> Kind regards
>>>> Karl Heinz Marbaise
>>>> 
>>>>> -Chris
>>>>> 
>>>>> On Mon, Mar 30, 2015 at 3:20 PM, Olivier Lamy  wrote:
>>>>> +1
>>>>> 
>>>>>> On 29 March 2015 at 10:33, Karl Heinz Marbaise 
>>>>>> 
>>>>>> wrote:
>>>>>> Hi,
>>>>>> 
>>>>>>> We solved 8 issues:
>>>>>>> http://jira.codehaus.org/secure/ReleaseNote.jspa?
>>>>>>> projectId=10527&version=20624
>>>>>>> 
>>>>>>> There are still a couple of issues left in JIRA:
>>>>>>> http://jira.codehaus.org/issues/?jql=project%20%3D%
>>>>>>> 20SCM%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%
>>>>>>> 20DESC%2C%20priority%20DESC
>>>>>>> 
>>>>>>> Staging repo:
>>>>>>> https://repository.apache.org/content/repositories/maven-1162
>>>>>>> 
>>>>>>> https://repository.apache.org/content/repositories/maven-> >>>>> 
>>>>>>> 1162/org/apache/maven/scm/maven-scm/1.9.4/maven-scm-1.9.
>>>>>>> 4-source-release.zip
>>>>>>> 
>>>>>>> Source release checksum(s):
>>>>>>> maven-scm-1.9.4-source-release.zip sha1:
>>>>>>> 6dc042b15f242283c25059e7499137
>>>>>>> 52a493f6a9
>>>>>>> 
>>>>>>> Staging site:
>>>>>>> http://maven.apache.org/scm-archives/scm-LATEST/
>>>>>>> 
>>>>>>> Guide to testing staged releases:
>>>>>>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>>>>>> 
>>>>>>> Vote open for 72 hours.
>>>>>>> 
>>>>>>> [ ] +1
>>>>>>> [ ] +0
>>>>>>> [ ] -1
>>> 
>>> -
>>> 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
> 

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

Re: Maven SCM 1.9.5 (was Re: [VOTE] Release Apache Maven SCM version 1.9.4)

[Chris Graham]

Ah. Perfect. Thanks for the heads up!

:-)

-Chris

Sent from my iPhone

On 01/04/2015, at 5:17 PM, Karl Heinz Marbaise  wrote:

> Hi Chris,
> 
> if you prefer pull request just use them...No problem...
> 
> Kind regards
> Karl Heinz Marbaise
> On 3/31/15 9:17 PM, Chris Graham wrote:
>> Yes I can attach patches.
>> 
>> I thought that I had to make a pull request?
>> 
>> Sent from my iPhone
>> 
>> On 01/04/2015, at 4:12 AM, Karl Heinz Marbaise  wrote:
>> 
>>> Hi Chris,
>>> 
>>> best is to start attaching the patches you create to the appropriate 
>>> issues...so i can take a look and apply those patches...
>>> 
>>> I hope you are allowed to attach files to the issues?
>>> 
>>> I'm checking this with Hervé ...
>>> 
>>> 
>>> On 3/31/15 10:31 AM, Chris Graham wrote:
>>>> Hi Karl.
>>>> 
>>>> Sorry dude, no can do. I don't have the authority to do much at all in Jira
>>>> (other than create/comment).
>>>> 
>>>> Is it possible for someone to assign me sufficient authority to be able to
>>>> perform these jira tasks myself:
>>>> 
>>>> https://jira.codehaus.org/browse/SCM-724
>>>> https://jira.codehaus.org/browse/SCM-725
>>>> https://jira.codehaus.org/browse/SCM-774
>>> 
>>> Not a bug ?
>>> 
>>> 
>>>> https://jira.codehaus.org/browse/SCM-775
>>> 
>>>> https://jira.codehaus.org/browse/SCM-790
>>>> https://jira.codehaus.org/browse/SCM-795
>>>> https://jira.codehaus.org/browse/SCM-796
>>>> 
>>>> Thanks!
>>>> 
>>>> -Chris
> 
> -
> 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: Building SCM 1.9.5-SNAPSHOT

[Chris Graham]

Heh. I was tired. For some reason, I was looking at the end of the hash, not 
the beginning. Doh!

Brain fade. :-)

-Chris

Sent from my iPhone

On 01/04/2015, at 5:03 PM, Anders Hammar  wrote:

> As I'm being mentioned here I'd like to clarify:
> 
> I'm able to build with an IBM JDK 1.6 (included with WAS 8.0.0.10) on
> Windows 7. Some of the unit tests and int tests fail though, very likely
> due to the fact that I'm currently behind a corp firewall/proxy.
> 
> Chris is on Windows XP I believe, and is possibly using a slightly
> different version of the IBM JDK 1.6. I think we were building from the
> same git commit (master, current HEAD,
> 4a4f362655a301c5112be633b31c2860644ba06f) though.
> 
> Chris: git commits are identified by SHA-1 check sums, which is
> unambiguous. Most of the time though, it's enough to specify the "short
> SHA-1" to identify a specific commit. That's what I did in our private
> thread where I stated "4a4f36", which is in fact the same commit you were
> seeing with "git log" ("4a4f362655a301c5112be633b31c2860644ba06f").
> 
> /Anders
> 
> On Wed, Apr 1, 2015 at 5:15 AM, Chris Graham  wrote:
> 
>> Hi Raphael!
>> 
>> Thanks for that. I thought that I was on master, but I'll double check!
>> 
>> Appreciate (from everyone) the help.
>> 
>> -Chris
>> 
>> On Wed, Apr 1, 2015 at 8:24 AM, Raphael Ackermann <
>> raphael.ackerm...@gmail.com> wrote:
>> 
>>> Default clone doesn't get you master branch but some old and outdated
>>> branch. Had same problem with rat check.
>>> Switching to master made it pass.
>>> 
>>> On Tue, Mar 31, 2015, 22:23 Chris Graham  wrote:
>>> 
>>>> Hi All.
>>>> 
>>>> I've forked the apache scm repo on github and cloned it locally.
>>>> 
>>>> I'm simply trying to build it, before I start making any changes at
>> all.
>>>> 
>>>> I've run into several issues, something is truly not right here, but I
>>> can
>>>> not quite work out what.
>>>> 
>>>> At the moment, either under 2.2.1 or 3.0.4, I'm getting a RAT failure.
>>>> Using IBM 1.6 JDK on XP.
>>>> 
>>>> [ERROR] Failed to execute goal
>>> org.apache.rat:apache-rat-plugin:0.11:check
>>>> (rat-check) on project maven-scm: Too many files with unapproved
>> license:
>>>> 1745 See RAT report in: C:\CALMData\Workspa
>>>> ces\RTC\Deb\maven-scm\target\rat.txt -> [Help 1]
>>>> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
>> execute
>>>> goal org.apache.rat:apache-rat-plugin:0.11:check (rat-check) on project
>>>> maven-scm: Too many files with unapproved lice
>>>> nse: 1745 See RAT report in:
>>>> C:\CALMData\Workspaces\RTC\Deb\maven-scm\target\rat.txt
>>>>at
>>>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(
>>>> MojoExecutor.java:213)
>>>>at
>>>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(
>>>> MojoExecutor.java:153)
>>>>at
>>>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(
>>>> MojoExecutor.java:145)
>>>>at
>>>> 
>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(
>>>> LifecycleModuleBuilder.java:84)
>>>>at
>>>> 
>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(
>>>> LifecycleModuleBuilder.java:59)
>>>>at
>>>> 
>> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(
>>>> LifecycleStarter.java:183)
>>>>at
>>>> org.apache.maven.lifecycle.internal.LifecycleStarter.
>>>> execute(LifecycleStarter.java:161)
>>>>at
>> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
>>>>at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
>>>>at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
>>>>at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
>>>>at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
>>>>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>at
>>>> 
>>> 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImp

Re: Building SCM 1.9.5-SNAPSHOT

[Chris Graham]

Hi Raphael!

Thanks for that. I thought that I was on master, but I'll double check!

Appreciate (from everyone) the help.

-Chris

On Wed, Apr 1, 2015 at 8:24 AM, Raphael Ackermann <
raphael.ackerm...@gmail.com> wrote:

> Default clone doesn't get you master branch but some old and outdated
> branch. Had same problem with rat check.
> Switching to master made it pass.
>
> On Tue, Mar 31, 2015, 22:23 Chris Graham  wrote:
>
> > Hi All.
> >
> > I've forked the apache scm repo on github and cloned it locally.
> >
> > I'm simply trying to build it, before I start making any changes at all.
> >
> > I've run into several issues, something is truly not right here, but I
> can
> > not quite work out what.
> >
> > At the moment, either under 2.2.1 or 3.0.4, I'm getting a RAT failure.
> > Using IBM 1.6 JDK on XP.
> >
> > [ERROR] Failed to execute goal
> org.apache.rat:apache-rat-plugin:0.11:check
> > (rat-check) on project maven-scm: Too many files with unapproved license:
> > 1745 See RAT report in: C:\CALMData\Workspa
> > ces\RTC\Deb\maven-scm\target\rat.txt -> [Help 1]
> > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> > goal org.apache.rat:apache-rat-plugin:0.11:check (rat-check) on project
> > maven-scm: Too many files with unapproved lice
> > nse: 1745 See RAT report in:
> > C:\CALMData\Workspaces\RTC\Deb\maven-scm\target\rat.txt
> > at
> > org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> > MojoExecutor.java:213)
> > at
> > org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> > MojoExecutor.java:153)
> > at
> > org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> > MojoExecutor.java:145)
> > at
> > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(
> > LifecycleModuleBuilder.java:84)
> > at
> > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(
> > LifecycleModuleBuilder.java:59)
> > at
> > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(
> > LifecycleStarter.java:183)
> > at
> > org.apache.maven.lifecycle.internal.LifecycleStarter.
> > execute(LifecycleStarter.java:161)
> > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> > 39)
> > at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(
> > DelegatingMethodAccessorImpl.java:37)
> > at java.lang.reflect.Method.invoke(Method.java:599)
> > at
> > org.codehaus.plexus.classworlds.launcher.Launcher.
> > launchEnhanced(Launcher.java:290)
> > at
> > org.codehaus.plexus.classworlds.launcher.Launcher.
> > launch(Launcher.java:230)
> > at
> > org.codehaus.plexus.classworlds.launcher.Launcher.
> > mainWithExitCode(Launcher.java:409)
> > at
> > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> > Caused by: org.apache.rat.mp.RatCheckException: Too many files with
> > unapproved license: 1745 See RAT report in:
> > C:\CALMData\Workspaces\RTC\Deb\maven-scm\target\rat.txt
> > at org.apache.rat.mp.RatCheckMojo.check(RatCheckMojo.java:194)
> > at org.apache.rat.mp.RatCheckMojo.execute(RatCheckMojo.java:182)
> > at
> > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(
> > DefaultBuildPluginManager.java:101)
> > at
> > org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> > MojoExecutor.java:209)
> > ... 19 more
> >
> > When I look at the report file, I can see that target is being included.
> > Huh
> >
> > *
> > Summary
> > ---
> > Generated at: 2015-04-01T07:14:41+11:00
> > Notes: 176
> > Binaries: 1010
> > Archives: 80
> > Standards: 3075
> >
> > Apache Licensed: 1305
> > Generated Documents: 0
> >
> > JavaDocs are generated and so license header is optional
> > Generated files do not required license 

Re: Building SCM 1.9.5-SNAPSHOT

[Chris Graham]

I will try to find an oracle one. Anders did manage to try the IBM one, and
it worked... :(

On Wed, Apr 1, 2015 at 8:14 AM, Hervé BOUTEMY  wrote:

> Hi,
>
> No such problem here.
> Can you try with an Oracle JDK, please? Since this is the only unusual
> part of
> your configuration.
>
> Regards,
>
> Hervé
>
> Le mercredi 1 avril 2015 07:20:57 Chris Graham a écrit :
> > Hi All.
> >
> > I've forked the apache scm repo on github and cloned it locally.
> >
> > I'm simply trying to build it, before I start making any changes at all.
> >
> > I've run into several issues, something is truly not right here, but I
> can
> > not quite work out what.
> >
> > At the moment, either under 2.2.1 or 3.0.4, I'm getting a RAT failure.
> > Using IBM 1.6 JDK on XP.
> >
> > [ERROR] Failed to execute goal
> org.apache.rat:apache-rat-plugin:0.11:check
> > (rat-check) on project maven-scm: Too many files with unapproved license:
> > 1745 See RAT report in: C:\CALMData\Workspa
> > ces\RTC\Deb\maven-scm\target\rat.txt -> [Help 1]
> > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> > goal org.apache.rat:apache-rat-plugin:0.11:check (rat-check) on project
> > maven-scm: Too many files with unapproved lice
> > nse: 1745 See RAT report in:
> > C:\CALMData\Workspaces\RTC\Deb\maven-scm\target\rat.txt
> > at
> >
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:2
> > 13) at
> >
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:1
> > 53) at
> >
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:1
> > 45) at
> >
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(Life
> > cycleModuleBuilder.java:84) at
> >
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(Life
> > cycleModuleBuilder.java:59) at
> >
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(Lif
> > ecycleStarter.java:183) at
> >
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarte
> > r.java:161) at
> > org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at
> > org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at
> > org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at
> > org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at
> > org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
> > ) at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
> > .java:37) at java.lang.reflect.Method.invoke(Method.java:599)
> > at
> >
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.ja
> > va:290) at
> >
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> > at
> >
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.
> > java:409) at
> > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> > Caused by: org.apache.rat.mp.RatCheckException: Too many files with
> > unapproved license: 1745 See RAT report in:
> > C:\CALMData\Workspaces\RTC\Deb\maven-scm\target\rat.txt
> > at org.apache.rat.mp.RatCheckMojo.check(RatCheckMojo.java:194)
> > at org.apache.rat.mp.RatCheckMojo.execute(RatCheckMojo.java:182)
> > at
> >
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPl
> > uginManager.java:101) at
> >
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:2
> > 09) ... 19 more
> >
> > When I look at the report file, I can see that target is being included.
> > Huh
> >
> > *
> > Summary
> > ---
> > Generated at: 2015-04-01T07:14:41+11:00
> > Notes: 176
> > Binaries: 1010
> > Archives: 80
> > Standards: 3075
> >
> > Apache Licensed: 1305
> > Generated Documents: 0
> >
> > JavaDocs are generated and so license header is optional
> > Generated files do not required license headers
> >
> > 1745 Unknown Licenses
> >
> > ***
> >
> > Unapproved licenses:
> >
> >   maven-scm/..project
> >   maven-scm/.settings/org.maven.ide.eclipse.prefs
>

Building SCM 1.9.5-SNAPSHOT

[Chris Graham]

Hi All.

I've forked the apache scm repo on github and cloned it locally.

I'm simply trying to build it, before I start making any changes at all.

I've run into several issues, something is truly not right here, but I can
not quite work out what.

At the moment, either under 2.2.1 or 3.0.4, I'm getting a RAT failure.
Using IBM 1.6 JDK on XP.

[ERROR] Failed to execute goal org.apache.rat:apache-rat-plugin:0.11:check
(rat-check) on project maven-scm: Too many files with unapproved license:
1745 See RAT report in: C:\CALMData\Workspa
ces\RTC\Deb\maven-scm\target\rat.txt -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.rat:apache-rat-plugin:0.11:check (rat-check) on project
maven-scm: Too many files with unapproved lice
nse: 1745 See RAT report in:
C:\CALMData\Workspaces\RTC\Deb\maven-scm\target\rat.txt
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:599)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.rat.mp.RatCheckException: Too many files with
unapproved license: 1745 See RAT report in:
C:\CALMData\Workspaces\RTC\Deb\maven-scm\target\rat.txt
at org.apache.rat.mp.RatCheckMojo.check(RatCheckMojo.java:194)
at org.apache.rat.mp.RatCheckMojo.execute(RatCheckMojo.java:182)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more

When I look at the report file, I can see that target is being included.
Huh

*
Summary
---
Generated at: 2015-04-01T07:14:41+11:00
Notes: 176
Binaries: 1010
Archives: 80
Standards: 3075

Apache Licensed: 1305
Generated Documents: 0

JavaDocs are generated and so license header is optional
Generated files do not required license headers

1745 Unknown Licenses

***

Unapproved licenses:

  maven-scm/..project
  maven-scm/.settings/org.maven.ide.eclipse.prefs
  maven-scm/maven-scm-api/.classpath
  maven-scm/maven-scm-api/.project
  maven-scm/maven-scm-api/.settings/org.eclipse.jdt.core.prefs
  maven-scm/maven-scm-api/.settings/org.maven.ide.eclipse.prefs
  maven-scm/maven-scm-api/target/.plxarc
  maven-scm/maven-scm-api/target/checkstyle-cachefile
  maven-scm/maven-scm-api/target/checkstyle-header.txt
  maven-scm/maven-scm-api/target/checkstyle-result.xml

maven-scm/maven-scm-api/target/maven-status/maven-compiler-plugin/compile/default-compile/createdFiles.lst

maven-scm/maven-scm-api/target/maven-status/maven-compiler-plugin/compile/default-compile/inputFiles.lst

maven-scm/maven-scm-api/target/maven-status/maven-compiler-plugin/testCompile/default-testCompile/createdFiles.lst

maven-scm/maven-scm-api/target/maven-status/maven-compiler-plugin/testCompile/default-testCompile/inputFiles.lst
  maven-scm/maven-scm-api/target/rat.txt



Given that this was not my initial error, which was this:

ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) on
project maven-scm-api: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.17:test failed: Unable to
load the mojo 'test' in the plugin
'org.apache.maven.plugins:maven-surefire-plugin:2.17'. A required class is
missing: javax

Re: Maven SCM 1.9.5 (was Re: [VOTE] Release Apache Maven SCM version 1.9.4)

[Chris Graham]

Yes I can attach patches.

I thought that I had to make a pull request?

Sent from my iPhone

On 01/04/2015, at 4:12 AM, Karl Heinz Marbaise  wrote:

> Hi Chris,
> 
> best is to start attaching the patches you create to the appropriate 
> issues...so i can take a look and apply those patches...
> 
> I hope you are allowed to attach files to the issues?
> 
> I'm checking this with Hervé ...
> 
> 
> On 3/31/15 10:31 AM, Chris Graham wrote:
>> Hi Karl.
>> 
>> Sorry dude, no can do. I don't have the authority to do much at all in Jira
>> (other than create/comment).
>> 
>> Is it possible for someone to assign me sufficient authority to be able to
>> perform these jira tasks myself:
>> 
>> https://jira.codehaus.org/browse/SCM-724
>> https://jira.codehaus.org/browse/SCM-725
>> https://jira.codehaus.org/browse/SCM-774
> 
> Not a bug ?
> 
> 
>> https://jira.codehaus.org/browse/SCM-775
> 
>> https://jira.codehaus.org/browse/SCM-790
>> https://jira.codehaus.org/browse/SCM-795
>> https://jira.codehaus.org/browse/SCM-796
>> 
>> Thanks!
>> 
>> -Chris
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

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

Re: [VOTE] Release Apache Maven SCM version 1.9.4

[Chris Graham]

Hi Karl.

Sorry dude, no can do. I don't have the authority to do much at all in Jira
(other than create/comment).

Is it possible for someone to assign me sufficient authority to be able to
perform these jira tasks myself:

https://jira.codehaus.org/browse/SCM-724
https://jira.codehaus.org/browse/SCM-725
https://jira.codehaus.org/browse/SCM-774
https://jira.codehaus.org/browse/SCM-775
https://jira.codehaus.org/browse/SCM-790
https://jira.codehaus.org/browse/SCM-795
https://jira.codehaus.org/browse/SCM-796

Thanks!

-Chris


On Tue, Mar 31, 2015 at 4:57 AM, Karl Heinz Marbaise 
wrote:

> Hi Chris,
>
> could you please assign those jira's to new release i've created 1.9.5.
>
> Thanks..
> Kind regards
> Karl Heinz Marbaise
> On 3/30/15 7:42 PM, Karl Heinz Marbaise wrote:
>
>> Hi Chris,
>>
>> On 3/30/15 12:10 PM, Chris Graham wrote:
>>
>>> Argh. I was going to have a few more fixed (hopefully by the end of the
>>> week). Are you happy to rerun a 1.9.5 in such a short period of time?
>>>
>>
>> If they are important what i assumealways..why not...what should
>> us prevent...
>>
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>>>
>>> -Chris
>>>
>>> On Mon, Mar 30, 2015 at 3:20 PM, Olivier Lamy  wrote:
>>>
>>>  +1
>>>>
>>>> On 29 March 2015 at 10:33, Karl Heinz Marbaise 
>>>> wrote:
>>>>
>>>>  Hi,
>>>>>
>>>>> We solved 8 issues:
>>>>> http://jira.codehaus.org/secure/ReleaseNote.jspa?
>>>>> projectId=10527&version=20624
>>>>>
>>>>> There are still a couple of issues left in JIRA:
>>>>> http://jira.codehaus.org/issues/?jql=project%20%3D%
>>>>> 20SCM%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%
>>>>> 20DESC%2C%20priority%20DESC
>>>>>
>>>>> Staging repo:
>>>>> https://repository.apache.org/content/repositories/maven-1162
>>>>>
>>>>> https://repository.apache.org/content/repositories/maven-
>>>>> 1162/org/apache/maven/scm/maven-scm/1.9.4/maven-scm-1.9.
>>>>> 4-source-release.zip
>>>>>
>>>>> Source release checksum(s):
>>>>> maven-scm-1.9.4-source-release.zip sha1:
>>>>> 6dc042b15f242283c25059e7499137
>>>>> 52a493f6a9
>>>>>
>>>>> Staging site:
>>>>> http://maven.apache.org/scm-archives/scm-LATEST/
>>>>>
>>>>> Guide to testing staged releases:
>>>>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>>>>
>>>>> Vote open for 72 hours.
>>>>>
>>>>> [ ] +1
>>>>> [ ] +0
>>>>> [ ] -1
>>>>>
>>>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven SCM version 1.9.4

[Chris Graham]

Will do!

-Chris

Sent from my iPad

> On 31 Mar 2015, at 4:57 am, Karl Heinz Marbaise  wrote:
> 
> Hi Chris,
> 
> could you please assign those jira's to new release i've created 1.9.5.
> 
> Thanks..
> Kind regards
> Karl Heinz Marbaise
>> On 3/30/15 7:42 PM, Karl Heinz Marbaise wrote:
>> Hi Chris,
>> 
>>> On 3/30/15 12:10 PM, Chris Graham wrote:
>>> Argh. I was going to have a few more fixed (hopefully by the end of the
>>> week). Are you happy to rerun a 1.9.5 in such a short period of time?
>> 
>> If they are important what i assumealways..why not...what should
>> us prevent...
>> 
>> 
>> Kind regards
>> Karl Heinz Marbaise
>>> 
>>> -Chris
>>> 
>>>> On Mon, Mar 30, 2015 at 3:20 PM, Olivier Lamy  wrote:
>>>> 
>>>> +1
>>>> 
>>>> On 29 March 2015 at 10:33, Karl Heinz Marbaise 
>>>> wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> We solved 8 issues:
>>>>> http://jira.codehaus.org/secure/ReleaseNote.jspa?
>>>>> projectId=10527&version=20624
>>>>> 
>>>>> There are still a couple of issues left in JIRA:
>>>>> http://jira.codehaus.org/issues/?jql=project%20%3D%
>>>>> 20SCM%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%
>>>>> 20DESC%2C%20priority%20DESC
>>>>> 
>>>>> Staging repo:
>>>>> https://repository.apache.org/content/repositories/maven-1162
>>>>> 
>>>>> https://repository.apache.org/content/repositories/maven-
>>>>> 1162/org/apache/maven/scm/maven-scm/1.9.4/maven-scm-1.9.
>>>>> 4-source-release.zip
>>>>> 
>>>>> Source release checksum(s):
>>>>> maven-scm-1.9.4-source-release.zip sha1: 6dc042b15f242283c25059e7499137
>>>>> 52a493f6a9
>>>>> 
>>>>> Staging site:
>>>>> http://maven.apache.org/scm-archives/scm-LATEST/
>>>>> 
>>>>> Guide to testing staged releases:
>>>>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>>>> 
>>>>> Vote open for 72 hours.
>>>>> 
>>>>> [ ] +1
>>>>> [ ] +0
>>>>> [ ] -1
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

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

Re: [VOTE] Release Apache Maven SCM version 1.9.4

[Chris Graham]

Well releases are meant to be cheap and easy! :-)

So, that's fine. Thanks!

-Chris

Sent from my iPad

> On 31 Mar 2015, at 4:42 am, Karl Heinz Marbaise  wrote:
> 
> Hi Chris,
> 
>> On 3/30/15 12:10 PM, Chris Graham wrote:
>> Argh. I was going to have a few more fixed (hopefully by the end of the
>> week). Are you happy to rerun a 1.9.5 in such a short period of time?
> 
> If they are important what i assumealways..why not...what should us 
> prevent...
> 
> 
> Kind regards
> Karl Heinz Marbaise
>> 
>> -Chris
>> 
>>> On Mon, Mar 30, 2015 at 3:20 PM, Olivier Lamy  wrote:
>>> 
>>> +1
>>> 
>>>> On 29 March 2015 at 10:33, Karl Heinz Marbaise  wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> We solved 8 issues:
>>>> http://jira.codehaus.org/secure/ReleaseNote.jspa?
>>>> projectId=10527&version=20624
>>>> 
>>>> There are still a couple of issues left in JIRA:
>>>> http://jira.codehaus.org/issues/?jql=project%20%3D%
>>>> 20SCM%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%
>>>> 20DESC%2C%20priority%20DESC
>>>> 
>>>> Staging repo:
>>>> https://repository.apache.org/content/repositories/maven-1162
>>>> 
>>>> https://repository.apache.org/content/repositories/maven-
>>>> 1162/org/apache/maven/scm/maven-scm/1.9.4/maven-scm-1.9.
>>>> 4-source-release.zip
>>>> 
>>>> Source release checksum(s):
>>>> maven-scm-1.9.4-source-release.zip sha1: 6dc042b15f242283c25059e7499137
>>>> 52a493f6a9
>>>> 
>>>> Staging site:
>>>> http://maven.apache.org/scm-archives/scm-LATEST/
>>>> 
>>>> Guide to testing staged releases:
>>>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>>> 
>>>> Vote open for 72 hours.
>>>> 
>>>> [ ] +1
>>>> [ ] +0
>>>> [ ] -1
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

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

Re: [VOTE] Release Apache Maven SCM version 1.9.4

[Chris Graham]

Argh. I was going to have a few more fixed (hopefully by the end of the
week). Are you happy to rerun a 1.9.5 in such a short period of time?

-Chris

On Mon, Mar 30, 2015 at 3:20 PM, Olivier Lamy  wrote:

> +1
>
> On 29 March 2015 at 10:33, Karl Heinz Marbaise  wrote:
>
> > Hi,
> >
> > We solved 8 issues:
> > http://jira.codehaus.org/secure/ReleaseNote.jspa?
> > projectId=10527&version=20624
> >
> > There are still a couple of issues left in JIRA:
> > http://jira.codehaus.org/issues/?jql=project%20%3D%
> > 20SCM%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%
> > 20DESC%2C%20priority%20DESC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1162
> >
> > https://repository.apache.org/content/repositories/maven-
> > 1162/org/apache/maven/scm/maven-scm/1.9.4/maven-scm-1.9.
> > 4-source-release.zip
> >
> > Source release checksum(s):
> > maven-scm-1.9.4-source-release.zip sha1: 6dc042b15f242283c25059e7499137
> > 52a493f6a9
> >
> > Staging site:
> > http://maven.apache.org/scm-archives/scm-LATEST/
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>

Re: move maven core to java 7?

[Chris Graham]

What's the rush?

Releases are cheap and easy, so I find the argument to upgrade now due to one 
less release is somewhat lacking.

Sent from my iPad

> On 9 Mar 2015, at 2:22 am, Dennis Lundberg  wrote:
> 
> Hi Igor,
> 
> In my opinion the switch to Java 7 as a prerequisite is a non-risky
> thing to do, even though I still argue that we should wait till the
> next release to do it.
> 
> Making use of the new Java 7 features in the code is the risky bit.
> That in my book warrants a minor release bump rather that a patch
> version bump.
> 
>> On Sat, Mar 7, 2015 at 2:45 PM, Igor Fedorenko  wrote:
>> We changed version from 3.2.x to 3.3.x quite late in the release and
>> this was the reason I proposed change to java 7. It allows us continue
>> 3.3.x improvement and use new language features.
>> 
>> Personally I believe changing compiler configuration to target java 7 is
>> very unlikely to introduce regressions in Maven at this point, but I can
>> understand if somebody wants to do additional validation.
>> 
>> Making actual code changes just to show we use java 7 language features
>> in 3.3.0 seems unnecessary risk, however. I think it makes more sense to
>> release 3.3.0 as is, then do java 7 cleanup in 3.3.1.
>> 
>> --
>> Regards,
>> Igor
>> 
>> 
>>> On 2015-03-07 7:26, Hervé BOUTEMY wrote:
>>> 
>>> Le samedi 7 mars 2015 13:06:26 Hervé BOUTEMY a écrit :
> 
> There is nothing stoping you from releasing 3.3.0 on Java 6 now, and
> 3.4.0
> on Java 7 in a few weeks.
 
 
 what I don't like with this plan is that it is exactly what happened with
 3.1.1 then 3.2.1:
>>> 
>>> and before 2.1.0 vs 2.2.0
>>> 
>>> and the only cause (IIRC) is that we had a schedule, then thought it would
>>> be
>>> good to upgrade, but didn't change the schedule to have 1 to 2 weeks to
>>> test
>>> 
>>> if we decide to take 2 weeks to integrate some improvements that the
>>> upgrade
>>> permits and test, would the upgrade to 3.3.0 be ok?
>>> 
>>> Regards,
>>> 
>>> Hervé
>>> 
 we never did any bugfix for 3.1.1, 3.1.1 was a dead branch
 for start. 3.2.2 bugfixes could/should have been backported to 3.1.1, but
 who will ever do that? (not me...)
 
 I agree that the lack of schedule can be a problem if we decide to make
 the
 release this week-end: but if we take one week to integrate Java 7
 improvements (ie mostly syntax for better maintainability and a few new
 APIs) and take one week after that to test the result, IMHO we get a
 better
 plan: a new Maven version, with features and the assurance we'll do
 bugfix
 releases on it (the fact that it has upgraded Java requirement is just a
 fact on release notes)
 
 Regards,
 
 Hervé
 
 Le samedi 7 mars 2015 12:04:15 Dennis Lundberg a écrit :
> 
> Hi Kristian,
> 
> Please note that I am not opposed to using Java 7 in the core. What I am
> objecting to is the planning, or rather the lack of it.
> 
> We currently have core ready to be released on Java 6. Then just before
> it
> is about to be released someone says, hey  lets switch Java version as
> well. IMO that is something you should plan for before work is even
> started
> on the next release.
> 
> Then there is the agreement we made regarding Java versions and their
> EOL.
> 
> Switching to Java 7 before the release will mean that a fewer number of
> users will be able to reap the benefits of the bugfixes and features in
> Maven 3.3.0.
> 
> There is nothing stoping you from releasing 3.3.0 on Java 6 now, and
> 3.4.0
> on Java 7 in a few weeks.
> 
> Weighing in all of this I don't see any reason to change the Java
> version
> for 3.3.0.
> Den 6 mar 2015 13:54 skrev "Kristian Rosenvold" <
> 
> kristian.rosenv...@gmail.com>:
>> 
>> I already have the full jdk7 port in a branch in github, so that
>> assumption
>> does not hold :)
>> 
>> Kristian
>> 
>> 2015-03-06 13:50 GMT+01:00 Dennis Lundberg :
>>> 
>>> Hi,
>>> 
>>> If we are going to release 3.3.0 very soon, like this week or the
>>> next, there won't be any time to start using Java 7 features in the
>>> 3.3.0 release. Therefor I would prefer to go with Java 6 for 3.3.0 and
>>> announce, in the 3.3.0 release notes, that the 3.3.x line is the last
>>> line that will work with Java 6. Depending on what the core developers
>>> want to focus on after the 3.3.0 release is done, the core can either
>>> go 3.3.1-SNAPSHOT with Java 6 or 3.4.0-SNAPSHOT with Java 7. This
>>> would also be consistent with our policy [1] for plugins/components
>>> wanting to move to a higher major Java version, in that we should
>>> release what we currently have in trunk before upgrading to a higher
>>> major Java version.
>>> 
>>> My votes are:
>>> -1 for Java 7 in 3.3.0
>>> +1 for Ja

Re: move maven core to java 7?

[Chris Graham]

My preference is to always go for the lowest common denoninator, as it
gives the largest possible spread.

My 'grumbling' as Stephen put it [ :-) ], is more that I'd like people to
have an awareness that there are other platforms out there.

For example, the current IBM WAS 8.x stack defaults to Java 6, and Java 7
is an extra optional install. I'm not sure if there is an IBM Java 8
available (or being used in a product - I'm not sure, I've not looked, and
now, I no long can!).

Once the core moves the plugins will follow.

I don't necessarilly agree with the premise that those stuck on older
versions of Java will not want to use the newer core/plugins, especially as
backports of fixes are exceptionally uncommon.

But if you feel the pressing need to update, feel free.


On Fri, Mar 6, 2015 at 6:11 AM, Karl Heinz Marbaise 
wrote:

> Hi,
>
> On 3/5/15 2:16 PM, Igor Fedorenko wrote:
>
>> This is chicken-and-egg situation. We won't use java 7 features unless
>> the code targets java 7.
>>
>> Try-with-resources and multi-exception catch are the too features I'd
>> like to start using throughout the code. Although not "critical" per se,
>> I think they make writing correct maintainable code noticeably easier.
>>
>> Improvements to standard library, nio in particular, is another big
>> reason for me. For example, Files#walkFileTree is significantly faster
>> than comparable File-based implementation on large source trees. Knowing
>> the core is on java 7 will allow us use that in plexus-utils for example.
>>
>
> Hm..plexus-utils is used in many plugins which would cause them to upgrade
> to Java 7 as well ?
>
>
>
>> Besides, java 7 is EOL'ed by Oracle next month. Yes, many organizations
>> still use java 6 (and java 5), but the same organizations are not likely
>> to move to use latest maven features any time soon either.
>>
>> --
>> Regards,
>> Igor
>>
>> On 2015-03-05 7:59, Robert Scholte wrote:
>>
>>> I don't know the numbers, but I think JDK6 is still used a lot by the
>>> community.
>>> Current code builds fine with JDK6.
>>> Which JDK7 specific features do you want to use, which are not possible
>>> with the current codebase?
>>> Without any critical codechanges I'd go for -1.
>>>
>>> Robert
>>>
>>> Op Thu, 05 Mar 2015 13:19:11 +0100 schreef Igor Fedorenko
>>> :
>>>
>>>  With maven core version change to 3.3.0 on master, any objections I
 change compile source/target to java 7?

 --
 Regards,
 Igor


>
> Kind regards
> Karl Heinz Marbaise
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: SCM Providers

[Chris Graham]

Brilliant! Ta!

Now, to find the VM I was using... :)

-Chris

On Wed, Mar 4, 2015 at 8:18 AM, Robert Scholte  wrote:

> We're already preparing a solution for Jira. So as long as Jira isn't
> read-only, all issues and comments should be safe and will be included with
> the migration.
>
> Robert
>
> Op Tue, 03 Mar 2015 22:11:18 +0100 schreef Chris Graham <
> chrisgw...@gmail.com>:
>
>
>  Excellent! Jazz/RTC it's optional as well. UCM Clearcase is, but not
>> ClearQuest Enabled UCM Clearcase (but that's the point of CQ!).
>>
>> Ok, I'll roll my sleeves up!
>>
>> So what is the current issue tracker now? Given that codehaus's is going
>> away?
>>
>> I'll manually copy the live issues if need be.
>>
>>
>> On Wed, Mar 4, 2015 at 7:54 AM, Robert Scholte 
>> wrote:
>>
>>  Hi Chris,
>>>
>>> It seems like these are the only systems (only retweets of my question,
>>> no
>>> responses).
>>> AFAIK for TFS is is optional, depending on how you configured it on your
>>> server.
>>> I haven't found a general term for this concept, so I would go for
>>> workitem.
>>> It looks indeed like the pushChanges option, so let's see if such an
>>> implementation would fit.
>>>
>>> thanks,
>>> Robert
>>>
>>> Op Thu, 26 Feb 2015 01:10:43 +0100 schreef Chris Graham <
>>> chrisgw...@gmail.com>:
>>>
>>>
>>>  Hi Robert.
>>>
>>>>
>>>> Yes, it's time that I think we should. :)
>>>>
>>>> I may have some time shortly to look into fixing the outstanding Jazz
>>>> issues.
>>>>
>>>> Firstly, what do we call the
>>>> workitemId/ticketNo/whateverelsethingsarecalled ?
>>>> Where do we put it? I'd be tempted to put it in the same structure as
>>>> pushChanges, as it's easily accessable and can be used across all scm
>>>> providers.
>>>>
>>>> So you've said that MS TFS uses (is it optional or mandatory?) a
>>>> workitem
>>>> concept. Jazz does, and it's optional per workspace. What other SCM
>>>> use/require a workitem concept? ClearQuest enabled UCM Clearcase has a
>>>> task. Any others?
>>>>
>>>> -Chris
>>>>
>>>>
>>>> On Thu, Sep 11, 2014 at 5:22 AM, Robert Scholte 
>>>> wrote:
>>>>
>>>>  Hi Chris,
>>>>
>>>>>
>>>>> I had to dive deep in my mail archive, but it seems that the day after
>>>>> my
>>>>> attempt a colleague managed to release with my initial setup. So it
>>>>> probably had to do with my rights, configuration or whatever. I'll ask
>>>>> the
>>>>> status of that project and if the still can release successfully.
>>>>>
>>>>> It would be nice if we could collect a couple of usecases with
>>>>> workitems
>>>>> and with different scm's if possible and come with a good strategy to
>>>>> solve
>>>>> this.
>>>>>
>>>>> thanks,
>>>>> Robert
>>>>>
>>>>> Op Wed, 10 Sep 2014 07:39:10 +0200 schreef Chris Graham <
>>>>> chrisgw...@gmail.com>:
>>>>>
>>>>>
>>>>>  Hi Robert!
>>>>>
>>>>>
>>>>>> From a thread a long time ago! This issue has popped up again.
>>>>>>
>>>>>> https://jira.codehaus.org/browse/SCM-775
>>>>>>
>>>>>> Did you/How did you ever end up solving the issue for TFS?
>>>>>>
>>>>>> You're right, a general solution would be preferable.
>>>>>>
>>>>>> I think the workflow around the (re)use of a Work Item would be
>>>>>> determined
>>>>>> by the client, and I'd rather not force their hand on that one.
>>>>>>
>>>>>> -Chris
>>>>>>
>>>>>>
>>>>>> On Thu, Jul 25, 2013 at 4:27 AM, Robert Scholte >>>>> >
>>>>>> wrote:
>>>>>>
>>>>>>  Hi,
>>>>>>
>>>>>>
>>>>>>> Recently I had a look at Microsoft Team Foundation Server and faced
>>>>>>> the
>>>>&g

Re: SCM Providers

[Chris Graham]

Excellent! Jazz/RTC it's optional as well. UCM Clearcase is, but not
ClearQuest Enabled UCM Clearcase (but that's the point of CQ!).

Ok, I'll roll my sleeves up!

So what is the current issue tracker now? Given that codehaus's is going
away?

I'll manually copy the live issues if need be.


On Wed, Mar 4, 2015 at 7:54 AM, Robert Scholte  wrote:

> Hi Chris,
>
> It seems like these are the only systems (only retweets of my question, no
> responses).
> AFAIK for TFS is is optional, depending on how you configured it on your
> server.
> I haven't found a general term for this concept, so I would go for
> workitem.
> It looks indeed like the pushChanges option, so let's see if such an
> implementation would fit.
>
> thanks,
> Robert
>
> Op Thu, 26 Feb 2015 01:10:43 +0100 schreef Chris Graham <
> chrisgw...@gmail.com>:
>
>
>  Hi Robert.
>>
>> Yes, it's time that I think we should. :)
>>
>> I may have some time shortly to look into fixing the outstanding Jazz
>> issues.
>>
>> Firstly, what do we call the
>> workitemId/ticketNo/whateverelsethingsarecalled ?
>> Where do we put it? I'd be tempted to put it in the same structure as
>> pushChanges, as it's easily accessable and can be used across all scm
>> providers.
>>
>> So you've said that MS TFS uses (is it optional or mandatory?) a workitem
>> concept. Jazz does, and it's optional per workspace. What other SCM
>> use/require a workitem concept? ClearQuest enabled UCM Clearcase has a
>> task. Any others?
>>
>> -Chris
>>
>>
>> On Thu, Sep 11, 2014 at 5:22 AM, Robert Scholte 
>> wrote:
>>
>>  Hi Chris,
>>>
>>> I had to dive deep in my mail archive, but it seems that the day after my
>>> attempt a colleague managed to release with my initial setup. So it
>>> probably had to do with my rights, configuration or whatever. I'll ask
>>> the
>>> status of that project and if the still can release successfully.
>>>
>>> It would be nice if we could collect a couple of usecases with workitems
>>> and with different scm's if possible and come with a good strategy to
>>> solve
>>> this.
>>>
>>> thanks,
>>> Robert
>>>
>>> Op Wed, 10 Sep 2014 07:39:10 +0200 schreef Chris Graham <
>>> chrisgw...@gmail.com>:
>>>
>>>
>>>  Hi Robert!
>>>
>>>>
>>>> From a thread a long time ago! This issue has popped up again.
>>>>
>>>> https://jira.codehaus.org/browse/SCM-775
>>>>
>>>> Did you/How did you ever end up solving the issue for TFS?
>>>>
>>>> You're right, a general solution would be preferable.
>>>>
>>>> I think the workflow around the (re)use of a Work Item would be
>>>> determined
>>>> by the client, and I'd rather not force their hand on that one.
>>>>
>>>> -Chris
>>>>
>>>>
>>>> On Thu, Jul 25, 2013 at 4:27 AM, Robert Scholte 
>>>> wrote:
>>>>
>>>>  Hi,
>>>>
>>>>>
>>>>> Recently I had a look at Microsoft Team Foundation Server and faced the
>>>>> same kind of issue.
>>>>> I'm not sure if you could/should reuse a WorkItem. For the
>>>>> maven-release-plugin this could very well be acceptable, but for
>>>>> commits
>>>>> in
>>>>> general? I don't think so.
>>>>> If it is static, then you can make it part of the SCM-URL
>>>>> If it is a system-wide setting, then create a specific
>>>>> scm-settings.xml.
>>>>>
>>>>> This latter is not very well documented, or it is hard to find. In the
>>>>> past I've written a setup-maven-plugin[1], with which you could create
>>>>> such
>>>>> files and which has a link to the original documentation.
>>>>>
>>>>> If the workitem is variable, then the -D option is probably the best.
>>>>>
>>>>> Would be nice if we could think of a general solution.
>>>>>
>>>>>
>>>>> Robert
>>>>>
>>>>> [1] http://mojo.codehaus.org/setup/setup-maven-plugin/plugin-info.html
>>>>>
>>>>> Op Wed, 24 Jul 2013 01:35:43 +0200 schreef Chris Graham <
>>>>> chrisgw...@gmail.com>:
>>>>>
>>>>>
>&

Re: status of last plugins release with Maven 2.2.1 and Java 5 requirements

[Chris Graham]

Sent from my iPad

> On 3 Mar 2015, at 6:35 pm, Karl Heinz Marbaise  wrote:
> 
> Hi,
>> On 3/3/15 5:45 AM, Hervé BOUTEMY wrote:
>> Hi Maven devs,
>> 
>> We're now near the objective [1]
>> 
>> On 49 plugins, 37 reached the target (with m-pmd-p requiring Java 6 instead 
>> of
>> 5) and 2 already jumped to Maven 3.0 requirement
>> And maven-stage-plugin is on vote
>> 
>> = 40 from 49: more than 80% of the job is done, great!
>> 
>> Thank you to those who worked on this, particularly Karl Heinz who did a 
>> great
>> part of it.
>> 
>> This lets 9 plugins to release:
>> - maven-scm-plugin
> 
> One issue open which could be moved to an other release..

Huh??? There should be at least 2-3 jazz issues open.

> 
>> - maven-docck-plugin
> 
> Is ready for release...i can do that within the next days...
> 
>> - maven-jar-plugin
>> - maven-patch-plugin
> 
> Is ready for release...i can do that within the next days...
> 
> 
>> - maven-verifier-plugin
> 
> There had been some updates in the verifier shared component and it would be 
> wise to wait for a release of the shared component...
> 
>> - maven-archetype-plugin
> 
> Benson has made it work...I can do the release if no objections Benson?
> 
> 
>> - maven-eclipse-plugin
> 
> 
>> - maven-compiler-plugin
> 
> Release 3.3 seemed to be ready for releaseI can if no one else would like 
> to do the release...
> 
> 
>> - maven-doap-plugin
> 
> Currently a single issue open...
> 
>> 
>> Are there volunteers on each one, please?
>> 
>> IMHO, we should write down the list of plugins and versions to the Maven 2 
>> EOL
>> page [2], to clearly store this info while it is available (copy/pasting the
>> report) and link to versioned documentation of every plugin: if no objection,
>> I'll do it in a few days.
> 
> This would be great...I can support if you need help...
> 
>> 
>> I think that we should also have a convention on each plugin (and perhaps 
>> each
>> component) to document requirements history: I have no precise idea on the 
>> way
>> to do that. Addition to plugin-info.html (with parameters in pom.xml)? Add a
>> standard paragraph in index.html (and update maven-docck-plugin to check for
>> it)? Any idea?
>> 
>> Then we'll be able to upgrade to Maven 3.0 and Java 6 requirements in parent
>> pom.
>> And of course announce to users the plan towards plugins 3.x for Maven 3.0 
>> and
>> JDK 6 requirement (and remember full Maven 2.x EOL, that is not only Maven,
>> but also plugins).
>> 
>> Really good job: this gives a great consistency step that was lacking before.
>> 
>> Regards,
>> 
>> Hervé
>> 
>> [1] 
>> https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/dist-tool-prerequisites.html
>> 
>> [2] http://maven.apache.org/maven-2.x-eol.html
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>> 
> 
> 
> Mit freundlichem Gruß
> Karl-Heinz Marbaise
> -- 
> SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
> Dipl.Ing.(FH) Karl-Heinz MarbaiseICQ#: 135949029
> Hauptstrasse 177 USt.IdNr: DE191347579
> 52146 Würselen   http://www.soebes.de
> 
> -
> 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: SCM Providers

[Chris Graham]

Hi Robert.

Yes, it's time that I think we should. :)

I may have some time shortly to look into fixing the outstanding Jazz
issues.

Firstly, what do we call the
workitemId/ticketNo/whateverelsethingsarecalled ?
Where do we put it? I'd be tempted to put it in the same structure as
pushChanges, as it's easily accessable and can be used across all scm
providers.

So you've said that MS TFS uses (is it optional or mandatory?) a workitem
concept. Jazz does, and it's optional per workspace. What other SCM
use/require a workitem concept? ClearQuest enabled UCM Clearcase has a
task. Any others?

-Chris


On Thu, Sep 11, 2014 at 5:22 AM, Robert Scholte 
wrote:

> Hi Chris,
>
> I had to dive deep in my mail archive, but it seems that the day after my
> attempt a colleague managed to release with my initial setup. So it
> probably had to do with my rights, configuration or whatever. I'll ask the
> status of that project and if the still can release successfully.
>
> It would be nice if we could collect a couple of usecases with workitems
> and with different scm's if possible and come with a good strategy to solve
> this.
>
> thanks,
> Robert
>
> Op Wed, 10 Sep 2014 07:39:10 +0200 schreef Chris Graham <
> chrisgw...@gmail.com>:
>
>
>  Hi Robert!
>>
>> From a thread a long time ago! This issue has popped up again.
>>
>> https://jira.codehaus.org/browse/SCM-775
>>
>> Did you/How did you ever end up solving the issue for TFS?
>>
>> You're right, a general solution would be preferable.
>>
>> I think the workflow around the (re)use of a Work Item would be determined
>> by the client, and I'd rather not force their hand on that one.
>>
>> -Chris
>>
>>
>> On Thu, Jul 25, 2013 at 4:27 AM, Robert Scholte 
>> wrote:
>>
>>  Hi,
>>>
>>> Recently I had a look at Microsoft Team Foundation Server and faced the
>>> same kind of issue.
>>> I'm not sure if you could/should reuse a WorkItem. For the
>>> maven-release-plugin this could very well be acceptable, but for commits
>>> in
>>> general? I don't think so.
>>> If it is static, then you can make it part of the SCM-URL
>>> If it is a system-wide setting, then create a specific scm-settings.xml.
>>>
>>> This latter is not very well documented, or it is hard to find. In the
>>> past I've written a setup-maven-plugin[1], with which you could create
>>> such
>>> files and which has a link to the original documentation.
>>>
>>> If the workitem is variable, then the -D option is probably the best.
>>>
>>> Would be nice if we could think of a general solution.
>>>
>>>
>>> Robert
>>>
>>> [1] http://mojo.codehaus.org/setup/setup-maven-plugin/plugin-info.html
>>>
>>> Op Wed, 24 Jul 2013 01:35:43 +0200 schreef Chris Graham <
>>> chrisgw...@gmail.com>:
>>>
>>>
>>>  Hey All.
>>>
>>>>
>>>> In the RTC/Jazz forum, a request came up for the ability to associate a
>>>> Work Item with the commits that the SCM plugin does.
>>>>
>>>> On the Jazz side, I think that I've worked things out.
>>>>
>>>> However, I am unsure as to how to best do this on the maven and scm
>>>> provider side.
>>>>
>>>> The generic question boils down to:
>>>>
>>>> How can we supply a scm specific parameter to a specific scm provider?
>>>>
>>>> One that is not applicable to all providers.
>>>>
>>>> I really do not want to add a -D option. :-)
>>>>
>>>> Thoughts/comments/suggestions?
>>>>
>>>> -Chris
>>>>
>>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] To SemVer or not to SemVer, that is the question

[Chris Graham]

On Mon, Feb 23, 2015 at 8:42 AM, Fred Cooke  wrote:

>
> I'd also love to hear that no one is trying to release 200 artifacts in a
> single reactor. That makes no sense at all, to me. The chances are on a big
> corporate project you've only changed <25% of them per top level release
> anyway. So to run a top level MVN release against the entire tree would
> produce 75% duplicate (by code, not number) artifacts. Or did I
> misunderstand?
>

>From a pragmatic, not a SemVer point of view, it makes a lot of sense. I
can think of some Message Broker projects that I did, with a few hundred
message sets. You're right, in that the % change is minimal. The issue is
that it's rarely the same modules that change. And in that sense, setting
up the SCM tagging would be a nightmare.

So, what I've done is to set up a monolithic build, where I rebuild
everything everytime, and release everything time. So it's not SemVer, but
it works. I can verify the SCM provenance of the code with a single tag.
The only thing that defines a vesion, is that it's different, in some way,
to another another version.

In message brokers case, it drastically simplifies the deployment options,
it's simple as everything gets deployed each and every time. Automating the
deployment of a single message set across any given number of bar files
into whatever execution groups require it would be next to impossible (and
not worth the effort in doing so).

I used long life release branches (a release of X.Y lives in it's own
branch, in some cases up to 18 months), with many releases of
X.Y.Z-SNAPSHOT on the branch. The last project used Oracle CC&B, and we
have 5 concurrent release branches. SemVer in that instance is not doable.

So yes, the same code will be tagged multiple times, with different
versions with no real changes to the module. And that is fine. You've also
got to remember that I set the maven builds up underneath the devs, so that
they were not aware of it, other than this strange looking pom.xml that
suddenly appeared in their projects :)

Re: Remove M2_HOME setup from download page instructions

[Chris Graham]

I switch between versions all the time; this is useful.

Sent from my iPhone

On 27/01/2015, at 4:47 PM, "Manfred Moser"  wrote:

> I would still suggest to make sure its documented somewhere. I find it 
> incredibly useful to just change M2_HOME to simply switch Maven versions. 
> 
> manfred
> 
> Mirko Friedenhagen wrote on 26.01.2015 21:40:
> 
>> Dan, go ahead, I have not set this variable for years.
>> 
>> Regards
>> Mirko
>> -- 
>> Sent from my mobile
>> On Jan 27, 2015 5:52 AM, "Dan Tran"  wrote:
>> 
>>> Hi,
>>> 
>>> Any objection  to remove the need to setup M2_HOME env variable at maven
>>> download page?
>>> 
>>> 
>>> Thanks
>>> 
>>> -Dan
>>> 
>>> https://jira.codehaus.org/browse/MNGSITE-223
>>> 
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

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

Re: [VOTE] Name our mascot: "Shotgun" vs "The Maven Owl"

[Chris Graham]

A

Sent from my iPhone

On 15/12/2014, at 9:39 PM, Stephen Connolly  
wrote:

> After the run-off round, we are left with two names standing.
> 
> This second vote will be a straight and simple majority wins.
> 
> The vote will be open for at least 72 hours (with the potential of an
> extension until I send a message saying that the polls are closed)
> 
> There will be no discussion in this thread, we have talked it all enough
> already. If you want to discuss something, please use a different thread.
> 
> Vote:
> 
> [A]: Shotgun
> [B]: The Maven Owl
> 
> Thank you very much for your time
> 
> -Stephen

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

Re: [VOTE] Run-off for mascot's name

[Chris Graham]

H

-Chris

Sent from my iPhone

On 10/12/2014, at 11:53 PM, Graham Leggett  wrote:

> Hi all,
> 
> K.
> 
> Regards,
> Graham
> --
> 
> 
>> On 9 Dec 2014, at 10:52, Stephen Connolly  
>> wrote:
>> 
>> This is a run-off vote to select the top two options for our new mascot's
>> name.
>> 
>> The entries with the highest number of votes will be selected for the final
>> round. If there is only one entry with the highest number of votes then the
>> entries with the second highest number of votes will also be included in
>> the final round.
>> 
>> The vote will be open for 72 hours.
>> 
>> The entries are as follows:
>> 
>> A. Abraham
>> B. Boo
>> C. Darth Mowl
>> D. Jacob
>> E. Kaboom
>> F. Moses
>> G. Rap
>> H. Shotgun
>> K. The Maven Owl
>> L. Ty
>> 
>> It is not clear whether all of the above suggestions were completely
>> serious, but I have included them anyway for this first round.
>> 
>> Please respond with at most your top three in order of preference. I may
>> not use second or third preferences if we get a sufficient number of votes,
>> but in the case of a small poll the additional preferences will help.
>> 
>> In the event of repeated votes from an individual, only the last cast vote
>> as determined by me will count.
>> 
>> Any other discussion should happen in a separate thread.
>> 
>> Thanks
>> 
>> -Stephen
> 
> -
> 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: Ticket Transition Workflow: Abandoned issues

[Chris Graham]

RTC uses Backlog. Does Jira have something similar?

Sent from my iPhone

On 27/11/2014, at 8:13 AM, David Jencks  wrote:

> Retired rather than Archived?
> 
> This cleanup seems like a really good idea :-)
> 
> david jencks
> 
> On Nov 26, 2014, at 12:41 PM, Paul Benedict  wrote:
> 
>> My 2-cents on the word "Archived" is that it's a synonym for
>> Backup/Storage, which I don't think is what this process is about.
>> 
>> 
>> Cheers,
>> Paul
>> 
>> On Wed, Nov 26, 2014 at 1:57 PM, Michael Osipov  wrote:
>> 
>>> Am 2014-11-26 um 16:16 schrieb Paul Benedict:
>>> 
 This email is related to thread "Abandoned bug analysis" [1].
 
 We have done the Great Ticket Cleanup of 2014 twice this year. It has
 really been productive for anyone who triages outstanding bugs and
 enhancements. We've been adding a note in the ticket, as a courtesy to the
 participants, and closing them as "Won't Fix".
 
 This is certainly one valid way of accomplishing the goal. However, I do
 believe we should enhance our workflow by adding an "Abandoned" (my fav)
 or
 "Archived" resolution. Why? Because "Won't Fix" is typically is used to
 close out a bug that will never be fixed (i.e., too many people rely on
 the
 bad behavior) or the enhancement is deemed worthless or incorrect. But
 more
 importantly, it's not possible to do a JIRA search and distinguish between
 these two conditions unless a new resolution is introduced.
 
>>> 
>>> We need two new things:
>>> 
>>> 1. Status: Awaiting Feedback (not just labels).
>>> 2. Resolution: Archived
>>> 
>>> Michael
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>> 
>>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

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

Re: Ticket Transition Workflow: Abandoned issues

[Chris Graham]

Nicely worded!

+1

Sent from my iPhone

On 27/11/2014, at 2:16 AM, Paul Benedict  wrote:

> This email is related to thread "Abandoned bug analysis" [1].
> 
> We have done the Great Ticket Cleanup of 2014 twice this year. It has
> really been productive for anyone who triages outstanding bugs and
> enhancements. We've been adding a note in the ticket, as a courtesy to the
> participants, and closing them as "Won't Fix".
> 
> This is certainly one valid way of accomplishing the goal. However, I do
> believe we should enhance our workflow by adding an "Abandoned" (my fav) or
> "Archived" resolution. Why? Because "Won't Fix" is typically is used to
> close out a bug that will never be fixed (i.e., too many people rely on the
> bad behavior) or the enhancement is deemed worthless or incorrect. But more
> importantly, it's not possible to do a JIRA search and distinguish between
> these two conditions unless a new resolution is introduced.
> 
> So I'd like to officially propose a new resolution to address this concern.
> 
> [1]
> http://mail-archives.apache.org/mod_mbox/maven-dev/201411.mbox/%3c5473ab9b.4090...@apache.org%3E
> 
> Cheers,
> Paul

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

Re: Abandoned bugs analysis

[Chris Graham]

+1 for Abandoned or Archived.

Won't Fix implies that some one has actually looked at it.

-Chris

Sent from my iPhone

On 26/11/2014, at 9:05 AM, Paul Benedict  wrote:

> We did this bug clean up before so this isn't new to me. However, I do
> wonder if the resolution "Won't Fix" rubs people the wrong way? Maybe if we
> had an "Abandoned" resolution that would sit better. Aside from reading the
> comments in the ticket, it's not possible to know what was closed truly
> because something is intended never to be fixed and what was closed due to
> age.
> 
> 
> Cheers,
> Paul
> 
> On Tue, Nov 25, 2014 at 3:58 PM, Michael Osipov  wrote:
> 
>> One postive response from MECLIPSE-196: Perfectly happy this was closed,
>> happy we're not using EARs any more. Can't wait to see new things coming
>> from takari.
>> 
>> Am 2014-11-25 um 22:22 schrieb Jason van Zyl:
>> 
>>> I don't agree. This is a project, not a product and if no one looks at
>>> something for 2 years then no one cares. We are not erasing the issues and
>>> if someone does care enough to ask to reopen an issue then that's great.
>>> But I've tried to purge down the list to something manageable twice now and
>>> it keeps growing so I highly appreciate what Michael is doing because it's
>>> unmanageable right now. And now that he's done that I have some motivation
>>> again to look through the issues so kudos to Michael. Nothing stops anyone
>>> from going through and reopening something, I don't think we need group
>>> scrubbing sessions. I think core committers need to go through and help
>>> curate the issues on a more regular basis.
>>> 
>>> On Nov 25, 2014, at 4:03 PM, Dennis Lundberg  wrote:
>>> 
>>> Hi Michael
 
 Unfortunatelly, I think that 2 years of inactivity is way to short time.
 I
 wish it wasn't so, but the reality is that the age of an issue is not a
 good indicator of whether the issue is valid or not.
 
 I think a better approach is to have joint bug scrub sessions, where we
 join forces to manually check the validity of the issues.
 
 --
 Dennis Lundberg
 Den 24 nov 2014 23:05 skrev "Michael Osipov" :
 
 Hi folks,
> 
> I ran this query in JIRA: project in projectsWhereUserHasPermission
> ("Administer
> Projects") AND updated <= "2012-12-31" and resolution = Unresolved and
> type
> = Bug ORDER BY created desc
> 
> Bugs which haven't been touched for almost two years. Total amount:
> *1139*. A lot of them are still Maven 1.x related 8-).
> 
> Is there someone with bulk change abilities able to close those as
> "Won't
> Fix" with a note like: Big clean up end of 2014, you think that this
> issue
> still persists, reopen it?
> 
> What do you think?
> 
> Michael
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 
> 
>>> Thanks,
>>> 
>>> Jason
>>> 
>>> --
>>> Jason van Zyl
>>> Founder,  Apache Maven
>>> http://twitter.com/jvanzyl
>>> http://twitter.com/takari_io
>>> -
>>> 
>>> the course of true love never did run smooth ...
>>> 
>>>  -- Shakespeare
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> -
>> 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: New logo?

[Chris Graham]

On Sat, Nov 22, 2014 at 10:38 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On Saturday, November 22, 2014, Chris Graham  wrote:
>
> > Chiming in late here. Where does "Couché-tard" come from and what does it
> > mean? How is it relevant?
>
>
> Couché-tard is the French nickname for an owl, literal meaning is "sleeps
> late"
>
>
So, if you don't speak French, or have a classical education, you're not
likely to get that. I guess, that if people are going to ask what is it, is
it a good logo?

And it's franco centric, wouldn't the comments about the feature and native
amercian indians apply?


> >
> > I read one of Stephen's earlier posts where the colourisation V was
> > questions. Stephen's response was the wrong one: Would you prefer the A?
> My
> > response is: why colourise or stress any of them? I don't get the
> > significance.
>
>
> We have a logo that currently stresses the a for - from my perspective - no
> reason at all.
>
> If we ditch all stress then we have little continuity of the existing brand
>
>
The name is the brand, I doubt very much that anyone would place undue
attention on a stressed a or v.


> Thus for continuity I favour stressing one letter, and because this is v3
> of our logo I choose the 3rd letter and v for version ;-) (real reason is I
> think the v looks better)
>
>
Than a 'a', yes. Agreed. But are we trying too hard to be too cute too
cleaver?


> >
> >
> > On Thu, Nov 20, 2014 at 8:43 PM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com > wrote:
> >
> > > Stop calling Couché-tard "shotgun owl"!
> > >
> > > Does this make it clearer that it's a feather patch:
> > >
> > >
> >
> http://people.apache.org/~stephenc/maven-logo-contest/maven-owl-4-large.png
> > >
> > > On 19 November 2014 21:19, Dan Rollo  >
> > wrote:
> > >
> > > > Looks great!  Before reading the comet below, I had the same
> “shotgun”
> > > > thought about the white chest patch. Would it help if the white oval
> > > moved
> > > > up, and started at the scarf? (Basically the top of the oval hidden
> > under
> > > > the scarf?)
> > > >
> > > > Understood about the “design by committee”.
> > > >
> > > > Dan
> > > >
> > > >
> > > >
> > > > From: Andreas Gudian >
> > > > Subject: Re: New logo?
> > > > Date: November 19, 2014 at 12:49:59 PM EST
> > > > To: Maven Developers List >
> > > >
> > > >
> > > > I like it. Cute but resolute birdy, and the font looks fresh and
> > modern.
> > > >
> > > > But wait - did someone shoot a hole right through the owl? You can
> even
> > > see
> > > > the shadow behind it. ;-) Maybe the patch in the middle could be a
> > little
> > > > darker, perhaps with a hint/tint of the surrounding colour?
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > 
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > 
> > > >
> > > >
> > >
> >
>
>
> --
> Sent from my phone
>

Re: New logo?

[Chris Graham]

Chiming in late here. Where does "Couché-tard" come from and what does it
mean? How is it relevant?

I read one of Stephen's earlier posts where the colourisation V was
questions. Stephen's response was the wrong one: Would you prefer the A? My
response is: why colourise or stress any of them? I don't get the
significance.


On Thu, Nov 20, 2014 at 8:43 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Stop calling Couché-tard "shotgun owl"!
>
> Does this make it clearer that it's a feather patch:
>
> http://people.apache.org/~stephenc/maven-logo-contest/maven-owl-4-large.png
>
> On 19 November 2014 21:19, Dan Rollo  wrote:
>
> > Looks great!  Before reading the comet below, I had the same “shotgun”
> > thought about the white chest patch. Would it help if the white oval
> moved
> > up, and started at the scarf? (Basically the top of the oval hidden under
> > the scarf?)
> >
> > Understood about the “design by committee”.
> >
> > Dan
> >
> >
> >
> > From: Andreas Gudian 
> > Subject: Re: New logo?
> > Date: November 19, 2014 at 12:49:59 PM EST
> > To: Maven Developers List 
> >
> >
> > I like it. Cute but resolute birdy, and the font looks fresh and modern.
> >
> > But wait - did someone shoot a hole right through the owl? You can even
> see
> > the shadow behind it. ;-) Maybe the patch in the middle could be a little
> > darker, perhaps with a hint/tint of the surrounding colour?
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: https://github.com/apache/maven-scm/pull/17

[Chris Graham]

Hi Benson,

Perfect! Exactly what I was looking for!

Thanks!

-Chris


On Mon, Sep 15, 2014 at 8:16 PM, Benson Margulies 
wrote:

> Chris, See
>
> http://maven.apache.org/developers/conventions/git.html.
>
> I didn't know it existed until yesterday.
>
>
> On Mon, Sep 15, 2014 at 1:26 AM, Chris Graham 
> wrote:
>
> > So, if the scm stuff is in git, my original question still remains
> > unanswered.
> >
> > What are the process steps needed to go through to be able to perform
> > meaningful work in terms of working on the maven-scm modules?
> >
> > Has anyone actually documented what needs doing on the git side of
> things?
> > Creating a patch if was still based in svn, is easy enough, but for git I
> > do not have a clue.
> >
> > -Chris
> >
> > On Thu, Sep 11, 2014 at 8:13 PM, Benson Margulies  >
> > wrote:
> >
> > > A mixture. The release plugin had not moved.
> > > On Sep 10, 2014 11:46 PM, "Chris Graham"  wrote:
> > >
> > > > Sorry, I thought that the plugins, the scm ones in this case, had
> moved
> > > to
> > > > git? Still in SVN? If so, then no issues.
> > > >
> > > > -Chris
> > > >
> > > > On Thu, Sep 11, 2014 at 11:43 AM, Benson Margulies <
> > > bimargul...@gmail.com>
> > > > wrote:
> > > >
> > > > > For plugins, you need mostly to make an account on Codehaus JIRA,
> > then
> > > > you
> > > > > svn checkout as per the information in the plugin's page, and then
> > you
> > > > can
> > > > > attach a patch to a JIRA.
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Sep 10, 2014 at 9:37 PM, Chris Graham <
> chrisgw...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Whilst not strictly related to this thread...
> > > > > >
> > > > > > Is there a document that tells us what we need to do to
> contribute?
> > > > > > How/what repos we need to clone/setup, how to generate a
> patch/pull
> > > > > request
> > > > > > etc?
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > -Chris
> > > > > >
> > > > > > On Thu, Sep 11, 2014 at 7:04 AM, Benson Margulies <
> > > > bimargul...@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Of course; I'm just trying to help you get off the ground; is
> > there
> > > > > > > something else you'd like me to do?
> > > > > > >
> > > > > > > On Wed, Sep 10, 2014 at 4:58 PM, Robert Scholte <
> > > > rfscho...@apache.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I don't want to depend on external systems.
> > > > > > > > you could add me (rfscholte) but that'll only be for
> > reproducing
> > > > the
> > > > > > > issue.
> > > > > > > > and then I need isolate the problem and translate it to a
> > > unittest.
> > > > > > > >
> > > > > > > >
> > > > > > > > Op Wed, 10 Sep 2014 22:53:38 +0200 schreef Benson Margulies <
> > > > > > > > bimargul...@gmail.com>:
> > > > > > > >
> > > > > > > >
> > > > > > > >  Well, you'll need to push a clone where you can write, or
> tell
> > > me
> > > > > your
> > > > > > > >> github ID so I can add you as a collaborator.
> > > > > > > >>
> > > > > > > >> On Wed, Sep 10, 2014 at 4:45 PM, Robert Scholte <
> > > > > rfscho...@apache.org
> > > > > > >
> > > > > > > >> wrote:
> > > > > > > >>
> > > > > > > >>  The first step already fails on my machine.
> > > > > > > >>>
> > > > > > > >>> mvn release:prepare release:perform -B -DpushChanges=false
> > > > > > > >>>
> > > > > > > >>> I'm a bit surprised, because I see:
> > &

Re: https://github.com/apache/maven-scm/pull/17

[Chris Graham]

So, if the scm stuff is in git, my original question still remains
unanswered.

What are the process steps needed to go through to be able to perform
meaningful work in terms of working on the maven-scm modules?

Has anyone actually documented what needs doing on the git side of things?
Creating a patch if was still based in svn, is easy enough, but for git I
do not have a clue.

-Chris

On Thu, Sep 11, 2014 at 8:13 PM, Benson Margulies 
wrote:

> A mixture. The release plugin had not moved.
> On Sep 10, 2014 11:46 PM, "Chris Graham"  wrote:
>
> > Sorry, I thought that the plugins, the scm ones in this case, had moved
> to
> > git? Still in SVN? If so, then no issues.
> >
> > -Chris
> >
> > On Thu, Sep 11, 2014 at 11:43 AM, Benson Margulies <
> bimargul...@gmail.com>
> > wrote:
> >
> > > For plugins, you need mostly to make an account on Codehaus JIRA, then
> > you
> > > svn checkout as per the information in the plugin's page, and then you
> > can
> > > attach a patch to a JIRA.
> > >
> > >
> > >
> > > On Wed, Sep 10, 2014 at 9:37 PM, Chris Graham 
> > > wrote:
> > >
> > > > Whilst not strictly related to this thread...
> > > >
> > > > Is there a document that tells us what we need to do to contribute?
> > > > How/what repos we need to clone/setup, how to generate a patch/pull
> > > request
> > > > etc?
> > > >
> > > > Thanks,
> > > >
> > > > -Chris
> > > >
> > > > On Thu, Sep 11, 2014 at 7:04 AM, Benson Margulies <
> > bimargul...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > Of course; I'm just trying to help you get off the ground; is there
> > > > > something else you'd like me to do?
> > > > >
> > > > > On Wed, Sep 10, 2014 at 4:58 PM, Robert Scholte <
> > rfscho...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > I don't want to depend on external systems.
> > > > > > you could add me (rfscholte) but that'll only be for reproducing
> > the
> > > > > issue.
> > > > > > and then I need isolate the problem and translate it to a
> unittest.
> > > > > >
> > > > > >
> > > > > > Op Wed, 10 Sep 2014 22:53:38 +0200 schreef Benson Margulies <
> > > > > > bimargul...@gmail.com>:
> > > > > >
> > > > > >
> > > > > >  Well, you'll need to push a clone where you can write, or tell
> me
> > > your
> > > > > >> github ID so I can add you as a collaborator.
> > > > > >>
> > > > > >> On Wed, Sep 10, 2014 at 4:45 PM, Robert Scholte <
> > > rfscho...@apache.org
> > > > >
> > > > > >> wrote:
> > > > > >>
> > > > > >>  The first step already fails on my machine.
> > > > > >>>
> > > > > >>> mvn release:prepare release:perform -B -DpushChanges=false
> > > > > >>>
> > > > > >>> I'm a bit surprised, because I see:
> > > > > >>> [INFO] Executing: cmd.exe /X /C "git push g...@github.com:
> > > > bimargulies/
> > > > > >>> pom-file-name-tc.git
> > > > > >>> refs/heads/master:refs/heads/master"
> > > > > >>>
> > > > > >>> Actual failure:
> > > > > >>> [ERROR] Failed to execute goal org.apache.maven.plugins:
> > > > > >>> maven-release-plugin:2.5:prepare (default-cli) on project
> > > > > >>> pom-file-name-tc: Unable to commit files
> > > > > >>> [ERROR] Provider message:
> > > > > >>> [ERROR] The git-push command failed.
> > > > > >>> [ERROR] Command output:
> > > > > >>> [ERROR] Warning: Permanently added the RSA host key for IP
> > address
> > > > > >>> '192.30.252.131' to the list of known hosts.
> > > > > >>> [ERROR] Permission denied (publickey).
> > > > > >>> [ERROR] fatal: Could not read from remote repository.
> > > > > >>> [ERROR]
> > > > > >>> [ERROR] Please make sure you have the correct access rights
> > > &g

Re: https://github.com/apache/maven-scm/pull/17

[Chris Graham]

Sorry, I thought that the plugins, the scm ones in this case, had moved to
git? Still in SVN? If so, then no issues.

-Chris

On Thu, Sep 11, 2014 at 11:43 AM, Benson Margulies 
wrote:

> For plugins, you need mostly to make an account on Codehaus JIRA, then you
> svn checkout as per the information in the plugin's page, and then you can
> attach a patch to a JIRA.
>
>
>
> On Wed, Sep 10, 2014 at 9:37 PM, Chris Graham 
> wrote:
>
> > Whilst not strictly related to this thread...
> >
> > Is there a document that tells us what we need to do to contribute?
> > How/what repos we need to clone/setup, how to generate a patch/pull
> request
> > etc?
> >
> > Thanks,
> >
> > -Chris
> >
> > On Thu, Sep 11, 2014 at 7:04 AM, Benson Margulies  >
> > wrote:
> >
> > > Of course; I'm just trying to help you get off the ground; is there
> > > something else you'd like me to do?
> > >
> > > On Wed, Sep 10, 2014 at 4:58 PM, Robert Scholte 
> > > wrote:
> > >
> > > > I don't want to depend on external systems.
> > > > you could add me (rfscholte) but that'll only be for reproducing the
> > > issue.
> > > > and then I need isolate the problem and translate it to a unittest.
> > > >
> > > >
> > > > Op Wed, 10 Sep 2014 22:53:38 +0200 schreef Benson Margulies <
> > > > bimargul...@gmail.com>:
> > > >
> > > >
> > > >  Well, you'll need to push a clone where you can write, or tell me
> your
> > > >> github ID so I can add you as a collaborator.
> > > >>
> > > >> On Wed, Sep 10, 2014 at 4:45 PM, Robert Scholte <
> rfscho...@apache.org
> > >
> > > >> wrote:
> > > >>
> > > >>  The first step already fails on my machine.
> > > >>>
> > > >>> mvn release:prepare release:perform -B -DpushChanges=false
> > > >>>
> > > >>> I'm a bit surprised, because I see:
> > > >>> [INFO] Executing: cmd.exe /X /C "git push g...@github.com:
> > bimargulies/
> > > >>> pom-file-name-tc.git
> > > >>> refs/heads/master:refs/heads/master"
> > > >>>
> > > >>> Actual failure:
> > > >>> [ERROR] Failed to execute goal org.apache.maven.plugins:
> > > >>> maven-release-plugin:2.5:prepare (default-cli) on project
> > > >>> pom-file-name-tc: Unable to commit files
> > > >>> [ERROR] Provider message:
> > > >>> [ERROR] The git-push command failed.
> > > >>> [ERROR] Command output:
> > > >>> [ERROR] Warning: Permanently added the RSA host key for IP address
> > > >>> '192.30.252.131' to the list of known hosts.
> > > >>> [ERROR] Permission denied (publickey).
> > > >>> [ERROR] fatal: Could not read from remote repository.
> > > >>> [ERROR]
> > > >>> [ERROR] Please make sure you have the correct access rights
> > > >>> [ERROR] and the repository exists.
> > > >>>
> > > >>> As said: I want to create a *unittest*
> > > >>> If I'm correct, the status-call has the wrong arguments. So what
> > should
> > > >>> it
> > > >>> look like? What's the result of this (so I can mock the consumer)
> and
> > > >>> what
> > > >>> should the next call be?
> > > >>>
> > > >>> Robert
> > > >>>
> > > >>> Op Wed, 10 Sep 2014 21:17:10 +0200 schreef Benson Margulies <
> > > >>> bimargul...@gmail.com>:
> > > >>>
> > > >>>
> > > >>>  Step 1: in the top level dir of the example, run mvn --batch-mode
> > > >>>
> > > >>>> release:prepare release:perform. All will be well. A repo will
> > > populate
> > > >>>> in
> > > >>>> /tmp.
> > > >>>>
> > > >>>> Step 2: modify pom in 'second' directory to use the just-release
> > > parent
> > > >>>> pom, commit, push.
> > > >>>>
> > > >>>> Step 3: mvn release:prepare in second directory.
> > > >>>>
> > > >>>> No errors, but the pom.xml will be sitting ther

Re: https://github.com/apache/maven-scm/pull/17

[Chris Graham]

Whilst not strictly related to this thread...

Is there a document that tells us what we need to do to contribute?
How/what repos we need to clone/setup, how to generate a patch/pull request
etc?

Thanks,

-Chris

On Thu, Sep 11, 2014 at 7:04 AM, Benson Margulies 
wrote:

> Of course; I'm just trying to help you get off the ground; is there
> something else you'd like me to do?
>
> On Wed, Sep 10, 2014 at 4:58 PM, Robert Scholte 
> wrote:
>
> > I don't want to depend on external systems.
> > you could add me (rfscholte) but that'll only be for reproducing the
> issue.
> > and then I need isolate the problem and translate it to a unittest.
> >
> >
> > Op Wed, 10 Sep 2014 22:53:38 +0200 schreef Benson Margulies <
> > bimargul...@gmail.com>:
> >
> >
> >  Well, you'll need to push a clone where you can write, or tell me your
> >> github ID so I can add you as a collaborator.
> >>
> >> On Wed, Sep 10, 2014 at 4:45 PM, Robert Scholte 
> >> wrote:
> >>
> >>  The first step already fails on my machine.
> >>>
> >>> mvn release:prepare release:perform -B -DpushChanges=false
> >>>
> >>> I'm a bit surprised, because I see:
> >>> [INFO] Executing: cmd.exe /X /C "git push g...@github.com:bimargulies/
> >>> pom-file-name-tc.git
> >>> refs/heads/master:refs/heads/master"
> >>>
> >>> Actual failure:
> >>> [ERROR] Failed to execute goal org.apache.maven.plugins:
> >>> maven-release-plugin:2.5:prepare (default-cli) on project
> >>> pom-file-name-tc: Unable to commit files
> >>> [ERROR] Provider message:
> >>> [ERROR] The git-push command failed.
> >>> [ERROR] Command output:
> >>> [ERROR] Warning: Permanently added the RSA host key for IP address
> >>> '192.30.252.131' to the list of known hosts.
> >>> [ERROR] Permission denied (publickey).
> >>> [ERROR] fatal: Could not read from remote repository.
> >>> [ERROR]
> >>> [ERROR] Please make sure you have the correct access rights
> >>> [ERROR] and the repository exists.
> >>>
> >>> As said: I want to create a *unittest*
> >>> If I'm correct, the status-call has the wrong arguments. So what should
> >>> it
> >>> look like? What's the result of this (so I can mock the consumer) and
> >>> what
> >>> should the next call be?
> >>>
> >>> Robert
> >>>
> >>> Op Wed, 10 Sep 2014 21:17:10 +0200 schreef Benson Margulies <
> >>> bimargul...@gmail.com>:
> >>>
> >>>
> >>>  Step 1: in the top level dir of the example, run mvn --batch-mode
> >>>
>  release:prepare release:perform. All will be well. A repo will
> populate
>  in
>  /tmp.
> 
>  Step 2: modify pom in 'second' directory to use the just-release
> parent
>  pom, commit, push.
> 
>  Step 3: mvn release:prepare in second directory.
> 
>  No errors, but the pom.xml will be sitting there modified, and there
>  will
>  be a tag pointing to the wrong place.
> 
> 
> 
>  On Wed, Sep 10, 2014 at 3:10 PM, Robert Scholte  >
>  wrote:
> 
>   that's just the beginning...
> 
> > so: how did you execute it? what did you get? what would you expect?
> >
> > Op Wed, 10 Sep 2014 20:54:49 +0200 schreef Benson Margulies <
> > bimargul...@gmail.com>:
> >
> >
> >  Aha, I have one for you. https://github.com/
> > bimargulies/pom-file-name-tc.
> >
> >  I
> >> attached it to a dup JIRA which I closed, or you can take it as you
> >> see
> >> it.
> >> You may in general find MRELEASE-887 helpful in this respect.
> >>
> >> On Wed, Sep 10, 2014 at 2:53 PM, Robert Scholte <
> rfscho...@apache.org
> >> >
> >> wrote:
> >>
> >>  Hi,
> >>
> >>
> >>> IIRC I didn't have enough info to make a unittest, i.e. reproduce
> >>> what
> >>> they get right now and what they would expect to be able to fix it.
> >>> That would take me too much time to find out, so I left this one
> open
> >>> for
> >>> now.
> >>>
> >>> thanks,
> >>> Robert
> >>>
> >>> Op Wed, 10 Sep 2014 20:23:07 +0200 schreef Benson Margulies <
> >>> bimargul...@gmail.com>:
> >>>
> >>>
> >>>  Yes, the remarks which dribbled off pointed to adapting the fix
> back
> >>> into
> >>>
> >>>  the m-r-p.
> >>>
> 
> 
>  On Wed, Sep 10, 2014 at 2:21 PM, Karl Heinz Marbaise <
>  khmarba...@gmx.de
>  >
>  wrote:
> 
>   Hi Benson,
> 
> 
>   > Is anyone working on a fix to MRELEASE-875?
> >
> >
> >
> >   Based on JIRA it is assigned to Dominik Bartholdi which
> requested
> >
> >>
> >>  reviews
> >>
> > from others on Github...
> >
> > BTW: Not working on that...
> >
> > Kind regards
> > Karl-Heinz Marbaise
> >
> >
> >
> >
> >
> >
> > 
> > -
> > To unsu

Re: [jira] (SCM-775) Request for new optional parameter RTC (workItem) with release:prepare to associate workitem with changesets got created during build process

[Chris Graham]

Ideally yes, it would be wonderful to be able to create a WI as a part if the 
release.

The problem Jazz/RTC at least is that there is no command line tool to 
manipulate WI's. There is a feature request to do so, but it has not been 
started.

That issue aside, there is also the case where the WI needs to be created 
beforehand. This is also the easiest case to solve.

I'm still very interested to hear from those who have worked with similar 
systems to see how they do/want to do it.

-Chris

Sent from my iPhone

On 11/09/2014, at 2:05 AM, David Jencks  wrote:

> Sorry for the reply on list, my codehaus jira credentials seem to have gotten 
> messed up….
> 
> I would expect the best normal workflow would be to have the release plugin 
> create the work item, then attach the change sets to it.  I have some 
> evidence that it is possible for external programs to do stuff like this, but 
> I have no idea how.
> 
> david jencks
> 
> On Sep 10, 2014, at 8:51 AM, "AShit Shah (JIRA)"  wrote:
> 
>> 
>>   [ 
>> https://jira.codehaus.org/browse/SCM-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=352607#comment-352607
>>  ] 
>> 
>> AShit Shah commented on SCM-775:
>> 
>> 
>> Both options are fine. 
>> 
>> I think ANT have it via build.xml. I personally would prefer to have it via 
>> a -D option at command line and not hard-coded in pom.xml. 
>> 
>> I was thinking of creating one release build WI for every agile sprint. Not 
>> sue if this is right approach though.
>> 
>>> Request for new optional parameter RTC (workItem) with release:prepare to 
>>> associate workitem with changesets got created during build process
>>> -
>>> 
>>>   Key: SCM-775
>>>   URL: https://jira.codehaus.org/browse/SCM-775
>>>   Project: Maven SCM
>>>Issue Type: Improvement
>>>Components: maven-scm-provider-jazz
>>>  Affects Versions: 1.9.1
>>>  Reporter: AShit Shah
>>> 
>>> Maven {{release:prepare}} command is failing with below error while 
>>> delivering updated pom.xml to the stream due to Preconditions configured in 
>>> RTC to have comments and associated work item with every delivery. 
>>> [ERROR] Name: Deliver
>>> [ERROR] Participant Reports:
>>> [ERROR] Name: Require Work items and Comments
>>> [ERROR] A work item must be associated with the change set.`
>>> [ERROR] At least one of the associated work items must specify that the 
>>> work is planned for the current iteration.
>>> [ERROR] At least one of the associated work items must be assigned to you.
>>> [ERROR] Problem running 'deliver':
>>> [ERROR] 'Deliver' failed. Preconditions have not been met: A work item must 
>>> be associated with the change set.
>>> [ERROR] -> [Help 1]
>>> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
>>> goal org.apache.maven.plugins:maven-release-plugin:2.5:prepare 
>>> (default-cli) on project junit-ext: Unable to commit files
>>> Provider message:
>>> Error code for Jazz SCM deliver command - 17
>>> I can not find any optional parameters on 
>>> http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html
>>>  for release:prepare command which I can use and pass the RTC workitem 
>>> number on command line.
>>> Suggestion:
>>> It will be great if you can provide optional parameters like "workItem" 
>>> which I can use and pass RTC workitem number with release:prepare at 
>>> command line.
>>> Example: mvn -PmyProfile release:prepare -DworkItem=123456
>>> So build process should associate change sets created by release:prepare 
>>> with work item 123456 and deliver change sets to the stream.
>>> As of now I have to use "-DpushChanges=false" parameter to block delivery 
>>> process and I have to manually find the change sets, associate them with 
>>> work item and deliver them before I run release:perform.
>>> Thanks.
>> 
>> 
>> 
>> --
>> This message was sent by Atlassian JIRA
>> (v6.1.6#6162)
> 
> 
> -
> 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: SCM Providers

[Chris Graham]

Hi Robert!

>From a thread a long time ago! This issue has popped up again.

https://jira.codehaus.org/browse/SCM-775

Did you/How did you ever end up solving the issue for TFS?

You're right, a general solution would be preferable.

I think the workflow around the (re)use of a Work Item would be determined
by the client, and I'd rather not force their hand on that one.

-Chris


On Thu, Jul 25, 2013 at 4:27 AM, Robert Scholte 
wrote:

> Hi,
>
> Recently I had a look at Microsoft Team Foundation Server and faced the
> same kind of issue.
> I'm not sure if you could/should reuse a WorkItem. For the
> maven-release-plugin this could very well be acceptable, but for commits in
> general? I don't think so.
> If it is static, then you can make it part of the SCM-URL
> If it is a system-wide setting, then create a specific scm-settings.xml.
>
> This latter is not very well documented, or it is hard to find. In the
> past I've written a setup-maven-plugin[1], with which you could create such
> files and which has a link to the original documentation.
>
> If the workitem is variable, then the -D option is probably the best.
>
> Would be nice if we could think of a general solution.
>
>
> Robert
>
> [1] http://mojo.codehaus.org/setup/setup-maven-plugin/plugin-info.html
>
> Op Wed, 24 Jul 2013 01:35:43 +0200 schreef Chris Graham <
> chrisgw...@gmail.com>:
>
>
>  Hey All.
>>
>> In the RTC/Jazz forum, a request came up for the ability to associate a
>> Work Item with the commits that the SCM plugin does.
>>
>> On the Jazz side, I think that I've worked things out.
>>
>> However, I am unsure as to how to best do this on the maven and scm
>> provider side.
>>
>> The generic question boils down to:
>>
>> How can we supply a scm specific parameter to a specific scm provider?
>>
>> One that is not applicable to all providers.
>>
>> I really do not want to add a -D option. :-)
>>
>> Thoughts/comments/suggestions?
>>
>> -Chris
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Trying to port Neo4j on AIX

[Chris Graham]

And the failing error is?
Should this not be posted on the users list?

-Chris


On Thu, Aug 28, 2014 at 1:36 AM, Siah Lyimo  wrote:

>
>
>
> Hi,
> I'm  working on porting Neo4j on AIX and I was wondering if there is anyone
> who has previously made an attempt to port to AIX.
> I'm currently having the following ERRORS while running "mvn clean install"
>
> Tests in error:
>   DumpProcessInformationTest.shouldDumpProcessInformation:60 » IO Cannot
> run pro...
>
> Tests run: 2087, Failures: 10, Errors: 1, Skipped: 25
>
> [INFO]
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Neo4j .. SUCCESS
> [  2.391 s]
> [INFO] Licensing configuration  SUCCESS
> [  1.814 s]
> [INFO] Neo4j - Primitive Collections .. SUCCESS
> [  9.302 s]
> [INFO] Neo4j - IO . SUCCESS
> [ 18.431 s]
> [INFO] Neo4j - Graph Database Kernel .. FAILURE [05:48
> min]
> [INFO] Neo4j - JMX support  SKIPPED
> [INFO] Neo4j - Usage Data Collection .. SKIPPED
> [INFO] Neo4j - Monitor Logging  SKIPPED
> [INFO] Neo4j - Graphviz generation  SKIPPED
> [INFO] Neo4j - Lucene Index ... SKIPPED
> [INFO] Neo4j - Graph Algorithms ... SKIPPED
> [INFO] Neo4j - Graph Matching . SKIPPED
> [INFO] Neo4j Community Cypher Build ... SKIPPED
> [INFO] Neo4j - Cypher Commons . SKIPPED
> [INFO] Neo4j - Cypher Compiler 2.2  SKIPPED
> [INFO] Neo4j - Cypher . SKIPPED
> [INFO] Neo4j - Consistency Checker  SKIPPED
> [INFO] Neo4j Community  SKIPPED
> [INFO] Neo4j GraphGist  SKIPPED
> [INFO] Neo4j - Cypher Documentation ... SKIPPED
> [INFO] Neo4j Cypher Reference Card Tests .. SKIPPED
> [INFO] Neo4j Community  SKIPPED
> [INFO] Neo4j - Generic shell .. SKIPPED
> [INFO] Neo4j Examples . SKIPPED
> [INFO] Neo4j Server API ... SKIPPED
> [INFO] Neo4j Browser .. SKIPPED
> [INFO] Neo4j Server ... SKIPPED
> [INFO] Neo4j - Server Plugin Tests  SKIPPED
> [INFO] Neo4j Server Examples .. SKIPPED
> [INFO] Neo4j - UDC Integration  SKIPPED
> [INFO] Neo4j Community Build .. SKIPPED
> [INFO] Neo4j - Graph DB Monitoring and Management tools ... SKIPPED
> [INFO] Neo4j Advanced . SKIPPED
> [INFO] Neo4j Advanced Server .. SKIPPED
> [INFO] Neo4j Advanced Build ... SKIPPED
> [INFO] Neo4j - Communication Package .. SKIPPED
> [INFO] Neo4j - Clustering Infrastructure .. SKIPPED
> [INFO] Neo4j - Backup Tool  SKIPPED
> [INFO] Neo4j - High Availability .. SKIPPED
> [INFO] Neo4j Enterprise ... SKIPPED
> [INFO] Neo4j Enterprise Server  SKIPPED
> [INFO] Neo4j - Enterprise Performance Tests ... SKIPPED
> [INFO] Neo4j Enterprise Build . SKIPPED
> [INFO] Neo4j Integration Tests  SKIPPED
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time: 06:24 min
> [INFO] Finished at: 2014-08-27T10:03:41-05:00
> [INFO] Final Memory: 75M/253M
> [INFO]
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test (default-test) on
> project neo4j-kernel: There are test failures.
> [ERROR]
> [ERROR] Please refer
> to /home/neo4j/community/kernel/target/surefire-reports for the individual
> test results.
>
> Thank you in advance.
>
> Regards,
>
> Siah Lyimo.
> Software Engineering intern

Re: [RFC] [MENFORCER-174]

[Chris Graham]

Limit or Restrict...

Sent from my iPhone

On 30/06/2014, at 4:08 PM, Karl Heinz Marbaise  wrote:

> Hi,
> 
> according to comments about the naming of the rule (BanDistributionManagement 
> my original name) and the suggestions made by Robert Scholte which of course 
> are true in particular about the confusions about the intention of the rule.
> 
> I would like to know if someone of the devs has a good/better idea...
> 
> My idea is: FilterDistributionManagement
> 
> The idea of the rule is to limit the usage of distributionManagement in 
> particular areas of pom may be only within a company pom etc.
> 
> What about LimitDistributionManagementUsage
> 
> Many thanks in advance...
> 
> Kind regards
> Karl-Heinz Marbaise
> 
> -
> 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: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Chris Graham]

Sent from my iPhone

On 11/04/2014, at 9:23 AM, Barrie Treloar  wrote:

> On 10 April 2014 23:37, Lennart Jörelid  wrote:
> 
>> So ... the consequence of your approach would be that POMs throughout a
>> maven reactor would have to repeat a dependency declaration if the classes
>> in your maven project "directly" import a type. This - to me - seems not
>> only complex to resolve in a big reactor, but quite user-unfriendly as
>> well. An example shows this, I think:
>> 
> 
> This is the *recommended* best practice.
> 
> If you use something directly, then you should be explicit about that
> dependency.

If I've followed this thread and fully understood it, the proposal is to force 
the declaration of a dependency in the current Pom, even if they are declared 
as dependencies of your declared dependency, ie transitive dependencies.

Does this not effectively disable the use of transitive dependencies?

I find transitive dependencies one of the most useful, powerful features of 
Maven. 

Without them, it takes me back to the (horrid) Ant days of manually having walk 
the dependency tree.

And what of consolidation/library poms, where one Pom lists 100's of other jars 
needed? The WebSphere Process Server one (172 jars!) comes to mind.

In short, if I've followed and understood this correctly, and I may not have 
(holiday time for me), it sounds a very bad idea Igon.

-Chris

> 
> http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.htmlwill
> report failures for you so you can check.

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

SCM Web URL?

[Chris Graham]

Hi All.

In looking at:

http://maven.apache.org/scm/maven-scm-plugin/source-repository.html

I can wee the Web Access link as:

https://git-wip-us.apache.org/repos/asf?p=maven-scm.git/maven-scm-plugin

but it returns a 404!

What is it meant to be?

-Chris

Re: MRELEASE-431

[Chris Graham]

I've been using the 4 digit versions with the release plugin for the last 6
years or so.
I've never used ranges, as I either thought there was a problem with them
and the release plugin.
So if 1.0.0.10 comes before 1.0.0.9, wouldn't 1.0.10 therefor come before
1.0.9?

-Chris


On Sun, Mar 16, 2014 at 8:55 PM, Robert Scholte wrote:

> Hi Chris,
>
> the input is a String, so it's possible to support as many digits as you
> can.
> However, an ArtifactVersion [1] doesn't support that much digits, so I'll
> lock it to 3 to keep the current Maven versioning style. When working with
> ranges 1.0.0.10 comes before 1.0.0.9 because the part after the second dot
> can't be handled as an Integer, so it is handled as a String. For that
> reason the Maven Release plugin shouldn't be able to generate such
> versions. If you are aware of this and never use ranges, you are safe (but
> not your consumers ;) )
>
> Robert
>
> [1] http://maven.apache.org/ref/3.2.1/maven-artifact/apidocs/
> org/apache/maven/artifact/versioning/ArtifactVersion.html
>
> Op Sun, 16 Mar 2014 05:30:12 +0100 schreef Chris Graham <
> chrisgw...@gmail.com>:
>
>
>  Hi Robert.
>>
>> Just a request, can you please test to 4 (that I always use) and 5 digits,
>> that sometimes I have to use?
>>
>> Ie
>> 1.0.0.1-SNAPSHOT
>> and
>> 1.0.0.1.1-SNAPSHOT
>>
>> If you can, it might save me quite a bit of work later on. The release
>> plugin copes with 4 digits, but not 5 (from what I can see in the code).
>>
>> Ta.
>>
>> -Chris
>>
>>
>>
>> On Fri, Mar 14, 2014 at 5:19 AM, Robert Scholte > >wrote:
>>
>>  To say it in your own words: IMHO I think you're wrong here ;)
>>>
>>> Version policy is about calculating the next version based on an input
>>> version.
>>> These are valid examples:
>>> default policy:
>>> getReleaseVersion("1-SNAPSHOT") = 1
>>> getReleaseVersion("1.0-SNAPSHOT") = 1.0
>>> getReleaseVersion("1.0.0-SNAPSHOT") = 1.0.0
>>> getDevelopmentVersion("1") = 2-SNAPSHOT
>>> getDevelopmentVersion("1.0") = 1.1-SNAPSHOT
>>> getDevelopmentVersion("1.0.0") = 1.0.1-SNAPSHOT
>>>
>>> odd-even
>>> getReleaseVersion("1.0-SNAPSHOT") = 1.1
>>> getDevelopmentVersion("1.1") = 1.2-SNAPSHOT
>>>
>>> the metadata gives the following opportunity:
>>> suppose you're on 3.2-SNAPSHOT but want to release a bugfix. In that case
>>> you'd like to return to the latest SNAPSHOT. So instead of 3.1.4 ->
>>> 3.1.5-SNAPSHOT it'll be 3.1.4 -> 3.2-SNAPSHOT
>>>
>>> I think it's weird to depend the policy on the GAV. Just choose a proper
>>> policy for your project.
>>>
>>> I also think that the ArtifactResolver is not required here.
>>> It's like instead of passing a string-based version, you'd like to pass
>>> an
>>> artifact and extract it's version.
>>> My idea is the other way around: extract the version from the artifact
>>> first and pass that to the policy.
>>> I would expect it to be the version in the pom.xml. If you want to check
>>> it, use an enforcer rule or something like that.
>>>
>>> We should try to keep the task of this class as simple as possible.
>>>
>>> Robert
>>>
>>> Op Thu, 13 Mar 2014 13:55:43 +0100 schreef Simone Tripodi <
>>> simonetrip...@apache.org>:
>>>
>>>
>>>  Hi again Robert,
>>>
>>>>
>>>> sorry for bugging - I hope I don't :P - but I notice Metadata also has
>>>> a very limited subset of informations about the ongoing released
>>>> artifact.
>>>> IMHO informations such us packaging and classifier should be part of
>>>> that data set - maybe I am wrong and work around that?
>>>>
>>>> TIA, All the best!
>>>> -Simo
>>>>
>>>> http://people.apache.org/~simonetripodi/
>>>> http://twitter.com/simonetripodi
>>>>
>>>>
>>>> On Wed, Mar 12, 2014 at 7:08 PM, Robert Scholte 
>>>> wrote:
>>>>
>>>>  Hi Simone,
>>>>>
>>>>> for that reason I've added the Metadata, from which you can get the
>>>>> latest
>>>>> released artifact.
>>>>> I really hope you don't need the ArtifactResolver.
>>>>>
>

Re: MRELEASE-431

[Chris Graham]

Is that going to deal with versions such as 2.6-beta-9? As currently exist?

-Chris


On Fri, Mar 14, 2014 at 8:25 PM, Baptiste Mathus  wrote:

> 2014-03-13 19:19 GMT+01:00 Robert Scholte :
>
> > To say it in your own words: IMHO I think you're wrong here ;)
> >
> > Version policy is about calculating the next version based on an input
> > version.
> > These are valid examples:
> > default policy:
> > getReleaseVersion("1-SNAPSHOT") = 1
> > getReleaseVersion("1.0-SNAPSHOT") = 1.0
> > getReleaseVersion("1.0.0-SNAPSHOT") = 1.0.0
> > getDevelopmentVersion("1") = 2-SNAPSHOT
> > getDevelopmentVersion("1.0") = 1.1-SNAPSHOT
> > getDevelopmentVersion("1.0.0") = 1.0.1-SNAPSHOT
> >
> > odd-even
> > getReleaseVersion("1.0-SNAPSHOT") = 1.1
> > getDevelopmentVersion("1.1") = 1.2-SNAPSHOT
> >
> > the metadata gives the following opportunity:
> > suppose you're on 3.2-SNAPSHOT but want to release a bugfix. In that case
> > you'd like to return to the latest SNAPSHOT. So instead of 3.1.4 ->
> > 3.1.5-SNAPSHOT it'll be 3.1.4 -> 3.2-SNAPSHOT
> >
> > I think it's weird to depend the policy on the GAV. Just choose a proper
> > policy for your project.
> >
>
> FWIW, I'm also interested by this feature to further standardize our
> release process. And we'd ideally need at least the artifactId to be able
> to calculate the next developmentVersion. To make it short, the suffix of
> our artifactIds describe if it's an internal implementation project, or if
> it's an globally visible interface.
>
> In the second case, since this is a publicly published/used, the versioning
> is not the same and kind of more agressively checked (which seems similar
> to what Simone is describing in their bytecode analysis approach).
>
> HTH
>
> -- Baptiste
>

Re: MRELEASE-431

[Chris Graham]

Hi Robert.

Just a request, can you please test to 4 (that I always use) and 5 digits,
that sometimes I have to use?

Ie
1.0.0.1-SNAPSHOT
and
1.0.0.1.1-SNAPSHOT

If you can, it might save me quite a bit of work later on. The release
plugin copes with 4 digits, but not 5 (from what I can see in the code).

Ta.

-Chris



On Fri, Mar 14, 2014 at 5:19 AM, Robert Scholte wrote:

> To say it in your own words: IMHO I think you're wrong here ;)
>
> Version policy is about calculating the next version based on an input
> version.
> These are valid examples:
> default policy:
> getReleaseVersion("1-SNAPSHOT") = 1
> getReleaseVersion("1.0-SNAPSHOT") = 1.0
> getReleaseVersion("1.0.0-SNAPSHOT") = 1.0.0
> getDevelopmentVersion("1") = 2-SNAPSHOT
> getDevelopmentVersion("1.0") = 1.1-SNAPSHOT
> getDevelopmentVersion("1.0.0") = 1.0.1-SNAPSHOT
>
> odd-even
> getReleaseVersion("1.0-SNAPSHOT") = 1.1
> getDevelopmentVersion("1.1") = 1.2-SNAPSHOT
>
> the metadata gives the following opportunity:
> suppose you're on 3.2-SNAPSHOT but want to release a bugfix. In that case
> you'd like to return to the latest SNAPSHOT. So instead of 3.1.4 ->
> 3.1.5-SNAPSHOT it'll be 3.1.4 -> 3.2-SNAPSHOT
>
> I think it's weird to depend the policy on the GAV. Just choose a proper
> policy for your project.
>
> I also think that the ArtifactResolver is not required here.
> It's like instead of passing a string-based version, you'd like to pass an
> artifact and extract it's version.
> My idea is the other way around: extract the version from the artifact
> first and pass that to the policy.
> I would expect it to be the version in the pom.xml. If you want to check
> it, use an enforcer rule or something like that.
>
> We should try to keep the task of this class as simple as possible.
>
> Robert
>
> Op Thu, 13 Mar 2014 13:55:43 +0100 schreef Simone Tripodi <
> simonetrip...@apache.org>:
>
>
>  Hi again Robert,
>>
>> sorry for bugging - I hope I don't :P - but I notice Metadata also has
>> a very limited subset of informations about the ongoing released
>> artifact.
>> IMHO informations such us packaging and classifier should be part of
>> that data set - maybe I am wrong and work around that?
>>
>> TIA, All the best!
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://twitter.com/simonetripodi
>>
>>
>> On Wed, Mar 12, 2014 at 7:08 PM, Robert Scholte 
>> wrote:
>>
>>> Hi Simone,
>>>
>>> for that reason I've added the Metadata, from which you can get the
>>> latest
>>> released artifact.
>>> I really hope you don't need the ArtifactResolver.
>>>
>>> Robert
>>>
>>> Op Wed, 12 Mar 2014 13:30:12 +0100 schreef Simone Tripodi
>>> :
>>>
>>>
>>>  Hi again Robert,

 in one of my VersionPolicy implementations, I need to resolve the
 latest release artifact - then I have a tool to compare the bytecodes
 and automatically understand which is the release number.

 Question is: while I need an ArtifactResolver, I also need
 ArtifactRepository for local/remotes that, inside a MOJO, would be get
 via the code below... what are the related Plexus annotations, in
 order to obtain the same components?

 TIA, all the best!
 -Simo

 @Parameter(required = true, defaultValue = "${localRepository}",
 readonly = true)
 private ArtifactRepository localRepository;

 @Parameter(required = true, defaultValue =
 "${project.remoteArtifactRepositories}", readonly = true)
 private List remoteRepositories;
 http://people.apache.org/~simonetripodi/
 http://twitter.com/simonetripodi


 On Mon, Mar 10, 2014 at 7:09 PM, Robert Scholte 
 wrote:

>
> Hi Simone,
>
> I still have to find a solution for the VersionParseException which can
> be
> thrown with the current implementation of DefaultVersionInfo. I
> probably
> have to add it to both methods of VersionPolicy
>
> Your custom implementation will look something like:
>
> @Component( role = VersionPolicy.class, hint = "tripodi" )
> public class TripodiVersionPolicy implements VersionPolicy {
>  // your stuff
> }
>
> The plugin will get parameters like projectVersionPolicyId and/or
> dependencyVersionPolicyId.
> At least, that's my idea right now to split it up per type. This way
> implementations can stay as clean as possible.
>
> Robert
>
> Op Mon, 10 Mar 2014 14:17:43 +0100 schreef Simone Tripodi
> :
>
>
>  Hi again Robert,
>>
>> new APIs look reasonable and easily extensible to me, thanks for
>> putting
>> effort on that!
>> I maybe missed something but I didn't notice how they are integrated
>> in
>> the
>> core module...
>> TIA all the best!
>> -Simo
>>
>>
>> http://people.apache.org/~simonetripodi/
>> http://twitter.com/simonetripodi
>>
>>
>> On Sat, Mar 8, 2014 at 3:17 PM, Robert Scholte 
>> wrote:
>>
>

Re: Developing Maven Archetype

[Chris Graham]

Generate the archetype from your working source.

Sent from my iPhone

On 10/03/2014, at 8:06 AM, Petar Tahchiev  wrote:

> Hello,
> 
> thanks for your responses. Yes, unforutnately, I do need parameterized Java
> code (package names, classnames, also xml files, etc..). As I said it's
> pretty complicated project.
> I looked at templating-maven-plugin but it seems that filtering the
> standard src/main/java folder is not supported. Also, I may not understand
> the quite your suggestion, but using the templating-maven-plugin will also
> break Eclipse as I will be still having ${packageName} in my sources.
> 
> I'm kind of surprised that no one else has had this problem before. Does
> this mean that the archetypes are only supposed to work with simple
> projects that are not continuously developed?
> 
> 
> 2014-03-09 22:50 GMT+02:00 Baptiste Mathus :
> 
>> Just a quick thought, maybe using some hacky form of a development profile
>> using the templating-maven-plugin to filter those properties could help?
>> 
>> 
>> 2014-03-09 20:47 GMT+01:00 Benson Margulies :
>> 
>>> Are you sure that you absolutely need parameterized Java code? There's
>>> really no good way to work with it. You could instead use the
>>> maven-shade-plugin to customer-ize your results as part of their
>>> build.
>>> 
>>> 
>>> On Sun, Mar 9, 2014 at 3:36 PM, Petar Tahchiev 
>>> wrote:
 Hey guys,
 
 here's an interesting question: how do you develop your maven
>>> archetypes? I
 have a web-project that consists of lots of controllers and jsps, and I
 have been developing this for a long time, and I want to keep
>> developing
 it. I also want to provide this project to my clients as an archetype
>> so
 they can be up-and-running as quickly as possible.
 
 I thought of creating an archetype from my project every time I release
>>> the
 archetype, but that seems really unefficient as I release new versions
>>> very
 often, and also the archetype is quite complicated.
 
 I also thought to create the archetype once, and keep developing it in
 Eclipse, but that's not possible because for instance the package names
 look like this:
 
 package ${packageName};
 
 and of-course Eclipse complains.
 
 So my questions is - if you have a complicated archetype that you keep
 developing over time, how do you develop it? Is there an
>> Eclipse/IntelliJ
 plugin for archetype developing?
 
 --
 Regards, Petar!
 Karlovo, Bulgaria.
 ---
 Public PGP Key at:
 
>>> 
>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>> 
>>> 
>> 
>> 
>> --
>> Baptiste  MATHUS - http://batmat.net
>> Sauvez un arbre,
>> Mangez un castor !
>> 
> 
> 
> 
> -- 
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

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

Re: [VOTE] Maven 2.x is end of life

[Chris Graham]

+1

PS: like your style mark!

-Chris

Sent from my iPhone

On 16/02/2014, at 2:11 PM, "Mark Derricutt"  wrote:

> On 14 Feb 2014, at 4:14, Stephen Connolly wrote:
> 
>> +1: Maven 2.x is end of life, I am not willing to act as release manager
>> for this line of releases
>> 0: I have no opinion
>> -1: Maven 2.x is not end of life, I am willing to act as release manager
>> for this line of releases
> 
> 
> +1
> 
> In the word of Rob Halford and his short lived FIGHT band project:
> 
> o/~ KILL IT KILL IT KILL IT
> o/~ KILL!
> o/~ IT!
> 
> http://www.youtube.com/watch?v=cK1HP5eKEU0
> 
> Mark
> 
> -
> 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: Respinned releases and versions Re: [VOTE] Release Maven 3.2.0

[Chris Graham]

I prefer not to rehash what we all went painstakingly over a few months
back...


On Wed, Feb 12, 2014 at 8:06 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On 12 February 2014 08:35, Arnaud Héritier  wrote:
>
> > Hi,
> >
> >   I'm in favor to not reuse the version. Like many others I'm often lost
> > between intermediate and final versions (but we can see it also as a
> maven
> > dev and advanced users privilege/constraint too - thus applying to very
> few
> > people).
> >
> >  We discussed about it many times and AFAIK we have 2 solutions to
> achieve
> > this :
> >
> >   1/ We just pass some minor versions like Apache Tomcat is doing (
> > http://tomcat.apache.org/tomcat-7.0-doc/changelog.html you may find many
> > "not released" versions). We announce only releases considered stable
> > (let's say 3.2.1 and not 3.2.0), we have distinct tags in our SCM and
> > versions in Jira. Users will have to take care to append all release
> notes
> > of none stable version to know what we changed between two stables
> versions
> > (or we have to do it for them).
> >   2/ We add an extra release number like 3.2.0_1, 3.2.0_2... I think it
> is
> > like Sonatype Nexus team is doing. We have distinct tags in our SCM
> > (3.2.0_1, 3.2.0_2) but we can manually add a 3.2.0 tag to the stable
> > version we publicly announce. In Jira we only have a 3.2.0 version and we
> > just reopen or add issues in it to track the release landing. For users
> > we'll just announce a 3.2.0 but the binary they'll have will be called
> > 3.2.0_2 for example.
> >
> >   In both cases we will throw in the bin unstable releases.
> >
> >   I like both approaches and prefer them compared to our current one.
> >   Between both of them I would prefer the second one (transparent for
> users
> > and not difficult for us).
> >
> >   WDYT ?
> >
>
> I prefer any scheme where we do not reuse a version number *ever*.
>
> We can handle the JIRA problem by just moving the issues fixed in forward
> (or just renaming the version that wasn't released in JIRA)
>
> The version was never released therefore it doesn't exist. The only
> remnants would be the tag in SCM.
>
> If there are any users "confused" then we just tell them the answer "that
> version just didn't meet our release criteria"...
>
> The users will get over it... plugins or core... they will still get over
> it... they don't care what version number we give something once bigger
> numbers have more features and/or less bugs
>
> The only down side I can see is that we would be admitting that we have a
> quality bar... right now, unless you follow the dev list, it could seem
> that we don't do a lot of testing of releases - because you don't see all
> the (take 2) style votes. By skipping version numbers we would be saying
> "look here we do have a quality bar" and users would then be able to
> complain about how low that bar is with respect to their expectations...
>
> Still I would rather that kind of pressure from users and field questions
> like "what happened to 3.2.0?" than respin 3.2.0
>
> That is my EURO 0.02
>
> As always the chair will bow to the decision of the PMC committee!
>
> -Stephen
>
>
> >
> > Note : Even If I'm in favor of this change I really don't want to hold up
> > the current release which such debate/vote thus I think it may be better
> to
> > apply this change only for the next release depending of how many time
> all
> > active developers think they need to finalize the 3.2.0 release and
> launch
> > another vote.
> >
> > Arnaud
> >
> >
> > On Wed, Feb 12, 2014 at 3:05 AM, Mark Derricutt  wrote:
> >
> > > On 12 Feb 2014, at 13:57, Benson Margulies wrote:
> > >
> > > > 3.2.0.1 :-)
> > >
> > > 3.2.0-patchlevel-1-GA.
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
> >
> > --
> > -
> > Arnaud Héritier
> > http://aheritier.net
> > Mail/GTalk: aheritier AT gmail DOT com
> > Twitter/Skype : aheritier
> >
>

Re: Release Instructions: Unified or Simpler Mono-Module (was Re: svn commit: r1549574 - /maven/skins/trunk/maven-skins/pom.xml)

[Chris Graham]

+1
The value is in the process, and that comes from it being simple and
repeatable, minimising 'specials' :)
-Chris


On Sun, Dec 15, 2013 at 2:26 AM, Robert Scholte wrote:

> +1 for a standardized process, even though the results for mono-projects
> stay the same.
>
> Robert
>
> Op Sat, 14 Dec 2013 15:47:51 +0100 schreef Hervé BOUTEMY <
> herve.bout...@free.fr>:
>
>
>  the only change is that you'd have to run "mvn -Preporting site
>> site:stage"
>> even for mono-modules, when actually the "site:stage" part is required
>> only
>> for multi-module
>>
>> the purpose is to have stupid easy unified instructions, without "if
>> multi-
>> module" step: every component has the exact same commands
>>
>> the drawback is that, from a pure technical point of view, "site:stage"
>> goal
>> could be avoided for the 80 mono-components and is absolutely required
>> only
>> for the 20 multi-modules: but once scm-publish plugin will be configured
>> to
>> publish from staging directory instead of direct site directory,
>> "site:stage"
>> will be required even for mono-modules.
>> It costs typing a few letters more (or copy/pasting). Running the goal
>> doesn't
>> take much time (a few seconds). And I suppose nobody cares about site
>> content
>> being duplicated on disk, using twice space.
>>
>> Regards,
>>
>> Hervé
>>
>> Le samedi 14 décembre 2013 15:24:27 Robert Scholte a écrit :
>>
>>> Could you describe in short how the process would look like? As in
>>> staging/performing the release and finalizing it (after enough votes).
>>>
>>> Robert
>>>
>>> Op Sat, 14 Dec 2013 14:19:52 +0100 schreef Hervé BOUTEMY
>>>
>>> :
>>> > before I update documentation and parent poms:
>>> > any objection from any future release manager if we unify site:stage
>>> > requirement?
>>> >
>>> > Regards,
>>> >
>>> > Hervé
>>> >
>>> > Le mardi 10 décembre 2013 23:59:19 Hervé BOUTEMY a écrit :
>>> >> really, here is the link...
>>> >> https://builds.apache.org/view/M-R/view/Maven/job/dist-
>>> tool-plugin/site/d
>>> >> ist -tool-check-source-release.html
>>> >>
>>> >> Le mardi 10 décembre 2013 23:50:26 Hervé BOUTEMY a écrit :
>>> >> > (better with link)
>>> >> > /> Do we have any metrics on how many mono- to multi- module builds
>>> we
>>> >> > have?/ indirectly, yes: dist-tool [1] tells we have 101 releases
>>> >> >
>>> >> >
>>> >> > plugins, shared, skins, poms, reporting and resources are
>>> >>
>>> >> mono-modules:
>>> >> > 44+20+6+2+3+5 = 80
>>> >> >
>>> >> >
>>> >> > other ones are multi-modules: 101-80 = 21 (-3 given we have Maven
>>> 2.0,
>>> >> > 2.2,
>>> >> > 3.0 and 3.1)
>>> >> >
>>> >> >
>>> >> >
>>> >> > so I see 80 mono-module and 18 multi-modules
>>> >> >
>>> >> >
>>> >> > Regards,
>>> >> >
>>> >> >
>>> >> > Hervé
>>> >> >
>>> >> > Le mardi 10 décembre 2013 11:39:13 Barrie Treloar a écrit :
>>> >> > > On 10 December 2013 11:24, Hervé BOUTEMY 
>>> >>
>>> >> wrote:
>>> >> > > > Le mardi 10 décembre 2013 01:05:30 Michael-O a écrit :
>>> >> > > >> Am 2013-12-10 00:58, schrieb Hervé BOUTEMY:
>>> >> ${project.build.directory}/staging/${maven.site.path}>> >>
>>> >> > > >> >> nt
>>> >> > > >> >> en
>>> >> > > >> >> t>
>>> >> > > >> >
>>> >> > > >> > is not really necessary here, since skins are never
>>> >>
>>> >> multi-module,
>>> >>
>>> >> > > >> > then
>>> >> > > >> > no
>>> >> > > >> > need to site:stage
>>> >> > > >> >
>>> >> > > >> > that's not a blocking issue, since it will work: just need to
>>> >>
>>> >> do
>>> >>
>>> >> > > >> > extra
>>> >> > > >> > site:stage step, not usually needed
>>> >> > > >>
>>> >> > > >> I am aware of that. That change was intentional. It conforms to
>>> >>
>>> >> all
>>> >>
>>> >> > > >> other POMs and to the procedure described in the docs. Nothing
>>> >>
>>> >> more,
>>> >>
>>> >> > > >> nothing less.
>>> >> > > >
>>> >> > > > not really what I wanted to express with "if the component has
>>> >> > > > multiple
>>> >> > > > modules, locally stage the site:"
>>> >> > > > but staging in every situation has the advantage that
>>> instructions
>>> >> > > > would
>>> >> > > > not be different for mono-module and multi-module
>>> >> > > >
>>> >> > > > I don't know what you all prefer: simpler instructions for
>>> >>
>>> >> mono-module
>>> >>
>>> >> > > > (but
>>> >> > > > require a little thinking to know in which situation a build is)
>>> >>
>>> >> or
>>> >>
>>> >> > > > uniform
>>> >> > > > instructions (even if it is a little more complex than
>>> absolutely
>>> >> > > > necessary
>>> >> > > > for mono-modules)
>>> >> > > >
>>> >> > > > the ideal situation would be a site:deploy goal that does all
>>> the
>>> >> > > > magic
>>> >> > > > in
>>> >> > > > case of scm: dist management site url
>>> >> > > > anybody interested in trying to do it with me?
>>> >> > >
>>> >> > > You might want to pull this out into a new thread. - Why dont I do
>>> >> > > that...
>>> >> > > I have been following because we had someone new wanting to do RM
>>> >>
>>> >> and
>>> >>
>>> >> > > I was interested in their pain.
>>> >> > 

Re: maven-release-plugin oddity - no git commit under mvn 3.1.1

[Chris Graham]

Hi Mark.
Yes it is, just define them as dependencies of the maven-release-plugin in
your parent (or otherwise) pom.
-Chris


On Mon, Dec 9, 2013 at 3:23 PM, Mark Derricutt  wrote:

> Ok - so this looks to be an issue introduced in Git 1.8.5, from
> https://raw.github.com/git/git/master/Documentation/RelNotes/1.8.5.txt
>
>  * "git status" now omits the prefix to make its output a comment in a
>commit log editor, which is not necessary for human consumption.
>Scripts that parse the output of "git status" are advised to use
>"git status --porcelain" instead, as its format is stable and easier
>to parse.
>
> From looking at the git log of
>
> ./maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/status/GitStatusConsumer.java
> I see that the has been using the newer "git status --porcelain" command
> for some time now, however from walking the dependencies of
> maven-release-plugin, I appear to find 1.7 being resolved ( at least via
> IntellliJ ).
>
> It looks like Olivier Lamy updated the "git status" support in [1] in git
> commit 5c58908896a1b82bc6ee0af005adf0d6ef326395
>
> Up until this week this didn't appear to be a problem, until Git 1.8.5 was
> released and removed the leading # from the status messages
>
> How do we get Maven to start using the newer releases of SCM - is that just
> a matter of declaring a dependency in my parent pom?
>
> Mark
>
>
>
> [1] [SCM-686] Maven SCM failed to parse "git status" output if git messages
> are translated - Submitted by Ralf Thielow.
>
> --
> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
> Porcupine Tree
>
>
> On Mon, Dec 9, 2013 at 3:40 PM, Mark Derricutt  wrote:
>
> > Hey all,
> >
> > Just encountered a strange issue with the maven-release-plugin, when
> doing
> > a release:prepare from my machine using Maven 3.1.1, and
> > maven-release-plugin 2.4.2 I get the following output:
> >
> > [INFO] Checking in modified POMs...
> > [INFO] Executing: /bin/sh -c cd
> > /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation && git
> add
> > -- pom.xml
> > [INFO] Working directory:
> > /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
> > [INFO] Executing: /bin/sh -c cd
> > /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation && git
> > status
> > [INFO] Working directory:
> > /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
> > [INFO] Tagging release with the label com.smxemail.translation-13.2.9...
> > [INFO] Executing: /bin/sh -c cd
> > /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation && git
> tag
> > -F
> >
> /var/folders/bq/jtxn4t511xz7l_t3t4q4c634gn/T/maven-scm-596385603.commit
> > com.smxemail.translation-13.2.9
> > [INFO] Working directory:
> > /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
> > [INFO] Executing: /bin/sh -c cd
> > /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation && git
> > ls-files
> > [INFO] Working directory:
> > /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
> > [INFO] Transforming 'com.smxemail.translation'...
> > [INFO] Not removing release POMs
> > [INFO] Checking in modified POMs...
> > [INFO] Executing: /bin/sh -c cd
> > /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation && git
> add
> > -- pom.xml
> > [INFO] Working directory:
> > /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
> > [INFO] Executing: /bin/sh -c cd
> > /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation && git
> > status
> > [INFO] Working directory:
> > /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
> > [INFO] Release preparation complete.
> > [INFO]
> > 
> > [INFO] BUILD SUCCESS
> >
> > You can see here that there are no "git commit" commands being run, this
> > in turn breaks the build.
> >
> > A coworker who is still using Maven 3.0.4 was able to prepare and release
> > the artefact fine however, so I'm wondering if there's some issue at the
> > SCM layer of maven that's breaking when running under 3.1.1 that isn't an
> > issue when using 3.0.4.
> >
> > Has anyone else seen any behaviour like this?
> >
> > Mark
> >
>

Re: Property namespaces Was: Changing JDK version without specifying maven-compiler-plugin version

[Chris Graham]

On Wed, Nov 27, 2013 at 5:49 PM, Mirko Friedenhagen  wrote:

> Hello Laird,
>
> the only pity with using properties is that they are not namespaced most of
> the time (the maven.compiler.* ones being an exception here), "output" is
> claimed at least by three mojos IIRC. And skipTests is almost a general one
> but you may not easily specify that you do not want to run surefire but
> e.g. invoker tests nonetheless :-)
>
> I would have liked conventions like always "prefix with plugin name".
>
>
+1000 to that!

Re: Do releases _really_ need to be built with Java 1.5?

[Chris Graham]

The client in question is using Oracle's CC&B (Customer Care and Billing)
their package for power companies.

So moving is not a trivial decision, as Oracle have to say if they are
prepared to support the specific combination we have. AIX level, WAS
version, JDK version etc. The joys of commercial contracts...

There are plans to move to CC&B 2.4 on top of WAS 8.5 (8.5.5), but that
will be sometime in the next 24 odd months.

So the main issue is funding to support the migration development issue.
Not a decision NOT to migrate as it where. :-)

-Chris



On Tue, Nov 12, 2013 at 10:26 PM, Lennart Jörelid  wrote:

> Hm..
>
> While WAS 6.1 is still certainly still an IBM-supported version, I can
> certainly feel your JDK version pain there, Chris.
>
> Just out of curiosity - would you claim that the motives for staying on
> such an old application server version would be motivated more by economy
> than technology? Or are there technological reasons why your organisation
> (and, therefore, likely others in the 0.0001% league) cannot move to a
> newer version of the application server supporting a newer JDK standard?
>
> There is always the delicate balance between upgrading minimum (JDK/lib)
> requirements to enable nice/productive features versus staying on an elder
> version for compatibility reasons. Personally, I wouldn't claim Maven to be
> overly progressive in its minimum JDK requirements...
>
>
> 2013/11/12 Chris Graham 
>
> > Um, yes, me! :-)
> >
> > Seriously we are still stuck on Java 1.5/WAS 6.1/COBOL for at least
> > another year. Until we move to java 6 (or 7) depending on what oracle
> will
> > support.
> >
> > -Chris, representing 0.0001% :-)
> >
> >
> > Sent from my iPhone
> >
> > On 12/11/2013, at 4:41 PM, Romain Manni-Bucau 
> > wrote:
> >
> > > Isnt the question: is there still someone needing j5? Almost all apache
> > > projects and others moved to j6 at least
> > > Le 11 nov. 2013 23:53, "John Patrick"  a
> écrit :
> > >
> > >> i guess it's the only way to definitely ensure backwards compatibility
> > >>
> > >> open potential solution would be to use vagrant, I use it to ensure
> > >> developers as using the same base build setup and the files can be
> > source
> > >> controlled
> > >>
> > >>
> > >>
> > >> On 11 November 2013 22:39, Benson Margulies 
> > wrote:
> > >>
> > >>>
> > >>>
> > >>
> >
> http://maven.apache.org/developers/release/maven-project-release-procedure.html
> > >>>
> > >>> says so. I don't know where I'm going to get that environment.
> > >>>
> > >>> -
> > >>> 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
> >
> >
>
>
> --
>
> --
> +==+
> | Bästa hälsningar,
> | [sw. "Best regards"]
> |
> | Lennart Jörelid
> | EAI Architect & Integrator
> |
> | jGuru Europe AB
> | Mölnlycke - Kista
> |
> | Email: l...@jguru.se
> | URL:   www.jguru.se
> | Phone
> | (skype):jgurueurope
> | (intl): +46 708 507 603
> | (domestic): 0708 - 507 603
> +==+
>

Re: Do releases _really_ need to be built with Java 1.5?

[Chris Graham]

Um, yes, me! :-)

Seriously we are still stuck on Java 1.5/WAS 6.1/COBOL for at least another 
year. Until we move to java 6 (or 7) depending on what oracle will support.

-Chris, representing 0.0001% :-)


Sent from my iPhone

On 12/11/2013, at 4:41 PM, Romain Manni-Bucau  wrote:

> Isnt the question: is there still someone needing j5? Almost all apache
> projects and others moved to j6 at least
> Le 11 nov. 2013 23:53, "John Patrick"  a écrit :
> 
>> i guess it's the only way to definitely ensure backwards compatibility
>> 
>> open potential solution would be to use vagrant, I use it to ensure
>> developers as using the same base build setup and the files can be source
>> controlled
>> 
>> 
>> 
>> On 11 November 2013 22:39, Benson Margulies  wrote:
>> 
>>> 
>>> 
>> http://maven.apache.org/developers/release/maven-project-release-procedure.html
>>> 
>>> says so. I don't know where I'm going to get that environment.
>>> 
>>> -
>>> 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: What is the top level of the source tree and what exactly is an Apache distribution?

[Chris Graham]

And an update nightmare.

Which begs the question, is the N/L text should need to be changed, would
they all have to be updated and another release triggered, or just at the
next release cycle?

-Chris


On Mon, Sep 16, 2013 at 8:46 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Let's see what legal concludes... my postulate is that people advocating
> for the files in SCM have not fully considered what that implies and that
> the "PMC must vote on releases so that legal indemnity of committers is in
> place" will remove the suggested requirement to keep NOTICE and LICENSE
> files (which are potentially out of date - and allowed to be so by people
> advocating their presence in SCM - see the use of the phrase "best effort")
> from the table... but if it falls the other way, so be it... we'll just
> have several hundred of these files scattered all over the place!
>
>
> On 16 September 2013 11:25, Chris Graham  wrote:
>
> > My take: Given we vote on a source bundle, and that includes the required
> > files, I think we're good.
> >
> > If it is ruled that this is not the case, do we have to change on what
> and
> > how we vote (we I think you've covered)?
> >
> > -Chris
> >
> > Sent from my iPhone
> >
> > On 16/09/2013, at 7:50 PM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > In an effort to get to a definitive answer for
> > >
> >
> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201309.mbox/%3CCA%2BnPnMwUvmaoOuBJ7dpVj9qAmwVnbfcxTid7UZgc6EdEL7%2BOpg%40mail.gmail.com%3EI
> > > did some searching...
> > >
> > > The ASF Licensing How To includes this helpful simple snippet:
> > >
> > > http://www.apache.org/dev/licensing-howto.html#source-tree-location
> > >
> > > # Location Within the Source Tree
> > >>
> > >
> > >
> > > LICENSE and NOTICE belong at the [top level of the source tree][1].
> They
> > >> may be named LICENSE.txt and NOTICE.txt, but the bare names are
> > preferred.
> > >
> > >
> > >>  [1]:  http://www.apache.org/legal/src-headers.html#notice
> > >
> > >
> > > If we wander over to that link:
> > >
> > > http://www.apache.org/legal/src-headers.html#notice
> > >
> > > # NOTICE file
> > >>
> > >
> > >
> > > 0. Every Apache distribution should include a NOTICE file in the top
> > >> directory, along with the standard LICENSE file.
> > >> 1. The top of each NOTICE file should include the following text,
> > suitably
> > >> modified to reflect the product name and year(s) of distribution of
> the
> > >> current and past versions of the product:
> > >>  Apache [PRODUCT_NAME]
> > >>  Copyright [] The Apache Software Foundation
> > >>  This product includes software developed at
> > >>  The Apache Software Foundation (http://www.apache.org/).
> > >> 2. The remainder of the NOTICE file is to be used for required
> > third-party
> > >> notices.
> > >> 3. The NOTICE file may also include copyright notices moved from
> source
> > >> files submitted to the ASF.
> > >> 4. See also Modifications to NOTICE
> > >
> > >
> > > Now that is mostly OK but it does beg the following questions:
> > >
> > > 1. What exactly is "the top level of the source tree"? Is it the tree
> in
> > > SCM or is it the tree in the .zip or .tar.gz files that end up in the
> > /dist
> > > directory. The text I have seen would seep to imply that the phrase
> > refers
> > > to the top level of the source tree in an Apache distribution... which
> > > brings us to..
> > >
> > > 2. What exactly is "an Apache distribution"? To the best of my
> knowledge
> > > this is just the .zip or .tar.gz files that end up in the /dist
> > directory.
> > > I know that other people have opinions that things like SCM also are
> > Apache
> > > distributions, but it would seem to me that the two links I cited above
> > > would be *very clear* in stating that SCM is viewed as a distribution
> if
> > it
> > > was the official view of the ASF (and perhaps it is... in which case
> > please
> > > fix the website)
> > >
> > > By way of some concrete examples, and because real world examples are
> > much
> > > much better than

Re: What is the top level of the source tree and what exactly is an Apache distribution?

[Chris Graham]

My take: Given we vote on a source bundle, and that includes the required 
files, I think we're good.

If it is ruled that this is not the case, do we have to change on what and how 
we vote (we I think you've covered)?

-Chris

Sent from my iPhone

On 16/09/2013, at 7:50 PM, Stephen Connolly  
wrote:

> In an effort to get to a definitive answer for
> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201309.mbox/%3CCA%2BnPnMwUvmaoOuBJ7dpVj9qAmwVnbfcxTid7UZgc6EdEL7%2BOpg%40mail.gmail.com%3EI
> did some searching...
> 
> The ASF Licensing How To includes this helpful simple snippet:
> 
> http://www.apache.org/dev/licensing-howto.html#source-tree-location
> 
> # Location Within the Source Tree
>> 
> 
> 
> LICENSE and NOTICE belong at the [top level of the source tree][1]. They
>> may be named LICENSE.txt and NOTICE.txt, but the bare names are preferred.
> 
> 
>>  [1]:  http://www.apache.org/legal/src-headers.html#notice
> 
> 
> If we wander over to that link:
> 
> http://www.apache.org/legal/src-headers.html#notice
> 
> # NOTICE file
>> 
> 
> 
> 0. Every Apache distribution should include a NOTICE file in the top
>> directory, along with the standard LICENSE file.
>> 1. The top of each NOTICE file should include the following text, suitably
>> modified to reflect the product name and year(s) of distribution of the
>> current and past versions of the product:
>>  Apache [PRODUCT_NAME]
>>  Copyright [] The Apache Software Foundation
>>  This product includes software developed at
>>  The Apache Software Foundation (http://www.apache.org/).
>> 2. The remainder of the NOTICE file is to be used for required third-party
>> notices.
>> 3. The NOTICE file may also include copyright notices moved from source
>> files submitted to the ASF.
>> 4. See also Modifications to NOTICE
> 
> 
> Now that is mostly OK but it does beg the following questions:
> 
> 1. What exactly is "the top level of the source tree"? Is it the tree in
> SCM or is it the tree in the .zip or .tar.gz files that end up in the /dist
> directory. The text I have seen would seep to imply that the phrase refers
> to the top level of the source tree in an Apache distribution... which
> brings us to..
> 
> 2. What exactly is "an Apache distribution"? To the best of my knowledge
> this is just the .zip or .tar.gz files that end up in the /dist directory.
> I know that other people have opinions that things like SCM also are Apache
> distributions, but it would seem to me that the two links I cited above
> would be *very clear* in stating that SCM is viewed as a distribution if it
> was the official view of the ASF (and perhaps it is... in which case please
> fix the website)
> 
> By way of some concrete examples, and because real world examples are much
> much better than abstract hypotheticals.
> 
> Consider the Apache Maven project. We are a top level project with many
> things that we release. We have Maven Core itself and we have many plugins
> and other shared components that have their own release lifecycles... we
> also have some components in our Subversion repository and others in GIT
> repositories.
> 
> Case 1
> --
> 
> For technical reasons, i.e. given the way GIT works, it is easiest to put
> any group of things that get released as an atomic unit into a single GIT
> repository. Thus we have Maven Core (with the 12 modules that are used to
> build Maven Core) at
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=tree Now as it
> happens the top level of that group of 12 modules is the root of that GIT
> repository and we have LICENSE and NOTICE files there. As part of our
> release process we produce a source distribution of that tree and hence the
> LICENSE and NOTICE files will be at the root of the
> apache-maven-x.y.x-src.tar.gz and apache-maven-x.y.x-src.zip files that end
> up in the /dist directory. So in this case it does not matter whether an
> Apache distribution is only the apache-maven-x.y.x-src.tar.gz files or also
> includes the https://git-wip-us.apache.org/repos/asf?p=maven.git GIT
> repository. In this case we have the files at the root of both source trees.
> 
> Case 2
> --
> 
> Now let us consider a different set of atomically released modules.
> Surefire consists of again 12 modules that all get released at the same
> time. The source tree in SCM is
> https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=tree as
> again that is a separate source repository from our other stuff. Our most
> recent source release of Surefire is
> http://www.apache.org/dist/maven/surefire/surefire-2.16-source-release.zipand
> if we look at that file
> 
> $ unzip -l ~/Downloads/surefire-2.16-source-release.zip */LICENSE */NOTICE
> Archive:  /Users/stephenc/Downloads/surefire-2.16-source-release.zip
>  Length Date   TimeName
>    
>  108  08-11-13 16:57
> surefire-2.16/surefire-api/src/main/appended-resources/META-INF/NOTICE
>11358  08-11-13

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

[Chris Graham]

On Sun, Sep 15, 2013 at 3:24 AM, Jason van Zyl  wrote:

> When a release fails like this it is annoying to have to rev back the
> version of the POM. I'm not sure who flipped the versions in the POM and
> while it's a little more visible to see what you're moving toward I prefer
> the pattern of:
>
> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 --> 3.1-SNAPSHOT
>
> I know this may not be obvious to the casual observer as they may think
> 3.1 is next, but I'm personally fine with that.
>
>
So, what you've done is to change the meaning of SNAPSHOT.

Why would you not stick with the far more clearly understood:

3.1.1-SNAPSHOT -> 3.1.1 -> 3.1.2-SNAPSHOT -> 3.1.2 etc

If the IT's have issues, then there is clearly something wrong with them,
and they should be fixed.

Did the IT's fail in a similar manner for 3.0.x ?

-Chris

Re: Can I create folder Dependency?

[Chris Graham]

I use this, make-maven-files.sh to build a runtime-library.pom file, which
is a consolidation pom of all jars within the folder from which it is run.

#!/bin/bash

# All you need to do is:
# 1. Edit the values below.
# 2. Copy this script into the dir with the jars in it (no nested dirs)
# 3. Run make-maven-files.sh.
# 4. Execute either maven-install.sh and/or maven-deploy.sh that were
generated by make-maven-files.sh
#
# Chris Graham - chrisgw...@gmail.com
#

groupId=com.ibm.ram
version=7.5.1.2
repositoryId=project.repo.id
repositoryURL=http://maven.repo.server/url

#example
# repositoryId=warpspeed.non.freeware
# repositoryURL=
http://archiva.warpspeed.com.au/archiva/repository/warpspeed.non.freeware

echo "" > runtime-library.pom
echo "http://maven.apache.org/POM/4.0.0\"; xmlns:xsi=\"
http://www.w3.org/2001/XMLSchema-instance\"; xsi:schemaLocation=\"
http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd\";>"
>> runtime-library.pom
echo "4.0.0" >> runtime-library.pom
echo "$groupId" >> runtime-library.pom
echo "runtime-library" >> runtime-library.pom
echo "$version" >> runtime-library.pom
echo "pom" >> runtime-library.pom
echo "Library POM for the $groupId v$version
runtime." >> runtime-library.pom
echo "" >> runtime-library.pom

echo "#!/bin/bash" > maven-install.sh
echo "mvn install:install-file -Dfile=runtime-library.pom
-DpomFile=runtime-library.pom" >> maven-install.sh

echo "#!/bin/bash" > maven-deploy.sh
echo "mvn deploy:deploy-file -Dfile=runtime-library.pom
-DpomFile=runtime-library.pom -DrepositoryId=$repositoryId
-Durl=$repositoryURL" >> maven-deploy.sh

find . -name "*.jar" | sort -u | sed "s/^.*\///" | while read jar
do
  artifactId=`echo $jar | sed 's/.jar//'`

  echo "mvn install:install-file -Dfile=$jar -DgroupId=$groupId
-DartifactId=$artifactId -Dversion=$version -DgeneratePom=true
-Dpackaging=jar -DcreateChecksum=true" >> maven-install.sh

  echo "mvn deploy:deploy-file -Dfile=$jar -DgroupId=$groupId
-DartifactId=$artifactId -Dversion=$version -DgeneratePom=true
-Dpackaging=jar -DcreateChecksum=true -DrepositoryId=$repositoryId
-Durl=$repositoryURL" >> maven-deploy.sh

  echo "" >> runtime-library.pom
  echo "$groupId" >> runtime-library.pom
  echo "$artifactId" >>
runtime-library.pom
  echo "$version" >> runtime-library.pom
  echo "" >> runtime-library.pom

done

echo "" >> runtime-library.pom
echo "" >> runtime-library.pom

echo "Done."



On Wed, Sep 4, 2013 at 1:32 PM, Wayne Fay  wrote:

> > I am new for Maven; I have a question:
>
> Questions like this should go to the Maven Users list. This list is
> reserved for discussion of the development of Maven itself.
>
> > Can I create folder Dependency in Maven? without installing the jar
> > (dependency)?
>
> No. You will waste a lot of time going down this road. You only need
> to install "all" those jars one time (assuming you have a Repo
> Manager, you'll use "mvn deploy:deploy-file" otherwise you'll need to
> "mvn install:install-file" them on each developer's machine) and write
> the  stanzas once. Then you can reuse that work in your
> various projects. Bite the bullet and do it now. 100 jars is not too
> bad. If you do it the right way, I bet you'll find a lot of them are
> open source and already hosted in Central.
>
> Wayne
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: What is the correct Git SCM URL for a branch?

[Chris Graham]

On Sun, Sep 1, 2013 at 8:21 PM, Hervé BOUTEMY  wrote:

> if I read Jazz SCM url format [1], in a multi-module build, scm info
> automatically calculated from root to modules (ie appending artifact-id)
> will
> give wrong scm info, no?
> did you try it?
>
>
All of my testing was for multi module projects. Nested ones. So it was
never a problem.

There is an ugly work around/hack (that automatically happens) for non-nest
projects. So add a dummy path to the end of the Component name, and it
seems to work out.

As the SCM section is only in the root pom, it does not seem to be effected.

A tag (in maven SCM terms) is the equivalent of a snapshot of a component
(in Jazz SCM terms). Technically, it is a collection of Change Sets, but
effectively works out to be a "tag" for a given component.

So I think of all modules as a part of the same component (just like all
modules under a trank/branch in svn). so it tends to work nicely.


> there are 2 other parts:
> - m-release-p: did you add any logic to deal with plugin scm info
> modification
> when tagging a version?
>

I didn't, but I think that Robert had to add some logic in there that
applied to Jazz (and I think some others as well). I'd have to go back and
look.


> - m-pir-p: when you do a checkout (or clone, or view, I don't know the
> exact
> term for Jazz), IIUC, you get a repository copy: did you write some
> instructions in the generated page to cd to module base directory? (again
> for
> multi-module builds)
>

You're the first to ask about this.

I just quickly run a site build, and the generated URL's in the Source
Repository pages are wrong, as they assume the ability to check out just
one module of a multi module project (eg SVN terms, a svn checkout of
.../trunk/Module). This shows the CVS/SVN embedded thinking that is pretty
much implicit across much of the SCM and Release modules.

I do not believe that it is possible to check out (via the command line, I
think that you _may_ be able to via the GUI) one sub dir (ie Module) of a
Jazz SCM Component.

A checkout in Jazz SCM terms is a "Load". :-)

See:

http://maven.apache.org/scm/maven-scm-providers/maven-scm-provider-jazz/index.html


[1] http://maven.apache.org/scm/jazz.html
>
> Le dimanche 1 septembre 2013 09:54:39 Chris Graham a écrit :
> > I did something similar in the Jazz provider. It's a complex URL, or can
> be
> > if it needs to be, but it's still a single line.
> >
> > It's just a matter of making the parser smarted. And that's local to the
> > provider, so go nuts. I also put lots of unit tests in there to
> illustrate
> > the correct and incorrect usage.
> >
> > -Chris
> >
> > On Fri, Aug 30, 2013 at 6:33 AM, Hervé BOUTEMY  >wrote:
> > > Le samedi 24 août 2013 23:08:05 Robert Scholte a écrit :
> > > > I agree that a single SCM line doesn't really match anymore with
> systems
> > > > like DSCM (git, Mercurial)
> > > > It would have been better if we could think of a better way to define
> > >
> > > this
> > >
> > > > in a newer POM-model.
> > >
> > > it was overkill at the time Maven was done, and even today, splitting
> scm
> > > developerConnection into 3 parts seems overkill for classical SCMs,
> even
> > > if
> > > doable
> > >
> > > notice that even with "single SCM line", we can have multiple fields,
> like
> > > we
> > > already have for example with git to distinguish fetch and push urls:
> > > scm:git:
> > > [fetch=]
> > >
> http://mywebserver.org/path_to_repository[push=]ssh://username@otherserver
> > > :8898/~/repopath.git 
> > >
> > > in the same spirit, we could support a branch and a path parts
> > > scm:git:
> > >
> https://git-wip-us.apache.org/repos/asf/maven.git[branch=]maven-3.0.x[path
> > > =]/maven-core 
> > >
> > > with such scm url format, we have the structure we like without POM
> format
> > > change, and module value inheritance by adding artifact-id to the url
> > > stays
> > > simple and consistent
> > >
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > -
> > > 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: What is the correct Git SCM URL for a branch?

[Chris Graham]

I did something similar in the Jazz provider. It's a complex URL, or can be
if it needs to be, but it's still a single line.

It's just a matter of making the parser smarted. And that's local to the
provider, so go nuts. I also put lots of unit tests in there to illustrate
the correct and incorrect usage.

-Chris


On Fri, Aug 30, 2013 at 6:33 AM, Hervé BOUTEMY wrote:

> Le samedi 24 août 2013 23:08:05 Robert Scholte a écrit :
> > I agree that a single SCM line doesn't really match anymore with systems
> > like DSCM (git, Mercurial)
> > It would have been better if we could think of a better way to define
> this
> > in a newer POM-model.
> it was overkill at the time Maven was done, and even today, splitting scm
> developerConnection into 3 parts seems overkill for classical SCMs, even if
> doable
>
> notice that even with "single SCM line", we can have multiple fields, like
> we
> already have for example with git to distinguish fetch and push urls:
> scm:git:
> [fetch=]
> http://mywebserver.org/path_to_repository[push=]ssh://username@otherserver:8898/~/repopath.git
> 
>
> in the same spirit, we could support a branch and a path parts
> scm:git:
> https://git-wip-us.apache.org/repos/asf/maven.git[branch=]maven-3.0.x[path=]/maven-core
> 
>
> with such scm url format, we have the structure we like without POM format
> change, and module value inheritance by adding artifact-id to the url stays
> simple and consistent
>
>
> Regards,
>
> Hervé
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Model Converter version 2.3

[Chris Graham]

Sent from my iPhone

On 15/08/2013, at 10:05 PM, sebb  wrote:

> On 15 August 2013 10:08, Chris Graham  wrote:
>> What sebb does not appear to have understood or accepted, as Stephen has
>> endlessly pointed out, is that we vote on the source bundle, not a scm
>> revision, and that, strictly speaking a SCM is not even required (however
>> sensible it is to use one).
>> 
>> He wants a tree and a revision so that we can compare between releases,
>> where what he should be doing, strictly speaking, is comparing source tar
>> balls, as that is what we really are voting on.
> 
> I agree that what is released (and voted on) are the source tarballs.
> And any such tarballs should be identical (barring possibly different
> EOL settings for text files).
> 
> However, that is only one of the checks that need to be made.
> 
> The PMC also needs to ensure that the files are being released under
> the correct license.

Are not the licenses in the source that is in the source tarball?

If so, can not the rat plugin or similar be used to check the compliance?

> I contend that the only practical way to check the licences is to
> compare the source tarball(s) with the files in SCM.
> 
> [The files should only be added to SCM if the license is OK, so the
> SCM tag acts as a database of validated source files.]
> 
> The SVN revision / Git hash are needed to ensure uniqueness.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

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

Re: [VOTE] Release Apache Maven Model Converter version 2.3

[Chris Graham]

What sebb does not appear to have understood or accepted, as Stephen has
endlessly pointed out, is that we vote on the source bundle, not a scm
revision, and that, strictly speaking a SCM is not even required (however
sensible it is to use one).

He wants a tree and a revision so that we can compare between releases,
where what he should be doing, strictly speaking, is comparing source tar
balls, as that is what we really are voting on.

The greater maven community also does not appear to have a problem with
this approach.

-Chris



On Thu, Aug 15, 2013 at 6:50 PM, Jörg Schaible
wrote:

> Hi Oliver,
>
> Olivier Lamy wrote:
>
> > On 15 August 2013 08:53, sebb  wrote:
> >> On 14 August 2013 21:21, Dennis Lundberg  wrote:
> >>> On Wed, Aug 14, 2013 at 10:47 AM, sebb  wrote:
> >>>
>  On 13 August 2013 18:58, Dennis Lundberg  wrote:
>  > On Tue, Aug 13, 2013 at 12:30 AM, sebb  wrote:
>  >> On 12 August 2013 20:10, Jason van Zyl  wrote:
>  >>>
>  >
>  > I have now read the threads that are referring to, and have not
>  > found a single link to any ASF rule stating that we need to
>  > include these things in a VOTE thread.
>  
>   So how do you propose that reviewers check the provenance of the
>   files in the source release?
>  >>>
>  >>> Are you looking for files that are in a distribution that didn't
>  >>> come
>  from source control? Everything else as far as provenance goes is
>  covered. Errant content is a potential problem, but everything in a
>  distribution should come from source control which no one has access
> to
>  until they have a signed CLA on file.
>  >>
>  >> Yes. That is where the whole saga started.
>  >>
>  >> Proving provenance is why the SCM coordinates are needed for the
>  >> vote.
>  >>
>  >> The SCM details may also be useful to discover files accidentally
>  >> omitted from the source archive.
>  >
>  > You want to compare the contents of the *-source-release.zip with
>  > something from SCM, to make nothing bad has crept into the source
>  > bundle. So you need to know where in SCM you can find it. Have I
>  > understood you correctly?
> 
>  It's vital to be able to link the files in the source release
>  archive(s) to their origin in SCM.
> 
>  The provenance of any source files the ASF releases must be clearly
>  traceable.
> 
> >>>
> >>> This information is clearly traceable and available to anyone who wants
> >>> to review a release made by the Maven project. Our process uses the
> >>> Release Plugin, which will put the POM from the SCM tag in the staging
> >>> directory along with the source-release.zip. In that POM wou will find
> >>> the URL to the original sources in SCM.
> >>>
> >>
> >> As has already been pointed out, SVN tags are not immutable, so the
> >> tag name alone is not sufficient.
> >
> > I think Stephen perfectly sum up the situation.
> > If you're not happy follow that.
> >
> > But please STOP the troll!
>
> The Maven PMC has made clear, that it knows about the problems and want to
> ignore it. However, please understand that Sebb is playing devil's advocate
> here, because the same release process is used for other Apache projects
> where the PMCs will *not* ignore this flaws. Sebb is more or less pestering
> you, because he is tired of having the same discussions in projects where
> he
> *is* PMC and is therefore responsible for the release. So, it is a bit
> short
> sighted to declare him as troll, simply because you (the Maven PMC) decided
> to ignore the problem.
>
> - Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Strange handling of + in version portion of GAV

[Chris Graham]

This is valid. The + does not have to be escaped into %2B.

See: http://www.rfc-editor.org/rfc/rfc1738.txt

-Chris


On Mon, Jul 29, 2013 at 6:05 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

>
> http://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/build-monitor-plugin/1.0+build.14/
>
> Has anyone noticed that we don't seem to be encoding the + character when
> mapping GAV to URL?
>

Re: Release Maven 3.1.1

[Chris Graham]

+1

I agree that slight less frequent releases can be easier to users to cope with.

The 6-8 week period is ok with me.

-Chris

Sent from my iPhone

On 29/07/2013, at 2:48 AM, "Robert Scholte"  wrote:

> Hi,
> 
> Personally I'm not a huge fan of the release-model as done by Jenkins, 
> meaning releasing once or twice a week with only a few fixes.
> As a user I'm not going to update for every new release, it most have real 
> value before I upgrade.
> As both developer and user it's much more easier to recognize issues as part 
> of a specific version, if the number of releases stays small enough.
> I'd prefer to gather more fixes per release and go for a 6-8 week (or 4-6 
> week) release cycle.
> IIRC that was also the original intention with M3.
> 
> Robert
> 
> Op Sun, 28 Jul 2013 18:36:32 +0200 schreef Jason van Zyl :
> 
>> On Jul 28, 2013, at 12:25 PM, Hervé BOUTEMY  wrote:
>> 
>>> I'd like to work on cd tonight
>>> 
>>> so if you wait for tomorrow...
>>> 
>> 
>> I don't really want to wait, why can't that just go in next week? You don't 
>> know how long it will take and I think we should just start releasing what 
>> we have.
>> 
>>> notice there are 2 ITs failing on ASF's Jenkins because of a failure to find
>>> artifacts that are available AFAIK in the local repo: I suppose I'm missing
>>> something trivial in the configuration
>>> Can you help me on this, please?
>> 
>> The ITs need to work, I till take a look at report back.
>> 
>>> 
>>> Regards,
>>> 
>>> Hervé
>>> 
>>> Le dimanche 28 juillet 2013 12:08:35 Jason van Zyl a écrit :
 I'd like to release Maven 3.1.1 and try to get the cadence revived for 
 minor
 version releases by trying to release minor versions as frequently as there
 are fixes to make available.
 
 Just a couple simple fixes:
 
 [MNG-5499] maven-aether-provider leaks Sisu Plexus and ObjectWeb classes
 onto the classpath when they are not required [MNG-5495] API
 incompatibility causes Swagger Maven Plugin (and others) to fail under
 Maven 3.1.0
 
 But helps consumers of the Maven Aether Provider and plugin issues caused 
 by
 incompatibilities with the converters. There are lots of other things to
 fix, but as they become available they can be released. If possible I'd
 just like to start releasing any fixes we have on a weekly basis.
 
 Any objections?
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -
 
 A man enjoys his work when he understands the whole and when he
 is responsible for the quality of the whole
 
 -- Christopher Alexander, A Pattern Language
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>> 
>> 
>> Thanks,
>> 
>> Jason
>> 
>> --
>> Jason van Zyl
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> -
>> 
>> People develop abstractions by generalizing from concrete examples.
>> Every attempt to determine the correct abstraction on paper without
>> actually developing a running system is doomed to failure. No one
>> is that smart. A framework is a resuable design, so you develop it by
>> looking at the things it is supposed to be a design of. The more examples
>> you look at, the more general your framework will be.
>> 
>>  -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
>> 
>> 
>> 
>> 
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

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

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

[Chris Graham]

On Thu, Jul 25, 2013 at 11:16 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> There are two schools of thought amongst the current members of this
> projects PMC.
>
>
Are they mutually exclusive?

>From my (limited [so I could be way off here]) understanding of Apache,
don't you only get to be on the PMC for having demonstrated the correct
community spirit and sufficient commitment 'to the cause' (as it were)?

And like many real world jobs, when you 'step up' you often gain/get
thrusted upon you more responsibility; it's just a part of the job.

I understand why the Apache Foundation has the legal requirements that it
does. It also needs people to monitor implement them. That appears to fall
upon the PMC.

It seems to me that for someone to get to be on the PMC to start with they
have demonstrated sufficient community spirit and commitment to the project.

So as you said, it's not black and white. :-) I'm happy to see it as both.

Personally, I prefer to lead by example. But you can still do that whilst
maintining the legal requirements.

-Chris





> Without wanting to deliberately tip my hand and reveal where my opinion is,
> we would like to solicit the opinions if the community that we serve.
>
> Please give us your thoughts.
>
> The topic is essentially:
>
> Do you want the members of the Maven PMC to be social leaders of the Maven
> community, who's actions demonstrate the best community behaviour?
>
> The alternative is that members of the Maven PMC are here purely to
> complete the legal requirements that an Apache TLP has delegated to PMCs
>
> This is not black and white... The answer can be grey... And everyone is
> human so can make mistakes...
>
> So community, what are you expecting?
>
> - Stephen Connolly
>
> On Thursday, 25 July 2013, wrote:
>
> > Author: jdcasey
> > Date: Wed Jul 24 23:21:58 2013
> > New Revision: 1506778
> >
> > URL: http://svn.apache.org/r1506778
> > Log:
> > Adding section on PMC standards of community commitment
> >
> > Modified:
> > maven/site/trunk/content/markdown/project-roles.md
> >
> > Modified: maven/site/trunk/content/markdown/project-roles.md
> > URL:
> >
> http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1506778&r1=1506777&r2=1506778&view=diff
> >
> >
> ==
> > --- maven/site/trunk/content/markdown/project-roles.md (original)
> > +++ maven/site/trunk/content/markdown/project-roles.md Wed Jul 24
> > 23:21:58 2013
> > @@ -176,6 +176,29 @@ The Project Management Committee has the
> >  * Voting on release artifacts.
> >  * 
> >
> > + Standards for Community Commitment
> > +
> > +In the spirit of supporting the health of our community, Project
> > +Management Committee members refrain from actions that subvert the
> > +functioning of the committee itself.
> > +
> > +First, Project Management Committee members should not maintain
> > long-running
> > +forks of Maven code outside of the project itself. Making significant
> > +changes to Maven code outside of the project displays a lack of
> > +investment in the community. Additionally, attempting to re-integrate
> > +a large number of code changes in bulk overwhelms the ability of
> > +volunteers in the community to review (and potentially veto) the
> > +changes. This effectively thwarts the policing function of the
> > +PMC.
> > +
> > +Second, Project Management Committee members should not divert
> > +work on redesigning, reimplementing, or improving Maven code to
> > +alternative projects outside of this community for the purposes of
> > +reintroducing them as replacement for existing Maven code. While there
> > +is a danger here of falling into a Not Invented Here mentality, new
> > projects
> > +created by Maven PMC members strictly to replace Maven code should not
> be
> > +allowed.
> > +
> >  ### [Project Management Chair](
> > http://www.apache.org/foundation/how-it-works.html#pmc-chair)
> >
> >  For various legal reasons, there are certain things that the Apache
> >
> >
> >
>
> --
> Sent from my phone
>

SCM Providers

[Chris Graham]

Hey All.

In the RTC/Jazz forum, a request came up for the ability to associate a
Work Item with the commits that the SCM plugin does.

On the Jazz side, I think that I've worked things out.

However, I am unsure as to how to best do this on the maven and scm
provider side.

The generic question boils down to:

How can we supply a scm specific parameter to a specific scm provider?

One that is not applicable to all providers.

I really do not want to add a -D option. :-)

Thoughts/comments/suggestions?

-Chris

Re: [VOTE] All new (non-patch) releases of Maven Core after 30th Sep 2013 to require Java 6+

[Chris Graham]

I'm cool with that.

+1

PS: The EOL date for Java 1.5 was not just for zOS, it applied to all
platforms for the IBM JDK, AIX and Linux included.


On Wed, Jul 24, 2013 at 8:42 AM, Olivier Lamy  wrote:

> +1
>
> 2013/7/23 Stephen Connolly :
> > This vote is to cover the minimum required version of Java for Maven
> Core.
> >
> > Maven Plugins produced by the Apache Maven Project that are flagged as
> > compatible with older versions of Maven Core as their baseline will still
> > require to stick to the minimum Java requirements of that Maven Core
> > version. In other words, if for example maven-compiler-plugin advertises
> > compatibility with Maven Core 2.0.11+ then that will still need to be
> > compiled targeting Java 1.4 and only using dependencies that are aligned
> > with that runtime requirement.
> >
> > Additionally patch releases to existing releases of Maven Core will not
> be
> > subject to this requirement.
> >
> > For example [example]*if* this vote passes and *if* on Sep 29th we
> release
> > Maven 3.2.0 and *if* on Oct 2nd we release Maven 2.0.12, Maven 2.2.2,
> Maven
> > 3.0.6, Maven 3.1.1, Maven 3.2.1 and Maven 3.3.0 (due to say some security
> > issue that affected all versions of Maven) then only Maven 3.3.0 would be
> > require Java 6 as a minimum runtime requirement, the 2.0.12 release would
> > still require Java 1.4 and the 2.2.2, 3.0.6, 3.1.1 and 3.2.1 versions
> would
> > all still require Java 1.5.[/example]
> >
> > This is not a requirement that 3rd party plugins need use Java 6 as a
> > minimum. Third party plugins are free to require any Java version >= the
> > corresponding Maven minimum requirement, though obviously from a users
> > perspective it is best if plugins try to adhere to our contracts for
> > corresponding versions of Maven Core.
> >
> > Justification for the cut-off date:
> >
> > * Oracle has gone end of life on Java 6 Feb 2013 (note that there is
> still
> > extended and sustaining support for existing Oracle customers using Java
> 5)
> > * IBM will go end of life for z/OS on 30th Sep 2013 (other platforms are
> > still with support, but there are other Java vendors for other platforms)
> > * Apple no longer supports any hardware that does not have at least an
> > Apple Java 6 version available.
> > * Red Hat is providing support for OpenJDK 6
> > * HP-UX, OpenVMS, and Tru64 all have a Java 6 implementation available.
> >
> > As I see it, that essentially ensures that for the vast majority of
> > platforms there is a very strong likelihood of a Java 6 compatible
> version
> > of Java available for that platform. Toolchains support or forking of the
> > compiler and surefire can provide support for users who still need to
> build
> > with older versions of Java (e.g., as was the case for Java 1.4.2 with
> > Maven 2.2.1). Additionally users who are forced to use a java version
> older
> > than Java 6 also are likely unable to upgrade their version of Maven, so
> > this change will not affect them
> >
> > This vote is open for 72 hours. A minimum of three +1 binding votes (i.e.
> > from the PMC) and the majority of votes cast from committers will be
> > required to pass this vote.
> >
> > +1000: Yes, and when can we have the vote to go for Java 7 as a minimum?
> > (This option is equivalent to +1 but provides people the ability to
> > indicate an additional preference while not contributing to the
> inevitible
> > noise)
> > +1: Yes
> > 0: No opinion
> > -1: No
> >
> > -Stephen
>
>
>
> --
> Olivier Lamy
> Ecetera: http://ecetera.com.au
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven 3.1 - Stable ?

[Chris Graham]

+1

Sent from my iPhone

On 20/07/2013, at 11:28 AM, Paul Benedict  wrote:

> Herve, I noticed the release history uses a national date format that I
> don't recognize. I think the standard ISO date format of -MM-DD is most
> recognized by developers. What do you think? Is it worth changing?
> 
> 
> On Fri, Jul 19, 2013 at 12:37 PM, Paul Benedict wrote:
> 
>> Glad to see Maven 3.1 finally be listed on the home page as the preferred
>> version. But the release date is wrong; it's currently display the prior
>> 3.0.5 release date (23 February 2013).
>> 
>> 
>> 
>> On Thu, Jul 18, 2013 at 2:10 PM, Hervé BOUTEMY wrote:
>> 
>>> sure :)
>>> 
>>> Le jeudi 18 juillet 2013 11:54:19 Jason van Zyl a écrit :
 Am I staging and not publishing? Maybe that's why my stuff never comes
>>> up.
 
 On Jul 18, 2013, at 11:48 AM, Hervé BOUTEMY 
>>> wrote:
> I fixed the typo a few days ago, it was staged but not published
> 
> I just published it, so the problem is not here any more
> 
> Regards,
> 
> Hervé
> 
> Le jeudi 18 juillet 2013 12:29:54 Stephen Connolly a écrit :
>> Why is 3.1.0 labelled as 3.1.0-alpha-1 (and why have we two
>>> 3.1.0-alpha-1
>> labels... I expect the same answer)
>> 
>> On 17 July 2013 21:01, Hervé BOUTEMY  wrote:
>>> Le mercredi 17 juillet 2013 14:13:38 Paul Benedict a écrit :
 Is 3.0.5 still the preferred version? I ask because the right-hand
 aside
>>> 
>>> is
>>> 
 still "Get Maven 3.0.5" -- which makes sense if 3.1 is not GA, but
>>> I
>>> 
>>> think
>>> 
 it is, right?
 
 PS: None of the release-notes.html pages include the release date.
>>> Can
>>> 
>>> this
>>> 
 information be added (in the future)? It is difficult to determine
>>> how
>>> 
>>> long
>>> 
 it has been since a prior release.
>>> 
>>> I wrote http://maven.apache.org/docs/history.html recently exactly
>>> for
>>> this
>>> purpose
>>> 
>>> Regards,
>>> 
>>> Hervé
>>> 
>>> 
>>> 
>>> -
>>> 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
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -
 
 Selfish deeds are the shortest path to self destruction.
 
 -- The Seven Samuari, Akira Kurosawa
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>> 
>>> 
>> 
>> 
>> --
>> Cheers,
>> Paul
>> 
> 
> 
> 
> -- 
> Cheers,
> Paul

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

Re: [VOTE] Retire maven-idea-plugin

[Chris Graham]

+1 (non-binding)


On Sat, Jul 20, 2013 at 6:11 AM, Baptiste Mathus  wrote:

> +1 (non binding)
> Le 19 juil. 2013 21:45, "Anders Hammar"  a écrit :
>
> > +1, non-binding
> >
> > /Anders (mobile)
> > Den 19 jul 2013 19:01 skrev "Dennis Lundberg" :
> >
> > > Hi
> > >
> > > It has been almost five years since I made the last release of
> > > maven-idea-plugin. The features in IDEA to integrate Maven has been
> > greatly
> > > improved since then, making our own plugin obsolete. I therefor propose
> > > that we retire maven-idea-plugin.
> > >
> > > If this vote is successful I will make one final release of the plugin,
> > > making it clear on the plugin site that it has been retired. After that
> > the
> > > source code will be moved into the "retired" area in Subversion.
> > >
> > > This is AFAIK the first vote to follow our process for retiring a
> plugin.
> > > For those interested, the process  is described here:
> > > http://maven.apache.org/developers/retirement-plan-plugins.html
> > >
> > >
> > > [ ] +1 Yes, it's about time
> > > [ ] -1 No, because...
> > >
> > > --
> > > Dennis Lundberg
> > >
> >
>