> > 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
> *new* bundles. Teams can use them as needed. In many cases
> original bundlings were "wrong" or inconvenient. For
> 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
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
> to define the naming and versioning conventions to be used. The
> commons logging bundle follows those conventions. Of course,
> 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
> 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
For example, what if I wanted to ship
a "product" or other open
source project that used javax.servlet
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
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>
> 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
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
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
> 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
> org.apache.cactus one is "iffy" .. I'm not sure we can deliver
> 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
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.
orbit-dev mailing list