[jira] Commented: (MNG-193) symmetry for outputs of a plugin
[ http://jira.codehaus.org/browse/MNG-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204380#action_204380 ] Jason van Zyl commented on MNG-193: --- This will be part of a new Plugin API which is out of scope for Maven 3.0. > symmetry for outputs of a plugin > > > Key: MNG-193 > URL: http://jira.codehaus.org/browse/MNG-193 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Plugins and Lifecycle >Reporter: Brett Porter > Fix For: 3.1.alpha1 > > > We need a way to declaratively say what the outputs of a plugins are going to > be. The concrete example being the Antlr plugin that generates a source root, > we should know what this is going to be before executing the 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] Updated: (MNG-193) symmetry for outputs of a plugin
[ http://jira.codehaus.org/browse/MNG-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-193: -- Issue Type: New Feature (was: Improvement) > symmetry for outputs of a plugin > > > Key: MNG-193 > URL: http://jira.codehaus.org/browse/MNG-193 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Plugins and Lifecycle >Reporter: Brett Porter > Fix For: 3.1.alpha1 > > > We need a way to declaratively say what the outputs of a plugins are going to > be. The concrete example being the Antlr plugin that generates a source root, > we should know what this is going to be before executing the 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: (MNG-4242) -DlocalRepository=file:/foo configuration lost
[
http://jira.codehaus.org/browse/MNG-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-4242.
--
Resolution: Incomplete
> -DlocalRepository=file:/foo configuration lost
> ---
>
> Key: MNG-4242
> URL: http://jira.codehaus.org/browse/MNG-4242
> Project: Maven 2 & 3
> Issue Type: Bug
> Environment: Maven 2.1
> JDK 1.6.10
>Reporter: Martin Gainty
>
> given org.apache.maven.project.DefaultMavenprojectBuilder has this code
> {code:java}
> public ProjectBuilderConfiguration setLocalRepository( ArtifactRepository
> localRepository )
> {
> this.localRepository = localRepository;
> //this returns an unimplemented null object
> return this;
> }
> public MavenProject buildStandaloneSuperProject( ArtifactRepository
> localRepository,
> ProfileManager
> profileManager )
> throws ProjectBuildingException
> {
> return buildStandaloneSuperProject( new
> DefaultProjectBuilderConfiguration().setLocalRepository( localRepository )
>
> .setGlobalProfileManager( profileManager ) );
> }
> //calls to 1 arg constructor
> // what is using this externally? jvz.
> public MavenProject buildStandaloneSuperProject( ArtifactRepository
> localRepository )
> throws ProjectBuildingException
> {
> //TODO mkleint - use the (Container, Properties) constructor to make
> system properties embeddable
> ProfileManager profileManager = new DefaultProfileManager( container
> );
> return buildStandaloneSuperProject( new
> DefaultProjectBuilderConfiguration().setLocalRepository( localRepository )
>
> .setGlobalProfileManager( profileManager ) );
> //the input to buildStandloneSuperProject is essentially an empty object
> }
> //supposedly calls here
> public MavenProject buildStandaloneSuperProject(
> ProjectBuilderConfiguration config )
> throws ProjectBuildingException
> {
>the real work..
> }
>org.apache.maven.project.ProjectBuilderConfiguration contains this
> definition
> public interface ProjectBuilderConfiguration
> {
> ArtifactRepository getLocalRepository();
> ProfileManager getGlobalProfileManager();
> Properties getUserProperties();
> Properties getExecutionProperties();
> ProjectBuilderConfiguration setGlobalProfileManager( ProfileManager
> globalProfileManager );
> //nothing happens here
> ProfileManager getGlobalProfileManager();
> {code}
> anything passed into these set of routines is nulled out by setLocalRepository
> Martin Gainty
> 15 Ju 2009 18:37
--
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: (MNG-4242) -DlocalRepository=file:/foo configuration lost
[
http://jira.codehaus.org/browse/MNG-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204379#action_204379
]
Jason van Zyl commented on MNG-4242:
Provide a test, or some way to understand what you're trying to convey. I don't
understand this at all.
> -DlocalRepository=file:/foo configuration lost
> ---
>
> Key: MNG-4242
> URL: http://jira.codehaus.org/browse/MNG-4242
> Project: Maven 2 & 3
> Issue Type: Bug
> Environment: Maven 2.1
> JDK 1.6.10
>Reporter: Martin Gainty
>
> given org.apache.maven.project.DefaultMavenprojectBuilder has this code
> {code:java}
> public ProjectBuilderConfiguration setLocalRepository( ArtifactRepository
> localRepository )
> {
> this.localRepository = localRepository;
> //this returns an unimplemented null object
> return this;
> }
> public MavenProject buildStandaloneSuperProject( ArtifactRepository
> localRepository,
> ProfileManager
> profileManager )
> throws ProjectBuildingException
> {
> return buildStandaloneSuperProject( new
> DefaultProjectBuilderConfiguration().setLocalRepository( localRepository )
>
> .setGlobalProfileManager( profileManager ) );
> }
> //calls to 1 arg constructor
> // what is using this externally? jvz.
> public MavenProject buildStandaloneSuperProject( ArtifactRepository
> localRepository )
> throws ProjectBuildingException
> {
> //TODO mkleint - use the (Container, Properties) constructor to make
> system properties embeddable
> ProfileManager profileManager = new DefaultProfileManager( container
> );
> return buildStandaloneSuperProject( new
> DefaultProjectBuilderConfiguration().setLocalRepository( localRepository )
>
> .setGlobalProfileManager( profileManager ) );
> //the input to buildStandloneSuperProject is essentially an empty object
> }
> //supposedly calls here
> public MavenProject buildStandaloneSuperProject(
> ProjectBuilderConfiguration config )
> throws ProjectBuildingException
> {
>the real work..
> }
>org.apache.maven.project.ProjectBuilderConfiguration contains this
> definition
> public interface ProjectBuilderConfiguration
> {
> ArtifactRepository getLocalRepository();
> ProfileManager getGlobalProfileManager();
> Properties getUserProperties();
> Properties getExecutionProperties();
> ProjectBuilderConfiguration setGlobalProfileManager( ProfileManager
> globalProfileManager );
> //nothing happens here
> ProfileManager getGlobalProfileManager();
> {code}
> anything passed into these set of routines is nulled out by setLocalRepository
> Martin Gainty
> 15 Ju 2009 18:37
--
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: (MNG-4354) DefaultArtifactResolver has problems when used with multiple repos
[ http://jira.codehaus.org/browse/MNG-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204378#action_204378 ] Hasan Ceylan commented on MNG-4354: --- Hello Brett, Two things: 1) Responding with a feed back 2) Closing the issue... These two things obviously totally different. If I had got this feedback three months ago, - while I still remember all the insights - I would have solved it totally by then. So, not that the fact that it's not been solved, but no feedback has been provided for so long, that is I'm not happy with. Regards, Hasan Ceylan > DefaultArtifactResolver has problems when used with multiple repos > -- > > Key: MNG-4354 > URL: http://jira.codehaus.org/browse/MNG-4354 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.2.1 > Environment: N/A >Reporter: Hasan Ceylan >Priority: Blocker > Fix For: 2.2.2 > > Attachments: maven.patch > > > DefaultArtifactResolver attaches the repositories to artifacts (AFAIK) to > optimize the repo look ups. > Here I have a case > 1) An artifact dependens on org.eclipse.equniox:app:1.2.0 > 2) org.eclipse.equinox:app depends on > org.eclipse.equinox:registry:[3.4.0,4.0.0) > 3) Both central repo and custom corporate repo has > org.eclipse.equinox:registry > 4) central repo has outdated versions > 3.2.1-R32x_v20060814 > 3.3.0-v20070522 > 5) DefaultArtifactResolver for optimization attaches central repo (last one > wins) > 6) Central repo neither satisfies the version range nor - even if it did - > has the latest version > 7) dependency is not satisfied > 8) Build halts > Attached patch is a dirty hack to disable signle repo downloand and checks > all the repositories. -- 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-3648) Maven is too verbose in its output, obscuring actual messages
[ http://jira.codehaus.org/browse/MNG-3648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-3648. -- Resolution: Fixed Fix Version/s: (was: 3.x) 3.0-alpha-6 > Maven is too verbose in its output, obscuring actual messages > - > > Key: MNG-3648 > URL: http://jira.codehaus.org/browse/MNG-3648 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Logging >Affects Versions: 2.0.8 >Reporter: Ittay Dror > Fix For: 3.0-alpha-6 > > > Things I would like to move to 'debug' or 'trace' levels: > 1. Reactor build order list: the order is always the same, so why print? if > it's an issue of telling the user, in case he forgot to trigger a profile, > then i think that in most cases it misses the target, simply because it > appears so much that people just don't pay attention to the list > 2. Reactor summary: showing successful modules means it's harder to find the > failed ones. Just show me what failed. > 3. Plugins usually print they are running in 'info' level. This is actually a > tracing message as they will always run. > I know I can suppress these with '-q', but then it suppresses all 'info' > messages, so that relevant information about actions taken (actions that > change in each build) is not printed. -- 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: (MNG-3648) Maven is too verbose in its output, obscuring actual messages
[ http://jira.codehaus.org/browse/MNG-3648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204365#action_204365 ] Jason van Zyl commented on MNG-3648: Output is a lot better in 3.0. > Maven is too verbose in its output, obscuring actual messages > - > > Key: MNG-3648 > URL: http://jira.codehaus.org/browse/MNG-3648 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Logging >Affects Versions: 2.0.8 >Reporter: Ittay Dror > Fix For: 3.0-alpha-6 > > > Things I would like to move to 'debug' or 'trace' levels: > 1. Reactor build order list: the order is always the same, so why print? if > it's an issue of telling the user, in case he forgot to trigger a profile, > then i think that in most cases it misses the target, simply because it > appears so much that people just don't pay attention to the list > 2. Reactor summary: showing successful modules means it's harder to find the > failed ones. Just show me what failed. > 3. Plugins usually print they are running in 'info' level. This is actually a > tracing message as they will always run. > I know I can suppress these with '-q', but then it suppresses all 'info' > messages, so that relevant information about actions taken (actions that > change in each build) is not printed. -- 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-3658) improve maven embedder documentation
[ http://jira.codehaus.org/browse/MNG-3658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-3658. -- Resolution: Won't Fix Fix Version/s: (was: 3.x) > improve maven embedder documentation > > > Key: MNG-3658 > URL: http://jira.codehaus.org/browse/MNG-3658 > Project: Maven 2 & 3 > Issue Type: Wish > Components: Embedding >Affects Versions: 2.0.7 >Reporter: Benjamin Pochat > > Hi, > I would like to use the maven embedder. > What is described in the maven website seems wonderfull > (http://maven.apache.org/guides/mini/guide-embedding-m2.html) > But when I tried to go further, I was not able to find a precise > documentation about the API that seems to be provided. > The documentation that comes out from Google > (http://repo1.maven.org/maven2/org/apache/maven/maven-embedder/2.0.4/) looks > like out of date : maven website describes that the class MavenEmbedder > implements a method "execute" returning a MavenExecutionResult ; but this > method is not documented in the javadoc coming out from Google. > It even looks like the maven embedder is not included in the standard > distribution of maven : there is no classe named MavenEmbedder in the lib > maven-core-2.0.X.jar, neither in the dependecies of the pom > maven-core-2.0.X.pom. > In other words, I have nothing to make maven embedding work. > Regards, > Benjamin -- 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: (MNG-3658) improve maven embedder documentation
[ http://jira.codehaus.org/browse/MNG-3658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204364#action_204364 ] Jason van Zyl commented on MNG-3658: The embedder doesn't exist anymore, new documentation will need to be created. > improve maven embedder documentation > > > Key: MNG-3658 > URL: http://jira.codehaus.org/browse/MNG-3658 > Project: Maven 2 & 3 > Issue Type: Wish > Components: Embedding >Affects Versions: 2.0.7 >Reporter: Benjamin Pochat > > Hi, > I would like to use the maven embedder. > What is described in the maven website seems wonderfull > (http://maven.apache.org/guides/mini/guide-embedding-m2.html) > But when I tried to go further, I was not able to find a precise > documentation about the API that seems to be provided. > The documentation that comes out from Google > (http://repo1.maven.org/maven2/org/apache/maven/maven-embedder/2.0.4/) looks > like out of date : maven website describes that the class MavenEmbedder > implements a method "execute" returning a MavenExecutionResult ; but this > method is not documented in the javadoc coming out from Google. > It even looks like the maven embedder is not included in the standard > distribution of maven : there is no classe named MavenEmbedder in the lib > maven-core-2.0.X.jar, neither in the dependecies of the pom > maven-core-2.0.X.pom. > In other words, I have nothing to make maven embedding work. > Regards, > Benjamin -- 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-3670) Running 'compile' goal on specific project leads to exception.
[
http://jira.codehaus.org/browse/MNG-3670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-3670.
--
Resolution: Incomplete
Fix Version/s: (was: 3.x)
> Running 'compile' goal on specific project leads to exception.
> --
>
> Key: MNG-3670
> URL: http://jira.codehaus.org/browse/MNG-3670
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Embedding
>Affects Versions: 3.0-alpha-1
>Reporter: Anton Makeev
> Attachments: problem.zip
>
>
> The exception arises if particular artifacts have not been downloaded yet.
> {code}
> org.apache.maven.wagon.observers.ChecksumObserver.transferStarted(ChecksumObserver.java:68)
> org.apache.maven.wagon.events.TransferEventSupport.fireTransferStarted(TransferEventSupport.java:106)
> org.apache.maven.wagon.AbstractWagon.fireGetStarted(AbstractWagon.java:528)
> org.apache.maven.wagon.AbstractWagon.getTransfer(AbstractWagon.java:293)
> org.apache.maven.wagon.AbstractWagon.getTransfer(AbstractWagon.java:274)
> org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:97)
> org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61)
> org.apache.maven.artifact.manager.DefaultWagonManager.verifyChecksum(DefaultWagonManager.java:733)
> org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:577)
> org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:424)
> org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:341)
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:167)
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:82)
> org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:552)
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:233)
> org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:132)
> org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:509)
> org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:539)
> org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:132)
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:347)
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:321)
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:289)
> org.apache.maven.plugin.DefaultPluginManager.getPluginArtifacts(DefaultPluginManager.java:436)
> org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:279)
> org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:211)
> org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:186)
> org.apache.maven.plugin.loader.DefaultPluginLoader.loadPlugin(DefaultPluginLoader.java:79)
> org.apache.maven.plugin.loader.DefaultPluginLoader.loadPlugin(DefaultPluginLoader.java:52)
> org.apache.maven.lifecycle.plan.DefaultBuildPlanner.loadPluginDescriptor(DefaultBuildPlanner.java:322)
> org.apache.maven.lifecycle.plan.DefaultBuildPlanner.findForkModifiers(DefaultBuildPlanner.java:192)
> org.apache.maven.lifecycle.plan.DefaultBuildPlanner.addForkedLifecycleModifiers(DefaultBuildPlanner.java:179)
> org.apache.maven.lifecycle.plan.DefaultBuildPlanner.constructBuildPlan_aroundBody0(DefaultBuildPlanner.java:117)
> org.apache.maven.lifecycle.plan.DefaultBuildPlanner.constructBuildPlan_aroundBody1$advice(DefaultBuildPlanner.java:403)
> org.apache.maven.lifecycle.plan.DefaultBuildPlanner.constructBuildPlan(DefaultBuildPlanner.java:1)
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.getLifecycleBindings(DefaultLifecycleExecutor.java:400)
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentForProject(DefaultLifecycleExecutor.java:235)
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:191)
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149)
> org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223)
> org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304)
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1)
> org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:904)
> org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304)
> org.apache.maven.embedder.MavenEmbedder.
[jira] Commented: (MNG-3681) different artifact resolution from Maven 2.0.9 for continuum-wagon-notifier
[ http://jira.codehaus.org/browse/MNG-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204362#action_204362 ] Jason van Zyl commented on MNG-3681: Test against 3.0 alphas and reopen if it's still a problem. > different artifact resolution from Maven 2.0.9 for continuum-wagon-notifier > --- > > Key: MNG-3681 > URL: http://jira.codehaus.org/browse/MNG-3681 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0-alpha-1 >Reporter: Brett Porter > > plexus-component-api 1.0-alpha-16 via plexus-formica via continuum-core is > resolved in 2.1-SNAPSHOT > 1.0-alpha-20 via plexus-quartz via continuum-core is resolved in 2.0.9 > This can be seen by checking out and building Continuum trunk at r679645 -- 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: (MNG-3670) Running 'compile' goal on specific project leads to exception.
[
http://jira.codehaus.org/browse/MNG-3670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204363#action_204363
]
Jason van Zyl commented on MNG-3670:
Test against 3.0 alphas, reopen if still a problem.
> Running 'compile' goal on specific project leads to exception.
> --
>
> Key: MNG-3670
> URL: http://jira.codehaus.org/browse/MNG-3670
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Embedding
>Affects Versions: 3.0-alpha-1
>Reporter: Anton Makeev
> Attachments: problem.zip
>
>
> The exception arises if particular artifacts have not been downloaded yet.
> {code}
> org.apache.maven.wagon.observers.ChecksumObserver.transferStarted(ChecksumObserver.java:68)
> org.apache.maven.wagon.events.TransferEventSupport.fireTransferStarted(TransferEventSupport.java:106)
> org.apache.maven.wagon.AbstractWagon.fireGetStarted(AbstractWagon.java:528)
> org.apache.maven.wagon.AbstractWagon.getTransfer(AbstractWagon.java:293)
> org.apache.maven.wagon.AbstractWagon.getTransfer(AbstractWagon.java:274)
> org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:97)
> org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61)
> org.apache.maven.artifact.manager.DefaultWagonManager.verifyChecksum(DefaultWagonManager.java:733)
> org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:577)
> org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:424)
> org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:341)
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:167)
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:82)
> org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:552)
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:233)
> org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:132)
> org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:509)
> org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:539)
> org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:132)
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:347)
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:321)
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:289)
> org.apache.maven.plugin.DefaultPluginManager.getPluginArtifacts(DefaultPluginManager.java:436)
> org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:279)
> org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:211)
> org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:186)
> org.apache.maven.plugin.loader.DefaultPluginLoader.loadPlugin(DefaultPluginLoader.java:79)
> org.apache.maven.plugin.loader.DefaultPluginLoader.loadPlugin(DefaultPluginLoader.java:52)
> org.apache.maven.lifecycle.plan.DefaultBuildPlanner.loadPluginDescriptor(DefaultBuildPlanner.java:322)
> org.apache.maven.lifecycle.plan.DefaultBuildPlanner.findForkModifiers(DefaultBuildPlanner.java:192)
> org.apache.maven.lifecycle.plan.DefaultBuildPlanner.addForkedLifecycleModifiers(DefaultBuildPlanner.java:179)
> org.apache.maven.lifecycle.plan.DefaultBuildPlanner.constructBuildPlan_aroundBody0(DefaultBuildPlanner.java:117)
> org.apache.maven.lifecycle.plan.DefaultBuildPlanner.constructBuildPlan_aroundBody1$advice(DefaultBuildPlanner.java:403)
> org.apache.maven.lifecycle.plan.DefaultBuildPlanner.constructBuildPlan(DefaultBuildPlanner.java:1)
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.getLifecycleBindings(DefaultLifecycleExecutor.java:400)
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentForProject(DefaultLifecycleExecutor.java:235)
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:191)
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149)
> org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223)
> org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304)
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1)
> org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:904)
> org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304)
[jira] Closed: (MNG-3681) different artifact resolution from Maven 2.0.9 for continuum-wagon-notifier
[ http://jira.codehaus.org/browse/MNG-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-3681. -- Resolution: Incomplete Fix Version/s: (was: 3.x) > different artifact resolution from Maven 2.0.9 for continuum-wagon-notifier > --- > > Key: MNG-3681 > URL: http://jira.codehaus.org/browse/MNG-3681 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0-alpha-1 >Reporter: Brett Porter > > plexus-component-api 1.0-alpha-16 via plexus-formica via continuum-core is > resolved in 2.1-SNAPSHOT > 1.0-alpha-20 via plexus-quartz via continuum-core is resolved in 2.0.9 > This can be seen by checking out and building Continuum trunk at r679645 -- 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: (MNG-3771) The site plugin relies on MavenProjectBuilder.build( project, localRepo, profileManager )
[ http://jira.codehaus.org/browse/MNG-3771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204361#action_204361 ] Jason van Zyl commented on MNG-3771: The site plugin lives on its own now. > The site plugin relies on MavenProjectBuilder.build( project, localRepo, > profileManager ) > - > > Key: MNG-3771 > URL: http://jira.codehaus.org/browse/MNG-3771 > Project: Maven 2 & 3 > Issue Type: Task >Reporter: Jason van Zyl >Assignee: Jason van Zyl > > We need to make a new version of the plugin and decouple from the internals. -- 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-3771) The site plugin relies on MavenProjectBuilder.build( project, localRepo, profileManager )
[ http://jira.codehaus.org/browse/MNG-3771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-3771. -- Resolution: Won't Fix Fix Version/s: (was: 3.x) > The site plugin relies on MavenProjectBuilder.build( project, localRepo, > profileManager ) > - > > Key: MNG-3771 > URL: http://jira.codehaus.org/browse/MNG-3771 > Project: Maven 2 & 3 > Issue Type: Task >Reporter: Jason van Zyl >Assignee: Jason van Zyl > > We need to make a new version of the plugin and decouple from the internals. -- 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: (MNG-3894) provide an include mechanism to include other pom.xml
[ http://jira.codehaus.org/browse/MNG-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204359#action_204359 ] Jason van Zyl commented on MNG-3894: You can use scope = import today for many cases. > provide an include mechanism to include other pom.xml > - > > Key: MNG-3894 > URL: http://jira.codehaus.org/browse/MNG-3894 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Inheritance and Interpolation > Environment: any >Reporter: Stefan Franke > > The idea to manage project independent templates is not new. But it is not > possible to do this with maven and neither inheritance nor the dependency > mechanism is enough. > The include mechnism would include the requested pom (including ist parent > poms) as if the containing elements where part of the current pom. Thus > allowing to use every available pom mechanism. On conflict local pom settings > wins. > Very useful and needed to reduce redundancy between different projects! -- 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-3894) provide an include mechanism to include other pom.xml
[ http://jira.codehaus.org/browse/MNG-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-3894. -- Resolution: Not A Bug Fix Version/s: (was: 3.x) > provide an include mechanism to include other pom.xml > - > > Key: MNG-3894 > URL: http://jira.codehaus.org/browse/MNG-3894 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Inheritance and Interpolation > Environment: any >Reporter: Stefan Franke > > The idea to manage project independent templates is not new. But it is not > possible to do this with maven and neither inheritance nor the dependency > mechanism is enough. > The include mechnism would include the requested pom (including ist parent > poms) as if the containing elements where part of the current pom. Thus > allowing to use every available pom mechanism. On conflict local pom settings > wins. > Very useful and needed to reduce redundancy between different projects! -- 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: (MNG-401) Add meta-data to root of Maven repository.
[ http://jira.codehaus.org/browse/MNG-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204358#action_204358 ] Jason van Zyl commented on MNG-401: --- This is now the Nexus index for all intents and purposes. > Add meta-data to root of Maven repository. > -- > > Key: MNG-401 > URL: http://jira.codehaus.org/browse/MNG-401 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Artifacts and Repositories > Environment: N/A >Reporter: Faron Dutton > > Add an XML file (e.g., maven-info.xml) to the root of all Maven repositories > that describes which variant of the repository structure a site uses. This > would be very helpful for tools that need to navigate a repository's > directory structure. For repositories that lack this meta-data, the tool > would assume a Maven 1.0 structure. -- 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-401) Add meta-data to root of Maven repository.
[ http://jira.codehaus.org/browse/MNG-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-401. - Resolution: Won't Fix Fix Version/s: (was: 3.x) > Add meta-data to root of Maven repository. > -- > > Key: MNG-401 > URL: http://jira.codehaus.org/browse/MNG-401 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Artifacts and Repositories > Environment: N/A >Reporter: Faron Dutton > > Add an XML file (e.g., maven-info.xml) to the root of all Maven repositories > that describes which variant of the repository structure a site uses. This > would be very helpful for tools that need to navigate a repository's > directory structure. For repositories that lack this meta-data, the tool > would assume a Maven 1.0 structure. -- 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: (MNG-714) When artifact not found on mirror the real site isn't checked
[ http://jira.codehaus.org/browse/MNG-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204357#action_204357 ] Jason van Zyl commented on MNG-714: --- The real mirror is not checked on purpose. The way repository managers work these days would break severely if we started doing this. > When artifact not found on mirror the real site isn't checked > - > > Key: MNG-714 > URL: http://jira.codehaus.org/browse/MNG-714 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0-beta-1 >Reporter: Kenney Westerhof >Assignee: Jason van Zyl > Attachments: MNG-714-maven-artifact-manager.patch > > Original Estimate: 3 hours > Remaining Estimate: 3 hours > > I'm using the settings.xml mirror feature as a local cache. Periodically I > upload my local repo > to the webserver specified as mirror. > When an artifact cannot be found on the mirror, the original site isn't > checked (and possibly the rest of the sites). > I'm not sure what the exact function of the mirror is (except caching?), but > repo1 is checked often regardless > of mirror presence, so I figure it's not meant to totally disable checking > the central repo's. > Simple reproduction: define a few mirrors in your settings.xml for central, > central-plugins and snapshots, pointing to > say file://tmp/empty/dir/. > Stacktrace: > [DEBUG] Error resolving artifact version from metadata. > org.apache.maven.wagon.ResourceDoesNotExistException: Unable to locate > resource in repository > at > org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:81) > at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:70) > at > org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:343) > at > org.apache.maven.artifact.manager.DefaultWagonManager.getArtifactMetadata(DefaultWagonManager.java:263) > at > org.apache.maven.artifact.metadata.AbstractVersionArtifactMetadata.retrieveFromRemoteRepository(AbstractVersionArtifactMetadata.java:93) > at > org.apache.maven.artifact.transform.AbstractVersionTransformation.retrieveFromRemoteRepository(AbstractVersionTransformation.java:171) > at > org.apache.maven.artifact.transform.AbstractVersionTransformation.resolveVersion(AbstractVersionTransformation.java:96) > at > org.apache.maven.artifact.transform.SnapshotTransformation.transformForResolve(SnapshotTransformation.java:43) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:95) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:63) > at > org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:290) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:274) > at > org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:81) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:186) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:70) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:197) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:185) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:156) > at > org.apache.maven.plugin.DefaultPluginManager.ensurePluginContainerIsComplete(DefaultPluginManager.java:544) > at > org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:479) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:334) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:378) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:351) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:337) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:229) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:123) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:209) > at org.apache.maven.cli.Ma
[jira] Updated: (MNG-683) Lifecycle mappings should specify phase bindings in terms of general functionality type
[ http://jira.codehaus.org/browse/MNG-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-683: -- Fix Version/s: (was: 3.x) 3.1.alpha1 > Lifecycle mappings should specify phase bindings in terms of general > functionality type > --- > > Key: MNG-683 > URL: http://jira.codehaus.org/browse/MNG-683 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Plugins and Lifecycle >Affects Versions: 2.0-alpha-3 >Reporter: John Casey > Fix For: 3.1.alpha1 > > > Currently, the 'jar' lifecycle mapping specifies that the 'compiler:complie' > mojo will be bound to the 'compile' phase. The 'compiler' prefix is mapped > concretely to the maven-compiler-plugin. This means that it's not currently > possible to use a different mojo to compile jar projects. > How can a third party implementor touch this lifecycle phase for jars without > implementing a new plexus-compiler implementation, and even then, how is the > new compiler impl supposed to be added to the plugin container? -- 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: (MNG-4354) DefaultArtifactResolver has problems when used with multiple repos
[ http://jira.codehaus.org/browse/MNG-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204356#action_204356 ] Brett Porter commented on MNG-4354: --- we can take a look for 2.2.x, but a patch that is classified as a "dirty hack" with no tests in critical functionality is not something we can just apply. If you put together an integration test and more information about the changes required it can be adopted much faster. Thanks! We don't assign things as they come in, they get reviewed as people with time look over them, and our priorities tend to be on regressions and bugs with large numbers of votes. > DefaultArtifactResolver has problems when used with multiple repos > -- > > Key: MNG-4354 > URL: http://jira.codehaus.org/browse/MNG-4354 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.2.1 > Environment: N/A >Reporter: Hasan Ceylan >Priority: Blocker > Fix For: 2.2.2 > > Attachments: maven.patch > > > DefaultArtifactResolver attaches the repositories to artifacts (AFAIK) to > optimize the repo look ups. > Here I have a case > 1) An artifact dependens on org.eclipse.equniox:app:1.2.0 > 2) org.eclipse.equinox:app depends on > org.eclipse.equinox:registry:[3.4.0,4.0.0) > 3) Both central repo and custom corporate repo has > org.eclipse.equinox:registry > 4) central repo has outdated versions > 3.2.1-R32x_v20060814 > 3.3.0-v20070522 > 5) DefaultArtifactResolver for optimization attaches central repo (last one > wins) > 6) Central repo neither satisfies the version range nor - even if it did - > has the latest version > 7) dependency is not satisfied > 8) Build halts > Attached patch is a dirty hack to disable signle repo downloand and checks > all the repositories. -- 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-714) When artifact not found on mirror the real site isn't checked
[ http://jira.codehaus.org/browse/MNG-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-714. - Resolution: Won't Fix Fix Version/s: (was: 3.x) > When artifact not found on mirror the real site isn't checked > - > > Key: MNG-714 > URL: http://jira.codehaus.org/browse/MNG-714 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0-beta-1 >Reporter: Kenney Westerhof >Assignee: Jason van Zyl > Attachments: MNG-714-maven-artifact-manager.patch > > Original Estimate: 3 hours > Remaining Estimate: 3 hours > > I'm using the settings.xml mirror feature as a local cache. Periodically I > upload my local repo > to the webserver specified as mirror. > When an artifact cannot be found on the mirror, the original site isn't > checked (and possibly the rest of the sites). > I'm not sure what the exact function of the mirror is (except caching?), but > repo1 is checked often regardless > of mirror presence, so I figure it's not meant to totally disable checking > the central repo's. > Simple reproduction: define a few mirrors in your settings.xml for central, > central-plugins and snapshots, pointing to > say file://tmp/empty/dir/. > Stacktrace: > [DEBUG] Error resolving artifact version from metadata. > org.apache.maven.wagon.ResourceDoesNotExistException: Unable to locate > resource in repository > at > org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:81) > at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:70) > at > org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:343) > at > org.apache.maven.artifact.manager.DefaultWagonManager.getArtifactMetadata(DefaultWagonManager.java:263) > at > org.apache.maven.artifact.metadata.AbstractVersionArtifactMetadata.retrieveFromRemoteRepository(AbstractVersionArtifactMetadata.java:93) > at > org.apache.maven.artifact.transform.AbstractVersionTransformation.retrieveFromRemoteRepository(AbstractVersionTransformation.java:171) > at > org.apache.maven.artifact.transform.AbstractVersionTransformation.resolveVersion(AbstractVersionTransformation.java:96) > at > org.apache.maven.artifact.transform.SnapshotTransformation.transformForResolve(SnapshotTransformation.java:43) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:95) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:63) > at > org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:290) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:274) > at > org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:81) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:186) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:70) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:197) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:185) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:156) > at > org.apache.maven.plugin.DefaultPluginManager.ensurePluginContainerIsComplete(DefaultPluginManager.java:544) > at > org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:479) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:334) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:378) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:351) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:337) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:229) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:123) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:209) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:267) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.re
[jira] Commented: (MNG-740) dependencies resolution not work using pom on local source tree - special case
[ http://jira.codehaus.org/browse/MNG-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204355#action_204355 ] Jason van Zyl commented on MNG-740: --- Test against the 3.0 alphas and reopen if still a problem. > dependencies resolution not work using pom on local source tree - special case > -- > > Key: MNG-740 > URL: http://jira.codehaus.org/browse/MNG-740 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0-beta-1 > Environment: xp >Reporter: Dan Tran > Attachments: c.log, jira.zip, mng-740-test-case.zip > > > Folks, I would like to make sure i am able to build my artitfact with it > parent poms are not either in local or remote repo. > Attached is the dummy m2 structure to repoduce the problem. > Here are detail > somedir > root > pom.xml > subprojects > pom.xml > A > pom.xml > BC-parent > B >pom.xml<--- depend on A > C >pom.xml <--- depends on B > Here are the step the reproduce > 1. Install root's pom ( m2 install ) > 2. Install A ( m2 install in subproejcts/A > 3. install B ( m2 install in subprojects/BC-parent/B > 4. install C ( m2 install in subprojects/BC-parent/C) >C fails here. See attach logs > however if I do a full install from subprojects or manually install > subproejcts pom and BC-parent pom ( via m2 install -N) the problem goes away -- 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-740) dependencies resolution not work using pom on local source tree - special case
[ http://jira.codehaus.org/browse/MNG-740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-740. - Resolution: Cannot Reproduce Fix Version/s: (was: 3.x) > dependencies resolution not work using pom on local source tree - special case > -- > > Key: MNG-740 > URL: http://jira.codehaus.org/browse/MNG-740 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0-beta-1 > Environment: xp >Reporter: Dan Tran > Attachments: c.log, jira.zip, mng-740-test-case.zip > > > Folks, I would like to make sure i am able to build my artitfact with it > parent poms are not either in local or remote repo. > Attached is the dummy m2 structure to repoduce the problem. > Here are detail > somedir > root > pom.xml > subprojects > pom.xml > A > pom.xml > BC-parent > B >pom.xml<--- depend on A > C >pom.xml <--- depends on B > Here are the step the reproduce > 1. Install root's pom ( m2 install ) > 2. Install A ( m2 install in subproejcts/A > 3. install B ( m2 install in subprojects/BC-parent/B > 4. install C ( m2 install in subprojects/BC-parent/C) >C fails here. See attach logs > however if I do a full install from subprojects or manually install > subproejcts pom and BC-parent pom ( via m2 install -N) the problem goes away -- 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-763) [language support] consider include source root
[ http://jira.codehaus.org/browse/MNG-763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-763. - Resolution: Won't Fix Fix Version/s: (was: 3.x) > [language support] consider include source root > --- > > Key: MNG-763 > URL: http://jira.codehaus.org/browse/MNG-763 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: POM >Reporter: Brett Porter >Priority: Minor > > this is something used by the native plugin but could be used by several > plugins that deal with C/C++ and maybe other languages. We should consider > adding it to the build section and the MavenProject object. -- 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-841) Support customization of default excludes
[ http://jira.codehaus.org/browse/MNG-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-841: -- Fix Version/s: (was: 3.x) 3.1.alpha1 > Support customization of default excludes > - > > Key: MNG-841 > URL: http://jira.codehaus.org/browse/MNG-841 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: POM >Affects Versions: 2.0-alpha-3 > Environment: WinXP SP2, Java 1.5, Maven 2.0-alpha-3 >Reporter: John Fallows > Fix For: 3.1.alpha1 > > > Our company uses a home-grown version control system that has it's own > per-directory admin subdirectory, similar in purpose to the administration > subdirectories used by other version control systems, eg. CVS, .svn, etc. > These directories are excluded from processing by default in Maven2, and we > would like to add our custom admin subdirectory to the default exclusion list. > Recommended solution from Maven Users Mailing List: > Brett Porter wrote: > # What you really need is to be able to configure it in a root POM shared by > all projects, I think. > Hopefully, any such entry in pom.xml would not completely replace the default > excludes list, but merely entend the built-in definition. -- 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-4354) DefaultArtifactResolver has problems when used with multiple repos
[ http://jira.codehaus.org/browse/MNG-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-4354: -- Fix Version/s: 2.2.2 > DefaultArtifactResolver has problems when used with multiple repos > -- > > Key: MNG-4354 > URL: http://jira.codehaus.org/browse/MNG-4354 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.2.1 > Environment: N/A >Reporter: Hasan Ceylan >Priority: Blocker > Fix For: 2.2.2 > > Attachments: maven.patch > > > DefaultArtifactResolver attaches the repositories to artifacts (AFAIK) to > optimize the repo look ups. > Here I have a case > 1) An artifact dependens on org.eclipse.equniox:app:1.2.0 > 2) org.eclipse.equinox:app depends on > org.eclipse.equinox:registry:[3.4.0,4.0.0) > 3) Both central repo and custom corporate repo has > org.eclipse.equinox:registry > 4) central repo has outdated versions > 3.2.1-R32x_v20060814 > 3.3.0-v20070522 > 5) DefaultArtifactResolver for optimization attaches central repo (last one > wins) > 6) Central repo neither satisfies the version range nor - even if it did - > has the latest version > 7) dependency is not satisfied > 8) Build halts > Attached patch is a dirty hack to disable signle repo downloand and checks > all the repositories. -- 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-935) Gentoo style pom dependencies
[ http://jira.codehaus.org/browse/MNG-935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-935. - Resolution: Won't Fix Fix Version/s: (was: 3.x) > Gentoo style pom dependencies > - > > Key: MNG-935 > URL: http://jira.codehaus.org/browse/MNG-935 > Project: Maven 2 & 3 > Issue Type: Wish > Components: Dependencies > Environment: None appropriate >Reporter: Brian C. Dilley > > I'm a long time Gentoo Linux (http://www.gentoo.org/) user, and i think that > Maven could adpot some idea's from gentoo's portage > (http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1). > Gentoo has a concept of "ebuilds" (which can be compared to poms). An ebuild > is an install script of sorts for installing a particular piece of software. > An ebuild defines, among other things, what it's dependencies (other ebuilds) > are. There are two types of dependencies: optional and required. A required > depency is something that the software needs to be built or run, while an > optional depency is the exact opposite... it is optional at compile and run > time. Basically an optional depency is a feature that the piece of sotware > supports that isn't necessary for it to function. > There is also something in gentoo called "USE flags". Use flags are a system > scope set of parameters that determine how ebuilds are built... and which > features are included or excluded. For instance, "alsa" is a USE flag. If > your use flags have "alsa" in them then any application that supports Alsa > (Advanced Linux Sound Architecture) as an optional dependency will be > compiled with support for alsa. Likewise, if your USE flags contain "-alsa" > then anything that has optional support for alsa will not be compiled with > support for alsa. I should also mention that if a particular ebuild requires > alsa... alsa will be built as well as it (because it requires alsa at > compile/run time)... but it and anything else that requires it will be the > only piece of software on the machine that has alsa support. I should also > note that Gentoo has what is called "profiles". Profiles contain (among > other things) a default set of USE flags for the general user, so in theory a > Gentoo user doesn't have to modify their USE flags whatsoever. > My thinking is that Maven could adopt this. Poms could specify required and > optional dependencies, and at a project level USE flags could be defined to > filter what gets included in a project. For instance someone using the Spring > Framework may not be using Hibernate... in their use flags "-hibernate" could > be defined so that maven knows not to grab hibernate (and all of it's > dependencies) just because they want to use the spring MVC framework. -- 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-647) Allow Maven 2 to be monitored using JMX.
[ http://jira.codehaus.org/browse/MNG-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-647. - Resolution: Won't Fix Fix Version/s: (was: 3.x) > Allow Maven 2 to be monitored using JMX. > > > Key: MNG-647 > URL: http://jira.codehaus.org/browse/MNG-647 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Design, Patterns & Best Practices >Reporter: Rahul Thakur >Priority: Trivial > > Having JMX hooks in M2 to allow monitoring (and possibly runtime > configuration) by JMX clients would be nice. This would be a neat feature > especially where M2 is being used in embedded mode. -- 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: (MNG-647) Allow Maven 2 to be monitored using JMX.
[ http://jira.codehaus.org/browse/MNG-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204354#action_204354 ] Jason van Zyl commented on MNG-647: --- Out of scope for Maven. > Allow Maven 2 to be monitored using JMX. > > > Key: MNG-647 > URL: http://jira.codehaus.org/browse/MNG-647 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Design, Patterns & Best Practices >Reporter: Rahul Thakur >Priority: Trivial > > Having JMX hooks in M2 to allow monitoring (and possibly runtime > configuration) by JMX clients would be nice. This would be a neat feature > especially where M2 is being used in embedded mode. -- 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: (MNG-935) Gentoo style pom dependencies
[ http://jira.codehaus.org/browse/MNG-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204353#action_204353 ] Jason van Zyl commented on MNG-935: --- Absolutely no way. We're going down the OSGi road. > Gentoo style pom dependencies > - > > Key: MNG-935 > URL: http://jira.codehaus.org/browse/MNG-935 > Project: Maven 2 & 3 > Issue Type: Wish > Components: Dependencies > Environment: None appropriate >Reporter: Brian C. Dilley > > I'm a long time Gentoo Linux (http://www.gentoo.org/) user, and i think that > Maven could adpot some idea's from gentoo's portage > (http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1). > Gentoo has a concept of "ebuilds" (which can be compared to poms). An ebuild > is an install script of sorts for installing a particular piece of software. > An ebuild defines, among other things, what it's dependencies (other ebuilds) > are. There are two types of dependencies: optional and required. A required > depency is something that the software needs to be built or run, while an > optional depency is the exact opposite... it is optional at compile and run > time. Basically an optional depency is a feature that the piece of sotware > supports that isn't necessary for it to function. > There is also something in gentoo called "USE flags". Use flags are a system > scope set of parameters that determine how ebuilds are built... and which > features are included or excluded. For instance, "alsa" is a USE flag. If > your use flags have "alsa" in them then any application that supports Alsa > (Advanced Linux Sound Architecture) as an optional dependency will be > compiled with support for alsa. Likewise, if your USE flags contain "-alsa" > then anything that has optional support for alsa will not be compiled with > support for alsa. I should also mention that if a particular ebuild requires > alsa... alsa will be built as well as it (because it requires alsa at > compile/run time)... but it and anything else that requires it will be the > only piece of software on the machine that has alsa support. I should also > note that Gentoo has what is called "profiles". Profiles contain (among > other things) a default set of USE flags for the general user, so in theory a > Gentoo user doesn't have to modify their USE flags whatsoever. > My thinking is that Maven could adopt this. Poms could specify required and > optional dependencies, and at a project level USE flags could be defined to > filter what gets included in a project. For instance someone using the Spring > Framework may not be using Hibernate... in their use flags "-hibernate" could > be defined so that maven knows not to grab hibernate (and all of it's > dependencies) just because they want to use the spring MVC framework. -- 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-1326) Using CVS/CVN/etc. as source-code repository for Maven + having list of known projects.
[ http://jira.codehaus.org/browse/MNG-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1326: -- Fix Version/s: (was: 3.x) > Using CVS/CVN/etc. as source-code repository for Maven + having list of known > projects. > --- > > Key: MNG-1326 > URL: http://jira.codehaus.org/browse/MNG-1326 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Command Line, Reactor and workspace >Reporter: Miks Rozenbergs > > INTRODUCTION > This feature is about Maven being able to automatically download source for > dependent projects and compile them. > The desired procedure would be to: > 1. manually check out the project you wish to build > 2. run maven on it > Maven itself would then: > 1. read through dependencies, > 2. checkout each of the dependencies from Source Control system > 3. for each checked out project, do step #1. > This would for example solve the issue of re-build everything from an > arbitrary node on dependency graph e.g. creating a hotfix for some big > application. > IMPLEMENTATION > It would require to have a list of all known groupId/artifactId/version with > they corresponding location. Maven would know the location of this list (it > can be provided in settings.xml) and for each dependency it would check this > list to see where to get the it's source. -- 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-1649) Allow plugins to depend upon other plugin's goals
[ http://jira.codehaus.org/browse/MNG-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1649: -- Fix Version/s: (was: 3.x) > Allow plugins to depend upon other plugin's goals > - > > Key: MNG-1649 > URL: http://jira.codehaus.org/browse/MNG-1649 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugin API, Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: Mark Hobson > > Need to resolve the use-case discussed on dev: > http://www.nabble.com/Re%3A-m2-Plugins-that-depend-on-other-plugin-goals-t473646.html -- 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-248) allow the creation of goal aliases in the POM and in user settings
[ http://jira.codehaus.org/browse/MNG-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-248. - Resolution: Won't Fix Fix Version/s: (was: 3.x) > allow the creation of goal aliases in the POM and in user settings > -- > > Key: MNG-248 > URL: http://jira.codehaus.org/browse/MNG-248 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Plugins and Lifecycle, POM >Reporter: Brett Porter >Priority: Trivial > > I think a popular feature, esp. without maven.xml, would be the addition of > goal aliasing. > eg: > > my-favourite-goal > > clean:clean > install > > -- 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-2455) goals should be able to run without using pom.xml even if its available
[ http://jira.codehaus.org/browse/MNG-2455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2455: --- Fix Version/s: (was: 3.x) 3.0-alpha-7 > goals should be able to run without using pom.xml even if its available > --- > > Key: MNG-2455 > URL: http://jira.codehaus.org/browse/MNG-2455 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Plugin API > Environment: software platform >Reporter: Jagan >Priority: Blocker > Fix For: 3.0-alpha-7 > > > Maven goals should be able to run ignoring a pom.xml even if its present. > In my custom made plugin, I want to ignore the pom file. > Tried to use @requiresProject false, this ran fine if there is no pom, but if > a pom file is available it uses it. > Can someone please add a feature to ignore the pom even if its there. > maybe like @ignoreProject or something like that. This change looks pretty > simple and this issue is blocking our development. > Thanks > -Jagan -- 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-2340) Incorrect dependency version downloaded
[
http://jira.codehaus.org/browse/MNG-2340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-2340.
--
Resolution: Cannot Reproduce
Fix Version/s: (was: 3.x)
> Incorrect dependency version downloaded
> ---
>
> Key: MNG-2340
> URL: http://jira.codehaus.org/browse/MNG-2340
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Embedding
>Affects Versions: 2.0.4
>Reporter: Adrian
>Priority: Critical
> Attachments: MNGECLIPSE-131.zip
>
>
> I have a parent pom with a dependency management section specifying the
> version of an artifact to use. In the child project, I override this version.
> The maven plugin ignores the overriding version and downloads the version
> specified by the parent pom.
> For example, in the parent pom
> {code}
>
> lucene
> lucene
> 1.4.3
>
> {code}
> in the project pom, inheriting the parent pom
> {code}
>
> lucene
> lucene
> 2.0
>
> {code}
> The maven eclipse plugin downloads version 1.4.3 for my project
--
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-2381) improved control over the repositories in the POM
[ http://jira.codehaus.org/browse/MNG-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2381: --- Fix Version/s: (was: 3.x) 3.1.alpha1 > improved control over the repositories in the POM > - > > Key: MNG-2381 > URL: http://jira.codehaus.org/browse/MNG-2381 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories, Design, Patterns & Best > Practices >Reporter: Brett Porter > Fix For: 3.1.alpha1 > > > some discussion: > http://mail-archives.apache.org/mod_mbox/maven-users/200510.mbox/%3c9e3862d80509301841w70bb5883hf352ac3c3bb7e...@mail.gmail.com%3e > some questions raised by Chris Berry in relation to this: > Let's take, for example, repos defined in settings.xml, in a parent POM, a > grandparent POM, and in the local POM . So for this case, what is > The precedence level (if any) ?? > The search order of hierarchies?? > Are they additive?? > Can they be masked?? > How can one disable SNAPSHOTs completely ?? > There are times, mostly when cutting a Release, when you want to be very sure > that you are not using any SNAPSHOTs. How does one accomplish this?? > So can one then mask all repos except those seen in settings.xml?? > These need to be defined and documented as at present, however I believe this > yields the need for more control, particularly with relation to the latter > requests. Snapshot repositories should not be used in a release build, which > it would be good to define as building something that is not a snapshot > rather than tying it to the performRelease flag and the release plugin (or > imply the perform release plugin under these conditions regardless of the > plugin being used). > It would be good to better mirror the repositories, and perhaps use the same > pattern to control this from the user end (so settings.xml might always use a > mirror for a given repository, block another one, and do these things under a > profile in some circumstances). > I also have the overall goal of reducing traffic, so perhaps we need to group > dependencies under a particular repository too. I think this is filed > separately. -- 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-2315) Add option to exclude all transitive dependencies for a particular one
[ http://jira.codehaus.org/browse/MNG-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2315: --- Fix Version/s: (was: 3.x) 3.1.alpha1 > Add option to exclude all transitive dependencies for a particular one > -- > > Key: MNG-2315 > URL: http://jira.codehaus.org/browse/MNG-2315 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Dependencies >Affects Versions: 2.0.4 >Reporter: Carlos Sanchez >Priority: Critical > Fix For: 3.1.alpha1 > > > Something like > > ... > true > -- 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: (MANTTASKS-172) extend scope of 'result' variable in org.apache.maven.artifact.ant.DependenciesTask.doExecute()
[ http://jira.codehaus.org/browse/MANTTASKS-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl moved MNG-2283 to MANTTASKS-172: -- Complexity: (was: Intermediate) Component/s: (was: Artifacts and Repositories) Fix Version/s: (was: 3.x) Affects Version/s: (was: 2.0.4) Key: MANTTASKS-172 (was: MNG-2283) Project: Maven 2.x Ant Tasks (was: Maven 2 & 3) > extend scope of 'result' variable in > org.apache.maven.artifact.ant.DependenciesTask.doExecute() > > > Key: MANTTASKS-172 > URL: http://jira.codehaus.org/browse/MANTTASKS-172 > Project: Maven 2.x Ant Tasks > Issue Type: Wish >Reporter: diego tognola >Priority: Trivial > > Change the variable 'result' defined locally in the doExecute() method of > org.apache.maven.artifact.ant.DependenciesTask to be a class member, instead. > It should be accessible to subclasses (directly or via a getter method). > This will allow the creation of customized ant tasks extending > DependenciesTask which can use 'results' for post-processing. -- 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-2276) profile activation by property doesn't work with properties defined in settings.
[ http://jira.codehaus.org/browse/MNG-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2276: --- Fix Version/s: (was: 3.x) 3.0-alpha-7 > profile activation by property doesn't work with properties defined in > settings. > > > Key: MNG-2276 > URL: http://jira.codehaus.org/browse/MNG-2276 > Project: Maven 2 & 3 > Issue Type: Bug > Components: POM, Profiles >Affects Versions: 2.0.4 >Reporter: Brian Fox > Fix For: 3.0-alpha-7 > > Attachments: mng-2276.zip > > > Activating a profile like below doesn't get activated unless the property is > set on the CLI. I need to have the property defined in the settings.xml so > it's always set. > > > prod > > > deploy-ct > > > Further, I noticed that if I set it so that the activation is like: > > > deploy-cttrue > > > The profile is triggered just by setting the cli like "mvn -Ddeploy-ct" It > is not active if I use "-Ddeploy-ct=false" but the settings descriptor says > that the existence of the property is only used if value is not set. -- 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: (MNG-2259) Maven should check the contents of the POMs and jars that it downloads
[ http://jira.codehaus.org/browse/MNG-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204352#action_204352 ] Jason van Zyl commented on MNG-2259: Use strict checksum validation. One day when all the checksums are valid. > Maven should check the contents of the POMs and jars that it downloads > -- > > Key: MNG-2259 > URL: http://jira.codehaus.org/browse/MNG-2259 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: Alan Cabrera > > Sometimes they are corrupt. -- 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-2275) profiles should be merged when inherited
[
http://jira.codehaus.org/browse/MNG-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-2275:
---
Fix Version/s: (was: 3.x)
3.0-alpha-7
> profiles should be merged when inherited
>
>
> Key: MNG-2275
> URL: http://jira.codehaus.org/browse/MNG-2275
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.4
>Reporter: Brian Fox
> Fix For: 3.0-alpha-7
>
>
> I have some default profiles setup in a super parent pom that all projects
> inherit from. In some projects I want to change the active profile, but not
> from the CLI because other projects running in the same multi-project build
> need to have the normal default. I attempted to work around this by setting
> the profile to be active on a property in the child pom. See below for parent
> and child. It appears that when I do this, the child profile replaces the
> parent. It should be merged so that the properties are pulled from the parent
> and uses the activation from the child.
> parent:
>
>
>
> dev
>
>
> src/main/filters/dev-default.values
>
>
>
> auto-test
>
>
> src/main/filters/auto-test-default.values
>
>
>
> man-test
>
>
> src/main/filters/man-test-default.values
>
>
>
> prod
>
>
> src/main/filters/prod-default.values
>
>
>
>
>
> child pom..
>
>
>
>
> ${user.default.values}
>
>
>
> ${profile-default.values}
> ${user.default.values}
> ${client-ct-package.values}
>
>
>
> src/main/resources
> true
>
>
>
>
>
>
> prod
>
>
> deploy-ct
>
>
--
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-2259) Maven should check the contents of the POMs and jars that it downloads
[ http://jira.codehaus.org/browse/MNG-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2259. -- Resolution: Won't Fix Fix Version/s: (was: 3.x) > Maven should check the contents of the POMs and jars that it downloads > -- > > Key: MNG-2259 > URL: http://jira.codehaus.org/browse/MNG-2259 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: Alan Cabrera > > Sometimes they are corrupt. -- 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: (MNG-2248) Maven should get the source and javadoc jars from a repository if they are available
[ http://jira.codehaus.org/browse/MNG-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204351#action_204351 ] Jason van Zyl commented on MNG-2248: All the IDE integrations support this now. It's done on demand to be efficient. Downloading them if they are available greatly slows things down. > Maven should get the source and javadoc jars from a repository if they are > available > > > Key: MNG-2248 > URL: http://jira.codehaus.org/browse/MNG-2248 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Artifacts and Repositories >Reporter: Aaron Freeman >Priority: Minor > > It would be nice if the component that downloads a binary jar file from a > repositroy would also download any available source or javadoc jars. > Currently the only way to do this is by using the eclipse 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: (MNG-2248) Maven should get the source and javadoc jars from a repository if they are available
[ http://jira.codehaus.org/browse/MNG-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2248. -- Resolution: Won't Fix Fix Version/s: (was: 3.x) > Maven should get the source and javadoc jars from a repository if they are > available > > > Key: MNG-2248 > URL: http://jira.codehaus.org/browse/MNG-2248 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Artifacts and Repositories >Reporter: Aaron Freeman >Priority: Minor > > It would be nice if the component that downloads a binary jar file from a > repositroy would also download any available source or javadoc jars. > Currently the only way to do this is by using the eclipse 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] Updated: (MNG-2241) Versions are required when it shouldn't with multi-modules projects and war dependencies
[
http://jira.codehaus.org/browse/MNG-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-2241:
---
Fix Version/s: (was: 3.x)
3.0-alpha-7
> Versions are required when it shouldn't with multi-modules projects and war
> dependencies
>
>
> Key: MNG-2241
> URL: http://jira.codehaus.org/browse/MNG-2241
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.4
> Environment: Maven 2.0.4, Java 5, Windows XP
>Reporter: Celso Gomes Barreto Junior
> Fix For: 3.0-alpha-7
>
>
> In a multi-project with a parent pom which should enforces modules's versions
> in dependencyManagement element, when I use a war dependnecy it starts to
> require the version declaration in child pom's dependencies. When I use jar
> dependencies, it works fine.
> Project structure:
> parent project
> |_ web (war)
> |_ commons (jar)
> |_ webcommons (war)
> --
> parent project pom:
>
>
> 4.0.0
> Procdev - Referência
> globo
> procdevref
> pom
> 0.0.1
> no
>
> web
> commons
> webcommons
>
>
>
>
> globo
> procdevref-web
> ${project.version}
>
>
> globo
> procdevref-commons
> ${project.version}
>
>
> globo
> procdevref-webcommons
> ${project.version}
>
>
>
>
>
> junit
> junit
> 3.8.1
> test
>
>
>
> --
> web project pom:
>
>
> 4.0.0
>
> globo
> procdevref
> 0.0.1
>
> Procdev Web
> procdevref-web
> war
> 0.0.1
> no
>
>
> globo
> procdevref-webcommons
> war
>
>
> globo
> procdevref-commons
>
>
> jstl
> jstl
> [1.1.2,]
>
>
> taglibs
> standard
> [1.1.2,]
>
>
>
> --
> webcommons project pom:
>
>
> 4.0.0
>
> globo
> procdevref
> 0.0.1
>
> Procdev Web Commons
> procdevref-webcommons
> war
> 0.0.1
> no
>
> --
> commons project pom:
>
>
> 4.0.0
>
> globo
> procdevref
> 0.0.1
>
> Procdev Commons
> procdevref-commons
> jar
> 0.0.1
> no
>
> When i Run it with "mvn -X clean install" I get:
> + Error stacktraces are turned on.
> Maven version: 2.0.4
> [DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and
> Settin
> gs\celso.cs\.m2\plugin-registry.xml'
> [DEBUG] Building Maven global-level plugin registry from:
> 'C:\java\maven-2.0.4\b
> in\..\conf\plugin-registry.xml'
> [INFO] Scanning for projects...
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] Error building POM (may not be this project's POM).
> Project ID: globo:procdevref-web
> POM Location: C:\Projetos\ProcdevReferencia\web\pom.xml
> Validation Messages:
> [0] 'dependencies.dependency.version' is missing for
> globo:procdevref-webco
> mmons
> Reason: Failed to validate POM
--
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-2194) no downloading attempts of non-existing artifact
[ http://jira.codehaus.org/browse/MNG-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2194: --- Fix Version/s: (was: 3.x) 3.0-alpha-7 We keep track of misses now, but we'll validate and close this out in 3.0-alpha-7. > no downloading attempts of non-existing artifact > > > Key: MNG-2194 > URL: http://jira.codehaus.org/browse/MNG-2194 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.0.2 > Environment: not dependent on environment >Reporter: John Franey >Priority: Minor > Fix For: 3.0-alpha-7 > > > I'm converting a project to maven 2. Some dependencies do not exist in > ibiblio, so I've 'installed' these into my local repository. > I'm unhappy because every time I perform a run, there is a significant > delay (sometimes) when maven tries to download these non-existent > artifacts. I get these messages: > Downloading: http://repo1.maven.org/maven2/.../...pom > How can I prevent maven's attempt to download these non-existent > artifacts? I'm most interested in eliminating the delay. > I know I can run with the 'offline' option. This is OK as long as I'm > sure all existing artifacts that are already downloaded into my cache. > So I can do this until I build on a system with no local cache of add a > new dependency to my projects, at which time the delay is experienced > due to these non-existent artifacts. -- 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-2216) Add default encodings section to POM
[
http://jira.codehaus.org/browse/MNG-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-2216:
---
Fix Version/s: (was: 3.x)
3.1.alpha1
> Add default encodings section to POM
>
>
> Key: MNG-2216
> URL: http://jira.codehaus.org/browse/MNG-2216
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: POM::Encoding
>Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3
>Reporter: Trustin Lee
> Fix For: 3.1.alpha1
>
> Attachments: example-pom.xml
>
>
> Look at the attached example POM.
> Do you see many duplicate configuration properties ('UTF-8') in it? and the
> names of properties are very inconsistent.
> It would be great if:
> 1) Add a global section which specifies default encodings:
>
>
> UTF-8
>
> UTF-8
>
> 2) Make encoding properties in all plugins to be consistent and deprecate old
> properties. The default values could be:
> inputEncoding = ${pom.encoding.input}
> outputEncoding = ${pom.encoding.output}
> so users can override the default settings easily.
--
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: (MNG-2111) Support for a bundled scope
[ http://jira.codehaus.org/browse/MNG-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204349#action_204349 ] Jason van Zyl commented on MNG-2111: You can do this with the shade plugin which can also modify the POM to reflect the bundling of other dependencies. > Support for a bundled scope > --- > > Key: MNG-2111 > URL: http://jira.codehaus.org/browse/MNG-2111 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.0.2 >Reporter: Charles Paclat > > The current alternatives for "scope" do not support the case where a > component is dependent during compile and assembly on a partcular set of > dependent components, and then bundles those components as part of its > distribution jar. > In such a case a third dependent component would like to declare that it is > dependent on that component and be told that it need only download and > include that one component in its classpath. The current "runtime" scope is > purely additive, in that it allows one to define that an additional jar is > required at runtime that was not needed at compile time. The proposed new > scope would state that the jar is required at compile and assemble time but > not at runtime by using components. -- 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-2111) Support for a bundled scope
[ http://jira.codehaus.org/browse/MNG-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2111. -- Resolution: Won't Fix Fix Version/s: (was: 3.x) > Support for a bundled scope > --- > > Key: MNG-2111 > URL: http://jira.codehaus.org/browse/MNG-2111 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.0.2 >Reporter: Charles Paclat > > The current alternatives for "scope" do not support the case where a > component is dependent during compile and assembly on a partcular set of > dependent components, and then bundles those components as part of its > distribution jar. > In such a case a third dependent component would like to declare that it is > dependent on that component and be told that it need only download and > include that one component in its classpath. The current "runtime" scope is > purely additive, in that it allows one to define that an additional jar is > required at runtime that was not needed at compile time. The proposed new > scope would state that the jar is required at compile and assemble time but > not at runtime by using components. -- 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-2118) Listing central repo in pluginRepositories confuses Maven
[
http://jira.codehaus.org/browse/MNG-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-2118.
--
Resolution: Cannot Reproduce
Fix Version/s: (was: 3.x)
> Listing central repo in pluginRepositories confuses Maven
> -
>
> Key: MNG-2118
> URL: http://jira.codehaus.org/browse/MNG-2118
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugins and Lifecycle, POM
>Affects Versions: 2.0.2
>Reporter: Jason Dillon
>Priority: Critical
>
> It appears that if you list the central repository in the pluginRepositories,
> that it may cause Maven to incorrectly check the central repository for
> plugin data.
> Specifically, I found this when using the maven-clean-plugin 2.1. I did not
> have this plugin in my local repository, and when running {{mvn clean}} it
> causes the build to fail:
> {noformat}
> + Error stacktraces are turned on.
> [DEBUG] Building Maven user-level plugin registry from:
> '/Users/jason/.m2/plugin-registry.xml'
> [DEBUG] Building Maven global-level plugin registry from:
> '/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/conf/plugin-registry.xml'
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO] Paycore
> [INFO] Paycore :: Merchant
> [INFO] Paycore :: Merchant :: Core
> [INFO] Paycore :: Merchant :: Services
> [INFO]
>
> [INFO] Building Paycore
> [INFO]task-segment: [clean]
> [INFO]
>
> [DEBUG] maven-clean-plugin: resolved to version 2.1 from repository
> maven-snapshots
> [DEBUG] Trying repository maven-snapshots
> Downloading:
> http://snapshots.maven.codehaus.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.1/maven-clean-plugin-2.1.pom
> [DEBUG] Artifact not found - using stub model: Unable to locate resource in
> repository
> org.apache.maven.plugins:maven-clean-plugin:pom:2.1
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2),
> maven-snapshots (http://snapshots.maven.codehaus.org/maven2),
> paybytouch-legacy (http://repository.paybytouch.com/m1/repository)
> [DEBUG] Using defaults for missing POM
> org.apache.maven.plugins:maven-clean-plugin:pom:2.1
> [DEBUG] maven-surefire-plugin: resolved to version 2.1.3-SNAPSHOT from
> repository maven-snapshots
> [DEBUG] maven-surefire-plugin: resolved to version 2.1.3-20060228.012944-10
> from repository maven-snapshots
> [DEBUG] Retrieving parent-POM from the repository for project:
> null:maven-surefire-plugin:maven-plugin:2.1.3-20060228.012944-10
> [DEBUG] maven-one-plugin: resolved to version 1.0-20060213.011019-4 from
> repository maven-snapshots
> [DEBUG] maven-one-plugin: resolved to version 1.0-20060213.011019-4 from
> repository maven-snapshots
> [DEBUG] org.apache.maven.plugins:maven-clean-plugin:maven-plugin:2.1
> (selected for runtime)
> -
> this realm = app0.child-container[org.apache.maven.plugins:maven-clean-plugin]
> urls[0] =
> file:/Users/jason/.m2/repository/org/apache/maven/plugins/maven-clean-plugin/2.1/maven-clean-plugin-2.1.jar
> Number of imports: 0
> this realm = plexus.core.maven
> urls[0] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/commons-cli-1.0.jar
> urls[1] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/doxia-sink-api-1.0-alpha-7.jar
> urls[2] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/jsch-0.1.24.jar
> urls[3] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-artifact-2.0.2.jar
> urls[4] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-artifact-manager-2.0.2.jar
> urls[5] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-core-2.0.2-javadoc.jar
> urls[6] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-core-2.0.2.jar
> urls[7] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-error-diagnostics-2.0.2.jar
> urls[8] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-model-2.0.2.jar
> urls[9] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-monitor-2.0.2.jar
> urls[10] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-plugin-api-2.0.2.jar
> urls[11] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-plugin-descriptor-2.0.2.jar
> urls[12] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-plugin-parameter-documenter-2.0.2.jar
> urls[13] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-plugin-registry-2.0.2.jar
> u
[jira] Commented: (MNG-2110) ArtifactRepositoryLayout isn't extensible
[ http://jira.codehaus.org/browse/MNG-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204348#action_204348 ] Jason van Zyl commented on MNG-2110: The system is now full extensible. We use this support in M2Eclipse to override core components using plugins. > ArtifactRepositoryLayout isn't extensible > - > > Key: MNG-2110 > URL: http://jira.codehaus.org/browse/MNG-2110 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.2 >Reporter: Matthew Beermann > Fix For: 3.0-alpha-6 > > > I'm writing a plugin that (among other tasks) provides a new > ArtifactRepositoryLayout suitable for Eclipse repositories. In my > META-INF/plexus/components.xml, I have: > > > org.apache.maven.artifact.repository.layout.ArtifactRepositoryLayout > eclipse > > org.apache.maven.artifact.repository.layout.EclipseArtifactRepositoryLayout > > This plugin is listed in the POM with true. I would > expect that a with eclipse would discover and > load this layout provider. Instead, it simply results in an exception. Note > that this same components.xml file also defines some lifecycle mappings, > which work perfectly. > [INFO] Trace > org.apache.maven.reactor.MavenExecutionException: Cannot find layout > implementation corresponding to: 'eclipse' for remote repository with id: > 'Eclipse Update Site'. > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365) > ... > Caused by: > org.codehaus.plexus.component.repository.exception.ComponentLookupException: > Component descriptor cannot be found in the component repository: > org.apache.maven.artifact.repository.layout.ArtifactRepositoryLayouteclipse. > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:323) -- 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-2110) ArtifactRepositoryLayout isn't extensible
[ http://jira.codehaus.org/browse/MNG-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2110. -- Resolution: Fixed Fix Version/s: (was: 3.x) 3.0-alpha-6 > ArtifactRepositoryLayout isn't extensible > - > > Key: MNG-2110 > URL: http://jira.codehaus.org/browse/MNG-2110 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.2 >Reporter: Matthew Beermann > Fix For: 3.0-alpha-6 > > > I'm writing a plugin that (among other tasks) provides a new > ArtifactRepositoryLayout suitable for Eclipse repositories. In my > META-INF/plexus/components.xml, I have: > > > org.apache.maven.artifact.repository.layout.ArtifactRepositoryLayout > eclipse > > org.apache.maven.artifact.repository.layout.EclipseArtifactRepositoryLayout > > This plugin is listed in the POM with true. I would > expect that a with eclipse would discover and > load this layout provider. Instead, it simply results in an exception. Note > that this same components.xml file also defines some lifecycle mappings, > which work perfectly. > [INFO] Trace > org.apache.maven.reactor.MavenExecutionException: Cannot find layout > implementation corresponding to: 'eclipse' for remote repository with id: > 'Eclipse Update Site'. > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365) > ... > Caused by: > org.codehaus.plexus.component.repository.exception.ComponentLookupException: > Component descriptor cannot be found in the component repository: > org.apache.maven.artifact.repository.layout.ArtifactRepositoryLayouteclipse. > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:323) -- 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-2069) Output more information in error message
[ http://jira.codehaus.org/browse/MNG-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2069. -- Resolution: Cannot Reproduce > Output more information in error message > > > Key: MNG-2069 > URL: http://jira.codehaus.org/browse/MNG-2069 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Embedding > Environment: Linux / JDK 1.5 >Reporter: Jimisola Laursen >Priority: Minor > Fix For: 3.x > > > (issue redirected to Embedded component by Eugene Kuleshov, see > http://jira.codehaus.org/browse/MNGECLIPSE-73?page=all) > I keep getting the following error message over and over again: > 2/12/06 4:00:10 PM CET: Reading /LF/pom.xml > 2/12/06 4:00:17 PM CET: [WARN] Unable to get resource from repository central > (http://repo1.maven.org/maven2) > 2/12/06 4:00:17 PM CET: Unable to download the artifact from any repository > and I don't know what is causing it. It would really help out if the > error/warning message provided was more informative. > Hence, what resource is it trying to get? > Below is the the output with debug turned on: > 2/12/06 4:46:24 PM CET: [DEBUG] xml-apis:xml-apis:jar:1.0.b2 (selected for > compile) > 2/12/06 4:46:24 PM CET: [DEBUG] com.ibm.icu:icu4j:jar:2.6.1 (selected for > compile) > 2/12/06 4:46:24 PM CET: [DEBUG] xerces:xmlParserAPIs:jar:2.6.1 (removed - > nearer found: 2.6.2) > 2/12/06 4:46:24 PM CET: [DEBUG] xerces:xmlParserAPIs:jar:2.6.2 (selected for > compile) > 2/12/06 4:46:24 PM CET: [DEBUG] xerces:xercesImpl:jar:2.2.1 (removed - nearer > found: 2.6.2) > 2/12/06 4:46:24 PM CET: [DEBUG] xerces:xercesImpl:jar:2.6.2 (selected for > compile) > 2/12/06 4:46:24 PM CET: [DEBUG] junit:junit:jar:3.8.1 (selected for test) > 2/12/06 4:46:24 PM CET: [DEBUG] se.stickybit.lf:lf-test-license:jar:0.1 > (selected for system) > 2/12/06 4:46:24 PM CET: [DEBUG] xmlbeans:xbean:jar:2.1.0 (selected for > compile) > 2/12/06 4:46:24 PM CET: [DEBUG] xsdlib:xsdlib:jar:20030225 (selected for > compile) > 2/12/06 4:46:24 PM CET: [DEBUG] xmlbeans:xmlpublic:jar:2.1.0 (selected for > compile) > 2/12/06 4:46:24 PM CET: [DEBUG] dom4j:dom4j:jar:1.6.1 (selected for compile) > 2/12/06 4:46:24 PM CET: [DEBUG] stax:stax-api:jar:1.0 (selected for compile) > 2/12/06 4:46:24 PM CET: [DEBUG] pull-parser:pull-parser:jar:2 (selected for > compile) > 2/12/06 4:46:24 PM CET: [DEBUG] jaxme:jaxme-api:jar:0.3 (selected for compile) > 2/12/06 4:46:24 PM CET: [DEBUG] dom4j:dom4j:jar:1.5.2 (removed - causes a > cycle in the graph) > 2/12/06 4:46:24 PM CET: [DEBUG] jaxen:jaxen:jar:1.1-beta-6 (removed - nearer > found: 1.1-beta-8) > 2/12/06 4:46:24 PM CET: [DEBUG] While downloading xml-apis:xml-apis:2.0.2 > This artifact has been relocated to xml-apis:xml-apis:1.0.b2. > 2/12/06 4:46:24 PM CET: [DEBUG] xml-apis:xml-apis:jar:1.0.b2 (selected for > compile) > 2/12/06 4:46:24 PM CET: [DEBUG] msv:xsdlib:jar:20030807 (selected for compile) > 2/12/06 4:46:24 PM CET: [DEBUG] xpp3:xpp3:jar:1.1.3.3 (selected for compile) > 2/12/06 4:46:24 PM CET: [DEBUG] msv:relaxngDatatype:jar:20030807 (selected > for compile) > 2/12/06 4:46:24 PM CET: [DEBUG] log4j:log4j:jar:1.2.9 (selected for compile) > 2/12/06 4:46:24 PM CET: [DEBUG] xmlbeans:xbean_xpath:jar:2.1.0 (selected for > compile) > 2/12/06 4:46:24 PM CET: [DEBUG] msv:msv:jar:20050913 (selected for compile) > 2/12/06 4:46:24 PM CET: [DEBUG] Found 0 components to load on start > 2/12/06 4:46:24 PM CET: [DEBUG] Building Maven user-level plugin registry > from: '/home/jimisola/.m2/plugin-registry.xml' > 2/12/06 4:46:24 PM CET: [DEBUG] Trying repository central > 2/12/06 4:46:35 PM CET: [WARN] Unable to get resource from repository central > (http://repo1.maven.org/maven2) > 2/12/06 4:46:35 PM CET: Unable to download the artifact from any repository > 2/12/06 4:46:35 PM CET: [DEBUG] Found 0 components to load on start > 2/12/06 4:46:35 PM CET: [DEBUG] Building Maven user-level plugin registry > from: '/home/jimisola/.m2/plugin-registry.xml' > 2/12/06 4:46:35 PM CET: [DEBUG] Found 0 components to load on start > 2/12/06 4:46:35 PM CET: [DEBUG] Building Maven user-level plugin registry > from: '/home/jimisola/.m2/plugin-registry.xml' > 2/12/06 4:46:35 PM CET: [DEBUG] Trying repository central > 2/12/06 4:46:36 PM CET: [WARN] Unable to get resource from repository central > (http://repo1.maven.org/maven2) > 2/12/06 4:46:36 PM CET: Unable to download the artifact from any repository -- 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: (MNG-2069) Output more information in error message
[ http://jira.codehaus.org/browse/MNG-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204347#action_204347 ] Jason van Zyl commented on MNG-2069: Just too old now. > Output more information in error message > > > Key: MNG-2069 > URL: http://jira.codehaus.org/browse/MNG-2069 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Embedding > Environment: Linux / JDK 1.5 >Reporter: Jimisola Laursen >Priority: Minor > Fix For: 3.x > > > (issue redirected to Embedded component by Eugene Kuleshov, see > http://jira.codehaus.org/browse/MNGECLIPSE-73?page=all) > I keep getting the following error message over and over again: > 2/12/06 4:00:10 PM CET: Reading /LF/pom.xml > 2/12/06 4:00:17 PM CET: [WARN] Unable to get resource from repository central > (http://repo1.maven.org/maven2) > 2/12/06 4:00:17 PM CET: Unable to download the artifact from any repository > and I don't know what is causing it. It would really help out if the > error/warning message provided was more informative. > Hence, what resource is it trying to get? > Below is the the output with debug turned on: > 2/12/06 4:46:24 PM CET: [DEBUG] xml-apis:xml-apis:jar:1.0.b2 (selected for > compile) > 2/12/06 4:46:24 PM CET: [DEBUG] com.ibm.icu:icu4j:jar:2.6.1 (selected for > compile) > 2/12/06 4:46:24 PM CET: [DEBUG] xerces:xmlParserAPIs:jar:2.6.1 (removed - > nearer found: 2.6.2) > 2/12/06 4:46:24 PM CET: [DEBUG] xerces:xmlParserAPIs:jar:2.6.2 (selected for > compile) > 2/12/06 4:46:24 PM CET: [DEBUG] xerces:xercesImpl:jar:2.2.1 (removed - nearer > found: 2.6.2) > 2/12/06 4:46:24 PM CET: [DEBUG] xerces:xercesImpl:jar:2.6.2 (selected for > compile) > 2/12/06 4:46:24 PM CET: [DEBUG] junit:junit:jar:3.8.1 (selected for test) > 2/12/06 4:46:24 PM CET: [DEBUG] se.stickybit.lf:lf-test-license:jar:0.1 > (selected for system) > 2/12/06 4:46:24 PM CET: [DEBUG] xmlbeans:xbean:jar:2.1.0 (selected for > compile) > 2/12/06 4:46:24 PM CET: [DEBUG] xsdlib:xsdlib:jar:20030225 (selected for > compile) > 2/12/06 4:46:24 PM CET: [DEBUG] xmlbeans:xmlpublic:jar:2.1.0 (selected for > compile) > 2/12/06 4:46:24 PM CET: [DEBUG] dom4j:dom4j:jar:1.6.1 (selected for compile) > 2/12/06 4:46:24 PM CET: [DEBUG] stax:stax-api:jar:1.0 (selected for compile) > 2/12/06 4:46:24 PM CET: [DEBUG] pull-parser:pull-parser:jar:2 (selected for > compile) > 2/12/06 4:46:24 PM CET: [DEBUG] jaxme:jaxme-api:jar:0.3 (selected for compile) > 2/12/06 4:46:24 PM CET: [DEBUG] dom4j:dom4j:jar:1.5.2 (removed - causes a > cycle in the graph) > 2/12/06 4:46:24 PM CET: [DEBUG] jaxen:jaxen:jar:1.1-beta-6 (removed - nearer > found: 1.1-beta-8) > 2/12/06 4:46:24 PM CET: [DEBUG] While downloading xml-apis:xml-apis:2.0.2 > This artifact has been relocated to xml-apis:xml-apis:1.0.b2. > 2/12/06 4:46:24 PM CET: [DEBUG] xml-apis:xml-apis:jar:1.0.b2 (selected for > compile) > 2/12/06 4:46:24 PM CET: [DEBUG] msv:xsdlib:jar:20030807 (selected for compile) > 2/12/06 4:46:24 PM CET: [DEBUG] xpp3:xpp3:jar:1.1.3.3 (selected for compile) > 2/12/06 4:46:24 PM CET: [DEBUG] msv:relaxngDatatype:jar:20030807 (selected > for compile) > 2/12/06 4:46:24 PM CET: [DEBUG] log4j:log4j:jar:1.2.9 (selected for compile) > 2/12/06 4:46:24 PM CET: [DEBUG] xmlbeans:xbean_xpath:jar:2.1.0 (selected for > compile) > 2/12/06 4:46:24 PM CET: [DEBUG] msv:msv:jar:20050913 (selected for compile) > 2/12/06 4:46:24 PM CET: [DEBUG] Found 0 components to load on start > 2/12/06 4:46:24 PM CET: [DEBUG] Building Maven user-level plugin registry > from: '/home/jimisola/.m2/plugin-registry.xml' > 2/12/06 4:46:24 PM CET: [DEBUG] Trying repository central > 2/12/06 4:46:35 PM CET: [WARN] Unable to get resource from repository central > (http://repo1.maven.org/maven2) > 2/12/06 4:46:35 PM CET: Unable to download the artifact from any repository > 2/12/06 4:46:35 PM CET: [DEBUG] Found 0 components to load on start > 2/12/06 4:46:35 PM CET: [DEBUG] Building Maven user-level plugin registry > from: '/home/jimisola/.m2/plugin-registry.xml' > 2/12/06 4:46:35 PM CET: [DEBUG] Found 0 components to load on start > 2/12/06 4:46:35 PM CET: [DEBUG] Building Maven user-level plugin registry > from: '/home/jimisola/.m2/plugin-registry.xml' > 2/12/06 4:46:35 PM CET: [DEBUG] Trying repository central > 2/12/06 4:46:36 PM CET: [WARN] Unable to get resource from repository central > (http://repo1.maven.org/maven2) > 2/12/06 4:46:36 PM CET: Unable to download the artifact from any repository -- 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-2103) Inheritance of overrides that of
[ http://jira.codehaus.org/browse/MNG-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2103: --- Fix Version/s: (was: 3.x) 3.0-alpha-7 > Inheritance of overrides that of > - > > Key: MNG-2103 > URL: http://jira.codehaus.org/browse/MNG-2103 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Inheritance and Interpolation >Reporter: Prasad Kashyap > Fix For: 3.0-alpha-7 > > Attachments: test-inheritance-true.zip, test-inheritance.zip > > > The settings of overrides that of it's > By convention, all top level configuration settings are usually overridden by > the settings in the lower levels. -- 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-2046) External property file in command line
[ http://jira.codehaus.org/browse/MNG-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2046. -- Resolution: Won't Fix > External property file in command line > -- > > Key: MNG-2046 > URL: http://jira.codehaus.org/browse/MNG-2046 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Command Line >Affects Versions: 2.0.2 >Reporter: Raphaël Corre >Priority: Minor > Fix For: 3.x > > > It would be great to allow the option "-propertyfile" in the command line, > like Ant does to load multi properties. For the moment, it's possible to do > "'D", but for a single property. -- 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: (MNG-2046) External property file in command line
[ http://jira.codehaus.org/browse/MNG-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204345#action_204345 ] Jason van Zyl commented on MNG-2046: This would certainly get abused. > External property file in command line > -- > > Key: MNG-2046 > URL: http://jira.codehaus.org/browse/MNG-2046 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Command Line >Affects Versions: 2.0.2 >Reporter: Raphaël Corre >Priority: Minor > Fix For: 3.x > > > It would be great to allow the option "-propertyfile" in the command line, > like Ant does to load multi properties. For the moment, it's possible to do > "'D", but for a single property. -- 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-2036) The clean plugin requires dependent plugins defined in a project's pom.xml to be in the repository before it can perform a clean
[ http://jira.codehaus.org/browse/MNG-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2036: --- Fix Version/s: (was: 3.x) 3.0-alpha-7 This should be relatively easy to fix now in 3.x. > The clean plugin requires dependent plugins defined in a project's pom.xml to > be in the repository before it can perform a clean > > > Key: MNG-2036 > URL: http://jira.codehaus.org/browse/MNG-2036 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Plugins and Lifecycle > Environment: maven2 2.0.1 >Reporter: Chad Brandon > Fix For: 3.0-alpha-7 > > > It appears that any plugins that are in my pom.xml need to be downloaded > before clean can work, otherwise it fails with unsatisfied dependencies (for > example, I can't clean our distribution until the rest of the plugins of our > build are installed). -- 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-1977) Global dependency exclusions
[ http://jira.codehaus.org/browse/MNG-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-1977: --- Fix Version/s: (was: 3.x) 3.1.alpha1 > Global dependency exclusions > > > Key: MNG-1977 > URL: http://jira.codehaus.org/browse/MNG-1977 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: POM >Reporter: Kees de Kooter > Fix For: 3.1.alpha1 > > > I depend on some libraries, which in turn depend on something > (which in turn depend on something) that I don't want, because I declare > some other artifact in my pom.xml. > A concrete example: I don't want that the artifact "xerces" is imported in > my project because I declare to depend on "xercesImpl" which ships newer > libraries but with the same namespaces. > I guess I would need an "exclude transitive dependency at all", either > globally or from this and that artifact. I saw the tag, but it > forces me to be very verbose and have exact control on what is required by a > dependency. -- 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-1949) project-level plugin dependencies not handled correctly in multimodule builds
[ http://jira.codehaus.org/browse/MNG-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-1949: --- Fix Version/s: (was: 3.x) 3.0-alpha-7 > project-level plugin dependencies not handled correctly in multimodule builds > - > > Key: MNG-1949 > URL: http://jira.codehaus.org/browse/MNG-1949 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.1 >Reporter: John Casey > Fix For: 3.0-alpha-7 > > > plugin containers are only initialized once per build, which means they may > contain incorrect project-introduced dependencies for project Y in a > multimodule build (polluted by project X predecessor). We should look at ways > of dumping plugin containers with project-specific configurations, or else > providing a container overlay to handle project-specific dependencies, etc. > NOTE: This is tied into the notions of build extensions, which will have > similar consequences on the core container. -- 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: (MSITE-444) reporting section should allow additional dependencies in plugins as well
[ http://jira.codehaus.org/browse/MSITE-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl moved MNG-1948 to MSITE-444: -- Complexity: (was: Intermediate) Component/s: (was: Plugins and Lifecycle) (was: POM) Fix Version/s: (was: 3.x) 3.0-alpha-1 Key: MSITE-444 (was: MNG-1948) Project: Maven 2.x Site Plugin (was: Maven 2 & 3) > reporting section should allow additional dependencies in plugins as well > - > > Key: MSITE-444 > URL: http://jira.codehaus.org/browse/MSITE-444 > Project: Maven 2.x Site Plugin > Issue Type: Improvement >Reporter: Brett Porter >Assignee: John Casey > Fix For: 3.0-alpha-1 > > > currently, you can only do this in the build section -- 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: (MSITE-443) add a reportingManagement section
[
http://jira.codehaus.org/browse/MSITE-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl moved MNG-1931 to MSITE-443:
--
Complexity: (was: Intermediate)
Component/s: (was: Design, Patterns & Best Practices)
(was: POM)
Fix Version/s: (was: 3.x)
3.0-alpha-1
Key: MSITE-443 (was: MNG-1931)
Project: Maven 2.x Site Plugin (was: Maven 2 & 3)
> add a reportingManagement section
> -
>
> Key: MSITE-443
> URL: http://jira.codehaus.org/browse/MSITE-443
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Environment: maven-site-plugin 2.0-beta-3-SNAPSHOT
>Reporter: Indrajit Raychaudhuri
> Fix For: 3.0-alpha-1
>
>
> Consider the following POM:
> {code:xml}
>
>
>
>
>
> org.apache.maven.plugins
> maven-javadoc-plugin
>
> false
>
>
>
>
>
>
>
>
>
> org.apache.maven.plugins
> maven-javadoc-plugin
>
>
>
>
> {code}
> {{mvn site:site}} doesn't honor the javadoc configuration specified in the
> {{}} section.
> However, {{mvn javadoc:javadoc}} honors them.
> This is true not just for javadoc but other plugins like checkstyle as well.
> I guess, the {{}} section doesn't use the {{}}
> section at all.
--
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-443) add a reportingManagement section
[
http://jira.codehaus.org/browse/MSITE-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204343#action_204343
]
Jason van Zyl commented on MSITE-443:
-
Now the site plugin's use case.
> add a reportingManagement section
> -
>
> Key: MSITE-443
> URL: http://jira.codehaus.org/browse/MSITE-443
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Environment: maven-site-plugin 2.0-beta-3-SNAPSHOT
>Reporter: Indrajit Raychaudhuri
> Fix For: 3.0-alpha-1
>
>
> Consider the following POM:
> {code:xml}
>
>
>
>
>
> org.apache.maven.plugins
> maven-javadoc-plugin
>
> false
>
>
>
>
>
>
>
>
>
> org.apache.maven.plugins
> maven-javadoc-plugin
>
>
>
>
> {code}
> {{mvn site:site}} doesn't honor the javadoc configuration specified in the
> {{}} section.
> However, {{mvn javadoc:javadoc}} honors them.
> This is true not just for javadoc but other plugins like checkstyle as well.
> I guess, the {{}} section doesn't use the {{}}
> section at all.
--
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-1803) Provide line number information when there are errors processing a pom.xml
[
http://jira.codehaus.org/browse/MNG-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-1803:
---
Fix Version/s: (was: 3.x)
3.0-alpha-7
This is a lot better in 3.0, but we could still provide more assistance:
currently it looks like this:
bash-3.2$ mvn validate
[INFO] Scanning for projects...
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR] The project org.apache.maven:maven-core:3.0-SNAPSHOT
(/Users/jvanzyl/js/org/apache/maven/maven-3/trunk/maven-core/pom.xml) has 1
error
[ERROR] 'dependencies.dependency.version' must be a valid version for
commons-jxpath:commons-jxpath:jar but is '${jxpathVersion}'.
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
But we could add the line/column as well.
> Provide line number information when there are errors processing a pom.xml
> --
>
> Key: MNG-1803
> URL: http://jira.codehaus.org/browse/MNG-1803
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Logging, POM
>Affects Versions: 2.0
> Environment: Maven 2.0, Windows xp, jdk 1.5, cygwin
>Reporter: Howard M. Lewis Ship
> Fix For: 3.0-alpha-7
>
>
> When there is an error in a pom.xml, Maven 2 does a reasonable job
> identifying the error, but it doesn't provide the location of the error. For
> example, I forget to include a inside one of my dependencies:
> bash-3.00$ mvn
> [INFO] Scanning for projects...
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] Error building POM (may not be this project's POM).
> Project ID: hivemind:hivemind
> POM Location: c:\workspace\jakarta-hivemind\library\pom.xml
> Validation Messages:
> [0] 'dependencies.dependency.version' is missing.
> Reason: Failed to validate POM
> [INFO]
>
> [INFO] Trace
> org.apache.maven.reactor.MavenExecutionException: Failed to validate POM
> at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:359)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:276)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.project.InvalidProjectModelException: Failed to
> validate POM
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:774)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:624)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFile(DefaultMavenProjectBuilder.java:298)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:276)
> at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:509)
> at
> org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:441)
> at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:345)
> ... 11 more
> [INFO]
>
> [INFO] Total time: < 1 second
> [INFO] Finished at: Sat Dec 10 10:09:16 PST 2005
> [INFO] Final Memory: 1M/2M
> [INFO]
>
> Maven should have identified the LINE NUMBER, not just the file. I shouldn't
> have to pick my way though the document when Maven already has. Better yet,
> it should display the invalid portion of the file and highlight the exact
> point of the error.
> I realize that it is controversial to add this issue as a bug and not an
> enha
[jira] Updated: (MNG-1701) Validate that a plugin is not configured twice in the pom
[ http://jira.codehaus.org/browse/MNG-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-1701: --- Fix Version/s: (was: 3.x) 3.0-alpha-7 > Validate that a plugin is not configured twice in the pom > - > > Key: MNG-1701 > URL: http://jira.codehaus.org/browse/MNG-1701 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: Carlos Sanchez >Priority: Trivial > Fix For: 3.0-alpha-7 > > > Check that there're no two elements of the same 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: (MNG-1628) Create new phase to prepare for integration tests
[ http://jira.codehaus.org/browse/MNG-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-1628. - Resolution: Duplicate couldn't find an issue for when the phase was added > Create new phase to prepare for integration tests > - > > Key: MNG-1628 > URL: http://jira.codehaus.org/browse/MNG-1628 > Project: Maven 2 & 3 > Issue Type: Task > Components: Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: Vincent Massol > > I think we need some integration-test-prepare phase. This is where tools like > Cargo can be used to prepare everything required for integration tests (like > starting containers, db, etc). ATM if you look at the existing phases the > phase that is before integration-test is the "package" phase which is not > appropriate for 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] Reopened: (MNG-1628) Create new phase to prepare for integration tests
[ http://jira.codehaus.org/browse/MNG-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter reopened MNG-1628: --- > Create new phase to prepare for integration tests > - > > Key: MNG-1628 > URL: http://jira.codehaus.org/browse/MNG-1628 > Project: Maven 2 & 3 > Issue Type: Task > Components: Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: Vincent Massol > > I think we need some integration-test-prepare phase. This is where tools like > Cargo can be used to prepare everything required for integration tests (like > starting containers, db, etc). ATM if you look at the existing phases the > phase that is before integration-test is the "package" phase which is not > appropriate for 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] Commented: (MNG-1649) Allow plugins to depend upon other plugin's goals
[ http://jira.codehaus.org/browse/MNG-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204340#action_204340 ] Jason van Zyl commented on MNG-1649: Plugins depending on plugins is just a bad idea. > Allow plugins to depend upon other plugin's goals > - > > Key: MNG-1649 > URL: http://jira.codehaus.org/browse/MNG-1649 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugin API, Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: Mark Hobson > Fix For: 3.x > > > Need to resolve the use-case discussed on dev: > http://www.nabble.com/Re%3A-m2-Plugins-that-depend-on-other-plugin-goals-t473646.html -- 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-1649) Allow plugins to depend upon other plugin's goals
[ http://jira.codehaus.org/browse/MNG-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1649. -- Resolution: Won't Fix > Allow plugins to depend upon other plugin's goals > - > > Key: MNG-1649 > URL: http://jira.codehaus.org/browse/MNG-1649 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugin API, Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: Mark Hobson > Fix For: 3.x > > > Need to resolve the use-case discussed on dev: > http://www.nabble.com/Re%3A-m2-Plugins-that-depend-on-other-plugin-goals-t473646.html -- 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-1326) Using CVS/CVN/etc. as source-code repository for Maven + having list of known projects.
[ http://jira.codehaus.org/browse/MNG-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1326. -- Resolution: Won't Fix > Using CVS/CVN/etc. as source-code repository for Maven + having list of known > projects. > --- > > Key: MNG-1326 > URL: http://jira.codehaus.org/browse/MNG-1326 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Command Line, Reactor and workspace >Reporter: Miks Rozenbergs > Fix For: 3.x > > > INTRODUCTION > This feature is about Maven being able to automatically download source for > dependent projects and compile them. > The desired procedure would be to: > 1. manually check out the project you wish to build > 2. run maven on it > Maven itself would then: > 1. read through dependencies, > 2. checkout each of the dependencies from Source Control system > 3. for each checked out project, do step #1. > This would for example solve the issue of re-build everything from an > arbitrary node on dependency graph e.g. creating a hotfix for some big > application. > IMPLEMENTATION > It would require to have a list of all known groupId/artifactId/version with > they corresponding location. Maven would know the location of this list (it > can be provided in settings.xml) and for each dependency it would check this > list to see where to get the it's source. -- 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: (MNG-1326) Using CVS/CVN/etc. as source-code repository for Maven + having list of known projects.
[ http://jira.codehaus.org/browse/MNG-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204339#action_204339 ] Jason van Zyl commented on MNG-1326: This is not what Maven was built to do. It can be implemented as a plugin or extension, but won't be supported by default. > Using CVS/CVN/etc. as source-code repository for Maven + having list of known > projects. > --- > > Key: MNG-1326 > URL: http://jira.codehaus.org/browse/MNG-1326 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Command Line, Reactor and workspace >Reporter: Miks Rozenbergs > Fix For: 3.x > > > INTRODUCTION > This feature is about Maven being able to automatically download source for > dependent projects and compile them. > The desired procedure would be to: > 1. manually check out the project you wish to build > 2. run maven on it > Maven itself would then: > 1. read through dependencies, > 2. checkout each of the dependencies from Source Control system > 3. for each checked out project, do step #1. > This would for example solve the issue of re-build everything from an > arbitrary node on dependency graph e.g. creating a hotfix for some big > application. > IMPLEMENTATION > It would require to have a list of all known groupId/artifactId/version with > they corresponding location. Maven would know the location of this list (it > can be provided in settings.xml) and for each dependency it would check this > list to see where to get the it's source. -- 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: (MNG-1628) Create new phase to prepare for integration tests
[ http://jira.codehaus.org/browse/MNG-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204338#action_204338 ] Paul Benedict commented on MNG-1628: If the suggested phase is already implemented, this should be marked as Duplicate rather than Won't Fix. > Create new phase to prepare for integration tests > - > > Key: MNG-1628 > URL: http://jira.codehaus.org/browse/MNG-1628 > Project: Maven 2 & 3 > Issue Type: Task > Components: Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: Vincent Massol > > I think we need some integration-test-prepare phase. This is where tools like > Cargo can be used to prepare everything required for integration tests (like > starting containers, db, etc). ATM if you look at the existing phases the > phase that is before integration-test is the "package" phase which is not > appropriate for 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] Closed: (MNG-136) Allow the selection of the xml (un)marshalling tools based on the POM version.
[ http://jira.codehaus.org/browse/MNG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-136. Resolution: Duplicate Fix Version/s: (was: 3.x) > Allow the selection of the xml (un)marshalling tools based on the POM version. > -- > > Key: MNG-136 > URL: http://jira.codehaus.org/browse/MNG-136 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Inheritance and Interpolation >Reporter: Jason van Zyl >Assignee: Jason van Zyl >Priority: Critical > > Depending on what version of the POM we are dealing with we need to be able > to deal with those various versions. We probably also have to think about how > incompatible elements are dealt with. -- 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] Reopened: (MNG-136) Allow the selection of the xml (un)marshalling tools based on the POM version.
[ http://jira.codehaus.org/browse/MNG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter reopened MNG-136: -- > Allow the selection of the xml (un)marshalling tools based on the POM version. > -- > > Key: MNG-136 > URL: http://jira.codehaus.org/browse/MNG-136 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Inheritance and Interpolation >Reporter: Jason van Zyl >Assignee: Jason van Zyl >Priority: Critical > > Depending on what version of the POM we are dealing with we need to be able > to deal with those various versions. We probably also have to think about how > incompatible elements are dealt with. -- 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-1067) Replace the mock plugin data with real data
[ http://jira.codehaus.org/browse/MNG-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1067: -- Fix Version/s: (was: 3.x) > Replace the mock plugin data with real data > --- > > Key: MNG-1067 > URL: http://jira.codehaus.org/browse/MNG-1067 > Project: Maven 2 & 3 > Issue Type: Task > Components: Embedding >Reporter: Jason van Zyl > > Initially we need to download the plugin metadata and use that to grab the > metadata from a plugin JAR. Eventually we can create an index. -- 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-53) The model reader/writer used inside DefaultMavenProjectBuilder need to be components
[ http://jira.codehaus.org/browse/MNG-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-53. --- Resolution: Duplicate Fix Version/s: (was: 3.x) sorted out by the refactor of the project builder > The model reader/writer used inside DefaultMavenProjectBuilder need to be > components > > > Key: MNG-53 > URL: http://jira.codehaus.org/browse/MNG-53 > Project: Maven 2 & 3 > Issue Type: Task > Components: Inheritance and Interpolation >Reporter: Jason van Zyl >Priority: Minor > > Currently the model reader/writer being used are the ones generated by > Modello but we need a small wrapper around these to make them components so > that we can use the standard plexus component assembly to pull in the version > of reader/writer we want to use. This will come into play when we start > reading/writing different versions of the model. -- 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-1084) Review thread safety in maven to make the embedder safe to use
[ http://jira.codehaus.org/browse/MNG-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1084: -- Fix Version/s: (was: 3.x) > Review thread safety in maven to make the embedder safe to use > -- > > Key: MNG-1084 > URL: http://jira.codehaus.org/browse/MNG-1084 > Project: Maven 2 & 3 > Issue Type: Task > Components: Embedding >Reporter: Jason van Zyl >Assignee: Jason van Zyl > > I've found several things so far so a general review needs to be done. -- 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-1065) SummaryPluginDescriptor doesn't expose goals prefix (id)
[ http://jira.codehaus.org/browse/MNG-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1065: -- Fix Version/s: (was: 3.x) > SummaryPluginDescriptor doesn't expose goals prefix (id) > - > > Key: MNG-1065 > URL: http://jira.codehaus.org/browse/MNG-1065 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Embedding >Reporter: Jason van Zyl > Attachments: goals.png > > > For Goals selection dialog it be nice to display goal prefixes/id (currently > goals are grupped by plugins). > Currently only name (human readable) and artifactid is exposed. -- 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-1120) don't require if there is a valid schema element
[ http://jira.codehaus.org/browse/MNG-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1120: -- Fix Version/s: (was: 2.3.x) > don't require if there is a valid schema element > - > > Key: MNG-1120 > URL: http://jira.codehaus.org/browse/MNG-1120 > Project: Maven 2 & 3 > Issue Type: Bug > Components: POM >Reporter: Brett Porter >Priority: Minor > > This can't happen in 2.0.x. -- 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] Reopened: (MNG-1175) Investigate if MavenEmbedderLogger can be replaced by ...plugin.logging.Log
[ http://jira.codehaus.org/browse/MNG-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter reopened MNG-1175: --- > Investigate if MavenEmbedderLogger can be replaced by ...plugin.logging.Log > --- > > Key: MNG-1175 > URL: http://jira.codehaus.org/browse/MNG-1175 > Project: Maven 2 & 3 > Issue Type: Task > Components: Embedding >Reporter: Eugene Kuleshov >Assignee: Jason van Zyl >Priority: Critical > > Maven plugins are using its own logging framework ...plugin.logging.Log which > is quite the same as MavenEmbedderLogger exposed by embedder. Please > investigate if plugin logger should be used directly. > That could be helpful if some of IDE plugins would use maven plugins directly > (e.g. some utility classes from maven-eclipse-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: (MNG-1175) Investigate if MavenEmbedderLogger can be replaced by ...plugin.logging.Log
[ http://jira.codehaus.org/browse/MNG-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-1175. - Resolution: Won't Fix Fix Version/s: (was: 3.x) > Investigate if MavenEmbedderLogger can be replaced by ...plugin.logging.Log > --- > > Key: MNG-1175 > URL: http://jira.codehaus.org/browse/MNG-1175 > Project: Maven 2 & 3 > Issue Type: Task > Components: Embedding >Reporter: Eugene Kuleshov >Assignee: Jason van Zyl >Priority: Critical > > Maven plugins are using its own logging framework ...plugin.logging.Log which > is quite the same as MavenEmbedderLogger exposed by embedder. Please > investigate if plugin logger should be used directly. > That could be helpful if some of IDE plugins would use maven plugins directly > (e.g. some utility classes from maven-eclipse-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: (MNG-1191) need to correctly distinguish between maven internal errors and user errors
[ http://jira.codehaus.org/browse/MNG-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-1191. - Resolution: Duplicate Fix Version/s: (was: 3.x) > need to correctly distinguish between maven internal errors and user errors > --- > > Key: MNG-1191 > URL: http://jira.codehaus.org/browse/MNG-1191 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Errors >Reporter: Brett Porter > > currently don't know much about the exception that occurred and whether it > should be autoreported as a "crash", or if it is user error, or user > environment. -- 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] Reopened: (MNG-1191) need to correctly distinguish between maven internal errors and user errors
[ http://jira.codehaus.org/browse/MNG-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter reopened MNG-1191: --- > need to correctly distinguish between maven internal errors and user errors > --- > > Key: MNG-1191 > URL: http://jira.codehaus.org/browse/MNG-1191 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Errors >Reporter: Brett Porter > > currently don't know much about the exception that occurred and whether it > should be autoreported as a "crash", or if it is user error, or user > environment. -- 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-1203) snapshot directories create in local repository on some occasions
[ http://jira.codehaus.org/browse/MNG-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1203: -- Fix Version/s: (was: 2.2.x) > snapshot directories create in local repository on some occasions > - > > Key: MNG-1203 > URL: http://jira.codehaus.org/browse/MNG-1203 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Reporter: Brett Porter >Priority: Trivial > > do you still see 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-1440) Developer Object Model (DOM)
[ http://jira.codehaus.org/browse/MNG-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1440: -- Fix Version/s: (was: 2.3.x) > Developer Object Model (DOM) > > > Key: MNG-1440 > URL: http://jira.codehaus.org/browse/MNG-1440 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Design, Patterns & Best Practices, POM >Reporter: Jason van Zyl >Priority: Trivial > > Would be cool to be able to reference a developer by id from any POM and get > their full range of information. -- 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-1592) Top level element in POM is not correctly validated
[ http://jira.codehaus.org/browse/MNG-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-1592. - Resolution: Duplicate Fix Version/s: (was: 3.x) > Top level element in POM is not correctly validated > --- > > Key: MNG-1592 > URL: http://jira.codehaus.org/browse/MNG-1592 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: Carlos Sanchez >Assignee: Jason van Zyl > Attachments: it1019.patch > > > this pom doesn't make the build break > > 4.0.0 > test > test > 1.0 > > and I'm starting to see wrong poms with a top level instead of > -- 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-1439) Organization Object Model (OOM)
[ http://jira.codehaus.org/browse/MNG-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1439: -- Fix Version/s: (was: 3.x) > Organization Object Model (OOM) > > > Key: MNG-1439 > URL: http://jira.codehaus.org/browse/MNG-1439 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Design, Patterns & Best Practices, POM >Reporter: Jason van Zyl >Priority: Trivial > > Would be cool to start capturing organizational information and just use a > reference from projects to the OOM. -- 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] Reopened: (MNG-1592) Top level element in POM is not correctly validated
[ http://jira.codehaus.org/browse/MNG-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter reopened MNG-1592: --- > Top level element in POM is not correctly validated > --- > > Key: MNG-1592 > URL: http://jira.codehaus.org/browse/MNG-1592 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: Carlos Sanchez >Assignee: Jason van Zyl > Attachments: it1019.patch > > > this pom doesn't make the build break > > 4.0.0 > test > test > 1.0 > > and I'm starting to see wrong poms with a top level instead of > -- 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-1667) M2_HOME is not used in the way described in README.txt and as such bootstrap build fails
[
http://jira.codehaus.org/browse/MNG-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-1667:
--
Fix Version/s: (was: 2.2.x)
the readme was updated some time ago too
> M2_HOME is not used in the way described in README.txt and as such bootstrap
> build fails
>
>
> Key: MNG-1667
> URL: http://jira.codehaus.org/browse/MNG-1667
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Bootstrap & Build
> Environment: Win32 (XP SP2)
>Reporter: John Allen
>
> From README.txt
> Set the environment variable M2_HOME pointing to the dir where you want
> Maven2 installed.
> NOTE: presently, the directory {M2_HOME}/bin must be in your path:
> set PATH=%PATH%;%M2_HOME%\bin
> or
> export PATH=$PATH:$M2_HOME/bin
> MVN SNAPSHOT is actually installed into %M2_HOME$/../maven-2.0.1-SNAPSHOT
> and this is not the location on the PATH so integration tests fail.
--
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-2705) add jar sources in repository for snapshot builds
[ http://jira.codehaus.org/browse/MNG-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-2705: -- Fix Version/s: (was: 3.x) > add jar sources in repository for snapshot builds > - > > Key: MNG-2705 > URL: http://jira.codehaus.org/browse/MNG-2705 > Project: Maven 2 & 3 > Issue Type: Task > Components: Bootstrap & Build >Reporter: Barrie Treloar >Priority: Minor > > When using IDE like eclipse, it would be great to have dependecies sources > (optionnaly) added to repository. > This way eclipse plugin (and others) could generate a .classpath file that > set "source attachement" and allow code and javadoc consult, debuging and > inherited methods implementation with original parameters names. -- 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-2643) "Unlimited" number of version digits
[ http://jira.codehaus.org/browse/MNG-2643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-2643: -- Fix Version/s: (was: 3.x) > "Unlimited" number of version digits > > > Key: MNG-2643 > URL: http://jira.codehaus.org/browse/MNG-2643 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Dependencies >Affects Versions: 2.0.4 >Reporter: Jonas Olsson > > Currently Maven only handles three digit versions, but that seems to be an > artificial limit, not a technical one. > Couldn't the version ordering/comparison be extend to an arbitrary number of > digits? -- 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-1725) Find a reusable/consistent way to insulate Mojos from 'does not implement Log' in commons-logging
[ http://jira.codehaus.org/browse/MNG-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-1725. - Resolution: Duplicate Fix Version/s: (was: 3.x) > Find a reusable/consistent way to insulate Mojos from 'does not implement > Log' in commons-logging > - > > Key: MNG-1725 > URL: http://jira.codehaus.org/browse/MNG-1725 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: John Casey > > I've had to add a runtime dependency on log4j to the checkstyle plugin to > allow it to work, since there are classloader issues with using the > Jdk14Logger provider. We will continue to have these issues until we find a > way to resolve this consistently for all plugins. Possibly some sort of > shared-code utility or something... -- 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-4505) use slf4j to control various logging frameworks
use slf4j to control various logging frameworks --- Key: MNG-4505 URL: http://jira.codehaus.org/browse/MNG-4505 Project: Maven 2 & 3 Issue Type: Improvement Components: Logging Reporter: Brett Porter In MNG-1725, Jason indicated this was the plan for Maven 3.x. I didn't see an existing issue and from what I can tell it hasn't been implemented yet, so creating an issue to track 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] Reopened: (MNG-1725) Find a reusable/consistent way to insulate Mojos from 'does not implement Log' in commons-logging
[ http://jira.codehaus.org/browse/MNG-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter reopened MNG-1725: --- > Find a reusable/consistent way to insulate Mojos from 'does not implement > Log' in commons-logging > - > > Key: MNG-1725 > URL: http://jira.codehaus.org/browse/MNG-1725 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: John Casey > > I've had to add a runtime dependency on log4j to the checkstyle plugin to > allow it to work, since there are classloader issues with using the > Jdk14Logger provider. We will continue to have these issues until we find a > way to resolve this consistently for all plugins. Possibly some sort of > shared-code utility or something... -- 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-1885) Uniquely identify modules by module name and version number
[ http://jira.codehaus.org/browse/MNG-1885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1885: -- Fix Version/s: (was: 3.x) > Uniquely identify modules by module name and version number > --- > > Key: MNG-1885 > URL: http://jira.codehaus.org/browse/MNG-1885 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Design, Patterns & Best Practices > Environment: This is a platform independent issue. Windows XP, Java > builds >Reporter: John Reynolds >Priority: Trivial > > Currently when buiding project dependencies and/or performing a build via the > reactor "-r option" it will not build projects that have the same project id. > This works in most unique project scenarios, but in scenarios where you may > have the directories for a project broken out by version number, you end up > with the same artifact-id for the multiple projects. The only difference > would be that they are target at different versions. > Example Layout > Project X > | > +--Dev (pom.xml contains artifact "ProjectX" version Dev (Dev head > contains latest release) > | > +--1.0 (pom.xml contains artifact "ProjectX" Version 1.0 > | > +--2.0 (pom.xml contains artifact "ProjectX" Version 2.0 > We may actually build multiple versions of plug-ins that could be deployed > and built as a whole. It would simplify the builds if the "-r" option would > build each project and version it finds. Today it will only build one of > them. > The same issue or set of problems is presented to the module concept. It's > difficult for a parent project that needs to build multiple projects to point > at specific versions. Today they project would require a unique artifact and > a module pointing to each directory for the pom. It will only build one of > the instances of the artifact ID. This forces changes to the parent pom, to > deal with the issue. It would be nice to be able to build a specific > version or all the versions related to a module. > Multi-Project module builds should have the knowledge of versions when > deciding what to build, with an option of including specific versions or all > versions of an artifactId > The "-r" reactor option should all directories to be recursed and build > multiple projects of the same artifact id, regardless over version. -- 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-1916) Making it possible for plug-in to add modules to the reactor programatically
[
http://jira.codehaus.org/browse/MNG-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-1916:
--
Fix Version/s: (was: 3.x)
> Making it possible for plug-in to add modules to the reactor programatically
>
>
> Key: MNG-1916
> URL: http://jira.codehaus.org/browse/MNG-1916
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Plugin API, Reactor and workspace
>Reporter: Nils Fredrik Gjerull
>
> I would like to be able to specify a number of directories as plug-in
> directories, automatically discover every plug-in in those directories and
> include them in the reactor. As I understands it the reactor with it's
> modules ({{org.apache.maven.execution.ReactorManager}}) is created in
> {{org.apache.maven.DefaultMaven}}. If I understands this correctly maven
> plug-ins can't add projects to the reactor programatically.
> My proposition to solve this is to add a phase which will be executed after
> the pom.xml is parsed, but before the information stored in
> Model/MavenProject is used, and most importantly before the {{ReactorManager
> is created}}. Then you can add information to the MavenProject
> programatically, increasing the flexibility for plug-ins.
> I am not fluent in the maven2 code base, but it seems to me that this require
> quite a lot of changes to the code. As I understands it the life cycle starts
> after the {{ReactorManager}} is made, and therefore after the information in
> Model have started to be used.
--
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-2012) build with custom repository location and settings file doesn't work anymore
[ http://jira.codehaus.org/browse/MNG-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-2012: -- Fix Version/s: (was: 3.x) > build with custom repository location and settings file doesn't work anymore > > > Key: MNG-2012 > URL: http://jira.codehaus.org/browse/MNG-2012 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Bootstrap & Build >Reporter: Jerome Lacoste >Priority: Minor > Attachments: m2.log > > > And related to the MNG-1667 breakage, > ./bootstrap.sh -s ~/.m2/settings-m2trunk.xml $* > with settings-m2trunk.xml pointing to a different repository doesn't work at > all anymore > Breaks very early during the build process. Will try to get a log. -- 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-2235) unify .m2 configuration and have a "super settings"
[ http://jira.codehaus.org/browse/MNG-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-2235: -- Fix Version/s: (was: 3.x) > unify .m2 configuration and have a "super settings" > --- > > Key: MNG-2235 > URL: http://jira.codehaus.org/browse/MNG-2235 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Settings >Reporter: Brett Porter > > the ".m2/settings.xml" configuration is located in several places, and > instead should be a configuration solely of the default maven settings > builder to make it easily changable. > Also, any defaults in the settings model should come from a super model > implemented in a similar fashion to the super pom. -- 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
