[jira] Michael Osipov mentioned you (JIRA)
[ https://issues.apache.org/jira/browse/MPOM-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov mentioned you on MPOM-40 --- [~mavendevlist], unfortunately JSR 305 has virtually been ceased and Google's reference implementation is offline. Do you want to drop any effect on this topic and close this issue? > Key: MPOM-40 > View Online: https://issues.apache.org/jira/browse/MPOM-40 > Add Comment: https://issues.apache.org/jira/browse/MPOM-40#add-comment Hint: You can mention someone in an issue description or comment by typing "@" in front of their username. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[jira] Michael Osipov mentioned you (JIRA)
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov mentioned you on MCHECKSTYLE-314
---
This is merely {{@Execute( goal = "checkstyle" )}} in
{{CheckstyleViolationCheckMojo}}. If ([~mavendevlist]) does not oppose to
that, I would go ahead and commit this change.
> Key: MCHECKSTYLE-314
> View Online: https://issues.apache.org/jira/browse/MCHECKSTYLE-314
> Add Comment:
> https://issues.apache.org/jira/browse/MCHECKSTYLE-314#add-comment
Hint: You can mention someone in an issue description or comment by typing "@"
in front of their username.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MNG-5878) Subversion SCM module URLs incorrectly build when module name != artifactId
[
https://issues.apache.org/jira/browse/MNG-5878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14715970#comment-14715970
]
Jason van Zyl commented on MNG-5878:
Seems perfectly reasonable.
> Subversion SCM module URLs incorrectly build when module name != artifactId
> ---
>
> Key: MNG-5878
> URL: https://issues.apache.org/jira/browse/MNG-5878
> Project: Maven
> Issue Type: New Feature
> Components: Inheritance and Interpolation
>Affects Versions: 3.3.3
>Reporter: Michael Osipov
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MNG-5878) Subversion SCM module URLs incorrectly build when module name != artifactId
[
https://issues.apache.org/jira/browse/MNG-5878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14715455#comment-14715455
]
Hervé Boutemy commented on MNG-5878:
feature added in branch
[812e1e9d|http://git-wip-us.apache.org/repos/asf/maven/commit/812e1e9d]
principe is to define {{project.directory}} property in child pom.xml that will
be used instead of artifactId when defined
(and this property in not inherited to further childs of child)
> Subversion SCM module URLs incorrectly build when module name != artifactId
> ---
>
> Key: MNG-5878
> URL: https://issues.apache.org/jira/browse/MNG-5878
> Project: Maven
> Issue Type: New Feature
> Components: Inheritance and Interpolation
>Affects Versions: 3.3.3
>Reporter: Michael Osipov
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14698136#comment-14698136
]
Stephen Connolly commented on MPIR-234:
---
Say you are looking at a projects site.
You say, "oh where's the source code".
You go to the "source repository" report for that module.
It tells you: "this module is part of the XYZ repo. You can only checkout that
SCM type's repos in full... Not a sub module only. To check out the smallest
individual unit use the following command: . Then to get to this module: cd
abc/def/ghi"
That is what should be in a sub module's site for Git/Accurev/etc.
Why? Because navigating module sites to find the parent can be tricky... Even
when it isn't, finding the module within the resulting checkout can be tricky
(we had an Accurev repo with 40+ modules back in 2008 at a former employers
before we migrated to SVN)
Sent from my iPhone
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Comment Edited] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14698029#comment-14698029
]
Chris Graham edited comment on MPIR-234 at 8/15/15 2:16 AM:
>> It should not be displayed, or inferred from any other (ie sub module)
>> location.
>If you are looking at a module's site and you have to go changing it, you want
>to know how to check out that module.
Perhaps I was not clear, or you missed my point.
Which is: In some SCM's checking out a sub module, it is impossible. It's an
all or nothing operation, not a cherry picking one.
>So there should be a "Source Repository" for sub-modules.
No there should not. Or, at best, it is only meaningful for those SCM's that
can support it.
All you are doing in your example is cloning the entire repo [you cann't
not] and then checking out (-b) the branch. How is this a sub module?
was (Author: chrisgwarp):
>> It should not be displayed, or inferred from any other (ie sub module)
>> location.
>If you are looking at a module's site and you have to go changing it, you want
>to know how to check out that module.
Perhaps I was not clear, or you missed by point.
Which is: In some SCM's checking out a sub module, it is impossible. It's an
all or nothing operation, not a cherry picking one.
>So there should be a "Source Repository" for sub-modules.
No there should not. Or, at best, it is only meaningful for those SCM's that
can support it.
All you are doing in your example is cloning the entire repo [you cann't
not] and then checking out (-b) the branch. How is this a sub module?
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
> ----
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14698032#comment-14698032
]
Chris Graham commented on MPIR-234:
---
+1
Making the URL's longer just increases the complexity of the existing parsing
code (which in some cases, is already complex enough).
Add more elements.
And if your going to do that, I'd say that it's time to start looking at SCM
API 2.0 and making it MORE abstracted (not less).
It's not all about Git...
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14698029#comment-14698029
]
Chris Graham commented on MPIR-234:
---
>> It should not be displayed, or inferred from any other (ie sub module)
>> location.
>If you are looking at a module's site and you have to go changing it, you want
>to know how to check out that module.
Perhaps I was not clear, or you missed by point.
Which is: In some SCM's checking out a sub module, it is impossible. It's an
all or nothing operation, not a cherry picking one.
>So there should be a "Source Repository" for sub-modules.
No there should not. Or, at best, it is only meaningful for those SCM's that
can support it.
All you are doing in your example is cloning the entire repo [you cann't
not] and then checking out (-b) the branch. How is this a sub module?
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14697908#comment-14697908
]
Benson Margulies commented on MPIR-234:
---
I am going to put in a fruitless reminder that it would be a lot cleaner to add
more elements under than to keep making the URL longer and longer.
Everyone says, 'oh, we can't do that, we might bust some crappily-written tool
that reads POMs.' I think we should just rev the POM schema to allow for
arbitrary 'foreign namespace' elements, and use namespace for this kind of
extension, and the tools that are still using 15-year-old XML parsing
technology can go ahead and croak.
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14697836#comment-14697836
]
Hervé Boutemy commented on MPIR-234:
yes SCM urls can be really complex
core needs to remain simple and let MPIR (or other tools) interpret the scm
value to dispatch every information to proper usable info
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14697645#comment-14697645
]
Robert Scholte commented on MPIR-234:
-
I really wonder if we should call it a URL. IMHO it is a connection String, the
scmSpecific part is not unified.
We should question: what does the scm section contain and where is it used for?
Git is an example where in doesn't only contain the location, but it can also
contain fetch+push information. So here it also contains the release strategy.
Let's assume that we want to construct the connection, because for some SCMs it
makes more sense to add it somewhere in the middle (e.g. the connection uses an
additional arguments like
[h2|http://www.h2database.com/html/features.html#database_url])
We would need to use as extensions, which I don't like for Maven core.
So what do we gain by inheriting + expanding it for modules: reports are much
better in creating proper instructions. I still think it has introduced too
much complexity for the effective pom for modules which doesn't add true value.
{quote}
"So the question becomes what do we put on the Source Repository page for a
module without an explicit section."
We don't. Either N/A or See Root SCM URL.
{quote}
I'd say: leave it up to the SCM implementation, they know the best answer. IIRC
with SoftwareAG the SCM and IDE are that much integrated with each other that
it doesn't make sense to try to access it on filesystem.
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14697360#comment-14697360
]
Hervé Boutemy commented on MPIR-234:
bq. NIT: those checkout instructions do not checkout the branch that the report
was generated from
if already did that in MPIR-291, available in MPIR 2.8
the only mising part is that, in MPIR-290, I don't display {{cd
maven-surefire/surefire-api}}
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Comment Edited] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14697360#comment-14697360
]
Hervé Boutemy edited comment on MPIR-234 at 8/14/15 4:53 PM:
-
bq. NIT: those checkout instructions do not checkout the branch that the report
was generated from
I already did that in MPIR-291, available in MPIR 2.8
the only mising part is that, in MPIR-290, I don't display {{cd
maven-surefire/surefire-api}}
was (Author: hboutemy):
bq. NIT: those checkout instructions do not checkout the branch that the report
was generated from
if already did that in MPIR-291, available in MPIR 2.8
the only mising part is that, in MPIR-290, I don't display {{cd
maven-surefire/surefire-api}}
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14696991#comment-14696991
]
Stephen Connolly commented on MPIR-234:
---
> It should not be displayed, or inferred from any other (ie sub module)
> location.
If you are looking at a module's site and you have to go changing it, you want
to know how to check out *that module*.
So there should be a "Source Repository" for sub-modules.
So let's take a concrete example: Surefire
http://maven.apache.org/surefire/source-repository.html
I have no major complaints with the above page:
This has sub-module within the same GIT repo... let's pick one of them:
http://maven.apache.org/surefire/surefire-api/source-repository.html
What I want is that the fact that this is a sub-component of the main
repository should be called out more explicitly, e.g.
{code}
$ git clone https://git-wip-us.apache.org/repos/asf/maven-surefire.git
$ cd maven-surefire/surefire-api
{code}
would be better checkout instructions.
NIT: those checkout instructions do not checkout the branch that the report was
generated from... so better yet would be
{code}
$ git clone -b surefire-2.18.1_vote-1
https://git-wip-us.apache.org/repos/asf/maven-surefire.git
$ cd maven-surefire/surefire-api
{code}
On the other hand, it is really annoying with SVN to always be having the URL
in the report as that of the tag... really great would be to give the links for
the branch the release was cut from as well as the links to the tag
So you'd have
{code}
The source can be checked out anonymously from GIT. To checkout the source code
that for this release use the following command:
$ git clone -b surefire-2.18.1_vote-1
https://git-wip-us.apache.org/repos/asf/maven-surefire.git
$ cd maven-surefire/surefire-api
Alternatively if you want to check out the development stream you can use the
following command:
$ git clone https://git-wip-us.apache.org/repos/asf/maven-surefire.git
$ cd maven-surefire/surefire-api
{code}
Now that page also brings up an additional topic... namely the "Web Access"
section.
The Web Access section currently assumes that you will navigate the repo
exactly like the file system... this is not entirely an unreasonable
assumption... but it need not remain true, for example there are some web
browsers that use a query parameter for the repo path... so the path needs to
be encoded appropriately.
To me it would make more sense to have the Web Access link generated by a
plugable strategy and injected into the report using a role-hint...
so if I inject the {{github}} into the report... well
that assumes that GIT urls are for GitHub / GitHub enterprise and can compute
the web access url from the git url... much less for the user to configure and
therefore much less to go wrong.
If the role is not injected, we could ask all providers to sniff check... so a
github.com URL would be auto-sniffed by the github implementation and bonus the
user didn't have to configure anything... an implementation of {{none}} would
suppress the link entirely for those people who feel the need to hide.
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14696274#comment-14696274
]
Chris Graham commented on MPIR-234:
---
"So the question becomes what do we put on the Source Repository page for a
module without an explicit section."
We don't. Either N/A or See Root SCM URL.
This has just really driven it home for me: In SCM's like RTC/Clearcase/Accurev
(and a flattened Git), the concept of a SCM URL for a submodule makes no sense
at all. It is not possible. When you check out from these, it is an all or
nothing approach. You can not cherry pick the bits you want.
So, from my SCM agnostic POV, the poms SCM section is only of value (and valid)
in a a root (release) pom. It should not be displayed, or inferred from any
other (ie sub module) location.
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14696261#comment-14696261
]
Chris Graham commented on MPIR-234:
---
"it's a general contract that should be enforcer for every supported scm
(http://maven.apache.org/scm/scms-overview.html ): scm url should support going
from a parent to a child Maven module by adding the path to the url"
One that made perfect sense in the CVS/SVN days, and these core concepts have
been etched in stone in the Maven & SCM thinking. However, this is not always
possible with all SCM's.
The base assumption above, does not always hold true for Accurev, ClearCase,
RTC, and depending on how you set it up, possibly even Git.
Git can be nested, with a root pom (and blah statements), or
flattened (and ../blah statements). If flattened, the
assumption above does not told true.
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14696247#comment-14696247
]
Chris Graham commented on MPIR-234:
---
I see a general drift towards a Git centric discussion, which is understandable
as most of us use it. However, the entire Maven (and particularly the SCM APIs)
implementation (and therefore thinking) are meant to be SCM agnostic.
As for Flattened/Nested. Let me try to explain (I was rushed). When you perform
a release with MRP, you perform a tagging operation. With SVN, it's a path
within the repo. We only tag our own bit. In Git, the entire repo is tagged,
and in RTC, the Component has a Snapshot taken. In SVN you can check out just a
path into your WC - you can even cherry pick from where and create your own
working structure. This falls down as the MRP can not reconstruct this, hand
made, cherry picked dir structure; it can only check out one point, and thus
lends itself to a nest structure (if not enforces it). In Git, you clone and
entire repo, and in RTC/Clearcase you load an entire Component. RTC, like Git,
can have multiple folders worth (I think of them as eclipse projects - as
that's the space I work in - esp with RTC) available. In Git, it's easy (and
makes sense to) have a root pom and nested modules, an a dir format supported
by the MRP. In RTC, it's impossible to do with the Eclipse client to place a
pom.xml in the root of a component (although it is not forbidden from the
underlying SCM impl, it may be possible from the SCM command line). It really
wants one or more folders (ie eclipse projects) in the root level of a
Component. When you check them out (SCM load in rtc terms) you get all of the
projects/folders into the one check out dir. This is kind of forced by the
eclipse client as it looks for .project files when it checks out. So you end up
with a flattened structure. In all of the RTC examples I've work with, esp when
working with the MRP and the RTC SCM integration, I've always nested the
projects and manually created links in Eclipse. Most RTC based devs either do
not know a) you can actually do this, or b) do not want too. There is no
Project Set Support for RTC SCM in eclipse (although it's been requested). Does
that all make sense or have I actually made things worse?
In terms of "ignore scm section" that was more a reference to the
help:effective-pom comment, where the scm section of the pom is output in all
pom's not just the root one. I thought that the discussion may have been
heading in the direction of actually using the scm sections in non root poms,
as I seem to remember that there is/was a request to actually implement using
the sub module poms (non root ones) scm section, so you'd perform multiple
check out operations (to make the hand crafted, cherry picked option listed
above. This is not a thing that I am a fan of.
My point here, is that I don't think that the scm section should exist, or be
used, or displayed for anything other than the root pom.
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14694875#comment-14694875
]
Hervé Boutemy commented on MPIR-234:
notice that this is what I already did in MPIR-290: display only a part of the
scm git url in the report
the only weak part is that the algorithm to detect repo part from path part is
"index of '.git'"
but this is the update that made me think that we just need a clearly defined
separator for this info
and everything wil work well: no change in Maven core (keep path behaviour),
and update in MPIR scm report to better parse the scm url and display parts
nicely
and of course, update Maven scm to document the new url format (addition of
this separator to path) and improve the url parser
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14694289#comment-14694289
]
Hervé Boutemy commented on MPIR-234:
finally removing scm info from effective model is IMHO throwing baby with bath
while extending Maven scm urls to make sure that they contain path in repo
would not be that complex (and would ne require any change in Maven core)
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Issue Comment Deleted] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated MPIR-234:
---
Comment: was deleted
(was: finally removing scm info from effective model is IMHO throwing baby with
bath
while extending Maven scm urls to make sure that they contain path in repo
would not be that complex (and would ne require any change in Maven core))
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14694288#comment-14694288
]
Hervé Boutemy commented on MPIR-234:
finally removing scm info from effective model is IMHO throwing baby with bath
while extending Maven scm urls to make sure that they contain path in repo
would not be that complex (and would ne require any change in Maven core)
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14694267#comment-14694267
]
Hervé Boutemy commented on MPIR-234:
bq. So the question becomes what do we put on the Source Repository page for a
module without an explicit section. Well what we do is we copy verbatim
the SCM checkout instructions from the release root and add cd path/to/module
at the end of those instructions.
ok, so you're talking about the MPIR scm report: I'm completely +1 on this
the MPIR scm report does not display scm url verbatim: it interprets it to
display human-readable useful info
this doesn't tall anything about effective scm model value: what I tell is that
the model value can -- or even should -- contain the path in repository info:
the scm report will display this info as you suggested
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14693980#comment-14693980
]
Robert Scholte commented on MPIR-234:
-
I created MNG-5870 for adjustments on core.
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14693414#comment-14693414
]
Stephen Connolly commented on MPIR-234:
---
[~hboutemy] So my point is that the scm: URLs are not something that users
understand.
Technically also it is almost impossible with an URL like:
{code}
scm:svn:http://[username[:password]@]server_name[:port]/path/to/repository/path/inside/repository
{code}
to determine where the {{path/to/repository}} ends and the
{{path/inside/repository}} starts.
The only reason you need to determine this is when you are dealing with
something where the {{path/inside/repository}} is something other than the
empty string.
The empty string case is easy, because you can expect to check-out the whole
project.
Once you are dealing with a sub-path of the repository you cannot check out
just that sub-path (ok so subversion and CVS are special cases... but why
should we make everything else adapt to these two special cases)
So then we get to my proposal.
I say if there is an explicit {{}} section in a pom file *then* that pom
file represents a *release root*.
You can expect to check out that SCM URL and get a whole chunk of the project
that can be built independently from other projects.
If there is no explicit {{}} section in the pom then you are not expected
to be able to check out just that sub-module on its own.
So the question becomes what do we put on the Source Repository page for a
module without an explicit {{}} section. Well what we do is we copy
*verbatim* the SCM checkout instructions from the release root and add {{cd
path/to/module}} at the end of those instructions.
There is a separate question to be answered about how things like Central's
validation rules requiring a section in a pom file would work for those
cases where inheritance does not follow aggregation... but since inheritance
not following aggregations will require somebody to configure the
{{groupId:artifactId}} of the release root (and possibly the relative path from
the release root) in the report, we could just punt and ignore an explicit
{{}} section if there is a configured release root.
For model version 5, we should add a path from the scm connection as an element
in the {{scm}} section so that url mangling never has to apply.
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Comment Edited] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14692588#comment-14692588
]
Hervé Boutemy edited comment on MPIR-234 at 8/12/15 12:07 AM:
--
I don't understand the idea of "report configuration"
but I completely agree with the idea of scm configuration that should be
necessary only for release root
and of course, no scm specific logic in Maven core
and that's what we get with extended git scm url
it's a general contract that should be enforcer for every supported scm
(http://maven.apache.org/scm/scms-overview.html ): scm url should support going
from a parent to a child Maven module by adding the path to the url
in fact, our svn documentation saying
{{scm:svn:http://[username[:password]@]server_name[:port]/path_to_repository}}
IMHO has always been misleading: it should probably be
{{scm:svn:http://[username[:password]@]server_name[:port]/path_to_repository/path_inside_repository}}
the difference between svn and scms causing issues currently is that the
separation between path_to_repository and path_inside_repository is really
enforced: hence the separator that has to be added to clearly mark the
difference
was (Author: hboutemy):
I don't understand the idea of "scm configuration"
but I completely agree with the idea of scm configuration that should be
necessary only for release root
and of course, no scm specific logic in Maven core
and that's what we get with extended git scm url
it's a general contract that should be enforcer for every supported scm
(http://maven.apache.org/scm/scms-overview.html ): scm url should support going
from a parent to a child Maven module by adding the path to the url
in fact, our svn documentation saying
{{scm:svn:http://[username[:password]@]server_name[:port]/path_to_repository}}
IMHO has always been misleading: it should probably be
{{scm:svn:http://[username[:password]@]server_name[:port]/path_to_repository/path_inside_repository}}
the difference between svn and scms causing issues currently is that the
separation between path_to_repository and path_inside_repository is really
enforced: hence the separator that has to be added to clearly mark the
difference
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14692588#comment-14692588
]
Hervé Boutemy commented on MPIR-234:
I don't understand the idea of "scm configuration"
but I completely agree with the idea of scm configuration that should be
necessary only for release root
and of course, no scm specific logic in Maven core
and that's what we get with extended git scm url
it's a general contract that should be enforcer for every supported scm
(http://maven.apache.org/scm/scms-overview.html ): scm url should support going
from a parent to a child Maven module by adding the path to the url
in fact, our svn documentation saying
{{scm:svn:http://[username[:password]@]server_name[:port]/path_to_repository}}
IMHO has always been misleading: it should probably be
{{scm:svn:http://[username[:password]@]server_name[:port]/path_to_repository/path_inside_repository}}
the difference between svn and scms causing issues currently is that the
separation between path_to_repository and path_inside_repository is really
enforced: hence the separator that has to be added to clearly mark the
difference
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Comment Edited] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14682341#comment-14682341
]
Robert Scholte edited comment on MPIR-234 at 8/11/15 7:31 PM:
--
The more I think about it, the more I like the idea of [~stephenc].
- No scm specific logic in Maven core.
- Relying on the scm of the parent isn't always correct. Instead only a moduled
pom can calculate the actual connection for its modules.
- For the m-release-p it'll be much easier: no scm on the execution root, then
it is not a valid release root. This will prevent a lot of issues when starting
a new Maven project which fail when tagging due to incorrect inheritance.
This is actually one of the things I tried to fix with maven-project-utils'
[ScmUtils.java|http://svn.apache.org/viewvc/maven/shared/trunk/maven-project-utils/src/main/java/org/apache/maven/shared/project/utils/ScmUtils.java?view=markup].
If we want to expose the connection for submodules like now is done for svn, we
could adjust the pom.xml during a release: all poms are touched anyway and
m-release-p already has the required scm dependency so the calculation should
be simple.
was (Author: rfscholte):
The more I think about it, the more I like the idea of [~stephenc].
- No scm specific logic in Maven core.
- Relying on the scm of the parent isn't always correct. Instead only a moduled
pom can calculate the actual connection for its modules.
- For the m-release-p it'll be much easier: no scm on the execution root, then
it is not a valid release root. This will prevent a lot of issues when starting
a new Maven project which fail when tagging due to incorrect inheritance.
This is actually one of the things I tried to fix with maven-project-utils'
[ScmUtils.java|http://svn.apache.org/viewvc/maven/shared/trunk/maven-project-utils/src/main/java/org/apache/maven/shared/project/utils/ScmUtils.java?view=markup].
If we want to expose the connection for submodules like now is done for svn, we
could adjust the pom.xml during a release: all poms are touched anyway and
m-release-p already has the required scm dependency so the calculation should
be simple.
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14682341#comment-14682341
]
Robert Scholte commented on MPIR-234:
-
The more I think about it, the more I like the idea of [~stephenc].
- No scm specific logic in Maven core.
- Relying on the scm of the parent isn't always correct. Instead only a moduled
pom can calculate the actual connection for its modules.
- For the m-release-p it'll be much easier: no scm on the execution root, then
it is not a valid release root. This will prevent a lot of issues when starting
a new Maven project which fail when tagging due to incorrect inheritance.
This is actually one of the things I tried to fix with maven-project-utils'
[ScmUtils.java|http://svn.apache.org/viewvc/maven/shared/trunk/maven-project-utils/src/main/java/org/apache/maven/shared/project/utils/ScmUtils.java?view=markup].
If we want to expose the connection for submodules like now is done for svn, we
could adjust the pom.xml during a release: all poms are touched anyway and
m-release-p already has the required scm dependency so the calculation should
be simple.
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14681589#comment-14681589
]
Mirko Friedenhagen commented on MPIR-234:
-
In regards to [~hboutemy] comment: the simple way of adding artifactId only
works for some versioning systems (I only know CVS and Subversion here, maybe
others as well, but IMO CVS is a dead horse). I would consider git and
subversion to be the dominant VCS nowadays and these two differ.
I like [~stephenc]'s approach to take a defined scm section as a hint, that
this is the root of a project and would not fiddle with any paths from thereon.
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14681565#comment-14681565
]
Stephen Connolly commented on MPIR-234:
---
Perhaps {{scmParent}} would be better than individual ones for
{{parent.groupId}} and {{parent.artifactId}} but the risk is that people would
try and specify the version also... which would be incorrect IMHO... though you
could just ignore anything after a second {{:}} ;-)
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14681564#comment-14681564
]
Stephen Connolly commented on MPIR-234:
---
> Argh! hit Add too soon
I wonder should we be reporting an inferred SCM location at all when the SCM is
inherited *and* equal to the parent's (to catch the case where somebody uses EL
to define the SCM locations of the child projects, e.g.)
{code}
scm:git:ssh://g...@github.com/myorg/${project.artifactId}.git
scm:git:ssh://g...@github.com/myorg/${project.artifactId}.git
{code}
Though, even there I feel that the SCM section should only be present for
*release roots*. In fact in some custom tooling we have at my day job we use
the presence of the SCM section in the {{pom.xml}} as an indicator that this is
a release root.
I would much rather have the report of a project that is inheriting it's SCM
section say "Go to XYZ and check it out to get the source" rather than try and
infer a sub-path.
This is good for a number of reasons, not least being that when looking at the
*master* branch docs, if you do not check out the release root you will have
unresolved -SNAPSHOT dependencies.
Now there are obviously some complications, such as where inheritance does not
follow aggregation. In those cases I think it would be reasonable for people to
configure the report with the pointer to the aggregating release root project
(by {{G:A}} and then resolved from the reactor falling back to the repos) so
that you can display the correct SCM details.
If we go with this approach, we gain that the {{}} element should only be
present for release roots and we can kill off the crazy inference logic
completely... so basically the report's configuration would have perhaps three
values:
{code}
...
...
...
{code}
If the {{scmParentGroupId}} or {{scmParentArtifactId}} are unset then you walk
up the {{parent}} tree until you find a {{parent}} with a {{}} section...
you can then walk back down trying to find the relative path using {{}}
references if you cannot find it then I would just give up... and assume that
an unspecified {{scmParentRelativePath}} is unknown.
Then the page would basically say,
> To get the source code checkout: and cd
>
That should work for everything. Where the report is incorrect the users can
either add the configuration to the report or add an explicit {{}} section.
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Comment Edited] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14681545#comment-14681545
]
Stephen Connolly edited comment on MPIR-234 at 8/11/15 9:49 AM:
Well in general I see the SCM section being inherited as being an indication
that the module is intended to be checked out with the parent and not
independently.
Now there are some differences... for example when somebody includes
{{project.artifactId}}
was (Author: stephenc):
Well in general I see the SCM section being inherited as being an indication
that the module is intended to be checked out with the parent and not
independently.
Now there are some differences... for example when somebody includes {{
${project.artifactId} }}
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14681545#comment-14681545
]
Stephen Connolly commented on MPIR-234:
---
Well in general I see the SCM section being inherited as being an indication
that the module is intended to be checked out with the parent and not
independently.
Now there are some differences... for example when somebody includes {{
${project.artifactId} }}
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14681370#comment-14681370
]
Hervé Boutemy commented on MPIR-234:
we need more generic discussion, not only git oriented: so useful comment
I don't understand this flattened vs nested structure feature, particularly
when you compare to git
And I don't understand what you call "ignore SCM section"
the quesion is: what is the best algorithm (simple and generic being very
valuable properties for "best" notion) to calculate the SCM section of a model
when it is empty in the POM but not in parent?
currently, the best algorithm is "parent url + /artifactid"
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14679583#comment-14679583
]
Chris Graham commented on MPIR-234:
---
Just too add some more fuel to the fire. :)
Jazz, like Git, ClearCase etc, can be used in a nested or flattened structure.
There would have to be an option to set it or not.
As another comment, shouldn't the SCM section actually be removed/ignored from
sub modules anyway?
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14679270#comment-14679270
]
Hervé Boutemy commented on MPIR-234:
yes, url is a different story from connection/developerConnection
to me, this Jira issue is more about connection/developerConnection than url
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14679242#comment-14679242
]
Robert Scholte commented on MPIR-234:
-
We need to keep in mind that there's a difference between in input (the values
in the scm-section of the pom) and the output (e.g. scm report). The input is
restricted to a single line and it should point to the exact location. The
output can transform this to a multiline instruction.
The extended version of the scm:git pattern looks good to me, but we also need
to keep in mind that there is something like submodules. AFAIK submodules can
be a location to tag from, whereas the {{path_in_repository}} probably not.
Does it actually matter?
So this might work for the connection for git, but the URL is a completely
different story. I'm afraid that this can't be solved with expressions, unless
we introduce a prefix, so we can again separate input from output.
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14679189#comment-14679189
]
Hervé Boutemy commented on MPIR-234:
I'm not a gitweb expert: I don't know if it can support human readable urls.
But clearly, at the moment, the gitweb conf at ASF won't support classical urls
where you add path at the end of the url. But github does a good job at it
POM contains some non build information, like urls, developers information, and
so on.
Until recently, urls were not a problem, when url of a subdirectory = url of
parent + /subdir = what everybody expected
I hate having to change whole Maven feature set just because one SCM has some
bizarre urls on some installations, then require complex algorithms to match
bizarre expectations
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Comment Edited] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14679150#comment-14679150
]
Michael Osipov edited comment on MPIR-234 at 8/9/15 1:48 PM:
-
Would that actually work with Gitweb? Look how Gitweb creates browsable URLs:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=tree;f=maven-compat
Hervé, I like your simple idea but I do not think that SCM handling should be
in the core at all. Core is responsible for building and not SCM-related stuff.
Who uses SCM information? MREALEASE (+ MSCM) and MSITE + reporting plugins. If
so, they should handle this. I would favor some (build) extension which is
plugged into core which properly calculates SCM anon/dev URLs as well as web
URL. Additionally, a separate improvement which can properly calculate a site
URL (not related to SCM imho). Maven can be shipped with Git and Subversion
extensions by default.
was (Author: michael-o):
Would that actually work with Gitweb? Look how Gitweb creates browsable URLs:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=tree;f=maven-compat
Hervé, I like your simple idea but I do not think that SCM handling should be
in the core at all. Core is responsible for building and not SCM-related stuff.
Who uses SCM information? MREALEASE (+ MSCM) and MSITE + reporting plugins. If
so, they should handle this. I would favor some (build) extension which is
plugged into core which properly calculates SCM anon/dev URLs as well as web
URL. Additionally, a separate improvement which can properly calculate a site
URL (not related to SCM imho). Maven can be shipped with Git and Subverion
extensions by default.
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Comment Edited] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14679150#comment-14679150
]
Michael Osipov edited comment on MPIR-234 at 8/9/15 1:48 PM:
-
Would that actually work with Gitweb? Look how Gitweb creates browsable URLs:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=tree;f=maven-compat
Hervé, I like your simple idea but I do not think that SCM handling should be
in the core at all. Core is responsible for building and not SCM-related stuff.
Who uses SCM information? MREALEASE (+ MSCM) and MSITE + reporting plugins. If
so, they should handle this. I would favor some (build) extension which is
plugged into core which properly calculates SCM anon/dev URLs as well as web
URL. Additionally, a separate improvement which can properly calculate a site
URL (not related to SCM imho). Maven can be shipped with Git and Subverion
extensions by default.
was (Author: michael-o):
Would that actually work with Gitweb? Look how Gitweb creates browsable URLs:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=tree;f=maven-compat
Hervé, I like your simple idea but I do not think that SCM handling should be
in the core at all. Core is responsible for building and not SCM-related stuff.
Who uses SCM information? MREALEASE (+ MSCM) and MSITE + reporting plugins. If
so, they should handle this. I would favor some (build) extension which is
plugged into core which properly calculates SCM anon/dev URLs as well as web
URL. Additionally, a separate improvement which can properly calculate a site
URL (not related to SCM imho).
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14679150#comment-14679150
]
Michael Osipov commented on MPIR-234:
-
Would that actually work with Gitweb? Look how Gitweb creates browsable URLs:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=tree;f=maven-compat
Hervé, I like your simple idea but I do not think that SCM handling should be
in the core at all. Core is responsible for building and not SCM-related stuff.
Who uses SCM information? MREALEASE (+ MSCM) and MSITE + reporting plugins. If
so, they should handle this. I would favor some (build) extension which is
plugged into core which properly calculates SCM anon/dev URLs as well as web
URL. Additionally, a separate improvement which can properly calculate a site
URL (not related to SCM imho).
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Comment Edited] (MPIR-312) Subversion SCM module URLs incorrectly build when module name != artifactId
[
https://issues.apache.org/jira/browse/MPIR-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14679111#comment-14679111
]
Hervé Boutemy edited comment on MPIR-312 at 8/9/15 11:54 AM:
-
a new idea: during build, there is already the algorithm to use local path,
then values in effective pom are ok even if module directory != artifactId
for artifacts from repo, perhaps we could use flatten-maven-plugin to detect
that the "module directory == artifactId" convention is not used, then expand
local path-calculated info flattened pom.xml?
was (Author: hboutemy):
a new idea: during build, there is already the algorithm to use local path
for artifacts from repo, perhaps we could use flatten-maven-plugin to detect
that the "module directory = artifactId" convention is not used then expand
calculated info flattened pom.xml
> Subversion SCM module URLs incorrectly build when module name != artifactId
> ---
>
> Key: MPIR-312
> URL: https://issues.apache.org/jira/browse/MPIR-312
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.7
>Reporter: Michael Osipov
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Comment Edited] (MPIR-312) Subversion SCM module URLs incorrectly build when module name != artifactId
[
https://issues.apache.org/jira/browse/MPIR-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14679111#comment-14679111
]
Hervé Boutemy edited comment on MPIR-312 at 8/9/15 11:53 AM:
-
a new idea: during build, there is already the algorithm to use local path
for artifacts from repo, perhaps we could use flatten-maven-plugin to detect
that the "module directory = artifactId" convention is not used then expand
calculated info flattened pom.xml
was (Author: hboutemy):
a new idea: during build, there is already the algorithm to use local path
for artifacts from repo, perhaps we could use flatten-maven-plugin to detect
that the "module directory = artifactId" convention is not used then expand
calculated info flattened pom.xml
> Subversion SCM module URLs incorrectly build when module name != artifactId
> ---
>
> Key: MPIR-312
> URL: https://issues.apache.org/jira/browse/MPIR-312
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.7
>Reporter: Michael Osipov
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14679106#comment-14679106
]
Hervé Boutemy commented on MPIR-234:
I'm thinking at this for a long time now, here is where I am for now:
First, the simplest idea: we can add easily in core a list of scms that don't
require adding artifactId to scm connection and developerConnection (AFAIK, url
is always expected to add artifactId): if the list is in a resource file, one
can later add another file to extend the list
But if we do so, the scm.connection does not contain information about the path
in scm: that's unfortunate, since I'm sure this would be useful for any tooling
wanting to use data (like release).
Perhaps it would be better to extend git scm url: currently, it is documented
in http://maven.apache.org/scm/git.html as
{{scm:git:git://server_name[:port]/path_to_repository}} (other forms are
similar)
if we extend it to
{{scm:git:git://server_name[:port]/path_to_repository:path_in_repository}}, we
can keep path info for tooling
and magically, the simple "add artifactId to path" algorithm is back to be a
good algorithm
WDYT?
the feature request for directoryname != artifactId is a feature request that
would just complement the algorithm: once someone finds an algorithm that can
detect the path when not equals parent+artifactId and not during build (where
current directory helps) but during resolution from repo, this will be ok
notice: perhaps flatten-maven-plugin can help us on this by expanding directory
during install
> SCM-link in site of multimodule projects should not append module name by
> default (at least for git)
>
>
> Key: MPIR-234
> URL: https://issues.apache.org/jira/browse/MPIR-234
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.4
>Reporter: Mirko Friedenhagen
>
> I have setup a simple multi module project (see
> https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex)
> which uses git on github as {{scm}}. While rendering the site, MPIR will by
> default add the name of the module to the SCM-URLs in source-repository.html.
> So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see
> https://github.com/mfriedenhagen/multi-module-sample/core/,
> g...@github.com:mfriedenhagen/multi-module-sample.git/core and
> git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for
> the core module. All these URLs are invalid. For SVN this could be assumed to
> be the right behaviour, for git and probably other SCMs this is not true. As
> a workaround I have to reconfigure the scm section (see
> https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml)
> in the modules like this:
> {code:xml}
>
> ${project.parent.scm.connection}
>
> ${project.parent.scm.developerConnection}
> ${project.parent.scm.url}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] James Wennmacher mentioned you (JIRA)
[ https://issues.apache.org/jira/browse/MANTTASKS-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Wennmacher mentioned you on MANTTASKS-246 --- [~mavendevlist] could probably direct you how to submit a fix. > Key: MANTTASKS-246 > View Online: https://issues.apache.org/jira/browse/MANTTASKS-246 > Add Comment: > https://issues.apache.org/jira/browse/MANTTASKS-246#add-comment Hint: You can mention someone in an issue description or comment by typing "@" in front of their username. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[jira] Subscription: Design & Best Practices
Issue Subscription
Filter: Design & Best Practices (25 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-5277best practices: The Maven Way
https://jira.codehaus.org/browse/MNG-5277
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 and other tags
https://jira.codehaus.org/browse/MNG-868
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
MNG-1425best practices: the location of configuration files vs resources
https://jira.codehaus.org/browse/MNG-1425
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] Subscription: Design & Best Practices
Issue Subscription
Filter: Design & Best Practices (25 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-5277best practices: The Maven Way
https://jira.codehaus.org/browse/MNG-5277
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 and other tags
https://jira.codehaus.org/browse/MNG-868
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
MNG-1425best practices: the location of configuration files vs resources
https://jira.codehaus.org/browse/MNG-1425
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] Subscription: Design & Best Practices
Issue Subscription
Filter: Design & Best Practices (25 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-5277best practices: The Maven Way
https://jira.codehaus.org/browse/MNG-5277
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 and other tags
https://jira.codehaus.org/browse/MNG-868
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
MNG-1425best practices: the location of configuration files vs resources
https://jira.codehaus.org/browse/MNG-1425
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] Subscription: Design & Best Practices
Issue Subscription
Filter: Design & Best Practices (25 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-5277best practices: The Maven Way
https://jira.codehaus.org/browse/MNG-5277
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 and other tags
https://jira.codehaus.org/browse/MNG-868
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
MNG-1425best practices: the location of configuration files vs resources
https://jira.codehaus.org/browse/MNG-1425
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] Subscription: Design & Best Practices
Issue Subscription
Filter: Design & Best Practices (25 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-5277best practices: The Maven Way
https://jira.codehaus.org/browse/MNG-5277
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 and other tags
https://jira.codehaus.org/browse/MNG-868
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
MNG-1425best practices: the location of configuration files vs resources
https://jira.codehaus.org/browse/MNG-1425
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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 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=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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 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=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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 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=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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 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=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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 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=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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 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-1423best practices: setting up multi-module build
https://jira.codehaus.org/browse/MNG-1423
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-1468best practices: version management in multi project builds
https://jira.codehaus.org/browse/MNG-1468
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
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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 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-1423best practices: setting up multi-module build
https://jira.codehaus.org/browse/MNG-1423
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-1468best practices: version management in multi project builds
https://jira.codehaus.org/browse/MNG-1468
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
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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 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-1423best practices: setting up multi-module build
https://jira.codehaus.org/browse/MNG-1423
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-1468best practices: version management in multi project builds
https://jira.codehaus.org/browse/MNG-1468
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
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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 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-1423best practices: setting up multi-module build
https://jira.codehaus.org/browse/MNG-1423
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-1468best practices: version management in multi project builds
https://jira.codehaus.org/browse/MNG-1468
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
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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 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-1423best practices: setting up multi-module build
https://jira.codehaus.org/browse/MNG-1423
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-1468best practices: version management in multi project builds
https://jira.codehaus.org/browse/MNG-1468
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
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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 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-1423best practices: setting up multi-module build
https://jira.codehaus.org/browse/MNG-1423
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-1468best practices: version management in multi project builds
https://jira.codehaus.org/browse/MNG-1468
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
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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 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-1423best practices: setting up multi-module build
https://jira.codehaus.org/browse/MNG-1423
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-1468best practices: version management in multi project builds
https://jira.codehaus.org/browse/MNG-1468
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
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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 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-1423best practices: setting up multi-module build
https://jira.codehaus.org/browse/MNG-1423
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-1468best practices: version management in multi project builds
https://jira.codehaus.org/browse/MNG-1468
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
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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 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-1423best practices: setting up multi-module build
https://jira.codehaus.org/browse/MNG-1423
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-1468best practices: version management in multi project builds
https://jira.codehaus.org/browse/MNG-1468
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
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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 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-1423best practices: setting up multi-module build
https://jira.codehaus.org/browse/MNG-1423
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-1468best practices: version management in multi project builds
https://jira.codehaus.org/browse/MNG-1468
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
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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 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-1423best practices: setting up multi-module build
https://jira.codehaus.org/browse/MNG-1423
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-1468best practices: version management in multi project builds
https://jira.codehaus.org/browse/MNG-1468
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
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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 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-1423best practices: setting up multi-module build
https://jira.codehaus.org/browse/MNG-1423
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-1468best practices: version management in multi project builds
https://jira.codehaus.org/browse/MNG-1468
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
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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 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-1423best practices: setting up multi-module build
https://jira.codehaus.org/browse/MNG-1423
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-1468best practices: version management in multi project builds
https://jira.codehaus.org/browse/MNG-1468
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
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
https://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-1425best practices: the location of configuration files vs resources
https://jira.codehaus.org/browse/MNG-1425
MNG-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
MNG-1468best practices: version management in multi project builds
https://jira.codehaus.org/browse/MNG-1468
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-1463best practices: plugin inheritance for a multi project build
https://jira.codehaus.org/browse/MNG-1463
MNG-1423best practices: setting up multi-module build
https://jira.codehaus.org/browse/MNG-1423
MNG-868 Use uniform format for and other tags
https://jira.codehaus.org/browse/MNG-868
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
MNG-1867deprecate system scope, analyse other use cases
https://jira.codehaus.org/browse/MNG-1867
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
https://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-1425best practices: the location of configuration files vs resources
https://jira.codehaus.org/browse/MNG-1425
MNG-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
MNG-1468best practices: version management in multi project builds
https://jira.codehaus.org/browse/MNG-1468
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-1463best practices: plugin inheritance for a multi project build
https://jira.codehaus.org/browse/MNG-1463
MNG-1423best practices: setting up multi-module build
https://jira.codehaus.org/browse/MNG-1423
MNG-868 Use uniform format for and other tags
https://jira.codehaus.org/browse/MNG-868
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
MNG-1867deprecate system scope, analyse other use cases
https://jira.codehaus.org/browse/MNG-1867
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
https://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-1425best practices: the location of configuration files vs resources
https://jira.codehaus.org/browse/MNG-1425
MNG-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
MNG-1468best practices: version management in multi project builds
https://jira.codehaus.org/browse/MNG-1468
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-1463best practices: plugin inheritance for a multi project build
https://jira.codehaus.org/browse/MNG-1463
MNG-1423best practices: setting up multi-module build
https://jira.codehaus.org/browse/MNG-1423
MNG-868 Use uniform format for and other tags
https://jira.codehaus.org/browse/MNG-868
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
MNG-1867deprecate system scope, analyse other use cases
https://jira.codehaus.org/browse/MNG-1867
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
https://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-1425best practices: the location of configuration files vs resources
https://jira.codehaus.org/browse/MNG-1425
MNG-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
MNG-1468best practices: version management in multi project builds
https://jira.codehaus.org/browse/MNG-1468
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-1463best practices: plugin inheritance for a multi project build
https://jira.codehaus.org/browse/MNG-1463
MNG-1423best practices: setting up multi-module build
https://jira.codehaus.org/browse/MNG-1423
MNG-868 Use uniform format for and other tags
https://jira.codehaus.org/browse/MNG-868
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
https://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-1425best practices: the location of configuration files vs resources
https://jira.codehaus.org/browse/MNG-1425
MNG-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
MNG-1468best practices: version management in multi project builds
https://jira.codehaus.org/browse/MNG-1468
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-1463best practices: plugin inheritance for a multi project build
https://jira.codehaus.org/browse/MNG-1463
MNG-1423best practices: setting up multi-module build
https://jira.codehaus.org/browse/MNG-1423
MNG-868 Use uniform format for and other tags
https://jira.codehaus.org/browse/MNG-868
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
https://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-1425best practices: the location of configuration files vs resources
https://jira.codehaus.org/browse/MNG-1425
MNG-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
MNG-1468best practices: version management in multi project builds
https://jira.codehaus.org/browse/MNG-1468
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-1463best practices: plugin inheritance for a multi project build
https://jira.codehaus.org/browse/MNG-1463
MNG-1423best practices: setting up multi-module build
https://jira.codehaus.org/browse/MNG-1423
MNG-868 Use uniform format for and other tags
https://jira.codehaus.org/browse/MNG-868
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
https://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-1425best practices: the location of configuration files vs resources
https://jira.codehaus.org/browse/MNG-1425
MNG-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
MNG-1468best practices: version management in multi project builds
https://jira.codehaus.org/browse/MNG-1468
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-1463best practices: plugin inheritance for a multi project build
https://jira.codehaus.org/browse/MNG-1463
MNG-1423best practices: setting up multi-module build
https://jira.codehaus.org/browse/MNG-1423
MNG-868 Use uniform format for and other tags
https://jira.codehaus.org/browse/MNG-868
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
https://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
MNG-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-868 Use uniform format for 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-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
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
MNG-1867deprecate system scope, analyse other use cases
https://jira.codehaus.org/browse/MNG-1867
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
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
https://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-1425best practices: the location of configuration files vs resources
https://jira.codehaus.org/browse/MNG-1425
MNG-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
MNG-1468best practices: version management in multi project builds
https://jira.codehaus.org/browse/MNG-1468
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-1463best practices: plugin inheritance for a multi project build
https://jira.codehaus.org/browse/MNG-1463
MNG-1423best practices: setting up multi-module build
https://jira.codehaus.org/browse/MNG-1423
MNG-868 Use uniform format for and other tags
https://jira.codehaus.org/browse/MNG-868
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
https://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
MNG-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-868 Use uniform format for 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-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
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
MNG-1867deprecate system scope, analyse other use cases
https://jira.codehaus.org/browse/MNG-1867
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
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
https://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
MNG-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-868 Use uniform format for 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-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
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
MNG-1867deprecate system scope, analyse other use cases
https://jira.codehaus.org/browse/MNG-1867
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
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
https://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
MNG-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-868 Use uniform format for 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-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
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
MNG-1867deprecate system scope, analyse other use cases
https://jira.codehaus.org/browse/MNG-1867
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
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
https://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
MNG-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-868 Use uniform format for 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-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
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
MNG-1867deprecate system scope, analyse other use cases
https://jira.codehaus.org/browse/MNG-1867
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
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
https://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
MNG-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-868 Use uniform format for 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-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
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
MNG-1867deprecate system scope, analyse other use cases
https://jira.codehaus.org/browse/MNG-1867
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
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
https://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
MNG-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-868 Use uniform format for 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-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
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
MNG-1867deprecate system scope, analyse other use cases
https://jira.codehaus.org/browse/MNG-1867
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
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
https://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
MNG-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-868 Use uniform format for 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-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
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
MNG-1867deprecate system scope, analyse other use cases
https://jira.codehaus.org/browse/MNG-1867
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
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
https://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
MNG-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-868 Use uniform format for 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-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
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
MNG-1867deprecate system scope, analyse other use cases
https://jira.codehaus.org/browse/MNG-1867
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
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
https://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
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-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-868 Use uniform format for 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-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
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=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
https://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
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-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-868 Use uniform format for 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-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
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=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
https://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
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-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-868 Use uniform format for 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-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
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=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
https://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
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-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-868 Use uniform format for 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-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
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=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
https://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
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-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-868 Use uniform format for 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-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
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=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
https://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
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-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-868 Use uniform format for 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-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
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=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
https://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
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-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-868 Use uniform format for 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-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
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=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
https://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
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-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-868 Use uniform format for 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-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
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=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
https://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
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-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-868 Use uniform format for 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-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
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=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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
http://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
http://jira.codehaus.org/browse/MNG-612
MNG-1950Ability to introduce new lifecycles phases
http://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
http://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
http://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
http://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
http://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
http://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
http://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
http://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
http://jira.codehaus.org/browse/MNG-4713
MNG-1569Make build process info read-only to mojos, and provide mechanism
for explicit out-params for mojos to declare
http://jira.codehaus.org/browse/MNG-1569
MNG-416 best practices: multiple profile deployments
http://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
http://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
http://jira.codehaus.org/browse/MNG-125
MNG-41 best practices: site management
http://jira.codehaus.org/browse/MNG-41
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
http://jira.codehaus.org/browse/MNG-1441
MNG-868 Use uniform format for and other tags
http://jira.codehaus.org/browse/MNG-868
MNG-1425best practices: the location of configuration files vs resources
http://jira.codehaus.org/browse/MNG-1425
MNG-1463best practices: plugin inheritance for a multi project build
http://jira.codehaus.org/browse/MNG-1463
MNG-657 possible chicken and egg problem with extensions
http://jira.codehaus.org/browse/MNG-657
MNG-1867deprecate system scope, analyse other use cases
http://jira.codehaus.org/browse/MNG-1867
MNG-1423best practices: setting up multi-module build
http://jira.codehaus.org/browse/MNG-1423
MNG-1468best practices: version management in multi project builds
http://jira.codehaus.org/browse/MNG-1468
You may edit this subscription at:
http://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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
http://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
http://jira.codehaus.org/browse/MNG-612
MNG-2381improved control over the repositories in the POM
http://jira.codehaus.org/browse/MNG-2381
MNG-2125[doc] when and how to define plugins in a pom
http://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
http://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
http://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
http://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
http://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
http://jira.codehaus.org/browse/MNG-4713
MNG-1563how to write integration tests
http://jira.codehaus.org/browse/MNG-1563
MNG-1950Ability to introduce new lifecycles phases
http://jira.codehaus.org/browse/MNG-1950
MNG-1569Make build process info read-only to mojos, and provide mechanism
for explicit out-params for mojos to declare
http://jira.codehaus.org/browse/MNG-1569
MNG-416 best practices: multiple profile deployments
http://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
http://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
http://jira.codehaus.org/browse/MNG-125
MNG-868 Use uniform format for and other tags
http://jira.codehaus.org/browse/MNG-868
MNG-657 possible chicken and egg problem with extensions
http://jira.codehaus.org/browse/MNG-657
MNG-41 best practices: site management
http://jira.codehaus.org/browse/MNG-41
MNG-1463best practices: plugin inheritance for a multi project build
http://jira.codehaus.org/browse/MNG-1463
MNG-1425best practices: the location of configuration files vs resources
http://jira.codehaus.org/browse/MNG-1425
MNG-1867deprecate system scope, analyse other use cases
http://jira.codehaus.org/browse/MNG-1867
MNG-1423best practices: setting up multi-module build
http://jira.codehaus.org/browse/MNG-1423
MNG-1468best practices: version management in multi project builds
http://jira.codehaus.org/browse/MNG-1468
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
http://jira.codehaus.org/browse/MNG-1441
You may edit this subscription at:
http://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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
http://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
http://jira.codehaus.org/browse/MNG-612
MNG-2381improved control over the repositories in the POM
http://jira.codehaus.org/browse/MNG-2381
MNG-2125[doc] when and how to define plugins in a pom
http://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
http://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
http://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
http://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
http://jira.codehaus.org/browse/MNG-4656
MNG-1950Ability to introduce new lifecycles phases
http://jira.codehaus.org/browse/MNG-1950
MNG-4713${basedir} variable makes portable builds overly difficult
http://jira.codehaus.org/browse/MNG-4713
MNG-1563how to write integration tests
http://jira.codehaus.org/browse/MNG-1563
MNG-1569Make build process info read-only to mojos, and provide mechanism
for explicit out-params for mojos to declare
http://jira.codehaus.org/browse/MNG-1569
MNG-416 best practices: multiple profile deployments
http://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
http://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
http://jira.codehaus.org/browse/MNG-125
MNG-868 Use uniform format for and other tags
http://jira.codehaus.org/browse/MNG-868
MNG-657 possible chicken and egg problem with extensions
http://jira.codehaus.org/browse/MNG-657
MNG-41 best practices: site management
http://jira.codehaus.org/browse/MNG-41
MNG-1463best practices: plugin inheritance for a multi project build
http://jira.codehaus.org/browse/MNG-1463
MNG-1425best practices: the location of configuration files vs resources
http://jira.codehaus.org/browse/MNG-1425
MNG-1867deprecate system scope, analyse other use cases
http://jira.codehaus.org/browse/MNG-1867
MNG-1423best practices: setting up multi-module build
http://jira.codehaus.org/browse/MNG-1423
MNG-1468best practices: version management in multi project builds
http://jira.codehaus.org/browse/MNG-1468
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
http://jira.codehaus.org/browse/MNG-1441
You may edit this subscription at:
http://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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
http://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
http://jira.codehaus.org/browse/MNG-612
MNG-2381improved control over the repositories in the POM
http://jira.codehaus.org/browse/MNG-2381
MNG-2125[doc] when and how to define plugins in a pom
http://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
http://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
http://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
http://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
http://jira.codehaus.org/browse/MNG-4656
MNG-1950Ability to introduce new lifecycles phases
http://jira.codehaus.org/browse/MNG-1950
MNG-4713${basedir} variable makes portable builds overly difficult
http://jira.codehaus.org/browse/MNG-4713
MNG-1563how to write integration tests
http://jira.codehaus.org/browse/MNG-1563
MNG-1569Make build process info read-only to mojos, and provide mechanism
for explicit out-params for mojos to declare
http://jira.codehaus.org/browse/MNG-1569
MNG-416 best practices: multiple profile deployments
http://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
http://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
http://jira.codehaus.org/browse/MNG-125
MNG-868 Use uniform format for and other tags
http://jira.codehaus.org/browse/MNG-868
MNG-657 possible chicken and egg problem with extensions
http://jira.codehaus.org/browse/MNG-657
MNG-41 best practices: site management
http://jira.codehaus.org/browse/MNG-41
MNG-1463best practices: plugin inheritance for a multi project build
http://jira.codehaus.org/browse/MNG-1463
MNG-1425best practices: the location of configuration files vs resources
http://jira.codehaus.org/browse/MNG-1425
MNG-1867deprecate system scope, analyse other use cases
http://jira.codehaus.org/browse/MNG-1867
MNG-1423best practices: setting up multi-module build
http://jira.codehaus.org/browse/MNG-1423
MNG-1468best practices: version management in multi project builds
http://jira.codehaus.org/browse/MNG-1468
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
http://jira.codehaus.org/browse/MNG-1441
You may edit this subscription at:
http://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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
http://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
http://jira.codehaus.org/browse/MNG-612
MNG-2381improved control over the repositories in the POM
http://jira.codehaus.org/browse/MNG-2381
MNG-2125[doc] when and how to define plugins in a pom
http://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
http://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
http://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
http://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
http://jira.codehaus.org/browse/MNG-4656
MNG-1950Ability to introduce new lifecycles phases
http://jira.codehaus.org/browse/MNG-1950
MNG-4713${basedir} variable makes portable builds overly difficult
http://jira.codehaus.org/browse/MNG-4713
MNG-1563how to write integration tests
http://jira.codehaus.org/browse/MNG-1563
MNG-1569Make build process info read-only to mojos, and provide mechanism
for explicit out-params for mojos to declare
http://jira.codehaus.org/browse/MNG-1569
MNG-416 best practices: multiple profile deployments
http://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
http://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
http://jira.codehaus.org/browse/MNG-125
MNG-868 Use uniform format for and other tags
http://jira.codehaus.org/browse/MNG-868
MNG-657 possible chicken and egg problem with extensions
http://jira.codehaus.org/browse/MNG-657
MNG-41 best practices: site management
http://jira.codehaus.org/browse/MNG-41
MNG-1463best practices: plugin inheritance for a multi project build
http://jira.codehaus.org/browse/MNG-1463
MNG-1425best practices: the location of configuration files vs resources
http://jira.codehaus.org/browse/MNG-1425
MNG-1867deprecate system scope, analyse other use cases
http://jira.codehaus.org/browse/MNG-1867
MNG-1423best practices: setting up multi-module build
http://jira.codehaus.org/browse/MNG-1423
MNG-1468best practices: version management in multi project builds
http://jira.codehaus.org/browse/MNG-1468
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
http://jira.codehaus.org/browse/MNG-1441
You may edit this subscription at:
http://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[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
http://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
http://jira.codehaus.org/browse/MNG-612
MNG-2381improved control over the repositories in the POM
http://jira.codehaus.org/browse/MNG-2381
MNG-2125[doc] when and how to define plugins in a pom
http://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
http://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
http://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
http://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
http://jira.codehaus.org/browse/MNG-4656
MNG-1950Ability to introduce new lifecycles phases
http://jira.codehaus.org/browse/MNG-1950
MNG-4713${basedir} variable makes portable builds overly difficult
http://jira.codehaus.org/browse/MNG-4713
MNG-1563how to write integration tests
http://jira.codehaus.org/browse/MNG-1563
MNG-1569Make build process info read-only to mojos, and provide mechanism
for explicit out-params for mojos to declare
http://jira.codehaus.org/browse/MNG-1569
MNG-416 best practices: multiple profile deployments
http://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
http://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
http://jira.codehaus.org/browse/MNG-125
MNG-868 Use uniform format for and other tags
http://jira.codehaus.org/browse/MNG-868
MNG-657 possible chicken and egg problem with extensions
http://jira.codehaus.org/browse/MNG-657
MNG-41 best practices: site management
http://jira.codehaus.org/browse/MNG-41
MNG-1463best practices: plugin inheritance for a multi project build
http://jira.codehaus.org/browse/MNG-1463
MNG-1425best practices: the location of configuration files vs resources
http://jira.codehaus.org/browse/MNG-1425
MNG-1867deprecate system scope, analyse other use cases
http://jira.codehaus.org/browse/MNG-1867
MNG-1423best practices: setting up multi-module build
http://jira.codehaus.org/browse/MNG-1423
MNG-1468best practices: version management in multi project builds
http://jira.codehaus.org/browse/MNG-1468
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
http://jira.codehaus.org/browse/MNG-1441
You may edit this subscription at:
http://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
