[jira] Commented: (MNG-2142) Forcing execution of the post-integration-test phase
[ http://jira.codehaus.org/browse/MNG-2142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=270190#comment-270190 ] Christopher Barrow commented on MNG-2142: - Actually there is a good solution which is to use the failsafe plug-in. This is designed for integration tests and handles this case very well. The test failures are discovered in the verify phase so the post-integration-test phase is always executed. So I would suggest it's not worth fixing this bug. > Forcing execution of the post-integration-test phase > > > Key: MNG-2142 > URL: http://jira.codehaus.org/browse/MNG-2142 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Integration Tests >Affects Versions: 2.0.3 >Reporter: Vincent Massol > Fix For: Issues to be reviewed for 3.x > > > The post-integration-test phase needs to always be called even in case of > tests failures in the integration-test phase. > For example when using Cargo the container may be left running if the > post-integration-test phase is not called... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-623) Add a configuration mode to be able to use git svn (at least for release plugin)
[ http://jira.codehaus.org/browse/SCM-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=270192#comment-270192 ] Olivier Lamy commented on SCM-623: -- note for myself : why not creating a new scm provider : gitsvn (the url will svn one). > Add a configuration mode to be able to use git svn (at least for release > plugin) > > > Key: SCM-623 > URL: http://jira.codehaus.org/browse/SCM-623 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-git >Affects Versions: 1.5 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 1.6 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2812) Please, can you deploy a new artifact : Shell API...
[
http://jira.codehaus.org/browse/MAVENUPLOAD-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=270195#comment-270195
]
Juven Xu commented on MAVENUPLOAD-2812:
---
with Sonatype's repository hosting or bundle upload service, you can still
deploy your artifacts to maven central
> Please, can you deploy a new artifact : Shell API...
>
>
> Key: MAVENUPLOAD-2812
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2812
> Project: Maven Upload Requests
> Issue Type: Task
>Reporter: PÉRIÉ Fabien
>Assignee: Juven Xu
>
> Shell is a fantastic API to launch many cmds on a shell system.
> Please upload !
> With a litle example :
> Shell sh = new Shell();
> String result = sh.command("ls | sort").consumeAsString();
> Thanks a lot !
> F.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MCHANGES-259) Create modularity for supporting multiple issue management systems
[ http://jira.codehaus.org/browse/MCHANGES-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MCHANGES-259: -- Attachment: MCHANGES-259.patch > Create modularity for supporting multiple issue management systems > -- > > Key: MCHANGES-259 > URL: http://jira.codehaus.org/browse/MCHANGES-259 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement > Components: other issue-trackers >Affects Versions: 2.5 >Reporter: Benson Margulies >Assignee: Benson Margulies > Attachments: MCHANGES-259.patch > > > In discussion of MCHANGES-245, Dennis notes the need for some global > modularity for capturing the behavior of the different issue management > systems. I'm creating this JIRA as a hat-rack to hang this work off of. > My plan is to start by creating something very simple in the way of an > abstract class, which can be elaborated as we go. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHANGES-259) Create modularity for supporting multiple issue management systems
[ http://jira.codehaus.org/browse/MCHANGES-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=270199#comment-270199 ] Benson Margulies commented on MCHANGES-259: --- Dennis, The attached patch is a lot of changes that try to start the modularity you are looking for. This is complex enough that I'd like some feedback from you before committing; I don't want to have to back it out. --benson > Create modularity for supporting multiple issue management systems > -- > > Key: MCHANGES-259 > URL: http://jira.codehaus.org/browse/MCHANGES-259 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement > Components: other issue-trackers >Affects Versions: 2.5 >Reporter: Benson Margulies >Assignee: Benson Margulies > Attachments: MCHANGES-259.patch > > > In discussion of MCHANGES-245, Dennis notes the need for some global > modularity for capturing the behavior of the different issue management > systems. I'm creating this JIRA as a hat-rack to hang this work off of. > My plan is to start by creating something very simple in the way of an > abstract class, which can be elaborated as we go. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHANGES-259) Create modularity for supporting multiple issue management systems
[ http://jira.codehaus.org/browse/MCHANGES-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=270200#comment-270200 ] Benson Margulies commented on MCHANGES-259: --- Note: this is a *start*. I didn't get involved in refactoring the unshared code. To be perfectly honest, I'm not that enthralled with this plugin at all. But I'd like to use it, and I can't without some support for customized JIRAs. I'm willing to do some work to get those changes to the point where everyone is comfy, but not to take on a giant rewrite. > Create modularity for supporting multiple issue management systems > -- > > Key: MCHANGES-259 > URL: http://jira.codehaus.org/browse/MCHANGES-259 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement > Components: other issue-trackers >Affects Versions: 2.5 >Reporter: Benson Margulies >Assignee: Benson Margulies > Attachments: MCHANGES-259.patch > > > In discussion of MCHANGES-245, Dennis notes the need for some global > modularity for capturing the behavior of the different issue management > systems. I'm creating this JIRA as a hat-rack to hang this work off of. > My plan is to start by creating something very simple in the way of an > abstract class, which can be elaborated as we go. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-683) maven:perform will not release projects unless the pom file is in the top directory in the SCM repo
maven:perform will not release projects unless the pom file is in the top directory in the SCM repo --- Key: MRELEASE-683 URL: http://jira.codehaus.org/browse/MRELEASE-683 Project: Maven 2.x Release Plugin Issue Type: Bug Components: perform Affects Versions: 2.1 Environment: linux/mac Reporter: Lee Thompson Playing around with the MOJO project hosted in GIT. I can't release a plugin unless all the MOJO projects are split into their own GIT repos. If you want to put all plugins in one GIT repo, checkout the code, jump into a plugin project and release just that one plugin... release:perform will not jump into the right sub-directory of the GIT repository. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-683) maven:perform will not release projects unless the pom file is in the top directory in the SCM repo
[ http://jira.codehaus.org/browse/MRELEASE-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg closed MRELEASE-683. -- Resolution: Duplicate Fix Version/s: 2.2 Assignee: Mark Struberg this is a duplicate of MRELEASE-457 which is already implemented in release 2.2 > maven:perform will not release projects unless the pom file is in the top > directory in the SCM repo > --- > > Key: MRELEASE-683 > URL: http://jira.codehaus.org/browse/MRELEASE-683 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: perform >Affects Versions: 2.1 > Environment: linux/mac >Reporter: Lee Thompson >Assignee: Mark Struberg > Fix For: 2.2 > > > Playing around with the MOJO project hosted in GIT. > I can't release a plugin unless all the MOJO projects are split into their > own GIT repos. If you want to put all plugins in one GIT repo, checkout the > code, jump into a plugin project and release just that one plugin... > release:perform will not jump into the right sub-directory of the GIT > repository. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-457) Non sparse-checkout SCM support
[
http://jira.codehaus.org/browse/MRELEASE-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=270210#comment-270210
]
Lee Thompson commented on MRELEASE-457:
---
Trying to catch up on this as I'm hitting it to. Don't think the patch will
work if there is no pom in the top directory of the source repo. In line with
what Benjamin stated, I think its better to inject rather than discover.
Injection of something like "pomSubDirectory" as a parameter into the
release:perform mojo would be very unobtrusize. The release descriptor already
has "ScmRelativePathProjectDirectory". Not sure if that is the right variable,
but if it was, it would be a very simple non-intrusive fix of
PerformReleaseMojo.java ...
{code:title=Bar.java|borderStyle=solid}
/**
* If the POM for the project you are releasing is not in the top directory
of your checked
* out source repository, then you will need to specicify this parameter.
It almost never
* occurs with Subversion since you can specify a checkout of any directory
in the
* repository. This is not the case for SCM systems like Git and Mercurial
as you check
* out the whole repository and frequently, the project you want to release
is not in
* the top directory. If your pom is in the top directory of your source,
this parameter
* is not needed.
*
* @parameter expression="${pomSubDirectory}"
* @since 2.2
*/
private String pomSubDirectory;
if (pomSubDirectory != null )
{
releaseDescriptor.setScmRelativePathProjectDirectory(
pomSubDirectory );
}
{code}
> Non sparse-checkout SCM support
> ---
>
> Key: MRELEASE-457
> URL: http://jira.codehaus.org/browse/MRELEASE-457
> Project: Maven 2.x Release Plugin
> Issue Type: New Feature
> Components: perform, scm
>Affects Versions: 2.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 2.2
>
> Attachments: MRELEASE-457.2.patch, MRELEASE-457.patch
>
>
> Some SCMs like GIT, Mercurial, Bazaar, BitKeeper, Darcs, and Monotone doesn't
> support sparse checkouts (checkout of a single subdirectory).
> So while doing a mvn release:perform in a sub-module, we will always get the
> _whole_ project checked out into target/checkout!
> For doing the clean build from this checkout, we have to implement a
> functionality to find the right submodule first.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHANGES-259) Create modularity for supporting multiple issue management systems
[ http://jira.codehaus.org/browse/MCHANGES-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=270211#comment-270211 ] Dennis Lundberg commented on MCHANGES-259: -- Benson, Some thoughts and questions after a brief look at your patch. * Lots of good stuff in there with the abstract class and all * I haven't worked with enums before. What data is stored in an "instance" of IssueType? * Is DefaultIssueManagmentSystem really needed? Or should it be renamed to JIRAIssueManagementSystem * Was there a particular reason to change the logic in AnnouncementMojo? The reason I ask is that I envision changes.xml to be just another IMS in the future, and the changes to the logic seems to go against that. I.e it hard codes the changes + 1 that we currently have, making it harder to change that going forward. A couple of more things I'd like to do: * Add an interface IssueManagementSystem and use that wherever possible in place of AbstractIssueManagementSystem * Add a constant in IssueAdapter: final String UNKNOWN_TYPE = ""; > Create modularity for supporting multiple issue management systems > -- > > Key: MCHANGES-259 > URL: http://jira.codehaus.org/browse/MCHANGES-259 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement > Components: other issue-trackers >Affects Versions: 2.5 >Reporter: Benson Margulies >Assignee: Benson Margulies > Attachments: MCHANGES-259.patch > > > In discussion of MCHANGES-245, Dennis notes the need for some global > modularity for capturing the behavior of the different issue management > systems. I'm creating this JIRA as a hat-rack to hang this work off of. > My plan is to start by creating something very simple in the way of an > abstract class, which can be elaborated as we go. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHANGES-259) Create modularity for supporting multiple issue management systems
[ http://jira.codehaus.org/browse/MCHANGES-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=270212#comment-270212 ] Benson Margulies commented on MCHANGES-259: --- 1. Enums. For each constant listed in the enum, there is one instance for the entire JVM. It has whatever fields and methods you declare on the enum. So, you are declaring a collection of named singletons which have a common contract. 2. Here's the modularity dilemma as I saw it. If we want to seriously support multiple IMSs, there is a lot of work to do. The comment at the top that we only support 'changes + 1' is there for a good reason given the code. So, I felt that I either had to tackle the big job of actually making it operate on and iterate over multiple systems, or I wanted to enforce the restriction. Now, I could scope the creation and use of the new object(s) to within the blocks for the individual IMSs, I realize, and leave things no worse off then they were. I'll do that. 3. If you prefer an interface, I think I'll rename the class from Abstract to Default, and add the interface. Unless you prefer the non-JIRA case to start out with no mappings, in which case I'd add the JIRA subclass. Generally, I want to point out that this whole business is somewhat off to one side of the patch that started all this. All IMSes that I know are configurable. So, with or without this stuff, we still need to keep the original patch code that allows the user to configure their own mappings. I wonder if we should release what's currently checked in before continuing with any variation on this. > Create modularity for supporting multiple issue management systems > -- > > Key: MCHANGES-259 > URL: http://jira.codehaus.org/browse/MCHANGES-259 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement > Components: other issue-trackers >Affects Versions: 2.5 >Reporter: Benson Margulies >Assignee: Benson Margulies > Attachments: MCHANGES-259.patch > > > In discussion of MCHANGES-245, Dennis notes the need for some global > modularity for capturing the behavior of the different issue management > systems. I'm creating this JIRA as a hat-rack to hang this work off of. > My plan is to start by creating something very simple in the way of an > abstract class, which can be elaborated as we go. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHANGES-259) Create modularity for supporting multiple issue management systems
[ http://jira.codehaus.org/browse/MCHANGES-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=270213#comment-270213 ] Dennis Lundberg commented on MCHANGES-259: -- 2. That'd be great. 3. I prefer to have an interface, and an abstract class with common implementation pieces. Also a JIRA subclass is better than a general purpose Default implementation, since the implementation in there is specific to JIRA. The patch for this issue doesn't contradict your original patch to make the mappings configurable. IMO we should do both. > Create modularity for supporting multiple issue management systems > -- > > Key: MCHANGES-259 > URL: http://jira.codehaus.org/browse/MCHANGES-259 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement > Components: other issue-trackers >Affects Versions: 2.5 >Reporter: Benson Margulies >Assignee: Benson Margulies > Attachments: MCHANGES-259.patch > > > In discussion of MCHANGES-245, Dennis notes the need for some global > modularity for capturing the behavior of the different issue management > systems. I'm creating this JIRA as a hat-rack to hang this work off of. > My plan is to start by creating something very simple in the way of an > abstract class, which can be elaborated as we go. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHANGES-259) Create modularity for supporting multiple issue management systems
[ http://jira.codehaus.org/browse/MCHANGES-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=270215#comment-270215 ] Benson Margulies commented on MCHANGES-259: --- OK, here's the disconnect on the second part of (3). Before I got here, the code was just assuming that all IMSs used the same strings. And, for all I know, several IMSs do agree on those three strings. So, I preserved this. If you want to put those three mappings into JIRA and leave others empty until someone fills in correct mappings, I'll do that. > Create modularity for supporting multiple issue management systems > -- > > Key: MCHANGES-259 > URL: http://jira.codehaus.org/browse/MCHANGES-259 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement > Components: other issue-trackers >Affects Versions: 2.5 >Reporter: Benson Margulies >Assignee: Benson Margulies > Attachments: MCHANGES-259.patch > > > In discussion of MCHANGES-245, Dennis notes the need for some global > modularity for capturing the behavior of the different issue management > systems. I'm creating this JIRA as a hat-rack to hang this work off of. > My plan is to start by creating something very simple in the way of an > abstract class, which can be elaborated as we go. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHANGES-259) Create modularity for supporting multiple issue management systems
[ http://jira.codehaus.org/browse/MCHANGES-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=270217#comment-270217 ] Dennis Lundberg commented on MCHANGES-259: -- Yes, that's my preference, to keep things as separate as possible. If we need the same mappings for Trac, then we should add a TracIMS class that we use for Trac. That way we are one step ahead of where we currently are: all supported IMSes have their own implementation and type mapping. > Create modularity for supporting multiple issue management systems > -- > > Key: MCHANGES-259 > URL: http://jira.codehaus.org/browse/MCHANGES-259 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement > Components: other issue-trackers >Affects Versions: 2.5 >Reporter: Benson Margulies >Assignee: Benson Margulies > Attachments: MCHANGES-259.patch > > > In discussion of MCHANGES-245, Dennis notes the need for some global > modularity for capturing the behavior of the different issue management > systems. I'm creating this JIRA as a hat-rack to hang this work off of. > My plan is to start by creating something very simple in the way of an > abstract class, which can be elaborated as we go. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-204) go-offline fails to resolve artifact available in maven reactor
[ http://jira.codehaus.org/browse/MDEP-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=270219#comment-270219 ] Corneil du Plessis commented on MDEP-204: - I'm amazed that this issue is still unresolved. Does no one use dependency:go-offline for multi-module projects? > go-offline fails to resolve artifact available in maven reactor > --- > > Key: MDEP-204 > URL: http://jira.codehaus.org/browse/MDEP-204 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: go-offline >Affects Versions: 2.0, 2.1 > Environment: maven 2.1.0 >Reporter: Stevo Slavic >Assignee: Brian Fox > Attachments: mvn-dependency-go-offline-failing-example.zip > > > Attached is example project, for which IMO dependency:go-offline should be > able to resolve all dependencies as they are only intermodule dependencies > within same multimodule project which haven't been installed yet but are > available in maven reactor so can be considered as resolvable in offline mode > - instead dependency:go-offline fails to resolve these dependencies. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MCHANGES-259) Create modularity for supporting multiple issue management systems
[ http://jira.codehaus.org/browse/MCHANGES-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MCHANGES-259. - Resolution: Fixed Fix Version/s: 2.6 /Users/benson/asf/mvn/plugins/maven-changes-plugin svn log -r1134984 r1134984 | bimargulies | 2011-06-12 17:08:34 -0400 (Sun, 12 Jun 2011) | 3 lines [MCHANGES-259] Start to build some modularity that knows that we have multiple issue management systems at work in here. This is just the beginning. /Users/benson/asf/mvn/plugins/maven-changes-plugin > Create modularity for supporting multiple issue management systems > -- > > Key: MCHANGES-259 > URL: http://jira.codehaus.org/browse/MCHANGES-259 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement > Components: other issue-trackers >Affects Versions: 2.5 >Reporter: Benson Margulies >Assignee: Benson Margulies > Fix For: 2.6 > > Attachments: MCHANGES-259.patch > > > In discussion of MCHANGES-245, Dennis notes the need for some global > modularity for capturing the behavior of the different issue management > systems. I'm creating this JIRA as a hat-rack to hang this work off of. > My plan is to start by creating something very simple in the way of an > abstract class, which can be elaborated as we go. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-683) maven:perform will not release projects unless the pom file is in the top directory in the SCM repo
[ http://jira.codehaus.org/browse/MRELEASE-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=270225#comment-270225 ] Lee Thompson commented on MRELEASE-683: --- Thanks! > maven:perform will not release projects unless the pom file is in the top > directory in the SCM repo > --- > > Key: MRELEASE-683 > URL: http://jira.codehaus.org/browse/MRELEASE-683 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: perform >Affects Versions: 2.1 > Environment: linux/mac >Reporter: Lee Thompson >Assignee: Mark Struberg > Fix For: 2.2 > > > Playing around with the MOJO project hosted in GIT. > I can't release a plugin unless all the MOJO projects are split into their > own GIT repos. If you want to put all plugins in one GIT repo, checkout the > code, jump into a plugin project and release just that one plugin... > release:perform will not jump into the right sub-directory of the GIT > repository. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-683) maven:perform will not release projects unless the pom file is in the top directory in the SCM repo
[ http://jira.codehaus.org/browse/MRELEASE-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRELEASE-683: -- Fix Version/s: (was: 2.2) > maven:perform will not release projects unless the pom file is in the top > directory in the SCM repo > --- > > Key: MRELEASE-683 > URL: http://jira.codehaus.org/browse/MRELEASE-683 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: perform >Affects Versions: 2.1 > Environment: linux/mac >Reporter: Lee Thompson >Assignee: Mark Struberg > > Playing around with the MOJO project hosted in GIT. > I can't release a plugin unless all the MOJO projects are split into their > own GIT repos. If you want to put all plugins in one GIT repo, checkout the > code, jump into a plugin project and release just that one plugin... > release:perform will not jump into the right sub-directory of the GIT > repository. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
