from:"Chris Graham"

Re: Maven Security, @Component and MNG-4384

2019-06-24 Thread 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

2019-06-23 Thread 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

2018-12-30 Thread 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

2018-12-29 Thread 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

2018-12-29 Thread 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

2018-04-19 Thread 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

2017-11-11 Thread 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 <chrisgw...@gmail.com> 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

2017-11-11 Thread 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

2017-09-07 Thread 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 <stephen.alan.conno...@gmail.com> 
> 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 <chrisgw...@gmail.com> 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 <khmarba...@gmx.de>
>> 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 <khmarba...@gmx.de
>>>> <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

2017-09-07 Thread 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] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)

2015-08-14 Thread Chris Graham (JIRA)


[ 
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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}
 scm
   connection${project.parent.scm.connection}/connection
   
 developerConnection${project.parent.scm.developerConnection}/developerConnection
   url${project.parent.scm.url}/url
 /scm
 {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)

2015-08-14 Thread Chris Graham (JIRA)

[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 bthat module/b.

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 bentire repo/b [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}
scm
connection${project.parent.scm.connection}/connection

developerConnection${project.parent.scm.developerConnection}/developerConnection
url${project.parent.scm.url}/url
/scm
{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] [Comment Edited] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)

2015-08-14 Thread Chris Graham (JIRA)

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

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

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 bentire repo/b [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 bthat module/b.

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 bentire repo/b [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

developerConnection${project.parent.scm.developerConnection}/developerConnection
url${project.parent.scm.url}/url
/scm
{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)

2015-08-13 Thread Chris Graham (JIRA)


[ 
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 moduleblah/module statements), or 
flattened (and module../blah/module 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}
 scm
   connection${project.parent.scm.connection}/connection
   
 developerConnection${project.parent.scm.developerConnection}/developerConnection
   url${project.parent.scm.url}/url
 /scm
 {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)

2015-08-13 Thread Chris Graham (JIRA)

[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

developerConnection${project.parent.scm.developerConnection}/developerConnection
url${project.parent.scm.url}/url
/scm
{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)

2015-08-13 Thread Chris Graham (JIRA)

[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 scm 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

developerConnection${project.parent.scm.developerConnection}/developerConnection
url${project.parent.scm.url}/url
/scm
{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)

2015-08-09 Thread Chris Graham (JIRA)


[ 
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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}
 scm
   connection${project.parent.scm.connection}/connection
   
 developerConnection${project.parent.scm.developerConnection}/developerConnection
   url${project.parent.scm.url}/url
 /scm
 {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

2015-06-01 Thread 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 ja...@takari.io wrote:

 Great, thanks Baptiste.

  On May 31, 2015, at 4:36 AM, Baptiste Mathus bmat...@batmat.net 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 baerr...@gmail.com:
 
  On 31 May 2015 at 08:18, Jason van Zyl ja...@takari.io 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 Batmat 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

Re: Full migration to Git

2015-06-01 Thread Chris Graham

+1.

Sent from my iPad

 On 1 Jun 2015, at 6:08 pm, Arnaud Héritier aherit...@gmail.com 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 chrisgw...@gmail.com 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 ja...@takari.io wrote:
 
 Great, thanks Baptiste.
 
 On May 31, 2015, at 4:36 AM, Baptiste Mathus bmat...@batmat.net
 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 baerr...@gmail.com:
 
 On 31 May 2015 at 08:18, Jason van Zyl ja...@takari.io 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 Batmat 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

2015-06-01 Thread Chris Graham



Sent from my iPad

 On 2 Jun 2015, at 12:16 am, Jason van Zyl ja...@takari.io 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 
 kristian.rosenv...@gmail.com 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 ja...@takari.io:
 
 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 ol...@apache.org wrote:
 
 On 1 June 2015 at 21:37, Jason van Zyl ja...@takari.io 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 ol...@apache.org 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 ja...@takari.io 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 ja...@takari.io 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
 
 
 
 
 
 
 
 
 
 
 
 
 
 -
 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
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder, Takari and Apache Maven
 http://twitter.com/jvanzyl
 http://twitter.com/takari_io
 -
 
 In short, man creates for himself a new religion of a rational
 and technical order to justify

SCM: ClearCase tests failing on Windows

2015-04-29 Thread 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: svn tagging fails in release:prepare ???

2015-04-22 Thread 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 kristian.rosenv...@gmail.com 
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 adrien.riv...@gmail.com:
 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 rfscho...@apache.org
 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 rfscho...@apache.org:
 
 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
 kristian.rosenv...@gmail.com:
 
 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: Re : ASF Jira Issues

2015-04-22 Thread Chris Graham

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

On Wed, Apr 22, 2015 at 10:41 PM, herve.bout...@free.fr 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 chrisgw...@gmail.com
 À: Maven Developers List dev@maven.apache.org
 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

2015-04-22 Thread 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, herve.bout...@free.fr 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 chrisgw...@gmail.com
 À: Maven Developers List dev@maven.apache.org
 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

2015-04-22 Thread 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: Building SCM 1.9.5-SNAPSHOT

2015-04-21 Thread Chris Graham

: 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 chrisgw...@gmail.com

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 chrisgw...@gmail.com

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 chrisgw...@gmail.com

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 chrisgw...@gmail.com

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 execute goal

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

2015-04-19 Thread 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

2015-04-13 Thread Chris Graham

)

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 chrisgw...@gmail.com
 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

2015-04-12 Thread 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

2015-04-12 Thread Chris Graham

On Sat, Apr 11, 2015 at 7:06 PM, Mirko Friedenhagen mfriedenha...@gmail.com
 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 rfscho...@apache.org 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

2015-04-09 Thread 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, chrisgw...@apache.org 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=1672232r1=1672231r2=1672232view=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.
 /roles
 timezone+1/timezone
   /developer
  +developer
  +  idchrisgwarp/id
  +  nameChris Graham/name
  +  emailchrisgw...@apache.org javascript:;/email
  +  roles
  +roleCommitter/role
  +  /roles
  +  timezoneAustralia/Melbourne/timezone
  +/developer
   !--End Committers--
 
   developer
 
 
 

 --
 Sent from my phone

Re: Building SCM 1.9.5-SNAPSHOT

2015-04-04 Thread 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 herve.bout...@free.fr wrote:

 typical of process output consumption problems

 see http://groovy-lang.org/groovy-dev-kit.html#process-management for
 description and solution:
 quoteBecause 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()/quote

 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 chrisgw...@gmail.com
 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 chrisgw...@gmail.com
 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 jie...@gmail.com wrote:
   Please dockerize all maven developer environments.
  
   On Wed, Apr 1, 2015 at 10:26 PM, Chris Graham chrisgw...@gmail.com
  
   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

Re: Building SCM 1.9.5-SNAPSHOT

2015-04-02 Thread Chris Graham


On 02/04/2015, at 5:15 PM, Karl Heinz Marbaise khmarba...@gmx.de 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] 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

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

2015-04-01 Thread 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 khmarba...@gmx.de 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 khmarba...@gmx.de 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

2015-04-01 Thread 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 and...@hammar.net 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 chrisgw...@gmail.com 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 chrisgw...@gmail.com 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

Re: [VOTE] Release Apache Maven SCM version 1.9.4

2015-04-01 Thread 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 herve.bout...@free.fr 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 khmarba...@gmx.de
 
 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 ol...@apache.org wrote:
 +1
 
 On 29 March 2015 at 10:33, Karl Heinz Marbaise khmarba...@gmx.de
 
 wrote:
 Hi,
 
 We solved 8 issues:
 http://jira.codehaus.org/secure/ReleaseNote.jspa?
 projectId=10527version=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: Building SCM 1.9.5-SNAPSHOT

2015-04-01 Thread 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 jie...@gmail.com wrote:

 Please dockerize all maven developer environments.

 On Wed, Apr 1, 2015 at 10:26 PM, Chris Graham chrisgw...@gmail.com
 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 .. 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: 39.431s
  [INFO] Finished at: Thu Apr 02 13:24:37 AEDT 2015
  [INFO] Final Memory: 12M/40M
  [INFO

Re: Building SCM 1.9.5-SNAPSHOT

2015-04-01 Thread 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 chrisgw...@gmail.com 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 chrisgw...@gmail.com 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 jie...@gmail.com wrote:

 Please dockerize all maven developer environments.

 On Wed, Apr 1, 2015 at 10:26 PM, Chris Graham chrisgw...@gmail.com
 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

Re: Building SCM 1.9.5-SNAPSHOT

2015-04-01 Thread Chris Graham

 4a4f362655a301c5112be633b31c2860644ba06f
Author: HervC3A9 Boutemy hbout...@apache.org
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 chrisgw...@gmail.com 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 and...@hammar.net 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 chrisgw...@gmail.com
 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 chrisgw...@gmail.com 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

Re: Building SCM 1.9.5-SNAPSHOT

2015-04-01 Thread Chris Graham

 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-scmmvn --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 chrisgw...@gmail.com 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]
 
 [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 rep
 ort in: C:\CALMData\Workspaces\RTC\Deb\maven-scm\target\rat.txt - [Help 1]
 [ERROR]
 [ERROR] To see the full stack trace of the errors, re-run Maven with the
 -e switch.
 [ERROR] Re-run Maven using the -X switch

Re: Building SCM 1.9.5-SNAPSHOT

2015-04-01 Thread 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 chrisgw...@gmail.com 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 jie...@gmail.com wrote:

 Please dockerize all maven developer environments.

 On Wed, Apr 1, 2015 at 10:26 PM, Chris Graham chrisgw...@gmail.com
 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 .. 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

Re: [VOTE] Release Apache Maven SCM version 1.9.4

2015-03-31 Thread 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 khmarba...@gmx.de
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 ol...@apache.org wrote:

  +1

 On 29 March 2015 at 10:33, Karl Heinz Marbaise khmarba...@gmx.de
 wrote:

  Hi,

 We solved 8 issues:
 http://jira.codehaus.org/secure/ReleaseNote.jspa?
 projectId=10527version=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: Building SCM 1.9.5-SNAPSHOT

2015-03-31 Thread 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 chrisgw...@gmail.com 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 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

Re: Building SCM 1.9.5-SNAPSHOT

2015-03-31 Thread 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 herve.bout...@free.fr 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
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/de
  fault-compile/createdFiles.lst
 
 
 maven-scm/maven-scm-api/target/maven-status/maven-compiler-plugin/compile/de
  fault-compile/inputFiles.lst
 
 
 maven-scm/maven-scm-api/target/maven-status/maven-compiler-plugin/testCompil
  e/default-testCompile/createdFiles.lst
 
 
 maven-scm/maven-scm-api/target/maven-status/maven-compiler-plugin/testCompil
  e/default

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

2015-03-31 Thread 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 khmarba...@gmx.de 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

Building SCM 1.9.5-SNAPSHOT

2015-03-31 Thread 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:

Re: [VOTE] Release Apache Maven SCM version 1.9.4

2015-03-30 Thread 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 ol...@apache.org wrote:

 +1

 On 29 March 2015 at 10:33, Karl Heinz Marbaise khmarba...@gmx.de wrote:

  Hi,
 
  We solved 8 issues:
  http://jira.codehaus.org/secure/ReleaseNote.jspa?
  projectId=10527version=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: [VOTE] Release Apache Maven SCM version 1.9.4

2015-03-30 Thread Chris Graham

Will do!

-Chris

Sent from my iPad

 On 31 Mar 2015, at 4:57 am, Karl Heinz Marbaise khmarba...@gmx.de 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 ol...@apache.org wrote:
 
 +1
 
 On 29 March 2015 at 10:33, Karl Heinz Marbaise khmarba...@gmx.de
 wrote:
 
 Hi,
 
 We solved 8 issues:
 http://jira.codehaus.org/secure/ReleaseNote.jspa?
 projectId=10527version=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

2015-03-30 Thread 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 khmarba...@gmx.de 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 ol...@apache.org wrote:
 
 +1
 
 On 29 March 2015 at 10:33, Karl Heinz Marbaise khmarba...@gmx.de wrote:
 
 Hi,
 
 We solved 8 issues:
 http://jira.codehaus.org/secure/ReleaseNote.jspa?
 projectId=10527version=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: move maven core to java 7?

2015-03-09 Thread 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 denn...@apache.org 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 i...@ifedorenko.com 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 denn...@apache.org:
 
 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 Java 7 in 3.4.0
 
 
 [1] http://maven.apache.org/developers/java6.html
 
 On Thu, Mar 5, 2015 at 1:19 PM, Igor Fedorenko i...@ifedorenko.com
 
 wrote:
 
 With maven core version change to 3.3.0 on master, any objections I
 change compile source/target to java 7?
 
 --
 Regards,
 Igor
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 --
 Dennis

Re: move maven core to java 7?

2015-03-05 Thread 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 khmarba...@gmx.de
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
 i...@ifedorenko.com:

  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: status of last plugins release with Maven 2.2.1 and Java 5 requirements

2015-03-03 Thread Chris Graham



Sent from my iPad

 On 3 Mar 2015, at 6:35 pm, Karl Heinz Marbaise khmarba...@gmx.de 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

2015-03-03 Thread Chris Graham

Brilliant! Ta!

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

-Chris

On Wed, Mar 4, 2015 at 8:18 AM, Robert Scholte rfscho...@apache.org 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 rfscho...@apache.org
 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 rfscho...@apache.org
 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 rfscho...@apache.org
 
 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


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

Re: SCM Providers

2015-03-03 Thread 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 rfscho...@apache.org 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 rfscho...@apache.org
 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 rfscho...@apache.org
 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


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

Re: SCM Providers

2015-02-25 Thread 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 rfscho...@apache.org
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 rfscho...@apache.org
 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

2015-02-22 Thread Chris Graham

On Mon, Feb 23, 2015 at 8:42 AM, Fred Cooke fred.co...@gmail.com 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 CCB, 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

2015-01-27 Thread 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 manf...@mosabuam.com 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 dant...@gmail.com 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

2014-12-15 Thread Chris Graham

A

Sent from my iPhone

On 15/12/2014, at 9:39 PM, Stephen Connolly stephen.alan.conno...@gmail.com 
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

2014-12-10 Thread Chris Graham

H

-Chris

Sent from my iPhone

On 10/12/2014, at 11:53 PM, Graham Leggett minf...@sharp.fm wrote:

 Hi all,
 
 K.
 
 Regards,
 Graham
 --
 
 
 On 9 Dec 2014, at 10:52, Stephen Connolly stephen.alan.conno...@gmail.com 
 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

2014-11-26 Thread Chris Graham

Nicely worded!

+1

Sent from my iPhone

On 27/11/2014, at 2:16 AM, Paul Benedict pbened...@apache.org 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: Ticket Transition Workflow: Abandoned issues

2014-11-26 Thread Chris Graham

RTC uses Backlog. Does Jira have something similar?

Sent from my iPhone

On 27/11/2014, at 8:13 AM, David Jencks david_jen...@yahoo.com.INVALID 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 pbened...@apache.org 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 micha...@apache.org 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: Abandoned bugs analysis

2014-11-25 Thread 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 pbened...@apache.org 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 micha...@apache.org 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 denn...@apache.org 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 micha...@apache.org:
 
 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?

2014-11-22 Thread 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 chrisgw...@gmail.com 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 javascript:; 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 danro...@gmail.com
 javascript:;
  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 andreas.gud...@gmail.com javascript:;
Subject: Re: New logo?
Date: November 19, 2014 at 12:49:59 PM EST
To: Maven Developers List dev@maven.apache.org javascript:;
   
   
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
  javascript:;
For additional commands, e-mail: dev-h...@maven.apache.org
  javascript:;
   
   
  
 


 --
 Sent from my phone

Re: New logo?

2014-11-21 Thread 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 danro...@gmail.com 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 andreas.gud...@gmail.com
  Subject: Re: New logo?
  Date: November 19, 2014 at 12:49:59 PM EST
  To: Maven Developers List dev@maven.apache.org
 
 
  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

2014-09-16 Thread Chris Graham

Hi Benson,

Perfect! Exactly what I was looking for!

Thanks!

-Chris


On Mon, Sep 15, 2014 at 8:16 PM, Benson Margulies bimargul...@gmail.com
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 chrisgw...@gmail.com
 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 bimargul...@gmail.com
 
  wrote:
 
   A mixture. The release plugin had not moved.
   On Sep 10, 2014 11:46 PM, Chris Graham chrisgw...@gmail.com 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:
[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 
  rfscho...@apache.org
   
wrote:
   
 that's just the beginning...
   
so: how did you execute it? what did you

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

2014-09-14 Thread 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 bimargul...@gmail.com
wrote:

 A mixture. The release plugin had not moved.
 On Sep 10, 2014 11:46 PM, Chris Graham chrisgw...@gmail.com 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:
  [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 
rfscho...@apache.org
 
  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

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

2014-09-10 Thread 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 david_jen...@yahoo.com.INVALID 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) j...@codehaus.org wrote:

[
https://jira.codehaus.org/browse/SCM-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

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

2014-09-10 Thread 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 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
  [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 rfscho...@apache.org
 
  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 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

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

2014-09-10 Thread 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 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:
[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 
  rfscho...@apache.org
   
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 unsubscribe, e-mail: dev

Re: SCM Providers

2014-09-09 Thread 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 rfscho...@apache.org
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

2014-08-28 Thread 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 sly...@us.ibm.com 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]

2014-06-30 Thread Chris Graham

Limit or Restrict...

Sent from my iPhone

On 30/06/2014, at 4:08 PM, Karl Heinz Marbaise khmarba...@gmx.de 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

2014-04-10 Thread Chris Graham



Sent from my iPhone

On 11/04/2014, at 9:23 AM, Barrie Treloar baerr...@gmail.com wrote:

 On 10 April 2014 23:37, Lennart Jörelid lennart.jore...@gmail.com 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?

2014-03-20 Thread 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

2014-03-16 Thread 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 rfscho...@apache.orgwrote:

 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 rfscho...@apache.org
 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 rfscho...@apache.org
 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
 simonetrip...@apache.org:


  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 ListArtifactRepository remoteRepositories;
 http://people.apache.org/~simonetripodi/
 http://twitter.com/simonetripodi


 On Mon, Mar 10, 2014 at 7:09 PM, Robert Scholte rfscho...@apache.org
 
 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

Re: MRELEASE-431

2014-03-15 Thread 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 rfscho...@apache.orgwrote:

 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 rfscho...@apache.org
 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
 simonetrip...@apache.org:


  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 ListArtifactRepository remoteRepositories;
 http://people.apache.org/~simonetripodi/
 http://twitter.com/simonetripodi


 On Mon, Mar 10, 2014 at 7:09 PM, Robert Scholte rfscho...@apache.org
 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
 simonetrip...@apache.org:


  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 rfscho...@apache.org
 wrote:

  Hi Simone,

 I've added a new module for Maven release policies including my idea
 of
 how the API should look like.
 Although one of my suggestions to specify this as an implementation
 in
 the
 plugin configuration, I now prefer to use it as a component. Downside
 is
 that you can't use a pojo, you'll need to add Plexus annotations and
 generate the

Re: MRELEASE-431

2014-03-15 Thread 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 bmat...@batmat.net wrote:

 2014-03-13 19:19 GMT+01:00 Robert Scholte rfscho...@apache.org:

  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: Developing Maven Archetype

2014-03-09 Thread Chris Graham

Generate the archetype from your working source.

Sent from my iPhone

On 10/03/2014, at 8:06 AM, Petar Tahchiev paranoia...@gmail.com 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 bmat...@batmat.net:
 
 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 bimargul...@gmail.com:
 
 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 paranoia...@gmail.com
 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 Batmat 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

2014-02-15 Thread Chris Graham

+1

PS: like your style mark!

-Chris

Sent from my iPhone

On 16/02/2014, at 2:11 PM, Mark Derricutt m...@talios.com 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

2014-02-12 Thread 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 aherit...@gmail.com 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 m...@talios.com 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)

2013-12-14 Thread 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 rfscho...@apache.orgwrote:

 +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

 herve.bout...@free.fr:
  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 herve.bout...@free.fr
 
  wrote:
 Le mardi 10 décembre 2013 01:05:30 Michael-O a écrit :
 Am 2013-12-10 00:58, schrieb Hervé BOUTEMY:
  content${project.build.directory}/staging/${maven.site.path}/co
 
  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.
   
I'm not sure I have a preference since its been so long since I
 last
did a release.
   
I definitely want to follow the instructions so that I dont stuff
something
up. Which would make me lean to unified instructions to make it
 
  easier
 
to
update the instructions when necessary.
   
Do we have any metrics on how many mono- to multi- module builds
 we
have?
 
  -
 
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:

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

2013-12-09 Thread 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 m...@talios.com 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 m...@talios.com 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

2013-11-27 Thread Chris Graham

On Wed, Nov 27, 2013 at 5:49 PM, Mirko Friedenhagen mfriedenha...@gmail.com
 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?

2013-11-12 Thread 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 rmannibu...@gmail.com 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 nhoj.patr...@gmail.com 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 bimargul...@gmail.com 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: Do releases _really_ need to be built with Java 1.5?

2013-11-12 Thread Chris Graham

The client in question is using Oracle's CCB (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 CCB 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 lennart.jore...@gmail.com
 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 chrisgw...@gmail.com

  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 rmannibu...@gmail.com
  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 nhoj.patr...@gmail.com 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 bimargul...@gmail.com
  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: What is the top level of the source tree and what exactly is an Apache distribution?

2013-09-16 Thread 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 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 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 16:57 surefire-2.16/LICENSE
178 08-11-13 16:57 surefire-2.16/NOTICE

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

2013-09-16 Thread 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 chrisgw...@gmail.com 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 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

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

2013-09-15 Thread Chris Graham

On Sun, Sep 15, 2013 at 3:24 AM, Jason van Zyl ja...@tesla.io 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?

2013-09-04 Thread 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 ?xml version=\1.0\ encoding=\UTF-8\?  runtime-library.pom
echo project xmlns=\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 modelVersion4.0.0/modelVersion  runtime-library.pom
echo groupId$groupId/groupId  runtime-library.pom
echo artifactIdruntime-library/artifactId  runtime-library.pom
echo version$version/version  runtime-library.pom
echo packagingpom/packaging  runtime-library.pom
echo descriptionLibrary POM for the $groupId v$version
runtime./description  runtime-library.pom
echo dependencies  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 dependency  runtime-library.pom
  echo groupId$groupId/groupId  runtime-library.pom
  echo artifactId$artifactId/artifactId 
runtime-library.pom
  echo version$version/version  runtime-library.pom
  echo /dependency  runtime-library.pom

done

echo /dependencies  runtime-library.pom
echo /project  runtime-library.pom

echo Done.



On Wed, Sep 4, 2013 at 1:32 PM, Wayne Fay wayne...@gmail.com 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 dependency 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?

2013-09-01 Thread Chris Graham

On Sun, Sep 1, 2013 at 8:21 PM, Hervé BOUTEMY herve.bout...@free.fr 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 herve.bout...@free.fr
 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:
   developerConnectionscm:git:
   [fetch=]
  
 http://mywebserver.org/path_to_repository[push=]ssh://username@otherserver
   :8898/~/repopath.git /developerConnection
  
   in the same spirit, we could support a branch and a path parts
   developerConnectionscm:git:
  
 https://git-wip-us.apache.org/repos/asf/maven.git[branch=]maven-3.0.x[path
   =]/maven-core /developerConnection
  
   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?

2013-08-31 Thread 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 herve.bout...@free.frwrote:

 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:
 developerConnectionscm:git:
 [fetch=]
 http://mywebserver.org/path_to_repository[push=]ssh://username@otherserver:8898/~/repopath.git
 /developerConnection

 in the same spirit, we could support a branch and a path parts
 developerConnectionscm:git:
 https://git-wip-us.apache.org/repos/asf/maven.git[branch=]maven-3.0.x[path=]/maven-core
 /developerConnection

 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

2013-08-15 Thread 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
joerg.schai...@scalaris.comwrote:

 Hi Oliver,

 Olivier Lamy wrote:

  On 15 August 2013 08:53, sebb seb...@gmail.com wrote:
  On 14 August 2013 21:21, Dennis Lundberg denn...@apache.org wrote:
  On Wed, Aug 14, 2013 at 10:47 AM, sebb seb...@gmail.com wrote:
 
  On 13 August 2013 18:58, Dennis Lundberg denn...@apache.org wrote:
   On Tue, Aug 13, 2013 at 12:30 AM, sebb seb...@gmail.com wrote:
   On 12 August 2013 20:10, Jason van Zyl ja...@tesla.io 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: [VOTE] Release Apache Maven Model Converter version 2.3

2013-08-15 Thread Chris Graham



Sent from my iPhone

On 15/08/2013, at 10:05 PM, sebb seb...@gmail.com wrote:

 On 15 August 2013 10:08, Chris Graham chrisgw...@gmail.com 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: Strange handling of + in version portion of GAV

2013-08-01 Thread 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

2013-07-28 Thread 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 rfscho...@apache.org 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 ja...@tesla.io:
 
 On Jul 28, 2013, at 12:25 PM, Hervé BOUTEMY herve.bout...@free.fr 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)

2013-07-25 Thread 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=1506778r1=1506777r2=1506778view=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.
* !-- TODO: get the rest of these --

+ 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

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

2013-07-23 Thread 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 ol...@apache.org wrote:

 +1

 2013/7/23 Stephen Connolly stephen.alan.conno...@gmail.com:
  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

SCM Providers

2013-07-23 Thread 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: Maven 3.1 - Stable ?

2013-07-22 Thread Chris Graham

+1

Sent from my iPhone

On 20/07/2013, at 11:28 AM, Paul Benedict pbened...@apache.org 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 pbened...@apache.orgwrote:
 
 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 herve.bout...@free.frwrote:
 
 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 herve.bout...@free.fr
 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 herve.bout...@free.fr 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

2013-07-19 Thread Chris Graham

+1 (non-binding)


On Sat, Jul 20, 2013 at 6:11 AM, Baptiste Mathus bmat...@gmail.com wrote:

 +1 (non binding)
 Le 19 juil. 2013 21:45, Anders Hammar and...@hammar.net a écrit :

  +1, non-binding
 
  /Anders (mobile)
  Den 19 jul 2013 19:01 skrev Dennis Lundberg denn...@apache.org:
 
   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

1 2 3 4 >

1 - 100 of 315 matches

Mail list logo