Suppose we have two different maven projects; project A and project B
Project B uses A and needs to dynamically (using maven pluggins ?) copy a source file "A.java" from project A, modify its package declaration and compile it (project B should have the same class from project A but with other package declaration ..)
I am trying to copy the source file from A to B before modifying the package declaration and compile all.
Is this the good approach ?
So, project A expose its java file as a resource
<build>
<resources>
<resource>
<directory>src/</directory>
<includes>
<include>**/A.java</include>
</includes>
</resource>
</resources>
</build>
But how can I copy this file to B (B is a dependency in A) ? does "maven-resources-plugin" enable to copy resources from a dependency project, and if so, how do I specify the property "directory" in "resource"
I tried by specify the location of the file in the jar dependency but it did not work
Do you have other propositions ?
Thanks
Finally I solved it by the following steps:
1 - Use "maven-dependency-plugin" to extract (unpack) what I want (the source files from the jar) of included artifacts.
2 - Use "maven-antrun-plugin" to execute ant commands, to replace the strings, create the new package and move modified sources ..
see here
3 - Use "build-helper-maven-plugin" to point the compiler to the new source package in order to include them in the compilation phase
PS: These three steps must happen in the phase "generate-sources" !
maven-resources-plugin enable you to copy java source anywhere before compiling (you can initialize phases) but the problem lies in package declaration in the java file. you need to modify it also and that is not simple in maven
But why you need to do so ? why you need to use the same code in two different packages ???
Related
I wants to build my anndroid project with maven.
There are 3 projects
Project - A (jar file )
Project - B (jar file )
Project - C (sdk package)
Project C is depended on B
Project B is depended on A
With maven I wants to release two flavor of by build
1st flavor : Release JAR from B (which contain code from B & A)
2nd flavor : Release SDK from C (which contain code from C & B & A)
Can I control this behaviors from MAVEN.
For the "1st flavor", you can use the maven-assembly-plugin with the predefined desriptor jar-with-dependencies that will embed all the dependencies into your project's jar, but pay attention to the transitive dependencies that could be embedded into it also. Otherwise you can also use the maven-shade-plugin which is having options that you could be interested in like minimizeJar and an easier way to configure of includes and excludes (see doc here).
For the "2nd flavor", the use of the maven-assembly-plugin would fit well with its bin descriptor or by defining your own descriptor if you need to include other files (see the descriptor format here). You can find a few examples on how to configure and use the maven-assembly-plugin for that on SO (you can also look at the questions I already answered about this plugin)
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 have a very specific requirement of our build infrastructure to copy some contents of another JAR dependency to a specific sub-folder of my web-application. We're using maven-assembly-plugin, and a natural way to do this is to use <dependencySet> along with <unpackOptions>.
The code sample (in assembly descriptor) I have looks as following:
<dependencySet>
<unpack>true</unpack>
<scope>runtime</scope>
<useProjectArtifact>false</useProjectArtifact>
<includes>
<include>my.group:artifact:jar</include>
</includes>
<unpackOptions>
<includes>
<include>subfolder/config.xml</include>
</includes>
</unpackOptions>
<outputDirectory>WEB-INF/otherfolder</outputDirectory>
</dependencySet>
The problem is that I can't figure out how to specify that I only want to copy just a single file artifact.jar/subfolder/config.xml to a target WEB-INF/otherfolder. The actual result is WEB-INF/otherfolder/subfolder/config.xml. As you can see, /subfolder gets appended to a final path. Is there any way to change the <include> expression so that /subfolder doesn't get appended?
Thanks in advance!
Have you ever thought about the maven-dependency-plugin which has a good support for unpacking archives.
Browsing through source reveals that this is not possible via maven-assembly plug-in. It gets all includes that are specified in assembly descriptor, and then passes this information to Plexus archiver which is used through multiple stages. Include patterns are passed to Plexus archiver as well, and then it obviously performs 'unpack' conserving directory structure.
As #khmarbaise indicates, the solution lies in combining dependency-plugin with assembly-plugin:
On package phase start by unpacking the dependencies you need to some target directory
On package (later in pom) use assembly to extract specific files from that directory into your artifact
Try this out with the <file/> tag and destName:
https://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_file
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.
I have a package X.Y.Z that exists in 2 bundles A and B:
bundle A
package X.Y.Z
class Class1
bundle B
package X.Y.Z
class Class2
Bundle B exports package X.Y.Z.
Bundle A imports package X.Y.Z and gets an exception that his own class Class1 is not found. Should it work?
I use glassfish 3.1 with felix
No it should not work. If you import package X.Y.Z then that import will be used in preference to the bundle's own internal contents.
More generally, you have a problem known as split packages. Packages should be coherent and exported by a single bundle, not smeared across multiple bundles. You should refactor your bundle contents so that all classes belonging to package X.Y.Z are present in a single bundle.
Again, Niel is absolutely correct. But, sometimes vendors, for whatever reason will have multiple .jar files containing the same packages. This is sometimes done when they want to provide small .jar files for discreet implementations of thier product. An example of why this may be done is if they have a text-processing algorithm for an EDI document that is different than a text processing algorithm for an xml document. In this example, they may choose to create two .jar (versions 1 and 2) files containing "badlyPlannedImplementation.util" containing the different implementationing classes. Personally, I've only run into this a couple of times, but the question is how do you handle it?
When you run into the issue where you have two .jar files that export the same package and you want access to both packages classes you use a mechanism called "shading". Shading is when you take those two packages and you gather their contents together in another .jar files package. This used to be done by a maven plugin called "maven-shade-plugin" but now the functionality is part of the maven-bundle plugin.
First, create a new project, we'll call ours "badlyPlannedImplementationShaded". Then, in your project create a pom.xml file. In your dependency section, include dependencies for both of your .jar files that you're trying to shade together.
Then, add the following to your build section.
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactid>
<version>2.1.0</version>
<extensions>true</extensions>
<configuration>
<instructions>
<Bundle-Version>${project.version}</Bundle-Version>
<Export-Package>
badlyPlannedImplementation.util;version="1",
badlyPlannedImplementation.util;version="2"
</Export-Package>
</instructions>
</configuration>
</plugin>
Doing this will create a new bundle that contains a util package that has all of the classes from the two .jar files you were trying to use.
I hope that helps!