I have a Mule project which makes use of a REST API Via the Mule Apikit.
When I run the project as a 'Mule Application' from eclipse there are no issues.
when I run the project as a 'Mule Application with Maven' the application builds but on startup of the mule server i see errors relating to resolution of the apikit schema and later namespace within my flows. ( I see the same thing when I load the application to a standalone Mule server.
org.xml.sax.SAXParseException: schema_reference.4: Failed to read schema document 'http://www.mulesoft.org/schema/mule/apikit/current/mule-apikit.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>.
I have two entries in my .pom file related to apikit.
<dependency>
<groupId>org.mule.modules</groupId>
<artifactId>mule-module-apikit</artifactId>
<version>1.6.1</version>
</dependency>
<plugin>
<groupId>org.mule.tools.maven</groupId>
<artifactId>mule-app-maven-plugin</artifactId>
<version>${mule.tools.version}</version>
<extensions>true</extensions>
<configuration>
<copyToAppsDirectory>true</copyToAppsDirectory>
<inclusions>
<inclusion>
<groupId>org.mule.modules</groupId>
<artifactId>mule-module-apikit</artifactId>
</inclusion>
</inclusions>
</configuration>
</plugin>
By default the Mule Maven plugin excludes all Mule dependencies, regardless of their scopes.
You need to forcefully include the APIkit dependency with:
<configuration>
<inclusions>
<inclusion>
<groupId>org.mule.modules</groupId>
<artifactId>mule-module-apikit</artifactId>
</inclusion>
</inclusions>
</configuration>
Reference: https://github.com/mulesoft/maven-mule-plugin/tree/maven-mule-plugin-1.9#managing-dependencies
This plugin seems to be the culprit:
<plugin>
<groupId>org.mule.tools</groupId>
<artifactId>maven-mule-plugin</artifactId>
<version>1.9</version>
<extensions>true</extensions>
</plugin>
When it is present the lib directory in the resulting zip is not populated, when it is removed the apikit (and other libraries) are present.
There are side effects to this however, This plugin seems to allow recognition of flow xml files in subfolders of the /app/ directory (which my project was using). Also adding/removing the dependancy seems to impact on the eclipse project ( I've seen it remove all of my src folders and replace them with a single /src/).
Related
Here is the project i'm working on: https://github.com/veracityidinc/idf-sandbox
I'm a front end dev so this is all a bit unclear to me.
I looked at the build log to try to figure after of course consulting google, and i see people saying stuff about a plugin and copying files. It just seems very weird to me that a web project - be it whatever kind - doesn't do this out of the box. It is very tedious to have to close and run the server any time i make a change. Also very weird that the html part of the app actually does this on its own.
GWT only deals with JS (and assets directly loaded by the code through special code constructs), not the other web assets.
DevMode (mvn gwt:run with Mojo's plugin) will serve your webapp, and Mojo's plugin will additionally copy the src/main/webapp on launch. If you want to update your web assets without restarting the DevMode, run mvn war:exploded -Dgwt.compiler.skip. And similarly for resources (in src/main/resources): run mvn process-resources.
This is also one good reason to adopt a different project layout, separating client and server code into distinct Maven modules, and running client and server code separately too (mvn gwt:codeserver for client code, through the net.ltgt.gwt.maven:gwt-maven-plugin, and mvn jetty:run or similarly for server code and web assets)
Using GWT SDM -Super dev mode- you will get this out of box, the SDM will keep running i the background and watch for files modified and upon refresh it will incrementally recompile your app and reload resources.
if you are using maven to get SDM to work you need to create a GWT project and apply the maven plugin, the recommended plugin is the tbroyer plugin and to create a GWT project that already configured correctly out of the box you can use the tbroyer multi module gwt-maven-archetype.
following the instructions from the archetype when you issue the command
mvn gwt:codeserver -pl *-client -am you are actually starting the SDM. the other command is starting your application server.
the generated project has a xxx-server module in which you can find a css file. once you run both commands and can load your application in the browser try to change some styles in that file and refresh the page, the changes should be reflected.
this is a sample plugin configuration when generating a project from the archtype
<plugin>
<groupId>net.ltgt.gwt.maven</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<configuration>
<moduleName>[replace this with your module]</moduleName>
<moduleShortName>app</moduleShortName>
</configuration>
</plugin>
now if you are not using this multi module structure you might try the start the application and the SDM using mvn gwt:devmode this should start the SDM for you
and if you are using uibinder, and you are editing styles in the *.ui.xml files when the SDM recompiles it should also pick the changes.
Edit
Checking on your project i made some changes to make it work.
first i changed the pom.xml, you can use my version for later projects but i think the better way is the generate a project using tbroyer archetype
The pom
<?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>
<groupId>com.candorgrc.idfusion</groupId>
<artifactId>idf-sandbox</artifactId>
<packaging>war</packaging>
<version>0.0.1-SNAPSHOT</version>
<name>IdFusion™ Sandbox</name>
<properties>
<!-- Setting maven.compiler.source to something different to 1.8 needs
that you configure the sourceLevel in gwt-maven-plugin since GWT compiler
2.8 requires 1.8 (see gwt-maven-plugin block below) -->
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<inject.gin.version>2.1.2</inject.gin.version>
<inject.guice.version>3.0</inject.guice.version>
<libsass.version>0.2.10-libsass_3.5.3</libsass.version>
<lesscss.version>1.7.0.1.1</lesscss.version>
<elemental2.version>1.0.0-RC1</elemental2.version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt</artifactId>
<version>2.8.2</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-servlet</artifactId>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-user</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-dev</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.google.elemental2</groupId>
<artifactId>elemental2-dom</artifactId>
<version>${elemental2.version}</version>
</dependency>
<dependency>
<groupId>com.google.gwt.inject</groupId>
<artifactId>gin</artifactId>
<version>${inject.gin.version}</version>
</dependency>
<dependency>
<groupId>com.google.inject</groupId>
<artifactId>guice</artifactId>
<version>${inject.guice.version}</version>
</dependency>
</dependencies>
<build>
<!-- Output classes directly into the webapp, so that IDEs and "mvn process-classes"
update them in DevMode -->
<outputDirectory>${project.build.directory}/${project.build.finalName}/WEB-INF/classes</outputDirectory>
<plugins>
<!-- GWT Maven Plugin -->
<plugin>
<groupId>net.ltgt.gwt.maven</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>1.0-rc-8</version>
<executions>
<execution>
<goals>
<goal>compile</goal>
</goals>
</execution>
</executions>
<configuration>
<moduleName>com.candorgrc.idfusion.sandbox.IdfSandbox</moduleName>
<moduleShortName>IdfSandbox</moduleShortName>
<failOnError>true</failOnError>
<!-- GWT compiler 2.8 requires 1.8, hence define sourceLevel here if
you use a different source language for java compilation -->
<sourceLevel>1.8</sourceLevel>
<warDir>${project.build.directory}/${project.build.finalName}</warDir>
<classpathScope>compile+runtime</classpathScope>
<!-- URL(s) that should be opened by DevMode (gwt:devmode). -->
<startupUrls>
<startupUrl>sandbox.html</startupUrl>
</startupUrls>
</configuration>
</plugin>
<plugin>
<groupId>org.lesscss</groupId>
<artifactId>lesscss-maven-plugin</artifactId>
<version>${lesscss.version}</version>
<configuration>
<sourceDirectory>${project.basedir}/src/main/webapp/less</sourceDirectory>
<outputDirectory>${project.basedir}/src/main/webapp/less</outputDirectory>
<compress>true</compress>
</configuration>
<executions>
<execution>
<goals>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
you will also need to create a new package on the same level as the client package and name it public this is the default public resource used by gwt. this should go in the src folder com.candorgrc.idfusion.sandbox.public then move your css file sandbox.css into this package.
once you do these changes you will be able to reload the css when you refresh the page as long as your IDE knows that the css is changed and it should move it to the correct location in the target folder.
I am trying to use OpenDaylight to generate Pojos from Yang files according to this guide.
I cloned Yangtools from OpenDaylight github and built the project with mvn clean install
i've added the following to my pom:
<plugin>
<groupId>org.opendaylight.yangtools</groupId>
<artifactId>yang-maven-plugin</artifactId>
<version>2.0.8-SNAPSHOT</version>
<executions>
<execution>
<goals>
<goal>generate-sources</goal>
</goals>
<configuration>
<!-- directory containing yang files to parse and generate code -->
<yangFilesRootDir>src/main/yang</yangFilesRootDir>
<codeGenerators>
<generator>
<codeGeneratorClass>
org.opendaylight.yangtools.maven.sal.api.gen.plugin.CodeGeneratorImpl
</codeGeneratorClass>
<!-- directory into which generated files will be placed -->
<outputBaseDir>
target/generated-sources
</outputBaseDir>
</generator>
</codeGenerators>
<!-- if true, plugin will search for yang files also in dependent projects -->
<inspectDependencies>true</inspectDependencies>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.opendaylight.yangtools</groupId>
<artifactId>maven-sal-api-gen-plugin</artifactId>
<version>0.7.4-Lithium-SR4</version>
<type>jar</type>
</dependency>
</dependencies>
</plugin>
however i am unable to generate the sources. I am getting the following error:
[ERROR] Failed to execute goal org.opendaylight.yangtools:yang-maven-plugin:2.0.8-SNAPSHOT:generate-sources (default) on project odl-poc: Execution default of goal org.opendaylight.yangtools:yang-maven-plugin:2.0.8-SNAPSHOT:generate-sources failed: An API incompatibility was encountered while executing org.opendaylight.yangtools:yang-maven-plugin:2.0.8-SNAPSHOT:generate-sources: java.lang.AbstractMethodError: Method org/opendaylight/yangtools/maven/sal/api/gen/plugin/CodeGeneratorImpl.generateSources(Lorg/opendaylight/yangtools/yang/model/api/SchemaContext;Ljava/io/File;Ljava/util/Set;Ljava/util/function/Function;)Ljava/util/Collection; is abstract
what am i doing wrong?
Looks like a version incompatibility - you're referencing yang-maven-plugin version 2.0.8-SNAPSHOT, which is the current unreleased master branch, and dependency maven-sal-api-gen-plugin version 0.7.4-Lithium-SR4, which was like 5 major releases ago and long obsolete.
I have an external .jar that cannot be imported from public repositories using pom.xml, it's sqljdbc41.jar.
I can run the project locally from my IDE, and everything will work. I referenced the library after downloading it like so:
<dependency>
<groupId>com.microsoft.sqlserver</groupId>
<artifactId>sqljdbc41</artifactId>
<version>4.1</version>
<scope>system</scope>
<systemPath>${basedir}/lib/sqljdbc41.jar</systemPath>
</dependency>
When I run mvn clean package to create my .jar file and try to run the created .jar, a mistake will pop up, which mentions the SQL Server references are not valid. I then extracted my .jar file and true enough, everything that is referenced in the pom.xml file properly gets downloaded and added, however, my SQL Server does not.
I can, in a very hacky way* just manually add the sqljdbc41.jar to my /lib folder after it's been compiled as a .jar, and it'll work, however that seems highly unoptimal. What would be a better approach?
*Opening the .jar file with Winrar, going to the /lib folder, manually selecting my sqljdbc41.jar file, then make sure to select the No Compression option bottom left where Winrar gives you compression options, in case you find this by Google and no one answered.
you can set 'includeSystemScope' to true.
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<includeSystemScope>true</includeSystemScope>
</configuration>
</plugin>
You could install the sqljdbc41.jar in your local repository :
mvn install:install-file -Dfile=path/to/sqljdbc41.jar -DgroupId=com.microsoft.sqlserver -DartifactId=sqljdbc41 -Dversion=4.1 -Dpackaging=jar
And then declare the dependency as a standard dependency :
<dependency>
<groupId>com.microsoft.sqlserver</groupId>
<artifactId>sqljdbc41</artifactId>
<version>4.1</version>
</dependency>
If you use a remote artifact repository (nexus, archiva...) you also need to deploy the artifact on this repository. You can find more here : https://maven.apache.org/guides/mini/guide-3rd-party-jars-remote.html
Another way, you can put it into the resources folder, such as resources/lib/xxx.jar, then config the pom.xml like this:
<dependency>
<groupId>com.microsoft.sqlserver</groupId>
<artifactId>sqljdbc41</artifactId>
<version>4.1</version>
<scope>system</scope>
<systemPath>${basedir}/src/main/resources/lib/sqljdbc41.jar</systemPath>
</dependency>
In Spring Boot: I also faced similar issue and below code helped me.
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>1.5.7.RELEASE</version>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
<configuration>
<includeSystemScope>true</includeSystemScope>
</configuration>
</plugin>
</plugins>
</build>
It works for me:
project {root folder}/libs/ojdbc-11.2.0.3.jar
pom.xml:
<dependency>
<groupId>com.oracle</groupId>
<artifactId>ojdbc</artifactId>
<version>11.2.0.3</version>
<scope>system</scope>
<systemPath>${basedir}/libs/ojdbc-11.2.0.3.jar</systemPath>
</dependency>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<includeSystemScope>true</includeSystemScope>
</configuration>
</plugin>
In my case, the fault was providing a version number without "dot" in tag:
<dependency>
<groupId>jdk.tools</groupId>
<artifactId>jdk.tools</artifactId>
<scope>system</scope>
<version>1</version>
<systemPath>${basedir}/src/main/resources/lib/tools.jar</systemPath>
</dependency>
This one works:
<dependency>
<groupId>jdk.tools</groupId>
<artifactId>jdk.tools</artifactId>
<scope>system</scope>
<version>1.8</version>
<systemPath>${basedir}/src/main/resources/lib/tools.jar</systemPath>
</dependency>
When Spring-Boot projects are used with maven or gradle plugins they packaged the applicaiton by default as executable jars.
These executable jars cannot be used as dependency in any another Spring-Boot project because the executable jar add classes in BOOT-INF/classes folder. This means that they cannot be found when the executable jar is used as a dependency because the dependency jar will also have the same class path structure as shown below.
If we want to use project-A as a maven dependency in project-B then we must have two artifacts. To produce the two artifacts, one that can be used as a dependency and one that is executable, a classifier must be specified. This classifier is applied to the name of the executable archive, leaving the default archive for use as a dependency.
To configure a classifier of exec in Maven, you can use the following configuration:
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<classifier>exec</classifier>
</configuration>
</plugin>
</plugins>
</build>
So the MAJIC WORD here is <classifier>exec</classifier> this will create a jar structure as below and then it could easily be conusmed by spring-boot project as maven dependency jar on class path.
The above plugin need to be add in project-A pom that is going to be used as dependency in project-B. Same is explained in spring documentation section 16.5. as well.
In order to work through the local repository, the target .jar file that we will work with must be in the s2 folder. Several methods can be used for this:
The file can be taken manually and put in the relevant place (not
preferred). The same process can be done by installing it via the
console.
Relevant Remote URL is written in the .pom file dependencies and
automatically places it in the s2 folder when Intellij is refreshed
(validate) in the IDE used.
The same process can be done by addressing the .pom file dependencies via the centeral repository.
Attention: ComponentScan should not be forgotten for the related jar work on SpringBot.
I'm trying to create a simple theme (using Chameleon and some custom css and images, etc), which I've done.
The problem is I want to wrap it up in a maven project and reference from other Vaadin projects as a dependency, so I can theme all my Vaadin apps the same way - or even better have it as a dependency of the parent project so that the whole app gets styled the same way and I can re-skin it for different customers.
I'm not sure how to package and deploy the theme project so that it will be usable from the other projects? Should I make it into a war project - but then how do the other projects 'get at it'? They'll be looking for the themes under their own VAADIN/themes directories - rather than copying it there (somehow), how could I just have them reference one single copy?
I've had the same problem. I solved it by using war overlays.
I have a base theme in the parent project which is extended in clients' configuration projects. The configuration project simply uses the war as a runtime dependency and the parent project's files are overlaid, as explained here.
Just add the dependency in the client's project:
<dependency>
<groupId>com.mygroup</groupId>
<artifactId>my-parent-project</artifactId>
<version>1.0.0-SNAPSHOT</version>
<type>war</type>
<scope>runtime</scope>
</dependency>
and import the parent project's styles in the client's theme's styles.css file:
#import "../parent-theme/styles.css"
and add the client's styles.
If you need to use the classes of the parent project, you can set the attachClasses property true in the maven-war-plugin configuration and also attach the sources by using maven-source-plugin if you need them for debugging:
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<attachClasses>true</attachClasses>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>2.1.2</version>
<executions>
<execution>
<id>attach-sources</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
<configuration>
<attach>true</attach>
</configuration>
</plugin>
and include them in your client's project:
<dependency>
<groupId>com.mygroup</groupId>
<artifactId>my-parent-project</artifactId>
<version>1.0.0-SNAPSHOT</version>
<classifier>classes</classifier>
<type>jar</type>
<scope>compile</scope>
</dependency>
I think I've found a way - not sure it's the best way because it copies the theme css into multiple war projects rather than creating one shared instance but the only other way would be to do some clever server configuration to share a url across projects or something.
http://www.ensor.cc/2011/06/mavens-war-overlay-what-are-war.html
I have been trying to use querydsl in a project which is an osgi bundle.
my pom.xml has the following dependencies:
<dependency>
<groupId>com.mysema.querydsl</groupId>
<artifactId>querydsl-apt</artifactId>
<version>2.5.0</version>
</dependency>
<dependency>
<groupId>com.mysema.querydsl</groupId>
<artifactId>querydsl-jpa</artifactId>
<version>2.5.0</version>
</dependency>
As well as the plugin
<plugin>
<groupId>com.mysema.maven</groupId>
<artifactId>maven-apt-plugin</artifactId>
<version>0.3.2</version>
<executions>
<execution>
<goals>
<goal>process</goal>
</goals>
<configuration>
<outputDirectory>target/generated-sources/java</outputDirectory>
<processor>com.mysema.query.apt.jpa.JPAAnnotationProcessor</processor>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.ops4j</groupId>
<artifactId>maven-pax-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<!-- | the following instructions build a simple set of public/private
classes into an OSGi bundle -->
<configuration>
<instructions>
<Import-Package>com.mysema.query.jpa,*</Import-Package>
<Export-Package>com.mypackage.package.*;version="${project.version}"</Export-Package>
</instructions>
</configuration>
</plugin>
Still when I try to start the bundle I get:
Error executing command: Unresolved constraint in bundle com.mypackage.package [163]: Unable to resolve 163.0: missing requirement [163.0] package; (&(package=com.mysema.query.jpa)(version>=2.5.0)(!(version>=3.0.0)))
I was using an older version of querydsl but apparently they fixed some stuff about osgi recently so I upgraded. The problem persists.
What I am missing for querydsl to work inside osgi?
Installing each dependency by hand will be a pain, but AFAIK there's nothing that will take a maven artifact and chain back of all dependencies - this would fail as where would it stop?
You could end up with every version of every logging framework (even if you had pax-logging installed), or the wrong implementation.
Alas in maven's case there's currently no way of applying semantic versioning or higher level requirement and capability. (Though BND (maven-bundle-plugin, bndtools) makes some sensible assumptions at a code level)
Karaf features (see the PDF manual in distribution's ${KARAF_HOME}) can do a lot to alleviate this but it can take some work to setup. There's a(t least) couple of ways to generate features files;
Use the features-maven-plugin
Use the maven-build-helper plugin to publish an XML file that you handcraft (laborious but you can maintain versions using resource filtering).