I am using jpackage to pack my Java application and want to use it to create file associations. I see that the utility supports this via the --file-associations command. Using this, you can point it to a file that includes file association information.
Does anyone know of documentation that gives a better description of how to create this file-association file? The help documentation in the utility itself describes keys that must appear in it, but there's no hint at how it needs to be formatted.
Here is what the packager lists in its own help:
--file-associations — Path to a Properties file that contains list of key, value pairs (absolute path or relative to the current directory). The keys "extension", "mime-type", "icon", and "description" can be used to describe the association. This option can be used multiple times.
Does anyone here know where I might be able to find an example of this that is written correctly or more detailed documentation on exactly how the feature is used? Would be much appreciated if someone could just point me in the right direction.
You need to write each key-value on each line separated by an equal sign without any quote and save as a text file with .properties extension for example
extension=<Your file extension without leading dot e.g. docx>
mime-type=<Your mimetype e.g. application/msword>
icon=<Path to the icon file e.g. word.ico (Windows) or word.icns (macOS)>
description=<Some description e.g. Microsoft Word Open XML Format Document>
I could not find any official documents either. However, this is how I created my properties file which works on the release version of Java 14.
Related
I got a Java project from another developer and I found several files with these two names strewn around the source folder:
vssver.scc
filesystem.attributes
I know the first one is from Visual SourceSafe but what about the second? Are these files from Visual SourceSafe too?
It's difficult to search this as Google simply ignores the dot character in between, even if I put the whole thing in quotes.
Edit: File contents are binary but mostly have references to classes from Java and libraries:
After some digging, it looks to be a (presumably obsolete) Netbeans thing. The only real reference I could find is this Netbeans mailing list post from August 2000, which says it was used to store various IDE metadata about each file.
It is created automatically when you modify some attributes of a file
using the IDE itself. [...] Every file (including directories) stores its
attributes in a filesystem.attributes located alongside it (in the
same containing directory). FileUtil.extractJar specially recognizes
filesystem.attributes in a JAR, so if you jar up your directory then
when it is extracted the jarred attributes will be applied to the
extraction folder.
The post mentions a "future reimplementation" using an XML-based filesystem, which I think has happened by now. This later post mentions using the name .nbattrs to replace the old filesystem.attributes. I'm not a NetBeans user, but this seems to be what happened; for instance, I found an example in this gist.
Is there a way to get the file signature of a file inside a document? I tried checking the Embedded Object Class but it seems that there is no function for getting the file signature. Is there a way to get it just by using lotus script?
If not then I believe I'll need to maybe use a java class agent right? Can you provide a link that is doing this function or maybe can you guide me with some codes for this one. I am familiar with java but when it is being used in lotus notes agents I am not much familiar with the class being used.
Basically what I need to do is check the files in the documents and check if they are a valid file with the valid signature. Just checking the extension name is not enough as it might be renamed but the signature of the file is not valid so I'll need to confirm the file signature in checking. Thanks.
You have to write the file to file system and then you can read the file from there. Use a temp directory and delete every file after usage.
Look here for code to write attachments to file system as a starting point. Property EmbeddedObjects is available for documents too in case you want to analyse all attachments of a document.
You can accomplish the same in Java. Just look for Java classes in Language cross-reference in documentation.
How to find file extension if the file has been renamed? Is there any tool are available for this?
Example: I have a file "1.doc"; I hope everybody know this is a Word document I just renamed as "1.txt". But the file is a Word document originally; how can I get the original file extension?
You cannot get the previous file extension back. All you can do is look at the contents of the file, and try to guess what it is.
Most (many?) file formats begin with a "magic" value that is intended to identify the file format, but this method can never be 100% accurate.
As #AaronDigulla mentionned in a comment, there are libraries out there that help you in the task of "guessing", and the answer(s) to that question contain pointers to some such libraries.
Once you rename the file, the previous name is not preserved.
As far as automatically guessing the format of the file from its contents, take a look at the Unix file utility. The version that's installed on my Ubuntu box lists Microsoft Word among the "magic" signatures that it knows about.
What you want to do is find out what its MIME type is. You can use this tutorial http://www.roseindia.net/java/java-get-example/get-mime-type.shtml
before renaming it save it in a separate string called originalName...because when you change the name of the string, the memory allocated is changed and theres is no go back or undo
Consider using javax.activation.FileDataSource from the JavaBeans Activation Framework. In particular use the getContentType() method.
I want to design a function in Java which will have prototype like this.
public String FindVersion(String FullPath)
{
}
where FullPath can be: C:\tmp\readme.txt
or C:\windows\system32\xcopy.exe
or like C:\windows\system3
FileVersionInfo is a Win32 API thing so you'll need to use the JNI and some C code to get access to it or use an external library. There is a an API I found called Sigar that seems to be able to do this
The details that you are asking are very specific to the file-system of the operating system on which the Java runs. As of until Java 7(java.nio.file.attribute); we don't have any API that gives you this information. The only option is to make use of some Win 32 API through the JNI interface.
Not all files track versioning, the average text file has no concept stored within the file or externally which encodes how many times it has been edited.
Some documents optionally store versioning information within the document, if enabled. For those files, the routine would look something like (in pseudocode)
public String FindVersion(String filepath) {
check to see if file type can be deduced;
check to see if the deduced file type supports versioning;
check to see if the file has versioning information;
go through the revisions of the file and report the latest one;
}
Some documents are versioned, but the versioning information is not stored within the document, it is stored in a system which tracks the versioning information independently of the document. In such a case, you really want to deal with the revision control system which is authoratative over the document. Often such system have utilities to indicate which version of the controlled document was last retreived; other times you need to query the document against all revisions looking for the closest match.
Basically, there's not one way to do it for every situation.
I have written extensive JavaDoc documentation on my application, and added lots of useful info at overview.html and package.html files (including links on the former to illustrations in doc-files/). Maven's Javadoc plugin nicely uses the standard javadoc tool to generate the classic JavaDoc frameset, but now I need to generate a PDF with the whole documentation.
AurigaDoclet generates very pretty PDFs, and I was able to make DocFlex work also. However, both ignore my overview.html and package.html files (tried both inside and outside Maven - the PDF will be a once-only thing, since I'd rather have the HTMLs on the long run).
Does anyone know how to make AurigaDoclet recoginze my non-Java files? Or, alternatively, another to generate a decent-looking PDF from either the source code or the JavaDoc-generated HTML?
Nailed it. After trying all the possible tools to generate straight from the source, I returned to HTMLDOC. It is not JavaDoc-aware, but it is so well built that a few tweaks are enough to make it generate a pretty usable PDF.
Here goes a step-by-step description of how I did it:
Download the software on the releases page;
Generate your traditional HTML docs in your preferred way (Ant, Maven, command-line javadoc - your choice);
The GUI is nice, but adding all files manually can be cumbersome, so just create a .book file with Document Type set to "Web Page", add one of the HTML files from your generated javadoc's root folder (e.g., overview-summary.html, anyone will do, it's just for reference on step 5). On the Output tab select the PDF format and set a name for it, and add other options to your heart's content (logos, colors, lots of cool stuff here). Save this project (say, myjavadocpdf.book) and close the GUI
Generate a list of all HTML files in your javadoc. I did it with Cygwin's find command (my DOS/cmd shell days are long over), but you can do anything you want, as long as you get a file list. In my case a find . | grep html$ | sort -r > files.txt did the trick;
For Windows users, dir /s/b *.html > files.txt should do the same (but keep in mind you may have to replace \s with /s if they appear like so on the next step).
Open the .book file generated on step 3 in your favorite pure text editor (as a programmer you should have strong opinions on that, so will keep my opinions to myself - NOT ;-) ) and append the list generated on step 4 to this .book file (it keeps the list of files at the end, making life really easy). Don't forget to fix the relative paths, if needed with a global search/replace (that's why you needed at least one file added on step 3 - to see which file path pattern htmldoc expects);
Now you should sort the files in a convenient order. I put my overview first, then package descriptions and each class, then the full index, and everything else at the end. Remember that any file you delete will become an external (hence broken) link, so choose wisely;
Save your .book file and re-open it on HTMLDOC. Voila: all files added and sorted. Click on generate. That's it!
You may want to fiddle with images (hint: use HTML width/height, not style/css). In the end, the resulting file is surprisingly good: nice looking and fully navigable for internal and external links. Impressive when you consider that the tool is not Java(Doc) aware at all...
EDIT: software is now free from original author; updated links, thank you #mohammed
According to the Sun JavaDoc FAQ, there's a couple of options -- mostly free, with one or two commercial offerings as well. Check it out at http://java.sun.com/j2se/javadoc/faq/index.html#print.
AurigaDoclet fails to process package.html.
For a fix see my comment at https://sourceforge.net/projects/aurigadoclet/forums/forum/339169/topic/1572199/index/page/1
If this question was bumped anyways, I can use this to link my ltxdoclet project.
This creates from the source (by being a JavaDoc plugin) documentation in LaTeX format, which you then can pass through PdfLaTeX to produce a PDF.
Optionally it also can include pretty-printed source code.