I have seen two different syntax in Karaf to add a repo, e.g.,
features:addurl mvn:org.apache.camel/camel-example-osgi/2.10.0/
xml/features
features:addurl mvn:org.apache.camel/camel-example-osgi/2.10.0/
xml
Can someone explain the difference between the 2? I believe they are both referring to a features file but they are in different locations?
features:addurl mvn:org.apache.camel/camel-example-osgi/2.10.0/xml
Doesn't actually work for me. BUT I think can break down what is happening.
mvn:org.apache.camel/camel-example-osgi/2.10.0 is a maven URl with an implicit 'type' and 'classifier'. The type is 'jar' and the classifier is empty, by default. Therefore it resolves to a file called camel-example-osgi-2.10.0.jar. (artifactId-version[-classifier].type)
In this case:
mvn:org.apache.camel/camel-example-osgi/2.10.0/xml is a type of 'xml' and no classifier. This resolves to a file called camel-example-osgi-2.10.0.xml, which doesn't exist.
mvn:org.apache.camel/camel-example-osgi/2.10.0/xml/features is a type of 'xml' and a classifier of 'features'. This, then, resolves to a file called camel-example-osgi-2.10.0-features.xml . We can look on the server and see that this file exists: http://repo1.maven.org/maven2/org/apache/camel/camel-example-osgi/2.10.0/
I can't find good documentation for it but 'classifier' adds the -$classifier to the filename. This is how some maven artifacts have a classifier of -jdkN and -jdkM or -jdbc4 or -jdbc3 on them.
References: https://ops4j1.jira.com/wiki/display/paxurl/Mvn+Protocol
http://maven.apache.org/pom.html#POM_Relationships
Related
I'm following Maven's Standard Directory Layout for my project.
Is there a preferred directory to put my checkstyle.xml file? I've seen it on at least 3 possible locations:
src/main/resources/checkstyle.xml
src/main/checkstyle/checkstyle.xml - Example: Joda-Time
src/checkstyle/checkstyle.xml - Example: Spring Boot
Since this is mostly a file for developers, the first option gives me doubts. Would it make sense to include checkstyle.xml into the JAR file?
Thanks,
Fede
Putting checkstyle.xml in src directory doesn't really make sense, as it is not part of source code.
The most common convention I've observed in my projects is putting it into config/checkstyle/checkstyle.xml. Thousands of projects use it (filename:checkstyle.xml path:config/checkstyle) and Gradle uses this location by default.
The result of the call to
Maven.resolver().resolve("groupId:artifactId:version").
withoutTransitivity().asSingleFile();
e.g.
Maven.resolver().resolve("myProjectGroupId:myProject:1.1")
.withoutTransitivity().asSingleFile();
results sometimes in the correct jar file with the name
artifactId-version.jar e.g. myProject-1.1.jar,
but sometimes I get a file
artifactId-unknownNumericalId.jar e.g. myProject-6244235517268120190.jar
that doesn't exist in the maven repository. I couldn't find any hint under which circumstances I get the right file or I get the file with the unknown id.
Could someone help me here?
Say I have an archetype and I generate a project from it. But I would like to resolve placeholders in a property file of the project I generated on after generation time by passing the value for placeholder through command line.
For example having the following command line:
mvn archetype:create -DarchetypeGroupId=... -DarchetypeArtifactId=... -DarchetypeVersion=1.0 -DgroupId=... -DartifactId=my-project -Dversion=1.0-SNAPSHOT -Dhello=Hello!
say the archetype contains app.properties (as part of project which is being generated) with the following content:
greeting=${hello}
Is it possible to replace ${hello} with "Hello!" right after project has been generated as a result of mvn archetype:create command?
Yes this is possible. From the advanced usage guide for maven archetypes:
If the user wants to customize the generated project even further, a groovy script named archetype-post-generate.groovy can be added in src/main/resources/META-INF/. This script will end up in the generated archetype's META-INF folder and will be executed upon creating a project from this archetype. This groovy script has access to the ArchetypeGenerationRequest object, as well as all the System.getProperties() and all the archetype generation properties the user has specified.
You could define additional properties in the archetype, following the format:
https://maven.apache.org/archetype/maven-archetype-plugin/specification/archetype-metadata.html
For example:
define the file: src\main\resources\META-INF\maven\archetype-metadata.xml
<archetype-descriptor
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://maven.apache.org/plugins/maven-archetype-plugin/archetype-descriptor/1.0.0"
xsi:schemaLocation="http://maven.apache.org/plugins/maven-archetype-plugin/archetype-descriptor/1.0.0 http://maven.apache.org/xsd/archetype-descriptor-1.0.0.xsd"
name="modelant.metamodel.api">
<requiredProperties>
<requiredProperty key="package"><defaultValue>${groupId}.${artifactId}</defaultValue></requiredProperty>
<requiredProperty key="parentGroupId"><defaultValue>${groupId}</defaultValue></requiredProperty>
<requiredProperty key="parentArtifactId"><defaultValue>${artifactId}</defaultValue></requiredProperty>
<requiredProperty key="parentVersion"><defaultValue>${version}</defaultValue></requiredProperty>
<requiredProperty key="metamodelUrl"/>
</requiredProperties>
</archetype-descriptor>
Here you see that it defines additional required properties, so they have to be mandatorily provided within the dialog, where:
some properties may have no value - see metamodelUrl
some properties may have default values either
-- as static text
-- or referring the values of the previously defined standard properties: groupId, artifactId, version
some poperties may override the values of the standard properties - the "package" property. Here it is redefined.
Please note:
the https://maven.apache.org/archetype/maven-archetype-plugin/advanced-usage.html Apache maven page on archetypes refers just calling "mvn install" in order to publish the artifact in the local repository. This is not enough - use: mvn clean install "archetype:update-local-catalog"
the https://maven.apache.org/archetype/archetype-models/archetype-descriptor/archetype-descriptor.html Apache maven page states that the proeprties are referred using "property name" expressions. This is not correct - the properties are allowed to be used in the filtered resources, treating them as velocity templates, thus the references are ${property name} and #if, #for, etc. statements could be used there
Not sure I understood correctly. For post processing after project creation you could use the param -Dgoals and invoke your custom plugin.
Am not sure about your requirement, but why cant you do the same during the project generation itself ?
I know that a java.lang.NoSuchMethodError means that the version of a class used for compiling is different from the version used at runtime. Usually, when I see this issue, I start the app.server in java -verbose mode, which tells me the jar file from which a class is loaded. If that jar file is not the one I intended to use, I know I'm using an incorrect version of the jar file.
Another approach I use, is to use javap to look at the method signatures of the class in the jar file I am using at runtime, to confirm that the jar does indeed contain the class with a different method signature.
I am seeing this error now in Karaf, an OSGi container and none of the above approaches are helping. java -verbose shows me the jar, javap shows me the method signature and the method signature is the same as that in the error stacktrace. In other words, I can see that the class from the jar being used at runtime does have the same method signature that the jvm says it cannot find.
Here is the exact stack trace, if it helps:
java.lang.NoSuchMethodError: org.apache.axiom.om.OMXMLBuilderFactory.createSOAPModelBuilder(Ljava/io/InputStream;Ljava/lang/String;)Lorg/apache/axiom/soap/SOAPModelBuilder;
at org.apache.axis2.builder.SOAPBuilder.processDocument(SOAPBuilder.java:55)
at org.apache.axis2.transport.TransportUtils.createDocumentElement(TransportUtils.java:179)
at org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:145)
at org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:108)
at org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:67)
at org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:354)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:421)
at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:229)
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:165)
at org.wso2.carbon.authenticator.stub.AuthenticationAdminStub.login(AuthenticationAdminStub.java:659)
Are there any other approaches I can/should use? Thanks for your help.
The Karaf commands exports [ids], imports [ids] and classes [ids] can used in combination with grep (each command has a --help option).
From the bundle throwing the error (with id N), imports N | grep org.apache.axiom.om will tell you which bundle it is actually importing that package from.
And approaching from the other side, exports | grep org.apache.axiom.om will list the bundles that export that package.
I'd expect you'll see more than one line from the exports and the import command will show incorrect version is being used.
You could also use java -verbose:class to see where classes are loaded from, which might show that the problematic class is loaded from a different bundle that you expected.
I have a maven 3 project. In the POM, I define numerous <properties> - some under <project>, others under specific <profile>. is the a way in maven to export all declared properties to a .properties file?
My current way of doing so is to:
create env.properties file in src/main/resources
for each property 'myProp' add this line to env.properties: myProp=${myProp}
enable resource filtering during builds
Seems like there ought to be a way to eliminate step 2 above...
thanks,
-nikita
Use properties-maven-plugin and its write-project-properties goal.
If I understand your requirements correctly, you can do this using the antrun-plugin coupled with Ant's echoproperties task. An example of this configuration is in the StOf question here.