Re: [orbit-dev] Ready for WTP contributions?

[David M Williams <david_williams@xxxxxxxxxx>]

> > Otherwise I suggest we change
the name that's in there to match what
> > was released in Callisto. 
> 
> Point taken.  The way I was looking at these things is that they
are
> *new* bundles.  Teams can use them as needed.  In many cases
the 
> original bundlings were "wrong" or inconvenient.  For
example, we 
> shipped org.eclipse.equinox.servlet.api.  That is now javax.servlet
> and javax.servlet.jsp.  We did this to better accomodate the
> usecases and conventions put forward in Orbit.  It is not a breaking
> change in that people can still get and use the old bundle with no
> loss of function. 

Yes, for the logging example, though,
I'm not sure BOTH bundles (old and 
new) could co-exist and still work right
(e.g. if some system-wide Singleton is supposed 
to exist). And, we _might_ be able to
get previous users to switch, but, I'd 
rather be prepared with a binary compatible
story ... I think one transition 
strategy would be to also provide a
new 
bundle with old name, and it simply
import and re-export packages from a 
newly named bundle?  

> We have an opportunity here to
establish and adopt best practices.  
> We should take it.  To that end, a stake has been put in the
ground 
> to define the naming and versioning conventions to be used.  The
new
> commons logging bundle follows those conventions.  Of course,
we can
> ammend/change the conventions as it is early days for Orbit. 

Yes, and being ultra sensative to compatibility
with previous versions is one "best practice" 
we should be exemplary in ... and an
example of how to "transition names" would be one
such case. 

> This line of discussion raises
an interesting question.  Does the 
> originating project have any particular standing different then the
> rest of the consuming projects when it comes to bundling in Orbit.
 
> My personal view is no, we are all just consumers and are all 
> working together to create a coherent and consistent solution to the
> third party library problem.  An approved library can be committed
> to Orbit by any Orbit committer. 

Yes, any could commit, as long as others
have veto rights as is 
required in Eclipse Foundation projects
:) 

And, allowing any to commit also requires
a very traceable history of what has 
been officially approved, which is why
I think we need a 
log that points back to the original
log showing approval. 
Or, at least, an easy to query bugzilla
entry. 

For example, what if I wanted to ship
a "product" or other open 
source project that used javax.servlet
and javax.servlet.jsp
other than word of mouth, how could
I verify that it's been approved? 
Also, I'm partially asking this question
since this project seems a 
little different from others in that
others are not considered "official" 
until they are "released".
Is there a similar "release date" for Orbit? 
[Obviously, we could force there to
be one, by saying so, but seems a bit odd, since
the underlying project/products have
already been released]. Or, are 
we in the odd postiion of saying these
bundles are only released when 
an _Eclipse_ project that uses them
is released? 

In summary, my main concerns in these
long note are

1. How to keeping binary compatibility
with what has come before? 
2. How to we provide documented traceabiltiy?



Thanks for any ideas ... or, talk on
the phone later in the week.

Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>
Sent by: orbit-dev-bounces@xxxxxxxxxxx

10/08/2006 05:25 PM

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

To	Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>
cc
Subject	Re: [orbit-dev] Ready for WTP contributions?

David Williams wrote on 10/08/2006 07:21:24 AM:

> Here is my initial list of what I was expecting to contribute from
> WTP ... but I see commons_logging is in there already!? 
> With a slightly different name! I'm guessing we used the underscore
> since its often referred to as "commons-logging". 
> 
> So, now we are faced with our first dilemma ... request an API 
> breaking change for those who used it in Callisto? 
> (since bundle names are API) by being "pure" and change
the name to 
> match the packages? Is anyone using 
> the one named commons.logging in a release? If the latter, I guess
> we'll need to provide two, deprecating one. 
> Otherwise I suggest we change the name that's in there to match what
> was released in Callisto. 

Point taken.  The way I was looking at these things is that they are
*new* bundles.  Teams can use them as needed.  In many cases
the original bundlings were "wrong" or inconvenient.  For
example, we shipped org.eclipse.equinox.servlet.api.  That is now
javax.servlet and javax.servlet.jsp.  We did this to better accomodate
the usecases and conventions put forward in Orbit.  It is not a breaking
change in that people can still get and use the old bundle with no loss
of function. 

Note also that over time some of the library producers will decide to ship
bundles.  When they do that, they may well choose a different name
than we have.  There is nothing we can do about that other than make
our dependencies less brittle.  In particular, people should consider
using Import-Package rather than Require-Bundle when depending on third
party code. 

We have an opportunity here to establish and adopt best practices.  We
should take it.  To that end, a stake has been put in the ground to
define the naming and versioning conventions to be used.  The new
commons logging bundle follows those conventions.  Of course, we can
ammend/change the conventions as it is early days for Orbit.

> Is the commons.logging that's in there official? [That's partially
> why I was interested in a trace-back log ... wondering 
> who else got this approved, who else might be using it in a release].

Everything that goes into Orbit should be "official".  All
Orbit committers should be painfully aware that anything they put in Orbit
must have been approved by the EMO. The one that is there now was created
by Simon Kaegi to accomodate some of the server side work he is doing.
 He went through a mess of approvals so it is likely that approval
was given for his use.  Note that it looks like the 1_0_4 branch is
empty right now.  Perhaps Simon did not complete his commit?

This line of discussion raises an interesting question.  Does the
originating project have any particular standing different then the rest
of the consuming projects when it comes to bundling in Orbit.  My
personal view is no, we are all just consumers and are all working together
to create a coherent and consistent solution to the third party library
problem.  An approved library can be committed to Orbit by any Orbit
committer. 

> org.apache.axis  (1.3.0) 
> org.apache.commons_logging (1.0.4) 
> org.apache.jakarta_log4j (1.2.8) 
> org.apache.wsil4j (1.0.0) 
> org.apache.xerces (2.8.0) 
> org.uddi4j (2.0.5) 
> org.wsdl4j (1.4.0) 
> org.apache.cactus (1.7.0) 
> 
> We have a few other (back level) versions for a few of the above,
> but that list gives the idea. 

An interesting question.  Should we seek to put all versions of all
libs that have ever existed in Eclipse into Orbit or only the current and
future ones? 

> org.apache.cactus one is "iffy" .. I'm not sure we can deliver
as a 
> pure bundle per se ... the way we use it is that the 
> jars it contains have to be copied to a server so they are available
> to the server. 

Is that inherent in Cactus or in your use of Cactus?  Libs can be
turned into bundles regardless of whether or not they are run on an OSGi
framework in the end.  Doing this allows provisioning systems to understand
their content and distribute them accordingly.

> org.apache.xerces is special, we may want to break that up into an
> "API" bundle and an "IMPL" bundle. 
> [hope that's not counted as derivative work :) ] The org.apache.
> xerces would be the impl one, for 
> backwards compatibility and it would "pre-req" the org.apache.xerces.api

Yes for the two separate bundles.  The naming needs to be addressed.
 For example, is the API Xerces API or XML API?  I'm assuming
that there would be other parser implementations that use the same API?
 We should ensure that the naming conventions cover this case.

> org.apache.axis may be problematic ... it currently contains a 
> number of "pre-req" jars too. I'll have 
> to do some homework on that one. 

Yes, this is similar to Tomcat.  In general we should try to separate
out these nested JARs because it is almost always the case that they are
used by someone else as well. 

> I assume the convention is the code ALWAYS goes in branches, per 
> version number? 
> In WTP, we always had most recent in HEAD also. [not sure that they
> need to be in HEAD, just asking]. 

That has been the convention to date (all 3 weeks of it ;-)  The logic
used was 
a) consistency 
b) elimination of confusion.  If you check out HEAD it is unclear
what you are getting etc.  In fact, the only people who would be checking
out these projects (HEAD or otherwise) should be the peopel working on
Orbit itself.  In that case they likely need to be very aware of what
branch they are working on. 

> I will open bugzillas as I start the work, where I will document 
> what I do. But thought I'd send this 
> note to dev list to get any general comments on the issues I raise.

Great.  As mentioned above, this is early days and there will be a
number of issues to work out. 

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