I'm working on a web application.
This is my project structure
src/
├── main
│ ├── java
│ ├── resources
│ └── webapp
└── test
├── java
└── resources
In my tests I want to call a method from a class in java which uses a file in resources.
So I want to know how to share my resources between main and test?
I don't want to copy files to test-resources every time I edit them.
I tried SymLink but got an error 'Can't copy to test-classes because file does not exist.`
And this is how I access a resource in case it matters
class.getResourceAsStream("/data.yml");
EDIT
So, apparently Maven do share resources between main and test by default but it's not the case here.
When I build I can see my resources from main under target/classes but nothing in target/test-classes.
Files present in main are visible in test.
So you can put resources on the main tree if necessary for both tests and main.
If the resources are necessary only for the test put them on the test subtree.
With Maven, your files under src/main/resources are shared with src/test/resources by default. Just put them there and they'll be accessible from the test folder as well.
Related
I have a .jar that I built following the Oracle docs, using jar cfm hangman.jar Manifest.txt src/classes/app/Main.class. The manifest.txt file contains Main-Class as classes.app.Main, telling where my Main class is. When executed, ClassNotFoundException is thrown, saying it couldn't find classes.app.Main. I need help trying to understand what's wrong here. Is it the main class or maybe a missing classpath?
Here's the project tree:
.
├── hangman.jar
├── Manifest.txt
├── README.md
└── src
├── app
│ ├── Main.java
│ ├── Player.java
│ ├── Players.java
│ ├── Play.java
│ ├── Themes.java
│ ├── Word.java
│ └── Words.java
└── classes
└── app
├── Main.class
├── Play.class
├── Player.class
├── Players.class
├── Themes.class
├── Word.class
└── Words.class
You don't show the code, but it is extremely likely that the package for your class is just app not classes.app, and classes is only a directory name to contain the class files, not actually part of the package hierarchy. The name of a class file entry in a jar, OR the name of a class file relative to a classpath directory, must be exactly a directory path equal to the package hierarchy (if any) plus the class name and the suffix .class, with nothing added or removed. This means your jar should be created by going to the classes directory and then adding the file(s) relative to that directory:
jar cfm hangman.jar Manifest.txt -C classes app/Main.class
and the Main-class entry in the manifest should be app.Main. If you only need main-class in the manifest and nothing else (except version, IIRC), you can have jar create it for you:
jar cfe hangman.jar app.Main -C classes app/Main.class
Also I note that there are other classes in your source tree. If these classes are called or referenced from the Main class, directly or indirectly (i.e. nested), they must also be in the jar. You probably want to use app/* instead, although it is possible you want or even need to be more selective.
Meta: I thought this was covered in the standard tutorial, but although most of the pieces are there they aren't really pulled together anyplace I could find and refer to.
in my project I decided to split unit and integration tests into separate packages and my project structure basically looks like this:
├── main
│ ├── java
│ │ └── ...
│ └── resources
│ └── ...
├── test
│ └── java
│ └── ...
└── test-integration
├── java
│ └── ...
└── resources
└── ...
It is a good choice to easily separate two kinds of tests, and intellij refactoring works fine with this solution. Everything is set up correctly, both test directories are marked as test sources roots using gradle's idea plugin, gradle recognizes both source sets, I have two separate tasks created to run each test suite etc. The only problem I have is that intellij automatic create test wizard doesn't differentiate between these two directories, and the only thing I can modify is the Destination package classpath, which obviously is identical for both test directories, and there is no option to choose which one I'd like to use.
Is there any way to configure IDEA to give me an option to choose between directories the test will be generated in? Or maybe some kind of gradle plugin that will move test files based on their suffix (e.g. *Test classes go to test directory, and *IT classes go to test-integration directory)? Or maybe there simply is no such option :D
There is no option to do that. Here's the source for that dialog. Ultimately what determines the directory is this method:
protected static List<VirtualFile> computeTestRoots(#NotNull Module mainModule) {
if (!computeSuitableTestRootUrls(mainModule).isEmpty()) {
//create test in the same module, if the test source folder doesn't exist yet it will be created
return suitableTestSourceFolders(mainModule)
.map(SourceFolder::getFile)
.filter(Objects::nonNull)
.collect(Collectors.toList());
}
IntelliJ is very extensible. You could write your own plugin relatively easily which changes this behaviour, by replacing the dialog associated with the action with your own dialog. Your own dialog could mostly be a copy-paste of what's already there, but with a different implementation of selectTargetDirectory.
The next step after "Create Test" dialog should be "Choose destination directory":
The behaviour in v2020.1.1 (https://www.jetbrains.com/idea/download).
I have a web app I want to deploy on Azure. I followed the recommended instructions and deployed my app, and according to the Azure portal, everything is working just fine. However, when I visit the base URL my app should reside in, I see a page that says the following:
This Java based web application has been successfully created
There's nothing here yet, but Microsoft Azure makes it simple to
publish content with GIT and FTP
Also when I visit any one of the endpoints (in this case, the /live endpoint) my app should have, I always see a page with the following message:
HTTP ERROR 404
Problem accessing /live. Reason:
Not Found
Powered by Jetty:// 9.3.13.v20161014
When I look at the directories on the machine, everything seems to be in place. All my files are inside wwwroot. However, there's another directory named webapp under wwwroot and inside it is another directory named ROOT with two files: index.jsp and background.png. index.jsp is the page that shows the aforementioned "There's nothing here yet" message.
I'm using Bitbucket as my source control provider and I use jetty to run my web app. I'm also using javalite as the library to manage my server and different endpoints.
You'll need to put your stuff under wwwroot/webapps/ROOT/, or package as ROOT.war and drop that under wwwroot/webapps - it will get picked up and extracted automagically:
wwwroot
└── webapps
└── ROOT
├── about.jsp
├── Content
│ ├── favicon.ico
│ └── Site.css
├── Images
│ ├── banner_coffee.png
├── index.jsp
├── META-INF
│ ├── context.xml
│ └── MANIFEST.MF
├── orderconfirmation.jsp
├── placeorder.jsp
├── Scripts
│ ├── jquery-1.7.1.min.js
└── WEB-INF
├── classes
├── lib
├── log4j.properties
└── web.xml
From https://github.com/Azure-Samples/app-service-web-java-get-started:
The main thing in the repo is a webapps folder with ROOT.war. The Tomcat/Jetty server in App Service will look inside this folder for web apps to host.
ROOT.war represents the default web app (at the site root). Any WAR file that's otherwise named represents a web app accessbile at ~/<WARfilename>.
Clearing things up
If your application sits in wwwroot/webapps/CoffeeShop/, then you'll access it at http://{site}.azurewebsites.net/CoffeeShop/.
If your application sits in wwwroot/webapps/ROOT/, then you'll access it at http://{site}.azurewebsites.net/.
I have a NiFi processor, that uses the redislabs/luascript lib in order to load a lua script and execute it on a redis instance.
The thing is that I don't know where exactly to put the lua script in order to load it using the luascript lib. I've put it into the nifi_proc/src/main/resources/lua/name.lua, but I get an IOException.
I have a nifi controller service for connecting to redis and a processor that uses that service.
My project structure:
.
├── nifi-bundle-nar
│ └── target
├── nifi-redis_cservice
│ ├── src
│ └── target
├── nifi-redis_cservice-api
│ ├── src
│ └── target
├── nifi-redis_cservice-api-nar
│ └── target
├── nifi-redis_cservice-nar
│ └── target
├── redis-processors
│ ├── src
│ └── target
└── target
└── maven-shared-archive-resources
Any ideas?
Can you share more information about how the processor is interacting with the library? Are you passing in an InputStream, calling out to a executable, etc.?
Ensure your resource is in the JAR module of your processor's project, not the processor's NAR module or the parent (that includes both). You should be able to use getResourceAsStream("lua/name.lua") from a Class object that is in the processor's JAR file (such as the processor class itself). I'm not sure what you'd need to do with it after that, is it possible to share the source code or more details around it?
EDIT (reply to comments below): fromResource() uses LuaScript's classloader to get the resource, I wonder if it doesn't have access to the nifi-proc or controller service resources. It seems like, unless the user needs to specify the location of the script, that the controller service should be loading in the Lua script. So an alternative could be to use the controller service class to getResourceAsStream, read the whole thing into a String, and use fromSource instead of fromResource.
How can I import a library from maven central into a project with the ceylon import-jar command?
Please show the full command.
E.g. for "joda-time-2.9.4.jar" from "http://repo.maven.apache.org/maven2/" into a local directory.
I guess it must be:
./ceylon-1.2.3/bin/ceylon import-jar --rep "http://repo.maven.apache.org/maven2/" --verbose --out localdir "joda-time:joda-time/2.9.4" "joda-time-2.9.4.jar"
But as far as I can see the tool is not working (ceylon versions 1.2.2 and 1.2.3).
Working with maven central is essential.
This question is linked with The ceylon copy tool because both tools present me with a riddle.
I understand you are asking about the ceylon import-jar tool specifically, but would like to offer a different solution that is easier if your goal is to import a jar from a remote repository.
I would suggest you use the Ceylon Gradle Plugin, which I wrote.
It knows how to grab dependencies from repositories (including JCenter and Maven Central, but many others), and it will run the ceylon -import-jar tool for you automatically.
Full Example:
Run the following command to create a new test project (enter simple for the folder name):
ceylon new simple --module-name=com.athaydes.test --module-version=1.0
Enter the new project name and have a look at what's in it (minimum Ceylon project):
cd simple
tree # or use Finder, Window Explorer or whatever
You'll see this:
└── source
└── com
└── athaydes
└── test
├── module.ceylon
├── package.ceylon
└── run.ceylon
Edit module.ceylon so it has the following contents (add whatever dependencies you want):
module com.athaydes.test "1.0" {
native("jvm")
import joda_time.joda_time "2.9.4";
}
Notice the name of the module must be a valid Ceylon identifier! So, the Gradle plugin replaces invalid characters with _, generating a valid Ceylon identifier from the Maven artifact name.
Create a build.gradle file at the root of the project so the Gradle plugin can work, with the following contents:
plugins {
id "com.athaydes.ceylon" version "1.2.0"
}
repositories {
jcenter()
}
ceylon {
module = "com.athaydes.test"
flatClasspath = false
importJars = true
forceImports = true // necessary to bypass optional dependencies issues in Maven poms
}
dependencies {
ceylonCompile "joda-time:joda-time:2.9.4"
}
We must declare this dependency here as a normal Maven dependency so Gradle knows where to get the Jars from.
Done... now just run importJars:
gradle importJars
Or, to just see the actual command generated (will not actually run it):
gradle -P get-ceylon-command importJars
Here's the generated command:
ceylon import-jar
--force
--descriptor=/Users/renato/programming/experiments/ceylon-gradle/simple/build/module-descriptors/joda_time_2.9.4.properties
--out=/Users/renato/programming/experiments/ceylon-gradle/simple/modules
--rep=aether:/Users/renato/programming/experiments/ceylon-gradle/simple/build/maven-settings.xml
--rep=/Users/renato/programming/experiments/ceylon-gradle/simple/modules
joda_time.joda_time/2.9.4
/Users/renato/.gradle/caches/modules-2/files-2.1/joda-time/joda-time/2.9.4/1c295b462f16702ebe720bbb08f62e1ba80da41b/joda-time-2.9.4.jar
The jars will be imported to the default location, modules (but you can configure that):
── build
│ ├── dependency-poms
│ │ └── joda-time-2.9.4.pom
│ ├── maven-repository
│ │ └── joda-time
│ │ └── joda-time
│ │ └── 2.9.4
│ │ ├── joda-time-2.9.4.jar
│ │ └── joda-time-2.9.4.pom
│ ├── maven-settings.xml
│ └── module-descriptors
│ └── joda_time_2.9.4.properties
├── build.gradle
├── modules
│ └── joda_time
│ └── joda_time
│ └── 2.9.4
│ ├── joda_time.joda_time-2.9.4.jar
│ ├── joda_time.joda_time-2.9.4.jar.sha1
│ └── module.properties
└── source
└── com
└── athaydes
└── test
├── module.ceylon
├── package.ceylon
└── run.ceylon
Now you can run the Ceylon code with the runCeylon task (or just run if there's no other task with this name):
gradle run
NOTE:
Unfortunately, actually importing the specific Jar you chose into the Ceylon repo is impossible with its original name... because in Ceylon, joda-time is an illegal identifier... so you need to change the name of the module when imported by Ceylon. The Gradle plugin does it for you.. but you need to know what the valid identifier will be to be able to write the import statement in the module file (you can just let the plugin run and it will tell you what the name will be).
A much simpler approach
If you want to avoid the complexity of this approach, you can just use the default Gradle plugin approach to NOT import Maven jars into the Ceylon repository and just use the simple Java classpath (which means you relinquish using the Ceylon modules system!).
If you do that, your build.gradle file will look like this:
plugins {
id "com.athaydes.ceylon" version "1.2.0"
}
repositories {
jcenter()
}
ceylon {
module = "com.athaydes.test"
}
And the module.ceylon file:
module com.athaydes.test "1.0" {
native("jvm")
import "joda-time:joda-time" "2.9.4";
}
Notice that we don't need to mess up with the dependency name using this approach. From Ceylon 1.2.3, you should prepend the dependency with the maven: qualifier to avoid warnings.
That simple!
1. As a (partial) answer to my question, this turned out to work:
$ ../bin/ceylon import-jar --rep flat:"../flat/" Jama/1.0.3 ../flat/Jama-1.0.3.jar
I downloaded the jar (in this case Jama-1.0.3.jar) by hand and then I was able to import it.
I had to try a lot to find out where to put the prefix "flat:", i.e. either to put it after "import" in the module descriptor "module.ceylon" or on the command line. The latter turned out to be the right choice.
But still, I haven't been able to find out how to import the jar from maven directly using the import-jar tool.
2. More detailed documentation is needed about managing modules. Specifically, there should be a clarification what the term "legacy repository" means.
Does "legacy" mean "deprecated"?
3. I hope that the following way to import dependencies into a project is not considered as "legacy" or "deprecated":
a) Rename the jar file, so that the name relfects the compressed directory structure within the jar.
b) Put the jar into a directory structure that again reflects the directory structure within the jar.
c) Put all that into the modules directory of the project, merging directories if necessary.
This seems to be the most explicit and reliable way to include dependencies into a project and I hope this way will not be deprecated or considered "legacy" at any time.