Re: [orbit-dev] commons.net (was: Orbit's first weekly build has been de

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

Certainly none of the issues I pointed
out would stop us declaring a Stable build.  If hey can be addressed
as appropriate over the next milestone with a goal to having all the bundles
in "final shape" by M6, that would be great.

The points about Ant are interesting.
 I understand now why it is the way it is.  Still not sure how
I feel about it.  Other bundles should be able to contirbute the JARs
from commons.net but this feels like overkill to require that.  I
suppose that having the plugin.xml there does not hurt.  Anyone else
got an opinion/thought on this?

Jeff




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!
 
Cheers,
--
Martin Oberhuber
Wind River Systems, Inc.
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm

---

From: orbit-dev-bounces@xxxxxxxxxxx
[mailto:orbit-dev-bounces@xxxxxxxxxxx] On Behalf Of Jeff McAffer
Sent: Thursday, February 08, 2007 3:58 AM
To: Orbit Developer discussion
Subject: Re: [orbit-dev] Orbit's first weekly build has been declared!


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
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev