I am using the gwt-maven-plugin and since recently I got strange errors in my IDE (eclipse oxygen). After researching it I realize that the gwt-maven-plugin is behaving differently when run in eclipse or on commandline.
On commandline everything is ok and the gwt:css creates an interface with the correct visisbility (public). But when I run it in eclipse the public is missing and thus I get all the errors in eclipse since the classes can not access the interface anymore. I am using gwt 2.6.1, JDK 1.8.0 (but build itself is with 1.6) and maven 3.5.2.
Any ideas what is causing this?
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>test</goal>
<goal>css</goal>
<goal>generateAsync</goal>
<goals>
</execution>
</executions>
<configuration>
<skip>${gwt.skipcompile.config}</skip>
<inplace>true</inplace>
<module>${gwt.module.config}</module>
<runTarget>Config.html</runTarget>
<hostedWebapp>${webappDirectory}</hostedWebapp>
<extraJvmArgs>-Xmx1024M -Xss1024k</extraJvmArgs>
<compileReport>true</compileReport>
<cssFiles>
<cssFile>MyCss.css</cssFile>
</cssFiles>
//And the code is generated like this (eclipse):
interface MyCss extends CssResource ...
//in command line
public interface MyCss extends CssResource ...
The gwt-maven-plugin delegates to GWT InterfaceGenerator and it doesn't add the public modifier. You can see the git-log and confirm that this has been always the case (already reported sometimes). So, you cannot be executing the plugin goal from the command line, you should be using something different. For example, you might have a script that adds the public modifier using awk (or something similar), and this is not executed from eclipse.
Side note: You really should upgrade GWT and gwt-maven-plugin.
Related
I'm working on a Maven Java project in VScode and I would like to use https://code.visualstudio.com/docs/java/java-linting to format and auto-correct the checkstyle errors in the source code.
I installed the extension, from command-pallet configured google_checks.xml, set checkstyle version, and then tried to trigger it from the command-palet with 'check code with checkstyle' command.
Nothing happened...
My settings.json looks as follows:
{
"java.configuration.updateBuildConfiguration": "automatic",
"java.checkstyle.configuration": "/google_checks.xml",
"java.checkstyle.version": "8.43"
}
[EDIT]
My pom.xml is:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>${maven-checkstyle-plugin.version}</version>
<configuration>
<configLocation>sun_checks.xml</configLocation>
</configuration>
<executions>
<execution>
<id>checkstyle</id>
<phase>validate</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
I forgot to mention that it's a Maven project. I activated the Maven site command, I saw 273 errors reported, then configured the extension to sun_check.xml as well but again no result when I tried to use it.
What's missing in order to trigger this extension?
The problem was a version mismatch "java.checkstyle.version" was configured to "8.43", when I changed it to "8.18" it finally worked.
I follow the tutorial: installing Checkstyle for Java, setting configuration file, then the configuration is applied to .java file immediately:
Deleting the generated settings about checkstyle, opening Command Palette and choose the option Java: Clean Java Language Server Workspace, then try again. OR please refer to goole_checks.xml and check if your code has already met the rules.
I have a project in Windows-1254 file encoding and some of files are in UTF-8 encoding.
<properties>
<project.build.sourceEncoding>Windows-1254</project.build.sourceEncoding>
<project.reporting.outputEncoding>Windows-1254</project.reporting.outputEncoding>
<version.plugin.maven.resources>3.1.0</version.plugin.maven.resources>
<functionAppName>az-app-core</functionAppName>
</properties>
I added plugin in pom and compiles correctly with mvn compile.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
<executions>
<execution>
<id>compile1</id>
<goals>
<goal>compile</goal>
</goals>
<configuration>
<excludes>
<exclude>**/StringUtil.java</exclude>
<exclude>**/TurkceInputTag_FaceLift.java</exclude>
<exclude>**/TurkceInputTag.java</exclude>
</excludes>
<encoding>Windows-1254</encoding>
</configuration>
</execution>
<execution>
<id>compile2</id>
<goals>
<goal>compile</goal>
</goals>
<configuration>
<includes>
<include>**/StringUtil.java</include>
<include>**/TurkceInputTag_FaceLift.java</include>
<include>**/TurkceInputTag.java</include>
</includes>
<encoding>UTF-8</encoding>
</configuration>
</execution>
</executions>
</plugin>
But I need to compile project by command not just clean compile but also give all configurations(defined above compile1, compile2 executions) to maven like
maven compile-plugin:compile -Dexecutions/execution1/id=compile1,encoding=Windows-1254,excludes=....
I can't change File types encoding to only UTF-8 or Windows-1254 encoding. I need to compile project using both 2 encoding.
How can maven plugin compiles by command with configurations, encoding,executions etc.?
Unfortunately the command line for Maven is not as flexible as you might like it to be for what you're wanting to achieve. (I have quite a big question about why you're trying to achieve it, and can't just specify that information in the POM as you've demonstrated).
If you look at the goal documentation for maven-compiler-plugin:compile, you'll see that some of the options, like encoding, have a 'user property'. This, prefixed with -D to make it a system property, allow you to configure it from the command line:
mvn <goals/phases> -Dencoding=... -Dmaven.compiler.failOnError=...
But running a goal from the command line will give a single execution, not the set of two that you want. So your options might be:
Run the mvn command twice, with different options on each one. Tricky though as you can't specify inclusions/exclusions.
Split the project into more than one, having different options for encoding in each, and run those from the command line.
Get around whatever limitation it is that is giving you this issue in the first place, and run from the POM as you've defined rather than on the command line.
I second khmarbaise.
All source code files in one project need to have the same encoding. Choose one and convert the other source code files.
EDIT:
You mentioned that you could not convert the files, but unfortunately, you did not tell us why.
Whatever hinders you to do it, you need to solve that issue.
So if your colleagues, managers or customers tell you not to change encoding, then you need to solve this problem by talking to these people, explaining them that a Maven project needs to have one (and just one) source code encoding and convincing them to change that.
Feel free to comment on my answer if I misunderstood you.
I see that a parameter can be configured in pom.xml or passed in the CLI such as -Dxxxxx=...
My question is if the same parameter is both configured in file pom.xml and passed in the CLI, which will be used by the maven plugin? Is there any document about this priority?
Mostly I believe CLI will override, but this real case shows the opposite.
<plugin>
<groupId>de.saumya.mojo</groupId>
<artifactId>rspec-maven-plugin</artifactId>
<version>1.0.0-beta</version>
<configuration>
<launchDirectory>${project.build.directory}/test-classes</launchDirectory>
<summaryReport>${project.build.directory}/test-Ruby.xml</summaryReport>
<specSourceDirectory>./new_test</specSourceDirectory>
</configuration>
<executions>
<execution>
<goals>
<goal>test</goal>
</goals>
</execution>
</executions>
</plugin>
When I ran
mvn test -DspecSourceDirectory=./spec
The plugin still picked the specSourceDirectory in the pom.xml which is ./new_test
I'm using maven 3.0.5, java 7, jruby 1.7.5
Got it resolved: it should be a property instead of a hardcode
<specSourceDirectory>${specSourceDirectory}</specSourceDirectory>
One thing is a plugin's configuration parameter and the other thing is Maven's invocation property (user property). For example, look at Surefire's skip configuration parameter. There is a skip parameter that can be set up by maven.test.skip property. In general these 2 names are independent, so can be either different or the same.
In your case, <specSourceDirectory>${specSourceDirectory}</specSourceDirectory> will be such a latter scenario and will work as you expect.
Attempting to modify an existing Java/Tomcat app for deployment on Heroku following their tutorial and running into some issues with AppAssembler not finding the entry class. Running target/bin/webapp (or deploying to Heroku) results in Error: Could not find or load main class org.stopbadware.dsp.Main
Executing java -cp target/classes:target/dependency/* org.stopbadware.dsp.Main runs properly however. Here's the relevant portion of pom.xml:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>appassembler-maven-plugin</artifactId>
<version>1.1.1</version>
<configuration>
<assembleDirectory>target</assembleDirectory>
<programs>
<program>
<mainClass>org.stopbadware.dsp.Main</mainClass>
<name>webapp</name>
</program>
</programs>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>assemble</goal>
</goals>
</execution>
</executions>
</plugin>
My guess is mvn package is causing AppAssembler to not use the correct classpath, any suggestions?
Your artifact's packaging must be set to jar, otherwise the main class is not found.
<pom>
...
<packaging>jar</packaging>
...
</pom>
The artifact itself is added at the end of the classpath, so nothing other than a JAR file will have any effect.
Try:
mvn clean package jar:jar appassembler:assemble
Was able to solve this by adding "$BASEDIR"/classes to the CLASSPATH line in the generated script. Since the script gets rewritten on each call of mvn package I wrote a short script that calls mvn package and then adds the needed classpath entry.
Obviously a bit of a hack but after a 8+ hours of attempting a more "proper" solution this will have to do for now. Will certainly entertain any more elegant ways of correcting the classpath suggested here.
I was going through that tutorial some time ago and had very similar issue. I came with a bit different approach which works for me very nicely.
First of all, as it was mentioned before, you need to keep your POM's type as jar (<packaging>jar</packaging>) - thanks to that, appassembler plugin will generate a JAR file from your classes and add it to the classpath. So thanks to that your error will go away.
Please note that this tutorial Tomcat is instantiated from application source directory. In many cases that is enough, but please note that using that approach, you will not be able to utilize Servlet #WebServlet annotations as /WEB-INF/classes in sources is empty and Tomcat will not be able to scan your servlet classes. So HelloServlet servlet from that tutorial will not work, unless you add some additional Tomcat initialization (resource configuration) as described here (BTW, you will find more SO questions talking about that resource configuration).
I did a bit different approach:
I run a org.apache.maven.plugins:maven-war-plugin plugin (exploded goal) during package and use that generated directory as my source directory of application. With that approach my web application directory will have /WEB-INF/classes "populated" with classes. That in turn will allow Tomcat to perform scanning job correctly (i.e. Servlet #WebServlet annotations will work).
I also had to change a source of my application in the launcher class:
public static void main(String[] args) throws Exception {
// Web application is generated in directory name as specified in build/finalName
// in maven pom.xml
String webappDirLocation = "target/embeddedTomcatSample/";
Tomcat tomcat = new Tomcat();
// ... remaining code does not change
Changes to POM which I added - included maven-war-plugin just before appassembler plugin:
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.5</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>exploded</goal>
</goals>
</execution>
</executions>
</plugin>
...
Please note that exploded goal is called.
I hope that small change will help you.
One more comment on that tutorial and maven build: note that the tutorial was written to show how simple is to build an application and run it in Heroku. However, that is not the best approach to maven build.
Maven recommendation is that you should adhere to producing one artifact per POM. In your case there are should two artifacts:
Tomcat launcher
Tomcat web application
Both should be build as separate POMs and referenced as modules from your parent POM. If you look at the complexity of that tutorial, it does not make much sense to split that into two modules. But if your applications gets more and more complex (and the launcher gets some additional configurations etc.) it will makes a lot of sense to make that "split". As a matter of fact, there are some "Tomcat launcher" libraries already created so alternatively you could use of one them.
You can set the CLASSPATH_PREFIX environment variable:
export CLASSPATH_PREFIX=target/classes
which will get prepended to the classpath of the generated script.
The first thing is that you are using an old version of appassembler-maven-plugin the current version is 1.3.
What i don't understand why are you defining the
<assembleDirectory>target</assembleDirectory>
folder. There exists a good default value for that. So usually you don't need it. Apart from that you don't need to define an explicit execution which bounds to the package phase, cause the appassembler-maven-plugin is by default bound to the package phase.
Furthermore you can use the useWildcardClassPath configuration option to make your classpath shorter.
<configuration>
<useWildcardClassPath>true</useWildcardClassPath>
<repositoryLayout>flat</repositoryLayout>
...
</configruation>
And that the calling of the generated script shows the error is depending on the thing that the location of the repository where all the dependencies are located in the folder is different than in the generated script defined.
I am currently developing a code generator, and I have built a test suite for it. The general ideia of how it is organized is depicted in the following image:
The Tests.java is a standard JUnit test class. I expect it to be on
package tests.system.bytecode.temp_tests;
as any Java developer would expect.
On the other hand, IOrderable.java and TreeSet.java are to be used by my code generator (after they are compiled to .class files, that is). But it is a bit troublesome for me to manage their current big big package declarations. The situation will only get worse as I add more tests and start to try to organize(nest) even more the tests.
It'd be perfect if IOrderable.java and TreeSet.java could have package declarations independent of their real paths, far removing future maintenance problems.
Is it possible to accomplish this with Eclipse? Maybe using Ant or Maven?
Thanks
Compiling .java classes in my Eclipse project with package declarations that don't correspond to their physical path in the project.
Should be not possible.
But you can separete the classes by different source folders.
In Eclipse you can have several source folders. When compiling they get mixed, so it would be what you need: one src folder for the normal classes and one src-gen Folder for the generated classes.
And with maven you can do the same.
There you have by default:
src/main/java
src/test/java
But you can add for example src/main/java2 or target/generated-src
Therefore you need the org.codehaus.mojo build-helper-maven-plugin. For example:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${basedir}/target/generated-src</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>