Thanks for the reversal of the -1. But I still need a +1 ?
Shanti
sebb wrote:
On 23/04/2009, Shanti Subramanyam <shanti.subraman...@sun.com> wrote:
sebb wrote:
On 23/04/2009, Shanti Subramanyam - PAE <shanti.subraman...@sun.com>
wrote:
On 04/22/09 10:35, sebb wrote:
On 16/04/2009, Shanti Subramanyam - PAE <shanti.subraman...@sun.com>
wrote:
On 04/15/09 18:15, sebb wrote:
On 16/04/2009, Shanti Subramanyam <shanti.subraman...@sun.com>
wrote:
Thank you very much for your very prompt review.
Answers to your questions below.
Shanti
sebb wrote:
The OlioDriver.jar file contains a smaller OlioDriver.jar
file.
This is very confusing; one of the jars should be renamed.
This is the format of the Faban (http://faban.sunsource.net)
Driver
jar
-
the user never has to do anything with it as the tool will
automatically
unjar and put everything in it's right place.
The binary olio file contains several .patch and .diff files.
These
don't seem correct for a binary file. What is their purpose?
These files are part of the 3rd party plugin
fixture_replacement2.
Since we
tend to include 3rd party code as is (for easier upgrade), I
think
it
might
be better to leave them as they are.
But why are they in the binary rails jar, rather than in just the
source
jar?
There is no difference between the source and binary code for rails
(or
php
for that matter) since these are interpreted languages. The only
difference
between the source and binary packages of Olio is the geocoder and
workload
- these are written in Java so the binary packages have the
OlioDriver.jar
and geocoder.jar and the source packages have the corresponding
source
dirs.
That does not explain why the diffs and patch files are present in the
binary jar, because as far as I can tell they are not intended to be
interpreted by rails.
Are they actually *needed* at run-time?
I really don't know. As I said, there is no concept of 'binary' for
scripting languages - the source is the binary. I will try and
investigate
this matter for the next release if it's not a major problem to leave
them
here for now.
I understand that there is no binary for scripting languages, and
therefore .js and .rb files appear in both source and binary archives.
However, the .diff and .patch files are scripts for a patch program,
which is used to modify source files. Are such patches really applied
at run-time? Seems rather wasteful to me if so.
But I agree that could be fixed later.
The source PHP file contains several jars; I would expect
these to
be
in the binary archive only. It also contains the file
"event.pdf"
which does not seem to belong in the archive (or indeed in
SVN).
These are third-party jars. They are included as a convenience
to
make
it
easier to build and run the source.
What about the event.pdf file?
This is a resource file used by the web application. If you notice
there
are several image files as well - these are all static files used by
the
web
app.
What about the license for the event.pdf file? Is that also AL
licensed?
All the resource files are created as part of the apache project, so
they
are all Apache licensed.
According to its properties, the event.pdf file was created in 1999
and last modified in 2004. AFAIK, that is well before the Apache
project started.
The file event.jpg was created in 2006, which was also before the
project, and is a picture of 5 real people. Hopefully they have given
permission for their photos to be published.
This project was started a long time ago at Sun - all of the code including
these files was then donated to apache.
Neither appears to be present in the binary file, so I'm not sure how
the web application can use them.
They do exist in the binary package - they are part of OlioDriver.jar.
Ah, OK, I see them now.
Note that there are other jpg files in the same directory with much
the same contents:
event_thumb.jpg, person.jpg and person_thumb.jpg.
AFAICT, these files don't belong in SVN or in any of the archives.
These files are required at run-time. The driver uses these resource files
to upload content to the web application - please see the source code under
'workload/.../driver'.
OK.
My vote is -1 based on the above.
I guess I don't really understand what the objection to having these files
are.
The files just seemed very odd, as if they did not relate to the project at all.
I wanted to make sure that they really belonged.
If you're concerned about the photo itself (it was actually just taken
by one of the engineers), I can replace it with a picture of me although you
may actually prefer the current image :-)
So long as the subjects of the picture are happy for their images to
be published, then fine.
But seriously, without these
files, we will have to somehow go out and manufacture image/pdf files at
install time - uploading files is a big part of a web2.0 workload these days
(and for sites like flickr the major workload).
Does anyone else see a serious issue with these files ?
I withdraw my -1 vote.
Shanti
Thanks
Shanti
On 04/15/09 09:23, Shanti Subramanyam - PAE wrote:
The Olio community has voted and approved this first
binary
release of
Olio. We are now asking for a Vote of the Incubator PMC to
publish
this
release.
The release includes both the PHP and Rails versions of
Olio.
The release artificats and RAT reports are available here
:
http://people.apache.org/~shanti/olio_0.1/
The mail thread and Vote results from Olio community :
http://mail-archives.apache.org/mod_mbox/incubator-olio-dev/200904.mbox/ajax/%3c49dd6496.9010...@sun.com%3e
Thanks
Shanti
---------------------------------------------------------------------
To unsubscribe, e-mail:
general-unsubscr...@incubator.apache.org
For additional commands, e-mail:
general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail:
general-unsubscr...@incubator.apache.org
For additional commands, e-mail:
general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail:
general-unsubscr...@incubator.apache.org
For additional commands, e-mail:
general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail:
general-unsubscr...@incubator.apache.org
For additional commands, e-mail:
general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail:
general-unsubscr...@incubator.apache.org
For additional commands, e-mail:
general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail:
general-unsubscr...@incubator.apache.org
For additional commands, e-mail:
general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
