[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[orbit-dev] commons.net (was: Orbit's first weekly build has been declared!)
|
Hi all,
I wanted to comment on the issues raised by Jeff regarding
commons.net -- thanks, Jeff, for reviewing -- I'm glad to get an expert
opinion!
Regarding the fixing of any issues, do we see a pressing
need to do so for any "stable build"? Given that we are currently the
only
consumers of commons.net, I'd hope not.
-
org.apache.commons.net is a "flat" (directory based) bundle with nested JARs.
Is there a technical reason fo rthis?
No. The bundle was created before the instructions
(exploding classfiles) were put in place, and I didnt have time yet to fix
it.
It also seems to include an image file (eclipse.png).
Because we have a feature for commons net where the bundle
holds the branding info for the about dialog. Somehow I thought the Apache
License required us doing so. Given the recent discussions around this, I guess
I'll probably remove the separate features for commons.net and oro and have it
included in some other feature only.
-
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
guess I just copied some existing Manifest which happened to be a singleton.
Actually, I agree that I can't see a reason why there shouldn't be muliple
versions.
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?
The
ant ftp, rcp, rsh tasks need commons.net to work. These tasks are being shipped
as part of our ant bundle already (with these tasks non functional without
commons net). So I thought it were a good idea to advertise commons net when it
is there.
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.
Hm. In this particular case, ant wants the plain, original
apache lib (and just wants to know where it lives). So I'd think that having the
extension point is ok.
I'm open and
glad about any more discussions about this!
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.
- 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?
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