Retrieving external .proto files for protoc with protobuf-maven-plugin - maven

Context: My team is working on making our suite of Java services containerized and dynamically scalable. To accomplish this, our plan is to use Envoy backed by etcd, with a custom-build Endpoint Discovery Service as described in the Envoy documentation, using the v2 gRPC-based API. We'll then generate Docker images for each service and deploy/manage them with Kubernetes.
We use Maven as a build system. I'm pretty well versed in Maven, but this is my first time with gRPC or protocol buffers.
I've created a stub for my service using Spring Boot, with Jetty offering some REST and JMX endpoints for management. Before introducing the protobuf stuff, the stub built and ran just fine.
I've downloaded the Envoy data-plane-api and checked the API definition files (**/*.proto) into my project under src/main/proto, keeping the directory structure from the download (e.g. src/main/proto/envoy/api/v2/eds.proto). (Side question: do I need the BUILD files?)
In the end, I'd like a standalone Maven build that can read these files and generate Java classes. The build needs to work on Windows and OS X boxes so that it works for developers, and on Linux boxes so that it works in our CI (Bamboo). It should require nothing more than a JDK, a Maven install, and a Maven repo. (We have an Artifactory instance where I can upload artifacts not otherwise available online, if necessary.)
What I have so far seems like it will accomplish my portability goals:
pom.xml:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<artifactId>discovery-service</artifactId>
<packaging>jar</packaging>
<name>Discovery Service</name>
<version>1.0.0</version>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.7.0</version>
<configuration>
<verbose>true</verbose>
<fork>true</fork>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
<plugin>
<groupId>org.xolstice.maven.plugins</groupId>
<artifactId>protobuf-maven-plugin</artifactId>
<version>0.5.1</version>
<configuration>
<protocArtifact>com.google.protobuf:protoc:3.5.1-1:exe:${os.detected.classifier}</protocArtifact>
<checkStaleness>true</checkStaleness>
</configuration>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>test-compile</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
<extensions>
<!-- provides os.detected.classifier (i.e. linux-x86_64, osx-x86_64) property -->
<extension>
<groupId>kr.motd.maven</groupId>
<artifactId>os-maven-plugin</artifactId>
<version>1.4.1.Final</version>
</extension>
</extensions>
</build>
<dependencies>
<dependency>
<groupId>io.hydrosphere</groupId>
<artifactId>envoy-data-plane-api_2.11</artifactId>
<version>v1.5.0_1</version>
</dependency>
<dependency>
<groupId>com.google.protobuf</groupId>
<artifactId>protobuf-java</artifactId>
<version>3.5.1</version>
</dependency>
<dependency>
<groupId>io.grpc</groupId>
<artifactId>grpc-core</artifactId>
<version>1.9.1</version>
</dependency>
<dependency>
<groupId>io.grpc</groupId>
<artifactId>grpc-protobuf</artifactId>
<version>1.9.1</version>
</dependency>
<!--Unrelated deps (Spring Boot, Jetty, logging, etc) omitted for brevity -->
</dependencies>
</project>
When I build this project using mvn compile, Maven correctly downloads protoc and invokes it, but protoc errors because it can't find some external dependencies:
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Detecting the operating system and CPU architecture
[INFO] ------------------------------------------------------------------------
[INFO] os.detected.name: osx
[INFO] os.detected.arch: x86_64
[INFO] os.detected.classifier: osx-x86_64
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Discovery Service 1.0.0
[INFO] ------------------------------------------------------------------------
Downloading: http://devutl1.sircon.com:8081/artifactory/libs-snapshot/org/glassfish/javax.el/maven-metadata.xml
Downloading: http://devutl1.sircon.com:8081/artifactory/libs-release/org/glassfish/javax.el/maven-metadata.xml
Downloaded: http://devutl1.sircon.com:8081/artifactory/libs-release/org/glassfish/javax.el/maven-metadata.xml (882 B at 547 B/s)
Downloaded: http://devutl1.sircon.com:8081/artifactory/libs-snapshot/org/glassfish/javax.el/maven-metadata.xml (882 B at 547 B/s)
[INFO]
[INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (default-cli) # discovery-service ---
[INFO]
[INFO] --- protobuf-maven-plugin:0.5.1:compile (default) # discovery-service ---
[INFO] Compiling 56 proto file(s) to /Users/jrobb/Projects/vertabrae/trunk/scaling/discovery-service/target/generated-sources/protobuf/java
[ERROR] PROTOC FAILED: validate/validate.proto: File not found.
gogoproto/gogo.proto: File not found.
envoy/api/v2/core/address.proto: Import "validate/validate.proto" was not found or had errors.
envoy/api/v2/core/address.proto: Import "gogoproto/gogo.proto" was not found or had errors.
envoy/config/metrics/v2/stats.proto: Import "envoy/api/v2/core/address.proto" was not found or had errors.
envoy/config/metrics/v2/stats.proto: Import "validate/validate.proto" was not found or had errors.
envoy/config/metrics/v2/stats.proto:148:5: "envoy.api.v2.core.Address" is not defined.
envoy/config/metrics/v2/stats.proto:167:5: "envoy.api.v2.core.Address" is not defined.
The output continues, with the same set of errors for each .proto file.
It seems that the crux of the issue is that I don't have validate/validate.proto or gogoproto/gogo.proto, which are imported at the top of (nearly?) every .proto file:
import "google/protobuf/wrappers.proto";
import "validate/validate.proto";
import "gogoproto/gogo.proto";
It seems to be finding wrappers.proto, which I think is coming from my compile-time Maven dependency on protobuf-java.
I think gogoproto/gogo.proto might be looking for this: https://github.com/gogo/protobuf/blob/master/gogoproto/gogo.proto
I'm totally stumped about where validate/validate.proto is supposed to come from. I've seen some evidence that it's specific to Envoy, but I can't find it.
I've spent the last few hours searching, and I'm coming up empty on anyone who's done this before. Where do I get those files? If I can't get them from Maven Central, I'll build them myself and upload to Artifactory.
My eyes are glazing over looking at documentation intended for people using other tech stacks, and I'm having trouble translating for my needs. Any and all help will be much appreciated, and I apologize if this is a hugely n00bish question. :)

Once again, the mere act of asking on SO has led me to the answer; found while adding context and detail to my question. There's a brand-new Java port of the Go-based Envoy control-plane: java-control-plane!
Somebody who, like me, would prefer to just depend on something from Maven Central, and already knew what they were looking for reported this issue, and while I was writing up this question, the maintainer answered: exactly that is coming soon!
I'm pleased to find that api/pom.xml in java-control-plane looks very similar to what I posted in my question. :)
So, if you find yourself in my situation, wanting to implement a Discovery Service for Envoy on a Java tech stack, java-control-plane is already there -- you just have to extend it with whatever backing store you want to use. I assume that, over time, implementations for that will pop up in the community as well. I'll be writing one for etcd and might end up contributing it back to the community.
Answering the finer details of my question:
Where do I get the two .proto file dependencies not included in data-plane-api?
They are in the java-control-plane source: they're checked in as part of the api module's source code, and therefore presumably not available as a separate dependency. I'm reasonably confident that the gogo.proto I found was the right one, but I'm still unclear on where I could have found validate.proto.
Do I need to include the BUILD files from data-plane-api in order to compile the *.proto files with protoc?
Nope! The api module in java-control-plane doesn't include them.

Related

How do I specify the type of asset when I publish asset to mulesoft's exchange?

When I was building a CI/CD with github actions, I ran into the following problems.
[INFO] ------------------------------------------------------------
[INFO] Publication status: error
[INFO] ------------------------------------------------------------
[INFO] Steps:
[INFO] - Description: Publishing asset
[INFO] - Status: error
[INFO] - Errors: [The asset is invalid, Error while trying to set type: app. Expected type is: rest-api.]
[INFO] .........................................
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
The following is my maven configuration
<plugin>
<groupId>org.mule.tools.maven</groupId>
<artifactId>mule-maven-plugin</artifactId>
<version>${mule.maven.plugin.version}</version>
<extensions>true</extensions>
<configuration>
<sharedLibraries>
<sharedLibrary>
<groupId>com.microsoft.sqlserver</groupId>
<artifactId>mssql-jdbc</artifactId>
</sharedLibrary>
</sharedLibraries>
<cloudhub2Deployment>
<uri>https://anypoint.mulesoft.com</uri>
<provider>MC</provider>
<environment>DEV</environment>
<target>****</target>
<muleVersion>4.4.0</muleVersion>
<server>anypoint-exchange-v3</server>
<businessGroup>AAAA</businessGroup>
<businessGroupId>*********</businessGroupId>
<applicationName>test-app2023</applicationName>
<replicas>1</replicas>
<vCores>0.1</vCores>
<deploymentSettings>
<http>
<inbound>
<publicUrl>tes-app2023t.anypoint.com</publicUrl>
</inbound>
</http>
<lastMileSecurity>false</lastMileSecurity>
<forwardSslSession>false</forwardSslSession>
<generateDefaultPublicUrl>true</generateDefaultPublicUrl>
</deploymentSettings>
<server>****</server>
<properties>
<anypoint.platform.base_uri>https://anypoint.mulesoft.com/</anypoint.platform.base_uri>
<anypoint.platform.client_id>****</anypoint.platform.client_id>
<anypoint.platform.client_secret>****</anypoint.platform.client_secret>
<anypoint.platform.analytics_base_uri>https://analytics-ingest.anypoint.mulesoft.com</anypoint.platform.analytics_base_uri>
</properties>
</cloudhub2Deployment>
<classifier>mule-application</classifier>
</configuration>
</plugin>
How should I properly set my exchange asset to rest-api instead of app?
I checked mulesoft's documentation and couldn't find a way to define...
The Mule Maven Plugin shared is configured for a Mule application. The asset type is set by the <classifier> element. Since this is a Mule application it is a correct type. In Anypoint Exchange a rest-api asset type identify an API description composed of RAML or OAS files. The Mule Maven Plugin is not compatible with that kind of assets, which makes sense because they are not built with Maven. If the Mule application implements a REST API, it is still a Mule application asset.
On the other hand if your asset is really RAML or OAS files you should use the Anypoint CLI instead to publish it to Anypoint Exchange. Read https://docs.mulesoft.com/exchange/to-create-an-asset for the different ways to create different types of assets.
I solved this problem myself.
The problem was caused by the duplication of the asset name of the API (raml) published from Design center and the asset name of the API (app) published from Maven.
I changed the artifactId in the pom.xml and solved the problem.
<groupId>****</groupId>
<artifactId>{asset name}</artifactId>
<version>1.0.0-SNAPSHOT</version>
<packaging>mule-application</packaging>

What Build Module in IntelliJ actually does for maven module

When I run
mvn clean install
for my maven module then it compiles fine. No issues.
But when I open my pom.xml file in IntelliJ and I choose to Build -> Build module then I get following issues:
Information:javac 1.8.0_144 was used to compile java sources
Information:Module "mymodule" was fully rebuilt due to project configuration/dependencies changes
Information:09.10.2017 21:16 - Compilation completed with 3 errors and 3 warnings in 23s 991ms
C:\somepath\mymodule\pom.xml
Error:Error:osgi: [mymodule] Exception: java.lang.ClassNotFoundException: org.apache.sling.bnd.models.ModelsScannerPlugin not found, parent: java.net.URLClassLoader#29453f44 urls:[] exception:java.lang.ClassNotFoundException: org.apache.sling.bnd.models.ModelsScannerPlugin
Error:Error:osgi: [mymodule] Failed to load plugin org.apache.sling.bnd.models.ModelsScannerPlugin;generatePackagesHeader=true, error: java.lang.ClassNotFoundException: org.apache.sling.bnd.models.ModelsScannerPlugin not found, parent: java.net.URLClassLoader#29453f44 urls:[] exception:java.lang.ClassNotFoundException: org.apache.sling.bnd.models.ModelsScannerPlugin
Error:Error:osgi: [mymodule] Cannot load the plugin org.apache.sling.bnd.models.ModelsScannerPlugin
This is a module with AEM code and it uses maven-sling-plugin. It works fine for other developers in the project. Because it's working when executed directly from maven I'm trying to understand what IntelliJ does in the background. But actually, my problem is those compilation issues.
From what I've found IntelliJ does not call maven when Build is done. Any ideas how can I find differences between running from IntelliJ and directly from Maven?
What happens here is that the ModelScanner plugin can't be found using the current ClassLoader. The reason for this can be that you are using IntelliJ IDEA Ultimate which comes with a OSGI plugin already pre-installed called 'Osmorc'. If this OSGI plugin is active it will determine the classloader to be used for building OSGI related projects.
So simply de-activating this Osmorc plugin in IntelliJ should allow your build to revert to the classloader from the ModelScannerPlugin mentioned in the configuration of your the maven-bundle-plugin in your projects POM.xml file which should solve the problem.
If this still results in a similar Maven build error, then make sure to add a Maven dependency 'org.apache.sling.bnd.model' to your maven-bundle-plugin in your POM.xml file.
<!-- Apache Felix Bundle Plugin -->
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>3.3.0</version>
<inherited>true</inherited>
<extensions>true</extensions>
<executions>
<!-- Configure extra execution of 'manifest' in process-classes phase to make sure SCR metadata is generated before unit test runs -->
<execution>
<id>scr-metadata</id>
<goals>
<goal>manifest</goal>
</goals>
<configuration>
<supportIncrementalBuild>true</supportIncrementalBuild>
</configuration>
</execution>
</executions>
<configuration>
<exportScr>true</exportScr>
<instructions>
<!-- Enable processing of OSGI DS component annotations -->
<_dsannotations>*</_dsannotations>
<!-- Enable processing of OSGI metatype annotations -->
<_metatypeannotations>*</_metatypeannotations>
<_plugin>org.apache.sling.bnd.models.ModelsScannerPlugin;generatePackagesHeader=true</_plugin>
</instructions>
</configuration>
<dependencies>
<dependency>
<groupId>org.apache.sling</groupId>
<artifactId>org.apache.sling.bnd.models</artifactId>
<version>1.0.0</version>
</dependency>
</dependencies>
</plugin>
could you please check your core pom file. it should contain a plugin section like this:
<plugin> <!-- Enable registration of Sling Models classes via bnd plugin --> org.apache.sling.bnd.models.ModelsScannerPlugin, <!-- Allow the processing of SCR annotations via a bnd plugin --> org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin;destdir=${project.build.outputDirectory} </plugin>
but if you created a project using aem archetype the tag looks like' <_plugin>

Vaadin Custom Components/Widgets with Maven and Spring Boot

I am relatively new to vaadin and started out with a spring boot application and the vaadin spring boot plugin. Everything worked fine until I got to the point where I tried to create my own components/widgets.
Unfortunately I didn't find any "official" example/documentation how to set up custom components within a spring boot application so I had to search the web to find out how to set up additional plugin(s) in maven to compile the code for the client side widgets. As far as I can tell from the log output the compilation of these components work, but when I try to access these components on the webpage I get an error:
Widgetset 'com.vaadin.DefaultWidgetSet' does not contain implementation for net.gtidev.test.components.MyComponent. Check its component connector's #Connect mapping, widgetsets GWT module description file and re-compile your widgetset. [...]
Here is the widget compiler log:
[INFO] Using com.vaadin:vaadin-client-compiler version 7.6.4
[ERROR] Mar 22, 2016 10:22:43 AM java.util.prefs.WindowsPreferences <init>
[ERROR] WARNUNG: Could not open/create prefs root node Software\JavaSoft\Prefs at root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5.
[INFO] Compiling module net.gtidev.test.components.TestWidgetset
[INFO] Computing all possible rebind results for 'com.vaadin.client.metadata.ConnectorBundleLoader'
[INFO] Rebinding com.vaadin.client.metadata.ConnectorBundleLoader
[INFO] Invoking generator com.vaadin.server.widgetsetutils.ConnectorBundleLoaderFactory
[INFO] Populating eager bundle
. . . . . 250 more lines
[INFO] Computing all possible rebind results for 'com.vaadin.client.ui.dd.VAcceptCriterionFactory'
[INFO] Rebinding com.vaadin.client.ui.dd.VAcceptCriterionFactory
[INFO] Invoking generator com.vaadin.server.widgetsetutils.AcceptCriteriaFactoryGenerator
[INFO] Detecting available criteria ...
[INFO] creating mapping for com.vaadin.event.dd.acceptcriteria.AcceptAll
[INFO] creating mapping for com.vaadin.event.dd.acceptcriteria.And
[INFO] creating mapping for com.vaadin.event.dd.acceptcriteria.ContainsDataFlavor
[INFO] creating mapping for com.vaadin.event.dd.acceptcriteria.SourceIs
[INFO] creating mapping for com.vaadin.ui.AbstractSelect.TargetItemIs
[INFO] creating mapping for com.vaadin.ui.AbstractSelect.AcceptItem
[INFO] creating mapping for com.vaadin.ui.Table.TableDropCriterion
[INFO] creating mapping for com.vaadin.ui.Tree.TreeDropCriterion
[INFO] creating mapping for com.vaadin.event.dd.acceptcriteria.Not
[INFO] creating mapping for com.vaadin.event.dd.acceptcriteria.Or
[INFO] creating mapping for com.vaadin.event.dd.acceptcriteria.ServerSideCriterion
[INFO] creating mapping for com.vaadin.event.dd.acceptcriteria.SourceIsTarget
[INFO] creating mapping for com.vaadin.event.dd.acceptcriteria.TargetDetailIs
[INFO] creating mapping for com.vaadin.ui.Tree.TargetInSubtree
[INFO] Done. (0seconds)
[INFO] Compiling 1 permutation
[INFO] Compiling permutation 0...
[INFO] Compile of permutations succeeded
[INFO] Compilation succeeded -- 59,217s
[INFO] Linking into C:\projects\misc\vaadin-boot\target\vaadin-boot-0.0.1-SNAPSHOT\net.gtidev.test.components.TestWidgetset
[INFO] Link succeeded
[INFO] Linking succeeded -- 0,492s
The files I use for my custom component were generated by the eclipse vaadin addon within a vaadin 7 project which I created only for this purpose. When I started this vaadin 7 project in eclipse the component worked. I then copied these files into my spring boot maven project where the custom component does not get loaded any more.
I know that spring boot applications have a slightly different bootstrap mechanism and layout than "classic" webapps and that amongst other things static resources are not loaded from the webapp-folder but from the classpath:/static folder. I think that the core of the problem has something to do with this fact but I don't know what to do to fix it.
My Plugin configuration (I tried with and without the commented options):
<plugin>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-maven-plugin</artifactId>
<version>7.6.4</version>
<configuration>
<strict>true</strict>
<force>true</force>
<!-- Enable during development to speed compiling. -->
<!-- <draftCompile>true</draftCompile>
<style>DETAILED</style> -->
<!-- End development options -->
<!--<webappDirectory>src/main/webapp/VAADIN/widgetsets</webappDirectory>-->
<modules>
<module>net.gtidev.test.components.TestWidgetset</module>
</modules>
</configuration>
<executions>
<execution>
<goals>
<goal>resources</goal>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
I tried different maven plugin combinations and configurations. In one example, there was also a Google-GWT Plugin mentioned, but running this plugin on the code produced the same log output as the vaadin plugin:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>2.5.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>-->
<!--<soycDetailed>false</soycDetailed>-->
<!--</configuration>-->
<executions>
<execution>
<goals>
<goal>resources</goal>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
To use custom client side extensions, Vaadin Add-ons, you'll need to add vaadin-maven-plugin to your project. It will scan the add-ons you use and GWT compile a new widgetset for your project that contains those extensions.
If you created the project with start.spring.io the maven plugin is not in your project by default. Create an example project for example using this Vaadin+Spring archetype or the official servlet based archetype and copy the vaadin-maven-plugin related parts from the pom.xml to your projects pom.xml. Then do a full build and everything should works as expected.

maven-war-plugin maven-compiler-plugin

i'm new to maven; I need to compile and packaging 2 war file in two different directory even if the source are the same (change only the web.xml file).
try to explain better:
directory structure of LT:
<DIR> LT1_war
<DIR> LT_war
pom.xml
a part of the pom is:
<modules>
<module>LT_war</module>
<module>LT1_war</module>
</modules>
inside the folder LT_war there is a pom and src-->main-->java
resources
webapp
this compile successful and also i packaging in a war LT_war (to deploy to tomcat)
I need a way in order to compile inside the directory LT1_war (using the source that are in the LT_war directory) and packaging using the webapp inside the LT_war directory (just changing the web.xml file)
I've try to write the pom inside the directory LT1_war but when i lunch mvn packaging it tell me:
[INFO] lt ................................................ SUCCESS [3.995s]
[INFO] LT ................................................ SUCCESS [1:12.629s]
[INFO] LT1 ............................................... FAILURE [41.367s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1:59.716s
[INFO] Finished at: Tue Jul 08 23:50:43 CEST 2014
[INFO] Final Memory: 20M/200M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-war-plugin:2.0:war (default-war) on project LT1: Error assembling WAR: Deployment descriptor: D:\attivi
taTomcat7\LT\LT1_war\target\LT1\WEB-INF\web.xml does not exist. -> [Help 1]:
this is a part of the pom file inside LT1_war:
<build>
<finalName>LT1</finalName>
<resources>
<resource>
<directory>../LT_war/src/</directory>
</resource>
</resources>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.0</version>
<configuration>
<excludes>**/.svn/**</excludes>
</configuration>
<executions>
<execution>
<id>exploded</id>
<phase>prepare-package</phase>
<goals>
<goal>exploded</goal>
</goals>
</execution>
<execution>
<id>war</id>
<phase>package</phase>
<goals>
<goal>war</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
There is a few things that I kindly consider terribly wrong with what you're doing:
A Maven project should never access files that are outside of its own module's folder. So LT1 please stay out of LT's folder!
Try to keep WAR projects small if you can. Modularize your code anyway, and make the WAR just depend on JAR files that contain the actual meat
One WAR file "borrowing" stuff from the other WAR might then be better fixed by having both WAR files depend on the code that you moved into such JAR file(s)
Stop using Java 5 if you reasonably can; it's been EOL since 2009. Also, consider moving your source/target levels to the parent project, so you don't redefine the same, yet have a consistent Java version
Talking about old versions, how come you even still have .svn folders that you need to exclude (for a while now there's only a .svn folder in the root of your Subversion work space, that wouldn't affect the Maven WAR plugin)
So your project structure could look like this:
ROOT
MEAT (packaging JAR, where your classes live)
LT (packaging WAR, depends on MEAT)
LT1 (packaging WAR, depends on MEAT, and stays the heck out of LT)
Addition (forgotten some aspect, as pointed out in comment)...
While MEAT is of packaging JAR, you want it to also include stuff that you had going into webapp without it ending up on the classpath. Provided you're using a fairly recent servlet-api, this can be achieved by giving MEAT a resources folder as follows:
src/main/resources/META-INF/resources/...
E.g. .../META-INF/resources/flower.jpeg will appear in the deployed WAR as <context root>/flower.jpg (instead of it just being added to the Java class path).
I need a way in order to compile inside the directory LT1_war (using the source that are in the LT_war directory) and packaging using the webapp inside the LT_war directory (just changing the web.xml file)
Generally, you compile from the root. It's not convenient to do what you're asking to do but it can be done by using the --also-make command line option.

Unable to deploy to Tomcat7 from cargo

I'm trying to deploy to a remote Tomcat7 with Cargo from Maven over https.
I've set up manager-script role and I've succeeded so far as to have been able to undeploy an app remotely.
What I have looks like this:
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.1.2</version>
<configuration>
<container>
<containerId>tomcat7x</containerId>
<type>remote</type>
</container>
<configuration>
<type>runtime</type>
<properties>
<cargo.remote.uri>https://xxx/manager/text</cargo.remote.uri>
<cargo.remote.username>${tomcat.username}</cargo.remote.username>
<cargo.remote.password>${tomcat.password}</cargo.remote.password>
</properties>
</configuration>
<deployer>
<type>remote</type>
<deployables>
<deployable>
<groupId>mycomp</groupId>
<artifactId>myartifact</artifactId>
<type>war</type>
<properties>
<context>/</context>
</properties>
</deployable>
</deployables>
</deployer>
</configuration>
</plugin>
Well, I know the credentials and everything is setup correctly, and I have used the new /text interface and I have been able to undeploy an existing app. But when trying to run deploy:
mvn cargo:deployer-deploy -e
I get an error with root cause:
Caused by: java.io.IOException: Error writing request body to server
at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.checkError(HttpURLConnection.java:2809)
at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.write(HttpURLConnection.java:2792)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
at java.io.BufferedOutputStream.write(BufferedOutputStream.java:109)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.pipe(TomcatManager.java:605)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.invoke(TomcatManager.java:501)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.deployImpl(TomcatManager.java:569)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.deploy(TomcatManager.java:273)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.deploy(TomcatManager.java:256)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.deploy(TomcatManager.java:240)
at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.deploy(AbstractTomcatManagerDeployer.java:101)
... 25 more
I get it quite immediately so it can't be a timeout.
Can the file be to large? It's a 60 MB war. I made sure my nginx allows bigger:
client_max_body_size 200M;
I also added multipart config to the text manager in the manager webapps web.xml like this:
servlet>
Manager
org.apache.catalina.manager.ManagerServlet
debug
2
<multipart-config>
<max-file-size>209715200</max-file-size>
<max-request-size>209715200</max-request-size>
<file-size-threshold>0</file-size-threshold>
</multipart-config>
http://nexnet.wordpress.com/2011/04/27/large-war-file-cannot-be-deployed-in-tomcat-7/
I love Maven in many ways, but the error reporting is really terrible. Any help highly appreciated.
I was bitten by this error recently, when I tried to cargo:deploy an artifact. Usually we stop, clean and start the webapps directory before deploying, but this time I noticed that one artifact was not removed.
After switching to cargo:redeploy the error was solved.
I ran into this same error message when deploying to a tomcat 8 server using the ant deploy task. The issue in my case was that I was running out of space on the server. Checking tomcat's manager log is what clued me in:
10-Jul-2014 10:15:38.065 INFO [http-nio-8080-exec-2] org.apache.catalina.core.ApplicationContext.log Manager: deploy: Deploying web application '/abc_beta'
10-Jul-2014 10:15:38.065 INFO [http-nio-8080-exec-2] org.apache.catalina.core.ApplicationContext.log Manager: Uploading WAR file to /usr/share/apache-tomcat-8.0.9/webapps/abc_beta.war
10-Jul-2014 10:15:57.962 SEVERE [http-nio-8080-exec-2] org.apache.catalina.core.ApplicationContext.log Manager: managerServlet.check[/abc_beta]
java.io.IOException: No space left on device
... stacktrace ...
I don't remember if or how I solved this, but as rascio has the same problem, I'll post a an idea. Maybe it's the wagon-extension for ssl that's needed:
<extensions>
<extension>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-ssh</artifactId>
<version>2.2</version>
</extension>
</extensions>
Wild guess though. I think you didn't need it before Maven 3.0.
Another reason for this exception that we stumbled upon suddenly on monday, when deployment jobs on our Jenkins instance using the cargo plugin plugin stopped working. Not all of them, but some. The main difference was a a custom settings.xml in the jobs for a Nexus repository to download deployables from.
The successful deployment jobs had it configured like described in https://support.sonatype.com/entries/20943003-configure-maven-to-download-from-nexus, the failed ones were missing the repository and pluginRepository
I'm still not sure why the behavior changed at one point. Any tipps?

Resources