I'm developing Java application on Eclipse, using Gradle. From the application I want to access the files in src/dist folder. When developing, I can access the files by using the path src/dist. But when the application was exported to "distributed" style (by using Gradle task installDist), the relative path from System.getProperty("user.dir") to the files in src/dist will change.
What it the best way to access to those files seamlessly both while developing and after distributed, either by changing my Java source code or Gradle build script? I have come up with following ideas:
Add an option that indicates the actual location of the files. When running on Eclipse I can add the options to the Run Configuration.
Check if the program is running inside jar. I can do it by checking getResources() or something.
Please tell me if you have better way to achieve this, or what is the best practice from the viewpoint of maintainability.
Related
Recently I have been working on a project in which I must use baddas jlink's jpackage to build that project. I have problems accessing files in jpackage's build directory. Let me give an example:
Now here, I want to access settings.properties file in my java application. What should I do?
I am Java developer, recently working on Xpages project. we are using Notes 9.0.1. I created Java agent to send email and I want to use some third party jar, something like org.apache.commons.lang3 , end up this issue. how to add third party jar, like commons-lang3-3.4.jar, in my Xpages project?
I tried different ways
add jar under /jvm/lib/ext folder, restart DDE.the I can see it in
my project JRE system libray, but could not import in my Java code.
Maybe this is the way for server deployment.
add jar under /Code/Jars and then DDE generated with new name added in /Webcontent/WEB-INF/lib, but...
Add jar directly under /Webcontent/WEB-INF/lib, but not appeared /Code/Jars in Application view
add jar under the Java agent Archive folder, but...
None of them allows me import the package in my Java code.
Anything I did wrong, or is there any good way to add third party jar in XPages project.
Thanks
If you add a JAR to your project by importing it into /Code/JARs, it should be added so as to be accessible by your build path(2,3). The same is true of your /WebContent/WEB-INF/lib, but that may not be automatically defined in your version of DDE; for example, Domino Designer 9 has the design elements of /Code/Java and /Code/JARs, which didn't previously exist (these are separate folders/paths from /WebContent/WEB-INF/src or /WebContent/WEB-INF/lib, either can be in the build path). In either case, if your approach is to have the JAR in your NSF, make sure your build path has the path with your JARs. Separately you could add each JAR individually.
You can get to the Build Path via Project > Properties, then for the part of your build path concerning JARs, go to "libraries":
individual JARs in Project Build Path
JAR class path in Build Path (ex- /WebContent/WEB-INF/lib)
As for the path of using the /jvm/lib/ext folder approach, I've covered that in a blog post and it's important to remember to have the JARs in the appropriate relative path both on the server and in your Designer/local path (otherwise your local, DDE, may not pick up the change).(1)
For both, if you keep build automatically turned off, you'll want to make sure you perform another build to see the changes.
As for a Java Agent archive, this should just work and again I'm wondering whether your build automatically setting is enabled/disabled. The /jvm/ext/lib path ought to work for this as well (shown in my linked blog post).(4) *Note: as Paul Withers points out in the comments, importing a JAR to a Java Agent can introduce memory leak issues, making the /jvm/ext/lib/ path preferable.
I am trying to add an external library to my Java project. The library files are in .jar format, and every time someone tries to run the project in a different environment, they have to modify the build path so that their environment can find the .jar files.
Is there any way to make it so that the .jar files are automatically found by the build path? Maybe by specifying where in the project the .jar files are located?
Edit: Here is an example -
In my linux environment, the .jar files are located in:
/home/MyUsername\SomeDirectory\workspace\java_project_name\data
In my windows environment, the .jar files are located in:
C:\MyUsername\SomeDirectory\workspace\java_project_name\data
In the example above, the project root directory is "java_project_name", and the .jar files are always in the java_project_name\data folder. Even though this is the case, different environments can't seem to detect that it is always in the same path in relation to the project's root directory.
I have looked in many places on how to do this, and some people told me it isn't possible. This doesn't sound reasonable to me, which is why I am posting this question here.
Thanks in advance for your help!
you can add a ClassPath: entry in your manifest file of the main jar, and use relative paths. As long as the jars are found relative to the main jar it will work.
This issue was one of my main motivators to start using maven.
#YoK nicely quotes here the relevant reasons to this question https://stackoverflow.com/a/3589930/1493954
Here is one the relevant quotes from Benefits of using Maven
Henning
quick project setup, no complicated build.xml files, just a POM and go
all developers in a project use the same jar dependencies due to
centralized POM.
getting a number of reports and metrics for a project
"for free"
reduce the size of source distributions, because jars can
be pulled from a central location
This is a common problem for developement environments.
I myself use the following solution in netbeans [Hope so that it works in your IDE too]:
Create an Ant variable [for e.g. JAR_LOCATION].
Each and every JAR that you refer, must have it's location relative to JAR_LOCATION.
Now, in every development environment that you're gonna use, you can set up the same ANT variable and it'll automatically pick up the JAR.
You can see the example in the given snapshot of netbeans..
I currently have a large Java program built using Swing and I am exploring the possibility of migrating to JavaFX. I am particularly interested in the ability to support native packaging since my current configuration involves simply double-clicking an executable JAR file and I find that many of my users are confused by this. Here is my problem: my program uses a plugin architecture in which, upon launching, it discovers various tools contained in JAR files and Groovy scripts. Because the end user can add their own tools by adding their own JAR library or script file the tools must exist in a folder outside of my main JAR. The folder must be discoverable by the end-user such that they could add/modify these files themselves. Here is my current configuration:
./ - the root of the program
|__ main.jar
|__ Resources folder containing JAR libraries and script files
This flexible configuration also allowed for the program to simply be copied into new locations without requiring a proper setup. So, I ask, is there any way of maintaining this type of open configuration while using the native packaging utilities that are now available? Would I need to create a resources folder outside the location of the JAR itself during some kind of setup? If this is the case, how do I go about doing this?
Alright, so I have a web service that was created using an eclipse dynamic web project. It is currently shared on a CVS repository, but the versioning system used is irrelevant. At the moment, I have literally NEVER been able to pull this project out as is and get it working. It leads to countless errors that cannot be fixed. Every time I need to work on this webservice in a new machine I have to create an entirely new dynamic project, copy over the source files, add all the necessary libraries and make the deployment assembly work correctly again. After finally making it run I share the project as the same one, stop after a second, and then synchronize again (in a way tricking eclipse into thinking this was the shared project all along).
I feel like others must have run into this problem and found a way around it. So if you have a web service or any dynamic web project, what files do you share, and how do you successfully pull it from the repository and get it to run on another machine besides what I currently do now?
Your help is much appreciated,
-Asaf
Edit: After reading some of the responses I feel that this question is actually more specific to those who use WTP to create/test their web services. Just wanted to add the clarification.
Edit2: Let me also clarify that the other 20 or so projects not using WTP are shared just fine. I am able to pull and run them with no problem. Only web service projects are an issue.
In general, you want to check in everything that's not "derived" (generated or compiled - that's usually the contents of the bin directory or other place where your code is compiled/built into). For Eclipse Java projects, you want to include the .project, .classpath, .settings, and any other similar files that Web Tools might create for Dynamic Web projects. The Eclipse CVS client will ignore files marked as Derived so you shouldn't have to worry to much about it.
Without more detail about what kind of problems you've run into, it's not possible to guess what was causing them. My only guess is that perhaps you had different versions of Eclipse and/or the WTP (Web Tools Platform) plugins installed on the different machine. That's just a wild guess, but could explain some incompatibility when you check out the project from CVS.
Bottom line, checking in those .* files is the long recommended approach from Eclipse gurus. Maven can kind of change things, but you didn't mention it so I'm assuming you aren't using it.
I am primarily sharing my experience, may be you can find some help.
Conceptually speaking, the files which the IDE can generate itself while creating new project should not be pushed. I.e the IDE specific files should not be pushed. And everything which the IDE cannot generate on its own must be pushed.
Forexample in case of eclipse, following files should not be pushed:
.settings
build
.classpath
.project
For setting the project on new machine, first pull the files from server, and then create a project from IDE using pulled files.
EDIT: If your project has external jars/libraries, then you will have to add to the classpath manually. You could also push .classpath but that might give errors while creating a new project.
I think it's easiest to use a build system and let the IDE generate the project from your build system.
Eclipse, Netbeans, and Intellij are all pretty good at building projects from maven or ant build files. With this solution you have a simple build that is easy to setup in CI (Hudson, Bamboo, whatever) and you don't have any IDE specific files checked in. If my workspace is totally different than yours, with different versions, plugins, whatever, I'm not stuck with your project file and you're not stuck with mine. My IDE creates the project appropriate for my environment and your IDE does the same for yours.
Since you mentioned having to manually add libraries, I assume you are not using any build manager (like, maven or ant) besides ecplise.
For ecplise to handle the project properly you need the source files (*.java) in their respective directories, any resources bundled with the web service (e.g. services.xml), the ".project", ".classpath", ".settings", etc. files for eclipse. This should be enough for eclipse to generate anything else necessary to build the project.
Any files/directories that are generated by eclipse during the build process (e.g. target & bin directory, *.class, *.war) should not be checked in -- they will be generated when needed during the build.
I am thinking that, since you are adding the necessary 3rd-party jars manually, these libraries might reside in a different path between computers (e.g. if the path contains the username, it will not be transferable to another computer for a different user). To fix that you can set up the classpath using an eclipse classpath variable. In Preferences->Java->Build Path->Classpath Variables set up a varable linked to the "root" folder where the 3rd party jars a stored. Then add the libraries to the project using this new variable, not their full path. To make it work on someone else's computer, you would only need to set this classpath variable to have the build path point to the correct libraries.
It might be beneficial if you migrated your project from eclipse only to a build manager (e.g. maven) that takes care of many of these issues for you. Eclipse can build a project from the configuration of the build manager, making it easier to manage the project.