Re: Mentor Request

[Barrie Treloar]

On 24 July 2016 at 18:34, Rajiv Jain  wrote:

> Not really. I don't mind. Basically, where help is needed and important
> features/improvements/fixes need to
>

The [Guide to helping with Maven]{
http://maven.apache.org/guides/development/guide-helping.html} has all the
information you need to start picking out ideas to start working on.

But you will need [an itch to scratch]{
http://www.catb.org/esr/writings/homesteading/cathedral-bazaar/ar01s02.html},
without it you won't have the energy to keep going.

So, is your $dayjob using Java with Maven? Are they having problems that
need addressing? Look to see if those have issues raised already and pick
one to work on.

If there aren't specific enhancements/fixes that your projects need, then
look at which bits of Maven they use and then browse the issues for those
areas and see if anything takes your interest.
Based on which area you pick different people will have more knowledge to
share. Create a new email on the dev list and/or comment on the issue.

Alternatively, what is your area of Java expertise? Look through the issue
log to see where it could be applied.

Lastly, documentation still needs more work. As you use Maven, if you can't
find the information that you need then create it so the next person
doesn't have that pronlem.

Re: Mentor Request

[Barrie Treloar]

On 23 July 2016 at 20:48, Rajiv Jain  wrote:

> Hi
>
> My name is Rajiv and I am interested in working with the development of
> Apache Maven. I have recently started making contributions though Pull
> requests and would like to contribute to Apache Maven. I believe Apache
> Maven is in active development.
>
> I saw the Mentoring Programme on the Apache website. I can contribute
> around 10 hours per week on issues/bugs/improvements or whatever is needed.
>
> Could someone please become my mentor?


Do you have a preferred area of Maven that is of interested to ou?

Re: [VOTE] Retire Maven Eclipse Plugin / Donation to Mojohaus

[Barrie Treloar]

On 4 October 2015 at 19:48, Robert Scholte  wrote:

> Hi,
>
> during the latest upgrade of the plugin-parent I faced several issues with
> the maven-eclipse-plugin.
> It will take quite some time to fix these issues, but is it worth
> maintaining it here?
> Nowadays the Maven support for Eclipse is good and stable.
> The maven-eclipse-plugin has a lot of integration tests which should be
> rewritten, because it always launches a new Maven fork and it takes ages to
> complete. This simply blocks good continuous integration of the plugins.
> I know there are still some projects with can't use the Maven Integration
> of Eclipse and depend on this plugin, so the sources need to stay available
> for users so the can extend it for their own usage.
>
> I therefor propose that we retire maven-eclipse-plugin for the Apache
> Maven project and donate it to the Mojohaus project
>
> 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.
>
> The process for retiring a plugin is described here:
> http://maven.apache.org/developers/retirement-plan-plugins.html
>
> The vote is open for 72 hours.
>
> [ ] +1 Yes, it's about time
> [ ] -1 No, because...


 +1
It needs a new home where people can give it some love if they want to
maintain it.

Re: Full migration to Git

[Barrie Treloar]

On 3 June 2015 at 18:14, Kristian Rosenvold 
wrote:

> FYI; I am setting up a full copy of asf svn (just 65GB) and will be trying
> some imports once this is ready
>

How did this go?

Re: preparing Maven Parent POM version 27

[Barrie Treloar]

On 9 September 2015 at 16:02, Anders Hammar  wrote:

> Yes! Didn't we already decide on this? Or was it Java 7 even?
>

Didn't we also write the decision down somewhere too?

I think
https://maven.apache.org/developers/java5.html
https://maven.apache.org/developers/java6.html

And something about which versions of Maven support which verisons of Java.
But I can't find that on the website, its probably in the email archives
somewhere.

Re: Full migration to Git

[Barrie Treloar]

Where are we at with this?

I know enough to be dangerous - but not useful.
And I need to the same migration at work (we've been contemplating moving
off SVN for over 18 months but hey...)

So learning how to do this and applying that knowledge on the Maven
repositories is a benefit, but I am struggling to find anything that
details the "whys" of doing things in particular ways.
Its often just the scripts and the results.

I'm happy to read if someone has links.

Or be baby sat/mentored through a migration.

s/Git/SCM "magic" checkout - Needs your help to test and eyeball the code

[Barrie Treloar]

http://maven.40175.n5.nabble.com/Git-as-the-canonical-SCM-td5719980.html#a5720106

Wow, 3 years ago and almost on its anniversary...

Many years ago there was talk about a "magic" plugin that would help you
checkout the "vertical" stack of a plugin and its been an itch I've been
meaning to scratch.

After investigation the SCM plugin checkout goal is very close to providing
this functionality. By frankensteining versions-maven-plugin and the next
snapshot number scheme from release-maven-plugin creating this features was
not too difficult.

I've not yet got around to learning how to use apache's git for committer
access, and I didn't want to pollute the current code base just yet, so
I've hacked this over at github.

Please have a look at
https://github.com/baerrach/maven-scm/tree/bt-magic-checkout

and let me know if it works as you would expect.

Things I'm not sure about:
* bolting this on to scm:checkout (I think its appropriate)
* using -DartifactCoords instead of -DGAV
* detailed enough documentation
*
https://maven.apache.org/guides/introduction/introduction-to-plugin-prefix-mapping.html
support
* Proper handling of pom files, ala
https://maven.apache.org/plugin-developers/common-bugs.html#Reading_and_Writing_Text_Files
* whether I've duplicate code that exists somewhere else that should be
used instead.

Cheers
Barrie

Re: Maven invoker plugin, addTestClassPath failing, but manually adding as dependency works

[Barrie Treloar]

On 5 September 2015 at 17:35, Robert Scholte <rfscho...@apache.org> wrote:

> Op Sat, 05 Sep 2015 08:56:09 +0200 schreef Barrie Treloar <
> baerr...@gmail.com>:
>
> I'm using the invoker plugin to test the mojo I'm hacking.
>>
>> I had assumed that the mojo's classpath would be available to invoker, but
>> when I print out the classpath that doesn't appear to be the case.
>>
>
> "the mojo"? the mojo you are testing? No, that's just a standalone mojo.
> m-invoker-p just triggers it, it has no knowledge of the mojo it is
> executing. That's one of the reasons why MINVOKER-154 is still open.
>
>
Yes, the mojo I am testing with invoker.
I'm really just after some of the helper classes that are on the classpath
of the mojo.
Seems silly to rewrite verbosely how to read a pom and create a model and a
MavenProject.

I've tried the addTestClassPath option but then I'm getting
>> groovy.lang.GroovyRuntimeException: Failed to create Script instance for
>> class: class Script1. Reason: java.lang.ClassCastException: Script1 cannot
>> be cast to groovy.lang.GroovyObject
>>
>
> Already if you set addTestClassPath to true? Any chance you specified a
> different verion of groovy somewhere?
>

No groovy anywhere.
Only via invoker.


>
>> Which looks a bit like https://issues.apache.org/jira/browse/MINVOKER-112
>> .
>>
>> If I add in the dependency directly to the maven-invoker-plugin then I can
>> keep working.
>>
>> What's the correct way?
>>
>
> The preferred way right now is adding the dependency as test-scoped to the
> maven-invoker-plugin. This should make it available for the scripts. I
> still want to support custom scopes for plugin dependencies, so you can
> easily specify when to use which dependency.


I've just used the default scope when adding the dependency to
maven-invoker-plugin, which works for me too.

I was trying to be lazy and just get the kitchen sink since I knew the
helper classes were already on my mojo's classpath. I didn't want to work
out which bits I actually needed :)

Maven invoker plugin, addTestClassPath failing, but manually adding as dependency works

[Barrie Treloar]

I'm using the invoker plugin to test the mojo I'm hacking.

I had assumed that the mojo's classpath would be available to invoker, but
when I print out the classpath that doesn't appear to be the case.

I've tried the addTestClassPath option but then I'm getting
groovy.lang.GroovyRuntimeException: Failed to create Script instance for
class: class Script1. Reason: java.lang.ClassCastException: Script1 cannot
be cast to groovy.lang.GroovyObject

Which looks a bit like https://issues.apache.org/jira/browse/MINVOKER-112.

If I add in the dependency directly to the maven-invoker-plugin then I can
keep working.

What's the correct way?

Re: Writing poms from mojos

[Barrie Treloar]

On 3 September 2015 at 20:49, Igor Fedorenko  wrote:

> Like I mentioned earlier, tycho-versions-plugin
>

Thanks, and especially for the link into the source file. That save me
effort.

I saw Tycho earlier and read m2eclipse.
oops.

Re: Writing poms from mojos

[Barrie Treloar]

On 4 September 2015 at 02:49, Daniel Kulp  wrote:

>
> The shade plugin can also create a “dependency reduced” pom.


Thanks.

The dependency reduced pom is completely regenerated by
MavenJDOMWriter.updateModel and doesn't attempt to keep any of the original
pom's formatting. It uses jdom to generate the xml.

Re: Writing poms from mojos

[Barrie Treloar]

There are ~3000 plugins in Maven Central (
http://search.maven.org/#search|ga|1|p%3A%22maven-plugin%22). My eyes
glazed over after scanning through the first 100 to see if there are plugin
names to indicate if they might re-write poms.

So I'll stick with the available plugins list (
http://maven.apache.org/plugins/) and it looks like the only plugins that
modify the pom are:
* release
* versions

I've also looked at m2eclipse (https://github.com/eclipse/m2e-core.git) to
see how it rewrites poms. m2eclipse can get away with working with the
Eclipse provided StructuredModels to grab a dom version of the editor and
just rewrite that one section, knowing that it doesn't need to rewrite the
whole file.

The Maven plugins on the other hand need to stream in the file and preserve
all the kooky white space and commenting, as well as update just the
sections they want to modify.

The release plugin uses org.jdom.Element to manipulate rewrites, and
org.jdom.output.XMLOutputter with a raw formatter to write the pom file out.

The versions plugin uses StringBuilder as an in memory copy of the pom file
and the StAX2 api to manipulate rewrites, and an XmlStreamWriter to write
the pom file out.

Have I missed any plugins?

For such a small number of plugins that need to make rewrites it probably
not necessary to have this functionality offered in Maven directly...

Re: Writing poms from mojos

[Barrie Treloar]

tidy-maven-plugin (https://github.com/mojohaus/tidy-maven-plugin) works
similar to versions plugin.

It uses a String copy of pom and for the non-trivial tidy tasks an
XMLEventReader from StAX api to manipulate rewrites, and
plexus.util.FileUtils.fileWrite to write the pom file out.

Re: Writing poms from mojos

[Barrie Treloar]

I've just looked at versions-maven-plugin, where a custom XMLEventReader
(ModifiedPomXMLEventReader) is used to rebuild the pom file.

A custom class is used because
StAX API (JSR-173) are not good round-trip rewriting bwhile/b keeping
all unchanged bytes in the file as is.  For example, the StAX API specifies
that codeCR/code characters will be stripped.  Current implementations
do not keep quot; and apos; characters consistent.

Re: Writing poms from mojos

[Barrie Treloar]

So, I'm sensing that rewriting the pom is a free-for-all and not something
we do through a Maven API.

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

[Barrie Treloar]

On 27 August 2015 at 05:02, Hervé Boutemy (JIRA) j...@apache.org wrote:


  Say you have this project structure:
  {noformat}
  /
|-- module1
|-- module2
  {noformat}
  and artifactIds are named:
  {noformat}
  my-parent
|-- my-module1
|-- my-module2
  {noformat}
  Prefix {{my-}} is omitted for brevity in module names. For instance,
 Jersey does that.
  When the SCM report is built, the artifactId is always used for path
 composition which leads to incorrect URLs. You can of course set the
 parameter {{checkoutDirectoryName}} but this would be extremely tedious for
 all modules down the tree.
  The code should obtain the module name and use it for URL composition.


Is this a feature or a bug of Maven?

I've always named my modules == artifactId because of this problem in lots
of of other places.

Is module name really allowed to be different to the artifactId?

Writing poms from mojos

[Barrie Treloar]

The release plugin has AbstractRewritePomsPhase which uses a lot of private
methods to do its work.

Is there a more utilitarian way of writing a pom?

I really only need to fiddle with a couple of values in an existing pom
(keeping whitespaces/formatting/etc) and re-write it.

Re: Writing poms from mojos

[Barrie Treloar]

On 26 August 2015 at 20:41, Robert Scholte rfscho...@apache.org wrote:

 depending on what you want, maybe flattened-maven-plugin[1] can come to
 the rescue.


I need the mojo I am hacking to rewrite the pom's to bend to my will.

I'm probably a week away from having a working git magic plugin working.

Re: Writing poms from mojos

[Barrie Treloar]

On 26 August 2015 at 20:10, Robert Scholte rfscho...@apache.org wrote:

 I still have this wish to replace the JDom implementation with Woodstox,
 so all kinds of dirty tricks can be removed.
 I would gamble on that approach.


I can't wait :)

My itch is already burning so I'll live with the damned version now.

I think I can repurpose the release plugins AbstractRewritePomsPhases :)
But I've yet to attempt that hackery.

Interpolation with no pom leaves ${project.basedir} unresolved

[Barrie Treloar]

In the mojo there is a Property with a default value of
${project.build.directory}/checkout

When maven is run in a directory with a pom, this will get interpolated as
/full/path/to_directory_with_pom_file/target

When maven is run in a directory without a pom, this will get interpolated
to
${project.basedir}/target

Why isn't ${project.basedir} expanded to the current working directory?

Re: maven-remote-resources-plugin downloads from disabled repositories

[Barrie Treloar]

You can see that the snapshot repos are disabled in the configuration of
the mojo.
Yet snapshots get downloaded.


[DEBUG] Configuring mojo
org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process from
plugin realm
ClassRealm[pluginorg.apache.maven.plugins:maven-remote-resources-plugin:1.5,
parent: sun.misc.Launcher$AppClassLoader@330bedb4]
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process' with
basic configurator --
[DEBUG]   (f) appendedResourcesDirectory =
/Users/barrie/ide/maven/maven-scm/maven-scm-plugin/src/main/appended-resources
[DEBUG]   (f) attachToMain = true
[DEBUG]   (f) attachToTest = true
[DEBUG]   (f) attached = true
[DEBUG]   (f) basedir = /Users/barrie/ide/maven/maven-scm/maven-scm-plugin
[DEBUG]   (f) encoding = UTF-8
[DEBUG]   (f) excludeTransitive = false
[DEBUG]   (f) includeProjectProperties = false
[DEBUG]   (f) includeScope = runtime
[DEBUG]   (f) localRepository =   id: local
  url: file:///Users/barrie/.m2/repository/
   layout: default
snapshots: [enabled = true, update = always]
 releases: [enabled = true, update = always]

[DEBUG]   (f) outputDirectory =
/Users/barrie/ide/maven/maven-scm/maven-scm-plugin/target/maven-shared-archive-resources
[DEBUG]   (f) remoteArtifactRepositories = [  id: central
  url: https://repo.maven.apache.org/maven2
   layout: default
snapshots: [enabled = false, update = never]
 releases: [enabled = true, update = daily]
,   id: apache.snapshots
  url: https://repository.apache.org/content/groups/snapshots-group
   layout: default
snapshots: [enabled = false, update = never]
 releases: [enabled = false, update = never]
]
[DEBUG]   (f) resourceBundles = [org.apache:apache-jar-resource-bundle:1.4]
[DEBUG]   (f) resources = [Resource {targetPath: null, filtering: false,
FileSet {directory:
/Users/barrie/ide/maven/maven-scm/maven-scm-plugin/src/main/resources,
PatternSet [includes: {}, excludes: {}]}}]
[DEBUG]   (f) runOnlyAtExecutionRoot = false
[DEBUG]   (f) skip = false
[DEBUG]   (f) useDefaultFilterDelimiters = true
[DEBUG]   (f) mavenSession =
org.apache.maven.execution.MavenSession@7728643a
[DEBUG]   (f) project = MavenProject:
org.apache.maven.plugins:maven-scm-plugin:1.9.5-SNAPSHOT @
/Users/barrie/ide/maven/maven-scm/maven-scm-plugin/pom.xml
[DEBUG] -- end configuration --
[DEBUG] Initializing Velocity, Calling init()...
[DEBUG] ***
[DEBUG] Starting Apache Velocity v1.7 (compiled: 2010-11-19 12:14:37)
[DEBUG] RuntimeInstance initializing.
[DEBUG] Default Properties File:
org/apache/velocity/runtime/defaults/velocity.properties
[DEBUG] Default ResourceManager initializing. (class
org.apache.velocity.runtime.resource.ResourceManagerImpl)
[DEBUG] ResourceLoader instantiated:
org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
[DEBUG] ResourceCache: initialized (class
org.apache.velocity.runtime.resource.ResourceCacheImpl) with class
java.util.Collections$SynchronizedMap cache map.
[DEBUG] Default ResourceManager initialization complete.
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Stop
[DEBUG] Loaded System Directive:
org.apache.velocity.runtime.directive.Define
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Break
[DEBUG] Loaded System Directive:
org.apache.velocity.runtime.directive.Evaluate
[DEBUG] Loaded System Directive:
org.apache.velocity.runtime.directive.Literal
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Macro
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Parse
[DEBUG] Loaded System Directive:
org.apache.velocity.runtime.directive.Include
[DEBUG] Loaded System Directive:
org.apache.velocity.runtime.directive.Foreach
[DEBUG] Velocimacro : initialization starting.
[DEBUG] Velocimacro : velocimacro.library is not set.  Trying default
library: VM_global_library.vm
[DEBUG] Velocimacro : Default library not found.
[DEBUG] Velocimacro : allowInline = true : VMs can be defined inline in
templates
[DEBUG] Velocimacro : allowInlineToOverride = false : VMs defined inline
may NOT replace previous VM definitions
[DEBUG] Velocimacro : allowInlineLocal = false : VMs defined inline will be
global in scope if allowed.
[DEBUG] Velocimacro : autoload off : VM system will not automatically
reload global library macros
[DEBUG] Velocimacro : Velocimacro : initialization complete.
[DEBUG] RuntimeInstance successfully initialized.
[DEBUG] Supplemental data models won't be loaded.  No models specified.
[DEBUG]
org.apache.maven.plugins:maven-scm-plugin:maven-plugin:1.9.5-SNAPSHOT
(selected for null)

   ... [del] ...

[DEBUG] Building project for
org.apache.maven.scm:maven-scm-provider-cvsexe:jar:1.9.5-SNAPSHOT:runtime
[DEBUG] Skipped remote request for
org.apache.maven.scm:maven-scm-providers-cvs:1.9.5-SNAPSHOT/maven-metadata.xml,
locally cached metadata up-to-date.
[DEBUG] Using transporter WagonTransporter 

Re: Interpolation with no pom leaves ${project.basedir} unresolved

[Barrie Treloar]

On 26 August 2015 at 03:11, Hervé BOUTEMY herve.bout...@free.fr wrote:

 see interpolation documentation in [1]

 and ModelInterpolator javadoc [2]
 projectDir - The project directory, may be null if the model does not
 belong
 to a local project but to some artifact's metadata.


Thanks. I didn't know about them.

I sorted the problem out a different way - I was trying to have two default
values depending on context which parameter injection doesn't help with. So
instead the default values are set in code and the parameter is left as
null. Much easier to determine if a value was provided or not will null.

Re: maven-remote-resources-plugin downloads from disabled repositories

[Barrie Treloar]

On 24 August 2015 at 14:09, Barrie Treloar baerr...@gmail.com wrote:



 On 23 August 2015 at 23:24, Karl Heinz Marbaise khmarba...@gmx.de wrote:

 mvn -pl maven-scm-plugin clean package


 I'm trying -pl project now.

 Something is going wrong in that its using an old version of the
 snapshot... and I need to work out why.


It's unrelated.

The maven-scm-plugin src/it/settings.xml used by
maven-plugin-testing-harness did not have an updatePolicy, hence using the
default daily instead of always.

It also has apache.snapshots (
http://people.apache.org/repo/m2-snapshot-repository) defined as a
repository (but not for pluginRepository), and has it enabled. With it
disabled the tests stop trying to overwrite my local changes with deployed
snapshots.

Re: maven-remote-resources-plugin downloads from disabled repositories

[Barrie Treloar]

Martin, I'd tried this but it still seems to pull down the new snapshots

profile
  idcentral/id
  repositories
repository
  idcentral/id
  urlhttps://repo.maven.apache.org/maven2/url
  snapshots
enabledfalse/enabled
updatePolicynever/updatePolicy
  /snapshots
/repository
repository
  idapache.snapshots/id
  urlhttps://repository.apache.org/content/groups/snapshots-group
/url
  releases
enabledfalse/enabled
updatePolicynever/updatePolicy
  /releases
  snapshots
enabledfalse/enabled
updatePolicynever/updatePolicy
  /snapshots
/repository
  /repositories
  pluginRepositories
pluginRepository
  idcentral/id
  urlhttps://repo.maven.apache.org/maven2/url
  snapshots
enabledfalse/enabled
updatePolicynever/updatePolicy
  /snapshots
/pluginRepository
pluginRepository
  idapache.snapshots/id
  urlhttps://repository.apache.org/content/groups/snapshots-group
/url
  releases
enabledfalse/enabled
updatePolicynever/updatePolicy
  /releases
  snapshots
enabledfalse/enabled
updatePolicynever/updatePolicy
 /snapshots
/pluginRepository
  /pluginRepositories
/profile
..
  activeProfiles
activeProfilecentral/activeProfile
  /activeProfiles

Re: maven-remote-resources-plugin downloads from disabled repositories

[Barrie Treloar]

On 23 August 2015 at 23:24, Karl Heinz Marbaise khmarba...@gmx.de wrote:

mvn -pl maven-scm-plugin clean package


I'm trying -pl project now.

Something is going wrong in that its using an old version of the
snapshot... and I need to work out why.

maven-remote-resources-plugin downloads from disabled repositories

[Barrie Treloar]

I'm tinkering with maven-scm and when I build it locally via
 ../maven-scm/maven-scm-plugin mvn -X clean install -Drat.skip

Maven attempts to download the snapshot metadata for it's the already
installed snapshot files. (This is probably because I'm running inside a
module and not at the top level)

I've attempted to disable apache.snapshots in settings.xml as I dont want
any snapshot I haven't built myself.

The configuration debugs indicate that the repositories are are disabled -
but Maven still attempts to get the metadata. It looks like
maven-remote-resources-plugin is the culprit.

Does anyone else see this?

I've only recently re-setup my Mac to cut code, so its possible I've not
got something configured correctly.

 mvn -v
Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1;
2014-12-15T03:59:23+10:30)
Maven home: /usr/local/Cellar/maven/3.2.5/libexec
Java version: 1.6.0_65, vendor: Apple Inc.
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: en_US, platform encoding: MacRoman
OS name: mac os x, version: 10.9.5, arch: x86_64, family: mac

The debug output:

[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process' with
basic configurator --
[DEBUG]   (f) appendedResourcesDirectory =
/Users/barrie/ide/maven/maven-scm/maven-scm-plugin/src/main/appended-resources
[DEBUG]   (f) attachToMain = true
[DEBUG]   (f) attachToTest = true
[DEBUG]   (f) attached = true
[DEBUG]   (f) basedir = /Users/barrie/ide/maven/maven-scm/maven-scm-plugin
[DEBUG]   (f) encoding = UTF-8
[DEBUG]   (f) excludeTransitive = false
[DEBUG]   (f) includeProjectProperties = false
[DEBUG]   (f) includeScope = runtime
[DEBUG]   (f) localRepository =   id: local
  url: file:///Users/barrie/.m2/repository/
   layout: default
snapshots: [enabled = true, update = always]
 releases: [enabled = true, update = always]

[DEBUG]   (f) outputDirectory =
/Users/barrie/ide/maven/maven-scm/maven-scm-plugin/target/maven-shared-archive-resources
[DEBUG]   (f) remoteArtifactRepositories = [  id: central
  url: https://repo.maven.apache.org/maven2
   layout: default
snapshots: [enabled = false, update = never]
 releases: [enabled = true, update = daily]
,   id: apache.snapshots
  url: https://repository.apache.org/content/groups/snapshots-group
   layout: default
snapshots: [enabled = false, update = never]
 releases: [enabled = false, update = never]
]
[DEBUG]   (f) resourceBundles = [org.apache:apache-jar-resource-bundle:1.4]
[DEBUG]   (f) resources = [Resource {targetPath: null, filtering: false,
FileSet {directory:
/Users/barrie/ide/maven/maven-scm/maven-scm-plugin/src/main/resources,
PatternSet [includes: {}, excludes: {}]}}]
[DEBUG]   (f) runOnlyAtExecutionRoot = false
[DEBUG]   (f) skip = false
[DEBUG]   (f) useDefaultFilterDelimiters = true
[DEBUG]   (f) mavenSession = org.apache.maven.execution.MavenSession@569c6f2
[DEBUG]   (f) project = MavenProject:
org.apache.maven.plugins:maven-scm-plugin:1.9.5-SNAPSHOT @
/Users/barrie/ide/maven/maven-scm/maven-scm-plugin/pom.xml
[DEBUG] -- end configuration --

...

[DEBUG]
org.apache.maven.scm:maven-scm-provider-svntest:jar:1.9.5-SNAPSHOT:test
(selected for test)
[DEBUG] org.apache.maven.scm:maven-scm-test:jar:1.9.5-SNAPSHOT:test
(selected for test)
[DEBUG] Building project for
org.apache.maven.scm:maven-scm-manager-plexus:jar:1.9.5-SNAPSHOT:compile
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
https://repository.apache.org/content/groups/snapshots-group/
[DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for
https://repository.apache.org/content/groups/snapshots-group/
Downloading:
https://repository.apache.org/content/groups/snapshots-group/org/apache/maven/scm/maven-scm-managers/1.9.5-SNAPSHOT/maven-metadata.xml
[DEBUG] Writing tracking file
/Users/barrie/.m2/repository/org/apache/maven/scm/maven-scm-managers/1.9.5-SNAPSHOT/resolver-status.properties
[WARNING] Could not transfer metadata
org.apache.maven.scm:maven-scm-managers:1.9.5-SNAPSHOT/maven-metadata.xml
from/to apache.snapshots (
https://repository.apache.org/content/groups/snapshots-group/):
java.lang.RuntimeException: Could not generate DH keypair
org.eclipse.aether.transfer.MetadataTransferException: Could not transfer
metadata
org.apache.maven.scm:maven-scm-managers:1.9.5-SNAPSHOT/maven-metadata.xml
from/to apache.snapshots (
https://repository.apache.org/content/groups/snapshots-group/):
java.lang.RuntimeException: Could not generate DH keypair

I'm ignoring the known error with DH crypto problems - I just want it to
not try to download snapshots...

single string GAV exploding as a utility method somewhere in Maven?

[Barrie Treloar]

Is there somewhere in the Maven code that we handle a single string as a
GAV that can get exploded correctly for Artifact resolving?

The dependency:get does it manually, and I'm loathe to copy-and-paste.

How to determine which git repo MAven plugins reside in (was [ANN] 2015 Committer School for people who want to become Maven Committers)

[Barrie Treloar]

This is a good question.

Normally, I'd look at the jira project which would link back to the Maven
project web pages.

The summary jira page
https://issues.apache.org/jira/browse/MNG?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel
doesn't describe MNG components well enough to find them.

The summary pages for each component doesn't link to a Maven project web
page.

If you select any issue, and then its Activity tab, you might get lucky and
get a Hudson notification.
And in the Hudson job you can find the git url in the Git Polling Log page.

In this case https://git-wip-us.apache.org/repos/asf/maven.git which is all
Maven Core.

I'm behind an NTLM firewall at work so I've avoided working with git and
Maven.
Hopefully someone else can provide an answer, and then we can update the
documentation to better reflect that.


-- Forwarded message --
From: Benjamin Chylla ejbga...@gmail.com
Date: 6 August 2015 at 00:53
Subject: Re: [ANN] 2015 Committer School for people who want to become
Maven Committers
To: Maven Developers List dev@maven.apache.org


Hello,

I have a question. I am trying to use Git in order to work with the source
code in the Maven Respository. When I find a Maven project issue on JIRA,
how do I determine which GitHub repository to make a fork of?

From my understanding, https://git-wip-us.apache.org/repos/asf/maven.git is
the location of the main git repository for Maven, but there is also a
separate repository for the integration tests for the Maven core (https:
//git-wip-us.apache.org/repos/asf/maven-integration-testing.git), as well
as other components (Archetype, Indexer, Plugin Testing, SCM, Surefire, and
Wagon).

For example, one of the open JIRA issues that I am interested in working on
has the following components listed: Embedding
https://issues.apache.org/jira/browse/MNG/component/12325608, General
https://issues.apache.org/jira/browse/MNG/component/12325623, Logging
https://issues.apache.org/jira/browse/MNG/component/12325605,Performance
https://issues.apache.org/jira/browse/MNG/component/12325616, Reactor and
workspace https://issues.apache.org/jira/browse/MNG/component/12325615.
There are two other issues that I am interested in; one displays
Dependencies after Component/s, while the other displays None.

I would also like to know whether the Affects Version/s section is
important. I am using Maven 3.3.3 on my machine. Is it important to use a
version of Maven that closely matches the affected version?

[ANN] 2015 Committer School for people who want to become Maven Committers

[Barrie Treloar]

It's time for the yearly committer school announcement.

If your company uses Maven, wouldn't it be good to convince them to spend
some of your time helping to make Maven better for them (and every one
else)?

If you use Maven, which of your itches do you think need scratching the
most? Find some spare time to make Maven a better tool.

Do you have knowledgeable non-technical people that could help contribute
too? Writing the documentation in a coherent way targetted to the specific
need of the user's skill level is hard. Ask you company to kick in by
assigning some talent to make understanding things better.

Read Stephen's blog post
http://javaadventure.blogspot.ie/2012/07/do-you-want-to-become-maven-committer.html
and let us know.

Re: Jira access for new committer

[Barrie Treloar]

On 24 June 2015 at 07:27, Manfred Moser manf...@simpligility.com wrote:


 Hello all,

 Thanks to your support I am now a new committer and would like to get the
 ball rolling. I have subscribed to all the mailing lists and followed the
 various ASF committer/developer docs.

 I have also done my first SVN commit adding myself to the Maven parent as
 requested...

 Now one thing I have not seen documented anywhere is how JIRA setup works.
 It seems like no single sign on to JIRA is set up or at least I am missing
 how that is supposed to work.

 I already have an account and e.g. created
 https://issues.apache.org/jira/browse/MNGSITE-241 with it. However as a
 committer I would like to be able to close issues, assign issues to myself
 and so on.

 Anyone know what I have to do to either get the simpligility account
 configured with more access rights (adding some roles) so I can manage
 manage JIRA issue for site, plugins, core and so on or otherwise how to
 access an account linked to my new mmo...@apache.org account.


Now that we are on Apache infrastructure any instructions that existed will
be out of date and needing some love and attention.

Re: Maven site issues

[Barrie Treloar]

On 24 June 2015 at 07:28, Manfred Moser manf...@simpligility.com wrote:

 Hi again,

 I would like to clean up the issues for the Maven site by going through and
 closing old ones or applying any changes I find useful. Provided I get my
 JIRA setup working .. am I okay to proceed on this?


You have the commit bit, you are free to progress.
If you think there is anything controversial in what you plan to do then
pinging the list to ask for advice/comments/suggestions would be good.

But otherwise, yes please, go for it!

Re: Jira access for new committer

[Barrie Treloar]

On 24 June 2015 at 07:27, Manfred Moser manf...@simpligility.com wrote:

 Anyone know what I have to do to either get the simpligility account
 configured with more access rights (adding some roles) so I can manage
 manage JIRA issue for site, plugins, core and so on or otherwise how to
 access an account linked to my new mmo...@apache.org account.


This is something the PMC need to do, and I think that is Brian Fox, for
configuring your permissions.

The onboarding process needs some better documentation.

Re: Jira access for new committer

[Barrie Treloar]

I've pinged Brian to have a look.

Re: Full migration to Git

[Barrie Treloar]

On 30 May 2015 at 21:29, Jason van Zyl ja...@takari.io wrote:

 Nothing will give me greater joy than removing the last traces of SVN from
 the Maven project.

 Did someone already start a list of what to convert? If so I’ll use that
 as a starting point, if not I’ll make one.

 Have we already discussed breaking monorepos like shared and plugins into
 their individual projects? Maybe we can use the techniques the mojo devs
 used for the migration from Codehaus to Github? I assume that process will
 be very similar to ours.


Did Codehaus document how they did the migration somewhere?

Re: Full migration to Git

[Barrie Treloar]

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.

Re: [VOTE] Add Manfred Moser as committer

[Barrie Treloar]

+1

Re: Jekyll experiment

[Barrie Treloar]

On 3/19/15 4:32 AM, Jason van Zyl wrote:

 Anyone interested in trying a Jekyll experiment for our website?

I'm not familiar with Jekyll.
I've noticed sphinx-doc and asciidoctor.

I'm currently reading the jekyll documentation...

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

Re: JIRA

[Barrie Treloar]

On 28 December 2014 at 08:46, Jason van Zyl ja...@takari.io wrote:

 Would certainly be easier to have it at Apache at this point. I don't
 think it's particularly hard, just time consuming. I think the only safe
 option is exporting the entire database and removing all projects except
 ours. It will probably take several attempts and there are a lot of
 projects at Codehaus in that JIRA instance. I've tried moving individual
 projects with the RPC mechanism and generally doesn't work all that well.


Perhaps someone who has done this before enough times if willing to step
forward?
Or can we lean on Atlassian?

Re: Need Jira account

[Barrie Treloar]

It's not obvious but you click in the top left on the xircles icon and sign
up there.

If you want your first patch should be to make sure the documentation is up
to date for someone new to the project!

Re: Removing the Ant Bootstrap

[Barrie Treloar]

On 20 December 2014 at 10:37, Jason van Zyl ja...@takari.io wrote:

 I myself have not used the bootstrap in 18 months. I use a previously
 built version of Maven. Anyone using it? Anyone care if I remove it?


+1.
It's a complicated setup that can be avoided.

Re: maven-eclipe-plugin build failing due to Could not generate DH keypair

[Barrie Treloar]

On 7 December 2014 at 10:24, Jörg Schaible joerg.schai...@gmx.de wrote:

 Benson Margulies wrote:

  Well, the only users would be either people using old versions of
 Eclipse,
  or very stubborn people trying to use it in the teeth of m2e.

 Or users that explicitly remove m2e from their Eclipse installation because
 even without it current Eclipse is quite unstable and extremely resource
 hungry.


There was a call a while ago to retire it, but there were enough people
stuck in the past and had no choice, or preferred its use that it stayed.

Perhaps it's time for a new home instead?

Re: Grief and pain with our unit/integration tests

[Barrie Treloar]

On 28 November 2014 at 08:16, Anders Hammar and...@hammar.net wrote:

 I've been in the same position as you. My solution back then was to work on
 Maven (and also some plugins) on my private MBP connecting to Internet
 through other channels (an open guest network).


I used my laptop tethered to my phone.
The bonus also being that (at the time) it was a faster dev environment.

The old test infrastructure would also look at some files in the src/test
directory structure for configuration information. I know I hacked
something to get it to look for a per user file but I never checked it in
since everyone else didn't appear to have the same corporate firewall
issues.
And in the end it was easier to use my laptop as it had all the keys/etc
needed and setting that up for the third time was a pain.

Re: Who evaluates menu ref=parent|modules / in site.xml?

[Barrie Treloar]

On 30 October 2014 07:33, Michael Osipov micha...@apache.org wrote:

 [del]




 I did a code analysis now.


[del]

Is that a manual inspection - or are you using tooling?
http://www.plan.org.au/

Re: PlexusTestCase ?

[Barrie Treloar]

On 16 October 2014 03:49, Robert Scholte rfscho...@apache.org wrote:

 TestCase is so 20th century...

 *If* you want to do it, please make a TestRule of it.
 See also https://jira.codehaus.org/browse/MPLUGINTESTING-28


Alright, I'll bite.
Send me more links on why this is better?

Re: Plexus Archiver / Plexus Components

[Barrie Treloar]

Wasn't there talk a while ago to remove Plexus entirely with more
maintained and up-to-date equivalents?

Would it be simpler to leave the artifacts at their existing locations and
make minor changes there, and instead migrate away?

I've paid zero attention as to how much work, or how feasible, this task is.

Does anyone else have an informed opinion?

Welcome Karl Heinz Marbaise to the Maven PMC

[Barrie Treloar]

I'm pleased to announce that the Maven PMC has voted to add Karl to the
Maven PMC.

Welcome, Karl.

Re: [ANN] 2014 Committer School for people who want to become Maven Committers

[Barrie Treloar]

On 19 August 2014 18:10, Hervé BOUTEMY herve.bout...@free.fr wrote:

 Le mardi 19 août 2014 09:14:48 Martin Todorov a écrit :
  Hi Barrie,
 
  Nice to hear back from you guys!
 
  Indeed, I do have a JIRA account, but last time I tried, I wasn't able to
  assign myself issues. Could somebody please look into this?
 please give me your Jira id and I'll add you to the right Jira group as a
 step
 in the school :)


His id is carlspring
http://jira.codehaus.org/secure/ViewProfile.jspa?name=carlspring

[ANN] 2014 Committer School for people who want to become Maven Committers

[Barrie Treloar]

It's time for the yearly committer school announcement.

Do you want to become a Maven Committer?

Read Stephen's blog post
http://javaadventure.blogspot.ie/2012/07/do-you-want-to-become-maven-
committer.html and let us know.

Re: A thought on local-SNAPSHOTs

[Barrie Treloar]

On 18 June 2014 12:23, Mark Derricutt m...@talios.com wrote:

 Interesting, I hadn't noticed this was only a warning.

 The main problem I have is the moment you start relying on these fake
 reactors you end up breaking C.I. builds with dependant changes.


Why?
Your CI should know that project B depends upon A.
If you checkin B first, then yes you will get problems.
If you checkin the correct order then the CI will stack the builds so you
wont have a problem.

Either in this thread or elsewhere was the guidance to avoid have a
snapshot repo for developers.
But this is needed for CI, as each build should be using a clean local
repo  - so it needs to pull snapshots from somewhere else as they wont be
in your now empty repo, nor build as part of the reactor.



 This is my main beef with multiple git repositories for projects - if you
 have a pairing of dependant changes ( an API change and an Implementation
 change ) - without specific tooling about sharing local-repos for discreet
 dependent change sets you end up with false-negative build failures.


This is a process issue.
Either your CI is too aggressive with its code change checking window, or
you need to slow down commits, and make sure they are in the correct order,
so that you avoid the false-positive failures.

Re: A thought on local-SNAPSHOTs

[Barrie Treloar]

On 18 June 2014 13:48, Mark Derricutt m...@talios.com wrote:

 You assume CI servers have intelligence and deep knowledge of Maven. Or
 that you have deep control over their configuration.

 You can't do that with Travis CI, nor with Code-review tools such as
 Gerrit ( not cleanly, not without doing evil things with maven configs like
 I mention in [1] ).

 Starting from a complete clean local repo is also kinda horrible as a
 small commit will now take 10 minutes or so to download deps just so a
 15second build could fail. That feels WRONG.


It takes a small (but not negligible) amount of time to haul the release
jars from you local Maven Repository - likely also hosted on your CI server.
Plus pulling in any snapshots previously deployed.

I'm not familiar enough your tools, or workflow.

If your CI server can't work out that two projects share a dependency
relationship are in the build queue then you are left with manual
workarounds.
Sharing a local maven cache (~/.m2/repo) feels wrong for two independent
projects.
And if they are dependent they should be built together in the same reactor
project.
You can manually wait for build-success to be received from the build
server before you checkin Project B.

As for review, if they are independent why do they need to be reviewed
together?

Perhaps rethinking the workflow is an option?

Re: A thought on local-SNAPSHOTs

[Barrie Treloar]

On 16 June 2014 14:12, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:

 On Sunday, 15 June 2014, Mark Derricutt m...@talios.com wrote:

  So if I have two modules that are interdependent on in-progress changes,
  how does one build/test the dependant one.
 
  Note - reactor builds and multi-modules builds are out of the question -
  the above modules are in separate git repositories and there's no way to
  create a fake reactor setup - i.e. a separate pom.xml just listing
  module/ elements ( maven complains when that pom is not the parent ).


 Even if the local aggregator does something like

 module../foo/module


A link to a blog post or more detail might be useful for those still
learning.

I'm pretty sure I know this to look like
ROOT/
- aggregator
  - pom.xml (reference modules ../projectA and ../projectB)
- projectA
- projectB

But its not something I do, and I'm hoping I got it right from Maven
experience :)

This is where the vaoporware Magic Checkout plugin that Kristian has
mentioned would be useful.
This plugin would automatically change a released dependency to its
snapshot version, check it out, and update/create the aggregator project to
reference the checked out version.

Re: MPLUGIN-260 - Plugin that uses annotations in Java 8 source can't generate descriptor

[Barrie Treloar]

On 23 April 2014 15:19, fr2fy97...@snkmail.com wrote:

 As I haven't got an account with Jira, I can't vote for the issue to
 give it higher priority.


Click on the codehaus icon.
In the Introduction box you will see instructions for creating an account.

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Barrie Treloar]

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.

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

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Barrie Treloar]

On 11 April 2014 14:40, Chris Graham chrisgw...@gmail.com wrote:



 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.


This thread is about making the classpath immutable to plugins.
As per Jason's original email if a plugin wants to change the classpath
they should declare it in the plugin pom, or document that users should
declare it in their pom.



 Does this not effectively disable the use of transitive dependencies?


Additionally this thread had stuff included around Mark Derricutt's email
that suggested Maven change its behaviour so that compile time dependencies
are not transitive.
Which is what the recommended best practice is to do anyway.

Runtime would still be transitive.


 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.


Consolidation or library poms would mostly contain runtime dependencies and
not be a problem.

For compile time dependencies the two ways to do this are via inheritance
or includes.
Inheritance (i.e. parent poms) works because the dependency management
defines what versions to use, and in the child you select what you actually
want.
If there are too many things to define in the child then maybe the include
way would be better.
I can't remember whether include is vaporware though...

http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-pom-best-practice.htmlsays
There's a certain point defined more by style and experience where you
decide that minimal duplication of configuration is a small price to pay
for allowing projects [...] to remain completely independent. Designing a
huge set of thirty plus projects which all inherit five levels of POM
configuration isn't always the best idea.

Re: Error in [ERROR] Failed to execute goal on project

[Barrie Treloar]

On 3 March 2014 21:49, ananths ananth...@gmail.com wrote:
 Hi ,
 Please can any one reply me  , i am getting error  when i build my project

 [ERROR] Failed to execute goal on project : Could not resolve dependencies
 for project :jar:1.0-SNAPSHOT: The following artifacts could not be
 resolved: javax.media:jai_core:jar:1.1.2_01, com.sun:jai_codec:jar:1.1.2_01:
 Failure to find javax.media:jai_core:jar:1.1.2_01 in
 http://repo.maven.apache.org/maven2 was cached in the local repository,
 resolution will not be reattempted until the update interval of central has
 elapsed or updates are forced - [Help 1]

This is the wrong list.
This is the development of maven list.
You need to be using the user list.

I recommend you have a look at the freely available books at
http://maven.apache.org/articles.html to help give you the basics of
using Maven.

If you look at 
http://search.maven.org/remotecontent?filepath=javax/media/jai_core/1.1.2_01/jai_core-1.1.2_01.pom
you will that Maven central does not have that jar because of
licencing issues.
You need to obtain it, and install it manually.

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

Re: Exposing security vulnerability information (CVEs) when building with Maven

[Barrie Treloar]

On 27 February 2014 21:17, Bernd Eckenfels e...@zusammenkunft.net wrote:
 Hello Mark,

 Just wanted to point you to a redhat project which I recently discovered, as 
 it seems to have potential for this (even if the approach is not the most 
 decentralized one):

 The Victims Database maps JAR Signatures to known vulnerabilities, if this is 
 extended with maven coordinates  it would be a real helpfull static analysis 
 tool for build time.


Sonatype were (are) looking at doing something similar with the data
from Central.

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

Re: JIRA Access

[Barrie Treloar]

On 21 February 2014 06:11, Benson Margulies bimargul...@gmail.com wrote:
 Register for an xircles account on Codehaus and you will have JIRA access. 
 Commit comes from sustained participation.

You can read some more at
http://javaadventure.blogspot.ie/2012/07/do-you-want-to-become-maven-committer.html

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

Re: Convert everything to Git

[Barrie Treloar]

On 13 February 2014 23:57, Jason van Zyl ja...@takari.io wrote:
[del]
 The biggest win for me is working on branches. Working with branches in SVN 
 is horrible, only worse in p4 which is saying a lot. The ability to easily 
 create branches, squash commits, incrementally improve them without fear. I 
 constantly rebase against master and it's really easy with all the great 
 tools like GitX, GitTower, or SourceTree to easily see changes. The Eclipse 
 support for Git is a million times better, and doing anything Git related 
 with JGit in Java is always a pleasure (because the #2 CGit guy, wrote JGit)
[del]
 But for me it's a primarily a personal workflow issue.

I'd really appreciate a write up on that workflow.

I'm still too green using git and I'd rather follow something that
others have thought about and blessed than try to develop that on my
own.

It would also help people wanting to contribute to focus on
contribution rather than version control gymnastics.

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

Re: IT failures

[Barrie Treloar]

On 10 February 2014 14:50, jieryn jie...@gmail.com wrote:
 Don't mess with existing tests. It's always wrong to do it. You're
 lazy and stupid if you do it.

Can you chill with the attitude.
Its not helpful, or appreciated.

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

Re: IOUtil.contentEqualsIgnoreEOL ?

[Barrie Treloar]

On 6 February 2014 06:45, Baptiste Mathus m...@batmat.net wrote:
 Anyone?
 I suppose I have my answer, I'll leave the current patch as-is :-)

Isn't the long term plan to drop anything custom and use existing code?
If its already in commons-io just use that instead.

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

Re: Change request procedure that spans multiple projects

[Barrie Treloar]

On 9 January 2014 17:37, Kristian Rosenvold
kristian.rosenv...@gmail.com wrote:
 Create one jira ticket for each project and create a 'depends on' link
 between the issues.

I think there was talk about voting to release the lot as a bundle but
I've not done that - you might search the archive for it.
The other way is just release them one at a time and in the correct
order once you've fixed the problems.

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

Re: New logo?

[Barrie Treloar]

On 18 December 2013 07:27, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 I am going to integrate linked-in's hopscotch to give people a tour of the

Nice!
Good to find these things.

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

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

[Barrie Treloar]

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}/content
 
  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

Re: Re: Re: Releasing Fluido Skin 1.3.1

[Barrie Treloar]

On 5 December 2013 00:40, Michael-O 1983-01...@gmx.net wrote:
 Thanks guys,

 I will have a look into 
 http://maven.apache.org/developers/release/maven-project-release-procedure.html
  in the next couple of days an process as required.

Feel free to send patches for the documentation.
It is always appreciated when fresh eyes look at stuff.

There is so many assumptions made, and jumbles of pages, that little
tweaks are often needed to make sure anyone can do this.

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

Re: Model Version 5.0.0

[Barrie Treloar]

On 25 November 2013 20:32, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 be able to generate a pom for 4.0.0 clients that contains some of the
 bug/features that some people seem to rely on, e.g. ${} expansion in
 dependencies... but we don't need to maintain such guarantees when we
 have a new schema.

If there is a better way, then we should promote that and stop the broken way.

 * There are valid cases where a parent pom can include a set of
 dependencies that are common to all child projects. It may not be a style
 that I like, but just as I am not going to give out if somebody writes
 their *project* and has the idiotic idea of using TABs to indent (I'll moan
 if I have to make a contribution to their project though) I do not think we
 should prevent such a use case. Additionally, and perhaps more importantly,
 there can be side artifacts for a pom packaging. Thus we really should be
 publishing a .dml file for the parent. Most likely it will be empty (we
 don't need dependencyManagement because .dml files *never* include a
 parent reference) but the file is needed for any side-artifacts

I think this is an area of confusion.
There is a difference between a parent pom and a dependency inheritance pom.
Too many times I've seen the parent pom have something common only
to find out its not common in this grand-child over here.
As above, If there is a better way we should be promoting that and
stopping the broken way.

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

Re: Model Version 5.0.0

[Barrie Treloar]

On 25 November 2013 03:28, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
[del]
 Given that we have decided that the reporting stuff possibly was a
 mistake... Well let's drop that

 Given that profiles do not make sense in deployed poms... Drop them too

 We think repositories is evil... Let's drop that... We've dropped build
 and reporting= no need for pluginRepositories at all so.

I'm in favour of cleaning out elements that cause problems when they
are tweaked in a the non-Maven Way.
The emails to the users list would be reduce and there is less chance
of causing confusion.

Applying the current best practises and baking them into the poms is
a good thing.

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

Re: checkstyle release vote

[Barrie Treloar]

On 15 November 2013 00:38, Benson Margulies bimargul...@gmail.com wrote:
 I realize that I've rarely been seen to do the work of checking and
 voting for other people's releases, but none the less here I am
 begging for one more vote on mine. I promise to pitch in more in the
 future.

Challenge accepted.

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

Location of docs for what to do to check a release?

[Barrie Treloar]

I thought if I am going to help vote on the checkstyle release I
should follow the docs we have, especially given the vocal opinions
previously expressed about releases.

And I find that I can't find them.

http://maven.apache.org/guides/development/guide-testing-releases.html
Just has what to test - not what we need to check from a PMC's legal
point of view.

http://maven.apache.org/developers/release/maven-project-release-procedure.html
Has Call the vote and Check the vote results but nothing in
between on what to do in order to vote.

http://maven.apache.org/developers/index.html
Doesn't have any links either.

Have I just overlooked something or we don't have a document?

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

Re: Location of docs for what to do to check a release?

[Barrie Treloar]

On 15 November 2013 10:49, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 The project-roles doc has most of what I could find... But I do not claim
 it to be a complete list, more a WIP

Is this on the website somewhere?
SVN access behind our firewall sometimes gives me the %^@ and I
didn't bring the laptop today.

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

Re: Anyone know why Doxia treats H1 as an unknown event and H2 as section_level_1?

[Barrie Treloar]

On 13 November 2013 19:56, Lukas Theussl ltheu...@gmail.com wrote:

 Hi Stephen,

 The Sink API only knows 5 section levels, which in html are mapped to h2 -
 h6: http://jira.codehaus.org/browse/DOXIA-203

Probably from a typography point of view H1 is junk
(http://practicaltypography.com/point-size.html) and everyone just
jumps to H2 instead.

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

Re: Generated help mojo and dependency to plexus-util

[Barrie Treloar]

On 6 November 2013 18:19, Anders Hammar and...@hammar.net wrote:
 you fixed the doc in http://jira.codehaus.org/browse/MPLUGIN-235 :)


 Oh my, don't even recall doing that...
 Thanks for keeping track of my work! :-)

The benefits of source control and issue tracking.
I dont understand how its even possible for projects to still not use those...

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

[ANN] 2013 Committer School for people who want to become Maven Committers

[Barrie Treloar]

We still want more people to get up and join the committer community.

It has been a year since Stephen posted on his blog -
http://javaadventure.blogspot.ie/2012/07/do-you-want-to-become-maven-committer.html

So I thought a yearly reminder for would be a good thing.

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

Re: Wagon PRoxy auth ??

[Barrie Treloar]

On 3 September 2013 15:12, Kristian Rosenvold
kristian.rosenv...@gmail.com wrote:
 While looking at the access denied problem for wagon, I ran into this code
 line:

 https://github.com/apache/maven-wagon/blob/master/wagon-providers/wagon-http/src/main/java/org/apache/maven/wagon/providers/http/AbstractHttpClientWagon.java#L740

 The call uses a deprecated version of authenticated that regenerates the
 BasicHttpContext every time.
 The new (not deprecated) version would seem to be just

 Header bs = new BasicScheme().authenticate( creds,
 httpMethod, localContext );

 (Where we add the existing localContext variable)

 I am a bit puzzled that the current code works with authenticated proxies
 at all, but this code is
 certainly not my domain. Is this a bug ?

I've always had problems being behind an NTLM proxy.
It doesn't bother me in normal use because we use a repository manager anyway.
Where I get bitten is in running integration tests, as there is often
a settings.xml file with stuff in it for that particular Maven IT
which fails because of the NTLM proxy.

So since I mostly work around the problem I have not verified whether
its been fixed properly.

-
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

[Barrie Treloar]

On 16 August 2013 08:54, Fred Cooke fred.co...@gmail.com wrote:
 It's funny that you cite no time and use the equivalent of 299.5 6 digit
 revision numbers to send us an email on your lack of time. You could have
 done 299 releases to Sebb's quite reasonable standards with that much
 keyboard activity. Point made? :-p

I don't understand your behaviour Fred.

You want people to change but then you attack them personally (even if
you add a smiley face)

As Olivier points out, this is open source volunteer work.
Perhaps you could actually help out and cut some code/releases?
You could even enhance the templates or release tooling to support
what you are asking for.

I think you would get better responses if you didn't throw stones.
A worst case scenario is that those who are doing the work, don't
bother.  How is that helping anyone?

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

Re: New to group

[Barrie Treloar]

On 10 August 2013 04:22, John Casey jdca...@commonjava.org wrote:
 You should be able to use a quick fix to add an entry to the pom to ignore
 these. It's not ideal, but it works well enough.

 On 8/9/13 1:31 PM, John Dix wrote:
 is not supported by m2e.

If the errors are only the is not supported by m2e, you can use
John's suggestion to quick fix them away.

The error is telling you that the build is using things that m2e does
not support (because you are building an older version of maven) and
you can quick fix and ignore them.

Maven on the command line should build everything fine still.

If you are getting other errors, then you will need to sort those out.

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

Re: New to group

[Barrie Treloar]

On 8 August 2013 03:13, John Dix john@amdocs.com wrote:
 I'll give this a try!

Browse around on the maven site under the developer docs - there
should be enough information there about setting up your environment,
etc.

If there isn't, a patch would be most welcome!

Its hard to know what level of detail to provide when you are already
past that stage, so its great that you are starting out fresh so you
can provide that perspective.

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

Re: Latest modello breaks maven core unit test

[Barrie Treloar]

On 5 August 2013 17:54, Kristian Rosenvold kristian.rosenv...@gmail.com wrote:
 the next core release; I did some pretty significant
 performance improvements to maven core that I'd like to have in the
 next release :)

You got links/changelog for those so I can look?

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

Re: Latest modello breaks maven core unit test

[Barrie Treloar]

On 5 August 2013 20:55, Kristian Rosenvold kristian.rosenv...@gmail.com wrote:
 no :)

 I used m3 core as a case for trying out some new  interesting
 strategies for using a profiler, which I'll
 try to blog about pretty soon.

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

Re: Latest modello breaks maven core unit test

[Barrie Treloar]

On 5 August 2013 21:15, Barrie Treloar baerr...@gmail.com wrote:
 On 5 August 2013 20:55, Kristian Rosenvold kristian.rosenv...@gmail.com 
 wrote:
 no :)

 I used m3 core as a case for trying out some new  interesting
 strategies for using a profiler, which I'll
 try to blog about pretty soon.

Stupid mail...

Remember to send blog links when its done.


-- 
Buy books from me and Book Depository at http://www.users.on.net/~baerrach/
Commissions go to http://www.plan.org.au/

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

Re: [2/2] git commit: o change the scope of org.eclipse.sisu to test in the maven-aether-provider to prevent it from leaking out to clients.

[Barrie Treloar]

On 28 July 2013 00:24, Kristian Rosenvold kristian.rosenv...@gmail.com wrote:
 It's ok if not pushed, but I think it should be made a lot clearer in the 
 guide.

Do we have a how to guide for using Git?

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

Re: Git resources was Re: [2/2] git commit: o change the scope of org.eclipse.sisu to test in the maven-aether-provider to prevent it from leaking out to clients.

[Barrie Treloar]

On 28 July 2013 07:45, Fred Cooke fred.co...@gmail.com wrote:
 [1] http://pragprog.com/the-pragmatic-programmer/extracts/coincidence

Ahh I see they are using you as an example :)

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

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

[Barrie Treloar]

+1 binding

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

Re: Java version usage survey

[Barrie Treloar]

On 17 July 2013 07:31, Arnaud Héritier aherit...@gmail.com wrote:
 Can still keep trucking with a FreeStyle + Maven Build Step though (and I
 prefer that way anyway)


 asJenkinsUser
 Me too if we backport features from the crappy maven integration into the
 freestyle job (automatic dependencies, post build deployment ..).
 What was done in Hudson was good from my point UI (excepted the GWT UI
 which was ugly)
 /asJenkinsUser

Should we not improve the crappy Maven job for Jenkins?

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

Re: Next release for master

[Barrie Treloar]

On 16 July 2013 08:39, Stephen Connolly stephen.alan.conno...@gmail.com wrote:
 Remember folks, we are CTR not RTC so we shouldn't be holding up getting
 stuff done

I think I should be able to grok that, but google isn't helping me.
Are you making up your own acronyms :)

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

Re: How Maven works - definitions

[Barrie Treloar]

On 14 July 2013 04:52, Mirko Friedenhagen mfriedenha...@gmail.com wrote:
 Martin,

 my point is mostly that while a lot of documentation is available, a
 short summary of the base concepts is hidden in all of this pages.
 Everything I wrote in my first email may be found in these pages, but
 I feel it is somewhat hidden :-).
 Regards Mirko

Please feel free to provide enlightenment via patches.

A new set of eyes can help find the gaps that matter and help provide
the details needed to explain them.

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

Re: Older (archiva) binaries not in Central.

[Barrie Treloar]

On 11 July 2013 13:45, Chris Graham chrisgw...@gmail.com wrote:
 Hi All.

 I'm mavenizing a non-maven project, and it is currently using

 jakarta-regexp-1.5.jar which is not in Central, but 1.4 is in Central.

 The other release can all be found here:

 http://archive.apache.org/dist/jakarta/regexp/

 How can we get OS resources such as this into Central?

Is this what you were looking for ?
http://maven.apache.org/guides/mini/guide-central-repository-upload.html

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

Re: Older (archiva) binaries not in Central.

[Barrie Treloar]

On 11 July 2013 14:44, Chris Graham chrisgw...@gmail.com wrote:
 For an existing, actively developed project, yes.

 However, in this case, it's been archived/placed in the attic.

 So the project team does not really exist.

 I can also add bsf V2.4 to the list of missings things as well. :-)

If it's OSS and not in Central and the project doesnt upload it (or
can't) anyone else Can.

There are some links on the page that head off to Sonatype that give
more details on what you need to do.

But there is no reason why you couldn't be the one to get it installed
into Central.

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

Re: How Maven works - definitions

[Barrie Treloar]

On 8 July 2013 04:01, Mirko Friedenhagen mfriedenha...@gmail.com wrote:
 Hello,

 first of all, thanks for your replies. I think it would help very much
 if an introductory would be at the plugin development page[1] to get
 the big picture. Or even be repeated at the the run[2] page.

 Running Maven is trivial until you encounter problems or wish to
 extend stuff. I deal a lot with supporting our department (roughly 200
 developers, 150 of whom are using Maven) and I am always reiterating
 explaining the basic glossary (phase, lifecycle, goal).

 While the Complete reference by Sonatype is great once you know the
 basics, it is quite extensive and not every application developer
 wants or needs to delve throught it :-)

I will agree the documentation could be improved.

I've also said in the past that one of Maven's problems is that it
just works for most people.

Compare that to Ant where before you can build a project you must read
the README, configure your project settings file and then try to
build, often trouble shooting by looking at the Ant website.  This
means the average user of Ant has picked up more stuff because they
are forced to.

In Maven only the person who is modifying the poms generally acquires
more in depth knowledge of Maven - including terminology.

Which means when someone does need to work out what went wrong there
is a steep learning curve because it was not amortized over time.

Ideas on how to fix that are welcome.

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

Re: [VOTE] Apache 3.1.0

[Barrie Treloar]

On 4 July 2013 22:29, Stephen Connolly stephen.alan.conno...@gmail.com wrote:
 I will let Barrie decide on whether we *have to* cancel this vote because
 of the issues he identified in the NOTICE file.

Sebb noticed it.

I just dig the version control sleuthing that showed we have been
failing this for a long time.

I think having a correct LICENSE and NOTICE file is important.

As for the header files on test files (at least one rat has been
configured to ignore) ... maybe not so much.
I'm still relearning my PMC responsibilities to.
I think adding something to the NOTICE file for these files is good enough.

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

Re: [VOTE] Apache 3.1.0

[Barrie Treloar]

On 1 July 2013 06:52, sebb seb...@gmail.com wrote:
 Another problem: the NOTICE file contains the following spurious text:

=
==  NOTICE file corresponding to the section 4 d of==
==  the Apache License, Version 2.0,   ==
==  in this case for the Apache Maven distribution.==
=

 This must not be present in NOTICE files, which are required to be as
 short as possible (but no shorter).

 ASF NOTICE files must start as per the following example:

 
 Apache Maven
 Copyright 2001-2013 The Apache Software Foundation

 This product includes software developed at
 The Apache Software Foundation (http://www.apache.org/).
 ==

 Note also that the phrase should be developed at not developed by
 - the distinction is important.

 Furthermore, the NOTICE file refers to additonal 3rd party software,
 but there don't appear to be any LICENSE files for the software.
 The licenses should either be in LICENSE.txt or linked therefrom.

From what I can tell we have been failing this since August 2010.
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=apache-maven/NOTICE.txt;hb=bfaf11090a212f8445f2ad929af8acce5a984bf0

I can't find change history for
http://www.apache.org/legal/src-headers.html so I don't know if we
have been failing all the time, or since it was changed.

And I can see you've raised http://jira.codehaus.org/browse/MNG-5487
to track this.

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

Re: Download links for source packages - where are they?

[Barrie Treloar]

On 26 June 2013 18:44, sebb seb...@gmail.com wrote:
 Howewer the ASF releases source.
 If you don't provide a download link to the source how are users
 supposed to find it?

 I agree that most people are not going to want to download the original 
 source.
 But that does not mean it should be left unlinked.

We provide all that for Maven core - the bit the users care about and run.

Plugins are download by Maven.
Few, if any, user is going to download a source distribution of a
plugin and built it themselves.
If they are going to do that, then they are likely to want to work on
Jira issues or provide a patch and it makes much more sense to work
with source control.
And we have prominent links to the source control repositories,
including the tags.

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

Re: Release process updates

[Barrie Treloar]

 And if the mvn deploy fails for any reason?

We get this often enough with a crappy connection to our nexus servers.

 Is it necessary to re-run release:perform?

release:perform may be at the stage where it has deleted the
configuration file details, in which case you just revert to the
manual steps that release:perform is automating for you.

If its tagged everything correctly, and you build is fine - but the
upload to the staging repository failed, then you can do this
yourself.

Or you can just re-spin the release process. No drama.

 And does that always create a fresh workspace?

Yes.

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

Re: Download links for source packages - where are they?

[Barrie Treloar]

On 26 June 2013 09:47, sebb seb...@gmail.com wrote:
 I could not find any download links for Maven source packages.

 As the ASF primary purpose is to release source, and that must be
 released via the mirror system, there ought to be download pages with
 links to the source package, sigs, hashes and KEYS file.

 Yes, there are source packages for some Maven plugins, but that is not
 the same as providing download pages.

 AFAIK every single other ASF project has download pages.


As a PMC member, I welcome scrutiny that we are following the
designated procedures.

Apologies for the length, I had to do some digging around to actually
remind myself of what we are meant to do.

According to http://www.apache.org/dev/release.html

http://www.apache.org/dev/release.html#where-do-releases-go

Where do releases go?

A release isn't 'released' until the contents are in the project's
distribution directory, which is a subdirectory of
www.apache.org/dist/. In addition to the distribution directory,
project that use Maven or a related build tool sometimes place their
releases on repository.apache.org beside some convenience binaries.
The distribution directory is required, while the repository system is
an optional convenience.

And http://www.apache.org/dev/release.html#what-must-every-release-contain

What Must Every ASF Release Contain?

Every ASF release must contain a source package, which must be
sufficient for a user to build and test the release provided they have
access to the appropriate platform and tools. The source package must
be cryptographically signed by the Release Manager with a detached
signature; and that package together with its signature must be tested
prior to voting +1 for release. Folks who vote +1 for release may
offer their own cryptographic signature to be concatenated with the
detached signature file (at the Release Manager's discretion) prior to
release.

Note that the PMC is responsible for all artifacts in their
distribution directory, which is a subdirectory of
www.apache.org/dist/ ; and all artifacts placed in their directory
must be signed by a committer, preferably by a PMC member. It is also
necessary for the PMC to ensure that the source package is sufficient
to build any binary artifacts associated with the release.

Every ASF release must comply with ASF licensing policy. This
requirement is of utmost importance and an audit should be performed
before any full release is created. In particular, every artifact
distributed must contain only appropriately licensed code. More
information can be found in the foundation website and in the release
licensing FAQ.

And http://www.apache.org/dev/release.html#release-announcements

How Should Releases Be Announced?

Please ensure that you wait at least 24 hours after uploading a new
release before updating the project download page and sending the
announcement email(s). This is so that mirrors have sufficient time to
catch up. (For time-critical security releases, the download pages
script supports bypassing this requirement.)

As far as I can tell there is no official policy requiring projects to
provide a download page.
It is just a convenience to end users to give them a direct download link.
The ASF documentation clearly defines where distributions must be placed.
Since you want people to use your project it makes sense to create a
download page to make it easy for them.

For Maven itself there are clearly defined download links from the
main entry point http://maven.apache.org.

For plugins I dont think it makes any sense to provide direct download
links to sources.
I checked http://www.apache.org/dev/release.html#maven-artifacts,
which links to http://www.apache.org/dev/publishing-maven-artifacts.html
doesn't provide any more guidance here either.

So why doesn't it make sense to provide direct download links?
Because it is Maven that is the consumer of artifacts rather than the end users.
And an end user is not likely to be building a plugin from source and
then installing it into their local Maven cache, it is much easier to
get Maven to download the binaries and use them that way.

The only reason I can think of a user wanting access to the source is
so they can make modifications, and if they dont know about the ASF
distribution pages, we give them the source repository link, e.g.
http://maven.apache.org/plugins/maven-compiler-plugin/source-repository.html,
on the automatically generated web pages. To me this is better as they
can then create patches.

Does that make sense?

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

Re: Release process updates

[Barrie Treloar]

On 26 June 2013 10:19, sebb seb...@gmail.com wrote:
 On 26 June 2013 01:41, Olivier Lamy ol...@apache.org wrote:
 correct.
 In case of failure during deploy:
 * cd target/checkout  mvn clean deploy -Papache-release
 or
 * export/checkout the tag  mvn clean deploy -Papache-release

 Neither of those guarantee that the workspace agrees with the tag.

 Only by checking out the tag into a fresh workspace can you hope to
 guarantee that.

Then replace
cd target/checkout  mvn clean deploy -Papache-release
with
delete target/checkout
svn co blah to target/checkout
mvn clean deploy -Papache-release

Since it was mvn release:perform that created target/checkout in the
first place and no one has made any changes in that directory, cd
target/checkout has the same results.

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

Re: Download links for source packages - where are they?

[Barrie Treloar]

On 26 June 2013 10:48, sebb seb...@gmail.com wrote:
 The point is that the ASF release source, and it must be provided for
 download via the ASF mirrors.

 See:

 http://www.apache.org/dev/release.html#host-GA

 If you don't point users to the source, I don't see how you can claim
 it has been properly released.

Which part of http://www.apache.org/dev/release.html#host-GA do you
think we are violating?
Releases are available via http://archive.apache.org/dist/maven/plugins/

We meet Project download pages must link to the mirrors for the
Maven Core Project - but not the plugins.

I can find no documentation that says you *must* provide a download page.
Just that if there is a download page it must point to the mirrors.

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

Re: Release process updates

[Barrie Treloar]

 Then replace
 cd target/checkout  mvn clean deploy -Papache-release
 with
 delete target/checkout
 svn co blah to target/checkout
 mvn clean deploy -Papache-release

 Since it was mvn release:perform that created target/checkout in the
 first place and no one has made any changes in that directory, cd

 You cannot know that for sure.
 People make mistakes; try things out, get distracted, forget that they
 changed something.

 target/checkout has the same results.

 Not guaranteed.

In the end that does not matter.

As long as the tag and the source release can be verified.
See http://www.apache.org/dev/release.html#owned-controlled-hardware,
which links to 
https://svn.apache.org/repos/private/committers/tools/releases/compare_dirs.pl
as a helper script.

The ASF release process does not help to ensure the release is useful,
merely that it meets the legal obligations of the foundation.

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

Re: Project Info Report: Feature to check dependencies against whitelist?

[Barrie Treloar]

There is some stuff out there.
(Note I've not used any of them)

http://khmarbaise.github.io/Maven-License-Verifier-Plugin/example.html

Nexus' marketing says it is able to do a health check on your app
(http://www.sonatype.com/application-health-check).

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

Re: using multiple artifacts from a single group

[Barrie Treloar]

On 13 June 2013 13:26, Wayne Fay wayne...@gmail.com wrote:
 I am a newbie to maven and I am still trying to get a grip of how maven

Please have a look at the freely available books at
http://maven.apache.org/articles.html

After that you might want to read up specifically on Maven and Android
development.

You will face too many challenges just winging it.

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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Barrie Treloar]

Write this scenario up in the trouble shooting notes on how to test
staging releases.

I fit into the behind corporate proxy category but I have not had
this problem (I use Kristian's solution).
Admittedly the effort required to configure the corporate proxy for a
staging url is often enough to disuade me from testing that plugin.
It is easier to pull out my personal laptop and tether it to test the
plugin.

Anyway with this discussion captured somewhere, if it truly becomes an
issues for enough people they can find what we discussed and re-raise
options.

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

Re: [DISCUSS] [VOTE] Should we respin CANCELLED releases with the same version number?

[Barrie Treloar]

On 29 May 2013 20:53, Stephen Connolly stephen.alan.conno...@gmail.com wrote:
 The issue with that is when using the Maven Release Plugin, you will not be
...

Can't we fix the tooling then?

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