I am creating a plugin for Eclipse, which contains tools for creating a custom type of project. These projects have a custom nature and builder. My builder (implements IncrementalProjectBuilder) takes a single input file, and generates a few (usually between 3 and 5) output files. When I run Clean Project, I need to remove the files the builder has previously generated.
Problem 1: The names of the generated files are not known exactly, but I do know the sort of files I expect to find (e.g. I know the extensions, and partial file names).
Problem 2: The user may add their own files to the project, which should not be affected by my build / clean steps.
My initial attempt was naive: remove every file except from the input file. This works, but has obvious problems.
My second attempt was better: I came up with a list of possible file names that may be generated, see if any of them exist and remove them.
By only knowing partial file names and matching them, I may inadvertently delete a user's file. E.g. I know I will generate a file called *_file.py. If the file I generate is called abc_file.py and the user has added their own xyz_file.py, I want to clean (remove) abc_file.py but leave xyz_file.py untouched.
The program which generates the output files from the input is constantly changing, and I don't want to rely on a concrete list of files that would need constant maintenance.
So, my question comes down to this. What methods exist for identifying the files generated by my custom builder, so I can remove them during a clean?
I've spent a couple of days Googling this one with not much to show for it. I am vaguely aware of a file system watcher in Java (Java7 WatchService?), but I don't know if that's the best solution to this problem.
Any information, advice or ideas appreciated.
One brute force approach would be to compare the project before and after the other program is invoked to get the list of files that were created/generated. Of course, it would be ideal if that program could somehow tell you which files it created. Once you have that list, you could iterate over those files as IFile's as use the setDerived() method to mark them as not being source files. When it comes time to clean the directory, you could use the derived setting to decide which files can be deleted.
Related
I am working with the apache orc-core java api. I have noticed a couple of things and was wondering if there are options to control them
Does not overwrite files. The call to OrcFile.createWriter fails if the specified file already exists. Is there an option to get it to overwrite by default?
Generates .crc files. If I write to a file called test.orc the program also creates a file called .test.orc.crc. Is there an option to disable this?
I know I can work around both of these simply by deleting the relevant files in the code. Was just wondering if there was a "proper" way.
I've used this method for extracting the Java and XML files from the apk file but my Java files have a lot of modifications which for sure wasn't there in the original code.
For example, in one class appears for several times access$902, access$902 ,string of digits like 2130903064. They appear in the place of other methods or variables and the project doesn't build because of them.
Can be there extracted the original files or is a solution for this problem? Thanks
No.
Because build process generate .class files, and reverse engineering nevers get to the original code (AFAIK).
If the .apk file was generated using the proguard, this will be less readable and more difficult to understand.
The best alternative is use the AndroChef java decompiler, that runs in windows. This tool can allow you to change the method / variable / class names to be more readable, including the generated files.
The original code only the developer / company owns. I hope you are not using this for something illegal.
I'm creating a simple Eclipse plugin in which I'm modifying an XML file using an editor, in this editor I have two buttons to add and remove entries in the XML file, and I need to identify the exact code generated by the editor (which XML entries where added/removed since the last time the file was saved).
I was exploring the IResourceChangeEvent and ResourceDelta class but it only let you know if the file was modified or not, but not the actual change. Is there a way to do that?
As you already mention, the workspace sends IResourceChangeEvents only after a resource was written. To get deltas you have to track the content yourself.
The workspace keeps a local history of files. You may want to look into IFileHistory and IFile#getHistory() to see if this is suitable for your needs.
I have to create a jar with a java application that fulfills the following features:
There are xml data packed in the jar which are read the first time the application is started. with every consecutive start of the application the data are loaded from a dynamically created binary file.
A customer should not be able to reset the application to its primary state (e.g. if the binary file gets deleted for some reason, the application should fail to run again and give an error message).
All this should not depend on the os it is running on (which means e.g. setting a registry entry in windows won't do the job)
Summarizing I want to prevent a once started application to be reset in order to limit illegitimate reuse of the application.
Now to my ideas on how to accomplish that:
Delete the xml from the jar at the first run (so far I came to the understanding that it is not possible to let an application edit it's own jar. is that true?)
Set a variable/property/setting/whatever in the jar permanently at the first run (is that possible)
Any suggestions/ideas on how to accomplish that?
update:
I did not find a solution for this exact problem, but I found a simple workaround: along with my software I ship a certain file which gets changed after the program is started the first time. of course if someone keeps a copy of the original file he can always replace it and start over.
Any user able to delete the binary file, will, with enough time, also be able to revert any changes made in the jar. When the only existing part of the application is in the hand of the user, you won't able to prevent changes to it.
You can easily just store a backup of the original jar, make a copy, use that for one run, delete, copy the original jar, etc. You would need some sort of mechanism outside the users machine, like an activation server. The user gets one code to activate an account, and can't use that code again.
I am developing a Java Desktop Application. This app needs a configuration to be started. For this, I want to supply a defaultConfig.properties or defaultConfig.xml file with the application so that If user doesn't select any configuration, then the application will start with the help of defaultConfig file.
But I am afraid of my application crash if the user accidentally edit the defaultConfig file. So Is there any mechanism through which I can check before the start of the application that whether the config file has changed or not.
How other applications (out in the market) deal with this type of situation in which their application depends on a configuration file?
If the user edited the config file accidentally or intentionally, then the application won't run in future unless he re-installs the application.
I agree with David in that using a MD5 hash is a good and simple way to accomplish what you want.
Basically you would use the MD5 hashing code provided by the JDK (or somewhere else) to generate a hash-code based on the default data in Config.xml, and save that hash-code to a file (or hardcode it into the function that does the checking). Then each time your application starts load the hash-code that you saved to the file, and then load the Config.xml file and again generate a hash-code from it, compare the saved hash-code to the one generated from the loaded config file, if they are the same then the data has not changed, if they are different, then the data has been modified.
However as others are suggesting if the file should not be editable by the user then you should consider storing the configuration in a manner that the user can not easily edit. The easiest thing I can think of would be to wrap the Output Stream that you are using to write the Config.xml file in a GZIP Output Stream. Not only will this make it difficult for the user to edit the configuration file, but it will also cause the Config.xml file to take up less space.
I am not at all sure that this is a good approach but if you want to go ahead with this you can compute a hash of the configuration file (say md5) and recompute and compare every time the app starts.
Come to think of it, if the user is forbidden to edit a file why expose it? Stick it in a jar file for example, far away from the user's eyes.
If the default configuration is not supposed to be edited, perhaps you don't really want to store it in a file in the first place? Could you not store the default values of the configuration in the code directly?
Remove write permissions for the file. This way the user gets a warning before trying to change the file.
Add a hash or checksum and verify this before loading file
For added security, you can replace the simple hash with a cryptographic signature.
From I have found online so far there seems to be different approaches code wise. none appear to be a 100 hundred percent fix, ex:
The DirectoryWatcher implements
AbstractResourceWatcher to monitor a
specified directory.
Code found here twit88.com develop-a-java-file-watcher
one problem encountered was If I copy
a large file from a remote network
source to the local directory being
monitored, that file will still show
up in the directory listing, but
before the network copy has completed.
If I try to do almost anything non
trivial to the file at that moment
like move it to another directory or
open it for writing, an exception will
be thrown because really the file is
not yet completely there and the OS
still has a write lock on it.
found on the same site, further below.
How the program works It accepts a ResourceListener class, which is FileListener. If a change is detected in the program a onAdd, onChange, or onDelete event will be thrown and passing the file to.
will keep searching for more solutions.