Skip to main content

[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. :-)


Back to the top