Re: [orbit-dev] Orbit Build process ready for review and contributions

[David M Williams <david_williams@xxxxxxxxxx>]

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

But, thanks for checking and reporting.
I will be double checking to be sure that empy one is not a problem with
my scripts. 

>   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 :) 
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 :) 
There actually are update jars produced by the current
process, but are not really exposed since, 
so far, the only update feature is the relatively
meaningless build features. But if you ftp/ssh to the 
download sites, you'd see them under /updateSite for
each build (they are not put on any true update site). 

>  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? 
As far as I know, to have "jarred bundles"
was the primary motivation ... but, I'm sure others 
may know more than I. 
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).

Eugene Kuleshov <eu@xxxxxxxx>
Sent by: orbit-dev-bounces@xxxxxxxxxxx

01/16/2007 03:57 PM

Please respond to
Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>

To	Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>
cc
Subject	Re: [orbit-dev] Orbit Build process ready for review and contributions

  That is weird:

org.apache.lucene_1.4.3 (this one actually have no classes)
org.apache.lucene.analysis_1.9.1

  I expected to see org.apache.lucene_1.9.1 too...
  Does anyone requested lucene 2.0 and/or Jakarta httpclient?
 
  So, is it a final decision to not provide an update site for those
bundles?

  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.

  regards,
  Eugene


David M Williams wrote:
> And that's two type of contributions: 1) new bundles, and 2) 
> improvements (to scripts, download pages, etc).
>
> I've written up information about the builds at
>
> http://wiki.eclipse.org/index.php/Orbit_Builds
>
> Please directly edit  that wiki page if you see places it can
be 
> improved. No need to get my permission!
>
> The builds themselves can be seen at
>
> http://download.eclipse.org/tools/orbit/committers/
>
> I've only just glanced at these results, so I am not at all sure if
> the bundles are as intended.
> Notice that this is the "committers" area, intended to be
for 
> committers working area builds. (Sort of
> like I-builds). Once it's felt bundles are "done" and ready
for 
> consumer's production builds, we can
> move these builds to the "downloads" area. (Jumping straight
from 
> Integration, to Released,
> I'm proposing).
>
> Bundle "owners" should soon check if the bundle is being
jarred or not 
> as desired.
> I mostly guessed at the feature.xml setting that controls this.
>
> I suggest specific bugs or feature enhancement requests be entered
> into Orbit's bugzilla system,
> but general discussion on this list is great.
>
> I personally don't plan any major enhancements to this current system
> (due to lack of time),
> but any one is welcome to contribute improvements!  In particular,
we 
> should try to get the
> Phoenix look and feel, if anyone knows how to do that.
>
> Questions, discussions are most welcome.

_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev