I have java application. Every time when I'm doing changes in JSP file I need to copy saved JSP to another place (specific project). May be you know tool that can track changes in real time in files in specific folder and after every saving - copy these files to another folder, thanks.
Eclipse, IntelliJIdea like IDEs have a feature called Local History. you can view, compare replace each saved version through that by few clicks.
In java there is a support for watching file changes. You can use this to implement your own program that listen to file changes and save the version automatically whereever you want.
http://docs.oracle.com/javase/tutorial/essential/io/notification.html
Take a look at Apache Ant or Maven. These tools take a little customization, but once configured they make deploying a new version of your application as simple as a single command. Of course there is a learning curve for both Ant and Maven, so the larger and more complex the project, the more useful and time-saving these resources become.
If you really want the "quick and dirty" option for testing purposes, simply set up a Shortcut located in your Server root folder and pointing to the .jsp file in your development workspace. Give the shortcut the same name (and relative location) as the original and the shortcut will always mirror your development copy. Note that I do not recommend this option, and am only including it for completeness.
Related
I can't seem to find a setting in Eclipse to save and back-up a single Project to multiple paths.
I have a single Java Project in Eclipse that I save on my local machine and either save as... or copy replace to a local network and local mass storage, for BACKUP. I'd like that to occur on any, all Project saves.
I saw Project properties, but I'm not too familiar with Eclipse and team dev options, and I don't want to F the paths, links, etc.
Thanks.
EDIT: I'll try what user101 recommended, but to avoid confusion, My own personal, primary Linux box is where development is performed. The other locations are, for lack of a better word, BACKUPS. I used the term "Sync" for the sake of what my question may be related to.
Sorry for any confusion.
What I understood is that you want the sources from different paths , if so You can try as below
1> Create new java project
2> Click on link additional source
I'm using Visual SVN on my Windows Box.
I have Repository Application, which has Framework as an svn:external. All well and good.
When I make a checkout of Application, I'd like to have the version of Application and Framework for inclusion in a footer file. This way I could have something like:
Application Version $ApplicationVersion$, Framework Version $FrameworkVersion$
Ordinarily, I understand I could use svn:keywords and add the revision - but as I understand it, svn:keywords apply on a per-file basis. A few sites have suggested using svnversion to produce the output for each variable, but I'm not entirely sure how to go about this.
Once again, on a Windows Box, using VisualSVN. I also develop on a Mac using Versions.app if it provides a more familiar interface for people to answer :)
Edit - my application is a PHP web application. As such, there is no compiling.
Thanks!
To use svnversion, you need to integrate it into the build process. If you run it on a subversion checkout, it will output a string like 73597:73598, indicating what version your tree has (notice that different files may have different versions, plus files may have also local modifications). You put something like
CFLAGS+=-DSVNVERSION="\"`svnversion`\""
into your Makefile, and then put
#define VERSION_STRING "Application version" SVNVERSION ", Framework version" FRAMEWORK_VERSION
into the code. If you don't use Make, or cannot readily have your build process run a command whose output produces a compiler command line option, then you can also use the subwcrev utility that comes with TortoiseSVN. You use that as a pre-build step, and have it transform some file with placeholders into a copy of the file with the placeholders replaced with the actual version; then your compilation will compile and link the new file.
Edit: For the PHP case, it is not possible to have the revision written automatically into a file on checkout or update. Instead, you could run svnversion on every PHP access, putting its output into the HTML response. If that gets too expensive, you can cache the svnversion result in a file and only regenerate the file if it is older than one hour (say), leaving it up to the user to remember to delete the file after an update to make it recompute the cache right away.
I want to distribute a swing app to my client. In that application two property file are there, which should be visible to client so that they can edit, I can not give it as runnable jar. Also I want something like apache-tomcat zip file which once you extract it will arrange folder structure also will give property file to edit and on next run it reads that property. Also apache-tomcat starts with startup.bat or startup.sh like that I also want.
Use Java Web Start to install and update the application.
User editable properties
Put them in (a properties file in) the Jar
When you go to check for the properties, do so using the PersistenceService. If they do not exist, read them from the text file in the Jar, and put them there. Here is a demo. of the service.
When the user wants to see/edit the properties, show them via a JOptionPane.
Desktop integration
JWS offers desktop shortcuts and menu items to launch apps., when supported by the platform, as well as an API to install and remove them (see the IntegrationService). Much slicker than batch files!
Currently we are using GetDown to handle distribution of our swing applications. We use Tomcat to distribute updates and GetDown to download those updates. It's really flexible and powerful, and much better than java WebStart.
A good tutorial : http://www.hascode.com/2012/05/creating-updatable-java-applications-using-getdown-and-the-getdown-maven-plugin/
Project website : http://code.google.com/p/getdown/
If I understand you correctly you want a tool to make distribution package for your application. That generates folder structure and unpacks application and data files to this structure.
There are many free and commercial setup builders. I think you would prefer multi-platform builder, so look for java setup builder.
Check this thread, this question was discussed there.
I write cross-platform java app and I need some place where I can store some amount of files. These files will be used by another java application that may run under another user. This mean that I cannot use:
System.getProperty("user.home");
since I may have no permissions to read/write these files. What I need is some way to get non-user-specific folder where every app can create/read/delete files (something like "C:\ProgramData" for windows).
Is there a cross-platform way to get such folder(at least for Windows and Linux), or if there is no any - what is the best way to get such folders for Windows(should work on XP-7), Linux and Android.
Any pieces of puzzle are welcomed.
I'm not aware of such such a cross-platform folder which is additionally readable by all users. But you can:
Define a specific folder for each OS, commons-lang may help you determining the platform (see SystemUtils)
Check if the folder read/writeable for the current user during application start-up.
Using a central configuration (where the data exchange folder is defined for this installation) may also be an option, but this depends on the packaging of your project.
I use Eclipse to write Java code and use DropBox to sync my code with others' across our multiple computers. Most of the time, everything works as expected: if anyone makes a change on either end, the change is saved and when the other person refreshes the Eclipse workspace, the changes come through and can be viewed and run successfully.
Sometimes, one of several errors arises. Sometimes Eclipse says it cannot find a main class and sometimes it says it could not find the class itself. Sometimes it will not report an error but for some reason will not actually update the .class file and therefore run an old version even though the compiler displays the new source code and that saves. I've then noticed that if I manually copy the code into a new .java file elsewhere in the file system and then compile it, it works fine, but for some reason it refuses to regenerate the .class file and I have to delete it manually and replace it with the one generated in the other project--then it works. But for solving the other problems everything needs to be manually copied, deleted, and re-pasted....
[The actual errors include NoClassDefFoundError, UnsupportedClassVersionError, and some other error related to not having a main class.]
I realize that the description here is somewhat vague, but unfortunately I'm not entirely sure what's going on. I hope I'm just missing some basic fact that would help solve all these problems.
Thanks!
I'm sure you will see issues using Dropbox for sharing your source.
Eclipse does not know what Dropbox is doing whilst it's uploading and downloading updates and their activities will certainly not be synchronised. At arbitrary points in time when Eclipse tries to do builds etc. it will find unexpected activity going on, maybe even partially downloaded source files which might explain the specific errors you are seeing.
You're trying to do something more complex than sharing photos or documents. The advice I would give is to use a source control system like git or subversion for source code sharing and control. You can then make use of plugins for Eclipse that are designed to integrate these systems in an easy to use way. There's a learning curve there, but the skills will serve you well.
You can use online versions of these solutions like github and unfuddle if you want to consume sharing, backup and version control of source as a service like you do with Dropbox. They're free, too.
Subversion, Git and all version control software solve all of these problems for you.
Dropbox is not really an adapted system for sharing code. What you should do is set up a SVN, and commit only the source files. This way, you won't have these kind of errors.
Dropbox does have versioning (you can restore old versions of a file), and doesn't seem to be a horrible solution for the problem. I keep my Eclipse repository on Dropbox so it is available on any computer; but since I only use it myself, I haven't encountered your problems.
There is one case I can absolutely see you running into problems--it's if your class files are stored in the dropbox as well. This would just screw everything up. Make sure you specify a location on your local hard-drive for all build artifacts (classes, jars, ...) and that the only thing on your dropbox is the .java sources.
In fact, I suggest you don't keep your eclipse project in your dropbox, just create your eclipse project and point it to the java files in your dropbox.
If this doesn't work for you, go with what other people here said and set up a SVN repository somewhere, it's easier than you would think.
Oh, another possible problem--dates! You may want to make sure the date on your java files isn't jumping forwards and backwards (as might happen if one of your developers were in another time zone). In this case, Eclipse may prefer not to re-compile your file.
Also, instead of the copy/etc procedure you are currently going through, try forcing a project clean.
Response to request for more info:
When you start Eclipse, select/create a workspace that is NOT on your dropbox. The best place is probably off your home directory. If you have already specified a default workspace, there should be a switch workspace item in the file menu.
Create your project. select "Create project from existing source" and specify the source files in your dropbox. I think you want "create separate folders for source and class files" to keep your class files out of your dropbox. If you see anything saying "Copy files into your workspace, say "no".
This should give you a valid, working project. I hope you don't see those problems any more.
One more thing may help--and this may work on your existing project--without the above procedure...
Whenever you refresh your files (f5) to load in changes from the dropbox, select the Project/clean menu and select the project. This should delete all the class files and rebuild them.
If your classfiles are shared on the dropbox, this could still have strange consequences on other people with eclipse open, so I really do suggest rebuilding your workspace as I said above.
How to avoid no main class
Provide one. That issue has nothing to do with DropBox