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

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

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