I constantly get:
mf.mwe2.launch.runtime.Mwe2Launcher - Couldn't find module x
error though the x.mwe2 file exists. I have enabled the xtext nature to the project and added related modules.
here's the .mwe2 file:
module com.ford.modelling.workflow.abcd
Workflow {
component = SayHello {
message = "hello"
}
}
What might be the problem? (a folder named src-gen already exists)
please make sure that the mwe2 file is placed in a java source folder and that you did a clean build on the project the mwe2 file is contained.
Had the same problem. The exception however occurs in the Mwe2Runner, not the Mwe2Launcher. The Mwe2Runner tried to load the mwe2 file as a resource and produces that error if it can't find it, although the Mwe2Launcher can.
Anyway, solution is to register your src-dir as a resource-dir by adding the following to your pom.xml
<build>
...
<resources>
<resource>
<directory>src</directory>
<excludes>
<exclude>**/*.java</exclude>
</excludes>
</resource>
</resources>
...
</build>
OK. I've found the problem (though not a solution yet).
Enabling scala nature halts the build process of MWE2. Can't figure out why but this is what happens. I remove the Scala nature and everything works.
Related
I am having some problems with simple cloud storage (simplecloud). When I run with Maven the console outputs following error :
java.io.FileNotFoundException: \var\key (The system cannot find the path specified)
Source code is here : src git
However it exists in the directory as shown here :
Any ideas?
Thanks in advance
POM :
<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/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.pliablematter</groupId>
<artifactId>simple-cloud-storage</artifactId>
<version>1.0-SNAPSHOT</version>
<name>Simple Cloud Storage</name>
<description>A simple wrapper around the Google Cloud Storage API</description>
<dependencies>
<dependency>
<groupId>com.google.http-client</groupId>
<artifactId>google-http-client-jackson2</artifactId>
<version>1.15.0-rc</version>
</dependency>
<dependency>
<groupId>com.google.apis</groupId>
<artifactId>google-api-services-storage</artifactId>
<version>v1beta2-rev6-1.15.0-rc</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>LATEST</version>
<scope>test</scope>
</dependency>
</dependencies>
Remove the initial \. Also, as pointed out by the others, as this is obviously a test key (judging by the name), you should place it under src/test/resources/var/key and change your code to look for just var/key/test.p12.
Make sure your \var\key directory is present in the target directory that Maven creates for the build. I'll go out on a limb and guess that it's probably not there now. If you have to have that \var\key in a non-standard place, you can use the Maven Resources Plugin to copy it into the target directory. As #Adrian Shum suggests, test\resources would be a standard place for Maven to look to find it.
EDIT:
Seems like you wanted to explore this option, so here's how you might use the Maven Resources Plugin in your Maven POM...
Inside the plugins node under build, add:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>2.6</version>
</plugin>
Then after the plugins node again inside build, add the directory or directories you need to copy over to target, for example:
<resources>
<resource><directory>src/main/resources</directory></resource>
</resources>
<testResources>
<testResource><directory>src/var/key</directory></testResource>
<testResource><directory>src/test/resources</directory></testResource>
</testResources>
I suggest you post the related code snippet in your CreateBucketTest.
I believe in your test you are opening a file \var\key. Obviously this is going to cause problem because the file you are thinking of is not really located at \var\key
Some suggestions to you:
instead of reading from absolute path, see if you can change it to opening stream for class path resources.
Put your key file under src/main/test/resources. Assume you put it under src/main/test/resources/cloudkey/key
With the above setup, when you run your test, the key file will be under the classpath at location /cloudkey/key
Edit:
After reading a bit on your code, here are some suggestions:
First, your getStorage relies on system property which is not very test friendly. Consider writing your code in a more test-friendly way
However I believe you are not going to refactor your code anyway, here is one way you can do:
put key in /src/test/resources. By doing so, when compiled, key will be put to BASE_DIR/target/test-classes/key.
Here I assume you will have only 1 key for all your tests. What you need to do is to set the system property private.key.path with the correct path of key. You can do so by configuring surefire plugin : http://maven.apache.org/surefire/maven-surefire-plugin/examples/system-properties.html. Add a systemPropertyVariables private.key.path with value ${project.build.testOutputDirectory}/key. By doing so, when your test is running, the sys property private.key.path will be set with the correct value, so that your test should run fine.
I have a Eclipse RCP product which I build with Tycho. After some smaller issues, this is working pretty fine and I have both CI and releases as wanted.
The product in question is provided both as an installable stand-alone RCP application and as an update site so the functionality can be installed in a vanilla Eclipse installation. This works fine as well.
The product have a main feature - which is used on the update site - and I would very much like the feature and the product to have the same version number. As it is today, this version number is mentioned is many places and I would really like to reduce this to just one. I currently have the version number in
the feature.xml of the main feature
the pom.xml of the same feature
the .product file for the product configuration file
the pom.xml of the project with the .product file
the categories.xml file of the update site
the about.mappings file
I have tried to use maven resource filters and that works for the POM files and about.mappings, but not for the rest. This is my current pom.xml for the main feature:
<?xml version="1.0" encoding="UTF-8"?>
<project ...>
<modelVersion>4.0.0</modelVersion>
<artifactId>...main.feature</artifactId>
<version>${product.version}-SNAPSHOT</version>
<packaging>eclipse-feature</packaging>
<parent>
<groupId>...</groupId>
<artifactId>...parent</artifactId>
<version>1.0.0-SNAPSHOT</version>
<relativePath>../...parent</relativePath>
</parent>
<build>
<!-- Substitutions: product.version -->
<resources>
<resource>
<directory>.</directory>
<includes>
<include>feature.xml</include>
</includes>
<filtering>true</filtering>
</resource>
</resources>
</build>
</project>
When running this configuration, I get the following exception from Tycho (or an exception that looks very similar to it):
[ERROR] Internal error: java.lang.IllegalArgumentException -> [Help 1]
org.apache.maven.InternalErrorException: Internal error: java.lang.IllegalArgumentException
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
Caused by: java.lang.IllegalArgumentException
at org.eclipse.equinox.internal.p2.metadata.VersionParser.parse(VersionParser.java:93)
at org.eclipse.equinox.p2.metadata.Version.create(Version.java:79)
at org.eclipse.tycho.p2.impl.publisher.FeatureDependenciesAction.getVersion(FeatureDependenciesAction.java:126)
at org.eclipse.tycho.p2.impl.publisher.AbstractDependenciesAction.perform(AbstractDependenciesAction.java:79)
... 11 more
(I have cut some lines...)
Basically, the embedded maven process seems to not perform the resource filtering at all for this type of packaging. Or??
I have tried many different things, but I cannot get it to work. My best guess is that I have to configure the lifecycle, but how...
Can anybody help me with this?
this is a known bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=362252
You don't need to specify versions explicitly in the categories.xml. Just specify 0.0.0 as version, and Tycho will replace it by the actual version of the included feature.
Littered throughout my project are various property files located in packages that are not being included when the package goal is run from a Maven build.
Using the 0.10.2 m2eclipse plugin and the default "package" goal.
In the project:
src->main->java->mypackage->MyProperties.java
src->main->java->mypackage->MyProperties.properties
In expanded war directory after the "package" goal is run:
target->classes->mypackage->MyProperties.class
-- no property file --
I'm trying to get the group to adopt Maven and resolving this issue is going to be a deal maker. Moving the properties files isn't going to be practical. Any help is much appreciated.
Put your property files where Application/Library resources belong, i.e. in src/main/resources:
src/main/resources/mypackage/MyProperties.properties
And it will get copied properly.
Pascal's answer is the correct maven way of doing things.
But some developers like to keep resources next to their sources (it's standard procedure in wicket, for example).
If you're going to do that, you will have to add your source folder to the resources:
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
</resource>
<resource>
<directory>src/main/java</directory>
<excludes>
<exclude>**/*.java</exclude>
</excludes>
</resource>
</resources>
</build>
I am working on a gwt module that is built using maven build system. I
had a working module that had the following project structure.
project-name/src/main/java/pkg1/pkg2/pkg3/EntryPoingClass
project-name/src/man/resources/pkg1/pkg2/ModuleDef.gwt.xml
The module definition was looking like this (I have put only this
project specific settings here...normal inherits are not specified for
the sake of brevity)
... <entry-point class='pkg1.pkg2.pkg3.EntryPointClass'/>
<source path='pkg3'/>...
I am not a big fan of having sub packages in the resources folder.
Hence I am trying to change it to something like the following
project-name/src/main/java/pkg1/pkg2/pkg3/EntryPoingClass project-name/src/man/resources/ModuleDef.gwt.xml
Also changed the module definition to
... <entry-point class='pkg1.pkg2.pkg3.EntryPointClass'/>
<source path='pkg1.pkg2.pkg3'/> <!-- Since the module def is not
inside any package I am specifying the entire 'client' package here --> ...
After this, invoking gwt compile fails with the following error
Unable to find type "pkg1.pkg2.pkg3.EntryPointClass"
Can anybody tell me if there is any relation between the package
structure of the EntryPointClass and the module definition package
structure apart from the fact that the EntryPointClass should be
inside the 'client' package specified in the module definition (which
is satisfied here)?
Btw, I could see that the compiled classes are available in the
classpath when invoking the gwt compiler.
Any help in this regard is greatly appreciated.
GWT compiler needs sources of client side classes, not only compiled bytecode. Is it in classpath?
In my company we always set pom.xml to copy sources to target as resources:
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
</resource>
<resource>
<directory>src/main/java</directory>
<includes>
<include>**/client/**/*.java</include>
<include>**/*.gwt.xml</include>
</includes>
</resource>
</resources>
</build>
Change **/client/**/*.java to anything satisfies your needs (probably pkg1/pkg2/pkg3/**/*.java). This way sources of client part are always in classpath.
I have a standard (I think) web project developed with the eclipse IDE. I wish to port it to Intellij idea 8.1 - I think that, among other things, it has better taglib support.
My project structure is as follows:
Project Folder
./src [java source files etc.]
./conf [configuration files - log4j, spring beans...]
./buid [ant files]
./WebContent
./WebContent/images [image files]
./WebContent/META-INF
./WebContent/META-INF/context.xml
./WebContent/pages [.jsp+.html files]
./WebContent/scripts [.js files]
./WebContent/skins [.css files]
./WebContent/WEB-INF
./WebContent/WEB-INF/classes [.class files]
./WebContent/WEB-INF/lib [.jar files]
./WebContent/WEB-INF/tags [.tag files]
./WebContent/WEB-INF/web.xml
I can't seem to get this project configured with my local tomcat server (version: apache-tomcat-6.0.18).
I think that a good answer would be a standard, step by step, cookbook answer as to how to port (and perhaps how to correctly define a tomcat web application within intellij idea).
Thanks all!
I think the first step would be to create a stand-alone build file which will produce a WAR. Do this before attempting to import the project into InteliJ.
I would use Maven. Creating a maven POM file to create a WAR is almost trivial and you can easily override the the default locations for your src, conf, and web content to match you existing src directory. Then test the build by deploying your newly Maven created WAR to Tomcat. I wouldn't think this first task would take more than a half day (at most a full day).
IntelliJ has a built in utility to import Maven projects. Then you should be off and running....
Regardless of the IDE you finally settle on, your project will be much better off in the long run for the Maven migration.
You initial Maven POM file will look something like this...
<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/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.yourcompany.yourapp</groupId>
<artifactId>yourapp</artifactId>
<packaging>war</packaging>
<version>1.0-SNAPSHOT</version>
<name>Your project name here</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
<dependency>
*** other dependencies here ***
</dependency>
</dependencies>
<build>
<sourceDirectory>src</sourceDirectory>
<resources>
<resource>
<directory>conf</directory>
<includes>
<include>**/*.xml</include>
</includes>
</resource>
</resources>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.0</version>
<configuration>
<webResources>
<resource>
<!-- this is relative to the pom.xml directory -->
<directory>WebContent</directory>
</resource>
</webResources>
</configuration>
</plugin>
</plugins>
</build>
</project>
*** This is an example POM only... It's just meant to get you started and may not work "as is".
Start off by creating an empty web application for tomcat, within IntelliJ - and make sure that it deploys correctly
This will produce a directory structure that you should then be able to copy your source files/web assets into.
The thing that you'll probably need to handle differently is the lib files - don't store these directly in the WEB-INF directory, as keeping them in a separate 'library' area, and allowing the IDE to include them in the WAR at build time is generally a better approach, as it promotes re-use across projects.
The key thing to aim for is to not try to set your project up to completely mirror a tomcat application, as the build process will pull together the various parts for you. It all breaks down into 3 sections...
Static assets - images, config files and jsp files (Ok, I know JSP files are kinda dynamic)
Java classes - source code that you write yourself (The IDE will compile these and place them in the appropriate location)
Java Libraries - third party code that you compile against (Again the IDE will place these in the appropriate location)
There are a few bits of configuration, within the project file, that you'll need to tweak to suit your needs, but it's generally straightforward.
By default, log4j will look for it's configuration file (either log4j.xml or log4j.properties) from the classpath of your application. So this means you should place it in WEB-INF\classes, or you can specify a different location with the environment variable log4j.configuration. See the log4j manual.
What IDE you use should have no impact on the structure of your application when it gets deployed to your servlet container. It sounds like maybe you were relying on Eclipse to package the files in a specific way - this is probably a bad practice. Are you using an actual build script?