Java 1.7.0_40
Gradle 1.10
I've never used Gradle's PMD plugin and I'm running into trouble trying to add rule sets to my build.gradle. The Pmd documentation is not clear about what the valid values of ruleSets are. Their example is ruleSets = ["basic", "braces"] and they link to the "official list". There's not much to go on, unfortunately.
I was guessing the section title maps to the valid string somehow? Like,
"Basic (java)" -> "basic"
"Braces (java)" -> "braces"
But what about things like "Empty Code (java)"?
Here's a working build.gradle example:
apply plugin: 'java'
apply plugin: 'pmd'
pmd {
ruleSets = [
// The first two better work since it's right in the Javadoc...
"basic",
"braces",
// This one does not work and other variations like
// "empty code", "emptycode", "empty-code", "empty_code" do not work.
"emptyCode"
]
}
repositories {
mavenCentral()
}
Gradle spits out the following error:
$ gradle check
:pmdMain FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':pmdMain'.
> Can't find resource emptyCode. Make sure the resource is a valid file or URL
or is on the CLASSPATH. Here's the current classpath:
/Users/kuporific/gradle/gradle-1.10/lib/gradle-launcher-1.10.jar
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug
option to get more log output.
BUILD FAILED
Total time: 9.907 secs
Running with --stacktrace or --debug as suggested doesn't seem to yield anything useful...
Note: create a dummy file like src/main/java/Dummy.java. Otherwise, the build will succeed.
How are ruleSets supposed to be declared?
Edit:
It ended up being easier declaring an xml rule set because it offers fine-grained control over the rules. It is included in build.gradle like so:
apply plugin: 'pmd'
pmd {
ruleSetFiles = files('path/to/ruleSet.xml')
}
And the rule set file looks something like this:
Note: This exaple is written for Gradle 1.10. Newer versions of Gradle (circa 2.0) use a newer version of PMD; therefore, many of the rulesets paths changed. So rulesets/logging-java.xml is now found in rulesets/java/logging-java.xml, for example.
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
name="Android Application Rules"
xmlns="http://pmd.sf.net/ruleset/1.0.0"
xsi:noNamespaceSchemaLocation="http://pmd.sf.net/ruleset_xml_schema.xsd"
xsi:schemaLocation="http://pmd.sf.net/ruleset/1.0.0
http://pmd.sf.net/ruleset_xml_schema.xsd" >
<rule ref="rulesets/logging-java.xml" />
<rule ref="rulesets/basic.xml" />
<rule ref="rulesets/braces.xml" />
<rule ref="rulesets/codesize.xml" >
<exclude name="TooManyMethods" />
</rule>
<rule ref="rulesets/controversial.xml">
<exclude name="UseConcurrentHashMap" />
<exclude name="AvoidLiteralsInIfCondition" />
<exclude name="DataflowAnomalyAnalysis" />
<exclude name="CallSuperInConstructor" />
<exclude name="AtLeastOneConstructor" />
<exclude name="NullAssignment" />
</rule>
<!-- etc... -->
</ruleset>
The latest version of PMD (5.1.3 when writing this answer) is supported by gradle. The rulesets need to be prefixed by a java-
I tested this with gradle-1.12
To use PMD 5.1.3 with gradle, the following configuration defines all the possibles rulesets I could find:
pmd {
toolVersion = '5.1.3'
ruleSets = [
'java-android',
'java-basic',
'java-braces',
'java-clone',
'java-codesize',
'java-comments',
'java-controversial',
'java-coupling',
'java-design',
'java-empty',
'java-finalizers',
'java-imports',
'java-j2ee',
'java-javabeans',
'java-junit',
'java-logging-jakarta-commons',
'java-logging-java',
'java-migrating',
'java-naming',
'java-optimizations',
'java-strictexception',
'java-strings',
'java-sunsecure',
'java-typeresolution',
'java-unnecessary',
'java-unusedcode'
]
}
Reference: http://forums.gradle.org/gradle/topics/_pmdtest_fails_with_cant_find_resource_null_when_rulesets_include_braces_gradle_2_0_rc_1
I realize this is a huge edit, but it's essentially a different answer. So after speaking to you and playing around with it, I've determined that the Gradle plugin uses a slightly older version of the pmd library than is published (namely, version 4.3); however, there are a few rulesets missing from the plugin since the most recent pmd version is 5.0.5 which breaks with a NullPointerException with Gradle and Java. Now, after writing possibly the most syntactically correct and painstaking Hello World Java program of my life to test all of these, I've compiled every single Java rule-set that works with the Gradle plugin at the moment:
here's the Main.java:
package william;
import java.util.logging.Logger;
public final class Main{
private Main(){}
public static void main(final String [ ] args){
final Logger log = Logger.getLogger(Main.class.getName());
log.fine("Hello World");
}
}
here's the build.gradle:
apply plugin: 'java'
apply plugin: 'pmd'
pmd {
ruleSets = [
"basic",
"braces",
"naming",
"android",
"clone",
"codesize",
"controversial",
"design",
"finalizers",
"imports",
"j2ee",
"javabeans",
"junit",
"logging-jakarta-commons",
"logging-java",
"migrating",
"optimizations",
"strictexception",
"strings",
"sunsecure",
"typeresolution",
"unusedcode"
]
}
repositories {
mavenCentral()
}
and now you might be wondering, which rulesets AREN'T supported yet? well the answer is:
"comments"
"empty"
"unnecessary"
Trust me when I say, the rest of the rules work flawlessly. They tore me apart when writing a Hello World. So, I hope this helps, the directory that has all of the Java rulesets.xml files defined is at: link to pmd's github java ruleset directory I ignore the migrate ones, because they didn't work. I think they're for something specific.
Good luck, and I would bring up the issue of the missing rulesets on the gradle forums to petition to get them added, or update the version. Or you could custom compile the plugin and link it to the newer pmd version if you are really desperate for the missing rulesets.
To add to the other excellent answers here. After applying pmd to your gradle build and invoking it via gradle pmdMain, the pmd jar will be downloaded to your gradle cache. From there you can run:
find ~/.gradle -name "*pmd*.jar" -exec jar -tvf {} \;|grep rulesets
And you will get the output:
0 Thu Nov 10 20:48:06 EST 2011 rulesets/
0 Thu Nov 10 20:48:06 EST 2011 rulesets/internal/
0 Thu Nov 10 20:48:06 EST 2011 rulesets/releases/
18068 Thu Nov 10 20:48:06 EST 2011 rulesets/naming.xml
65 Thu Nov 10 20:48:06 EST 2011 rulesets/jsprulesets.properties
710 Thu Nov 10 20:48:06 EST 2011 rulesets/migrating_to_15.xml
483 Thu Nov 10 20:48:06 EST 2011 rulesets/migrating_to_14.xml
1048 Thu Nov 10 20:48:06 EST 2011 rulesets/rulesets.properties
3017 Thu Nov 10 20:48:06 EST 2011 rulesets/javabeans.xml
2089 Thu Nov 10 20:48:06 EST 2011 rulesets/sunsecure.xml
777 Thu Nov 10 20:48:06 EST 2011 rulesets/migrating_to_junit4.xml
3198 Thu Nov 10 20:48:06 EST 2011 rulesets/scratchpad.xml
13190 Thu Nov 10 20:48:06 EST 2011 rulesets/strings.xml
1379 Thu Nov 10 20:48:06 EST 2011 rulesets/internal/all-java.xml
2639 Thu Nov 10 20:48:06 EST 2011 rulesets/internal/dogfood.xml
6036 Thu Nov 10 20:48:06 EST 2011 rulesets/finalizers.xml
5347 Thu Nov 10 20:48:06 EST 2011 rulesets/logging-jakarta-commons.xml
13629 Thu Nov 10 20:48:06 EST 2011 rulesets/migrating.xml
610 Thu Nov 10 20:48:06 EST 2011 rulesets/migrating_to_13.xml
3593 Thu Nov 10 20:48:06 EST 2011 rulesets/braces.xml
4163 Thu Nov 10 20:48:06 EST 2011 rulesets/clone.xml
702 Thu Nov 10 20:48:06 EST 2011 rulesets/releases/33.xml
1332 Thu Nov 10 20:48:06 EST 2011 rulesets/releases/41.xml
1009 Thu Nov 10 20:48:06 EST 2011 rulesets/releases/35.xml
395 Thu Nov 10 20:48:06 EST 2011 rulesets/releases/43.xml
1340 Thu Nov 10 20:48:06 EST 2011 rulesets/releases/40rc1.xml
1110 Thu Nov 10 20:48:06 EST 2011 rulesets/releases/34.xml
537 Thu Nov 10 20:48:06 EST 2011 rulesets/releases/38.xml
346 Thu Nov 10 20:48:06 EST 2011 rulesets/releases/37-jsp.xml
393 Thu Nov 10 20:48:06 EST 2011 rulesets/releases/37.xml
744 Thu Nov 10 20:48:06 EST 2011 rulesets/releases/39.xml
1066 Thu Nov 10 20:48:06 EST 2011 rulesets/releases/36.xml
1256 Thu Nov 10 20:48:06 EST 2011 rulesets/releases/42.xml
6379 Thu Nov 10 20:48:06 EST 2011 rulesets/android.xml
4967 Thu Nov 10 20:48:06 EST 2011 rulesets/logging-java.xml
11557 Thu Nov 10 20:48:06 EST 2011 rulesets/j2ee.xml
52926 Thu Nov 10 20:48:06 EST 2011 rulesets/design.xml
9216 Thu Nov 10 20:48:06 EST 2011 rulesets/basic-jsp.xml
37773 Thu Nov 10 20:48:06 EST 2011 rulesets/basic.xml
3981 Thu Nov 10 20:48:06 EST 2011 rulesets/imports.xml
3836 Thu Nov 10 20:48:06 EST 2011 rulesets/typeresolution.xml
2755 Thu Nov 10 20:48:06 EST 2011 rulesets/unusedcode.xml
25043 Thu Nov 10 20:48:06 EST 2011 rulesets/controversial.xml
3045 Thu Nov 10 20:48:06 EST 2011 rulesets/coupling.xml
13379 Thu Nov 10 20:48:06 EST 2011 rulesets/strictexception.xml
12787 Thu Nov 10 20:48:06 EST 2011 rulesets/codesize.xml
12484 Thu Nov 10 20:48:06 EST 2011 rulesets/junit.xml
10784 Thu Nov 10 20:48:06 EST 2011 rulesets/optimizations.xml
1412 Thu Nov 10 20:48:06 EST 2011 rulesets/basic-jsf.xml
1396 Thu Nov 10 20:48:06 EST 2011 rulesets/favorites.xml
These may not all be implemented, but it is a good starting point. For a description of each file, you can check the documentation here.
When using your own rulset.xml file as described by kuporific, like:
pmd {
ruleSetFiles = files('path/to/ruleSet.xml')
}
gradle 1.10 uses some kind of default rules. Yes it does complain if the filepath is wrong, yes it complains if the contents are invalid. But during the checks some default ruleset will be applied. So I'm kind of suprised this worked for you.
Also see: http://forums.gradle.org/gradle/topics/with_gradle_1_5_pmd_applying_basic_rules_even_when_they_are_not_included_in_our_rule_set_files
Workaround is not to use ruleSetfiles, but reference them one by one:
ruleSets = [ "$projectRoot/buildtools/pmd-rules/strings.xml"]
Related
Just want to build a Java application with a REST API (JAX-RS implemented by Jersey 2.33) that runs in a standalone Servlet 5 container, e.g. Tomcat 10. For this the build process (via Maven) creates a *.war file which is put subsequently into the webapps/ folder to start it.
The problem is that the JAX-RS API, that is to say its servlet, is not coming up. So calling the URL
http://localhost:8080/weld/api/address
produces HTTP Status 404 (not found).
The pom.xml looks as follows:
<?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>de.test</groupId>
<artifactId>weld</artifactId>
<version>1.0.0-SNAPSHOT</version>
<packaging>war</packaging>
<name>weld Maven Webapp</name>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<maven.compiler.source>11</maven.compiler.source>
<maven.compiler.target>11</maven.compiler.target>
<servlet-api.version>5.0.0</servlet-api.version>
<jax-rs-api.version>2.1.6</jax-rs-api.version>
<jersey.version>2.33</jersey.version>
</properties>
<dependencies>
<dependency>
<groupId>jakarta.servlet</groupId>
<artifactId>jakarta.servlet-api</artifactId>
<version>${servlet-api.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>jakarta.ws.rs</groupId>
<artifactId>jakarta.ws.rs-api</artifactId>
<version>${jax-rs-api.version}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>${jersey.version}</version>
</dependency>
</dependencies>
<build>
<finalName>weld</finalName>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.3</version>
<configuration>
<failOnMissingWebXml>false</failOnMissingWebXml>
</configuration>
</plugin>
</plugins>
</build>
</project>
The required dependencies and the rest to get it to work I have read from the Jersey documentation.
The *.war doesn't contain any web.xml because since Servlet API 3.1 this is optional. The class javax.ws.rs.core.Application which should actually auto-detected and bootstrap the JAX-RS API looks as follows:
package de.test.weld;
import org.glassfish.jersey.server.ResourceConfig;
import javax.ws.rs.ApplicationPath;
#ApplicationPath("api")
public class MyApplication extends ResourceConfig {
public MyApplication() {
registerClasses(AddressService.class);
}
}
The Java class with the very endpoint looks then like this:
package de.test.weld;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;
#Path("/address")
public class AddressService {
#GET
#Produces(MediaType.APPLICATION_JSON)
public String getAddress() {
return "any text, bla, nonsense";
}
}
Anything essential seems to be missing so that the Jersey Sevlet can be started.
A glimpse into the *.war looks like this:
$> jar -tvf webapps/weld.war
0 Sat Mar 13 13:13:24 CET 2021 META-INF/
131 Sat Mar 13 13:13:22 CET 2021 META-INF/MANIFEST.MF
0 Sat Mar 13 13:13:24 CET 2021 WEB-INF/
0 Sat Mar 13 13:13:24 CET 2021 WEB-INF/classes/
0 Sat Mar 13 13:13:24 CET 2021 WEB-INF/classes/de/
0 Sat Mar 13 13:13:24 CET 2021 WEB-INF/classes/de/test/
0 Sat Mar 13 13:13:24 CET 2021 WEB-INF/classes/de/test/weld/
0 Sat Mar 13 13:13:24 CET 2021 WEB-INF/lib/
619 Sat Mar 13 13:13:24 CET 2021 WEB-INF/classes/de/test/weld/AddressService.class
1025 Sat Mar 13 13:13:24 CET 2021 WEB-INF/classes/de/test/weld/TestServlet.class
581 Sat Mar 13 13:13:24 CET 2021 WEB-INF/classes/de/test/weld/MyApplication.class
25058 Fri Mar 12 15:26:10 CET 2021 WEB-INF/lib/jakarta.annotation-api-1.3.5.jar
19479 Fri Mar 12 15:26:10 CET 2021 WEB-INF/lib/osgi-resource-locator-1.0.3.jar
1174508 Fri Mar 12 15:26:10 CET 2021 WEB-INF/lib/jersey-common-2.33.jar
942190 Fri Mar 12 15:26:10 CET 2021 WEB-INF/lib/jersey-server-2.33.jar
18140 Fri Mar 12 15:26:10 CET 2021 WEB-INF/lib/jakarta.inject-2.6.1.jar
253811 Fri Mar 12 15:26:10 CET 2021 WEB-INF/lib/jersey-client-2.33.jar
91930 Fri Mar 12 15:26:10 CET 2021 WEB-INF/lib/jakarta.validation-api-2.0.2.jar
32383 Fri Mar 12 15:26:10 CET 2021 WEB-INF/lib/jersey-container-servlet-2.33.jar
73402 Fri Mar 12 15:26:10 CET 2021 WEB-INF/lib/jersey-container-servlet-core-2.33.jar
140376 Fri Mar 12 15:11:24 CET 2021 WEB-INF/lib/jakarta.ws.rs-api-2.1.6.jar
0 Sat Mar 13 13:13:24 CET 2021 META-INF/maven/
0 Sat Mar 13 13:13:24 CET 2021 META-INF/maven/de.test/
0 Sat Mar 13 13:13:24 CET 2021 META-INF/maven/de.test/weld/
2757 Sat Mar 13 13:12:34 CET 2021 META-INF/maven/de.test/weld/pom.xml
106 Sat Mar 13 13:13:24 CET 2021 META-INF/maven/de.test/weld/pom.properties
Here are some information about the versions in use:
Java 11, Maven 3.6, JAX-RS (Jersey 2.33), Servlet API 5.0.0, Tomcat 10 or Jetty 11
You need to use Jersey 3.x. The 3.x line is the first line that makes use of the Jakarta namespace. You have all the Jakarta dependencies (JAX-RS, Servlet), just the Jersey version you are using does not make use of them. See the Jersey docs for the latest 3.x version.
In the new Jakarta EE, all the javax packaging has changed to jakarta, e.g. jakarta.ws.rs.ApplicationPath. Once you change the Jersey version (assuming you don't have any other old dependencies, you should get import errors. All the javax imports should show errors. They should all be switched out with jakarta. All the javax imports (that includes JAX-RS, Servlet, Inject, etc).
I'm trying to use webjars for bootstrap based on their documentation
<dependencies>
<dependency>
<groupId>org.webjars</groupId>
<artifactId>bootstrap</artifactId>
<version>3.1.0</version>
</dependency>
</dependencies>
This is how I start the server.
public static void main(String[] args) throws Exception {
final Server server = createServer();
try {
server.start();
server.join();
} finally {
server.destroy();
}
}
private static Server createServer() throws Exception {
final int serverPort = getServerPort();
final Server server = new Server(serverPort);
final HandlerList servletContextHandlers = new HandlerList();
servletContextHandlers.addHandler(buildServletContextHandler());
server.setHandler(servletContextHandlers);
return server;
}
private static ServletContextHandler buildServletContextHandler() throws ConfigurationException {
final ResourceConfig resourceConfig = new ResourceConfig();
resourceConfig.register(new CustomApiBinder());
resourceConfig.packages("com.foo.api");
final ServletHolder servletHolder = new ServletHolder(new ServletContainer(resourceConfig));
final ServletContextHandler servletContextHandler = new ServletContextHandler(ServletContextHandler.SESSIONS);
servletContextHandler.setContextPath("/api");
servletContextHandler.addServlet(servletHolder, "/*");
return servletContextHandler;
}
Then when I try to link the bootstrap css sheet, I get a file not found error
<link rel='stylesheet' href='webjars/bootstrap/3.1.0/css/bootstrap.min.css'>
Do I need a special handler for that? From the documentation, it says that if you use servlet 3, you don't need anything else.
Does anyone have an example without using Spring?
Jetty 9.4.9.v20180320
Jersey 2.26
The bootstrap-<ver>.jar has a META-INF/resources/ subdirectory.
$ jar -tvf bootstrap-4.0.0.jar | grep META-INF/resources
0 Thu Jan 18 21:20:32 GMT 2018 META-INF/resources/
0 Thu Jan 18 21:20:32 GMT 2018 META-INF/resources/webjars/
0 Thu Jan 18 21:20:32 GMT 2018 META-INF/resources/webjars/bootstrap/
0 Thu Jan 18 21:20:38 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/
0 Thu Jan 18 21:20:38 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/
0 Thu Jan 18 21:20:38 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/js/
43852 Thu Jan 18 21:20:38 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap-grid-jsf.css
4076 Thu Jan 18 21:20:38 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap-grid-jsf.css.gz
43852 Thu Jan 18 11:29:48 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap-grid.css
4076 Thu Jan 18 21:20:38 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap-grid.css.gz
95910 Thu Jan 18 11:29:48 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap-grid.css.map
34243 Thu Jan 18 21:20:38 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap-grid.min-jsf.css
3483 Thu Jan 18 21:20:38 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap-grid.min-jsf.css.gz
34243 Thu Jan 18 11:29:48 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap-grid.min.css
3483 Thu Jan 18 21:20:38 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap-grid.min.css.gz
76209 Thu Jan 18 11:29:48 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap-grid.min.css.map
178152 Thu Jan 18 21:20:38 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap-jsf.css
22410 Thu Jan 18 21:20:38 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap-jsf.css.gz
4798 Thu Jan 18 21:20:38 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap-reboot-jsf.css
1683 Thu Jan 18 21:20:38 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap-reboot-jsf.css.gz
4798 Thu Jan 18 11:29:48 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap-reboot.css
1683 Thu Jan 18 21:20:38 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap-reboot.css.gz
57721 Thu Jan 18 11:29:48 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap-reboot.css.map
3936 Thu Jan 18 21:20:38 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap-reboot.min-jsf.css
1584 Thu Jan 18 21:20:38 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap-reboot.min-jsf.css.gz
3936 Thu Jan 18 11:29:48 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap-reboot.min.css
1584 Thu Jan 18 21:20:38 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap-reboot.min.css.gz
25881 Thu Jan 18 11:29:48 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap-reboot.min.css.map
178152 Thu Jan 18 11:29:48 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap.css
22410 Thu Jan 18 21:20:38 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap.css.gz
411645 Thu Jan 18 11:29:48 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap.css.map
144877 Thu Jan 18 21:20:38 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap.min-jsf.css
20563 Thu Jan 18 21:20:38 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap.min-jsf.css.gz
144877 Thu Jan 18 11:29:48 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap.min.css
20563 Thu Jan 18 21:20:38 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap.min.css.gz
551641 Thu Jan 18 11:29:48 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/css/bootstrap.min.css.map
195855 Thu Jan 18 11:29:48 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/js/bootstrap.bundle.js
41578 Thu Jan 18 21:20:38 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/js/bootstrap.bundle.js.gz
326634 Thu Jan 18 11:29:48 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/js/bootstrap.bundle.js.map
67742 Thu Jan 18 11:29:48 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/js/bootstrap.bundle.min.js
19244 Thu Jan 18 21:20:38 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/js/bootstrap.bundle.min.js.gz
273872 Thu Jan 18 11:29:48 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/js/bootstrap.bundle.min.js.map
115048 Thu Jan 18 11:29:48 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/js/bootstrap.js
20137 Thu Jan 18 21:20:38 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/js/bootstrap.js.gz
195373 Thu Jan 18 11:29:48 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/js/bootstrap.js.map
48944 Thu Jan 18 11:29:48 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/js/bootstrap.min.js
13105 Thu Jan 18 21:20:38 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/js/bootstrap.min.js.gz
161998 Thu Jan 18 11:29:48 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/js/bootstrap.min.js.map
284 Thu Jan 18 21:20:32 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/webjars-requirejs.js
182 Thu Jan 18 21:20:38 GMT 2018 META-INF/resources/webjars/bootstrap/4.0.0/webjars-requirejs.js.gz
This kind of JAR is a web resource jar, and for Jetty it's only available when using a full blown WebAppContext.
Note: When using a Jetty WebAppContext all of the WEB-INF/lib/*.jar!/META-INF/resources/ contents will be unpacked into a temporary directory so that Jetty can serve the contents of those special jar files.
You have a few options from here (ordered from best/easiest choice to most complex).
Have maven unpack your META-INF/resources jars into your resources directory, that you then reference by classpath resource URL as the ServletContextHandler resource base location.
Have your own code unpack the META-INF/resources directories into a temporary directory that you then use as a the ServletContextHandler resource base directory.
Change over to using a full blown WebAppContext with a war file and all of the extra configuration necessary to enable the various features you want to use.
Note, if your eventual end goal is to build a jetty uber jar, then option 1 will be the best choice overall.
The choice you make will depend on how you eventually want to package your project up.
Will it be 1 self executing jar? Then option 1.
Will it be a collection of jars? Then options 1 and 2 are good choices.
Will it be a collection of jars and a war file? Then option 3 is a good choice.
The biggest issue with META-INF/resources based content is name collision resolution. Because of this, I encourage you to go with option 1 as this will resolve (at build time) any conflict resolution issues.
Eg: If you have 2 JAR files, both with META-INF/resources/foo.css file (but with different contents) and a request arrives for http://<host>/foo.css, which one do you serve?
For an example of Option 1 see - https://github.com/jetty-project/embedded-jetty-with-web-resources
Some embedded-jetty resources maintained by the Eclipse Jetty project:
https://www.eclipse.org/jetty/documentation/9.4.x/embedding-jetty.html
https://github.com/jetty-project/embedded-jetty-cookbook
https://github.com/eclipse/jetty.project/tree/jetty-9.4.9.v20180320/examples/embedded/
You could try to add a ResourceHandler like:
ResourceHandler resourceHandler = new ResourceHandler();
resourceHandler.setDirectoriesListed(false);
resourceHandler.setResourceBase(Main.class.getResource("META-INF/resources/webjars").toExternalForm());
ContextHandler webJarContext = new ContextHandler();
webJarContext.setContextPath("/webjars");
webJarContext.setHandler(resourceHandler);
As Joakim Erdfelt suggested, I use maven to copy the resources into the target classes.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>unpack</id>
<phase>generate-test-sources</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>org.webjars</groupId>
<artifactId>swagger-ui</artifactId>
<version>${swagger-ui.version}</version>
<type>jar</type>
<includes>META-INF/resources/webjars/**/*</includes>
<excludes>META-INF/resources/webjars/**/*index.html</excludes>
<outputDirectory>${project.basedir}/target/classes/</outputDirectory>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
I have zmq.jar built by someone else long time ago. How can I find out which version it corresponds to?
Not much in the MANIFEST:
$ cat MANIFEST.MF
Manifest-Version: 1.0
Created-By: 1.6.0_14 (Sun Microsystems Inc.)
Here's the contents. Would someone be able to tell whether it's 2.x or 3.x?
$ jar tvf zmq.jar
0 Thu Feb 02 14:59:52 EST 2012 META-INF/
71 Thu Feb 02 14:59:52 EST 2012 META-INF/MANIFEST.MF
2429 Wed Feb 01 14:24:32 EST 2012 org/zeromq/App.class
4320 Tue Jan 24 14:40:32 EST 2012 org/zeromq/EmbeddedLibraryTools.class
2392 Tue Jan 24 14:40:32 EST 2012 org/zeromq/ZContext.class
3536 Tue Jan 24 14:40:32 EST 2012 org/zeromq/ZFrame.class
920 Tue Jan 24 14:40:32 EST 2012 org/zeromq/ZMQ$Context.class
2401 Tue Jan 24 14:40:32 EST 2012 org/zeromq/ZMQ$Error.class
3232 Tue Jan 24 14:40:32 EST 2012 org/zeromq/ZMQ$Poller.class
5613 Tue Jan 24 14:40:32 EST 2012 org/zeromq/ZMQ$Socket.class
2484 Tue Jan 24 14:40:32 EST 2012 org/zeromq/ZMQ.class
771 Tue Jan 24 14:40:32 EST 2012 org/zeromq/ZMQException.class
1468 Tue Jan 24 14:40:32 EST 2012 org/zeromq/ZMQForwarder.class
1663 Tue Jan 24 14:40:32 EST 2012 org/zeromq/ZMQQueue.class
424 Tue Jan 24 14:40:32 EST 2012 org/zeromq/ZMQStreamer.class
9771 Tue Jan 24 14:40:32 EST 2012 org/zeromq/ZMsg.class
Just ask for the version!
import org.zeromq.ZMQ;
public class ZMQVersion {
public static void main (String[] args) {
System.out.println(
String.format("Version string: %s, Version int: %d",
ZMQ.getVersionString(),
ZMQ.getFullVersion()));
}
}
I am having trouble using YUI Compressor as an Ant Task within Netbeans 7.1.2 and Ant 1.8.2.
When running "minify" ant target I get the following error:
taskdef class net.noha.tools.ant.yuicompressor.tasks.YuiCompressorTask cannot be found using the classloader AntClassLoader[]
The minify ant target looks like:
<target name="minify">
<!--${libs} is path to the downloaded jars -->
<property
name="yui-compressor.jar"
location="${file.reference.yuicompressor-2.4.2.jar}" />
<property
name="yui-compressor-ant-task.jar"
location="${file.reference.yui-compressor-ant-task-0.5.jar}" />
<property
name="YUIAnt.jar"
location="${file.reference.YUIAnt.jar}" />
<path id="task.classpath">
<pathelement location="${yui-compressor.jar}" />
<pathelement location="${yui-compressor-ant-task.jar}" />
<pathelement location="${YUIAnt.jar}" />
</path>
<!-- yui-compressor task definition -->
<taskdef
name="yui-compressor"
classname="net.noha.tools.ant.yuicompressor.tasks.YuiCompressorTask">
<classpath refid="task.classpath" />
</taskdef>
<!-- invoke compressor -->
<yui-compressor warn="false" charset="UTF-8" fromdir="${build.dir}" todir="${build.dir}">
<include name="/Projects/netbeans/testproj/src/resources/insert-image-dialog.js" />
<include name="/Projects/netbeans/testproj/src/resources/anotherjs.js" />
</yui-compressor>
</target>
My Netbeans "project.properties" file looks like
dist.dir=dist
dist.jar=${dist.dir}/Dec102012.jar
dist.javadoc.dir=${dist.dir}/javadoc
endorsed.classpath=
excludes=
file.reference.yui-compressor-ant-task-0.5.jar=/Users/someuser/Downloads/yui-compressor-ant-task-0.5/bin/yui-compressor-ant-task-0.5.jar
file.reference.YUIAnt.jar=/Users/someuser/Downloads/YUIAnt.jar
file.reference.yuicompressor2.4.2.jar=/Users/someuser/Downloads/builder/componentbuild/lib/yuicompressor/yuicompressor-2.4.2.jar
includes=**
jar.compress=false
javac.classpath=\
${file.reference.yuicompressor-2.4.2.jar}:\
${file.reference.yui-compressor-ant-task-0.5.jar}:\
${file.reference.YUIAnt.jar}
Also, I tried the following:
jar -tvf yui-compressor-ant-task-0.5.jar
0 Thu Feb 25 02:15:32 EST 2010 META-INF/
102 Thu Feb 25 02:15:30 EST 2010 META-INF/MANIFEST.MF
0 Thu Feb 25 02:15:30 EST 2010 net/
0 Thu Feb 25 02:15:30 EST 2010 net/noha/
0 Thu Feb 25 02:15:30 EST 2010 net/noha/tools/
0 Thu Feb 25 02:15:30 EST 2010 net/noha/tools/ant/
0 Thu Feb 25 02:15:30 EST 2010 net/noha/tools/ant/yuicompressor/
0 Thu Feb 25 02:15:30 EST 2010 net/noha/tools/ant/yuicompressor/tasks/
2993 Thu Feb 25 02:15:30 EST 2010 net/noha/tools/ant/yuicompressor/tasks/CompressionStatistics.class
1611 Thu Feb 25 02:15:30 EST 2010 net/noha/tools/ant/yuicompressor/tasks/FileType.class
2141 Thu Feb 25 02:15:30 EST 2010 net/noha/tools/ant/yuicompressor/tasks/YuiCompressorTask$1.class
7265 Thu Feb 25 02:15:30 EST 2010 net/noha/tools/ant/yuicompressor/tasks/YuiCompressorTask.class
175 Thu Feb 25 02:15:30 EST 2010 META-INF/INDEX.LIST
Which obvious proves that "YuiCompressorTask.class" exists, which is why the error I'm getting above does not make sense.
Is there some kind of Ant Library home I need to add the jar files to? Currently I'm just adding them to the normal Netbeans classpath like most projects. I'm guessing Ant Runtime uses a different library path altogether?
From Running Apache Ant:
Additional directories to be searched may be added by using the -lib option. The -lib option specifies a search path. Any jars or classes in the directories of the path will be added to Ant's classloader. The order in which jars are added to the classpath is as follows:
-lib jars in the order specified by the -lib elements on the command line
jars from ${user.home}/.ant/lib (unless -nouserlib is set)
jars from ANT_HOME/lib
Naive question, but this is my first step in JSF, so forgive me ;-)
I am following all the steps of the first example from "Core JavaServerFaces" by David Geary, Cay S. Horstmann (the 3rd edition).
What works in general:
java works
glassfish works
I can compile the attached code
I can create .war file
The problem begins when I copy the war file into autodeploy subdirectory of GlassFish and try to show the appropriate page in GF. In return I get 404 error and in logs I find this:
Selecting file /opt/glassfish3/glassfish/domains/domain1/autodeploy/login.war for autodeployment.
Module type not recognized for module /opt/glassfish3/glassfish/domains/domain1/applications/login
There is no installed container capable of handling this application login
Autodeploy failed : /opt/glassfish3/glassfish/domains/domain1/autodeploy/login.war.
glassfish 3.1.2, java 1.6.0_29, opensuse 11.4.
The question is how to make this code work?
Updates
jar tvf login.war
0 Thu Apr 12 22:24:24 CEST 2012 META-INF/
71 Thu Apr 12 22:24:24 CEST 2012 META-INF/MANIFEST.MF
0 Mon Jun 27 10:13:54 CEST 2011 src/
0 Mon Jun 27 10:13:54 CEST 2011 src/java/
0 Mon Jun 27 10:13:54 CEST 2011 src/java/com/
0 Thu Apr 12 22:16:32 CEST 2012 src/java/com/corejsf/
603 Thu Apr 12 22:16:32 CEST 2012 src/java/com/corejsf/UserBean.java
0 Mon Jun 27 10:13:54 CEST 2011 web/
0 Thu Apr 12 21:24:56 CEST 2012 web/WEB-INF/
877 Mon Jun 27 10:13:54 CEST 2011 web/WEB-INF/web.xml
0 Thu Apr 12 22:21:38 CEST 2012 web/WEB-INF/classes/
0 Thu Apr 12 22:21:38 CEST 2012 web/WEB-INF/classes/com/
0 Thu Apr 12 22:21:38 CEST 2012 web/WEB-INF/classes/com/corejsf/
704 Thu Apr 12 22:21:38 CEST 2012 web/WEB-INF/classes/com/corejsf/UserBean.class
0 Mon Jun 27 10:13:54 CEST 2011 web/WEB-INF/beans.xml
786 Mon Jun 27 10:13:54 CEST 2011 web/index.xhtml
394 Mon Jun 27 10:13:54 CEST 2011 web/welcome.xhtml
Your WAR file is broken.
Package it up in the web folder instead. WEB-INF should be in the root.