Jeff McAffer wrote:
"Bennett, Timothy (JIS - Applications)" <[EMAIL PROTECTED]>
wrote on 08/26/2005 12:04:15 PM:
-----Original Message-----
Slow and deliberate is good. I'm not avocating that we have all these
questions answered by the weekend, or even at a pace that the community
is uncomfortable with. I didn't mean to come across as trying to force
a breakneck pace. I think I've just got my head into Maven2 a lot
lately, and while I'm in here, I'm finding I've got a lot of questions.
I'm getting up to speed on Maven2 just like anyone else who is looking
to move from Ant or Maven1.
While I'm elbows deep in Maven2, it's a natural time for me to
experiment with building Felix using Maven2. What I may have failed to
recognize is that it's not a natural time for the rest of the community.
And that's cool.
For me it is the right time to start look at Maven. What I think is
important to recognize is that people in our community come from some
different backgrounds and have different priorities. Some people have a
strong (or rather extremely strong ;) ) OSGi background and have OSGi
development as main interest and others, like me, are here because we
are part of projects that have grown so huge that we really need a
plugin mechanism to control complexity. And have found, maybe based on
inspiration from Eclipse, that OSGi is the right tool.
Now, if we take Cocoon as an example, we have around 50 blocks (plugins)
that in turn depends on more than 100 external libraries. Both the
blocks and most of the libraries needs to be packaged as bundles.
Forrest and Lenya that are based on Cocoon have own plugin concepts and
maybe 20-30 plugins that they probably are going to port to bundle based
Cocoon blocks when we provide a stable implementation. We are also
expecting our users to build applications in terms of bundles and
external communities to provide blocks. Scalability is obviously a main
issue. I would assume that people from other communities face similar
situations.
Now what do we need from Felix? We currently use Knopflerfish, but we
are not allowed to relase anything based on the R3 licence so we must
switch to a R4 based framework to get an ASF compatible license.
Furthermore we need the more fine grained version handling and the
ability to list directory content in bundles from R4.
But what is maybe more important for us and what current OSGi
implementations (except maybe for Eclipse) doesn't provide is a
streamlined infrastructure for building, store in a repository, download
and deploy large numbers of bundles.
We could probably develop something for solving this within the Cocoon
community, but a number of other projects probably have about the same
problems. And if we find a way to build with Maven and integrate Maven
and OBR and maybe even Eclipse repository for storing bundles and the
stuff work seamlessly together with Eclipse, the end result will be so
much more usable.
So while the Mavenization and some the structure discussions certainly
are over kill for building current Felix, they are IMO essential for
some of us that are OSGi "users".
While you are on a M2 kick, it would be interested to know what it would
mean to build Eclipse with M2. From what I have seen of the the M2 OSGi
plugin, it looks like much of what would normally go in the manifest.mf of
a bundle is to be put in a maven POM file and then the build generates the
manifest?
I also prefer to be at least able to write an manifest.mf, then the POM
could add some (or all) of the fields if I want automatize some aspects.
So what would a M2 POM for say the org.eclipse.osgi and
org.eclipse.runtime bundles look like? How are additional (non-standard)
headers handled? How are the dependencies managed and compile-time
classpaths computed? For example, the org.eclipse.pde.ui bundle directly
or indirectly requires about 40 bundles on its compile-time classpath.
What is the M2 structure for this? How are platform/JRE dependencies
handled?
I guess what I am proposing is that you use the Eclipse projects/bundles
as a test case for what will come in Felix. As there are more and more
people interested in using and building on top of Felix, the build
infrastructure you put in place has to scale (both in terms of build
performance and usability). Presumably there will be some people who want
to use the Eclipse tooling for developing bundles (for Felix or
otherwise). Their output should be buildable using your structure. If
there are things that can be done in the Eclipse tooling to make that
easier, we'd be happy to look at that.
It would be very nice if we can find a POM format so that it is possible
to go back and forth between Maven and Eclipse based bundle building.
While I would assume that many people will use Eclipse for develping and
building bundles, we cannot require that people use a certain IDE to
develop Felix.
Summary: The Eclipse project structure is simple, mostly regular and
known. It may be a fine subject for your M2 OSGi experimentation.
I think a simple and regular structure is a must for scalability. And
that scalablity will be the main focus for some of us OSGi "users", at
least in the beginning.
/Daniel
