Re: [PROPOSAL] Merge the Doxia site into the Maven site
Hervé BOUTEMY wrote:
yes, that's what I meant
my point is that it is then published only on release: either we wait for next
release, or we copy the actual report by hand as if it was generated during
the 1.2 release
I don't get the point: the jira report is always generated for a given
release (not the current development version) as configured in the
report, so it can always be re-generated.
Cheers,
-Lukas
Regards,
Hervé
Le mercredi 28 mars 2012 21:36:47 Dennis Lundberg a écrit :
On 2012-03-28 08:35, Lukas Theussl wrote:
The JIRA report should go into the doxia sub-site (and corresponding
doxia-sitetools, etc), then you link to that from the base site for each
sub-project. WDYT?
Yup, that sounds like a good plan.
-Lukas
Hervé BOUTEMY wrote:
notice that I tried to commit improvements based on previous thoughts
and found in index.apt.vm the following link:
{{{./jira-report.html}Release Notes
for ${doxiaVersion}}}
And since the Jira report isn't available in Doxia base site, if you
simply
remove the actual JIRA report from Doxia site, we're stuck: we need to
add the
report to Doxia base and publish it (either manually for 1.2 or wait
for
1.3)
Regards
Hervé
Le mercredi 28 mars 2012 07:11:00 Hervé BOUTEMY a écrit :
The Doxia site expert is Vincent Siveton: I hope he can express his
opinion
Doxia (base + sitetools + tools) deserves IMHO the dedicated menus
from the
actual Doxia site [1] to let people understand: it can/should be
improved,
but if we merge the Doxia site with regular Maven site, we loose
this
dedicated menu: I don't think this will help.
But you're right with the JIRA report being inappropriate: Doxia
site
doesn't cover only Doxia base, which is [2].
I'm sure that this menu could be made more explicit to help people
understand the relation between Doxia site and each 3 components:
removing
the JIRA configuration is the first step.
Since infra hasn't problems with having a few number of sub-sites
being
treated as dedicated CMS site, I don't see any problem with
maintaining
Doxia site.
To sum up:
- +1 to JIRA configuration removel from Doxia site
- -1 to merging into Maven regular site
Regards,
Hervé
[1] http://maven.apache.org/doxia/index.html
[2] http://maven.apache.org/doxia/doxia/index.html
Le lundi 26 mars 2012 22:13:17 Dennis Lundberg a écrit :
Hi
When I saw some of the commits by Hervé on the CMS integration it
hit
me: Why do we have a separate site module for the Doxia site?
Unless there are any difficult technical hurdles standing in the
way,
why don't we just merge it into the regular Maven site?
I had a quick look at the POM and the only odd things in there is
a
configuration snippet for doxia-maven-plugin that is injected into
the
generated site somewhere, as well as creating some output files
(RTF
and
PDF) from a Doxia book example which are then copied to the
generated
site using maven-antrun-plugin.
There's also a JIRA report in the Doxia site, which in my opinion
is
wrong since Doxia is not one project anymore but rather an
umbrella
like
Plugins or Shared. So the solution would be to remove the report
from
the site and add it to the project sites of Doxia, Doxia Site
Tools and Doxia Tools.
Thoughts?
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [PROPOSAL] Merge the Doxia site into the Maven site
Le jeudi 29 mars 2012 08:11:58 Lukas Theussl a écrit :
Hervé BOUTEMY wrote:
yes, that's what I meant
my point is that it is then published only on release: either we wait
for next release, or we copy the actual report by hand as if it was
generated during the 1.2 release
I don't get the point: the jira report is always generated for a given
release (not the current development version) as configured in the
report, so it can always be re-generated.
true, we're ok on that :)
but the 1.2 release site was generated on 29/4/2011, and is available at 2
urls: latest [1] and 1.2 [2]
a real Jira report integration to this release would mean republishing the
whole site twice, with actual date which is not really the date of the
release.
Then IMHO we have 2 options:
- add the report to 1.2 release site by hacking and publishing the new report
only by hand (with wrong date, but who cares for just one page, or even the
date can be hacked by hand)
- wait for the future 1.3 release, which will contain the report configuration
directly when it is released (no hack)
I'm ok with both options, it's just a question of choice.
Regards,
Hervé
[1] http://maven.apache.org/doxia/doxia/index.html
[2] http://maven.apache.org/doxia/doxia-1.2/index.html
Cheers,
-Lukas
Regards,
Hervé
Le mercredi 28 mars 2012 21:36:47 Dennis Lundberg a écrit :
On 2012-03-28 08:35, Lukas Theussl wrote:
The JIRA report should go into the doxia sub-site (and corresponding
doxia-sitetools, etc), then you link to that from the base site for
each sub-project. WDYT?
Yup, that sounds like a good plan.
-Lukas
Hervé BOUTEMY wrote:
notice that I tried to commit improvements based on previous
thoughts
and found in index.apt.vm the following link:
{{{./jira-report.html}Release Notes
for ${doxiaVersion}}}
And since the Jira report isn't available in Doxia base site, if
you
simply
remove the actual JIRA report from Doxia site, we're stuck: we
need to
add the
report to Doxia base and publish it (either manually for 1.2 or
wait
for
1.3)
Regards
Hervé
Le mercredi 28 mars 2012 07:11:00 Hervé BOUTEMY a écrit :
The Doxia site expert is Vincent Siveton: I hope he can express
his
opinion
Doxia (base + sitetools + tools) deserves IMHO the dedicated
menus
from the
actual Doxia site [1] to let people understand: it can/should be
improved,
but if we merge the Doxia site with regular Maven site, we loose
this
dedicated menu: I don't think this will help.
But you're right with the JIRA report being inappropriate: Doxia
site
doesn't cover only Doxia base, which is [2].
I'm sure that this menu could be made more explicit to help
people
understand the relation between Doxia site and each 3
components:
removing
the JIRA configuration is the first step.
Since infra hasn't problems with having a few number of
sub-sites
being
treated as dedicated CMS site, I don't see any problem with
maintaining
Doxia site.
To sum up:
- +1 to JIRA configuration removel from Doxia site
- -1 to merging into Maven regular site
Regards,
Hervé
[1] http://maven.apache.org/doxia/index.html
[2] http://maven.apache.org/doxia/doxia/index.html
Le lundi 26 mars 2012 22:13:17 Dennis Lundberg a écrit :
Hi
When I saw some of the commits by Hervé on the CMS integration
it
hit
me: Why do we have a separate site module for the Doxia site?
Unless there are any difficult technical hurdles standing in
the
way,
why don't we just merge it into the regular Maven site?
I had a quick look at the POM and the only odd things in there
is
a
configuration snippet for doxia-maven-plugin that is injected
into
the
generated site somewhere, as well as creating some output
files
(RTF
and
PDF) from a Doxia book example which are then copied to the
generated
site using maven-antrun-plugin.
There's also a JIRA report in the Doxia site, which in my
opinion
is
wrong since Doxia is not one project anymore but rather an
umbrella
like
Plugins or Shared. So the solution would be to remove the
report
from
the site and add it to the project sites of Doxia, Doxia Site
Tools and Doxia Tools.
Thoughts?
-
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
-
[PROPOSAL] move doxia-book and doxia-maven-plugin from Doxia base to Doxia Sitetools
while working on the relations between components, I finally found why there was something I didn't understand for a long time about Doxia suite structure: Doxia base contains book support through a plugin, but Doxia base doesn't contain documents support -- it's Doxia Sitetools. So we have a circular dependency: doxia-maven-plugin (from Doxia base) - maven-doxia-tools - Doxia-decoration- model (from Doxia SiteTools) - Doxia base (xhtml, fo and itext) IMHO, doxia-book and doxia-maven-plugin should move to Doxia Sitetools [1]. This won't change the artifacts coordinate, so won't change anything for users. But this should help when explaining Doxia suite structure, which has been difficult for a long time, and having a consequence on versioning decision: should we keep base and Sitetools version at the same level or not? Any objection? Did I miss something? Regards, Hervé [1] http://maven.apache.org/doxia/doxia-sitetools/index.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: How to get the original pom which defines the rule configuration in a child?
So what you are trying to enforce is all of: The property is defined in the current Pom If the interplolated parent defines the property, the value defined in the current Pom is not the same as the inherited value Oh are you comparing the expanded or unexpanded value... Just in case the inherited value contains project coords On Wednesday, 28 March 2012, Mirko Friedenhagen mfriedenha...@gmail.com wrote: Hello, I have written a extra enforcer rule (requitePropertyDiverges), which shall make sure, that properties are overwritten in a child pom. The usecase is as follows: - company super pom CSP - project parent poms PPP1, PPP2 - project child poms PCP1A, PCP1B, PCP2A, PCP2B CSP |- PPP1 |- PCP1A |- PCP1B |- PPP2 |- PCP2A |- PCP2B Now CSP defines an URL in our inhouse wiki as well as a scm connection to our inhouse subversion repository. Developers using the CSP must e.g. override the URL as well as the scm.connection etc. The rule requireProperty allows to see that these properties are set, however as they are set in the CSP they just are enhanced by appending the artifactIds from their children. Right now I have to declare: rules requirePropertyDiverges propertyproject.url/property regexhttp://company/superpom/.*/regex definingGAcompany:superpom/definingGA /requirePropertyDiverges /rules Using project.originalModel as suggested suggested on mojo-dev, I could get rid of regex by checking project.originalModel.url is not null. Now I want to get rid of definingGA as well, which would be the groupId resp. artifactId of the pom defining the rule but how to get the definingGA programmatically? Regards Mirko - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [PROPOSAL] move doxia-book and doxia-maven-plugin from Doxia base to Doxia Sitetools
I agree that they don't belong into core, but I rather thought of moving them into doxia-tools instead. Not sure what is better. OTOH, neither book nor maven-plugin have been maintained (AFAIK) since they were moved out of the sandbox, and IMO they don't work too well. In particular there are problems reported with Maven 3 (DOXIA-438) which I haven't tested, but I wanted to suggest a long time ago to deprecate and ultimately remove them. Also the doxia-test-docs should move somewhere else. -Lukas Hervé BOUTEMY wrote: while working on the relations between components, I finally found why there was something I didn't understand for a long time about Doxia suite structure: Doxia base contains book support through a plugin, but Doxia base doesn't contain documents support -- it's Doxia Sitetools. So we have a circular dependency: doxia-maven-plugin (from Doxia base) - maven-doxia-tools - Doxia-decoration- model (from Doxia SiteTools) - Doxia base (xhtml, fo and itext) IMHO, doxia-book and doxia-maven-plugin should move to Doxia Sitetools [1]. This won't change the artifacts coordinate, so won't change anything for users. But this should help when explaining Doxia suite structure, which has been difficult for a long time, and having a consequence on versioning decision: should we keep base and Sitetools version at the same level or not? Any objection? Did I miss something? Regards, Hervé [1] http://maven.apache.org/doxia/doxia-sitetools/index.html - 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
Planning surefire 2.12.1, surefire integration test problem with the groups expression
I'd like to go for a bug-fix release 2.12.1, since we have a few issues from both 2.11 and 2.12 that should be fixed. We have this interesting problem releated to https://jira.codehaus.org/browse/SUREFIRE-809. A new feature for 2.12, this allows you to select which groups to use with some pretty sophisticated grammar. (John; did any docs get committed for this feature ??) Well the problem is that the grammar uses and ||, and it turns out these are almost *impossible* to escape correctly on the command line. We have 4 IT's in surefire that currently only pass on linux due to this issue. (When specified in the pom, this is no problem. It's when trying to send them in from the command line things get hairy. I haven't even been able to *determine* how to escape for windows cmd.exe) Now none of our command line stuff seems to handle this escaping. The best solution I can come up with is to add AND and OR as synonyms to the grammar ? After all, users wishing to specify from the command line will run into the same problem Since it seems to be undocumented right now, we could consider just *changing* to and/or. I don't really care as long as it can be sent properly from the command line. WDYT ? Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: How to get the original pom which defines the rule configuration in a child?
Hello, right now I retrieve the interpolated values, see https://fisheye.codehaus.org/browse/~br=mfriedenhagen/mojo/branches/mfriedenhagen/extra-enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequirePropertyDiverges.java?r=16217#to98. When the project parent pom PPP overrides the value defined in the company super pom CSP it would be sufficient. Of course should the PPP define it's own rule I want to enforce the children of the PPP must override the property. Regards Mirko On Thu, Mar 29, 2012 at 09:13, Stephen Connolly stephen.alan.conno...@gmail.com wrote: So what you are trying to enforce is all of: The property is defined in the current Pom If the interplolated parent defines the property, the value defined in the current Pom is not the same as the inherited value Oh are you comparing the expanded or unexpanded value... Just in case the inherited value contains project coords On Wednesday, 28 March 2012, Mirko Friedenhagen mfriedenha...@gmail.com wrote: Hello, I have written a extra enforcer rule (requitePropertyDiverges), which shall make sure, that properties are overwritten in a child pom. The usecase is as follows: - company super pom CSP - project parent poms PPP1, PPP2 - project child poms PCP1A, PCP1B, PCP2A, PCP2B CSP |- PPP1 |- PCP1A |- PCP1B |- PPP2 |- PCP2A |- PCP2B Now CSP defines an URL in our inhouse wiki as well as a scm connection to our inhouse subversion repository. Developers using the CSP must e.g. override the URL as well as the scm.connection etc. The rule requireProperty allows to see that these properties are set, however as they are set in the CSP they just are enhanced by appending the artifactIds from their children. Right now I have to declare: rules requirePropertyDiverges propertyproject.url/property regexhttp://company/superpom/.*/regex definingGAcompany:superpom/definingGA /requirePropertyDiverges /rules Using project.originalModel as suggested suggested on mojo-dev, I could get rid of regex by checking project.originalModel.url is not null. Now I want to get rid of definingGA as well, which would be the groupId resp. artifactId of the pom defining the rule but how to get the definingGA programmatically? Regards Mirko - 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: Planning surefire 2.12.1, surefire integration test problem with the groups expression
On 3/29/12 2:09 PM, Kristian Rosenvold wrote: I'd like to go for a bug-fix release 2.12.1, since we have a few issues from both 2.11 and 2.12 that should be fixed. We have this interesting problem releated to https://jira.codehaus.org/browse/SUREFIRE-809. A new feature for 2.12, this allows you to select which groups to use with some pretty sophisticated grammar. (John; did any docs get committed for this feature ??) I'll have to go back and look; I'm not sure. If not, I'll add them. Well the problem is that the grammar uses and ||, and it turns out these are almost *impossible* to escape correctly on the command line. We have 4 IT's in surefire that currently only pass on linux due to this issue. (When specified in the pom, this is no problem. It's when trying to send them in from the command line things get hairy. I haven't even been able to *determine* how to escape for windows cmd.exe) Now none of our command line stuff seems to handle this escaping. The best solution I can come up with is to add AND and OR as synonyms to the grammar ? After all, users wishing to specify from the command line will run into the same problem I thought I had added those synonyms already...have you tried them? I'm 90% sure I tried the grammer with things like A AND B AND NOT(C)... Since it seems to be undocumented right now, we could consider just *changing* to and/or. I don't really care as long as it can be sent properly from the command line. WDYT ? Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [PROPOSAL] move doxia-book and doxia-maven-plugin from Doxia base to Doxia Sitetools
On 2012-03-29 09:13, Lukas Theussl wrote: I agree that they don't belong into core, but I rather thought of moving them into doxia-tools instead. Not sure what is better. This was my thought also. OTOH, neither book nor maven-plugin have been maintained (AFAIK) since they were moved out of the sandbox, and IMO they don't work too well. In particular there are problems reported with Maven 3 (DOXIA-438) which I haven't tested, but I wanted to suggest a long time ago to deprecate and ultimately remove them. If agree that they should be moved, let's start with that. If the target is doxia-tools then let's move them there, prior to the 1.3 release of Doxia and Doxia Sitetools. My feeling about Doxia Tools is that their sub projects shouldn't be released all at the same time. They are individual projects and should have their own release cycles, much like our shared components or plugins. Also I'd like to move maven-doxia-tools from shared over to Doxia. Given its description Assists in using Doxia for site generation and report creation. I think that Sitetools would be a good home for it. Also the doxia-test-docs should move somewhere else. What are those? They look like they could be the basis of an IT suite. Perhaps it should be a completely separate project under the Doxia umbrella? -Lukas Hervé BOUTEMY wrote: while working on the relations between components, I finally found why there was something I didn't understand for a long time about Doxia suite structure: Doxia base contains book support through a plugin, but Doxia base doesn't contain documents support -- it's Doxia Sitetools. So we have a circular dependency: doxia-maven-plugin (from Doxia base) - maven-doxia-tools - Doxia-decoration- model (from Doxia SiteTools) - Doxia base (xhtml, fo and itext) IMHO, doxia-book and doxia-maven-plugin should move to Doxia Sitetools [1]. This won't change the artifacts coordinate, so won't change anything for users. But this should help when explaining Doxia suite structure, which has been difficult for a long time, and having a consequence on versioning decision: should we keep base and Sitetools version at the same level or not? Any objection? Did I miss something? Regards, Hervé [1] http://maven.apache.org/doxia/doxia-sitetools/index.html - 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 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
SCM initRepo method
Any ideas of how to get to initialised loggers (from the plexus container)
in this method?
My only option so far, is a new DefaultLog().
I'd perfer to use the normal ConsoleLogger etc as set up by the container,
and available to any descendants of the AbstractCommand...
It's just a nice to have.
Also, anyone object to me adding a removeRepo method to ScmTckTestCase.java?
IE:
/**
* This method is available to those SCM clients that need to perform
* a cleanup at the end of the tests. It is needed when server side
* operations are performed, or the check out dirs are outside
* of the normal target directory.
*/
public void removeRepo()
throws Exception
{
}
/**
* Provided to allow removeRepo() to be called.
* @see junit.framework.TestCase#tearDown()
*/
@Override
protected void tearDown()
throws Exception
{
super.tearDown();
removeRepo();
}
I'm thinking that the jazz provider (when scm provides a delete workspace
command...) and possibly the other server based SCM's may want this,
ClearCase, etc might benefit.
It's just a nice to have. And in ScmTckTestCase is the right place for it,
as that is where initRepo() lives and is called by setUp().
-Chris
ChangeLogCommandTckTest
Argh. I'm really struggling with this bit int he base code: //We should have one log entry for the initial repository ChangeLogScmResult result = provider.changeLog( getScmRepository(), fileSet, null, null, 0, (ScmBranch) null, null ); assertTrue( result.getProviderMessage(), result.isSuccess() ); assertEquals( 1, result.getChangeLog().getChangeSets().size() ); It is expecting one change log entry from the intially checked out repo (from initRepo). That new repo, from my understanding, contains a set of files, pom.xml, readme.txt, src/main/java/Foo.java etc. The issue that I can not get around, is that the very best that we can do, is to get two changesets (aka revisions). the implicit Initial - that I can not get rid of. That is the initial emptry component. Then there is the second changeset that I've added all of the expected files too. Suggestions as to how to work around this? :-) I'd rather not loose the test just because of this. -Chris
[jira] Subscription: Design Best Practices
Issue Subscription
Filter: Design Best Practices (24 issues)
Subscriber: mavendevlist
Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
https://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
https://jira.codehaus.org/browse/MNG-612
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-4656Declarative plugins similar to jsp tags or jsf composites
https://jira.codehaus.org/browse/MNG-4656
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
MNG-868 Use uniform format for properties and other tags
https://jira.codehaus.org/browse/MNG-868
MNG-1425best practices: the location of configuration files vs resources
https://jira.codehaus.org/browse/MNG-1425
MNG-1463best practices: plugin inheritance for a multi project build
https://jira.codehaus.org/browse/MNG-1463
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-1569Make build process info read-only to mojos, and provide mechanism
for explicit out-params for mojos to declare
https://jira.codehaus.org/browse/MNG-1569
MNG-1867deprecate system scope, analyse other use cases
https://jira.codehaus.org/browse/MNG-1867
MNG-1423best practices: setting up multi-module build
https://jira.codehaus.org/browse/MNG-1423
MNG-1468best practices: version management in multi project builds
https://jira.codehaus.org/browse/MNG-1468
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
