Re: [orbit-dev] Orbit's first weekly build has been declared!

[Christian Damus <cdamus@xxxxxxxxxx>]

Hi, Jeff,

See some comments in-line, below.

Cheers,

Christian

---

Christian W. Damus
Component Lead, Eclipse OCL
and EMFT-QTV
IBM
Rational Software


orbit-dev-bounces@xxxxxxxxxxx wrote on 02/07/2007
09:58:00 PM:

> 
> I took a look and while I don't have a problem with declaring this
> stable, there are some issues with some of the bundles.  I was
going
> to raise individual bugs but thought ti would be good to mention the
> issue here as they are in general, somewhat general :-) 
> 
> - Much of Batik specs the Bundle-RequiredExecutionEnvironment header
> as J2SE-1.3.  This is great.  I wonder if they can also
spec CDC 
> Foundation 1.0?  I see that there is some AWT/Swing stuff so
clearly
> that would not. 

[cwd] I would be happy to, if somebody
can test on CDC-Foundation 1.0.  I don't know where to begin with
that;  not only do I not know Batik well enough to test it, but I
have no experience with micro environments.  Perhaps for the next
milestone? 

> - As point of interest, I thought we were doing
batik as one large 
> bundle.  I'm fine with the way it is but wanted to clarify 

[cwd] I was convinced of the multi-bundling,
following discussion on our December call (I think that was the one that
David hosted in your absence).  I had another look through the Batik
documentation and understood a little better the separability of some of
these parts.

> - Some of the bundles spec version ranges on
the import-package 
> statements.  For example [1.6.0, 1.7.0).  I wonder what
that basis 
> is for choosing the upper range?  Does the producer of the prereq
> lib make any declarations about the way they will increment their
> version numbers?  Would it me more appropriate to spec actual
> precise version numbers?  (That is an honest question.  I
don't know
> what the "right" answer is) 

[cwd] I did it this way for the Batik
bundles because I don't really know what assumptions we can make about
version numbers from outside of Eclipse.  I thought it would be useful
to allow for service upgrades (I'm sure that Batik has bugs that will be
fixed), and figured the risk of changes that violate our versioning guidelines
would be small.  I upper-bounded on the next minor increment because
I don't know that we can be as confident at that level.  Basically,
it was a hedge.

> - not all the bundles have .qualifier in their version numbers 

[cwd] Yep, fixed that already.  Hope
it's not too late to spin a new build?

> - org.apache.commons.el includes source, build.*,
.classpath, ... 
> looks like the bin.includes line in build.properites has "."
which 
> of course would suck in everything in the project 
> - similarly for lucene.analysis 
> 
> - some budles have Eclipse-LazyStart: false.  That is ok but
not 
> really needed. 
> 
> - org.w3c.dom.smil is a bit whacky.  There is just one class
in the 
> entire bundle!  Is that correct?  Also, the manifest imports
and 
> exports the one package that is in that bundle.  I am very pleased
> that the manifest has "uses" clauses!  Similarly  the
SVG bundle 
> imports and exports and uses. 

[cwd] Yep.  W3C's SMIL DOM consists
of one class.  The importing of the exported package was a trick suggested
on the mailing list to hedge against iffy versioning of the source, which
does not track version numbers internally (W3C doesn't use CVS?).


> - org.apache.commons.net is a "flat" (directory based) bundle
with 
> nested JARs.  Is there a technical reason fo rthis?  It
also seems 
> to include an image file (eclipse.png).   
> 
> - commons.net is marked as a singleton.  This would be an excellent
> discussion topic to define the situations in which singleton-ness
is
> appropriate.  What drove us to make commons.net a singleton?
 I see 
> that it has an extension but that extension is anonymous (no id) so
> it should be ok to have multiple (depending on what the extension
> point is doing).  Speaking of that, why is commons.net contributing
> to the Eclipse Ant support?  In general the bundles we create
should
> be just straight bundlings of the third party libs with no 
> functional value add.  Other bundles can contribute to extensions
> etc.  Another fine discussion point. 
> 
> - junit is still a dir bundle.  I thought we had found a way
to make
> it a JAR'd bundle? 
> 
> Jeff 
> 
> 
>   
> 

> 
> David M Williams <david_williams@xxxxxxxxxx> 
> Sent by: orbit-dev-bounces@xxxxxxxxxxx 
> 02/07/2007 04:49 PM 
> 
> Please respond to
> Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>
> 
> To
> 
> orbit-dev@xxxxxxxxxxx 
> 
> cc
> 
> Subject
> 
> [orbit-dev] Orbit's first weekly build has been declared!
> 
> 
> 
> 
> 
> And, just in time too, since we need to declare a Stable build on
> Thursday! (if at all possible). 
> 
> The significance of the Stable build is that we 
>        1) are saying it's ready for consumers
to consume for their 
> own Milestones (such as those consumers participating in Europa).
>        2) We'll leave it there until the 'Simultaneous
Release' of 
> Europa (by which point we would have moved the bundles to some "Final"
area. 
> 
> In strict violation of progressive development, I am hoping to get
> the Xerces 2.8.0 plugins in a build, in time, but last minute, for
> this first Stable build, since 
> many people in Europa pre-req it ... and they tell me they are waiting!
> 
> So, committers: 
> 
>        1) Please check our lowly weekly build,
and let us know if 
> there's anything in there that should _not_ be consumed. See 
>        http://download.eclipse.org/tools/orbit/downloads/
> 
>        2) If any committer has any objections
with declaring a 
> stable build on Thursday, please speak up ... we really do want to
hear! 
>        The stable build would be based on the
I200702072036 build 
> (but with probably Xerces added, so will have a different date/time
stamp). 
>        I'm not sure which is easier yet ... to
rename the bit's 
> produced, or flip a switch to produce a build prefixed with "S"
... 
> so, again, if strong feelings, 
>        please say so. 
> 
> Much thanks. 
> _______________________________________________
> orbit-dev mailing list
> orbit-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/orbit-dev
> _______________________________________________
> orbit-dev mailing list
> orbit-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/orbit-dev