proguard-maven-plugin java 8 - maven-3

I am trying to use Proguard to obfuscate my Java 8 App.
Proguard supports Java 8 since version 5.0
For some reason the program-maven-plugin ignores my configuration to use Proguard version 5.1 and uses 4.3, incompatible with Java 8.
My configuration is
<plugin>
<groupId>com.pyx4me</groupId>
<artifactId>proguard-maven-plugin</artifactId>
<version>2.0.4</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>proguard</goal>
</goals>
</execution>
</executions>
<configuration>
<proguardVersion>5.1</proguardVersion>
<obfuscate>true</obfuscate>
<options>
<option>-allowaccessmodification</option>
<option>-keep class mypackage.Testt</option>
</options>
<libs>
<lib>${java.home}/lib/rt.jar</lib>
<lib>${java.home}/lib/javafx-mx.jar</lib>
</libs>
</configuration>
<dependencies>
<dependency>
<groupId>net.sf.proguard</groupId>
<artifactId>proguard-base</artifactId>
<version>5.1</version>
<scope>runtime</scope>
</dependency>
</dependencies>
</plugin>
Any clue?
Tks,

Answering my own question...
It happens that Proguard version 5.1 is not yet available on Maven repositories.
It is necessary to manually download it and run:
mvn install:install-file -Dfile=./proguard.jar -DgroupId=net.sf.proguard -DartifactId=proguard -Dversion=5.1 -Dpackaging=jar
In addition, the correct Proguard configuration is:
<dependency>
<groupId>net.sf.proguard</groupId>
<artifactId>proguard</artifactId>
<version>5.1</version>
</dependency>

Related

How to upgrade from Vaadin 23 to Vaadin 24?

I used the Plain Java starter app from the Hello World Starters page of downloads.
I updated its Maven POM to the latest versions of dependencies. So Vaadin 23.3.1, Java 19, jetty-maven-plugin 10.0.12, and so on. The POM looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns = "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/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>project-base</artifactId>
<name>Project base for Vaadin</name>
<version>1.0-SNAPSHOT</version>
<packaging>war</packaging>
<properties>
<maven.compiler.source>19</maven.compiler.source>
<maven.compiler.target>19</maven.compiler.target>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<failOnMissingWebXml>false</failOnMissingWebXml>
<vaadin.version>23.3.1</vaadin.version>
<drivers.downloader.phase>pre-integration-test</drivers.downloader.phase>
</properties>
<repositories>
<!-- The order of definitions matters. Explicitly defining central here to make sure it has the highest priority. -->
<repository>
<id>central</id>
<url>https://repo.maven.apache.org/maven2</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
<repository>
<id>vaadin-prereleases</id>
<url>
https://maven.vaadin.com/vaadin-prereleases/
</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
<!-- Repository used by many Vaadin add-ons -->
<repository>
<id>Vaadin Directory</id>
<url>https://maven.vaadin.com/vaadin-addons</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
</repositories>
<pluginRepositories>
<!-- The order of definitions matters. Explicitly defining central here to make sure it has the highest priority. -->
<pluginRepository>
<id>central</id>
<url>https://repo.maven.apache.org/maven2</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</pluginRepository>
<pluginRepository>
<id>vaadin-prereleases</id>
<url>
https://maven.vaadin.com/vaadin-prereleases/
</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</pluginRepository>
</pluginRepositories>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-bom</artifactId>
<type>pom</type>
<scope>import</scope>
<version>${vaadin.version}</version>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>com.vaadin</groupId>
<!-- Replace artifactId with vaadin-core to use only free components -->
<artifactId>vaadin</artifactId>
</dependency>
<!-- Added to provide logging output as Vaadin uses -->
<!-- the unbound SLF4J no-operation (NOP) logger implementation -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>4.0.1</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-testbench</artifactId>
<scope>test</scope>
</dependency>
<!-- https://mvnrepository.com/artifact/io.github.bonigarcia/webdrivermanager -->
<dependency>
<groupId>io.github.bonigarcia</groupId>
<artifactId>webdrivermanager</artifactId>
<version>5.3.1</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<defaultGoal>jetty:run</defaultGoal>
<plugins>
<!-- Define newer versions of Java compiler and war plugin to
better support the latest JDK versions. -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.10.1</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>3.3.2</version>
</plugin>
<!-- Jetty plugin for easy testing without a separate server -->
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>10.0.12</version>
<configuration>
<!--
Configures automatic reload of Jetty server
(with 2 second timeout) when new classes are compiled
(e.g. by IDEs).
Should be disabled when using a proper live reload system,
such as JRebel.
If using IntelliJ IDEA with autocompilation, this
might cause lots of unnecessary compilations in the
background. Consider using "0" and trigger restart manually
by hitting enter.
-->
<scan>2</scan>
<!-- Use war output directory to get the webpack files -->
<!--<webAppConfig>-->
<!-- <allowDuplicateFragmentNames>true</allowDuplicateFragmentNames>-->
<!--</webAppConfig>-->
</configuration>
</plugin>
<!--
Take care of synchronizing java dependencies and imports in
package.json and main.js files.
It also creates webpack.config.js if not exists yet.
-->
<plugin>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-maven-plugin</artifactId>
<version>${vaadin.version}</version>
<executions>
<execution>
<goals>
<goal>prepare-frontend</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<profiles>
<profile>
<!-- Production mode is activated using -Pproduction -->
<id>production</id>
<build>
<plugins>
<plugin>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-maven-plugin</artifactId>
<version>${vaadin.version}</version>
<executions>
<execution>
<goals>
<goal>build-frontend</goal>
</goals>
<phase>compile</phase>
</execution>
</executions>
<configuration>
<productionMode>true</productionMode>
</configuration>
</plugin>
</plugins>
</build>
</profile>
<profile>
<id>it</id>
<build>
<plugins>
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<configuration>
<!--<scanIntervalSeconds>0</scanIntervalSeconds>-->
<stopPort>8081</stopPort>
<stopWait>5</stopWait>
<stopKey>${project.artifactId}</stopKey>
</configuration>
<executions>
<execution>
<id>start-jetty</id>
<phase>pre-integration-test</phase>
<goals>
<goal>start</goal>
</goals>
</execution>
<execution>
<id>stop-jetty</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>
</plugin>
<!-- Runs the integration tests (*IT) after the server is started -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>3.0.0-M7</version>
<executions>
<execution>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
<configuration>
<trimStackTrace>false</trimStackTrace>
<enableAssertions>true</enableAssertions>
</configuration>
</plugin>
</plugins>
</build>
</profile>
</profiles>
</project>
Now I would like to try the pre-release of Vaadin 24.
I understand this new version will have little new in terms of features or fixes. Instead, this new version is aimed at making the transition from being based on Java EE 8 to being based on Jakarta EE 10. As discussed in this Vaadin company blog page, this leap involves (a) the dropping of some deprecated features, and (b) the switching of package names from javax.* to jakarta.*. These changes are part of the transition from Oracle donating Java EE technologies to the Eclipse Foundation to become Jakarta EE.
Official instructions, plus my details
The Vaadin company blog page Vaadin 24 pre-release available for Spring Boot 3.0, provides some instructions for migrating from Vaadin 23 to Vaadin 24. I can supplement that page with more details.
First, migrate to latest Vaadin 23
That page first instructs us to migrate to the latest version of Vaadin 23, currently 23.3.5. We see you did that your existing Maven POM file.
Just be sure to run your app to verify Vaadin 23 is working well before trying Vaadin 24.
Java version
That page says to next ensure that your project can run on Java 17, the latest long-term support version.
We see you did that too in your existing POM, running on Java 19 (the current Java release).
Vaadin version
The official instructions point us to this GitHub page to capture the current latest version of Vaadin 24. There we find 24.0.0.alpha10.
So we paste that version number into the POM.
Servlet spec
Next, look for the javax.servlet-api entry in your POM.
Vaadin 23 and earlier was designed for Java Servlet Specification version 3.1, and is compatible with Java Servlet Spec 4.0.1.
As we jump to Jakarta 10, the name of the spec changes to Jakarta Servlet. And the Servlet Spec is version 6 in Jakarta EE 10. We can verify with a Maven repository such as this one that the latest subversion of Servlet 6 is 6.0.0.
So we change this part of the POM:
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>4.0.1</version>
<scope>provided</scope>
</dependency>
… to:
<!-- https://mvnrepository.com/artifact/jakarta.servlet/jakarta.servlet-api -->
<dependency>
<groupId>jakarta.servlet</groupId>
<artifactId>jakarta.servlet-api</artifactId>
<version>6.0.0</version>
<scope>provided</scope>
</dependency>
Jetty
Your Vaadin 23 app is bundled with an embedded version of Jetty. This enables you to run your Vaadin web app using Jetty as the deployment web app server within your IDE. This arrangement is convenient, relieving you of the chore of configuring an external web app server.
You may nevertheless choose to use an externally web app server running in its own process, such as Tomcat, a separately-installed Jetty, Glassfish, WildFly, Payara, OpenLiberty, or any of several other such products. But if you wish to use the embedded Jetty within your IDE, read on.
Your existing POM is set to use jetty-maven-plugin version 10.0.x. That corresponds to Jetty 10. That version of Jetty supports Servlet 4.
But we are moving to Servlet 6. That requires a different version of Jetty, Jetty 12. Unfortunately, Jetty 12 seems to be still in development, hosted on GitHub. But 12 is at the alpha stage as of 2023-01. If curious, see this 2022-04 talk on YouTube, Jakarta Tech Talk - Implementing Servlet 6.0 in Jetty.
So we have a predicament, if we want to run Jetty embedded conveniently within our IDE. Technically Vaadin 24 is built for Jakarta 10, which implies Servlet 6. But we only have Jetty 11 available to us, which supports Servlet 5 rather than Servlet 6. But perhaps we might be lucky to find that Vaadin 24, because it has no significant feature changes from Vaadin 23, may not actually be using any new features available only in Servlet 6, nor using any old features deleted from Servlet 6. If so, we may get away with using version of 11.0.13 of jetty-maven-plugin to utilize Jetty 5.
<!-- Jetty plugin for easy testing without a separate server -->
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>11.0.13</version>
<configuration>
<!--
Configures automatic reload of Jetty server
(with 2 second timeout) when new classes are compiled
(e.g. by IDEs).
Should be disabeld when using a proper live reload system,
such as JRebel.
If using IntelliJ IDEA with autocompilation, this
might cause lots of unnecessary compilations in the
background. Consider using "0" and trigger restart manually
by hitting enter.
-->
<scan>2</scan>
<!-- Use war output directory to get the webpack files -->
<!--<webAppConfig>-->
<!-- <allowDuplicateFragmentNames>true</allowDuplicateFragmentNames>-->
<!--</webAppConfig>-->
</configuration>
</plugin>
Let’s try it, fingers crossed 🤞 … yes, success! Using embedded Jetty 11 with Vaadin 24 is working, at least for now.
Voilà
And that is all we need to do to migrate your Vaadin 23 app to Vaadin 24 (alpha 6).
You can use the Maven Jetty plugin command jetty:run to launch your web app just as you do with Vaadin 23.
Here is my resulting Maven POM file.
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns = "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/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>project-base</artifactId>
<name>Project base for Vaadin</name>
<version>1.0-SNAPSHOT</version>
<packaging>war</packaging>
<properties>
<maven.compiler.source>19</maven.compiler.source>
<maven.compiler.target>19</maven.compiler.target>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<failOnMissingWebXml>false</failOnMissingWebXml>
<vaadin.version>24.0.0.alpha6</vaadin.version>
<drivers.downloader.phase>pre-integration-test</drivers.downloader.phase>
</properties>
<repositories>
<!-- The order of definitions matters. Explicitly defining central here to make sure it has the highest priority. -->
<repository>
<id>central</id>
<url>https://repo.maven.apache.org/maven2</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
<repository>
<id>vaadin-prereleases</id>
<url>
https://maven.vaadin.com/vaadin-prereleases/
</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
<!-- Repository used by many Vaadin add-ons -->
<repository>
<id>Vaadin Directory</id>
<url>https://maven.vaadin.com/vaadin-addons</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
</repositories>
<pluginRepositories>
<!-- The order of definitions matters. Explicitly defining central here to make sure it has the highest priority. -->
<pluginRepository>
<id>central</id>
<url>https://repo.maven.apache.org/maven2</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</pluginRepository>
<pluginRepository>
<id>vaadin-prereleases</id>
<url>
https://maven.vaadin.com/vaadin-prereleases/
</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</pluginRepository>
</pluginRepositories>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-bom</artifactId>
<type>pom</type>
<scope>import</scope>
<version>${vaadin.version}</version>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>com.vaadin</groupId>
<!-- Replace artifactId with vaadin-core to use only free components -->
<artifactId>vaadin</artifactId>
</dependency>
<!-- Added to provide logging output as Vaadin uses -->
<!-- the unbound SLF4J no-operation (NOP) logger implementation -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
</dependency>
<!-- https://mvnrepository.com/artifact/jakarta.servlet/jakarta.servlet-api -->
<dependency>
<groupId>jakarta.servlet</groupId>
<artifactId>jakarta.servlet-api</artifactId>
<version>6.0.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-testbench</artifactId>
<scope>test</scope>
</dependency>
<!-- https://mvnrepository.com/artifact/io.github.bonigarcia/webdrivermanager -->
<dependency>
<groupId>io.github.bonigarcia</groupId>
<artifactId>webdrivermanager</artifactId>
<version>5.3.1</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<defaultGoal>jetty:run</defaultGoal>
<plugins>
<!-- Define newer versions of Java compiler and war plugin to
better support the latest JDK versions. -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.10.1</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>3.3.2</version>
</plugin>
<!-- Jetty plugin for easy testing without a separate server -->
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>11.0.13</version>
<configuration>
<!--
Configures automatic reload of Jetty server
(with 2 second timeout) when new classes are compiled
(e.g. by IDEs).
Should be disabled when using a proper live reload system,
such as JRebel.
If using IntelliJ IDEA with autocompilation, this
might cause lots of unnecessary compilations in the
background. Consider using "0" and trigger restart manually
by hitting enter.
-->
<scan>2</scan>
<!-- Use war output directory to get the webpack files -->
<!--<webAppConfig>-->
<!-- <allowDuplicateFragmentNames>true</allowDuplicateFragmentNames>-->
<!--</webAppConfig>-->
</configuration>
</plugin>
<!--
Take care of synchronizing java dependencies and imports in
package.json and main.js files.
It also creates webpack.config.js if not exists yet.
-->
<plugin>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-maven-plugin</artifactId>
<version>${vaadin.version}</version>
<executions>
<execution>
<goals>
<goal>prepare-frontend</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<profiles>
<profile>
<!-- Production mode is activated using -Pproduction -->
<id>production</id>
<build>
<plugins>
<plugin>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-maven-plugin</artifactId>
<version>${vaadin.version}</version>
<executions>
<execution>
<goals>
<goal>build-frontend</goal>
</goals>
<phase>compile</phase>
</execution>
</executions>
<configuration>
<productionMode>true</productionMode>
</configuration>
</plugin>
</plugins>
</build>
</profile>
<profile>
<id>it</id>
<build>
<plugins>
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<configuration>
<!--<scanIntervalSeconds>0</scanIntervalSeconds>-->
<stopPort>8081</stopPort>
<stopWait>5</stopWait>
<stopKey>${project.artifactId}</stopKey>
</configuration>
<executions>
<execution>
<id>start-jetty</id>
<phase>pre-integration-test</phase>
<goals>
<goal>start</goal>
</goals>
</execution>
<execution>
<id>stop-jetty</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>
</plugin>
<!-- Runs the integration tests (*IT) after the server is started -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>3.0.0-M7</version>
<executions>
<execution>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
<configuration>
<trimStackTrace>false</trimStackTrace>
<enableAssertions>true</enableAssertions>
</configuration>
</plugin>
</plugins>
</build>
</profile>
</profiles>
</project>
External app servers
You may want your IDE to execute with an external app server rather than use the embedded Jetty discussed above.
If so, you’ll need to use a version of your desired server that supports Jakarta EE 10. Here is a partial list.
Apache Tomcat 10.1
Eclipse Jetty 12
Eclipse GlassFish 7
Payara 6
IBM Open Liberty 22
Red Hat WildFly 27
… and more

API documentation in Vert.x

Is there any way to generate apis documentation in vert.x like swagger documentation in spring?
I did my research but didn't find any solution
You can easily bring in a dependency like smallrye-open-api create an interface for your services, place annotations and have it generated at compile time. I've done it for many vert.x components that I wrote.
<dependency>
<groupId>io.smallrye</groupId>
<artifactId>smallrye-open-api-core</artifactId>
</dependency>
<dependency>
<groupId>io.smallrye</groupId>
<artifactId>smallrye-open-api-jaxrs</artifactId>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>javax.ws.rs</groupId>
<artifactId>javax.ws.rs-api</artifactId>
<scope>compile</scope>
</dependency>
<build>
<plugins>
<plugin>
<groupId>io.smallrye</groupId>
<artifactId>smallrye-open-api-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>generate-schema</goal>
</goals>
</execution>
</executions>
<configuration>
<infoTitle>Notifier API</infoTitle>
<outputDirectory>../application/src/main/resources/</outputDirectory>
<includeDependenciesScopes>compile,provided,system,test,import</includeDependenciesScopes>
</configuration>
</plugin>
</plugins>
if the implementation is not in the same module remember to add a mock impl so that the plugin detect the interface as being used.

Third party integration (required at runtime) in maven

I am new to maven. I have used ant and know how to bundle third party jars with my jars so that they should be available at runtime. I am writing an application which depends on Apache tika library. I am using dependency to include Apache Tika jar. And my jar gets generated successfully. My pom.xml file is
<groupId>com.nayan.parsers</groupId>
<artifactId>nayantikaparser</artifactId>
<version>0.0.1-1-SNAPSHOT</version>
<packaging>jar</packaging>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-all</artifactId>
<version>1.3</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.11</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.apache.tika</groupId>
<artifactId>tika-app</artifactId>
<version>0.7</version>
</dependency>
</dependencies>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>copy</id>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>org.apache.tika</groupId>
<artifactId>tika-app</artifactId>
<version>0.7</version>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
<configuration>
<testFailureIgnore>true</testFailureIgnore>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<testFailureIgnore>true</testFailureIgnore>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
At the runtime since Tika will not be available on all systems I want to bundle classes from Tika jar into my output jar. But I am not sure how to do that. I ant I used to do it in the following way
<zip destfile="dist/${jar.name}-${build.version}.jar">
<!-- Include the temporary jar -->
<zipgroupfileset file="dist/temp.jar" />
<zipgroupfileset file="lib/tika-app-1.3.jar"/>
</zip>
How to do the same using maven.
Look into Maven assembly plugin. Specifically, jar-with-dependecies case. This will ensure all the dependencies are in the jar.
If you want finer control look into Maven shade plugin. See this case.
Its too late to update but I was able to achieve the desired results. I used shade plugin for maven
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.1</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<artifactSet>
<excludes>
<exclude>org.testng</exclude>
<exclude>log4j</exclude>
</excludes>
</artifactSet>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>

Problems building ANTLR v4 from source using ant : [java] error(7): cannot find or open file: *.g

I was trying to build ANTLR version 4 from source, as I downloaded it from the official website, but I cannot do it using ant. I downloaded the antlr-3.5-complete-no-st3.jar to the /lib folder as build.xml says, but when I run ant it returns:
[mkdir] Created dir: /../antlr/antlr4-master/build/generated-sources/antlr3/org/antlr/v4/parse
[java] error(7): cannot find or open file: *.g
BUILD FAILED
/../antlr/antlr4-master/build.xml:108: The following error occurred while executing this line:
/../antlr/antlr4-master/build.xml:84: Java returned: 1
I am on a MacBook running OSX 10.8.2
Is there anything else I have to do in order to have a successful compilation using ant?
Thanks in advance,
Dimos
You need to use Maven to build ANTLR 4 from source.
Building ANTLR 4 with Maven
Above "Building ANTLR 4 with Maven" link seems not available. Please follow the below links for ANTLR 4 maven build. These helped me to achieve antlr 4 maven build.
https://groups.google.com/forum/#!msg/antlr-discussion/Vw4Ia__sgPk/nDS5Y9YSDGIJ
How do I get help on the antlr4-maven-plugin
My ANTLR-Maven Plugin is as below:-
<build>
<plugins>
<plugin>
<groupId>org.antlr</groupId>
<artifactId>antlr4-maven-plugin</artifactId>
<version>4.0</version>
<configuration>
<sourceDirectory>${basedir}/src/main/java/com/test</sourceDirectory>
</configuration>
<executions>
<execution>
<goals>
<goal>antlr4</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
<pluginManagement>
<plugins>
<!--This plugin's configuration is used to store Eclipse m2e settings
only. It has no influence on the Maven build itself. -->
<plugin>
<groupId>org.eclipse.m2e</groupId>
<artifactId>lifecycle-mapping</artifactId>
<version>1.0.0</version>
<configuration>
<lifecycleMappingMetadata>
<pluginExecutions>
<pluginExecution>
<pluginExecutionFilter>
<groupId>org.antlr</groupId>
<artifactId>
antlr4-maven-plugin
</artifactId>
<versionRange>
[4.0,)
</versionRange>
<goals>
<goal>antlr4</goal>
</goals>
</pluginExecutionFilter>
<action>
<ignore></ignore>
</action>
</pluginExecution>
</pluginExecutions>
</lifecycleMappingMetadata>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
<dependencies>
<dependency>
<groupId>org.antlr</groupId>
<artifactId>antlr4-maven-plugin</artifactId>
<version>4.2.2</version>
</dependency>
</dependencies>

How to wrap an Ant v.1.8.1 build with Maven v. 2.x?

I need to build project with subprojects and main project is the Maven project, one of the subprojects - is the Ant project.
I need to compile all projects from one main pom.xml
I have found solution How to wrap an Ant build with Maven? and it's answer is correct, but not for my project. Because when my ant project required Ant v. 1.8.x, but on build with the
<dependencies>
<dependency>
<groupId>ant-contrib</groupId>
<artifactId>ant-contrib</artifactId>
<version>1.0b3</version>
<exclusions>
<exclusion>
<groupId>ant</groupId>
<artifactId>ant</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.apache.ant</groupId>
<artifactId>ant-nodeps</artifactId>
<version>1.8.1</version>
</dependency>
</dependencies>
<modules>
<module>Bundles/I_AboutForm</module>
<module>Bundles/I_AppVars</module>
</modules>
<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<phase>process-resources</phase>
<configuration>
<!--<taskdef resource="net/sf/antcontrib/antlib.xml" classpathref="maven.plugin.classpath" />-->
<tasks>
<ant antfile="MainApplication/build.xml" target="compile"/>
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
maven downloaded Ant v. 1.7.1 and uses him on build (in the local repo has Ant v.1.8.1).
I think, may be trouble in the dependings of the ant-contrib 1.0b3 - may be ant-contrib depends on Ant v. 1.7.1?
Please advice me how to build Ant v. 1.8.x project in Maven.
Thanks, best regards, Arthur.
looking at the version of the plugin 1.7, it seems to use the ant version 1.8.2
http://maven.apache.org/plugins/maven-antrun-plugin/dependencies.html
Try to specify the version 1.7 of the plugin maven-antrun-plugin
for example:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>

Resources