Re: [VOTE] Release Maven Enforcer version 1.0.1 - Take 2

2011-06-18 Thread Hervé BOUTEMY
+1

Hervé

Le jeudi 16 juin 2011, Kristian Rosenvold a écrit :
 Hi,
 
 The release includes the enforcer-plugin, enforcer-rules and
 enforcer-api modules. The site-staging problems from take 1 were fixed
 in r1136499. The only diff between this vote and take 1 is the site
 deployment.
 
 
 We solved 2 issues:
 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530version=16
 879
 
 There are still a couple of issues left in JIRA:
 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidejq
 lQuery=project+%3D+MENFORCER+AND+resolution+%3D+Unresolved+ORDER+BY+updated
 +DESC
 
 
 Staging repo:
 https://repository.apache.org/content/repositories/maven-011/
 
 Staging site:
 http://maven.apache.org/staging/plugins/maven-enforcer-plugin/
 
 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html
 
 Vote open for 72 hours.
 
 [ ] +1
 [ ] +0
 [ ] -1
 
 And here's my +1
 
 Kristian
 
 
 
 -
 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 version 21 of the parent POM for maven plugins

2011-06-18 Thread Hervé BOUTEMY
+1

Hervé

Le mercredi 15 juin 2011, Benson Margulies a écrit :
 Hi,
 
 We solved 1 issues:
 
 ** Improvement
* [MPOM-12] - Update maven-plugins to new
 org.apache.maven:maven-parent:20
 
 There are no open JIRAs against the maven-plugins parent.
 
 http://svn.apache.org/viewvc/maven/pom/trunk/maven/pom.xml?r1=1135900r2=11
 35901diff_format=h
 
 Staging repo:
 https://repository.apache.org/content/repositories/maven-014/
 
 Staging site:
 http://maven.apache.org/plugins/maven-plugins-21/
 
 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 Maven Remote Resources Plugin version 1.2.1

2011-06-18 Thread Hervé BOUTEMY
+1

Hervé

Le mardi 14 juin 2011, Kristian Rosenvold a écrit :
 Hi,
 
 We solved 1 issue:
 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11391version=17
 198
 
 There are still 2 issues left in JIRA:
 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidejq
 lQuery=project+%3D+MRRESOURCES+AND+resolution+%3D+Unresolved+ORDER+BY+updat
 ed+DESC
 
 Staging repo:
 https://repository.apache.org/content/repositories/maven-010/
 
 Staging site: (Sync pending)
 http://maven.apache.org/plugins/maven-remote-resources-plugin-1.2.1/
 
 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html
 
 Vote open for 72 hours.
 
 [ ] +1
 [ ] +0
 [ ] -1
 
 
 And here's my +1
 
 Kristian
 
 
 
 
 
 -
 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



[ANN] Maven Surefire Plugin 2.9 Released

2011-06-18 Thread Kristian Rosenvold
The Maven team is pleased to announce the release of the Maven
Surefire Plugin, version 2.9

This release includes the maven-surefire-plugin, which executes the
unit tests of an application, the maven-surefire-report-plugin, which
parses surefire/failsafe test results and renders them to DOXIA
creating the web interface version of the test results, as well as the
maven-failsafe-plugin, which executes the integration tests of an
application.

Surefire can now run JUnit 3 tests with a security manager present, see
http://maven.apache.org/plugins/maven-surefire-plugin/examples/junit.html

 Note to JUnit4 users upgrading:
Due to SUREFIRE-482 users upgrading to surefire 2.9 from 2.7
may see some (incorrectly defined) tests not being run any more.
This should be verified by running mvn -Dsurefire.junit4.upgradecheck=true
install at least once (this can be run multiple times until you
have fixed all issues)

http://maven.apache.org/plugins/maven-surefire-plugin/

You should specify the version in your project's plugin configuration:

plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
version2.9/version
/plugin



Release Notes - Maven Surefire - Version 2.9



** Bug
* [SUREFIRE-34] - Using security manager in a fork mode causes an
AccessControlException
* [SUREFIRE-534] - Xpp3Dom gets in the way of org.omg.CORBA.INITIALIZE
* [SUREFIRE-690] - testSetCompleted called before testSetStarting
when using m3 parallel builds
* [SUREFIRE-703] - surefire-junit47doesn't work with
redirectTestOutputToFile option
* [SUREFIRE-704] - maven surefire Error while executing forked
tests.; nested exception is java.lang.IllegalStateException:
testSetStarting called twice
* [SUREFIRE-720] - Toolchain is ignored
* [SUREFIRE-727] - Classpath too long on windows with
useManifestOnlyJar=false
* [SUREFIRE-730] - JUnit4RunListener does not report results from
concurrently running tests correctly
* [SUREFIRE-731] - Cannot build 2.8.1 from tag
* [SUREFIRE-733] - write(int) not overridden in ConsoleOuptutCapture
* [SUREFIRE-735] - Surefire plugin does not report fatal VM creation failure
* [SUREFIRE-740] - Fractional part of method execution time is
truncated for non English locale
* [SUREFIRE-741] - Stdout/stderr is now not being included in XML
test reports for test failures
* [SUREFIRE-742] - Latest 2.8.2-SNAPSHOT version having sporadic
java.lang.RuntimeException errors
* [SUREFIRE-743] - JUnit 4.x provider never calls notifier.testRunFinished
* [SUREFIRE-744] - NullPointerException in
ConcurrentReporterManager, falsely report of No tests were executed!


** Improvement
* [SUREFIRE-748] - Ensure plugin classloader is unloadable

** New Feature
* [SUREFIRE-736] - Add a list of system properties from a properties file

Enjoy,

-The Maven team

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



[ANN] Maven remote-resources-plugin 1.2.1 Released

2011-06-18 Thread Kristian Rosenvold
The Maven team is pleased to announce the release of the Maven Remote
Resources Plugin, version 1.2.1

This plugin is used to retrieve JARs of resources from remote
repositories, process those resources, and incorporate them into JARs
you build with Maven.

http://maven.apache.org/plugins/maven-remote-resources-plugin/

You should specify the version in your project's plugin configuration:

plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-remote-resources-plugin/artifactId
  version1.2.1/version
/plugin

Release Notes - Maven 2.x Remote Resources Plugin - Version 1.2.1


** Bug
* [MRRESOURCES-54] - m-r-r-p 1.2 not actually threadsafe
apparently due to antique velocity version


Enjoy,

-The Maven team

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



[ANN] Maven Verifier 1.3 Released

2011-06-18 Thread Kristian Rosenvold
The Maven team is pleased to announce the release of the Maven Verifier,
version 1.3

This is a shared library for use in testing various Maven components. It
allows the user to execute Maven builds as part of the testing process,
with methods supporting test preparation and assertion of results.

http://maven.apache.org/shared/maven-verifier/

To use the verifier, add the following to your POM's dependencies section:

dependency
  groupIdorg.apache.maven.shared/groupId
  artifactIdmaven-verifier/artifactId
  version1.3/version
  scopetest/scope
/dependency


The release contains various minor improvements and bugfixes, which
can be seen from
the attached svn log.


Enjoy,

-The Maven team


== CHANGELOG ==


r815892 | jdcasey | 2009-09-16 19:12:28 +0200 (on., 16 sep. 2009) | 1
line

removing one-off source release assemblies (and config), then upgrading
parent version for all shared projects up to 12, so source-release will
be automatic.

r823739 | bentmann | 2009-10-10 01:20:57 +0200 (lø., 10 okt. 2009) | 1
line

o Added support to launch ITs using embedded Maven 3.x

r824335 | bentmann | 2009-10-12 15:47:17 +0200 (ma., 12 okt. 2009) | 1
line

o Added another embedded launcher that does not load Maven from a home
directory but from the class path, this allows us to run the core ITs
with the Maven from our IDE workspace

r912161 | bentmann | 2010-02-20 18:46:18 +0100 (lø., 20 feb. 2010) | 1
line

o Simplified configuration of environment variables

r920045 | bentmann | 2010-03-07 18:43:28 +0100 (sø., 07 mars 2010) | 1
line

o Added setter for fork option

r920448 | bentmann | 2010-03-08 19:55:39 +0100 (ma., 08 mars 2010) | 1
line

o Removed validation of goal list to allow execution of default goals
given in POM

r931543 | bentmann | 2010-04-07 15:41:19 +0200 (on., 07 april 2010) | 1
line

o Fixed argument quoting to recognize more special characters

r936076 | krosenvold | 2010-04-20 23:58:36 +0200 (ti., 20 april 2010) |
1 line

o Removed deadlock-prone synchronization

r944714 | bentmann | 2010-05-15 22:29:45 +0200 (lø., 15 mai 2010) | 1
line

o Added method to purge specific g:a:v from local repo

r948765 | bentmann | 2010-05-27 12:31:10 +0200 (to., 27 mai 2010) | 1
line

o Disabled EMMA runtime controller to prevent port clashes during CI

r981591 | bentmann | 2010-08-02 18:44:34 +0200 (ma., 02 aug. 2010) | 1
line

o Added convenience method to add CLI option

r983169 | hboutemy | 2010-08-07 05:29:54 +0200 (lø., 07 aug. 2010) | 1
line

updated issue management urls to point precisely to the component in
MSHARED

r1029201 | bentmann | 2010-10-30 23:04:17 +0200 (lø., 30 okt. 2010) | 1
line

o Set user.dir when running embedded Maven

r1033965 | bentmann | 2010-11-11 16:39:40 +0100 (to., 11 nov. 2010) | 1
line

o Ensured parent directory of filtered file exists

r1050248 | bentmann | 2010-12-17 01:15:51 +0100 (fr., 17 des. 2010) | 1
line

o Added methods to further help inspection of local repo contents

r1050251 | bentmann | 2010-12-17 01:19:14 +0100 (fr., 17 des. 2010) | 1
line

o Made local repo layout customizable

r1050255 | bentmann | 2010-12-17 01:29:11 +0100 (fr., 17 des. 2010) | 1
line

o Added convenience option to remote debug mvn

r1050405 | bentmann | 2010-12-17 15:44:23 +0100 (fr., 17 des. 2010) | 1
line

o Allowed to query path to group-level metadata

r1059093 | bentmann | 2011-01-14 19:17:21 +0100 (fr., 14 jan. 2011) | 1
line

o Simplified extraction of Maven version

r1064936 | bentmann | 2011-01-29 02:24:36 +0100 (lø., 29 jan. 2011) | 1
line

o 

Re: [VOTE] Release Maven Enforcer version 1.0.1 - Take 2

2011-06-18 Thread Evgeny Mandrikov
+1

On Thu, Jun 16, 2011 at 19:58, Kristian Rosenvold 
kristian.rosenv...@gmail.com wrote:

 Hi,

 The release includes the enforcer-plugin, enforcer-rules and
 enforcer-api modules. The site-staging problems from take 1 were fixed
 in r1136499. The only diff between this vote and take 1 is the site
 deployment.


 We solved 2 issues:

 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530version=16879

 There are still a couple of issues left in JIRA:

 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidejqlQuery=project+%3D+MENFORCER+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC


 Staging repo:
 https://repository.apache.org/content/repositories/maven-011/

 Staging site:
 http://maven.apache.org/staging/plugins/maven-enforcer-plugin/

 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html

 Vote open for 72 hours.

 [ ] +1
 [ ] +0
 [ ] -1

 And here's my +1

 Kristian



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




-- 
Best regards,
Evgeny Mandrikov aka Godin http://godin.net.ru
http://twitter.com/_godin_
http://www.SonarSource.com http://www.sonarsource.com/


Re: [VOTE] Release Maven Enforcer version 1.0.1 - Take 2

2011-06-18 Thread Stephen Connolly
+ 1

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 16 Jun 2011 16:58, Kristian Rosenvold kristian.rosenv...@gmail.com
wrote:
 Hi,

 The release includes the enforcer-plugin, enforcer-rules and
 enforcer-api modules. The site-staging problems from take 1 were fixed
 in r1136499. The only diff between this vote and take 1 is the site
 deployment.


 We solved 2 issues:

http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530version=16879

 There are still a couple of issues left in JIRA:

http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidejqlQuery=project+%3D+MENFORCER+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC


 Staging repo:
 https://repository.apache.org/content/repositories/maven-011/

 Staging site:
 http://maven.apache.org/staging/plugins/maven-enforcer-plugin/

 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html

 Vote open for 72 hours.

 [ ] +1
 [ ] +0
 [ ] -1

 And here's my +1

 Kristian



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



[VOTE RESULT] release version 21 of the parent POM for maven plugins

2011-06-18 Thread Benson Margulies
This vote passes.

All votes +1;

binding:

Mark Struberg
John Casey
Olivier Lamy
Hervé BOUTEMY

nonbinding:

Lukas Theussl

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



Re: svn commit: r1136319 - /maven/plugins/trunk/maven-changelog-plugin/src/main/resources/scm-activity_pt_BR.properties

2011-06-18 Thread Dennis Lundberg
Please remember to add new locales to thel10n-maven-plugin configuration.

I've fixed it for the changelog and changes plugins.

On 2011-06-16 10:24, ol...@apache.org wrote:
 Author: olamy
 Date: Thu Jun 16 08:24:48 2011
 New Revision: 1136319
 
 URL: http://svn.apache.org/viewvc?rev=1136319view=rev
 Log:
 [MCHANGELOG-122] Add pt_BR localization
 Submitted by Taciano Tres
 
 
 Added:
 
 maven/plugins/trunk/maven-changelog-plugin/src/main/resources/scm-activity_pt_BR.properties
(with props)
 
 Added: 
 maven/plugins/trunk/maven-changelog-plugin/src/main/resources/scm-activity_pt_BR.properties
 URL: 
 http://svn.apache.org/viewvc/maven/plugins/trunk/maven-changelog-plugin/src/main/resources/scm-activity_pt_BR.properties?rev=1136319view=auto
 ==
 --- 
 maven/plugins/trunk/maven-changelog-plugin/src/main/resources/scm-activity_pt_BR.properties
  (added)
 +++ 
 maven/plugins/trunk/maven-changelog-plugin/src/main/resources/scm-activity_pt_BR.properties
  Thu Jun 16 08:24:48 2011
 @@ -0,0 +1,61 @@
 +# Licensed to the Apache Software Foundation (ASF) under one
 +# or more contributor license agreements.  See the NOTICE file
 +# distributed with this work for additional information
 +# regarding copyright ownership.  The ASF licenses this file
 +# to you under the Apache License, Version 2.0 (the
 +# License); you may not use this file except in compliance
 +# with the License.  You may obtain a copy of the License at
 +#
 +#  http://www.apache.org/licenses/LICENSE-2.0
 +#
 +# Unless required by applicable law or agreed to in writing,
 +# software distributed under the License is distributed on an
 +# AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 +# KIND, either express or implied.  See the License for the
 +# specific language governing permissions and limitations
 +# under the License.
 +
 +#Commons
 +report.And=e
 +report.SetRangeUnknown=Mudan\u00e7as de um per\u00edodo desconhecido
 +report.SetRangeSince=Mudan\u00e7as desde
 +report.SetRangeBetween=Mudan\u00e7as entre
 +report.SetTagCreation=Mudan\u00e7as desde a cria\u00e7\u00e3o do projeto
 +report.SetTagSince=Mudan\u00e7as deste o tag
 +report.SetTagBetween=Mudan\u00e7as entre tags
 +report.SetTagUntil=at\u00e9 tag
 +report.To=para
 +report.TotalCommits=Commits totais
 +
 +#Changelog
 +report.changelog.name=Registros de Mudan\u00e7as
 +report.changelog.description=Gerado relat\u00f3rio de mudan\u00e7as do SCV.
 +report.changelog.header=Relat\u00f3rio de Mudan\u00e7as
 +report.changelog.mainTitle=Relat\u00f3rio de Mudan\u00e7as
 +report.changelog.ChangedSetsTotal=N\u00famero total de mudan\u00e7as
 +report.changelog.FilesChanged=N\u00famero total de arquivos alterados
 +report.changelog.timestamp=Data e hora
 +report.changelog.author=Autor
 +report.changelog.details=Detalhes
 +report.changelog.revision=Revis\u00e3o
 +report.changelog.nosources=Origem n\u00e3o localizada para criar o 
 relat\u00f3rio.
 +
 +#Developer Activity
 +report.dev-activity.name=Atividade dos Desenvolvedores
 +report.dev-activity.description=Gerado relat\u00f3rio de atividades dos 
 desenvolvedores do SCV.
 +report.dev-activity.header=Relat\u00f3rio de Atividades dos Desenvolvedores
 +report.dev-activity.mainTitle=Relat\u00f3rio de Atividades dos 
 Desenvolvedores
 +report.dev-activity.noDevelopers=Desenvolvedores n\u00e3o encontrados no pom.
 +report.dev-activity.range=Per\u00edodo
 +report.dev-activity.filesChanged=N\u00famero total de arquivos alterados
 +report.dev-activity.developer=Desenvolvedor
 +
 +#File Activity
 +report.file-activity.name=Atividade nos Arquivos
 +report.file-activity.description=Gerado relat\u00f3rio de atividade nos 
 arquivos do SCM.
 +report.file-activity.header=Relat\u00f3rio de Atividade nos Arquivos
 +report.file-activity.mainTitle=Relat\u00f3rio de Atividade nos Arquivos
 +report.file-activity.range=Per\u00edodo
 +report.file-activity.filesChanged=N\u00famero total de arquivos alterados
 +report.file-activity.timesChanged=N\u00famero de altera\u00e7\u00f5es
 +report.file-activity.filename=Nome do arquivo
 
 Propchange: 
 maven/plugins/trunk/maven-changelog-plugin/src/main/resources/scm-activity_pt_BR.properties
 --
 svn:eol-style = native
 
 Propchange: 
 maven/plugins/trunk/maven-changelog-plugin/src/main/resources/scm-activity_pt_BR.properties
 --
 svn:keywords = Author Date Id Revision
 
 
 


-- 
Dennis Lundberg

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



[VOTE]: release maven-changes-plugin 2.6

2011-06-18 Thread Benson Margulies
Hi,

We solved 3 issues:

http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375


There are plenty of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DESCmode=hide

Staging repo:
https://repository.apache.org/content/repositories/maven-024/

Staging site:
http://maven.apache.org/plugins/maven-changes-plugin-2.6/

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: Get thee to the Core...

2011-06-18 Thread Benson Margulies
Returning to the very start of this thread:

Now that I seem to have caught up with my current box of itches on
plugins for the moment, I'd be more than happy to join this parade.
Could some more experience committer grab a defect JIRA that has a
some value to it, throw it up here on the list, and shout 'pull'?

On Mon, Jun 13, 2011 at 5:25 PM, Hervé BOUTEMY herve.bout...@free.fr wrote:
 While we have a good standard for plugin site organization [1] that was
 debated a few years ago to improve Maven documentation, we have nothing for
 components. And the actual state is not good: see Maven core, where even
 simplest description of every component is not done but inherited from
 parent...

 I think we could define something for components like plugins, relatively easy
 to follow and definitely useful as a starting point.
 I have a few ideas:
 - a site descriptor with links to javadoc and jxr (since code is the most
 important thing expected from components), and a FAQ
 - an introduction with a list of component interfaces and implementations
 provided (I have no precise idea on the form)

 Any other idea?

 I'll try to implement some ideas on Maven core for the next version: we'll
 write a guide later with practices found.

 Regards,

 Hervé

 [1] http://maven.apache.org/guides/development/guide-plugin-documentation.html

 Le vendredi 10 juin 2011, Evgeny Mandrikov a écrit :
 HI all,
 Just my 2 cents :

 Main problem with jumping into Maven core development is understanding of
 internal architecture and core parts. Also this affects development of
 plugins. Thus IMO improving this can definitely animate Maven ecosystem
 (Core, Core Plugins, Mojo, ...) in general.

 Another point is that improving core without visible user features doesn't
 bring a lot of value. But such things (like slf4j, @Inject) also
 interesting as a paralel process together with new features.

 On Thu, Jun 9, 2011 at 20:21, John Casey jdca...@commonjava.org wrote:
  CC'ing dev@: I hope the PMC doesn't mind.
 
  We've been spending some time on-and-off talking about how we can open up
  development in the Maven core, and see if we can attract some fresh minds
  and ideas. I'd like to copy a list of some things we've been talking
  about, and open it up to anyone here on the dev list who has an opinion.
 
  This list is not meant to be comprehensive, that's the point! I (and
  others) would like to start the conversation about what we need to do to
  get more of the community involved in developing the core of Maven.
 
  If you're interested, please read on, and give us your thoughts!
 
  ---
 
  On 6/8/11 8:18 PM, Barrie Treloar wrote:
  List of suggestions to improve hacking on the core
 
  * Move to a more sustainable architecture (Stephens started this with
  plexus-utils)
 
   * Upgrading Wagon (Mark)
 
 
   * Open up access to the community somehow (suggested by Kristian)
 
 
   * Draw in more developers to core (suggested by John)
 
 
   * Component annotations via more standard notations (suggested by John)
 
 
   * do stuff that is interesting to others (see the reaction to the
 
  mixin stuff I started) (suggested by Brett)
 
   * apply patches from people that genuinely can help (suggested by Brett)
 
  John also suggested
 
   - the Maven App Engine stuff I've been working on. which allows people
 
  to cobble together Maven-based apps, and play around with the
  different internal services / subsystems of Maven
 
  this is under:
 
  http://svn.apache.org/repos/asf/maven/sandbox/trunk/mae
 
  if anyone is interested...
 
   - blogs explaining the way to do various tasks inside the core...how
 
  different subsystems work, or something
 
  see below...
 
   - putting together some sort of call for people to come help with
 
  specific new features in the core, like versionless parents, multiple
  POM syntaxes, etc...
 
  I think this thread is going to be the call...or at least, the first of
  many such calls.
 
  Here I think etc needs to be expanded :)
 
  Please, that's the point of the conversation...expand it!
 
   p.s. I really like the idea of versionless parents that would save
 
  some pain I'm feeling)
 
  I'm almost in favor of a more formalized parent/child dual POM syntax
  than versionless parents. Why not go all the way and recognize child
  POMs as the slave modules they are?
 
  I disagree with blogs, but that may be a starting point.
 
  I was thinking about blogging as a way of answering specific
  engineering-related questions about how to get a particular thing done
  using Maven components. Or rather, how does Maven go about doing a
  particular task?
 
  Maybe this would turn into documentation eventually...but I almost see it
  as more of a forum at first. We have email for this, and that will be the
  eventual response, that we should use email...but blogs are so much more
  accessible from places like feedly and google.
 
   I think we need to create documentation that is accessible from the
 
  

The JIRA chocolate box

2011-06-18 Thread Benson Margulies
I just looked at the 'blocker' issues. We have a variety of very old
JIRAs here. None of the ones I looked at have a self-contained test
case that would can be downloaded, run, and converted to an
integration test, etc.

What's the policy? My temptation would be to comment on them asking if
the OP is still interested (in some cases, 5 years later), and, if so,
can they come up with a repeatable test case, and if not close as not
a real bug.

I don't mind in some cases doing work to build a test case, but to go
to all this trouble for a bug that was opened about maven 2.0.x, where
it may not be that easy to reconstruct the critical components of the
problem, seems a dubious use of time.

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



Re: The JIRA chocolate box

2011-06-18 Thread Stephen Connolly
+50

I say lets give each issue a ping, wait 2 weeks and close if no response

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 18 Jun 2011 23:30, Benson Margulies bimargul...@gmail.com wrote:
 I just looked at the 'blocker' issues. We have a variety of very old
 JIRAs here. None of the ones I looked at have a self-contained test
 case that would can be downloaded, run, and converted to an
 integration test, etc.

 What's the policy? My temptation would be to comment on them asking if
 the OP is still interested (in some cases, 5 years later), and, if so,
 can they come up with a repeatable test case, and if not close as not
 a real bug.

 I don't mind in some cases doing work to build a test case, but to go
 to all this trouble for a bug that was opened about maven 2.0.x, where
 it may not be that easy to reconstruct the critical components of the
 problem, seems a dubious use of time.

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



Re: The JIRA chocolate box

2011-06-18 Thread Stephen Connolly
they can always reopen if they want after the issue has been closed if the
2nd weeks was too short

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 19 Jun 2011 00:20, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
 +50

 I say lets give each issue a ping, wait 2 weeks and close if no response

 - Stephen

 ---
 Sent from my Android phone, so random spelling mistakes, random nonsense
 words and other nonsense are a direct result of using swype to type on the
 screen
 On 18 Jun 2011 23:30, Benson Margulies bimargul...@gmail.com wrote:
 I just looked at the 'blocker' issues. We have a variety of very old
 JIRAs here. None of the ones I looked at have a self-contained test
 case that would can be downloaded, run, and converted to an
 integration test, etc.

 What's the policy? My temptation would be to comment on them asking if
 the OP is still interested (in some cases, 5 years later), and, if so,
 can they come up with a repeatable test case, and if not close as not
 a real bug.

 I don't mind in some cases doing work to build a test case, but to go
 to all this trouble for a bug that was opened about maven 2.0.x, where
 it may not be that easy to reconstruct the critical components of the
 problem, seems a dubious use of time.

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



Re: The JIRA chocolate box

2011-06-18 Thread Benson Margulies
If no one objects to this idea, I'd like to add a component, which is
an email like the following to the user list.

--snip--

Dear Maven Users,

Over the years, the JIRA for core Maven
(http://jira.codehaus.org/browse/MNG) has accumulated many unresolved
issues. All this clutter makes it difficult to tell where the real
problems are. Further, many of these issues do not contain
self-contained test cases. Practically speaking, it is very difficult
to diagnose and resolve a problem without a test case 'on the bench.'
We developers would like to turn over a bit of a new leaf. We're going
to ask you to supply a test case to go with your bug reports. In
return, we're going to try very hard to attend to them. You can tar it
up and attach it to the jira, or just push it to github and add a
link.

To clean up the current mess, we plan to start going through the
backlog. We'll add comments asking for test cases or other followup.
If we don't hear back in two weeks, we're going to close.

We're sorry for any frustration felt by the originators of
long-neglected reports, but we believe that this process will help us
be more responsive in the future.

--snip--


On Sat, Jun 18, 2011 at 7:22 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 they can always reopen if they want after the issue has been closed if the
 2nd weeks was too short

 - Stephen

 ---
 Sent from my Android phone, so random spelling mistakes, random nonsense
 words and other nonsense are a direct result of using swype to type on the
 screen
 On 19 Jun 2011 00:20, Stephen Connolly stephen.alan.conno...@gmail.com
 wrote:
 +50

 I say lets give each issue a ping, wait 2 weeks and close if no response

 - Stephen

 ---
 Sent from my Android phone, so random spelling mistakes, random nonsense
 words and other nonsense are a direct result of using swype to type on the
 screen
 On 18 Jun 2011 23:30, Benson Margulies bimargul...@gmail.com wrote:
 I just looked at the 'blocker' issues. We have a variety of very old
 JIRAs here. None of the ones I looked at have a self-contained test
 case that would can be downloaded, run, and converted to an
 integration test, etc.

 What's the policy? My temptation would be to comment on them asking if
 the OP is still interested (in some cases, 5 years later), and, if so,
 can they come up with a repeatable test case, and if not close as not
 a real bug.

 I don't mind in some cases doing work to build a test case, but to go
 to all this trouble for a bug that was opened about maven 2.0.x, where
 it may not be that easy to reconstruct the critical components of the
 problem, seems a dubious use of time.

 -
 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: The JIRA chocolate box

2011-06-18 Thread Martin Gainty

agreed 
although scanning the Surefire JIRA i did notice some of jasons original jiras 
were'nt addressed for upwards of 3-4 years (by Brett Porter)

I havent heard of JIRA chocolate box..maybe an implementation of a Finite State 
Machine or perhaps this is a non sequitir?
Bedankt,
Martin 
__ 

 Date: Sat, 18 Jun 2011 18:30:04 -0400
 Subject: The JIRA chocolate box
 From: bimargul...@gmail.com
 To: dev@maven.apache.org
 
 I just looked at the 'blocker' issues. We have a variety of very old
 JIRAs here. None of the ones I looked at have a self-contained test
 case that would can be downloaded, run, and converted to an
 integration test, etc.
 
 What's the policy? My temptation would be to comment on them asking if
 the OP is still interested (in some cases, 5 years later), and, if so,
 can they come up with a repeatable test case, and if not close as not
 a real bug.
 
 I don't mind in some cases doing work to build a test case, but to go
 to all this trouble for a bug that was opened about maven 2.0.x, where
 it may not be that easy to reconstruct the critical components of the
 problem, seems a dubious use of time.
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
  

Re: The JIRA chocolate box

2011-06-18 Thread Ralph Goers
My guess is a reference to Forrest Gump - you never know what you are going to 
get.

Ralph

On Jun 18, 2011, at 7:51 PM, Martin Gainty wrote:

 
 agreed 
 although scanning the Surefire JIRA i did notice some of jasons original 
 jiras were'nt addressed for upwards of 3-4 years (by Brett Porter)
 
 I havent heard of JIRA chocolate box..maybe an implementation of a Finite 
 State Machine or perhaps this is a non sequitir?
 Bedankt,
 Martin 
 __ 
 
 Date: Sat, 18 Jun 2011 18:30:04 -0400
 Subject: The JIRA chocolate box
 From: bimargul...@gmail.com
 To: dev@maven.apache.org
 
 I just looked at the 'blocker' issues. We have a variety of very old
 JIRAs here. None of the ones I looked at have a self-contained test
 case that would can be downloaded, run, and converted to an
 integration test, etc.
 
 What's the policy? My temptation would be to comment on them asking if
 the OP is still interested (in some cases, 5 years later), and, if so,
 can they come up with a repeatable test case, and if not close as not
 a real bug.
 
 I don't mind in some cases doing work to build a test case, but to go
 to all this trouble for a bug that was opened about maven 2.0.x, where
 it may not be that easy to reconstruct the critical components of the
 problem, seems a dubious use of time.
 
 -
 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: The JIRA chocolate box

2011-06-18 Thread Benson Margulies
I am only proposing this for MNG at this point.

On Jun 18, 2011, at 10:55 PM, Ralph Goers ralph.go...@dslextreme.com wrote:

 My guess is a reference to Forrest Gump - you never know what you are going 
 to get.

 Ralph

 On Jun 18, 2011, at 7:51 PM, Martin Gainty wrote:


 agreed
 although scanning the Surefire JIRA i did notice some of jasons original 
 jiras were'nt addressed for upwards of 3-4 years (by Brett Porter)

 I havent heard of JIRA chocolate box..maybe an implementation of a Finite 
 State Machine or perhaps this is a non sequitir?
 Bedankt,
 Martin
 __

 Date: Sat, 18 Jun 2011 18:30:04 -0400
 Subject: The JIRA chocolate box
 From: bimargul...@gmail.com
 To: dev@maven.apache.org

 I just looked at the 'blocker' issues. We have a variety of very old
 JIRAs here. None of the ones I looked at have a self-contained test
 case that would can be downloaded, run, and converted to an
 integration test, etc.

 What's the policy? My temptation would be to comment on them asking if
 the OP is still interested (in some cases, 5 years later), and, if so,
 can they come up with a repeatable test case, and if not close as not
 a real bug.

 I don't mind in some cases doing work to build a test case, but to go
 to all this trouble for a bug that was opened about maven 2.0.x, where
 it may not be that easy to reconstruct the critical components of the
 problem, seems a dubious use of time.

 -
 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: The JIRA chocolate box

2011-06-18 Thread Martin Gainty

 Subject: Re: The JIRA chocolate box
 From: ralph.go...@dslextreme.com
 Date: Sat, 18 Jun 2011 19:54:30 -0700
 To: dev@maven.apache.org
 
 My guess is a reference to Forrest Gump - you never know what you are going 
 to get.
 
 Ralph
MGand thats all i have to say about that!...MG
MGThanks Ralph
 
 On Jun 18, 2011, at 7:51 PM, Martin Gainty wrote:
 
  
  agreed 
  although scanning the Surefire JIRA i did notice some of jasons original 
  jiras were'nt addressed for upwards of 3-4 years (by Brett Porter)
  
  I havent heard of JIRA chocolate box..maybe an implementation of a Finite 
  State Machine or perhaps this is a non sequitir?
  Bedankt,
  Martin 
  __ 
  
  Date: Sat, 18 Jun 2011 18:30:04 -0400
  Subject: The JIRA chocolate box
  From: bimargul...@gmail.com
  To: dev@maven.apache.org
  
  I just looked at the 'blocker' issues. We have a variety of very old
  JIRAs here. None of the ones I looked at have a self-contained test
  case that would can be downloaded, run, and converted to an
  integration test, etc.
  
  What's the policy? My temptation would be to comment on them asking if
  the OP is still interested (in some cases, 5 years later), and, if so,
  can they come up with a repeatable test case, and if not close as not
  a real bug.
  
  I don't mind in some cases doing work to build a test case, but to go
  to all this trouble for a bug that was opened about maven 2.0.x, where
  it may not be that easy to reconstruct the critical components of the
  problem, seems a dubious use of time.
  
  -
  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