[jira] Updated: (MINDEXER-37) Add a Maven Indexer Plugin
[ https://jira.codehaus.org/browse/MINDEXER-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MINDEXER-37: - Assignee: Olivier Lamy > Add a Maven Indexer Plugin > -- > > Key: MINDEXER-37 > URL: https://jira.codehaus.org/browse/MINDEXER-37 > Project: Maven Indexer > Issue Type: New Feature >Reporter: Olivier Lamy >Assignee: Olivier Lamy > > Basically the plugin could do the following : > * search on a local repo (indexer:search with various queries) > * create an index and upload it tru wagon > Other ideas ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MINDEXER-37) Add a Maven Indexer Plugin
Add a Maven Indexer Plugin -- Key: MINDEXER-37 URL: https://jira.codehaus.org/browse/MINDEXER-37 Project: Maven Indexer Issue Type: New Feature Reporter: Olivier Lamy Basically the plugin could do the following : * search on a local repo (indexer:search with various queries) * create an index and upload it tru wagon Other ideas ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5156) org.sonatype.aether.util.graph.transformer.JavaEffectiveScopeCalculator doesn't take into account direct vs. transitive dependencies
[
https://jira.codehaus.org/browse/MNG-5156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276188#comment-276188
]
Bisser commented on MNG-5156:
-
After you directed me to lines 68-72, I examined the code there and then I
debugged it again to see why it doesn't enter that branch. The reason was that
the 'root' project was not on top level. It was wrapped on the fly into a dummy
project like this:
{noformat}
private ModelSource createStubModelSource(String groupId, String artifactId,
String version)
throws
ProjectBuildingException {
StringBuilder sb = new StringBuilder();
sb.append("");
sb.append("");
sb.append("4.0.0");
sb.append("com.acme.dynamic.project");
sb.append("dummy-dynamic-project");
sb.append("1.0.0");
sb.append("pom");
sb.append("");
sb.append( "");
sb.append( "").append(groupId).append("");
sb.append(
"").append(artifactId).append("");
sb.append( "").append(version).append("");
sb.append( "compile");
sb.append( "");
sb.append("");
sb.append("");
ModelSource modelSource = new StringModelSource(sb.toString());
return modelSource;
}
{noformat}
So, in fact, the hierarchy was like this:
{noformat}
com.acme.dynamic.project:dummy-dynamic-project:pom:1.0.0
\- com.acme:root:jar:1.0.0:compile
+- com.acme:test-framework:jar:1.0.0:test
\- com.acme:another-module:jar:1.0.0:compile
\- com.acme:test-framework:jar:1.0.0:compile
{noformat}
I still think that it makes more sense for the 'test-framework' dependency to
have a 'test' scope because the 'root' dependency enforces the 'test' scope
explicitly, so it's whole sub-tree should use the 'test' scope for the
'test-framework'.
However, if the Maven team has decided that the scope should be 'compile' in
this case, then ok.
Thank you for replying so quickly!
> org.sonatype.aether.util.graph.transformer.JavaEffectiveScopeCalculator
> doesn't take into account direct vs. transitive dependencies
>
>
> Key: MNG-5156
> URL: https://jira.codehaus.org/browse/MNG-5156
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.2, 3.0.3
> Environment: Irrelevant (I debugged the code and I provide an exact
> location of the problem)
>Reporter: Bisser
>Priority: Minor
> Attachments: pom.xml
>
>
> When calculating the scope of a dependency, Maven should assign to direct
> dependencies higher priority than transitive dependencies.
> For example:
> com.acme:root:jar:1.0.0
> +- com.acme:test-framework:jar:1.0.0:test <
> direct dependency
> \- com.acme:another-module:jar:1.0.0:compile
>\- com.acme:test-framework:jar:1.0.0:compile <
> transitive dependency
> We can see that the 'root' project references test-framework directly with
> scope 'test'. However, the same test-framework also has a 'compile' scope,
> but via a transitive dependency. I believe that the final scope should be
> 'test' -- that's the explicit desire of the author of project 'root'.
> However, when I do roughly the following:
>ProjectBuilder projectBuilder =
> plexusContainer.lookup(ProjectBuilder.class);
>ProjectBuildingRequest projectBuildingRequest = ;
>projectBuildingRequest.setResolveDependencies(true);
>...
>ProjectBuildingResult result = projectBuilder.build(pom,
> projectBuildingRequest);
>MavenProject proj = result.getProject();
>...
>Set artifacts = proj.getArtifacts();
> The 'test-framework' Artifact has a scope of 'compile'!!! (I will provide
> more code, if you'd like.)
> After some debugging to find out the reason for this, I reached class
> org.sonatype.aether.util.graph.transformer.JavaEffectiveScopeCalculator.
> There, in method chooseEffectiveScope, there's the following code:
> else if ( scopes.contains( JavaScopes.COMPILE ) )
> {
> effectiveScope = JavaScopes.COMPILE;
> }
> So, no attention is paid whether the dependency is direct or transitive. If
> there's *any* dependency with scope 'compile', then the conflict is resolved
> by setting the final scope to 'compile'. But, as I said above, I believe the
> final scope should be 'test'.
> Here's a relevant stack trace:
> JavaEffectiveScopeCalculator.chooseEffectiveScope(Set) line: 220
> JavaEffectiveScopeCalculator.resolve(ConflictGroup, Map, Set) line:
> 139
> JavaEffectiveScopeCalculator.transformGraph(DependencyNode,
> DependencyGraphTransformationContext) line: 92
> ChainedDependencyGraphTransformer.t
[jira] Created: (MNG-5157) NPE stemming from DefaultModelBuilder.containsCoordinates
NPE stemming from DefaultModelBuilder.containsCoordinates - Key: MNG-5157 URL: https://jira.codehaus.org/browse/MNG-5157 Project: Maven 2 & 3 Issue Type: Bug Affects Versions: 3.0.3 Environment: $ mvn -version Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) Maven home: /opt/apache/maven/apache-maven-3.0.3 Java version: 1.6.0_26, vendor: Sun Microsystems Inc. Java home: /opt/oracle/java/jdk1.6.0_26/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "2.6.38-10-generic", arch: "amd64", family: "unix" Reporter: Andrew Lee Rubinger [ERROR] Internal error: java.lang.NullPointerException -> [Help 1] org.apache.maven.InternalErrorException: Internal error: java.lang.NullPointerException at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) 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:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: java.lang.NullPointerException at java.lang.String.contains(String.java:2103) at org.apache.maven.model.building.DefaultModelBuilder.containsCoordinates(DefaultModelBuilder.java:1047) at org.apache.maven.model.building.DefaultModelBuilder.importDependencyManagement(DefaultModelBuilder.java:948) at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:403) at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:374) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:536) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:542) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:328) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:632) at org.apache.maven.DefaultMaven.getProjectsForMavenReactor(DefaultMaven.java:581) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:233) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) ... 11 more I was able to come across this by declaring in a parent POM a dependencyManagement/dependency entry, then in a child POM putting the same dependencyManagement/dependency entry in place, this time w/ "import" scope. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-5156) org.sonatype.aether.util.graph.transformer.JavaEffectiveScopeCalculator doesn't take into account direct vs. transitive dependencies
[
https://jira.codehaus.org/browse/MNG-5156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-5156.
--
Resolution: Not A Bug
Assignee: Benjamin Bentmann
bq. I still think that it makes more sense for the 'test-framework' dependency
to have a 'test' scope because the 'root' dependency enforces the 'test' scope
explicitly
It's simply a matter of how one interprets a {{}} declaration,
usually they are meant to express requirements/needs. And if your own code
itself requires foo only in runtime scope but a lib that you require for
compilation requires foo in compile scope, it's safer to satisfy the stronger
need and put foo into compile scope.
Whether the subtle differences between direct dependencies and transitive ones
with regard to scope calculation make sense, is another question. In might have
been more consistent to leave the concept of dependency enforcement to
{{}} but now it is like it is.
Back to your wrapping project: Keep in mind that transitive test and provided
scope dependencies as well as optional dependencies are completely dropped from
the graph, i.e. the act of wrapping a dependency heavily changes the resolved
graph.
> org.sonatype.aether.util.graph.transformer.JavaEffectiveScopeCalculator
> doesn't take into account direct vs. transitive dependencies
>
>
> Key: MNG-5156
> URL: https://jira.codehaus.org/browse/MNG-5156
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.2, 3.0.3
> Environment: Irrelevant (I debugged the code and I provide an exact
> location of the problem)
>Reporter: Bisser
>Assignee: Benjamin Bentmann
>Priority: Minor
> Attachments: pom.xml
>
>
> When calculating the scope of a dependency, Maven should assign to direct
> dependencies higher priority than transitive dependencies.
> For example:
> com.acme:root:jar:1.0.0
> +- com.acme:test-framework:jar:1.0.0:test <
> direct dependency
> \- com.acme:another-module:jar:1.0.0:compile
>\- com.acme:test-framework:jar:1.0.0:compile <
> transitive dependency
> We can see that the 'root' project references test-framework directly with
> scope 'test'. However, the same test-framework also has a 'compile' scope,
> but via a transitive dependency. I believe that the final scope should be
> 'test' -- that's the explicit desire of the author of project 'root'.
> However, when I do roughly the following:
>ProjectBuilder projectBuilder =
> plexusContainer.lookup(ProjectBuilder.class);
>ProjectBuildingRequest projectBuildingRequest = ;
>projectBuildingRequest.setResolveDependencies(true);
>...
>ProjectBuildingResult result = projectBuilder.build(pom,
> projectBuildingRequest);
>MavenProject proj = result.getProject();
>...
>Set artifacts = proj.getArtifacts();
> The 'test-framework' Artifact has a scope of 'compile'!!! (I will provide
> more code, if you'd like.)
> After some debugging to find out the reason for this, I reached class
> org.sonatype.aether.util.graph.transformer.JavaEffectiveScopeCalculator.
> There, in method chooseEffectiveScope, there's the following code:
> else if ( scopes.contains( JavaScopes.COMPILE ) )
> {
> effectiveScope = JavaScopes.COMPILE;
> }
> So, no attention is paid whether the dependency is direct or transitive. If
> there's *any* dependency with scope 'compile', then the conflict is resolved
> by setting the final scope to 'compile'. But, as I said above, I believe the
> final scope should be 'test'.
> Here's a relevant stack trace:
> JavaEffectiveScopeCalculator.chooseEffectiveScope(Set) line: 220
> JavaEffectiveScopeCalculator.resolve(ConflictGroup, Map, Set) line:
> 139
> JavaEffectiveScopeCalculator.transformGraph(DependencyNode,
> DependencyGraphTransformationContext) line: 92
> ChainedDependencyGraphTransformer.transformGraph(DependencyNode,
> DependencyGraphTransformationContext) line: 75
> DefaultDependencyCollector.collectDependencies(RepositorySystemSession,
> CollectRequest) line: 253
> DefaultRepositorySystem.collectDependencies(RepositorySystemSession,
> CollectRequest) line: 345
> DefaultProjectDependenciesResolver.resolve(DependencyResolutionRequest) line:
> 131
> DefaultProjectBuilder.build(File, ModelSource,
> DefaultProjectBuilder$InternalConfig) line: 166
> DefaultProjectBuilder.build(ModelSource, ProjectBuildingRequest) line: 108
> .
> .
> .
> By the way, the Dependency Plugin reports this:
> ...
> +- com.acme:test-framework:jar:1.0.0:test (scope not updated to compile)
> The plugin reso
[jira] Commented: (MINSTALL-73) Add skip parameter
[ https://jira.codehaus.org/browse/MINSTALL-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276197#comment-276197 ] Martin Bengl commented on MINSTALL-73: -- Please add this little feature to the next release version! It would help us a lot! > Add skip parameter > -- > > Key: MINSTALL-73 > URL: https://jira.codehaus.org/browse/MINSTALL-73 > Project: Maven 2.x Install Plugin > Issue Type: Improvement > Components: install:install >Affects Versions: 2.4 >Reporter: Ludwig Magnusson > Attachments: MINSTALL-73.patch, MINSTALL-73-test.patch > > > Hello! > The deploy plugin has a skip parameter that if set to true, skips the deploy > goal. > http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html > I was thinking that the install plugin could have the same feature. I have > created a patch (wasn't that hard). And I will submit it when i find out what > number this task gets =) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-5157) NPE stemming from DefaultModelBuilder.containsCoordinates
[ https://jira.codehaus.org/browse/MNG-5157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-5157. -- Resolution: Fixed Fix Version/s: 3.0.4 Assignee: Benjamin Bentmann Fixed in [r1158623|http://svn.apache.org/viewvc?view=revision&revision=1158623]. What mvn meant to report is that your dependency declaration for the import POM is missing one of the coordinates groupId, artifactId or version. > NPE stemming from DefaultModelBuilder.containsCoordinates > - > > Key: MNG-5157 > URL: https://jira.codehaus.org/browse/MNG-5157 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0.3 > Environment: $ mvn -version > Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: /opt/apache/maven/apache-maven-3.0.3 > Java version: 1.6.0_26, vendor: Sun Microsystems Inc. > Java home: /opt/oracle/java/jdk1.6.0_26/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "2.6.38-10-generic", arch: "amd64", family: "unix" >Reporter: Andrew Lee Rubinger >Assignee: Benjamin Bentmann > Fix For: 3.0.4 > > > [ERROR] Internal error: java.lang.NullPointerException -> [Help 1] > org.apache.maven.InternalErrorException: Internal error: > java.lang.NullPointerException > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) > 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:597) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: java.lang.NullPointerException > at java.lang.String.contains(String.java:2103) > at > org.apache.maven.model.building.DefaultModelBuilder.containsCoordinates(DefaultModelBuilder.java:1047) > at > org.apache.maven.model.building.DefaultModelBuilder.importDependencyManagement(DefaultModelBuilder.java:948) > at > org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:403) > at > org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:374) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:536) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:542) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:328) > at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:632) > at > org.apache.maven.DefaultMaven.getProjectsForMavenReactor(DefaultMaven.java:581) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:233) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) > ... 11 more > I was able to come across this by declaring in a parent POM a > dependencyManagement/dependency entry, then in a child POM putting the same > dependencyManagement/dependency entry in place, this time w/ "import" scope. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5157) NPE stemming from DefaultModelBuilder.containsCoordinates
[ https://jira.codehaus.org/browse/MNG-5157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276200#comment-276200 ] Andrew Lee Rubinger commented on MNG-5157: -- My thanks. :) https://twitter.com/#!/ALRubinger/status/103784873315143680 > NPE stemming from DefaultModelBuilder.containsCoordinates > - > > Key: MNG-5157 > URL: https://jira.codehaus.org/browse/MNG-5157 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0.3 > Environment: $ mvn -version > Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: /opt/apache/maven/apache-maven-3.0.3 > Java version: 1.6.0_26, vendor: Sun Microsystems Inc. > Java home: /opt/oracle/java/jdk1.6.0_26/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "2.6.38-10-generic", arch: "amd64", family: "unix" >Reporter: Andrew Lee Rubinger >Assignee: Benjamin Bentmann > Fix For: 3.0.4 > > > [ERROR] Internal error: java.lang.NullPointerException -> [Help 1] > org.apache.maven.InternalErrorException: Internal error: > java.lang.NullPointerException > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) > 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:597) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: java.lang.NullPointerException > at java.lang.String.contains(String.java:2103) > at > org.apache.maven.model.building.DefaultModelBuilder.containsCoordinates(DefaultModelBuilder.java:1047) > at > org.apache.maven.model.building.DefaultModelBuilder.importDependencyManagement(DefaultModelBuilder.java:948) > at > org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:403) > at > org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:374) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:536) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:542) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:328) > at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:632) > at > org.apache.maven.DefaultMaven.getProjectsForMavenReactor(DefaultMaven.java:581) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:233) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) > ... 11 more > I was able to come across this by declaring in a parent POM a > dependencyManagement/dependency entry, then in a child POM putting the same > dependencyManagement/dependency entry in place, this time w/ "import" scope. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-605) Surefire tests through Cobertura fail when site-deploy is called during release:deploy
Surefire tests through Cobertura fail when site-deploy is called during
release:deploy
--
Key: MSITE-605
URL: https://jira.codehaus.org/browse/MSITE-605
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: site:deploy
Affects Versions: 3.0-beta-3
Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Maven home: D:\apache-maven-3.0.3\bin\..
Java version: 1.6.0_25, vendor: Sun Microsystems Inc.
Java home: E:\Program Files\Java\jdk1.6.0_25\jre
Default locale: nl_NL, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
Reporter: Robert Scholte
While releasing the sql-maven-plugin-1.5 I hit this problem.
There's a chain of plugins being called, but it seems likely that the
maven-site-plugin is the weakest link.
{noformat}
[INFO] --- cobertura-maven-plugin:2.4:instrument (report:cobertura) @
sql-maven-plugin ---
[INFO] Cobertura 1.9.4.1 - GNU GPL License (NO WARRANTY) - See COPYRIGHT
file
Instrumenting 7 files to
D:\java-workspace\codehaus-mojo\sql-maven-plugin\target\checkout\target\generated-classes\cobertura
[cobertura] WARN [main]
net.sourceforge.cobertura.instrument.ClassInstrumenter - No line number
information found for class org.codehaus.mojo.sql.SqlExecMojo$1. Perhaps you
need to compile with debug=true?
Cobertura: Saved information on 7 classes.
Instrument time: 533ms
[INFO] Instrumentation was successful.
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:testResources
(default-testResources) @ sql-maven-plugin ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @
sql-maven-plugin ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- maven-surefire-plugin:2.7.2:test (default-test) @
sql-maven-plugin ---
[INFO] Surefire report directory:
D:\java-workspace\codehaus-mojo\sql-maven-plugin\target\checkout\target\surefire-reports
---
T E S T S
---
Running org.codehaus.mojo.sql.SqlExecMojoTest
Tests run: 26, Failures: 0, Errors: 20, Skipped: 0, Time elapsed: 3.614 sec
<<< FAILURE!
Running org.codehaus.mojo.sql.SqlSplitterTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 56.521 sec
Results :
Tests in error:
testNoCommandMojo(org.codehaus.mojo.sql.SqlExecMojoTest):
org/apache/commons/logging/LogFactory
testCreateCommandMojo(org.codehaus.mojo.sql.SqlExecMojoTest): Could not
initialize class org.axiondb.jdbc.AxionConnection
testDropCommandMojo(org.codehaus.mojo.sql.SqlExecMojoTest): Could not
initialize class org.axiondb.jdbc.AxionConnection
testFileSetMojo(org.codehaus.mojo.sql.SqlExecMojoTest): Could not
initialize class org.axiondb.jdbc.AxionConnection
testFileArrayMojo(org.codehaus.mojo.sql.SqlExecMojoTest): Could not
initialize class org.axiondb.jdbc.AxionConnection
testAllMojo(org.codehaus.mojo.sql.SqlExecMojoTest): Could not initialize
class org.axiondb.jdbc.AxionConnection
testOrderFile(org.codehaus.mojo.sql.SqlExecMojoTest): Could not
initialize class org.axiondb.jdbc.AxionConnection
testOnErrorContinueMojo(org.codehaus.mojo.sql.SqlExecMojoTest): Could not
initialize class org.axiondb.jdbc.AxionConnection
testOnErrorAbortMojo(org.codehaus.mojo.sql.SqlExecMojoTest): Could not
initialize class org.axiondb.jdbc.AxionConnection
testOnErrorAbortAfterMojo(org.codehaus.mojo.sql.SqlExecMojoTest): Could
not initialize class org.axiondb.jdbc.AxionConnection
testDefaultUsernamePassword(org.codehaus.mojo.sql.SqlExecMojoTest): Could
not initialize class org.axiondb.jdbc.AxionConnection
testUsernamePasswordLookup(org.codehaus.mojo.sql.SqlExecMojoTest): Could
not initialize class org.axiondb.jdbc.AxionConnection
testBlockMode(org.codehaus.mojo.sql.SqlExecMojoTest): Could not
initialize class org.axiondb.jdbc.AxionConnection
testKeepFormat(org.codehaus.mojo.sql.SqlExecMojoTest): Could not
initialize class org.axiondb.jdbc.AxionConnection
testBadDelimiter(org.codehaus.mojo.sql.SqlExecMojoTest): Could not
initialize class org.axiondb.jdbc.AxionConnection
testGoodDelimiter(org.codehaus.mojo.sql.SqlExecMojoTest): Could not
initialize class org.axiondb.jdbc.AxionConnection
testBadDelimiterType(org.codehaus.mojo.sql.SqlExecMojoTest): Could not
initialize class org.axiondb.jdbc.AxionConnection
testGoodDelimiterType(org.codehaus.mojo.sql.SqlExecMojoTest): Could not
initialize class org.axiondb.jdbc.AxionConnection
testOutputFile(org.codehaus.mojo.sql.SqlExecMojoTest): Could n
[jira] Commented: (SCM-629) parsing server path starting with digit
[ https://jira.codehaus.org/browse/SCM-629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276211#comment-276211 ] Xavier Jodoin commented on SCM-629: --- it's valid url. Try git clone g...@github.com/360-Innovations/FJPAQuery.git > parsing server path starting with digit > --- > > Key: SCM-629 > URL: https://jira.codehaus.org/browse/SCM-629 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.5 >Reporter: Xavier Jodoin > Attachments: fix_repoPath_with_digit.patch > > > scm:git:g...@github.com:360-Innovations/FJPAQuery.git > it will get 360 as the server port -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-629) parsing server path starting with digit
[ https://jira.codehaus.org/browse/SCM-629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276223#comment-276223 ] Mark Struberg commented on SCM-629: --- @Xavier: g...@github.com/360-Innovations/FJPAQuery.git is perfectly fine, but g...@github.com:360-Innovations/FJPAQuery.git is not > parsing server path starting with digit > --- > > Key: SCM-629 > URL: https://jira.codehaus.org/browse/SCM-629 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.5 >Reporter: Xavier Jodoin > Attachments: fix_repoPath_with_digit.patch > > > scm:git:g...@github.com:360-Innovations/FJPAQuery.git > it will get 360 as the server port -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MINDEXER-29) Create IndexCreator that indexes JAR Manifest
[ https://jira.codehaus.org/browse/MINDEXER-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276225#comment-276225 ] Olivier Lamy commented on MINDEXER-29: -- with MINDEXER-36 some osgi metadatas has been added. > Create IndexCreator that indexes JAR Manifest > - > > Key: MINDEXER-29 > URL: https://jira.codehaus.org/browse/MINDEXER-29 > Project: Maven Indexer > Issue Type: New Feature >Reporter: Tamás Cservenák > > Create IndexCreator that indexes JAR Manifest. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-629) parsing server path starting with digit
[ https://jira.codehaus.org/browse/SCM-629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276232#comment-276232 ] Xavier Jodoin commented on SCM-629: --- Sorry typo it is g...@github.com:360-Innovations/FJPAQuery.git take a look http://github.com/360-Innovations/FJPAQuery > parsing server path starting with digit > --- > > Key: SCM-629 > URL: https://jira.codehaus.org/browse/SCM-629 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.5 >Reporter: Xavier Jodoin > Attachments: fix_repoPath_with_digit.patch > > > scm:git:g...@github.com:360-Innovations/FJPAQuery.git > it will get 360 as the server port -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-629) parsing server path starting with digit
[ https://jira.codehaus.org/browse/SCM-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Jodoin updated SCM-629: -- Attachment: Capture.png > parsing server path starting with digit > --- > > Key: SCM-629 > URL: https://jira.codehaus.org/browse/SCM-629 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.5 >Reporter: Xavier Jodoin > Attachments: Capture.png, fix_repoPath_with_digit.patch > > > scm:git:g...@github.com:360-Innovations/FJPAQuery.git > it will get 360 as the server port -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (MINDEXER-34) Order of IndexCreator's passed to addIndexingContextForced affects whether MavenPluginArtifactInfoIndexCreator has any effect
[
https://jira.codehaus.org/browse/MINDEXER-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on MINDEXER-34 started by Tamás Cservenák.
> Order of IndexCreator's passed to addIndexingContextForced affects whether
> MavenPluginArtifactInfoIndexCreator has any effect
> -
>
> Key: MINDEXER-34
> URL: https://jira.codehaus.org/browse/MINDEXER-34
> Project: Maven Indexer
> Issue Type: Bug
>Affects Versions: 4.1.0
> Environment: JDK 6, Ubuntu, Maven 3.0.3; actually Indexer 4.1.1 but
> that is not listed as an option here
>Reporter: Jesse Glick
>Assignee: Tamás Cservenák
>Priority: Critical
> Fix For: 4.1.2
>
>
> While working on a utility inside NetBeans to look up all plugins using a
> given goal prefix, I found unreliable behavior. To investigate, I wrote a
> unit test that used Maven Indexer (along with some NB helper classes) that:
> 1. Creates a fresh local repository.
> 2. Installs a trivial "plugin" ({{maven-plugin}} POM + JAR) with just a
> {{META-INF/maven/plugin.xml}} containing
> {{stuff}}.
> 3. Indexes the repository, using all available {{IndexCreator}} instances.
> 4. Runs a search like {{ArtifactInfo.PLUGIN_PREFIX="stuff"}} and checks that
> there is one hit.
> This test passed sometimes - including always when run from the debugger -
> but usually failed. Eventually I found that the order of {{IndexCreator}}
> instances returned from the Plexus container mattered: if {{min}} preceded
> {{maven-plugin}} then the test passed, whereas if {{min}} followed
> {{maven-plugin}} then the test failed. Furthermore, despite
> {{META-INF/plexus/components.xml}} listing these implementations in a
> particular order (seemingly arbitrary at build time), the actual order
> returned by {{PlexusContainer.lookupList}} seemed to vary randomly from run
> to run.
> The problem may have to do with
> {{MinimalArtifactInfoIndexCreator.updateLegacyDocument}}, which does
> something with {{PLUGIN_PREFIX}} and {{PLUGIN_GOALS}} for reasons unclear to
> me. When the creators were in the "wrong" order,
> http://code.google.com/p/luke/ confirmed that {{px}} and {{gx}} fields were
> just not present.
> I can work around this issue in the NetBeans code which indexes the local
> repository, using a hardcoded list of indexers (or rather, indexer IDs) as
> {{AbstractIndexCreatorHelper}} in the Indexer test sources does. But that
> does not help for downloaded remote indices, which might have been created by
> a faulty version of Indexer - since {{NexusIndexerCli.getIndexers}} uses
> {{lookupList}} when {{--type full}} is used. This means that any queries
> about plugin prefixes or goals may return results only for plugins which
> happen to have been downloaded locally. Indeed this is exactly what seems to
> happen when I try it, i.e. the Central index I am getting (via a proxy in
> Nexus 1.9.1.1) has no {{PLUGIN_*}} fields.
> The less desirable workaround would be to run a search on
> {{ArtifactInfo.PACKAGING="maven-plugin"}}, and for each hit, download the
> actual JAR and parse {{plugin.xml}} myself.
> I am not sure whether the position of
> {{MavenArchetypeArtifactInfoIndexCreator}} also matters, but it seems
> plausible, since it overrides a field normally stored in
> {{MinimalArtifactInfoIndexCreator}}.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MINDEXER-34) Order of IndexCreator's passed to addIndexingContextForced affects whether MavenPluginArtifactInfoIndexCreator has any effect
[
https://jira.codehaus.org/browse/MINDEXER-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276236#comment-276236
]
Tamás Cservenák commented on MINDEXER-34:
-
Fixed in rev1158739
http://svn.apache.org/viewvc?view=revision&revision=1158739
> Order of IndexCreator's passed to addIndexingContextForced affects whether
> MavenPluginArtifactInfoIndexCreator has any effect
> -
>
> Key: MINDEXER-34
> URL: https://jira.codehaus.org/browse/MINDEXER-34
> Project: Maven Indexer
> Issue Type: Bug
>Affects Versions: 4.1.0
> Environment: JDK 6, Ubuntu, Maven 3.0.3; actually Indexer 4.1.1 but
> that is not listed as an option here
>Reporter: Jesse Glick
>Assignee: Tamás Cservenák
>Priority: Critical
> Fix For: 4.1.2
>
>
> While working on a utility inside NetBeans to look up all plugins using a
> given goal prefix, I found unreliable behavior. To investigate, I wrote a
> unit test that used Maven Indexer (along with some NB helper classes) that:
> 1. Creates a fresh local repository.
> 2. Installs a trivial "plugin" ({{maven-plugin}} POM + JAR) with just a
> {{META-INF/maven/plugin.xml}} containing
> {{stuff}}.
> 3. Indexes the repository, using all available {{IndexCreator}} instances.
> 4. Runs a search like {{ArtifactInfo.PLUGIN_PREFIX="stuff"}} and checks that
> there is one hit.
> This test passed sometimes - including always when run from the debugger -
> but usually failed. Eventually I found that the order of {{IndexCreator}}
> instances returned from the Plexus container mattered: if {{min}} preceded
> {{maven-plugin}} then the test passed, whereas if {{min}} followed
> {{maven-plugin}} then the test failed. Furthermore, despite
> {{META-INF/plexus/components.xml}} listing these implementations in a
> particular order (seemingly arbitrary at build time), the actual order
> returned by {{PlexusContainer.lookupList}} seemed to vary randomly from run
> to run.
> The problem may have to do with
> {{MinimalArtifactInfoIndexCreator.updateLegacyDocument}}, which does
> something with {{PLUGIN_PREFIX}} and {{PLUGIN_GOALS}} for reasons unclear to
> me. When the creators were in the "wrong" order,
> http://code.google.com/p/luke/ confirmed that {{px}} and {{gx}} fields were
> just not present.
> I can work around this issue in the NetBeans code which indexes the local
> repository, using a hardcoded list of indexers (or rather, indexer IDs) as
> {{AbstractIndexCreatorHelper}} in the Indexer test sources does. But that
> does not help for downloaded remote indices, which might have been created by
> a faulty version of Indexer - since {{NexusIndexerCli.getIndexers}} uses
> {{lookupList}} when {{--type full}} is used. This means that any queries
> about plugin prefixes or goals may return results only for plugins which
> happen to have been downloaded locally. Indeed this is exactly what seems to
> happen when I try it, i.e. the Central index I am getting (via a proxy in
> Nexus 1.9.1.1) has no {{PLUGIN_*}} fields.
> The less desirable workaround would be to run a search on
> {{ArtifactInfo.PACKAGING="maven-plugin"}}, and for each hit, download the
> actual JAR and parse {{plugin.xml}} myself.
> I am not sure whether the position of
> {{MavenArchetypeArtifactInfoIndexCreator}} also matters, but it seems
> plausible, since it overrides a field normally stored in
> {{MinimalArtifactInfoIndexCreator}}.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (MINDEXER-35) Make Indexer index classes in WAR too
[ https://jira.codehaus.org/browse/MINDEXER-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MINDEXER-35 started by Tamás Cservenák. > Make Indexer index classes in WAR too > - > > Key: MINDEXER-35 > URL: https://jira.codehaus.org/browse/MINDEXER-35 > Project: Maven Indexer > Issue Type: Improvement >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák > Fix For: 4.1.2 > > > Make Indexer index classes in WAR too. > Currently, Indexer "cranks up and index" JARs only, while WARs may contain > classes too -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-629) parsing server path starting with digit
[ https://jira.codehaus.org/browse/SCM-629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276238#comment-276238 ] Dennis Lundberg commented on SCM-629: - I still say that it is an invalid scm URL. At least in the Maven SCM sense of it. > parsing server path starting with digit > --- > > Key: SCM-629 > URL: https://jira.codehaus.org/browse/SCM-629 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.5 >Reporter: Xavier Jodoin >Assignee: Mark Struberg > Attachments: Capture.png, fix_repoPath_with_digit.patch > > > scm:git:g...@github.com:360-Innovations/FJPAQuery.git > it will get 360 as the server port -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MINDEXER-35) Make Indexer index classes in WAR too
[ https://jira.codehaus.org/browse/MINDEXER-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276242#comment-276242 ] Tamás Cservenák commented on MINDEXER-35: - Fixed in rev1158770 http://svn.apache.org/viewvc?view=revision&revision=1158770 > Make Indexer index classes in WAR too > - > > Key: MINDEXER-35 > URL: https://jira.codehaus.org/browse/MINDEXER-35 > Project: Maven Indexer > Issue Type: Improvement >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák > Fix For: 4.1.2 > > > Make Indexer index classes in WAR too. > Currently, Indexer "cranks up and index" JARs only, while WARs may contain > classes too -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MINDEXER-35) Make Indexer index classes in WAR too
[ https://jira.codehaus.org/browse/MINDEXER-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák closed MINDEXER-35. --- Resolution: Fixed > Make Indexer index classes in WAR too > - > > Key: MINDEXER-35 > URL: https://jira.codehaus.org/browse/MINDEXER-35 > Project: Maven Indexer > Issue Type: Improvement >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák > Fix For: 4.1.2 > > > Make Indexer index classes in WAR too. > Currently, Indexer "cranks up and index" JARs only, while WARs may contain > classes too -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MINDEXER-36) Add some OSGI metadata in the index to be able to search on
[ https://jira.codehaus.org/browse/MINDEXER-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák reopened MINDEXER-36: - Please update the field names in OSGIArtifactIndexCreatorTest and then close this issue, to mark a "go" for a 4.1.2 relase ;) > Add some OSGI metadata in the index to be able to search on > --- > > Key: MINDEXER-36 > URL: https://jira.codehaus.org/browse/MINDEXER-36 > Project: Maven Indexer > Issue Type: New Feature >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 4.1.2 > > > Index at least : > * Bundle-SymbolicName > * Bundle-Version > * Export-Package > * Export-Service > Others OSGI metadata ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MINDEXER-34) Order of IndexCreator's passed to addIndexingContextForced affects whether MavenPluginArtifactInfoIndexCreator has any effect
[
https://jira.codehaus.org/browse/MINDEXER-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák closed MINDEXER-34.
---
Resolution: Fixed
> Order of IndexCreator's passed to addIndexingContextForced affects whether
> MavenPluginArtifactInfoIndexCreator has any effect
> -
>
> Key: MINDEXER-34
> URL: https://jira.codehaus.org/browse/MINDEXER-34
> Project: Maven Indexer
> Issue Type: Bug
>Affects Versions: 4.1.0
> Environment: JDK 6, Ubuntu, Maven 3.0.3; actually Indexer 4.1.1 but
> that is not listed as an option here
>Reporter: Jesse Glick
>Assignee: Tamás Cservenák
>Priority: Critical
> Fix For: 4.1.2
>
>
> While working on a utility inside NetBeans to look up all plugins using a
> given goal prefix, I found unreliable behavior. To investigate, I wrote a
> unit test that used Maven Indexer (along with some NB helper classes) that:
> 1. Creates a fresh local repository.
> 2. Installs a trivial "plugin" ({{maven-plugin}} POM + JAR) with just a
> {{META-INF/maven/plugin.xml}} containing
> {{stuff}}.
> 3. Indexes the repository, using all available {{IndexCreator}} instances.
> 4. Runs a search like {{ArtifactInfo.PLUGIN_PREFIX="stuff"}} and checks that
> there is one hit.
> This test passed sometimes - including always when run from the debugger -
> but usually failed. Eventually I found that the order of {{IndexCreator}}
> instances returned from the Plexus container mattered: if {{min}} preceded
> {{maven-plugin}} then the test passed, whereas if {{min}} followed
> {{maven-plugin}} then the test failed. Furthermore, despite
> {{META-INF/plexus/components.xml}} listing these implementations in a
> particular order (seemingly arbitrary at build time), the actual order
> returned by {{PlexusContainer.lookupList}} seemed to vary randomly from run
> to run.
> The problem may have to do with
> {{MinimalArtifactInfoIndexCreator.updateLegacyDocument}}, which does
> something with {{PLUGIN_PREFIX}} and {{PLUGIN_GOALS}} for reasons unclear to
> me. When the creators were in the "wrong" order,
> http://code.google.com/p/luke/ confirmed that {{px}} and {{gx}} fields were
> just not present.
> I can work around this issue in the NetBeans code which indexes the local
> repository, using a hardcoded list of indexers (or rather, indexer IDs) as
> {{AbstractIndexCreatorHelper}} in the Indexer test sources does. But that
> does not help for downloaded remote indices, which might have been created by
> a faulty version of Indexer - since {{NexusIndexerCli.getIndexers}} uses
> {{lookupList}} when {{--type full}} is used. This means that any queries
> about plugin prefixes or goals may return results only for plugins which
> happen to have been downloaded locally. Indeed this is exactly what seems to
> happen when I try it, i.e. the Central index I am getting (via a proxy in
> Nexus 1.9.1.1) has no {{PLUGIN_*}} fields.
> The less desirable workaround would be to run a search on
> {{ArtifactInfo.PACKAGING="maven-plugin"}}, and for each hit, download the
> actual JAR and parse {{plugin.xml}} myself.
> I am not sure whether the position of
> {{MavenArchetypeArtifactInfoIndexCreator}} also matters, but it seems
> plausible, since it overrides a field normally stored in
> {{MinimalArtifactInfoIndexCreator}}.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (WAGON-345) [PATCH] Migration from obsolete plexus-maven-plugin to plexus-containers-component-metadata
[PATCH] Migration from obsolete plexus-maven-plugin to plexus-containers-component-metadata --- Key: WAGON-345 URL: https://jira.codehaus.org/browse/WAGON-345 Project: Maven Wagon Issue Type: Improvement Affects Versions: 1.0 Reporter: Jaromír Cápík Attachments: maven-wagon-migration-to-component-metadata.patch The attached patch retires the obsolete plexus-maven-plugin and generates the metadata with plexus-containers-component-metadata instead. NOTE : The result XML file has a different order of elements, but all of them are present. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-703) [PATCH] Migration from obsolete plexus-maven-plugin to plexus-containers-component-metadata
[PATCH] Migration from obsolete plexus-maven-plugin to plexus-containers-component-metadata --- Key: MRELEASE-703 URL: https://jira.codehaus.org/browse/MRELEASE-703 Project: Maven 2.x Release Plugin Issue Type: Improvement Affects Versions: 2.0 Reporter: Jaromír Cápík Attachments: 004_mavenreleaseplugin_componentmetadata.patch The attached patch retires the obsolete plexus-maven-plugin and generates the metadata with plexus-containers-component-metadata instead. NOTE : The result XML file has a different order of elements, but all of them are present. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-606) Site plugin spuriously appends extra directory to breadcrumb URL in some cases
Site plugin spuriously appends extra directory to breadcrumb URL in some cases -- Key: MSITE-606 URL: https://jira.codehaus.org/browse/MSITE-606 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: relative links Affects Versions: 2.2 Reporter: Benson Margulies Attachments: site-breadcrumb-surprise-2.2.tar If the an apparently absolute URL in a breadcrumb happens to overlap with the element in the POM, the site plugin will append the an extra level of directory on the end. In the attached case, the string '/project' gets appended an extra time. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-606) Site plugin spuriously appends extra directory to breadcrumb URL in some cases
[ https://jira.codehaus.org/browse/MSITE-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276249#comment-276249 ] Benson Margulies commented on MSITE-606: This is fixed in 3.0, so it might be that I just did this for the record in case someone else runs into it. > Site plugin spuriously appends extra directory to breadcrumb URL in some cases > -- > > Key: MSITE-606 > URL: https://jira.codehaus.org/browse/MSITE-606 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: relative links >Affects Versions: 2.2 >Reporter: Benson Margulies > Fix For: 3.0 > > Attachments: site-breadcrumb-surprise-2.2.tar > > > If the an apparently absolute URL in a breadcrumb happens to overlap with the > element in the POM, the site plugin will append the an extra level of > directory on the end. In the attached case, the string '/project' gets > appended an extra time. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-606) Site plugin spuriously appends extra directory to breadcrumb URL in some cases
[ https://jira.codehaus.org/browse/MSITE-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MSITE-606. -- Resolution: Fixed Fix Version/s: 3.0 > Site plugin spuriously appends extra directory to breadcrumb URL in some cases > -- > > Key: MSITE-606 > URL: https://jira.codehaus.org/browse/MSITE-606 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: relative links >Affects Versions: 2.2 >Reporter: Benson Margulies > Fix For: 3.0 > > Attachments: site-breadcrumb-surprise-2.2.tar > > > If the an apparently absolute URL in a breadcrumb happens to overlap with the > element in the POM, the site plugin will append the an extra level of > directory on the end. In the attached case, the string '/project' gets > appended an extra time. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-607) no documentation for breadcrumbs in the doc of site.xml
no documentation for breadcrumbs in the doc of site.xml --- Key: MSITE-607 URL: https://jira.codehaus.org/browse/MSITE-607 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: documentation Affects Versions: 3.0 Reporter: Benson Margulies Some information from http://www.sonatype.com/books/mvnref-book/reference/site-generation-sect-tips-tricks.html#site-generation-add-breadcumbs should be on http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MINDEXER-36) Add some OSGI metadata in the index to be able to search on
[ https://jira.codehaus.org/browse/MINDEXER-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276252#comment-276252 ] Tamás Cservenák commented on MINDEXER-36: - IMO, the most useful searches would be: * Import-Package (example use case: "I want to see what bundles uses a certain package") * Bundle-SymbolicName (example use case: "I know the bundle I want") * Require-Bundle (example use case: "I want to see what bundles uses a certain bundle") * Export-Package (example use case: "I know only the package I need") And IMO, the Export-Service is deprecated. As for returned (index contained) information, the adding these too would be nice: * Bundle-Description (similar to MAVEN.DESCRIPTION) * Bundle-Name (similar to MAVEN.NAME) etc. > Add some OSGI metadata in the index to be able to search on > --- > > Key: MINDEXER-36 > URL: https://jira.codehaus.org/browse/MINDEXER-36 > Project: Maven Indexer > Issue Type: New Feature >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 4.1.2 > > > Index at least : > * Bundle-SymbolicName > * Bundle-Version > * Export-Package > * Export-Service > Others OSGI metadata ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MINDEXER-36) Add some OSGI metadata in the index to be able to search on
[ https://jira.codehaus.org/browse/MINDEXER-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276252#comment-276252 ] Tamás Cservenák edited comment on MINDEXER-36 at 8/17/11 12:26 PM: --- IMO, the most useful searches would be: * Import-Package (example use case: "I want to see what bundles uses a certain package") * Bundle-SymbolicName (example use case: "I know the bundle I want") * Require-Bundle (example use case: "I want to see what bundles uses a certain bundle") * Export-Package (example use case: "I know only the package I need") And AFAIK, the Export-Service is deprecated. As for returned (index contained) information, the adding these too would be nice: * Bundle-Description (similar to MAVEN.DESCRIPTION) * Bundle-Name (similar to MAVEN.NAME) etc. was (Author: cstamas): IMO, the most useful searches would be: * Import-Package (example use case: "I want to see what bundles uses a certain package") * Bundle-SymbolicName (example use case: "I know the bundle I want") * Require-Bundle (example use case: "I want to see what bundles uses a certain bundle") * Export-Package (example use case: "I know only the package I need") And IMO, the Export-Service is deprecated. As for returned (index contained) information, the adding these too would be nice: * Bundle-Description (similar to MAVEN.DESCRIPTION) * Bundle-Name (similar to MAVEN.NAME) etc. > Add some OSGI metadata in the index to be able to search on > --- > > Key: MINDEXER-36 > URL: https://jira.codehaus.org/browse/MINDEXER-36 > Project: Maven Indexer > Issue Type: New Feature >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 4.1.2 > > > Index at least : > * Bundle-SymbolicName > * Bundle-Version > * Export-Package > * Export-Service > Others OSGI metadata ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MINDEXER-36) Add some OSGI metadata in the index to be able to search on
[ https://jira.codehaus.org/browse/MINDEXER-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276254#comment-276254 ] Olivier Lamy commented on MINDEXER-36: -- sure I know Export-Service is deprecated but it's used (IMHO) a lot. So as all deprecated stuff, this field will probably live long time :-) > Add some OSGI metadata in the index to be able to search on > --- > > Key: MINDEXER-36 > URL: https://jira.codehaus.org/browse/MINDEXER-36 > Project: Maven Indexer > Issue Type: New Feature >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 4.1.2 > > > Index at least : > * Bundle-SymbolicName > * Bundle-Version > * Export-Package > * Export-Service > Others OSGI metadata ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MSITE-606) Site plugin spuriously appends extra directory to breadcrumb URL in some cases
[ https://jira.codehaus.org/browse/MSITE-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies reopened MSITE-606: > Site plugin spuriously appends extra directory to breadcrumb URL in some cases > -- > > Key: MSITE-606 > URL: https://jira.codehaus.org/browse/MSITE-606 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: relative links >Affects Versions: 2.2 >Reporter: Benson Margulies > Fix For: 3.0 > > Attachments: site-breadcrumb-surprise-2.2.tar > > > If the an apparently absolute URL in a breadcrumb happens to overlap with the > element in the POM, the site plugin will append the an extra level of > directory on the end. In the attached case, the string '/project' gets > appended an extra time. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-606) Site plugin spuriously appends extra directory to breadcrumb URL in some cases
[ https://jira.codehaus.org/browse/MSITE-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MSITE-606. -- Resolution: Fixed Arggh. reason to reopen was pilot error. > Site plugin spuriously appends extra directory to breadcrumb URL in some cases > -- > > Key: MSITE-606 > URL: https://jira.codehaus.org/browse/MSITE-606 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: relative links >Affects Versions: 2.2 >Reporter: Benson Margulies > Fix For: 3.0 > > Attachments: site-breadcrumb-surprise-2.2.tar > > > If the an apparently absolute URL in a breadcrumb happens to overlap with the > element in the POM, the site plugin will append the an extra level of > directory on the end. In the attached case, the string '/project' gets > appended an extra time. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MINDEXER-36) Add some OSGI metadata in the index to be able to search on
[ https://jira.codehaus.org/browse/MINDEXER-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276262#comment-276262 ] Olivier Lamy commented on MINDEXER-36: -- rev 1158871. Support added for : * Bundle-Description * Bundle-Name * Bundle-License * Bundle-DocURL * Import-Package > Add some OSGI metadata in the index to be able to search on > --- > > Key: MINDEXER-36 > URL: https://jira.codehaus.org/browse/MINDEXER-36 > Project: Maven Indexer > Issue Type: New Feature >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 4.1.2 > > > Index at least : > * Bundle-SymbolicName > * Bundle-Version > * Export-Package > * Export-Service > Others OSGI metadata ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-378) Remove the parameter goalPrefix (and corresponding code) from the archetype:add-archetype-metadata mojo
[
https://jira.codehaus.org/browse/ARCHETYPE-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276270#comment-276270
]
Herve Boutemy commented on ARCHETYPE-378:
-
after some discussion and research, here are my results:
- plugin mapping does not have any meaning for an archetype
- LATEST update isn't used since for a long time, archetypes were packages as
jar packaging, which does not update LATEST without any problem: maven-arhetype
packaging is here only for integration-tests and update-local-catalog
definitely, removing this mojo won't remove any functionality, only unneeded
copy/paste
I'm going to remove the mojo
> Remove the parameter goalPrefix (and corresponding code) from the
> archetype:add-archetype-metadata mojo
> ---
>
> Key: ARCHETYPE-378
> URL: https://jira.codehaus.org/browse/ARCHETYPE-378
> Project: Maven Archetype
> Issue Type: Task
> Components: Plugin
>Affects Versions: 2.0
>Reporter: Benjamin Bentmann
>Assignee: Olivier Lamy
>Priority: Trivial
> Fix For: 2.1
>
>
> As questioned in [Archtypes and plugin
> prefix|http://www.mail-archive.com/dev@maven.apache.org/msg89617.html], it
> appears the parameter {{goalName}} of the {{add-archetype-metadata}} mojo
> exists merely due to copy&paste but has no real use in the context of
> archetypes. As such the parameter and its backing code should be removed to
> reduce confusion for end users and to keep the group-level metadata free from
> bogus plugin prefix mappings for archetypes.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (ARCHETYPE-378) Remove the parameter goalPrefix (and corresponding code) from the archetype:add-archetype-metadata mojo
[
https://jira.codehaus.org/browse/ARCHETYPE-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed ARCHETYPE-378.
---
Resolution: Fixed
Assignee: Herve Boutemy (was: Olivier Lamy)
done in [r1158911|http://svn.apache.org/viewvc?rev=1158911&view=rev]
> Remove the parameter goalPrefix (and corresponding code) from the
> archetype:add-archetype-metadata mojo
> ---
>
> Key: ARCHETYPE-378
> URL: https://jira.codehaus.org/browse/ARCHETYPE-378
> Project: Maven Archetype
> Issue Type: Task
> Components: Plugin
>Affects Versions: 2.0
>Reporter: Benjamin Bentmann
>Assignee: Herve Boutemy
>Priority: Trivial
> Fix For: 2.1
>
>
> As questioned in [Archtypes and plugin
> prefix|http://www.mail-archive.com/dev@maven.apache.org/msg89617.html], it
> appears the parameter {{goalName}} of the {{add-archetype-metadata}} mojo
> exists merely due to copy&paste but has no real use in the context of
> archetypes. As such the parameter and its backing code should be removed to
> reduce confusion for end users and to keep the group-level metadata free from
> bogus plugin prefix mappings for archetypes.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MINDEXER-38) searchFlat can return empty results with multiple index if the first used returns empty result
searchFlat can return empty results with multiple index if the first used returns empty result -- Key: MINDEXER-38 URL: https://jira.codehaus.org/browse/MINDEXER-38 Project: Maven Indexer Issue Type: Bug Reporter: Olivier Lamy -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MINDEXER-38) searchFlat can return empty results with multiple index if the first used returns empty result
[ https://jira.codehaus.org/browse/MINDEXER-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MINDEXER-38: - Assignee: Olivier Lamy > searchFlat can return empty results with multiple index if the first used > returns empty result > -- > > Key: MINDEXER-38 > URL: https://jira.codehaus.org/browse/MINDEXER-38 > Project: Maven Indexer > Issue Type: Bug >Affects Versions: 4.1.1 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 4.1.2 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MINDEXER-38) searchFlat can return empty results with multiple index if the first used returns empty result
[ https://jira.codehaus.org/browse/MINDEXER-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MINDEXER-38: - Affects Version/s: 4.1.1 Fix Version/s: 4.1.2 > searchFlat can return empty results with multiple index if the first used > returns empty result > -- > > Key: MINDEXER-38 > URL: https://jira.codehaus.org/browse/MINDEXER-38 > Project: Maven Indexer > Issue Type: Bug >Affects Versions: 4.1.1 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 4.1.2 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-366) Maven mirror consulted after, rather than instead of, archetypeRepository URL
[
https://jira.codehaus.org/browse/ARCHETYPE-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276273#comment-276273
]
Herve Boutemy commented on ARCHETYPE-366:
-
I'm uneasy with this patch
I understand that it fixes your precise test case (with so few code change)
but I'm not sure it is ok for every other use case: not using the url
explicitely defined in the CLI as a first choice seems strange
I don't have a precise real-world use case where this order would be used to do
something useful, but I'm careful when it comes to such change
In fact, when I look at repository use in archetype plugin, it seems that not
defining an id is a problem (or using archetype-artifactId-repo isn't really
great)
but adding id support for repositories is a non-trivial task...
> Maven mirror consulted after, rather than instead of, archetypeRepository URL
> -
>
> Key: ARCHETYPE-366
> URL: https://jira.codehaus.org/browse/ARCHETYPE-366
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator
>Affects Versions: 2.0
> Environment: Ubuntu 10.04, JDK 6.
>Reporter: Jesse Glick
>Priority: Minor
> Attachments: ARCHETYPE-366.diff
>
>
> I have a local Nexus instance running, with a mirror of Central, and in
> {{settings.xml}}:
> {noformat}
>
> central
> central
> .../content/repositories/central/
>
> {noformat}
> This works fine for normal Maven operations. However, {{archetype:generate}}
> tries to download from the public repo _first_. So when I am online, after
> typing this:
> {noformat}
> rm -rf ~/.m2/repository/org/codehaus/mojo/archetypes test
> mvn -DarchetypeVersion=1.2 -Darchetype.interactive=false -DgroupId=test
> -DarchetypeArtifactId=osgi-archetype
> -DarchetypeRepository=http://repo1.maven.org/maven2/ -Dversion=1.0-SNAPSHOT
> -DarchetypeGroupId=org.codehaus.mojo.archetypes -Dbasedir=/tmp -Dpackage=test
> -DartifactId=test --batch-mode archetype:generate
> {noformat}
> I see:
> {noformat}
> [INFO] Archetype defined by properties
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> Downloaded:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> (4 KB at 8.7 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> Downloaded:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> (947 B at 8.3 KB/sec)
> {noformat}
> with no mention of Nexus; when I am offline:
> {noformat}
> [INFO] Archetype defined by properties
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> Downloading:
> http://localhost:6969/nexus/content/repositories/central/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> Downloaded:
> http://localhost:6969/nexus/content/repositories/central/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> (4 KB at 128.8 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> Downloading:
> http://localhost:6969/nexus/content/repositories/central/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> Downloaded:
> http://localhost:6969/nexus/content/repositories/central/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> (947 B at 57.8 KB/sec)
> {noformat}
> once this resource is cached in the Nexus mirror repo. (Since the online
> command does not ask Nexus, it normally is _not_ cached there and offline
> project creation simply fails; to force Nexus to cache it, I need to ask
> Maven to download it as a dep of something.)
> If I do not specify an explicit {{archetypeRepository}} then I get
> {noformat}
> [INFO] Archetype repository missing. Using the one from
> [org.codehaus.mojo.archetypes:osgi-archetype:1.2] found in catalog remote
> {noformat}
> and Nexus is consulted first, but this parameter is needed as a workaround
> for ARCHETYPE-344.
> One complicating factor with this example is that the 1.2 release of the
> archetype does not seem to be present in the Central index; I have no clue
> why. (It was released on February 15, i.e. more than three weeks ago, and my
> understanding is that the index is rebuilt weekly.) May not have anything to
> do with this bug, though.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MINDEXER-38) searchFlat can return empty results with multiple index if the first used returns empty result
[ https://jira.codehaus.org/browse/MINDEXER-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MINDEXER-38. Resolution: Fixed fixed [rev 1158917|http://svn.apache.org/viewvc?rev=1158917&view=rev] > searchFlat can return empty results with multiple index if the first used > returns empty result > -- > > Key: MINDEXER-38 > URL: https://jira.codehaus.org/browse/MINDEXER-38 > Project: Maven Indexer > Issue Type: Bug >Affects Versions: 4.1.1 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 4.1.2 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MINDEXER-36) Add some OSGI metadata in the index to be able to search on
[
https://jira.codehaus.org/browse/MINDEXER-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276279#comment-276279
]
Jesse Glick commented on MINDEXER-36:
-
Spelling oddities which become visible in the public API:
{{OSGIArtifactIndexCreator}} should perhaps be {{OSGiArtifactIndexCreator}}
(ditto {{OSGI}} and various identifiers used in the test); {{osgi-metadatas}}
should be {{osgi-metadata}}.
> Add some OSGI metadata in the index to be able to search on
> ---
>
> Key: MINDEXER-36
> URL: https://jira.codehaus.org/browse/MINDEXER-36
> Project: Maven Indexer
> Issue Type: New Feature
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
> Fix For: 4.1.2
>
>
> Index at least :
> * Bundle-SymbolicName
> * Bundle-Version
> * Export-Package
> * Export-Service
> Others OSGI metadata ?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MINDEXER-36) Add some OSGI metadata in the index to be able to search on
[
https://jira.codehaus.org/browse/MINDEXER-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276280#comment-276280
]
Jesse Glick commented on MINDEXER-36:
-
By the way, {{JarFileContentsIndexCreator}} could be updated to interpret
{{Bundle-Classpath}} if specified. Not sure how commonly this is used.
> Add some OSGI metadata in the index to be able to search on
> ---
>
> Key: MINDEXER-36
> URL: https://jira.codehaus.org/browse/MINDEXER-36
> Project: Maven Indexer
> Issue Type: New Feature
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
> Fix For: 4.1.2
>
>
> Index at least :
> * Bundle-SymbolicName
> * Bundle-Version
> * Export-Package
> * Export-Service
> Others OSGI metadata ?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MINDEXER-36) Add some OSGI metadata in the index to be able to search on
[ https://jira.codehaus.org/browse/MINDEXER-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276282#comment-276282 ] Olivier Lamy commented on MINDEXER-36: -- Not sure searching on Bundle-Classpath will help maybe for read. Can you elaborate on the ditto for test ? Ditto someone complains because tests exists :P > Add some OSGI metadata in the index to be able to search on > --- > > Key: MINDEXER-36 > URL: https://jira.codehaus.org/browse/MINDEXER-36 > Project: Maven Indexer > Issue Type: New Feature >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 4.1.2 > > > Index at least : > * Bundle-SymbolicName > * Bundle-Version > * Export-Package > * Export-Service > Others OSGI metadata ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-366) Maven mirror consulted after, rather than instead of, archetypeRepository URL
[
https://jira.codehaus.org/browse/ARCHETYPE-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276291#comment-276291
]
Jesse Glick commented on ARCHETYPE-366:
---
Right, the generated {{-repo}} ID is part of the root problem. The better
solution would be for the mojo to accept an ID rather than a URL, which
probably requires a new parameter name, e.g.
{{-DarchetypeRepositoryId=central}}. Oddly, {{-DarchetypeRepository=local}}
already works.
> Maven mirror consulted after, rather than instead of, archetypeRepository URL
> -
>
> Key: ARCHETYPE-366
> URL: https://jira.codehaus.org/browse/ARCHETYPE-366
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator
>Affects Versions: 2.0
> Environment: Ubuntu 10.04, JDK 6.
>Reporter: Jesse Glick
>Priority: Minor
> Attachments: ARCHETYPE-366.diff
>
>
> I have a local Nexus instance running, with a mirror of Central, and in
> {{settings.xml}}:
> {noformat}
>
> central
> central
> .../content/repositories/central/
>
> {noformat}
> This works fine for normal Maven operations. However, {{archetype:generate}}
> tries to download from the public repo _first_. So when I am online, after
> typing this:
> {noformat}
> rm -rf ~/.m2/repository/org/codehaus/mojo/archetypes test
> mvn -DarchetypeVersion=1.2 -Darchetype.interactive=false -DgroupId=test
> -DarchetypeArtifactId=osgi-archetype
> -DarchetypeRepository=http://repo1.maven.org/maven2/ -Dversion=1.0-SNAPSHOT
> -DarchetypeGroupId=org.codehaus.mojo.archetypes -Dbasedir=/tmp -Dpackage=test
> -DartifactId=test --batch-mode archetype:generate
> {noformat}
> I see:
> {noformat}
> [INFO] Archetype defined by properties
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> Downloaded:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> (4 KB at 8.7 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> Downloaded:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> (947 B at 8.3 KB/sec)
> {noformat}
> with no mention of Nexus; when I am offline:
> {noformat}
> [INFO] Archetype defined by properties
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> Downloading:
> http://localhost:6969/nexus/content/repositories/central/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> Downloaded:
> http://localhost:6969/nexus/content/repositories/central/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> (4 KB at 128.8 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> Downloading:
> http://localhost:6969/nexus/content/repositories/central/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> Downloaded:
> http://localhost:6969/nexus/content/repositories/central/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> (947 B at 57.8 KB/sec)
> {noformat}
> once this resource is cached in the Nexus mirror repo. (Since the online
> command does not ask Nexus, it normally is _not_ cached there and offline
> project creation simply fails; to force Nexus to cache it, I need to ask
> Maven to download it as a dep of something.)
> If I do not specify an explicit {{archetypeRepository}} then I get
> {noformat}
> [INFO] Archetype repository missing. Using the one from
> [org.codehaus.mojo.archetypes:osgi-archetype:1.2] found in catalog remote
> {noformat}
> and Nexus is consulted first, but this parameter is needed as a workaround
> for ARCHETYPE-344.
> One complicating factor with this example is that the 1.2 release of the
> archetype does not seem to be present in the Central index; I have no clue
> why. (It was released on February 15, i.e. more than three weeks ago, and my
> understanding is that the index is rebuilt weekly.) May not have anything to
> do with this bug, though.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MINDEXER-36) Add some OSGI metadata in the index to be able to search on
[
https://jira.codehaus.org/browse/MINDEXER-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276294#comment-276294
]
Jesse Glick commented on MINDEXER-36:
-
Regarding {{Bundle-Classpath}} - if I was not clear, I meant that when this is
specified, {{JarFileContentsIndexCreator}} should search for {{**/*.class}} in
the specified classpath entries instead of in the general JAR root. Normally
{{.}} is an entry, meaning that classes in the bundle JAR are still searched,
but this would allow the index of contained classes to list those in nested
JARs.
For test-related identifiers, this is pretty trivial but:
{{OSGIArtifactIndexCreatorTest}}, {{indexOSGIRepo}},
{{testIndexOSGIRepoThen...}}.
> Add some OSGI metadata in the index to be able to search on
> ---
>
> Key: MINDEXER-36
> URL: https://jira.codehaus.org/browse/MINDEXER-36
> Project: Maven Indexer
> Issue Type: New Feature
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
> Fix For: 4.1.2
>
>
> Index at least :
> * Bundle-SymbolicName
> * Bundle-Version
> * Export-Package
> * Export-Service
> Others OSGI metadata ?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCHANGELOG-123) Patch with support for SCM provider implementations (similar to release plugin)
Patch with support for SCM provider implementations (similar to release plugin)
---
Key: MCHANGELOG-123
URL: https://jira.codehaus.org/browse/MCHANGELOG-123
Project: Maven 2.x Changelog Plugin
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Alex Coyle
Attachments: maven-changelog-plugin-scmproviderimpl.patch
Hi,
The attached patch includes support for SCM 'provider implementations', similar
to what is included in the Maven Release Plugin. I made this change because I
wanted to use the Changelog plugin with the maven-scm-provider-svnjava project
(an SVN provider that uses SVNkit):
http://code.google.com/a/apache-extras.org/p/maven-scm-provider-svnjava/
I can confirm the patch works, and appears to generate a valid changelog report
in the Maven site, when used with Maven 3.0.3 and a Maven project that follows
this example POM structure:
{noformat}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
uk.co.example
example-project
pom
1.0.0-SNAPSHOT
Example Project
http://example.co.uk/example-project
scm:svn:http://svn.example.co.uk/example-project/trunk
scm:svn:http://svn.example.co.uk/example-project/trunk
org.apache.maven.plugins
maven-changelog-plugin
2.3-SNAPSHOT
com.google.code.maven-scm-provider-svnjava
maven-scm-provider-svnjava
1.13
maven-site-plugin
3.0-beta-3
org.apache.maven.plugins
maven-changelog-plugin
[A-Z]{2,}-\d+
http://jira.example.co.uk
javasvn
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MANTRUN-167) Maven Plugin Doesn't allow me to SETUP JDK 1.4.2 Version
[
https://jira.codehaus.org/browse/MANTRUN-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276313#comment-276313
]
daivish shah commented on MANTRUN-167:
--
Is anybody have idea on this ?
I am struggling to setup maven-antrun-plugin compiler as JDK 1.4.2 version.
Please let me know if anybody has idea on this.
Thanks,
daivish.
> Maven Plugin Doesn't allow me to SETUP JDK 1.4.2 Version
>
>
> Key: MANTRUN-167
> URL: https://jira.codehaus.org/browse/MANTRUN-167
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.6
> Environment: Windows
>Reporter: daivish shah
>
> Hi,
> I am using MAVEN 2.2.1 version and trying to compile my classes from ANT
> script.
> I want to compile my classes with JDK 1.4.2 version. How can i do it ?
> Following one is my entry which i am using EVEN i am setting up rt.jar and
> tools.jar with JDK 1.4.2 in my build.xml file still my Eclipse is referring
> JDK 1.5 version only.
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.6
>
>
> install
> install
>
> run
>
>
>
> ${java-version}
>
> ${java-version}
>
>antfile="WPSEjb_build.xml" />
>
>
>
>
>
>
> sun.jdk
> tools
> 1.4.2
> system
>
> ${java.home}/lib/tools.jar
>
>
>
>
> Please advice me which property is available in maven-antrun-plugin so i can
> set that and my compiler use JDK 1.4.2 version ?
> I am really stuck here. I am looking for your reply.
> Thanks,
> daivish..
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIASITETOOLS-51) site.xml parameter and template variables not documented
[ https://jira.codehaus.org/browse/DOXIASITETOOLS-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276314#comment-276314 ] Herve Boutemy commented on DOXIASITETOOLS-51: - FYI, link to [2] reworded in [r1157576|http://svn.apache.org/viewvc?rev=1157576&view=rev] > site.xml parameter and template variables not documented > - > > Key: DOXIASITETOOLS-51 > URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-51 > Project: Maven Doxia Sitetools > Issue Type: Bug >Reporter: SebbASF > > There's no proper documentation on the Maven site descriptor "custom" tag. > It's not mentioned in the main documentation [1], and is only mentioned in > passing in [2] - which in turn is not referenced from [1] > Here are the full details from [2]: > customDOM Custom configuration for use with customized > Velocity templates > The DOM reference above appears to be an instance of Xpp3Dom [3]. > Also, the Doxia code sets various context variables (in DefaultSiteRenderer > ?). > This should all be documented, along with some simple examples, and > referenced as necessary from the Maven site plugin documentation > [1] > http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html > [2] > http://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/decoration.html > [3] > http://plexus.codehaus.org/plexus-utils/apidocs/org/codehaus/plexus/util/xml/Xpp3Dom.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DOXIASITETOOLS-62) improve breadcrumbs inheritance: if child defines an item already in parent, remove every breadcrumb item from parent after it
improve breadcrumbs inheritance: if child defines an item already in parent, remove every breadcrumb item from parent after it -- Key: DOXIASITETOOLS-62 URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-62 Project: Maven Doxia Sitetools Issue Type: Improvement Components: Decoration model Affects Versions: 1.2 Reporter: Herve Boutemy see MSITE-582 suppose parent descriptor has following breacrumb items: A > B > C > D > E > F I want a child to remove D > E > F and replace with M > N > O A > B > C > M > N > O To do that, that child should define C > M > N > O C is found in parent breadcrumb items, then we can delete the following parent items then add following child items -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-608) aggregating breadcrumb behavior disappears in the presence of a menu in the parent
aggregating breadcrumb behavior disappears in the presence of a menu in the
parent
--
Key: MSITE-608
URL: https://jira.codehaus.org/browse/MSITE-608
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: multi module
Affects Versions: 3.0
Reporter: Benson Margulies
Attachments: site-breadcrumb-inheritance.jar
This may turn out to belong in Doxia. I don't know.
The attached project consists of an aggregating project and its module. The
breadcrumbs in the module are, I claim, wrong -- they lack the breadcrumb to
visit the parent.
If you remove this menu:
{code}
{code}
from the parent's src/site/site.xml, all is well. Once it's here, the
parent-level breadcrumb is omitted.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-608) aggregating breadcrumb behavior disappears in the presence of a menu in the parent
[
https://jira.codehaus.org/browse/MSITE-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276316#comment-276316
]
Herve Boutemy commented on MSITE-608:
-
I just tested your project, and I don't understand: I don't see any difference
when the menu is defined or not (which honestly is a Good Thing: a menu should
not have any impact on breadcrumbs).
The child breadcrumbs are always: Maven > Breadcrumb TC Module > About
And they are not wrong: if they lack a breadcrumb to visit the parent, it's not
a bug, it's a feature :)
The feature is: when a descriptor defines explicitely some breadcrumb item, no
automatic breadcrumb item is added
I found it reading the inheritance code, and it's IMHO logical since it permits
you to override automatic breadcrumbs with whatever you want (choose name and
href)
[Decoration Model
documentation|http://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/]
needs improvement to explain inheritance
I'll work on it when working on DOXIASITETOOLS-62, since inheritance algorithm
will become more flexible, then absolutely needs clear documentation
but before that, if you're able to start something, that would be great
> aggregating breadcrumb behavior disappears in the presence of a menu in the
> parent
> --
>
> Key: MSITE-608
> URL: https://jira.codehaus.org/browse/MSITE-608
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 3.0
>Reporter: Benson Margulies
> Attachments: site-breadcrumb-inheritance.jar
>
>
> This may turn out to belong in Doxia. I don't know.
> The attached project consists of an aggregating project and its module. The
> breadcrumbs in the module are, I claim, wrong -- they lack the breadcrumb to
> visit the parent.
> If you remove this menu:
> {code}
>
>
>
> {code}
> from the parent's src/site/site.xml, all is well. Once it's here, the
> parent-level breadcrumb is omitted.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-607) no documentation for breadcrumbs in the doc of site.xml
[ https://jira.codehaus.org/browse/MSITE-607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276318#comment-276318 ] Lukas Theussl commented on MSITE-607: - I think this info should go to the [Doxia Sitetools :: Decoration Model|http://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/index.html] docs and the site-plugin docs should refer to that, WDYT? > no documentation for breadcrumbs in the doc of site.xml > --- > > Key: MSITE-607 > URL: https://jira.codehaus.org/browse/MSITE-607 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: documentation >Affects Versions: 3.0 >Reporter: Benson Margulies > > Some information from > http://www.sonatype.com/books/mvnref-book/reference/site-generation-sect-tips-tricks.html#site-generation-add-breadcumbs > should be on > http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
