Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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.


Back to the top