I am looking for a way to dynamically extract the current folder name within maven pom.xml file.
For Example:
if the pom.xml file is at /home/jenkins/workspace/bdms-ci/bdms-bcr/pom.xml
then bdms-bcr is the current folder.
See a code snippet:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.17</version>
<configuration>
<testClassesDirectory>../../bdms-ci-improve/${project.basedir}/target/test-classes</testClassesDirectory>
<classesDirectory>../../bdms-ci-improve/${project.basedir}/target/classes</classesDirectory>
</configuration>
</plugin>
${project.basedir} will bring the full path which is not good since only the current folder is needed.
I tried to work with MavenProject class from the maven api document:
${project.file.parentFile.name} or ${project.file.name}, but it didn't work.
remember it is maven multi project and everything has to be dynamically.
The whole issue is for jenkins ci build which use parallel-test-executor plugin. I would like to compile once in the main job and then all the other test execute jobs will will only test by looking into the compiled code.
Using maven 3.2.3
#guymi,
Seems like you should be able to simply use ${project.artifactId} or perhaps ${parent.artifactId}.
EDIT
Or does your artifactId name disagree with the directory it's stored in?
If so, that's possible but not good practice and should be avoided.
It is not possible to do it. simple as that.
A workaround solution is by using artifactId with the same name as folder name. then you can do:
../../bdms-ci-improve/${project.artifactId}/target/test-classes</testClassesDirectory>
Related
I am creating my own maven-environment-plugin that creates and bundle resources for a predefined folder structure for each environment defined in the configuration. The plugin is outputting the folder structure and resource in a zip file and placing it in the target folder.
Questions:
How can I make my plugin work like the maven-assembly-plugin so my output to target folder also ends up in my local repository when I use 'mvn install'?
Do I need to mark it or something? Its automaticallly doing it when the maven-assembly-plugin is used.
How does maven-assembly-plugin manage to make sure of this?
I am using mojo for my plugin development.
<plugin>
<groupId>dk.kmd.devops.maven.plugin</groupId>
<artifactId>envconfiguration-maven-plugin</artifactId>
<version>1.0.3</version>
<configuration>
<environments>
<environment>${env.local}</environment>
<environment>${env.dev}</environment>
<environment>${env.t1}</environment>
<environment>${env.t2}</environment>
<environment>${env.p0}</environment>
</environments>
<sourceConfigDir>${basedir}/src/main/config</sourceConfigDir>
<zipEnvironments>true</zipEnvironments>
</configuration>
<executions>
<execution>
<phase>generate-resources</phase>
<goals>
<goal>generateEnv</goal>
</goals>
</execution>
</executions>
</plugin>
You need to attach (that's the correct terminology in this case) the new artifact (the generated zip file) to the build as part of its official artifacts.
This is basically what the attach-artifact goal of the build-helper-maven-plugin does:
Attach additional artifacts to be installed and deployed.
From its official examples, the attach goal:
Typically run after antrun:run, or another plugin, that produces files that you want to attach to the project for install and deploy.
The another plugin in this case can be the plugin you developed. Hence there are two solutions to your case:
Configure this plugin to attach the generated artifact as a further pom.xml configuration, or
add to your plugin the functionality to automatically attach the generated file
The second case can be covered via Maven API, using the MavenProjectHelper and its attachArtifact method.
In your mojo, you can import is as a component via:
/**
* Maven ProjectHelper
*/
#Component
private MavenProjectHelper projectHelper;
Then use the aforementioned method:
projectHelper.attachArtifact(project, "zip", outputFile);
You should probably already have the required Maven dependency providing it, but just in case it would be this one:
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-core</artifactId>
<version>3.3.9</version>
</dependency>
Note that the artifact will be attached to the build as an additional artifact via a classifier, that is, a suffix to the default artifact name differentiating it from the default artifact and making it unique as output of the build.
As a reference to real example and to further answer your (last) question, check this query on the GitHub maven-plugins repository, checking for the attachArtifact string, you will see it used in a number of Maven plugins, among which the maven-assembly-plugin, for example here in the AbstractAssemblyMojo class.
If all classes are up-to-date "Nothing to compile - all classes are up to date"
so will maven create jar again?
As I am seeing in my log that jar is not creating again. so maven come to know that all classes are up-to-date.
Question: is there any process or another thing which work on this?
The Maven Jar Plugin will create a jar via its jar goal if none exists or skip its creation if existing but nothing changed.
You can force the creation of the jar via its forceCreation option (since version 2.2). From official documentation:
Require the jar plugin to build a new JAR even if none of the contents appear to have changed. By default, this plugin looks to see if the output jar exists and inputs have not changed. If these conditions are true, the plugin skips creation of the jar. This does not work when other plugins, like the maven-shade-plugin, are configured to post-process the jar. This plugin can not detect the post-processing, and so leaves the post-processed jar in place. This can lead to failures when those plugins do not expect to find their own output as an input. Set this parameter to true to avoid these problems by forcing this plugin to recreate the jar every time.
Its default value is at false, which explains the behavior you are having.
If you want to force it always, you can add to your pom file:
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.6</version>
<configuration>
<forceCreation>true</forceCreation>
</configuration>
...
</plugin>
</plugins>
</build>
...
</project>
Or just on a single build, invoke it as following:
mvn package -Djar.forceCreation=true
So, going back to your question:
is there any process or another thing which work on this?
The answer is: Yes, the Maven Jar Plugin works on this and the option above will change its behavior.
I have a java application that uses maven for build management.
When I run the generated application jar with
java -jar myjar
the output files generated by the application end up in the projects root directory. So if I execute the jar in /my/project/dir and create a filewriter to write to logs/mylog
The resulting file ends up in
/my/project/dir/logs/mylog
Exactly as expected.
HOWEVER:
When maven surefire plugin executes the unit tests, the files end up in the module directory.
Say that i compile a maven project in /my/module.
The compiled files end up in /my/module/target/classes.
When maven executes these classes, through unit tests, the output of the same classes ends up in
/my/module/logs/mylog
I would like the files to end up in the target dir like
/my/module/target/logs/mylog
As this is where the class files reside.
So I am looking for a way to configure maven surefire to define the java classes' root directory to point to target instead of the module dir.
EDIT:
I have found this post:
Maven: change the directory in which tests are executed
That seems to attempt a fix to my problem. However, if i set the workingdirectory to my target dir, the tests can no longer find my resources, even if they are copied from the modules ${basedir} to ${basedir}/target
You should set your application working dir to ./target (or in a Maven property way: ${project.build.directory})
Solution:
By default, the maven surefire plugin executes its tests in the modules main directory.
In order to avoid this, set the workingdirectory of the plugin to the target directory.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>...</version>
<configuration>
<workingDirectory>${project.build.directory}</workingDirectory>
<basedir>${project.build.directory}</basedir>
</configuration>
</plugin>
Note that in case of tests that rely on some resources with root in the modules basedir, you need to copy these over. The easiest way i can find is with the resource plugin.
<build>
<resources>
<resource>
<directory>dependency</directory>
<targetPath>${project.build.directory}/dependency</targetPath>
</resource>
...
</build>
I can't tell you exactly how to do what you need to do because there is no real information
I can give you a hint about what to look at using.
Maven profiles can change the source, and behavior of Maven when they are selectively enabled.
Profiles are specifically designed to do just what you want to do.
I need to store an artifact in Maven/Nexus but when it's pulled down it must not have a version number at the end.
Before you berate me, point your scowl at Oracle.
I have comm.jar (Oracle comm port driver). I've put this in my nexus server & it comes down as comm-1.0.jar. But the JAR contains the following code:
if(streamtokenizer.ttype == -3
&& (i = streamtokenizer.sval.indexOf("comm.jar")) != -1)
It's hard coded to use its own name to know where to find the configuration file that goes with it. The jar is signed so I can't make changes to it.
So... how to I store a jar in Nexus and not have an extension number on it ?
This isn't the exact answer to my question but it does solve my problem.
I called my jar "comm.jar-1.0.2.jar" The code looks for 'comm.jar' in the file name so now it finds it!
ok, so it a fudge and I'm lucky the internal code is just looking for indexOf. but it works!
Thanks to everyone for there advice on this!
Jeff
This isn't a complete answer, more a collection of thoughts on how you might approach this.
I think you will need to declare your dependency with the version number present, to ensure Maven is happy to resolve the artifact and build it. So, the trick will be ensuring the aritfact is renamed before it is bundled in your finished product.
The Maven dependency:copy-dependencies goal has a stripVersion parameter that might come in useful. I suspect you can use this to rename the JAR correctly, perhaps as part of an assembly (ensuring the depedency is moved to a directory that is part of the classpath).
Such a plan may well break your development environment, however. Perhaps you can get around that by fudging a JAR file with the right name?
If you want it to work with a war project then you can use the File Name Mapping to strip the version.
<build>
<plugins>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.3</version>
<configuration>
<outputFileNameMapping>#{artifactId}#.#{extension}#</outputFileNameMapping>
</configuration>
</plugin>
</plugins>
</build>
The dependent jars will as normal end up in WEB-INF/lib but now without the version.
But from your question it is hard to tell what your end product is, war, jar, zip, ...
Applications built on top of the NetBeans platform have a <myappdir>/etc/<myapp>.conf file determining, among other things, application JVM parameters. Historically, this file was a part of the NetBeans IDE installation (as far as I could tell), but starting with NB 6.9, custom files are now supported.
I am having trouble packaging a custom configuration file using Maven to build the application.
I imagine the app.conf property should have been set in the project's pom under project/build/pluginManagement/plugins like so:
<plugin>
...
<configuration>
<brandingToken>${brandingToken}</brandingToken>
<cluster>${brandingToken}</cluster>
<appConf>myapp.conf</appConf>
</configuration>
The maven module representing my application contained no prior source, so I created the src/main/nbm folder and placed myapp.conf in src/main/nbm. This isn't picked up by nbm-maven-plugin. and putting the conf file into src/main/resources doesn't make a difference.
So, can anyone explain how a NetBeans Platform application with a custom configuration file can be built using maven?
UPDATE:
With Tim's prod in the right direction, I found the answer documented on Geertjan's blog. The solution is to configure the nbm-maven-plugin like so in the application module pom:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>nbm-maven-plugin</artifactId>
<configuration>
<etcConfFile>src/main/resources/my.conf</etcConfFile>
</configuration>
</plugin>
</plugins>
</build>
BTW, if you need a second name with Geertjan, you're not really a NetBeans platform developer. ;)
Have a look at the documentation of the nbm:cluster-app plugin, specifically the part on the conf file.
As per my understanding that should allow you to replace the default one with a custom one that you create.