I am working on GWT + NetBeans + Maven project and I keep getting out of memory error. I am running the project simply by executing gwt:debug goal.
I tried to set higher memory limits in pom.xml like this:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>${gwt.version}</version>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>test</goal>
</goals>
<configuration>
<modules>
<module>cz.bull.iui.User</module>
<!--<module>cz.bull.iui.Login</module>-->
</modules>
<localWorkers>4</localWorkers>
<extraJvmArgs>-Xmx1024M -Xss1024k -XX:MaxPermSize=1024M</extraJvmArgs>
<localWorkers>4</localWorkers>
<draftCompile>true</draftCompile>
<logLevel>INFO</logLevel>
<failOnError>false</failOnError>
<hostedWebapp>${project.build.directory}/${project.build.finalName}</hostedWebapp>
<style>OBF</style>
</configuration>
</execution>
</executions>
</plugin>
But the problem still occurs:
Could some advise me, where do I have to set it, so GWT gets enough memory? By checking Task manager I can see Development Mode console is using about 500MB at the occurrence of crash, which is less than defined.
Please have a look at below link where a lots of the ways are suggested to set the vm arguments in Jetty.
maven jetty plugin - how to control vm arguments?
The only good answer is to switch to Eclipse, it just doesn't work with NetBeans.
Related
I'm currently evaluating Sonarqube 6.3 (a big upgrade from my current 5.5 instance) and I'm getting confused trying to work out the functionality of the sonar.test.exclusions setting.
There's this question: Sonar Maven Plugin: How do I exclude test source directories? which seems to indicate that it is used to exclude test files from analysis (which is what I'm after - I don't want my sonar ruleset run over my unit tests). The documentation https://docs.sonarqube.org/display/SONAR/Narrowing+the+Focus also indicates that it is used to 'exclude unit test files' (perhaps this can be expanded upon to make it clearer?)
Thing is, when I add sonar.test.exclusions with a value of **/src/test/** and then run my analysis, I'm still getting code smells and the like being found for:
Foo/src/test/java/foo/bar/BarTest.java
Foo/src/test/java/lah/LahTest.java
etc.
When I use sonar.exclusions instead, they don't show up. Why is sonar.test.exclusions not doing what I expect?
First of all: if you have a Maven project, you should use the scanner for Maven (mvn sonar:sonar). It will simplify your configuration, and will automatically register src/test/java folder as a test directory.
Now if you want to do the configuration manually, or understand what is going on under the hood, here is the explanation: SonarQube scanner work with 2 sets of files, main and test. Main source files are configured using the property sonar.sources. Test source files are configured using sonar.tests.
On top of that, you can filter some content using the sonar.[test.]exclusions properties.
In you case your problem is that Foo/src/test/java/foo/bar/BarTest.java seems to be considered as a main source file. That's why sonar.test.exclusions has no effect.
Using maven with verfication goal (mvn clean verify sonar:sonar install), I have used this configuration without problems:
...
<properties>
....
<sonar.exclusions>
**/generated/**/*,
**/model/**/*
</sonar.exclusions>
<sonar.test.exclusions>
src/test/**/*
</sonar.test.exclusions>
....
<sonar.java.coveragePlugin>jacoco</sonar.java.coveragePlugin>
<sonar.jacoco.reportPath>${project.basedir}/../target/jacoco.exec</sonar.jacoco.reportPath>
<sonar.coverage.exclusions>
**/generated/**/*,
**/model/**/*
</sonar.coverage.exclusions>
<jacoco.version>0.7.5.201505241946</jacoco.version>
....
</properties>
....
Coverage exclusion configuration, inside properties (up) and jacoco plugin configuracion:
.....
<build>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>${jacoco.version}</version>
<executions>
<execution>
<id>prepare-agent</id>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>report</id>
<phase>prepare-package</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
<execution>
<id>post-unit-test</id>
<phase>test</phase>
<goals>
<goal>report</goal>
</goals>
<configuration>
<dataFile>target/jacoco.exec</dataFile>
<outputDirectory>target/jacoco-ut</outputDirectory>
</configuration>
</execution>
</executions>
<configuration>
<systemPropertyVariables>
<jacoco-agent.destfile>target/jacoco.exec</jacoco-agent.destfile>
</systemPropertyVariables>
</configuration>
</plugin>
</plugins>
</build>
....
I am using Mvp4g on the gwt client side. I want to generate symbolMap that is used by RemoteLogging Servlet but when I try to generate symbol map using mvn clean install and specifying -extra folder_name property in gwt-maven-plugin configuration, I don't see the symbolMap files. It is not a plain gwt app but its gwt with mvp4g. I don't know whether its mvp4g that is causing the problem.
mvp4g generates Java code on the client side. This happens before the compiler translates the code to JavaScript. Check your settings. May be this post helps. How to generate symbol map in gwt using maven?
Update:
I use this maven configuration:
<gwt.output>myPathToTheProjectDirectory/output</gwt.output>
<gwt.gen>genSources</gwt.gen>
<gwt.extra>extra</gwt.extra>
And this for the maven-gwt-plugin:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>2.6.1</version>
<executions>
<execution>
<phase>compile</phase>
<id>bla</id>
<goals>
<goal>compile</goal>
</goals>
<configuration>
<draftCompile>false</draftCompile>
<disableClassMetadata>true</disableClassMetadata>
<compileReport>true</compileReport>
<warSourceDirectory>${gwt.war}</warSourceDirectory>
<webappDirectory>${gwt.output}</webappDirectory>
<gen>${gwt.output}/${gwt.gen}</gen>
<extra>${gwt.output}/${gwt.extra}</extra>
<fragmentCount>8</fragmentCount>
<extraJvmArgs>-Xms1G -Xmx1G -Xss1024k -XX:MaxPermSize=1024m -Dgwt.persistentunitcache=false</extraJvmArgs>
<localWorkers>7</localWorkers>
</configuration>
</execution>
</executions>
</plugin>
In case I execute maven:compile, the symbolmaps are listed inside the folder myPathToTheProjectDirectory/output/extra/symbolmaps.
Try add this: <set-property name="compiler.useSourceMaps" value="true" />
It solves the problem for me.
I'm using Vaadin 6.8.2 and Maven to develop an application.
I've tried to add the Calendar add-on (1.3.0 - the version for Vaadin 6) to my project by following step by step the tutorial from this link: https://vaadin.com/book/vaadin6/-/page/addons.maven.html
However, I when I try to load my application in browser I get the following error:
Failed to load the widgetset: /myproject/VAADIN/widgetsets/my.company.ProjectWidgetSet/my.company.ProjectWidgetSet.nocache.js
If I look in the console, I see this:
INFO: Requested resource [VAADIN/widgetsets/my.company.ProjectWidgetSet/my.company.ProjectWidgetSet.nocache.js] not found from filesystem or through class loader. Add widgetset and/or theme JAR to your classpath or add files to WebContent/VAADIN folder.
Did you run in similar problems?
Any help, please? :)
You need to compile your widgetset. To enable it, you need something like this in your pom:
<!-- vaadin update widgetset step 1: need (re)build? -->
<plugin>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-maven-plugin</artifactId>
<version>1.0.2</version>
<executions>
<execution>
<goals>
<goal>update-widgetset</goal>
</goals>
</execution>
</executions>
</plugin>
<!-- vaadin update widgetset part 2: compile -->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>2.3.0-1</version>
<configuration>
<webappDirectory>src/main/webapp/VAADIN/widgetsets</webappDirectory>
<extraJvmArgs>-Xmx512M -Xss1024k</extraJvmArgs>
<runTarget>clean</runTarget>
<hostedWebapp>${project.build.directory}/${project.build.finalName}</hostedWebapp>
<noServer>true</noServer>
<port>8080</port>
<soyc>false</soyc>
</configuration>
<executions>
<execution>
<goals>
<goal>resources</goal>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
When in place, recompile your app. You should see something similar to what is described in chapter 15.5.3 following the link you provided. It takes some time to compile the widgetset, so it cannot go unnoticed.
You also need a ProjectWidgetSet.gwt.xml and a reference to it in web.xml, but since the error message you are getting already mentions ProjectWidgetSet (as opposed to DefaultWidgetset), I am guessing you already did that.
I had the same problem 'Failed to load the widgetset: ' and it came up when I tried to run the Vernotologist demo application by fetching from svn. To solve this:
Goto your gwt.xml file and make sure it is selected in the project explorer in eclipse
Make sure your Vaadin in eclipse plugin is installed
Find the Compile Widgetset Button in Eclipse Toolbar which comes as part of the vaadin plugin and looks like a gear. Click it
Step 3 will compile the widget set for you
Restart server and re-run your application
Source:
16.2.2. Compiling the Widget Set
from Book of Vaadin at this link: https://vaadin.com/book/-/page/gwt.eclipse.html
This is an old thread but in more recent versions of Vaadin (7.x.x) the solution is quite different. No GWT plugin needed:
<plugin>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-maven-plugin</artifactId>
<configuration>
<extraJvmArgs>-Xmx512M -Xss1024k</extraJvmArgs>
<webappDirectory>${basedir}/src/main/webapp/VAADIN/widgetsets</webappDirectory>
<hostedWebapp>${basedir}/src/main/webapp/VAADIN/widgetsets</hostedWebapp>
<noServer>true</noServer>
<draftCompile>false</draftCompile>
<style>OBF</style>
<compileReport>true</compileReport>
<runTarget>http://localhost:8080/</runTarget>
<widgetsetMode>cdn</widgetsetMode>
</configuration>
<executions>
<execution>
<goals>
<goal>compile-theme</goal>
<goal>update-widgetset</goal>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
Also, make sure your ProjectWidgetSet.gwt.xml is inside resources/my/company/ folder before compiling the above.
I had same problem "failed to load widgetset.nocache.js" but I solved it by reinstalling the "vaadin" plugin
steps :
1) help -> eclipse market place -> search for vaadin ->(if it is already installed)uninstall it and again install it by clicking on the "installed" button
2)recompile the project and run it
I am having headaches trying to setup maven-as-plugin.
My goal is to redeploy an ear before running integration tests.
I want this process to be automatic to integrate it into CI.
The server is a JBoss server (AS 7) running remotely.
Thanks to infamous PermGen space issues of Jboss, I need to restart the server before
deploying the ear. Otherwise, the server will explode every 5 runs or so ...
For that purpose, I have tried to setup a goal "shutdown", with reload=true.
The issue is that maven plugin won't wait for it to be finished before running the next goal (cleaning previous artifacts).
Here is an excerpt of my POM :
<!-- Jboss Deploy/undeploy application EAR -->
<plugin>
<groupId>org.jboss.as.plugins</groupId>
<artifactId>jboss-as-maven-plugin</artifactId>
<version>7.5.Final</version>
<configuration>
<!-- JBoss management -->
<hostname>${sanity.tests.jboss.host}</hostname>
<port>${sanity.tests.management.port}</port>
<username>${sanity.tests.jboss.username}</username>
<password>${sanity.tests.management.password}</password>
</configuration>
<executions>
<!-- Reload Jboss to avoid permgen space -->
<execution>
<id>restart</id>
<phase>pre-integration-test</phase>
<goals><goal>shutdown</goal></goals>
<configuration>
<reload>true</reload>
</configuration>
</execution>
<!-- Undeploy previous ear -->
<execution>
<id>undeploy</id>
<phase>pre-integration-test</phase>
<!-- Cleanup : Undeploy -->
<goals>
<goal>undeploy</goal>
</goals>
<configuration>
<matchPattern>rm-app.*.ear</matchPattern>
<ignoreMissingDeployment>true</ignoreMissingDeployment>
</configuration>
</execution>
<!-- Deploy before int test -->
<execution>
<id>deploy</id>
<phase>pre-integration-test</phase>
<goals>
<goal>deploy-artifact</goal>
</goals>
<configuration>
<name>xxxx</name>
<groupId>xxxxx</groupId>
<artifactId>xxxx</artifactId>
<version>${project.version}</version>
</configuration>
</execution>
</executions>
</plugin>
Any help would be much appreciated.
Try running your undeploy first. If that's the only ear on the AS then the reload will most likely be quick enough for the deploy goal to not timeout.
<goals>
<goal>undeploy</goal>
<goal>shutdown</goal>
<goal>deploy</goal>
</goals>
Unfortunately, I do not know how to increase the timeout of the deploy goal.
I had exactly the same issue. switangs suggestion (first undeploy before restarting JBoss) for sure helps. Another thing i did to add some time between server restart and redeployment was to bind the undeploy and restart of the server to a very early step of the build process (e.g. initialize), whereas the deployment step was bind to process-resources or pre-integration-test as in your case. That worked because i was deploying my artifacts in a separate integration test module, which first copied all relevant server artifacts with maven-dependency-plugin plugin to the ${project.build.directory}/dependency folder as one of the first steps.
But i agree that this is not a very good solution, a blocking restart cli command for standalone JBoss nodes would be much better.
In fact, the shutdown goal won't solve the PermGen issue.
I worked this out by use cli.
<plugin>
<groupId>org.jboss.as.plugins</groupId>
<artifactId>jboss-as-maven-plugin</artifactId>
<version>7.5.Final</version>
<configuration>
<afterDeployment>
<commands>
<command>/host=master:shutdown(restart=true)</command>
</commands>
</afterDeployment>
<!-- your configuration -->
...
</configuration>
<plugin>
and "master" is the name of host in domain mode.
I have a Maven-built web-app that uses JPA 2.0 at the back end. The JPA provider is EclipseLink 2.3.2.
When I build the project (and it deploys runs successfully) it builds the JPA meta-model in the directory
${basedir}/target/generated-sources/annotations/
Yet the IDE doesn't see the classes defined there. Little red dots with an exclamation point everywhere. Yet I can navigate to those files in the Projects window and open the generated source files.
Does this happen to anyone else and does anyone know of a way to fix it?
UPDATE:
As a work-around I have discovered that I can exit NetBeans, delete the NetBeans cache directory, then restart. This forces NetBeans to rebuild the cache and then the classes become visible again. Should I submit a bug to the NetBeans bug tracker? I can't come up with a test case to make it happen, but it does fairly often.
If you go to project properties/sources there is a note about this: you need to generate sources under
${basedir}/target/generated-sources/FOOBAR
where FOOBAR is the name of your plugin.
After reading #jeqo answer, I tested if, by manually renaming:
"${project.build.directory}/generated-sources/annotations" to ".../generated-sources/hibernate-jpamodelgen"
would make a difference to Nebeans (I'm using v8.2 on ubuntu 16.04).
Everything worked like a charm.
I then modified the pom file as follows:
1) removed the "org.hibernate: hibernate.jpamodelgen" dependency.
2) configured the maven-compiler-plugin as follows:
<plugin>
<groupId>>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.6.1</version>
<configuration>
<compilerArgument>-proc:none</compilerArgument>
</configuration>
</plugin>
These two steps is to make sure that the hibernate-jpamodelgen does
not run on auto-pilot just by adding it in the project dependency
list. Please refer to JPA Static MetaModel Generator doc.
3) added the following plugin with configuration
<plugin>
<groupId>org.bsc.maven</groupId>
<artifactId>maven-processor-plugin</artifactId>
<version>3.2.0</version>
<executions>
<execution>
<id>process</id>
<goals>
<goal>process</goal>
</goals>
<phase>generate-sources</phase>
<configuration>
<processors>
<processor>org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor</processor>
</processors>
<defaultOutputDirectory>${project.build.directory}/generated-sources/hibernate-jpamodelgen/</defaultOutputDirectory>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-jpamodelgen</artifactId>
<version>5.2.9.Final</version>
</dependency>
</dependencies>
</plugin>
This config is directly from the Hibernate JPA Static Metamodel Generator documentation page except for the following line:
<defaultOutputDirectory>${project.build.directory}/generated-sources/hibernate-jpamodelgen/</defaultOutputDirectory>
This line simply generates the metamodel in the directory named after the maven plugin name. From this point, I got all Netbeans references working at design time as if the generated classes were in the src directory subtree.
Hope this helps,
J
Sometimes Netbeans has troubles refreshing. Perhaps clean and rebuild the project and restart Netbeans?
Today I did more experiments on this topic because it is so annoying for me as well. Finally I have realized it is only a problem related how NetBeans deal with indexing classes. This is not a problem of the target directory name and not a problem of the project. It is only NetBeans' mistake. So I have created an issue as well hopefully NetBeans Team can bring the final solution soon. You can see my ticket here https://issues.apache.org/jira/browse/NETBEANS-4191
In my environment the NetBeans 11.3 (x64) with openJDK 1.8.0_242-b08 and apache-maven 3.6.3 version is used under Windows 10 (1607).
But until the final solution arrives here is what I did as a workaround solving the symbol not found problem.
I have added a profile section to my pom file:
<profile>
<id>nb-modelgen-fix</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<id>modelgen-touch-files</id>
<phase>install</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<touch>
<fileset id="model.elements" dir="src/main/java" includes="**/*.java">
<containsregexp expression="(#Entity|#MappedSuperclass|#Embeddable)" casesensitive="yes" />
</fileset>
</touch>
</target>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
I am using the following simple solution to generate the metamodel classes in my project:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<annotationProcessors>
<annotationProcessor>
org.eclipse.persistence.internal.jpa.modelgen.CanonicalModelProcessor
</annotationProcessor>
</annotationProcessors>
<compilerArgs>
<arg>-Aeclipselink.persistenceunits=MY-PU</arg>
</compilerArgs>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
And of course a maven-build-helper adding the generated source folders to the project:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>3.1.0</version>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${project.build.directory}/generated-sources/annotations</source>
<source>${project.build.directory}/generated-sources/wsimport</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
And also I have created a file in the same place where the pom.xml is located called nbactions.xml with the following content (to activate this profile in NetBeans IDE only)
<?xml version="1.0" encoding="UTF-8"?>
<actions>
<action>
<actionName>rebuild</actionName>
<packagings>
<packaging>*</packaging>
</packagings>
<goals>
<goal>clean</goal>
<goal>install</goal>
</goals>
<activatedProfiles>
<activatedProfile>nb-modelgen-fix</activatedProfile>
</activatedProfiles>
</action>
</actions>
What it does? When you execute the "Clean and Build" action in NetBeans IDE it activates a task (implemented easily with maven-antrun-plugin) which just a simple touch on all JPA annotated with #Entity, #MappedSuperClass or #Embeddable theese are the sources for the metamodel generations. I have attached this task to the install phase but it worked as well in other phases as well. It lookes that this way NetBeans wake up and makes for the missing indexes for the metamodel classess.
You can read more on this in my NetBeans' issue ticket.
I hope this can save time for anybody else.
If you are using jaxws then make sure you add a <sourceDestDir> node to the <configuration> section of the jaxws plug-in "artifact" in the appropriate pom. For example:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>dojaxws</goal>
</goals>
<configuration>
<sourceDestDir>${project.build.directory}/generated-sources/jaxws</sourceDestDir>
....
</configuration>
</execution>
</executions>
<configuration>
<wsdlDirectory>src/main/resources/com/mystuff/ws</wsdlDirectory>
<bindingDirectory>src/jaxws/binding</bindingDirectory>
<target>2.0</target>
</configuration>
</plugin>
As explained above and as noted by netbeans, you must use the generate-sources path appended with the "plug-in" name. Hopefully the above clears up what "plug-in name" means and how exactly one is supposed to get jaxws to put the generated sources where netbeans need them to be. Clearly the "configuration" section will be different for each plugin... The node <sourceDestDir> is needed for jaxws, other plugins may use something else.
For me it worked after I added <endorsed.dir>${project.build.directory}/endorsed</endorsed.dir> to the <properties> of the pom.xml, e.g.:
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<endorsed.dir>${project.build.directory}/endorsed</endorsed.dir>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<jakartaee>8.0</jakartaee>
</properties>
But I have no explanation why.