This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
[Build-010203CE] jdk1.3.xxx rh70 ================= What's about the IDE can handle various archives formats: tar at least gzip tgz ...other very common maybe rar arj ... -- thanks Dan
Mark as "wontfix" if you want. It is not reasonable to support a format not supported by the JRE, which just means gzip as far as I know, i.e. treat foo.txt.gz as a FileObject "foo.txt" with automatic decompression. tar is not a good idea, random access to tar archives is not possible (unlike ZIP). Since ZIP is the standard Java way to archive things, and we already support it, I'm not sure this is very useful.
I'm suppose that it is usefull. My idea, first time was about mounting tgz as a javadoc FS. I've got it when I had javadoc for new jdk1.4 in tgz format and I had to untar and ungzip and zip to zip format. and I've found that on my disk is more usefull javastuff in tgz format (sources, documentation,etc). BTW, every 'stupid' tool can handle it. And our ide is not 'stupid':-) Also it was discused on nbdev@...mailinglist and it acceptid as useful:-) ----------------------------- > sure I think it is. GZIP essentially is ZIP format and tar format is > trivial. We just need someone to contribute the code correction: Lahoda rightly pointed out that GZIP is not the same as ZIP. Since I managed to learn touch typing, sometimes I was too fast with the keyboard :-( Anyway GZIP reader and writer are part of JDK. See java.util.zip.GZIPInputStream and java.util.zip.GZIPOutputStream ----------------------------------------------------
Target milestone -> 3.3
Target milestone -> 3.3.1.
Target milestone -> 3.4
I don`t think that mentioned formats should be supported in filesystems package.
I don't know what we are waiting for? ....till the some other competitive IDE will can do it? Then we'll start thinking about to implement it? I thought that we won't be the anothers. Please look at the IDE as a platform tool, a tool which will serve their users. They won't accept such excuse. I'm reopening....
I don`t want to controvert your ideas about support of mentioned formats. I think that standalone module could be the best solution (perhaps new experimental module, perhaps jarpackager). Definitely filesystems package is not the right place for implementation. I strongly believe that filesystems should provide basic infrastructure+SPI for other modules and elementary and general implementation. There is no possible to pollute heavily filesystems and implement filesystem for every hierarchical structure that could be convenient. Won`t be fixed neither in openide neither in core.
Well, as you say it it seems reasonable to move this enhancement to another modele like jarpackager, so doing it now.
not sure if jarpackager is the right module for this enhancement.. as the name of the module suggests: it's JAR-packager, a tool for packaging jars.. I don't believe support for reading tars/zips should be included. moving to uncategorized, since there's no module for this kind of enhancement yet.
Well:-( .. as the name of the module suggests: it's JAR-packager, a tool for packaging jars.. And What is the JAR? kinda 'sendwich'? that you can't find anything common on JARs and ZIPs, etc... "JARs" are Java Archives exactly the same format as ZIP archives are. And in General Jar package knows to make/handle ZIP archives (But it hides this...) And if it just knows about ZIPs it could also know about other archives format;-) Moving back to jarpackager module. If you realy strongly disagree....there's an archiver module or how it's called, but IMHO...don't know if it is alive:-/ Thanks for understanding
BTW: category *uncategorized* is not for our ID...(now get lost info about which version, etc.....) Setting correct version and Milestone 4.0
but there is a module named archivesupport which intention is exactly what you propose in the enhancement. Moving there.
Sorry all, just noticed this issue thread. Archive support had been put on the back burner as few seemed to show much interest - but maybe I'm wrong? I still think there's a place for supporting a generic archive support module - something that could provide a nice standardized interface for working with archives without concerning itself too much about what compression scheme/file format is to be used. A good GUI and simple API would open the way for people to add support for their particular archiving programs either by simple command- line implementations or more involved code based implementations. As most archive implementations can be invoked over the command-line adding a way of doing this for Joe-user would seem to be a good way forward. Anyone want to dive in?
Target milestone was changed from not determined to TBD