[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [orbit-dev] Orbit Build process ready for review and contributions
|
David M Williams wrote:
I should have been more explict, the ones that are there right now,
are just based on me grabbing some stuff that was in CVS and guessing
what and how folks wanted built. This was mostly for me to test the
scipts and procedure I had, and hopefully to serve as an example of
how committers could get started. So, now, committers should check,
re-release if needed, and "do it right". I may just not have seen
lucene 1.9.1 (or, did something else wrong).
That is actually another indicator that chosen branching/project
naming is not obvious and counter intuitive...
> So, is it a final decision to not provide an update site for those
> bundles?
It's my understanding it's "final for now". That we'd re-consider
if/when more people and use-cases seemed to require it. Also, I
believe, someone was going to look into the implications of doing it
for (only) Europa requirements. You might open an enhancement
request, and encourage people to document their desire/use cases
there. Guess you haven't convinced us yet, Eugene :)
Interesting. My take on this is that it is Orbit has to convince me to
use its artifacts. Right now I am not convinced at all. :-)
My main concern
is it requires one feature per bundle, and "features" seem an archaic
construct and their use should be minimized. Also, if you did all the
work for it, I imagine people would not object too strongly :)
That is a weird reason for not doing things. This is mechanism
provided by the Platform. So, it is a standard and must me encouraged to
be used. You are doing exactly the opposite. Trying to avoid to use
Platform feature is not good. :-)
Besides, we still have almost two months before API freeze for Europa
and that may be enough time to create new update site format...
> I still believe it was very bad idea to explode all the .class
> files into cvs. Orbit should use original jars as much as possible.
As I recall, this so there'd be "as little change as possible" from
the third party distributions? Right? Other reasons? Is there another
way to get a jarred bundle without exploding the original jars?
You can create anything during the build. Repack, obfuscate, or even
assemble multiple jars into one. Just keep original jars in the CVS.
My primary point was to not commit classes into CVS. It is wrong use
of version control system, because those classes never supposed to
change, and since CVS commit is not an atomic operation you can say if
all classes committed right or not. So, committing a jar is much safer.
This would also allow to go to the source and verify what version is
included into the bundle (in case if there will be any doubts, and
sooner or later it will happens). It is much harder to verify all classes.
As far as I know, to have "jarred bundles" was the primary motivation
... but, I'm sure others may know more than I.
As far as I remember this is another Platform or PDE limitation? Why
should such things drive bad decisions? If it is a critical limitation
or bug, it should be fixed and not avoided.
And, keep in mind, if
we ever wanted an update site, with "packed" content, we'd be likely
be tweaking the orignals anyway :) (as part of jar conditioning).
Right. That is how pack200 works. But again, bad excuse. :-)
regards,
Eugene
