[jira] Closed: (CONTINUUM-1325) Surefire Report history is not kept for prior builds
[ http://jira.codehaus.org/browse/CONTINUUM-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed CONTINUUM-1325. --- Resolution: Fixed Fix Version/s: (was: Future) 1.1-beta-3 Fix with CONTINUUM-1411. > Surefire Report history is not kept for prior builds > > > Key: CONTINUUM-1325 > URL: http://jira.codehaus.org/browse/CONTINUUM-1325 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-alpha-2 > Environment: Linux webserver 2.6.20-1.2952.fc6 #1 SMP Wed May 16 > 17:59:13 EDT 2007 i686 i686 i386 GNU/Linux >Reporter: Brian Bonner >Assignee: Olivier Lamy > Fix For: 1.1-beta-3 > > > I'm not sure if this is a bug, or just existing behavior (i.e. maybe this is > a wish). > Continuum is not keeping prior surefire reports that correspond to failed > builds. > I added surefire-report:report-only to run the report after the build to get > it to display the surefire report if there is a test case that failed, but > it's not keeping a current version. > i.e. if I choose a prior build that has failures, it still shows the current > surefire report which has successes. > Is this how it's supposed to work? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-622) Configure default build description
[ http://jira.codehaus.org/browse/CONTINUUM-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed CONTINUUM-622. -- Assignee: Olivier Lamy Resolution: Fixed Fix Version/s: (was: Future) 1.1-beta-3 duplicates with CONTINUUM-1207 > Configure default build description > --- > > Key: CONTINUUM-622 > URL: http://jira.codehaus.org/browse/CONTINUUM-622 > Project: Continuum > Issue Type: Wish > Components: Core system >Affects Versions: 1.0.2 >Reporter: Shinobu Kawai >Assignee: Olivier Lamy > Fix For: 1.1-beta-3 > > > It would be great if it was possible to configure the build definition > created when adding a project. > e.g. Currently, the goal for m2 projects are "clean install". If you wanted > to have all your projects do "clean deploy site site:deploy", you need to > edit them one by one. But if you could configure the defaults, you can set > it to the goals you would use most. > I guess this will improve with the upcoming bulk updating feature, but you > still need to edit it. ;) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3165) Publish the reference docs for 2.0.7
[ http://jira.codehaus.org/browse/MNG-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MNG-3165. Resolution: Fixed Fix Version/s: Documentation I have published the docs and changed "/ref/current" to point to 2.0.7. > Publish the reference docs for 2.0.7 > > > Key: MNG-3165 > URL: http://jira.codehaus.org/browse/MNG-3165 > Project: Maven 2 > Issue Type: Task > Components: Documentation: General >Affects Versions: 2.0.7 >Reporter: Wendy Smoak >Assignee: Dennis Lundberg > Fix For: Documentation > > > The reference documentation for Maven 2.0.7 is missing from the website. > See: http://maven.apache.org/ref/ > This needs to be part of the release process. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3174) Create a request/result mechanism that will reduce the number of signatures required for artifact resolution
Create a request/result mechanism that will reduce the number of signatures required for artifact resolution Key: MNG-3174 URL: http://jira.codehaus.org/browse/MNG-3174 Project: Maven 2 Issue Type: Improvement Reporter: Jason van Zyl -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MARTIFACT-1) Create a request/result mechanism that will reduce the number of signatures required for artifact resolution
[ http://jira.codehaus.org/browse/MARTIFACT-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl moved MNG-3174 to MARTIFACT-1: Workflow: jira (was: Maven New) Key: MARTIFACT-1 (was: MNG-3174) Project: Maven Artifact (was: Maven 2) > Create a request/result mechanism that will reduce the number of signatures > required for artifact resolution > > > Key: MARTIFACT-1 > URL: http://jira.codehaus.org/browse/MARTIFACT-1 > Project: Maven Artifact > Issue Type: Improvement >Reporter: Jason van Zyl > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MARTIFACT-1) Create a request/result mechanism that will reduce the number of signatures required for artifact resolution
[ http://jira.codehaus.org/browse/MARTIFACT-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MARTIFACT-1: -- Affects Version/s: 3.0-alpha-1 > Create a request/result mechanism that will reduce the number of signatures > required for artifact resolution > > > Key: MARTIFACT-1 > URL: http://jira.codehaus.org/browse/MARTIFACT-1 > Project: Maven Artifact > Issue Type: Improvement >Affects Versions: 3.0-alpha-1 >Reporter: Jason van Zyl >Assignee: Jason van Zyl > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MARTIFACT-2) Remove the internal fail-fast behavior and allow the collection of all problems
Remove the internal fail-fast behavior and allow the collection of all problems --- Key: MARTIFACT-2 URL: http://jira.codehaus.org/browse/MARTIFACT-2 Project: Maven Artifact Issue Type: Improvement Reporter: Jason van Zyl We need a mechanism that makes it flexible to change how the resolver works but not keep increasing the number of signatures: ArtifactResolutionResult result = artifactResolver.resolve( artifactResolutionRequest ); So this just removes the many signatures required to perform differently. Based on the request the artifactResolver responses appropriately. So I'm following the pattern we have in the embedder where you have a request that can be constructed in a ruby-esque way: ArtifactResolutionRequest request = new ArtifactResolutionRequest() .setArtifact( projectArtifact ) .setArtifactDependencies( project.getDependencyArtifacts() ) .setLocalRepository( localRepository ) .setRemoteRepostories( project.getRemoteArtifactRepositories() ) .setManagedVersionMap( managedVersions ) .setMetadataSource( artifactMetadataSource ); ArtifactResolutionResult result = artifactResolver.resolve( request ); This will greatly reduce the confusion from people using the resolver. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Deleted: (MARTIFACT-2) Remove the internal fail-fast behavior and allow the collection of all problems
[ http://jira.codehaus.org/browse/MARTIFACT-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl deleted MARTIFACT-2: -- > Remove the internal fail-fast behavior and allow the collection of all > problems > --- > > Key: MARTIFACT-2 > URL: http://jira.codehaus.org/browse/MARTIFACT-2 > Project: Maven Artifact > Issue Type: Improvement >Reporter: Jason van Zyl > > We need a mechanism that makes it flexible to change how the resolver works > but not keep increasing the number of signatures: > ArtifactResolutionResult result = artifactResolver.resolve( > artifactResolutionRequest ); > > So this just removes the many signatures required to perform differently. > Based on the request the artifactResolver responses appropriately. So I'm > following > the pattern we have in the embedder where you have a request that can be > constructed in a ruby-esque way: > > ArtifactResolutionRequest request = new ArtifactResolutionRequest() > .setArtifact( projectArtifact ) > .setArtifactDependencies( project.getDependencyArtifacts() ) > .setLocalRepository( localRepository ) > .setRemoteRepostories( project.getRemoteArtifactRepositories() ) > .setManagedVersionMap( managedVersions ) > .setMetadataSource( artifactMetadataSource ); > ArtifactResolutionResult result = artifactResolver.resolve( request ); > > This will greatly reduce the confusion from people using the resolver. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MARTIFACT-1) Create a request/result mechanism that will reduce the number of signatures required for artifact resolution
[ http://jira.codehaus.org/browse/MARTIFACT-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106148 ] Jason van Zyl commented on MARTIFACT-1: --- We need a mechanism that makes it flexible to change how the resolver works but not keep increasing the number of signatures: ArtifactResolutionResult result = artifactResolver.resolve( artifactResolutionRequest ); So this just removes the many signatures required to perform differently. Based on the request the artifactResolver responses appropriately. So I'm following the pattern we have in the embedder where you have a request that can be constructed in a ruby-esque way: ArtifactResolutionRequest request = new ArtifactResolutionRequest() .setArtifact( projectArtifact ) .setArtifactDependencies( project.getDependencyArtifacts() ) .setLocalRepository( localRepository ) .setRemoteRepostories( project.getRemoteArtifactRepositories() ) .setManagedVersionMap( managedVersions ) .setMetadataSource( artifactMetadataSource ); ArtifactResolutionResult result = artifactResolver.resolve( request ); This will greatly reduce the confusion from people using the resolver. > Create a request/result mechanism that will reduce the number of signatures > required for artifact resolution > > > Key: MARTIFACT-1 > URL: http://jira.codehaus.org/browse/MARTIFACT-1 > Project: Maven Artifact > Issue Type: Improvement >Affects Versions: 3.0-alpha-1 >Reporter: Jason van Zyl >Assignee: Jason van Zyl > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MARTIFACT-3) Remove the fail-fast behavior in the core as it makes providing useful client feedback to correct problems
Remove the fail-fast behavior in the core as it makes providing useful client feedback to correct problems -- Key: MARTIFACT-3 URL: http://jira.codehaus.org/browse/MARTIFACT-3 Project: Maven Artifact Issue Type: Improvement Affects Versions: 3.0-alpha-1 Reporter: Jason van Zyl Fix For: 3.0-alpha-1 The second part was to collect absolutely everything that can possibly go wrong during the resolution and collect all exceptions instead of blowing up when something is missing. The current behavior has lead to many integrators like Milos to have to reimplement large parts of the artifact resolution mechanism because the mechanism is essentially fail-fast which is pretty much useless in an integrated environment. So the ArtifactResolutionResult tries to capture what has gone wrong and currently this is what I tried to categorize: - metadata missing - metadata retrieval problems - version range violation - circular dependencies - artifacts missing - artifact retrieval problems These are the primary set of problems (there may be more, but this is a first pass) and there is no reason we can't tell the user exactly what went wrong. The current method of spewing out pile of mostly incomprehensible text (this is based on feedback from many clients I've worked with who look at the standard out put for missing artifacts and have a very difficult time understanding what the actual problem is) is not good. Instead the exact problem should be determined and by looking at the ArtifactResolutionResult client code like our CLI or more importantly in IDE integration we can very much help the user. So the code now goes as far as it possibly can to find all problems and is exposed via this one method that uses a request. All existing methods I have preserved and I wrapped new code in the old signatures and throw exceptions prematurely to mimic the old behavior. Nothing changes for most of the code. All these changes are currently only used by the project builder and ultimately the embedder.buildWithDependencies() method that needs to know everything that went wrong in order to provide useful information. Milos, Vlad, Eugene, you should soon be able to use this code instead of your local modifications. The one thing that needs to be added is method for mixing in local reactor dependencies so that within an IDE projects can be resolved from the module list in IDEA, the workspace in Eclipse, and the workspace in Netbeans. I made every attempt to be backward compatible but jardiff/clirr will be the arbiter of that. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MARTIFACT-1) Create a request/result mechanism that will reduce the number of signatures required for artifact resolution
[ http://jira.codehaus.org/browse/MARTIFACT-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MARTIFACT-1: -- Fix Version/s: 3.0-alpha-1 > Create a request/result mechanism that will reduce the number of signatures > required for artifact resolution > > > Key: MARTIFACT-1 > URL: http://jira.codehaus.org/browse/MARTIFACT-1 > Project: Maven Artifact > Issue Type: Improvement >Affects Versions: 3.0-alpha-1 >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 3.0-alpha-1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MARTIFACT-3) Remove the fail-fast behavior in the core as it makes providing useful client feedback to correct problems
[ http://jira.codehaus.org/browse/MARTIFACT-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MARTIFACT-3. - Resolution: Fixed First pass implemented. > Remove the fail-fast behavior in the core as it makes providing useful client > feedback to correct problems > -- > > Key: MARTIFACT-3 > URL: http://jira.codehaus.org/browse/MARTIFACT-3 > Project: Maven Artifact > Issue Type: Improvement >Affects Versions: 3.0-alpha-1 >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 3.0-alpha-1 > > >The second part was to collect absolutely everything that can possibly go > wrong during the resolution and collect all exceptions instead of blowing up > when something is missing. >The current behavior has lead to many integrators like Milos to have to > reimplement large parts of the artifact resolution mechanism because the > mechanism is essentially >fail-fast which is pretty much useless in an integrated environment. > >So the ArtifactResolutionResult tries to capture what has gone wrong and > currently this is what I tried to categorize: > >- metadata missing >- metadata retrieval problems >- version range violation >- circular dependencies >- artifacts missing >- artifact retrieval problems > >These are the primary set of problems (there may be more, but this is a > first pass) and there is no reason we can't tell the user exactly what went > wrong. The current >method of spewing out pile of mostly incomprehensible text (this is based > on feedback from many clients I've worked with who look at the standard out > put for missing >artifacts and have a very difficult time understanding what the actual > problem is) is not good. Instead the exact problem should be determined and > by looking at >the ArtifactResolutionResult client code like our CLI or more importantly > in IDE integration we can very much help the user. > >So the code now goes as far as it possibly can to find all problems and is > exposed via this one method that uses a request. All existing methods I have > preserved and >I wrapped new code in the old signatures and throw exceptions prematurely > to mimic the old behavior. Nothing changes for most of the code. All these > changes are >currently only used by the project builder and ultimately the > embedder.buildWithDependencies() method that needs to know everything that > went wrong in order to >provide useful information. > >Milos, Vlad, Eugene, you should soon be able to use this code instead of > your local modifications. The one thing that needs to be added is method for > mixing in local >reactor dependencies so that within an IDE projects can be resolved from > the module list in IDEA, the workspace in Eclipse, and the workspace in > Netbeans. I made >every attempt to be backward compatible but jardiff/clirr will be the > arbiter of that. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MARTIFACT-1) Create a request/result mechanism that will reduce the number of signatures required for artifact resolution
[ http://jira.codehaus.org/browse/MARTIFACT-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MARTIFACT-1. - Resolution: Fixed First pass implemented. > Create a request/result mechanism that will reduce the number of signatures > required for artifact resolution > > > Key: MARTIFACT-1 > URL: http://jira.codehaus.org/browse/MARTIFACT-1 > Project: Maven Artifact > Issue Type: Improvement >Affects Versions: 3.0-alpha-1 >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 3.0-alpha-1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3147) CLONE -No component for RAR packaging projects in components.xml
[
http://jira.codehaus.org/browse/MNG-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Liljenberg closed MNG-3147.
-
Resolution: Won't Fix
MRAR-17
> CLONE -No component for RAR packaging projects in components.xml
>
>
> Key: MNG-3147
> URL: http://jira.codehaus.org/browse/MNG-3147
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.6
>Reporter: Peter Liljenberg
>
> For a project with packaging "rar" the codehaus maven plugin for Cobertura
> does not work.
> During instrumentation the following message is displayed:
> "Not executing cobertura:instrument as the project is not a Java
> classpath-capable package"
> The reason for this is that in the CoberturaInstrumentMojo.execute() the
> code checks which language that the artifact is implemented in, like this:
> ArtifactHandler artifactHandler = project.getArtifact().getArtifactHandler();
> if ( !"java".equals( artifactHandler.getLanguage() ) )
> {
> getLog().info( "Not executing cobertura:instrument as the project
> is not a Java classpath-capable package" );
> }
> Looking at the components.xml in the Maven sources, we find that the "rar"
> packaging is not specified at all, meaning that it will be handled with the
> DefaultArtifactHandler and all properties set to null, including the language
> property.
> This can be fixed with the following addition to components.xml:
>
>
>
> org.apache.maven.artifact.handler.ArtifactHandler
> rar
>
> org.apache.maven.artifact.handler.DefaultArtifactHandler
>
> rar
> rar
> true
> java
> false
>
>
> ...
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-242) remove plexus utils sources from site plugin sources since it is a dependency
[ http://jira.codehaus.org/browse/MSITE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106158 ] Dennis Lundberg commented on MSITE-242: --- Removing these files would mean that we have to bump the prerequisites to maven 2.0.6. Previous version of maven always use plexus-utils-1.1, even though we declare a dependency on plexus-utils-1.4.5. I don't think we can set such a high prerequisite at this time, so I'd like to move this issue to a later release of the site-plugin. > remove plexus utils sources from site plugin sources since it is a dependency > - > > Key: MSITE-242 > URL: http://jira.codehaus.org/browse/MSITE-242 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Herve Boutemy >Assignee: Dennis Lundberg > Fix For: 2.0-beta-6 > > > the dependency has been uncommented, but the source code copy hasn't been > removed -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-170) [ERROR] VM #displayTree: error : too few arguments to macro
[ http://jira.codehaus.org/browse/MSITE-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MSITE-170. - Assignee: Vincent Siveton Resolution: Fixed This was solved by DOXIA-128. > [ERROR] VM #displayTree: error : too few arguments to macro > --- > > Key: MSITE-170 > URL: http://jira.codehaus.org/browse/MSITE-170 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: fabrizio giustina >Assignee: Vincent Siveton > Fix For: 2.0-beta-6 > > > when running mvn site:site a couple of "too few arguments to macro" always > pop up. This is extremely bad in terms of user experience, and we should find > a way to remove these logs: > [ERROR] VM #displayTree: error : too few arguments to macro. Wanted 2 got 0 > [ERROR] VM #menuItem: error : too few arguments to macro. Wanted 1 got 0 > These errors are due to a known velocity bug related to the use of recursive > macros: > http://issues.apache.org/bugzilla/show_bug.cgi?id=13623 > http://mail-archives.apache.org/mod_mbox/jakarta-velocity-user/200402.mbox/[EMAIL > PROTECTED] > Recursive macros are defined in > org/apache/maven/doxia/siterenderer/resources/default-site.vm in the doxia > site-renderer component. > Logging is handled in the plexus velocity component. > This velocity bug is still open in velocity and no patch will be available > anytime soon. In the meanwhile we should try to handle this situation in some > way by filtering out messages or removing the use of recursive macros (very > hard, they are used to print out the site tree)... or switching to a better > templating engine like freemarker. > This issue could probably be addressed in the plexus velocity component or in > the doxia site renderer (given that waiting for a bugfixed velocity release > is not an option). I'm anyway assigning it to the site plugin since it's > where users see these logs coming from and where probably users could open > similar issues. > Any suggestion on how to dirty-patch this? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3175) Take another pass over the exceptions that can occur during execution and project handling
Take another pass over the exceptions that can occur during execution and project handling -- Key: MNG-3175 URL: http://jira.codehaus.org/browse/MNG-3175 Project: Maven 2 Issue Type: Task Components: Embedding Reporter: Jason van Zyl Fix For: 2.1-alpha-1 The problems that can occur during execution and project handing: - POM parsing errors - missing metadata - error retrieving metadata - version range violations - circular dependency violations - missing artifacts - error retrieving artifacts I have most of this handled in the ArtifactResolutionResult, but the ProjectBuildingResult and the MavenExecutionResult need some work to make sure that everything is passed through correctly. This is of the utmost important for embedding because it means from the UI that integrators can give users exact details as to problems that occur. Milos has really gone a long way to work around the fact we don't do this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3175) Take another pass over the exceptions that can occur during execution and project handling
[ http://jira.codehaus.org/browse/MNG-3175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3175: --- Affects Version/s: 2.1-alpha-1 Fix Version/s: 2.1-alpha-1 > Take another pass over the exceptions that can occur during execution and > project handling > -- > > Key: MNG-3175 > URL: http://jira.codehaus.org/browse/MNG-3175 > Project: Maven 2 > Issue Type: Task > Components: Embedding >Affects Versions: 2.1-alpha-1 >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 2.1-alpha-1 > > > The problems that can occur during execution and project handing: > - POM parsing errors > - missing metadata > - error retrieving metadata > - version range violations > - circular dependency violations > - missing artifacts > - error retrieving artifacts > I have most of this handled in the ArtifactResolutionResult, but the > ProjectBuildingResult and the MavenExecutionResult need some work to make > sure that everything is passed through correctly. This is of the utmost > important for embedding because it means from the UI that integrators can > give users exact details as to problems that occur. Milos has really gone a > long way to work around the fact we don't do this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1422) The icon for 'Cancel Build' is missing from the legend
The icon for 'Cancel Build' is missing from the legend -- Key: CONTINUUM-1422 URL: http://jira.codehaus.org/browse/CONTINUUM-1422 Project: Continuum Issue Type: Improvement Components: Web - UI Affects Versions: 1.1-beta-3 Environment: Continuum trunk r571513 Reporter: Wendy Smoak Priority: Minor There is a new icon for cancelling a build. It needs to be added to the legend, below the horizontal line with the other actions such as delete and release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1423) Default project group is missing from the list
Default project group is missing from the list -- Key: CONTINUUM-1423 URL: http://jira.codehaus.org/browse/CONTINUUM-1423 Project: Continuum Issue Type: Bug Affects Versions: 1.1-beta-3 Environment: Continuum trunk r571513 Reporter: Wendy Smoak In a new installation, after creating the admin user and logging in as admin, the list of project groups is empty. When I add a project group, it is assigned number '2', so I assume the Default group is there, just invisible for some reason. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-201) ${modules} renders as [] causing parse error
[
http://jira.codehaus.org/browse/MSITE-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MSITE-201.
-
Resolution: Fixed
Fixed in r571915.
> ${modules} renders as [] causing parse error
>
>
> Key: MSITE-201
> URL: http://jira.codehaus.org/browse/MSITE-201
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-6
>Reporter: Kenney Westerhof
>Assignee: Dennis Lundberg
> Fix For: 2.0-beta-6
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-206) Move the webapp features to a separate plugin
[ http://jira.codehaus.org/browse/MSITE-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106169 ] Dennis Lundberg commented on MSITE-206: --- Jason, would you mind if I bump this issue to a later release? It was originally scheduled for version 2.0. However that version was later renamed to 2.0-beta-6 and this issue came along for the ride. > Move the webapp features to a separate plugin > - > > Key: MSITE-206 > URL: http://jira.codehaus.org/browse/MSITE-206 > Project: Maven 2.x Site Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-5 >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 2.0-beta-6 > > > Prevent the complete download of Jetty for rendering the site and move to a > separate plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-1422) The icon for 'Cancel Build' is missing from the legend
[ http://jira.codehaus.org/browse/CONTINUUM-1422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak closed CONTINUUM-1422. -- Assignee: Wendy Smoak Resolution: Fixed Fix Version/s: 1.1-beta-3 Fixed in r571923 > The icon for 'Cancel Build' is missing from the legend > -- > > Key: CONTINUUM-1422 > URL: http://jira.codehaus.org/browse/CONTINUUM-1422 > Project: Continuum > Issue Type: Improvement > Components: Web - UI >Affects Versions: 1.1-beta-3 > Environment: Continuum trunk r571513 >Reporter: Wendy Smoak >Assignee: Wendy Smoak >Priority: Minor > Fix For: 1.1-beta-3 > > > There is a new icon for cancelling a build. It needs to be added to the > legend, below the horizontal line with the other actions such as delete and > release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1424) Ability to Cancel Build for a subset of a project group
Ability to Cancel Build for a subset of a project group --- Key: CONTINUUM-1424 URL: http://jira.codehaus.org/browse/CONTINUUM-1424 Project: Continuum Issue Type: Improvement Components: Web interface Affects Versions: 1.1-beta-2 Reporter: Wendy Smoak It should be possible to cancel the build for a subset of a project group using the checkboxes and a new button. It would be nice if the button did not appear if no builds are in progress. (This was already implemented for "Delete Project" and "Build Project" in CONTINUUM-983.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
