Modular components for Liferay portal provided as OSGi modules use non standard Maven layout. All JSP pages are located in /src/main/resources/META-INF/resources instead of typical /src/main/webapps. Moreover, jar packaging is used instead of typical war. When such a project is opened in NetBeans, no errors or warnings are shown in JSP file even it is broken deliberately.
Example project can be found here https://github.com/liferay/liferay-blade-samples/tree/7.1/maven/apps/jsp-portlet
Can I somehow configure NetBeans to process my JSP files as usual?
NetBeans source code revealed there is some support for non-standard locations via the configuration of maven-war-plugin. So this plugin has to be present even not needed for the build:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>3.2.2</version>
<configuration>
<warSourceDirectory>/src/main/resources/META-INF/resources</warSourceDirectory>
</configuration>
</plugin>
Related
I use tomcat7 with the tomcat-maven plugin. I am able to make it hotswap my jsp but it only work if I modify it directly in the target. How can I make tomcat also look for changes in my sources directory?
pom.xml
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.2</version>
<configuration>
<serverXml>${project.build.directory}/config/tomcat-config/${usingDb}/server.xml</serverXml>
<tomcatUsers>${project.build.directory}/config/tomcat-config/tomcat-users.xml</tomcatUsers>
<configurationDir>${project.build.directory}/config/tomcat-config</configurationDir>
<additionalClassesDirs>
<classesDir>${project.basedir}/src/main/webapp</classesDir>
</additionalClassesDirs>
<contextReloadable>true</contextReloadable>
<port>${tomcat.http.local.port}</port>
<path>/${url.contextPath}</path>
</configuration>
</plugin>
This depends on how you use/start the maven plugin.
Starting it with
mvn tomcat7:run
should do the trick (in comparison to run-war or any other goal). See details at http://tomcat.apache.org/maven-plugin-2.2/tomcat7-maven-plugin/plugin-info.html
This will actually reload the context in your tomcat. I'm not sure actual "Hot replacement" without reloading the context is possible without third party libraries/plugins like jrebel or similar.
You should be able to run the war:exploded maven goal to get your changes copied from your sources directory to the target directory.
Change your workspace in Eclipse to \tomcat\webapps Since it is just for your work, this should work fine. Whatever changes you make in Eclipse is in the same directory tomcat looks for applications to deploy
I need to change the maven site documentation source folder. I've check the plugin documentation and couldn't find this configuration.
Problem scenario:
I have a maven project with several child project, and one of this child is only a angular2 project.
On the angular project, the source folder has the pom.xml and several angular files, and one of the folder used by angular is 'src' (which is there the components, services, etc are stored).
I need to add maven site to this project, and it look the source files into 'src/site/*'. This works, but this 'site' folder is mixed with several ts files, and this looks messy, so I need to change the default folder for maven site plugin.
Is there any way to change it?
If you wish to change the source directory in which Maven looks for, although I would rather recommend to clean your directory, I think what's below should work:
<build>
....
<plugins>
....
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<version>3.4</version>
<configuration>
<siteDirectory>my/site/dir</siteDirectory>
</configuration>
</plugin>
....
</plugins>
....
</build>
I created a GWT project with
mvn archetype:generate -DarchetypeGroupId=org.codehaus.mojo -DarchetypeArtifactId=gwt-maven-plugin -DarchetypeVersion=2.5.0
Imported the project in eclipse juno.
First error I get is this :
Plugin execution not covered by lifecycle configuration: org.codehaus.mojo:gwt-maven-
plugin:2.5.0:i18n (execution: default, phase: generate-sources)
In the pom file.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>2.5.0</version>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>test</goal>
<goal>i18n</goal>
<goal>generateAsync</goal>
</goals>
</execution>
</executions>
<!-- Plugin configuration. There are many available options, see
gwt-maven-plugin documentation at codehaus.org -->
<configuration>
<runTarget>dashboard.html</runTarget>
<hostedWebapp>${webappDirectory}</hostedWebapp>
<i18nMessagesBundle>com.farheap.jsi.dashboard.client.Messages</i18nMessagesBundle>
</configuration>
Also the code contains a GreetingServiceAsync that can not be found.
private final GreetingServiceAsync greetingService = GWT.create(GreetingService.class);
You have two options:
You can add special (non-trivial) org.eclipse.m2e:lifecycle-mapping plugin
configuration to your POM. See here: Why am I receiving a "Plugin execution not covered by lifecycle configuration with GWT" error?
Or mark this issue as to be ignored in Eclipse POM editor, and then call mvn gwt:i18n. You can create a handy short cut launcher for it. Eclipse remembers your decisions what to ignore, it stores it into .settings directory permanently for the project.
In course of typical development localization messages do not change often so the second option is usually more convenient and speeds up build.
This applies for most GWT plugin goals! Even GWT compilation is rarely necessary as DevMode works directly with Java code and not generated JavaScrips. So in practice, you have to call all the goals at least once on the beginning and then live weeks without them; basic Eclipse JDT compilation is sufficient.
If you later decide not to use GWT localization framework in your real app then you can remove goal i18n completely from POM. Calling goal i18n generates file {project}/target/generated-sources/gwt/my/code/client/Messages.java which is required by (vanilla) Sample.java.
Also the code contains a GreetingServiceAsync that can not be found.
Run the build mvn install from command line or Eclipse Run as -> Maven install menu.
In case of command line mvn gwt:generateAsync should be enough. This goal generates {project}\target\generated-sources\gwt\my\code\client\GreetingServiceAsync.java and that is what you missing. Eclipse did not do it for you automatically because it was blocked by previous issue of i18n not being covered by lifecycle configuration. So yes, issues you mention are correlated.
I was able to follow the tutorial here and convert it to a Maven application.
I got the loading part right, but when I try to use it, it can't find the appropriate swt classes (When ran from windows 64). I did it on a Maven project. Here's the relevant part of the respective pom for the Windows 64 module:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>nbm-maven-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<!-- To have the jar plugin pickup the nbm generated manifest -->
<useDefaultManifestFile>true</useDefaultManifestFile>
<moduleType>normal</moduleType>
swt.windows.64/1</codeNameBase>
<publicPackages>
<publicPackage>org.eclipse.swt</publicPackage>
</publicPackages>
</configuration>
</plugin>
I translates to org.eclipse.swt.*. It seems to be a Maven module issue since it already tries to load from correct module.
Caused: java.lang.ClassNotFoundException: org.eclipse.swt.SWT starting from ModuleCL#25e0dee5[djproject.core] with possible defining loaders [ModuleCL#6783113b[swt.windows.64]] and declared parents [ModuleCL#32821bf7[org.netbeans.api.annotations.common]]
Caused: java.lang.NoClassDefFoundError: org/eclipse/swt/SWT
at chrriis.dj.nativeswing.swtimpl.core.SWTNativeInterface.initialize_(SWTNativeInterface.java:213)
at chrriis.dj.nativeswing.swtimpl.NativeInterface.initialize(NativeInterface.java:71)
at chrriis.dj.nativeswing.swtimpl.core.SWTNativeInterface.open_(SWTNativeInterface.java:337)
at chrriis.dj.nativeswing.swtimpl.NativeInterface.open(NativeInterface.java:100)
at synamicd.windows64.support.Windows64BrowserProvider.initialize(Windows64BrowserProvider.java:25)
Any help is more than welcomed!
Edit:
Code is available here.
when I try to build the application at the bitbucket location, it's build order suggests that none of the swt modules are used in the app - http://screencast.com/t/LMxIPy6A6ZUL
Applications built on top of the NetBeans platform have a <myappdir>/etc/<myapp>.conf file determining, among other things, application JVM parameters. Historically, this file was a part of the NetBeans IDE installation (as far as I could tell), but starting with NB 6.9, custom files are now supported.
I am having trouble packaging a custom configuration file using Maven to build the application.
I imagine the app.conf property should have been set in the project's pom under project/build/pluginManagement/plugins like so:
<plugin>
...
<configuration>
<brandingToken>${brandingToken}</brandingToken>
<cluster>${brandingToken}</cluster>
<appConf>myapp.conf</appConf>
</configuration>
The maven module representing my application contained no prior source, so I created the src/main/nbm folder and placed myapp.conf in src/main/nbm. This isn't picked up by nbm-maven-plugin. and putting the conf file into src/main/resources doesn't make a difference.
So, can anyone explain how a NetBeans Platform application with a custom configuration file can be built using maven?
UPDATE:
With Tim's prod in the right direction, I found the answer documented on Geertjan's blog. The solution is to configure the nbm-maven-plugin like so in the application module pom:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>nbm-maven-plugin</artifactId>
<configuration>
<etcConfFile>src/main/resources/my.conf</etcConfFile>
</configuration>
</plugin>
</plugins>
</build>
BTW, if you need a second name with Geertjan, you're not really a NetBeans platform developer. ;)
Have a look at the documentation of the nbm:cluster-app plugin, specifically the part on the conf file.
As per my understanding that should allow you to replace the default one with a custom one that you create.