tar, zip, unzip, bzip2, bunzip2

Some other existing implementation of the core features (aka compression/decompression algorithms) :

• jzlib, under BSD style license
• jazzlib, under GPL license
• java tar, under public domain. Unfortunately, it depends on Java Activation Foundation (JAF), which is something we should avoid.
• And of course : java.util.zip but I think it's only providing a subset of the zip format/features.

These have been implemented in org.jnode.fs.command.archive

Can I request that you create the User Command pages for these commands before (re-)closing this issue. Please use the source markup for one of existing command pages as a template, and try to conform to the same style and structure.

I have an objection to this.

It might be one thing to create these doc pages for commands that are specific to jnode. But it is quite another to waste time replicating documentation that is plastered all over the web. I started to do this, but quickly realized that it was going to take a good deal of time to make the pages for some of the new commands that have been added, and to what end? I certainly am not going to rewrite the documentation for 'tar'. And that also includes commands that are compatible with their posix/linux conterparts. The most i would be willing to agree to is to make the page with a synopsis and a description that gave a link to proper documentation. If there are specific differences between jnode's version and the posix/gnu version, then list those details. Otherwise, google it.

Otherwise, google it.

I don't think a JNode user should be expected to Google for documentation of a JNode command. IMO, the existence of external documentation is not a valid excuse for neglecting to create JNode command pages. If there is better documentation out there, consider linking to it from the JNode command page.

I know developers hate writing documentation, but come on ... lets be professional about this!

Its one thing if its a jnode command. Its a total other if the command is specified by posix/gnu as there are tons of documentation pages. And those docs have people that maintain them. They have many hours of time spent explaining the details of the application. I think a link to proper documentation with maintainers is better than something half put together and might get updated if someone pushes enough.

I have implemented pages for these commands, stating that they are compatible, or aim to be, with their posix/gnu/whatever interfaces, and provided a link to their docs.

I know developers are the worst for docs. I never do it enough. But until jnode has a doc team, i think you'll be fighting an up hill battle so far as jnode documentation goes. Even more so if you expect that documentation be written in html markup. It's simply the wrong tool for the job.

Doc pages are up for tar, zip, unzip, bzip2, and gzip

For the record, I'm not aiming this at you (cluster) personally, but at the team in general. What you (cluster) have done in the last couple of days is definitely worth while, though (IMO) just start. [ You have my permission to go and do something more interesting now ]

Even more so if you expect that documentation be written in html markup. It's simply the wrong tool for the job.

Remember a couple of weeks ago I suggested that you take a look at this issue? It is all part of the same problem. The syntax, the help descriptions and the full user documentation (viewable in HTML and other formats) should all be facets of the same stuff. Do you want to bite?

I agree HTML markup is the wrong answer, and the restrictions imposed by this content management system make it even worse. But it is better to make do with what we've got rather than using the tools as an excuse.

... stating that they are compatible, or aim to be ...

Well I don't mean to get on your case, but telling the user what we are aiming to implement rather than what we have actually implemented is ... well ... not that helpful.

But until jnode has a doc team, i think you'll be fighting an up hill battle so far as jnode documentation goes.

The "professional" answer is that if there is no technical documentation team ( and that is the norm in most industrial workplaces ) the developers have to write the documentation themselves. As far as I am concerned, writing documentation is part of the job spec for a professional software engineer.

Of course, JNode's documentation would be more readable if some tech writers got involved with the project. But I cannot see it happening. In the mean time, if we want people to use JNode ... and join the team ... we HAVE to document it.

Automatically closed -- issue fixed for two weeks with no activity.