I do have some configuration files. Currently these files are completely written manually. But some parts do change from time to time, like version number or current year.
In my ant scripts I could define some variables within the config files and replace these variables during my deployment with the current values. But I do use ant for the full automated nightly build. For normal and interactive work with the software, I do use Eclipse directly without any ant target.
Does anyone know any way how to replace such variables also within Eclipse deployment?
Of course, I could keep my source-config file with variables and use ant to create the final config file also in the source folder which is deployed and used, so both are checked in. But this is also redundant information and looky like a hack to me!
Because of so many misunderstandings:
I would like to have a source-config file with e. g. #MY-VAR# within the text. During deployment, this placeholder is replaced by a variable value known at compile time. This is possible with ant. Can I do something similar with Eclipse?
How do you read the variables? I would go for system wide properties, this will also work on Linux and Windows platforms and can be changed from computer to computer.
Are you developing in Java ?
Would this be helpful ?
http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.cdt.doc.user%2Ftasks%2Fcdt_t_run_env.htm
Related
I need to provide a settings file for my program, to which the user should have access to write some of the settings i need.
I created a file under a new directory (called settings) on the root of my application, but i have problem finding it at run time.
I use
File SettingsFile=new File(ClassLoader.getSystemClassLoader().getResource(".").getPath()+"settings/CreateSettings.txt");
When i execute this under eclipse i get
/application/home/dir/target/classes/settings/ZipCreateSettings.txt which is wrong.
If i execute it on terminal using java -jar, i get the correct path,
/application/home/dir/settings/ZipCreateSettings.txt
This would cause me problems cos i need to run the application directly from eclipse and not use the terminal, even though it is going to be executed using the jar when it is up and running.
I cant keep it like that anyway, cos this code might end up in someone else's hands, and they would have no idea what to do with it.
I have also used some other techniques like
new java.io.File("").getAbsolutePath(); but this always gives me the current working directory, so if i execute the jar from /home, i would get /home.
I think the problem might be maven (which i am not familiar with at all) since my code worked with a plain java application some time ago.
Since your file will be located outside your classpath, it is basically outside your application. Your application is not aware of files existing outside it's classpath. So you will need some kind of way to provide the Full/Absolute path to your file. You can't use the classloader in your case.
I suggest you use a system param instead of a hardcoded value. See here
I have a JavaFX app that reads in a configuration file. I'd like the config file to remain outside of the jar to facilitate modification without recompiling. Is there a way to set up netbeans to grab the config file and include it in the installer?
I've found the option to change to icon and that works fine but I haven't been able to discover how to tell it to also include specific external resources.
I've read the information posted here: http://docs.oracle.com/javafx/2/deployment/self-contained-packaging.htm but I'm still not seeing a way to accomplish this.
I don't think there's a way to do this (though I may be wrong). I needed something similar to this once, and the approach I took was
Package the file in the jar file
At program start-up time, check to see if the file exists in the expected location on the local drive
If it's there, read it, etc
Otherwise, read the contents from the jar and write them to the expected file
This solves the problem of "deploying outside the jar", and it also solves the problem of the user inadvertently deleting the file after deployment, etc.
The way I solved this issue (due to having many dependent .dll's and other type items) was to use netbeans to compile the jar, which has things like images/css/fxml etc. etc. and then use an Inno Script to actually compile and configure the installer, since inno makes it pretty straightforward to include extra resources. I have yet to find a way to do this properly within javafx itself.
One of the problems I'm running into is that my jar files and my source files don't match.
I'd like to:
Be Notified when when source and binary don't match (I think Visual Studio can do something like this...)
Set break points not by line, but by function. For example, set a break point at the entry of function foo().
I use eclipse mainly; so Solutions for eclipse would be most appreciated, but any IDE (or command line debugger) will do.
Thanks!
When developing just use and link to .class files that are saved by your IDE.
If your project starts to grow to a point where it's really useful to link to a .jar you're better off treating the jar's as separate projects.
Go to Project tab in Eclipse and then
click clean: Project->Clean…
click build automatically: Project->Build automatically
Use method breakpoints instead of line breakpoints. They can be set to halt on entering/exiting a method. You get them by double clicking the left editor side in a line containing a method declaration.
The debug information is limited to line numbers in the source file... I do agree that having a warning that the lines are wrong would be nice, but that would require more meta data in the jar than I think is available...
You might want to consider addressing the challenge with a change in your build process. This isn't exactly answering your question, but hopefully it will give you a strategy that will address the underlying problem.
When you generate the jar for deployment, also generate a jar with the binary AND source. For investigating the source code of a stack trace on the live server, set up a separate project in eclipse and have the binary+source jar be on the classpath. You may have to explicitly set the source code location back to the same jar (though I think Eclipse will just do this automatically).
Then you just have to add copying of the binary+source jar into the appropriate location in your workspace as you do your deployments (preferably with a deployment script).
If it's your server, you may want to even consider deploying the binary+source jar to the live server - that way you will always be able to get at the source.
I have a Java application installed. The jar is bundled into an .exe file using Launch4J. Now I want to create a patch for this application.
If I create another jar containing only updated files, how can I refer it in the original code?
I have java application installed. ..Now I want to create a patch for this application.
This is one of the strengths of the Java Web Start launch technology that comes with the J2SE. Simply update the Jar on the server, and the next time the app. launches, it will be updated.
The update can be honed for your use-case, configured to be done lazily or eagerly, before or after launch, or even programatically controlled using the JNLP API's DownloadService.
..And the jar is bundlled into an .exe file ..
'Unfortunately', JWS works on Windows, ..and Mac., and *nix - so you may have to expand your horizons.
BTW - I have no idea how to do the same with Launch4J, but then, that is really the wrong question. I aim to provide an answer to the right question, which is "How do I deploy & update a Java rich client?". ;)
I've never worked with Launch4J, however I think you should try to affect the classpath. JRE always loads the classes from the classpath. From this point of view, jars have no added value and just serve as a containers for your *.class files and resources.
Now, if you succeed to configure your tool to do something like:
classpath = C:\Temp\my_patch_path;$your_current_classpath
then its enough to put your changed files into C:\Temp\my_patch_path (of course preserving the package structure). JRE will load your classes first in this case.
Hope, this helps
Mark
It is might not be possible to do this without changing the contents of the exe.
I was unfortunately forced to result to uploading a WAR file as my backup for a web application I am working on.
Luckily I have the most recent WAR file available. I am using Eclipse IDE and am using the Web Tools plugin for all the J2EE work that I am doing with the Dynamic Web Application Project.
When I imported my WAR file, and ran it on a local server, everything works fine. The problem I a ran into is that in the Java Resources/src folder that all my packages and .java files were now only consists of all the same packages, but they are empty.
I checked to see if I could find the files and I found the .class files in an "Imported files" folder that is not accessible in the Eclipse Project Explorer. I believe that I need to do some type of build or something so that my .java files are available for me, but unfortunately this is one area where I lack.
One thing I would also like to know is, one way or the other, am I able to obtain the .java source code files if I have access to the .class files?
Also, I would like to configure this environment as it was before where my Java Resources:src folder contaiend the packages and .java files.
One thing I would also like to know is, one way or the other, am I able to obtain the .java source code files if I have access to the .class files?
The short answer is No. There is no way to regenerate original source files from bytecode files.
If you were really, really desperate you could try to use a Java bytecode decompiler on your bytecode files, but the result will be be nothing like your original source code.
All comments and javadocs will be gone.
All original code layout will be gone.
Original local variable and parameter names may be gone, depending on your original compiler switches.
Constant expressions may have been pre-evaluated, and loops, string concatenations and other constructs may have been transformed unrecognizably.
Depending on the maturity of the decompiler, the Java code might not be semantically equivalent to the original code, and might not even be compilable.
I hope you haven't spent too long developing this application because the best answer may be to start again.