4 Feb
2007
4 Feb
'07
7:07 p.m.
Hi Jeremi,
On 2/4/07, jeremi joslin <jeremi(a)xwiki.com> wrote:
Why would it be ... abnormal ? I don't understand.
Vincent already provided the answer above. Because you need metadata
and zip does not directly have support for it.
Renaming it to zip might be an option. I think not the best one for
the long term, but surely it would not be causing any confusion now.
So why changing to the jar format? ;-)
So I see you don't really like JAR :) Nevertheless, JAR is a widely
used, established format, with a stable specification
(http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html) -- as opposed
to your Xwiki ARchive, which is neither established, nor documented,
and to make things worse the extension XAR is already used for
different kind of archives.
Standalone tools for extracting and creating JAR's are part of the
standard JDK -- there are no standalone tools for Xwiki ARchives,
unless you build some. If you just use some zip archiver then you will
have first to realise that the zip compression algorithm is used (XAR
files are binary, and have a strange extension which if you Google for
leeds to eXtensible ARchiver -- so quite confusing for your users).
Then still you need to know how to create the package.xml if you want
to create a XAR file. Sure, it is possible to create XARs using the
Export facility in XWiki, but that's the only easy way and is limited
to pages in your wiki, so no XWiki Applications ... just collection of
pages.
Also the API for accessing and modifying metadata in JAR files is part
of the Java standard library, is stable and well understood.
To sum up, JAR is an established format which is very well suited for
your problem. Do you really want to reinvent the wheel?
Hi,
On 2/3/07, Vincent Massol <vincent(a)massol.net> wrote:
According to the JAR File Specification "A JAR file is essentially a
zip file that contains an optional META-INF directory". So can you
please explain what other compression format there is for JARs ? I
never heard of any others.
Hi Jeremi,
I'm +1 on my side but as you voted -1 we'll need to convince you to
change your vote ;-) Let me give it a try below...
On Feb 3, 2007, at 9:41 AM, jeremi joslin wrote:
yes, but a
JAR in java term is a zip. There is also JAR compression
method. so if you go this way, it's the same problem.
Hi,
-1
I'm not for changing to jar. it's not a Java archive, it's an XWiki
Archive. I don't see the point to change. People will think it's
javacode.
* JAR is an archive format. It can be used for lots of different
things. There are even software that use JARs for their installation. * I really
believe that in the future our applications will not be
made only of XML files but will also contain other libraries (jar
files) and java classes. For example imagine the IRC bot application.
There are some xwiki pages but we also need the picoirc jar. We'll
need to bundle all that together.
And what's wrong with putting a jar inside a
xar? even if we use a
jar, it will only be readable by XWiki.
* XWiki is a Java application so all users are
familiar with the JAR
format.
But it's not a normal jar. That will lead to misunderstanding.
Of course we can use the XAR format for that. XAR looks nice because
there's XWiki inside but there's a cost of inventing a new archive
format:
* It needs to be described
* There needs to be tools for it (or people need to rename it to
zip...). BTW if it's a zip we might as well name it zip... The
problem with Zip is that it does not support meta data information
such as the jar format does. And we need these... And there are APIs
to get these metadata so we don't have to reimplement all the code
(as we've done for the package.xml file).
* It makes it difficult for the build (this is the same argument as
above with tools) as all the existing plugins do not understand the
XAR format so we have to reinvent all the tools... This is why I had
to implement the xar handler and the xar plugin in our repository. It
would make it much easier if it were an existing format such as JAR.
Why not renaming the xar to the zip. it's just that people don't need
to know what is inside, but if they want they can.
I dont see the point, we are using an API for reading
and writing the
metadata: XML. We will also need to reimplement the writing of
metadata in the manifest file.
So it's already done isn't it?
It is part of the standard library:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/jar/Manifest.html
I think it would be much better to use an existing format (which we
do except we're using Zip instead of JAR), already documented rather
than invent a new one. There's no point in us hiding the underlying
format we use by changing the extension. We might as well use that
format's extension...
Ok, rename it to zip if you prefer, that's only a
problem the
extension to be xar for openning it under windows. But i prefer
people to think it's a file where they have all there pages, and don't
need to read what is inside. But if they want, they can.
if you look at this page :
http://filext.com/detaillist.php?extdetail=XAR there is some other
software who are using this extension. So why XWiki can't use it?
Some people have thrown nuclear bombs in the past. Is that a good
reason for others to do it? Probably not.
It's not because people are doing bad things that we have to follow
them ;-)
And even the xar format is not so used. I ask to my
friends, no one
know it. Did you know it before?
You are right, eXtensible ARchiver is not widely used at this time.
But it will be quite probable used by the MacOSX package system in the
future (http://www.nabble.com/xar-in-Mac-OS-X-t2081148.html). So
almost all software written for the Mac might come one day in this
format.
I thing changing to the jar format
will bring more misunderstanding.
Can you be more specific here. Where exactly would confusion arise ?
Regards,
Catalin