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
- 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.
- 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
- 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)
- not all the bundles have .qualifier
in their version numbers
- 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.
- 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?
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>
[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
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!
1) Please check our lowly weekly build, and
let us know if there's anything in there that should _not_ be consumed.
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
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