I have Eclipse Maven GWT project and I added flowable-form-engine dependency that uses Liquibase. Liquibase is searching for changelog file org/flowable/form/db/liquibase/flowable-form-db-changelog.xml but finds two!
org.flowable.common.engine.api.FlowableException: Error initialising form data schema
at org.flowable.form.engine.impl.db.FormDbSchemaManager.initSchema(FormDbSchemaManager.java:58)
at org.flowable.form.engine.impl.cmd.SchemaOperationsFormEngineBuild.execute(SchemaOperationsFormEngineBuild.java:29)
at org.flowable.form.engine.impl.cmd.SchemaOperationsFormEngineBuild.execute(SchemaOperationsFormEngineBuild.java:24)
at org.flowable.common.engine.impl.interceptor.DefaultCommandInvoker.execute(DefaultCommandInvoker.java:10)
at org.flowable.common.engine.impl.interceptor.TransactionContextInterceptor.execute(TransactionContextInterceptor.java:53)
at org.flowable.common.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:71)
at org.flowable.common.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.java:30)
at org.flowable.common.engine.impl.cfg.CommandExecutorImpl.execute(CommandExecutorImpl.java:56)
at org.flowable.form.engine.impl.FormEngineImpl.<init>(FormEngineImpl.java:45)
at org.flowable.form.engine.FormEngineConfiguration.buildFormEngine(FormEngineConfiguration.java:172)
at org.flowable.form.engine.configurator.FormEngineConfigurator.initFormEngine(FormEngineConfigurator.java:83)
at org.flowable.form.engine.configurator.FormEngineConfigurator.configure(FormEngineConfigurator.java:63)
at org.flowable.common.engine.impl.AbstractEngineConfiguration.configuratorsAfterInit(AbstractEngineConfiguration.java:859)
at org.flowable.engine.impl.cfg.ProcessEngineConfigurationImpl.init(ProcessEngineConfigurationImpl.java:985)
at org.flowable.engine.impl.cfg.ProcessEngineConfigurationImpl.buildProcessEngine(ProcessEngineConfigurationImpl.java:887)
at sk.dominanz.coarui.server.services.WorkflowServiceAdditional.<clinit>(WorkflowServiceAdditional.java:64)
... 33 more
Caused by: liquibase.exception.ChangeLogParseException: Error Reading Migration File: Found 2 files that match org/flowable/form/db/liquibase/flowable-form-db-changelog.xml
at liquibase.parser.core.xml.XMLChangeLogSAXParser.parseToNode(XMLChangeLogSAXParser.java:118)
at liquibase.parser.core.xml.AbstractChangeLogParser.parse(AbstractChangeLogParser.java:15)
at liquibase.Liquibase.getDatabaseChangeLog(Liquibase.java:217)
at liquibase.Liquibase.update(Liquibase.java:190)
at liquibase.Liquibase.update(Liquibase.java:179)
at liquibase.Liquibase.update(Liquibase.java:175)
at liquibase.Liquibase.update(Liquibase.java:168)
at org.flowable.form.engine.impl.db.FormDbSchemaManager.initSchema(FormDbSchemaManager.java:52)
... 48 more
Caused by: java.io.IOException: Found 2 files that match org/flowable/form/db/liquibase/flowable-form-db-changelog.xml
at liquibase.util.StreamUtil.singleInputStream(StreamUtil.java:206)
at liquibase.parser.core.xml.XMLChangeLogSAXParser.parseToNode(XMLChangeLogSAXParser.java:71)
... 55 more
So I debugged it and it finds one resource from target directory:
jar:file:/C:/work/git/coarui/target/Main-1.0-SNAPSHOT/WEB-INF/lib/flowable-form-engine-6.4.0.jar!/org/flowable/form/db/liquibase/flowable-form-db-changelog.xml
and other resource from maven repository:
jar:file:/C:/Users/Piro/.m2/repository/org/flowable/flowable-form-engine/6.4.0/flowable-form-engine-6.4.0.jar!/org/flowable/form/db/liquibase/flowable-form-db-changelog.xml
Is there a way to ignore one of them, or is my build path or dependency definition wrong?
My build path contains:
src/main/java sources
src/test/java sources
JRE System library
Maven dependencies (in C:/Users/Piro/.m2/repository...)
JUnit4
Looking at source code resources are read classLoader.getResources(path); where class loader is jetty class loader JettyLauncher$WebAppContextWithReload$WebAppClassLoaderExtension.
In my run/debug configuration I have classpath similar to build path plus GWT library gwt-dev-2.8.1.jar - C:\Users\Piro\.m2\repository\com\google\gwt\gwt-dev\2.8.1
In pom.xml dependency is defined as:
<dependency>
<groupId>org.flowable</groupId>
<artifactId>flowable-form-engine-configurator</artifactId>
<version>${flowableVersion}</version>
</dependency>
Maven GWT plugin groupId=net.ltgt.gwt.maven, artifactId=gwt-maven-plugin has configuration parameter classpathScope but I tested <classpathScope>compile+runtime</classpathScope>, <classpathScope>compile</classpathScope> and <classpathScope>runtime</classpathScope> and the same error occurs.
Searching the internet I found similar posts on flowable forum (1, 2) but no solution is provided.
This generally happens when you mix client and server code in the same Maven module, and given how GWT works there's no (easy) around that, besides splitting your code in separate client and server (and possibly shared) Maven modules.
You can have a look at https://github.com/tbroyer/gwt-maven-archetypes for examples (disclaimer: I'm the author, but also a member of GWT's Steering Committee)
it seems that for some reason your .m2 is in the classpath. If it really makes sense to you then you can try to use <scope>provided</scope> in a pom where you declare dependency to flowable-form-engine-configurator. However you may decide to exclude .m2 from classpath which is better I think.
Related
I'm struggling to make maven to compile classes and put them to the jar. Searching through the internet I found, that it expects standard structure (like src/java), but it can be overridden by adding
<packaging>jar</packaging>
<build>
<sourceDirectory>correct_path_to_source_files</sourceDirectory>
</build>
to pom.xml, but it doesn't help, maven keeps ignoring source files without any error: runnning compile says [INFO] Nothing to compile - all classes are up to date. However, no classes appear in target/classes and in jar as well. Other than packaging and build above, pom file contains only dependencies.
I'm not a big expert of java/scala, so I have no idea, what does this thing expect from me. Manual build in Idea solves the problem, but shouldn't it be done by assembly system?
How to make maven compile source files?
I think the problem is the same as described in this blog post but I get this for Java 10: I have an Eclipse RCP application that uses Java 10 features but also JAXB classes. In Eclipse, I have to add the java.xml.bind module to the build path configuration of my project (as described here) to let the compile errors go away.
However, when building the product with Tycho 1.2.0 I get the following error, exactly for the class that uses JAXB:
[ERROR] Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:1.2.0:compile (default-compile) on project epd-editor: Compilation failure: Compilation failure:
[ERROR] ...app\src\app\editors\XmlPage.java:
[ERROR] package app.editors;
[ERROR] ^
[ERROR] Internal compiler error: java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.lookup.BinaryModuleBinding.create(BinaryModuleBinding.java:64)
[ERROR] java.lang.NullPointerException
[ERROR] at org.eclipse.jdt.internal.compiler.lookup.BinaryModuleBinding.create(BinaryModuleBinding.java:64)
[ERROR] at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getModuleFromAnswer(LookupEnvironment.java:427)
[ERROR] at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForTypeFromModules(LookupEnvironment.java:367)
[ERROR] at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:228)
[ERROR] at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:105)
Is there a way to configure the Tycho compiler plugin so that it can see modules like java.xml.bind or is there another reason for this error?
Thanks.
Java EE modules are deprecated for removal and not resolved by default and will be removed in Java 11.
The best way to handle this is to use a third-party dependency, but as you observe JDT trips over its own feet when that is done. I opened an issue and it was fixed some time ago, but it's not easy to find an artifact that contains the change and works on Java 10. The first artifact I know of comes from Eclipse Photon I20180531-0700.
Execute the following in Eclipse's plugins folder (#people from the future: you may have to update the version):
mvn install:install-file \
-Dfile=org.eclipse.jdt.core_3.14.0.v20180528-0519.jar \
-DgroupId=org.eclipse.tycho \
-DartifactId=org.eclipse.jdt.core \
-Dversion=3.14.0.v20180528-0519 \
-Dpackaging=jar
You can then use it as follows as dependencies for Maven's compiler plugin:
<dependency>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-compiler-jdt</artifactId>
<version>1.1.0</version>
</dependency>
<dependency>
<groupId>org.eclipse.tycho</groupId>
<artifactId>org.eclipse.jdt.core</artifactId>
<!-- unreleased version that was pulled from Eclipse Photon I20180531-0700
contains the fix and compiles Java 10 -->
<version>3.14.0.v20180528-0519</version>
</dependency>
The problem is also described on java9.wtf with a demo project on GitHub. (I forgot to push, so it's only online for about five minutes now. 😒)
There are three ways you can include modules from the java.se.ee aggregator module, which is not included for compile or runtime in JDK 10. (As of JDK 11, these modules will be removed from the JDK).
The simplest is to use the command line option, --add-modules java.xml.bind. This will use the version that is still included in the JDK.
Find a JAXB implementation jar. Maven central is a good place to go for this, there is also a reference implementation for JSR 222 (JAXB), which is part of the Java Web Services Developer Pack (http://www.oracle.com/technetwork/java/webservicespack-jsp-140788.html) but this is waaaay old and may not be the best choice. You can add where you've downloaded the jar to the upgrade module path using --upgrade-module-path {path}
An alternative to 2 is to simply put the jar containing JAXB on the classpath.
I'm not familiar with Tycho but you would need to figure out how to use one of these methods with its configuration.
I am new to maven and am experiencing difficulties while trying to mavenise a Java project.
Setting:
IDE: Eclipse Oxygen.2 Release (4.7.2)
Java: 8
m2e: 1.8.2
What I did:
- copy-pasted the entire original java project and renamed it
- right-click in eclipse: Configure > Convert to Maven project
- in java build path, deletion of libraries import from original local lib repo. The build path shows the Maven Dependencies folder, with the only junit library.
- maven install => downloaded things in the user/.m2/repository/, but not all.
What does not work:
When I try to add a dependency right from a file:
,
nothing pops up in the artifact selection windows, even though there is a commons-logging/ folder in m2/repository
When I try to add the dependency manually in the pom.xml:
<dependency>
<groupId>org.kie.modules</groupId>
<artifactId>org-apache-commons-configuration-main</artifactId>
<version>6.5.0.Final</version>
<type>pom</type>
</dependency>
but the package resolution error still appears in the java file, and I get this warning after Maven install
`[WARNING] The POM for org.kie.modules:org-apache-commons-configuration-main:pom:6.5.0.Final is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details`
I did Maven Update project, eclipse project clean, nothing changes.
My goal for now is just that eclipse understands (at least for one library), that it has to take it from maven repository. I still have many other dependencies to solve (intra-project), but that will be the next step.
Thanks for your help.
The cause of the issue is stated in the warning message :
[WARNING] The POM for
org.kie.modules:org-apache-commons-configuration-main:pom:6.5.0.Final
is invalid, transitive dependencies (if any) will not be available,
enable debug logging for more details
It means that the pom.xml downloaded in your local maven repository exists but is not valid.
Delete the folder of the dependency downloaded in your local maven repository and try again.
If you still have the same problem, check that your central repository that provides the dependency provides also correctly the pom.xml for that.
You can do it by browsing the directory of the dependency from a web browser.
For example we can see that the maven central repository provides a valid pom :
http://central.maven.org/maven2/org/kie/modules/org-apache-commons-collections-main/6.5.0.Final/org-apache-commons-collections-main-6.5.0.Final.pom
I've managed to get JUnit 4.12 + Hamcrest 1.3 + Mockito 2.8.47 to work in Eclipse so that when I add them as dependencies, my tests will run.
(The way I've done this is using the p2-maven-plugin to bundle the following
artifacts from Maven Central into plugins/a feature and provide them via P2:
junit 4.12
org.mockito.mockito-core 2.8.47
org.hamcrest.all 1.3.0
Adding the plugins to my test fragment as dependencies makes the tests
run in Eclipse.
However, the Tycho build of the same fragment will fail with the
following messages:
java.lang.LinkageError: loader constraint violation: loader (instance of org/eclipse/osgi/internal/loader/EquinoxClassLoader) previously initiated loading for a different type with name "org/hamcrest/Matcher"
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.defineClass(ModuleClassLoader.java:273)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.defineClass(ClasspathManager.java:632)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findClassImpl(ClasspathManager.java:586)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClassImpl(ClasspathManager.java:538)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:525)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:325)
at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:345)
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:423)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:372)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:364)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:161)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:12)
at org.junit.Assert.assertThat(Assert.java:956)
at org.junit.Assert.assertThat(Assert.java:923)
So it seems that some other plugin is loading the package
org.hamcrest.Matcher before my fragment does. This is probably due
to the import/export/partial import/partial export chaos surrounding the
JUnit/Hamcrest/Mockito setup.
Does anyone have an idea -- or even better: a working example -- of how to
get the three components work together both within the IDE (for quick
checks on whether tests run) and Tycho (for checks during the build)?
Seems like that the loader want the dependencies in a bundle.
But I guess you haven't put your test lib in a bundle.
You could try to add them in the dependencies of your product to see how it reacts.
Background
The root of the problem is, that org.junit already has a dependency to org.hamcrest.core. So when your test-plugins has a dependency to org.hamcrest.all (which contains everything of hamcrest-core and all other hamcrest artifacts), all classes specified in hamcrest-core exist twice. Once in the bundle of hamcrest-core and once in hamcrest-all, which is why you get the linkage error.
If you open the Manifest of org.junit in the Manifest-Editor of Eclipse and go to the 'Dependencies' tab it should show you org.hamcreast.core in the "Required Plug-ins" section and org.hamcreast.core should be re-exported. Or in the raw-manifest it should look like this:
Require-Bundle: org.hamcrest.core;bundle-version="1.3.0";visibility:=reexport
Solution 1 - add hamcrest sub-modules
Instead of adding the all hamcrest-modul containing hamcrest.all as dependency to my Eclipse test-bundle/project (via 'Require-Bundle'), I add the hamcrest sub-modules that I require, except for hamcrest-core (because it is already re-exported in my case). For me hamcrest-library was sufficient.
The available hamcrest sub-modules are (according to the org.hamcrest:hamcrest-parent pom, which can be found here: https://repo1.maven.org/maven2/org/hamcrest/hamcrest-parent/1.3/hamcrest-parent-1.3.pom):
hamcrest-core
hamcrest-library
hamcrest-generator
hamcrest-integration
Creating the p2-Repo containing the required bundles
When using Maven and the 'org.reficio:p2-maven-plugin' to build the p2-repo that contains the mentioned test-bundles, the conversion of the maven-artifacts to OSGi-bundles does not produce fully working results by default.
Converting a maven-module to a full OSGi-bundle consists mainly of configuring the MANIFEST.MF to contain proper entries. For this the p2-maven-plugin utilizes "bnd tool".
By default the Java packages provided by all maven dependencies of a maven module are added as optional Imported-package when that module is converted into a OSGi-bundle.
In my case this had the consequence that the org.hamcrest.library bundle refereed to the packages from hamcrest-core only via Import-Package in its MANIFEST.MF.
But unfortunately with only this specified, the Equinox-ClassLoader did not find the classes from hamcrest-core in the test-runtime and threw a corresponding exception. Maybe this is also caused by the fact that hamcrest-core and hamcrest-library have a package "org.hamcrest" and bnd-tools adds the exported packages of a bundle to the imported packages again.
The solution in my case was to instruct the org.reficio:p2-maven-plugin respectively bnd-tools to add org.hamcrest.core as "Require-Bundle" to the Manifest of hamcrest-library. For this, the instructions-element shown below needs to be add to the artifact-element of org.hamcrest:hamcrest-library in the execution-configuration of the 'p2-maven-plugin' in the pom.xml used to build the p2-repo:
<artifact>
<id>org.hamcrest:hamcrest-library:1.3</id>
<instructions>
<Require-Bundle>org.hamcrest.core</Require-Bundle>
</instructions>
</artifact>
If hamcrest sub-modules other than hamcrest-library are are used, the instructions need to be analogous, corresponding to the dependencies listed in their pom.
Edit
Eclipse Orbit provides org.hamcrest.library, org.hamcrest.integrator and org.hamcrest.generator bundles that have have org.hamcrest.core as required bundle (if necessary):
https://download.eclipse.org/tools/orbit/downloads/
Appendix
In the end first solution caused a SecurityException:
java.lang.SecurityException: class "org.hamcrest.Matchers"'s signer information does not match signer information of other classes in the same package
Which is a known issue. The following two solutions avoid this issue and work properly during Tycho builds and from within Eclipse.
Solution 2 - bundle hamcrest sub-module jars with a plug-in
Another approach is to download the jar of the required hamcrest sub-module and bundle it with a Eclipse plugin directly, like it is described here:
https://www.vogella.com/tutorials/Hamcrest/article.html#hamcrest_eclipse
To bundle the jar with a plug-in, include it in the project and add it to the plug-ins classpath. Go to the Runtime-Tab of the Manifest-Editor and klick Add... in the Classpath section and select the jar. This should add the jar to the .classpath, MANIFEST.MF and build.properties file properly.
Make sure the jar is included before the other plug-in dependencies (which include hamcrest-core), as stated in the mentioned tutorial.
If hamcrest should be used in multiple test-projects/fragments, add the jar to a test plug-in all other test-projects depend on.
Solution 3 - use org.hamcrest 2.x
Since hamcrest-2 there is only one org.hamcrest jar/artifact that includes everything from hamcrest. Using hamcrest 2 avoids all the issues and is my preferred solution. Except for the changed packaing of hamcrest the API did not break, so it should be sufficient to just include org.hamcrest:
https://github.com/hamcrest/JavaHamcrest/releases/tag/v2.1
In order to create a p2-repo that includes org.hamcrest-2.2 the following sippet has to be included into the configuration-artifacts element of the p2-maven-plugin execution in the pom.xml:
<artifact>
<id>org.hamcrest:hamcrest-core:2.2</id>
<instructions>
<Require-Bundle>org.hamcrest;bundle-version="2.2.0";visibility:=reexport</Require-Bundle>
</instructions>
</artifact>
<artifact>
<id>org.hamcrest:hamcrest:2.2</id>
</artifact>
The IUs org.hamcrest.core 2.2 and org.hamcrest have to be included in the target-platform to make them available for plug-ins in Eclipse and during. All plug-ins which depend on org.junit now have org.hamcrest also available.
This aproach works because org.hamcrest.core still exists in version 2 stream, even tough it is deprected and empty. Its only purpose is to redirect build-systems to the new org.hamcrest-2.x jar/artifact. Therefore org.hamcrest.core-2.2 specifies a compile dependency to
org.hamcrest-2.2 in its pom.xml. Unfortunately the p2-maven-plugin dosn't translate it directly into a bundle-requirement for org.hamcrest in the manifest, but with the sippet above enforces that.
Because org.junit requires the bundle org.hamcrest.core with a minimal version of 1.3 (but without upper-bound) it uses the present org.hamcrest.core-2.2 . org.hamcrest.core-2.2 again requires org.hamcrest-2.2 and re-exports it. This makes org.junit use org.hamcrest-2.2 in the end and because org.junit re-exports hamcrest-core it also provides org.hamcrest-2.2 immediately to all depended plug-ins.
Note
If you want to play around with different variants of a jar, don't forget to clear (means delete on the drive) the bundle pools of Maven (in <your-home>/.m2/repository/p2/osgi/bundle/ and Eclipse PDE (in <your-workspace>/.metadata/.plugins/org.eclipse.pde.core/.bundle_pool/) in between. Otherwise you will always use the first one, because jar's with the same version are not updated.
I have a custom list of jars around 40 jars in a libs folder. I want to add all as a maven dependenices.
+ project
pom.xml
+ src
+ libs
Is there any way by that add all jar at a time.
Maven manages dependencies rather different than just including jars.
Essentially if you have a dependency on A and A uses B, you will need to have both A+B in your lib folder, but only A in your maven project, because maven transitively will include the subdependencies.
You should probably look through the maven repository, and see if you can find the jar files there in a similar version, and include that instead.
i.e. if you have commons-collections4-4.0.jar, use http://search.maven.org and write commons-collections4, and you will see a list of candidates. probably some with multiple version. Note, maven uses a groupId to scope jar files, so pick one with a suitable groupId, in this case org.apache.commons (Since commons-collections is an apache.org project).
When you have identified your dependency, it will show you ways to include it in your build, e.g. for maven, it would be
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-collections4</artifactId>
<version>4.0</version>
</dependency>
Looking at the pom file, you will be able to spot potential subdependencies, but otherwise, once you have added the dependency to your <dependencies/> section of your pom, run a mvn dependency:tree or mvn dependency:list to see how dependencies are transitively included.
Should you end up with libraries you cannot find in maven central, read this guide for the rest http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html
Found one wonderfull plugin to achieve this task. addjars-maven-plugin