I have a Maven project using the Swing Application Framework and would like to inject project information from the pom.xml into my application's global resources to avoid duplication.
The base application (provided via netbeans) uses Application.title, Application.version, Application.vendor, Application.description resources etc for Window titles and about box configuration but I can't find a way to set these values programatically at run time and I'm not a maven maven so don't have the skills to inject them at build time.
Anyone have any recommendations on how best to achieve the desired result?
You could try using filtered resources. If you create a property file, say src/main/resources/com/myapp/app.properties that looks like this:
version=${project.version}
name=${project.name}
id=${project.artifactId}
Them you need to enable filtering in your pom.xml:
<build>
<resources>
<resource>src/main/resources</resource>
<filtering>true</filtering>
</resources>
</build>
Now when maven builds your project, it'll expand the property file, and place it on the classpath. Then you can just call getResourceAsStream("/com/myapp/app.properties") to read it into your app.
Whist maven does automatically create a file /META-INF/maven/$groupId/$artifactId/pom.properties, this may not have all the information you need.
You can keep those in separte property file and read it from both pom.xml and your application.
Another option is to read pom.xml file from classpath (mvn will put it in META-INF folder) and parse it from there as plain xml file.
I would go with first option.
I would try using the maven-antrun-plugin. Pass the necessary maven properties to ant and create an ant build script which modifies an application properties file or the spring context configuration directly.
Another way would be to generate a separate properties file with the properties-maven-plugin and then add this properties file to the application bundle names:
For the pom.xml to write application.properties file:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-2</version>
<executions>
<execution>
<phase>process-resources</phase>
<goals>
<goal>write-project-properties</goal>
</goals>
</execution>
</executions>
<configuration>
<outputFile>${project.build.outputDirectory}/application.properties</outputFile>
</configuration>
</plugin>
...
</plugins>
...
</build>
For including the application.properties into your application:
public class MyApplication extends SingleFrameApplication
public MyApplication() {
super();
addGeneratedApplicationProperties();
}
private void addGeneratedApplicationProperties() {
ResourceManager resourceManager = getContext().getResourceManager();
getContext().setApplicationClass(MyApplication.class);
List<String> bundleNames = new LinkedList<String>(resourceManager.getApplicationBundleNames());
bundleNames.add(0, "application");
resourceManager.setApplicationBundleNames(bundleNames);
}
...
}
However, I find the maven-filter-solution way more elegant.
Related
I know this question is not new. But it seems that there is no definite answer. This answer from 2012 states that if generated sources are placed under target/generated-sources/<tool> they will be compiled. ANTLR 4 maven plugin follows this paradigm. Per documentation, the default value of outputDirectory is: ${project.build.directory}/generated-sources/antlr4.
Now in my case I have a custom tool that generates sources. I've set its output directory to be at ${project.build.directory}/generated-sources/whatever and it didn't work. Regarding the whateverpart, I've tried to use the id of the goal that generates the sources and even tried to hijack antlr4 name. No result though.
When I try this solution that suggests using mojo build-helper-maven-plugin it compiles as expected. But according to maven guide to generating sources it should be working without any helper plugin, shouldn't it? Am I missing something?
Here is the POM (fragment) configuration that I use to generate the sources.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.4.0</version>
<executions>
<execution>
<id>generate-code</id>
<phase>generate-sources</phase>
<goals>
<goal>java</goal>
</goals>
</execution>
</executions>
<configuration>
<includeProjectDependencies>false</includeProjectDependencies>
<includePluginDependencies>true</includePluginDependencies>
<executableDependency>
<groupId>com.company.product</groupId>
<artifactId>CodeGenerator</artifactId>
</executableDependency>
<arguments>
<argument>${basedir}/</argument>
<argument>${project.build.directory}/generated-sources/generate-code/</argument>
</arguments>
<mainClass>com.company.codegeneration.CodeGenerator</mainClass>
</configuration>
<dependencies>
<dependency>
<groupId>com.company.product</groupId>
<artifactId>CodeGenerator</artifactId>
<version>1.0-SNAPSHOT</version>
<type>jar</type>
</dependency>
</dependencies>
</plugin>
Your understanding is just a bit incorrect.
Nothing automatic, plugins generating source code typically handle that by adding their output directory (something like target/generated-sources/ by convention) as source directory to the POM so that it will be included later during the compile phase.
Some less well implemented plugins don't do that for you and you have
to add the directory yourself, for example using the Build Helper
Maven Plugin.
As the other answer noted, most plugins typically add the generated code as new source path.
Ex: See antlr4's Antlr4Mojo.java class. Here, the plugin is adding the generated classes to project source by calling addSourceRoot method in execute method.
// Omitted some code
void addSourceRoot(File outputDir) {
if (generateTestSources) {
project.addTestCompileSourceRoot(outputDir.getPath());
}
else {
project.addCompileSourceRoot(outputDir.getPath());
}
}
// Omitted some code
#Override
public void execute() throws MojoExecutionException, MojoFailureException {
// Omitted code
if(project!=null)
{
// Tell Maven that there are some new source files underneath the output
// directory.
addSourceRoot(this.getOutputDirectory());
}
}
// Omitted some code
So, you can either do this in your custom plugin or use the build-helper-maven-plugin.
I have a properties file:
property.a=$[value]
I am using maven-resources-plugin with filtering on this property file enabled in order to substitute build variables in there:
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<configuration>
<delimiters>
<delimiter>$[*]</delimiter>
</delimiters>
</configuration>
</plugin>
Everything works flawlessly, until $[*] token is not nested into ${*} one, like below:
property.a=${VALUE:$[value]}
Assuming value=XXX in Maven properties, I expected to get:
property.a=${VALUE:XXX}
However, Maven resources plugin doesn't substitute $[value] in there, leaving filtered contecnts as-is. I tried enabling supportMultiLineFiltering but it changed nothing. It feels like despite <delimiters> option is set explicitly, plugin treats ${*} as a valid delimiter either, and tries to filter it, without success.
How should I configure maven resources plugin so that it filters the property file contents as expected?
I just realized I missed a configuration option in maven resource plugin, designed specially for controlling default delimiters - useDefaultDelimiters, which is true by default. The configuration below solved the issue:
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<configuration>
<delimiters>
<delimiter>$[*]</delimiter>
</delimiters>
<useDefaultDelimiters>false</useDefaultDelimiters>
</configuration>
</plugin>
I have a Java Maven web app project that I'm trying to clean up. In the <build> section of my pom.xml, I have the following:
<build>
<resources>
<resource>
<filtering>true</filtering>
<directory>src/main/resources</directory>
</resource>
</resources>
<filters>
<filter>profiles/${build.profile.id}.profile.properties</filter>
</filters>
[...other properties...]
</build>
In my project, which on my Mac is /Users/anthony/workspace/my-project/, i src/main/resources/profiles/I have local.profile.properties and qa.profile.properties.
Then, in my maven profiles in my pom, I define ${build.profile.id} as the following:
<profile>
<id>local</id>
[...stuff...]
<properties>
<build.profile.id>local</build.profile.id> <!-- or qa -->
[...stuff...]
</properties>
</properties>
When I am in my console and run $ mvn clean install -Plocal, I get the following error:
Failed to execute goal ... on project my-project: Error loading property file '/Users/anthony/workspace/my-project/profiles/local.profile.properties'.
It seems like Maven is not recognizing the resource directory for my filtering profile properties file. This only works when I explicitly put the entire path of my properties file, like so:
<filters>
<filter>src/main/resources/profiles/${build.profile.id}.profile.properties</filter>
</filters>
Is there a way for me to not have to explicitly state src/main/resources? I thought that the point of me declaring a resources directory was that I could use it, especially for declaring filtering.
The resource directory only has a meaning as "resources" for the Java artifact being built, but not for Maven itself. For Maven, the "resources" directory has a special meaning in the sense that Maven knows where to copy those files to in the resulting jar-file. But for Maven working with files or filtering files, you have to tell Maven the exact path, as Maven does not know if the filtered file is a resource, a source file, or something else. Also, you could have multiple source or resource directory defined, and Maven would not know, in which one to filter. Thus you always need to specify the full path for Maven.
So, in short:
Is there a way for me to not have to explicitly state src/main/resources?
No.
I have a maven project which I would like to package in an executable jar.
It's using quite a few dependencies, like spring and so on.
It was suggested in a few posts to use OneJar, to avoid a lot of headaches.
This is what I have currently in my pom.xml:
<plugin>
<groupId>org.dstovall</groupId>
<artifactId>onejar-maven-plugin</artifactId>
<version>1.4.4</version>
<executions>
<execution>
<configuration>
<mainClass>com.cool.project.Application</mainClass>
<onejarVersion>0.97</onejarVersion>
<attachToBuild>true</attachToBuild>
<classifier>coolproject</classifier>
</configuration>
<goals>
<goal>one-jar</goal>
</goals>
</execution>
</executions>
</plugin>
In my Spring configuration one of the classes needs to pass the a resource (src/main/resources/coolfile.bin) path to an external library (jsch) method:
String resource = ConfigurationClass.class.getClassLoader().getResource("coolfile.bin").getFile();
jsch.addIdentity(resource);
When I run Application.java from the IDE (eclipse), the entire application loads successfully.
Although when I run mvn clean install, the onejar jar is built under the target folder, but when I try to run it with java -jar coolproject.one-jar.jar the following error is displayed:
...
Caused by: java.io.FileNotFoundException: file:/target/coolproject.one-jar.jar!/main/coolproject.jar!/coolfile.bin (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:138)
at java.io.FileInputStream.<init>(FileInputStream.java:97)
at com.jcraft.jsch.IdentityFile.newInstance(IdentityFile.java:83
If I inspect coolproject.one-jar.jar, I can find the coolproject.jar under the main folder, and if I inspect that, I can see coolfile.bin in its root.
So in theory the resource should be found? What am I missing?
Turns out that FileInputStream would not find the path specified by resource.
Luckily jsch provides another method where you can pass the byte array of the file rather than its location:
jsch.addIdentity("coolfile.bin", toByteArray(ConfigurationClass.class.getResourceAsStream("/coolfile.bin")), null, null);
I have a java project which uses .properties files for configuration. On the server, when launching, I set the classpath to include a folder which contains all the properties files. On my local machine, I'd like to point to a different folder.
I'm looking to add to the classpath, ideally for all projects, but adding it to each project is also fine. I've tried changing the Run > VM Options to include classpath, but with that change it can't find the main class, and I get java.lang.NoClassDefFoundError. I've also tried changing nbactions.xml directly to set the classpath to -classpath ~\MyFolder\;%classpath, but this has the same problem.
To add to the difficulty, the server is running linux while my local machine is running Windows.
I stuck with topic-starter issue also for a long time. My goal - put config files for debug purpose in project root and extend classpath to ${basedir}, so this code:
String appConfigLocation = System.getProperty("config.location");
if (appConfigLocation == null) {
logger.error("System property 'config.location' is not set...");
System.exit(1);
}
InputStream appConfigStream = Main.class.getClassLoader().getResourceAsStream(appConfigLocation);
if (appConfigStream == null) {
logger.error("Can't find resource {} in classpath, fix 'config.location'...", appConfigLocation);
System.exit(1);
}
Properties appProps = new Properties();
try {
appProps.load(appConfigStream);
} catch (IOException ex) {
System.out.println("IO error during loading of {}...", appConfigLocation);
System.exit(1);
}
read configs from ${basedir}. I like that instead of putting them to src/main/resources.
Check sources of ExecMojo.java for v1.2.1 http://grepcode.com/file/repo1.maven.org/maven2/org.codehaus.mojo/exec-maven-plugin/1.2.1/org/codehaus/mojo/exec/ExecMojo.java?av=f :
if ( CLASSPATH_TOKEN.equals( args[i] ) ) {
commandArguments.add( computeClasspathString( null ) );
}
and and v1.3.2 http://grepcode.com/file/repo1.maven.org/maven2/org.codehaus.mojo/exec-maven-plugin/1.3.2/org/codehaus/mojo/exec/ExecMojo.java?av=f:
if ( args[i].contains( CLASSPATH_TOKEN ) ) {
commandArguments.add( args[i].replace( CLASSPATH_TOKEN,
computeClasspathString( null ) ) );
}
So update NB config Execute goals to new version:
process-classes org.codehaus.mojo:exec-maven-plugin:1.3.2:exec
and use complex -classpath args in exec.argsparams:
exec.args=-classpath %classpath:.:"${basedir}" \
-Dconfig.location=app.properties \
-Dlogback.configurationFile=logback.xml \
${packageClassName}
Fix any action you need to have such behavior:
See also:
http://wiki.netbeans.org/FaqEnvVarsDuringRun
http://wiki.netbeans.org/FaqSysPropsDuringRun
Hi I had a similar need to give NetBeans7.4 a classpath to a jar with a driver outwith Maven dependencies e.g. c:\Program Files\Java\jdk1.7.0_25\db\lib\derby.jar in a Java Maven project called MyProject.
As you were thinking with the Run > VM Options, I would suggest the following:
1) right-click on MyProject to open project Properties
2) in 'Project Properties' pop-up, select 'Actions'
3) locate 'Run pproject' among the 'Actions' and select it
4) edit in 'Set Properties' text box entering
exec.args=-cp %classpath;.;"c:\Program Files\Java\jdk1.7.0_25\db\lib\derby.jar" biz.letsweb.derbyconnect.App
exec.executable=java
exec.workingdir=c:\Users\Tomasz\Documents\NetBeansProjects\DerbyConnect\target\classes
Alternatively edit nbactions.xml analogically. Once I did this, I could simply run the project inside NetBeans by pressing green arrow.
what about having the properties included as ? and those you use locally only have in a 's and activate that profile on local machine?
This is how I've been adding classpath to many of my projects
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<classpathPrefix>lib/</classpathPrefix>
<mainClass>com.nitinsurana.policereports.GUI</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
</plugins>
</build>
An outside the box solution I ended up using for my similar case in NetBeans 7.3.1:
Adding files to java classpath at runtime
private static void addSoftwareLibrary(File file) throws Exception {
Method method = URLClassLoader.class.getDeclaredMethod("addURL", new Class[]{URL.class});
method.setAccessible(true);
method.invoke(ClassLoader.getSystemClassLoader(), new Object[]{file.toURI().toURL()});
}
This gives me a hacky way to add files to my classpath at run time via program arguments. Related notes I compiled while researching:
To include a dependency for compilation only, not runtime set:
Dependency Scope
<dependency><scope>provided</scope>...</dependency>
To exclude a dependency from the shaded jar, set: Exclude
<exclude>groupId:artifactId[[:type]:classifier]</exclude>
To copy resources to the target directory from outside the typical source directory: Copy Resources
<project>
...
<build>
<plugins>
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>2.7</version>
<executions>
<execution>
<id>copy-resources</id>
<!-- here the phase you need -->
<phase>validate</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>target/extra-resources</outputDirectory>
<resources>
<resource>
<directory>extra-resources</directory>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
...
</build>
...
</project>
Note that the base path for directory is the project home. The linked post has <filtering>true</filtering> which can cause "invalid mark" in Netbeans 7.3.1.