How to resolve the playN asset path error? - gwt

I am getting the following error when I run my playN project.
"No file found for: /myproject/myproject.nocache.js"
Also I am getting only a black screen in the browser.
In the MyProjectHtml.java file I am giving the path as
"platform.assets().setPathPrefix("myproject/");"
How can I resolve this problem. I am not finding any file with the name "nocache".
Note: The comment in one of my previous question's answer will be useful: How to Run my playN game in production mode locally?
Thank you.
SOLVED: the resource folder under war was getting generated using eclipse compile only.I have created a source folder src/main/resources and moved all my resources package to it. Before it was under src/main/java. Now it works..! I can compile from terminal and run.

Are you running the project via Maven (mvn test -Ptest-html) or as GWT project (mvn gwt:run)?
The first case should work if your path is set correctly, but running it as a GWT project has always failed for me.
I also suggest doing a mvn clean install, and seeing which resources are contained within your .war file. Your .nocache.js file should be in there, if not, you probably have a bigger issue (incorrect project setup).
Update:
Seeing as you don't have the .nocache.js file in your war something is wrong with your Maven configuration. See if the following config has been added to your HTML pom in your plugins tags:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<executions>
<execution>
<phase>prepare-package</phase>
<goals>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
Either way, your HTML version won't run until you see the .nocache.js in your war file. Double-check your Maven configuration with a new PlayN project, and see where there are differences.

Related

Preserving Manifest.mf when building via sbt assembly

When I build my project using sbt assembly, I get java.util.zip.ZipException: duplicate entry: META-INF/MANIFEST.MF. The solution that google recommends, is to use MergeStrategy.discard.
That works in getting the project to build - but it crashes at runtime, because Dropwizard (a dependency) relies on info contained in manifest.mf (full issue details: https://github.com/dropwizard/dropwizard/issues/455 ).
The recommendation when encountering that error, is to merge the manifests.
I've tried all the MergeStrategies on Manifest.MF that seem like they'd do the trick (filterDistinctLines, concat, first, last), they all cause the build to fail with java.util.zip.ZipException: duplicate entry: META-INF/MANIFEST.MF. The only thing that compiles is discard, but that causes the program to crash at runtime due to Dropwizard relying on the mf file.
Any ideas what to do here? Is there a way to merge the manifests as described in the comments at https://github.com/dropwizard/dropwizard/issues/455 ?
So I ended up doing this:
Separated the Scala & Java projects
Build the sbt project as is - copy it to the java project/lib directory
Added a system dep for lib/scala project, and used the add-jar plugin to add this jar to the classpath when building the fatjar:
<plugin>
<groupId>com.googlecode.addjars-maven-plugin</groupId>
<artifactId>addjars-maven-plugin</artifactId>
<version>1.0.5</version>
<executions>
<execution>
<goals>
<goal>add-jars</goal>
</goals>
<configuration>
<resources>
<resource>
<directory>${real.base.dir}/lib</directory>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
Build the java project fatjar and deploy it - it now has access to the scala jar on the classpath.
Script (server is the name of the java project i made):
sbt clean assembly
cp target/scala*/project*.jar server/lib
cd server
mvn clean install
cd ../
cp server/target/server*.jar target

Why is maven running the same pom differently on two computers?

Me and my workmate are trying to call the same Maven command (mvn site) on exactly the same pom and getting totally different output.
The code of which we think is going wrong, is the javadoc-plugin we added lately:
<!-- https://maven.apache.org/plugins/maven-javadoc-plugin/ -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>${version.javadoc.plugin}</version>
<configuration>
<destDir>javadoc</destDir>
<charset>UTF-8</charset>
<docencoding>UTF-8</docencoding>
<doctitle>${project.name} API Documentation
${project.version}.${svn_revision}</doctitle>
<encoding>UTF-8</encoding>
<failonerror>false</failonerror>
<footer>Specification: ${specification.title}</footer>
<header>${project.name} API Documentation
${project.version}.${svn_revision}</header>
<source>1.8</source>
<use>true</use>
<version>true</version>
<windowtitle>${project.name} API Documentation
${project.version}.${svn_revision}</windowtitle>
<additionalparam>-Xdoclint:none</additionalparam>
</configuration>
<executions>
<execution>
<id>attach-javadocs</id>
<phase>deploy</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
Running this gets me the correct javadoc-generation in the targeted folder. When I pushed it to the svn repository and my mate downloaded, it was not working for him.
There is no Error and no warning, it just does not generate the javadoc.
Additional info:
We are not using any local settings.xml.
The output of mvn site -X (debug mode) does not make any difference regarding the javadoc-plugin.
He already reinstalled jdk and re-set his $JAVA_HOME.
Same Maven version
What could be the problem?
Thank you in advance
Run mvn -v to make sure you're using the same Maven and Java versions. The command will print the paths to the Java runtime, make sure they are same and correct.
If that checks out, run mvn help:effective-pom to see what Maven will execute. Redirect the output on both machines to a file and compare them.
Next, try to invoke the plugin directly from the command line. If that works, attaching to the life cycle doesn't work for some reason. If it doesn't work, check for error messages and use -X to check the plugin configuration.
If everything else fails, delete your local Maven repository (or at least the involved plugins).

How to run the project after building with maven

I am new to maven. So I have a project with pom.xml file. So I ran that with maven and the build was successful. I have glassfish. Glassfish is already running separately. So now what is the next step to run the project with Glassfish? My IDE is eclipse.
You have to first tell Maven to build the WAR, check out this plugin for that: http://maven.apache.org/plugins/maven-war-plugin/.
Then you need to tell maven how to deploy to glassfish, you can either configure a Maven execution plugin to do this (see here: https://www.mojohaus.org/exec-maven-plugin/). Or you can look around for a custom plugin devoted to integrating maven with glassfish. This one looks promising, but I have not used it: http://maven-glassfish-plugin.java.net/.
Maven provides a lot of basic functionality out of the box, but most of the cooler stuff with build automation is done through plugins.
Update
Just updating to add a very simple Pom that will do a auto-deployment. Note: if you just run a "mvn clean install", with the packaging set to 'war', maven will build the .war file for you and place it in the target/ folder. You can take this and deploy it to glassfish manually if you just want to get started.
Below is part of a very simple pom that uses the Maven execution plugin to auto-deploy to glassfish as a function of the build:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>exec</goal>
</goals>
<phase>install</phase>
</execution>
</executions>
<configuration>
<executable>${path-to-asadmin-util}</executable>
<arguments>
<argument>deploy</argument>
<argument>--user=${username}]</argument>
<argument>--passwordfile=${password-file}</argument>
<argument>--host=localhost</argument>
<argument>--port=4848</argument>
<argument>target/${project.name}</argument>
</arguments>
</configuration>
</plugin>
</plugins>
</build>
This basically just calls the deploy command on the glassfish asadmin utility[1]. You need to fill in the following variables:
${path-to-asadmin-util} --> this is the path to your asadmin utility
(normally in the glassfish_home/bin)
${username} --> glassfish admin username
${password-file} --> password file for logging into glassfish
admin[2]
${project.name} --> name of your war
If you want to get more complicated I suggest taking a look at this thread: GlassFish v3 and glassfish-maven-plugin (Mac).
[1] - http://docs.oracle.com/cd/E18930_01/html/821-2433/deploy-1.html#SJSASEEREFMANdeploy-1
[2] - http://docs.oracle.com/cd/E18930_01/html/821-2435/ghgrp.html#ghytn
Additonnaly, you should have a glance at this StackOverflow thread, dealing with maven deployement in glassifsh : https://stackoverflow.com/a/1836691/1047365.
For further understanding of Maven, you should REALLY read this (free) book : http://www.sonatype.com/books/mvnref-book/reference/. This is THE reference for Maven.
We can explain you what Maven is doing, producing, etc ... but Sonatype made a great work and you'll probably learn more reading it than we could ever do !
Regards.
I found this tutorial useful: http://tshikatshikaaa.blogspot.com/2012/05/introduction-to-maven-concepts-crash.html

How can I run a Maven webapp in Eclipse when I need resource filtering for properties files?

I need to get some updates on this issue, I found this thread back in 2009 here, but the answer was to use maven 2, I'm not sure if Q4E works with maven 3 or not. I need to have some properties files filtered during the mvn package phase for the resulting war to be functional, the resource filtering is working fine with CLI mvn install. But when I do "Run on server/debug on server", the filtering is not working any more.
The aforementioned thread author ended up using q4e, claiming q4e gets the resource filtering right. I have q4e installed as well along with m2e, but still doesn't work, so I don't know if q4e is not working with maven 3, or I'm doing something wrong.
Thanks,
David
updated to the latest m2e-wtp plugin 0.15 (resource filtering bug fix since 0.12), it works fine now.
I'm not sure if this matches your problem, but I wanted to populate my web.xml file with properties from the pom during build and I put a groovy script in the pom to do it. It worked a treat and might work for you too. It definately works in both eclipse and on the command line. Here is my pom fragment:
<plugin>
<!-- Groovy script to set the description and version in the web.xml display name -->
<groupId>org.codehaus.groovy.maven</groupId>
<artifactId>gmaven-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<id>groovy-magic</id>
<phase>prepare-package</phase>
<goals>
<goal>execute</goal>
</goals>
<configuration>
<source>
def file = new File("src/main/webapp/WEB-INF/web.xml");
def fileText = file.text;
def match = "<display-name>[^<]*</display-name>";
def replace = "<display-name>"+project.description+" "+project.version+"</display-name>";
fileText = fileText.replaceAll(match, replace);
file.write(fileText);
println "Updated web.xml"
</source>
</configuration>
</execution>
</executions>
</plugin>

Requestfactory Validation on Multi-Project Setup

I tried changing to the release version of gwt2.4 and run into a problem. I use multiple projects in my setup. I have a project with serverside code, one project with shared code, that can be used in different gwt projects and a gwt project binding everything together. I build everything with maven. i followed the instructions for annotationprocessing found here:
http://code.google.com/p/google-web-toolkit/wiki/RequestFactoryInterfaceValidation
when I compile my shared project, where the proxies and services are, the folder "generated-sources\apt\" with the DeobfuscatorBuilder.java is created. I have the sources of this project as dependency of my mainproject and try to run the validator as well, but the DeobfuscatorBuilder.java is not created here. Everything compiles but when I invoke a call to the requestfactory I get the error:
com.google.web.bindery.requestfactory.server.UnexpectedException: No RequestContext for operation ZwI9iqZS626uTt_TFwRtUwPYSOE=
I guess there is an mistake in my setup, but I could't find where ..
Does anybody know how to solve this problem?
Regards
arne
UPDATE:
I added this to my pom:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>unpack</id>
<phase>initialize</phase>
<goals>
<goal>unpack</goal>
<!-- <goal>build-classpath</goal> -->
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>com.myproject.core</groupId>
<artifactId>shared</artifactId>
<version>${shared.version}</version>
<classifier>sources</classifier>
<overWrite>true</overWrite>
<outputDirectory>${project.build.directory}/com.myproject.shared</outputDirectory>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
This unpacks the sources of my dependencies and puts them into my target folder.
Then I added:
<configuration>
<sourceDirectory>target/com.fileee.shared</sourceDirectory>
</configuration>
to my processor-plugin.
This way it is not necessary to have all the projects in the workspace and it should work with a continous integration system. Wouldn't have figured that out without Andys reply though :)
I had the same issue and spent hours scouring the web for an answer without any luck. If I add the processor plugin to the shared project, it generates the DeobfuscatorBuilder class, but I get the same No RequestContext exception as you. If I just have the processsor plugin on the GWT war project, the builder isn't generated at all.
With a fair amount of trial and error I found adding the source directory from the shared project into the processor plugin configuration on the war project worked...
http://code.google.com/p/android-shuffle/source/browse/shuffle-app-engine/pom.xml#269
It's a bit dirty, but it does the trick. If there's an official method that doesn't require cross project hackery I'd be more than welcome to switch, but I haven't seen anything suggested yet.
Cheers
Andy