|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
Back to the top