liferay-maven-plugin + direct-deploy configuration for DXP - maven

I'm currently on Liferay 6.2 (with Tomcat), and I can configure the liferay-maven-plugin in my Liferay hook project's maven pom.xml as below, in order to pre-process my hook WAR for hot deployment (using the direct-deploy goal of the plugin).
<plugin>
<groupId>com.liferay.maven.plugins</groupId>
<artifactId>liferay-maven-plugin</artifactId>
<version>6.2.1</version>
<executions>
<execution>
<id>pre-process-war</id>
<phase>package</phase>
<goals>
<goal>direct-deploy</goal>
</goals>
</execution>
</executions>
<configuration>
<appServerDeployDir>${project.basedir}/target/liferay-pre-process</appServerDeployDir>
<liferayVersion>6.2.1</liferayVersion>
<pluginType>hook</pluginType>
<unpackWar>false</unpackWar>
</configuration>
</plugin>
I'm now trying to migrate this hook to Liferay 7.2.1 CE. There is no plan to redesign this as an OSGI module at the moment i.e. it would continue to be packaged as a WAR. So how would my new direct-deploy configuration look like, with Liferay 7.2.1? Specifically:
a) Can I continue using the same Maven plugin? I see from this doc that the liferay-maven-plugin has been "removed", yet my understanding from other help pages is that this plugin should not be used only with the newer, OSGI-module style plugins (the latter makes more sense to me).
b) If I can continue using the same Maven plugin, which version of the plugin works with 7.2.1? Also, which liferayVersion value should I use here? I tried a bunch of combinations and none of them worked.
For instance, I first tried liferayVersion 7.2.1 but the build failed while running the direct-deploy goal, since Maven didn't find a com.liferay.portal:portal-web artifact with that version. So I tried the latest version of that artifact from Maven Central, which is 7.0.2, as my liferayVersion. But the build failed again, this time because it couldn't locate the corresponding version of com.liferay.portal:portal-service. There's no 7.x version of portal-service though, which makes sense because it's been replaced with the portal-kernel artifact. Not specifying liferayVersion doesn't work either.

I received a response in a Liferay forum which suggests that the liferay-maven-plugin has indeed been removed in Liferay 7.x, and so the only option left is to copy the WAR to Liferay's deploy folder and let it do the pre-processing at deploy time (as opposed to doing this at build time, with the Maven plugin). Given the lack of alternatives at this point, that seems to be the only way forward (and it works).

Related

Remote Deploy to WebSphere 8.5 using maven

I would like to control a remote deployment of a maven generated EAR over to an existing WAS instance not running on the build server.
Ideally, I would like to do this within Maven so that I can remote deploy in say the integration-test phase then proceed to run some JMeters in the verify phase. I guess this is pretty standard.
I have looked around and am unable to find a sensible way to do this in WAS 8.5.
There are a few posts:
Remote Deployment to WAS 6.1
websphere7am-maven-plugin
Cargo
and others around the web, including IBM. None seem to offer a way to achieve a remote deploy to WAS 8.5
Does anybody have a solution?
EDIT 1:
Further confirmation from IBM that no official maven solution exists can be found here:
WAS 8.5 - Using Ant to automate tasks
AFAIK there is no Maven plugin for full-fledged WAS 8.5, only for WAS Liberty Profile. But that one does not support deployment to remote server.
Remote deployment can be done using WsAdmin Ant Task & Maven AntRun Plugin
<plugin>
<groupId>com.orctom.mojo</groupId>
<artifactId>was-maven-plugin</artifactId>e
<version>1.0.8</version>
<executions>
<execution>
<id>deploy</id>
<phase>install</phase>
<goals>
<goal>deploy</goal>
</goals>
<configuration>
<wasHome>${env.WAS_HOME}</wasHome>
<applicationName>${project.build.finalName}</applicationName>
<host>${local or remote address}</host>
<server>server01</server>
<node>node01</node>
<virtualHost>default_host</virtualHost>
<verbose>true</verbose>
</configuration>
</execution>
</executions>
</plugin>
From https://github.com/orctom/was-maven-plugin
Updated on 5/29/2014
Developer of this plugin states on github, "1.0.1 and 1.0.2 is not working, please don't use them!", so I've updated this answer to show version 1.0.3.
Updated on 1/27/2015
Updated to '1.0.8'.
You will soon be able to automatically deploy to WebSphere remotely using Jenkins. You can create a maven project and have Jenkins automatically deploy to WebSphere with the plugin listed below. If you're interested, follow it since I'll be taking feature requests for a limited time.
https://wiki.jenkins-ci.org/display/JENKINS/WebSphere+Deployer+Plugin
Enjoy!
we're using was6-maven-plugin to perform both local and remote deployments to WAS 7. Internally this plugin uses ant tasks from wsadmin so I guess it would also work with WAS 8.5.

SoapUI Maven plugin has weird dependencies

I'm trying to use the SoapUI Maven plugin as shown here: http://www.soapui.org/Test-Automation/maven-2x.html
I can't add the eviware repository, since I'm behind a corporate firewall (only the browser can connect to the outside world) and have to use the local artifactory repo (which mirrors maven central).
So I tried downloading the appropriate jars and poms from the eviware repo and adding them to the local artifactory. Now it seems I've gone down the rabbit hole, the SoapUI plugin has more and more dependencies that I need to add. At first I didn't mind, but we're looking at tens of jars now, and most of them seem to be things that should be in maven central. But then I saw that most of these have altered group-IDs - for example there is a jetty dependency that uses "jetty" as group-ID instead of the canonical "org.mortbay.jetty". And this seems to be the case for many of these dependencies.
So my question has two sides: What are the SoapUI folks doing here? This seems fishy to me, or am I overlooking something?
And second, can I somehow make the plugin use the canonical jars instead of having to chase all the stuff that's in eviware's repository?
Have a look on this soapui forum, I explain why soapui uses weird maven coordinates and what could be done to use regular ones.
I have already complained about the problem on this post and I am sure that SoapUI dev are aware of the problem. Sadly, there is no current work to fix it.
I have tried relentlessly to use the maven-soapui-plugin, but It didn't work for me. However the maven-soapui-extension-plugin mentioned by pppeater and developed by redfish above has worked fine when I tried it. I have used artifactory as my repo manager.
First configure the plugin on your pom
<plugin>
<groupId>com.github.redfish4ktc.soapui</groupId>
<artifactId>maven-soapui-extension-plugin</artifactId>
<version>4.6.3.0</version>
<executions>
<execution>
<id>soapui-tests</id>
<phase>verify</phase>
<goals>
<goal>test</goal>
</goals>
</execution>
</executions>
<configuration>
<projectFile>${basedir}/src/test/soapui/airline-sample-soapui- project.xml</projectFile>
<outputFolder>${basedir}/target/soapui</outputFolder>
<junitReport>true</junitReport>
<exportwAll>false</exportwAll>
<printReport>false</printReport>
</configuration>
</plugin>
You still need to add the soapui plugin to your repo manager remote repositories and virtual repositories list using the url http://www.soapui.org/repository/maven2/
Just came across this plugin: https://github.com/redfish4ktc/maven-soapui-extension-plugin which notes: "starting from soapui 3.6.1, almost all SmartBear plugin versions have missing dependencies. This is fixed in maven-soapui-extension-plugin"
It also appears to address some Groovy dependencies which others have noted as an issue with the plugin.

how to deploy Maven dependencies automatically into JBoss as OSGI bundles?

I have a project that deploys an standalone OSGí Apache ServiceMix application. It has tons of dependencies and it is built with Maven. Now I want to deploy this application into a JBoss AS. I found an interesting Maven plugin called jboss-as-maven-plugin (org.jboss.as.plugins) to deploy anything. I use maven-bundle-plugin (org.apache.felix) to construct my bundles and it works fine, but when I deploy the project bundles, the deployment fails because dependencies are not satisfied.
How can I automatically bundle and deploy all the dependency tree with a Maven goal? Is it possible? My project has dozens of dependencies declared on the pom.xml and some of them are other projects in my workspace.
Currently the only solution to this I know are the Karaf features. You can create a feature file out of your pom dependencies.
I found that jboss seems to support subsystems. That may help to specify the bundles required to run your application. It does not seem to be the OSGi subsystem spec but for jboss this may already help. For OSGi spec 5 there is the standardized subsystem spec which may provide a standard way to do this across containers.
If jboss supports OBR (OSGi bundle repository) then you can limit the number of dependencies you have to specify.
If your application do not use OSGi per see, you may consider packing your application as a WAR which is deployable in JBoss.
Then you would need to use web.xml to bootstrap your application, such as using a Spring XML file.
There is a Camel example as a WAR here: http://camel.apache.org/servlet-tomcat-example.html
You can autoinstall your bundles with org.apache.sling plugin
<plugin>
<groupId>org.apache.sling</groupId>
<artifactId>maven-sling-plugin</artifactId>
<executions>
<execution>
<id>install-bundle</id>
<goals>
<goal>install</goal>
</goals>
</execution>
</executions>
<configuration>
<slingUrl>http://localhost:8181/system/console/install</slingUrl>
<user>karaf</user>
<password>karaf</password>
</configuration>
</plugin>
you can find detailed pom.xml from Adobe website :https://docs.adobe.com/docs/en/cq/5-6-1/developing/developmenttools/how-to-build-aem-projects-using-apache-maven.html
or http://www.cqblueprints.com/tipsandtricks/build-and-deploy-osgi/build-deploy-osgi-1.html

Generated project with gwt-maven-plugin : eclipse

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.

How should I get Maven to deploy artifacts for all supported architectures at the same time?

I have a question that's probably pretty similar to this. I need to solve what I have to imagine to be a pretty common problem -- how to configure Maven to produce multiple variations on the same artifact -- but I have yet to find a good solution.
I have a multi-module project, that eventually results in the assembly plugin generating an artifact. However, part of the assembly includes libraries that have changed substantially in the recent past, with the result that some consumers of the project need library version N, while others need version N+1. Ideally, we'd just automatically generate multiple artifacts, e.g. theproject-1.2.3.thelib-1.0.tar.gz, theproject-1.2.3.thelib-1.1.tar.gz, etc. (where that's release 1.2.3 of our project, running against either library version 1.0 or 1.1).
Right now, I have a bunch of default properties, which build against the latest version of the library in question, plus a profile to build against the older version. I can deploy one or the other this way, but cannot deploy both in one build. Here's the key wrinkle that differs from the above question: I can't automate build-one-clean-build-the-other inside of the release plugin.
Normally, we'd mvn release:prepare release:perform from the root of the multi-module project to take care of deploying everything to our internal Nexus. However, in that case, we have to pick one -- either run the old-library profile, or run without and get the new one. I need the release plugin to deploy both. Is this just impossible? I have to imagine we're not the first people who want to have our automated builds generate support for different platforms....
You may install additional artifacts with differrent types/classifiers. Use attach-artifact goal of the build-helper-maven-plugin to achieve this. Here is a small example - we are deploying a Windows and a Unix installers of the product as windows/exe and unix/sh files. These files will be installed to the local repo and deploy to the distribution management.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<id>install-installation</id>
<phase>install</phase>
<goals>
<goal>attach-artifact</goal>
</goals>
<configuration>
<artifacts>
<artifact>
<file>${basedir}/target/${project.artifactId}-${project.version}-windows.exe</file>
<classifier>windows</classifier>
<type>exe</type>
</artifact>
<artifact>
<file>${basedir}/target/${project.artifactId}-${project.version}-unix.sh</file>
<classifier>unix</classifier>
<type>sh</type>
</artifact>
</artifacts>
</configuration>
</execution>
</executions>
</plugin>
Hope this helps.

Resources