Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
After the recent refactoring of Cocoon where part of cocoon-core is
moved to the new cocoon-bootstrap, we have two packages: o.a.c.servlet
and o.a.c.util, that are split into two blocks. This means that we
cannot work on Cocoon3 anymore.
Sorry to say this, but this statement is simply crap. I'm really annoyed
by those statements. Why can't you work on Cocoon3 anymore? I think you
are a little bit exaggerating here, aren't you? Starting an email with
such a paragraph is really not helping in starting a healthy discussion.
Is anybody else saying here that just because someone checked in
something which breaks building cocoon means "that we cannot work on
cocoon anymore?" I have rarely seen such statements in the past here and
I'm really wondering what your motivation for such statements is.
I'm sorry if you felt attacked, I had no intension to attack you or
anyone else. There was a problem that needed to be solved so that I
could continue to work. Of course I could have solved it without asking
at the list first. But as it involved changing packages on classes that
might be part of our contract and reverting some of your recent changes
I thought it was much better to ask on the list first so that we could
find a solution that take all needs into account.
With OSGi, dependencies are at the package level. If several bundles
(blocks) provide the same package the framework will chose the package
from one bundle and ignore the rest of the implementations of the
package (actually, several versions of the same package can be used at
the same time but that is not relevant for the current issue).
I thought we discussed this and I think it was you who said that it's
possible to have several bundles export the same packages.
I hope I have not said that, in any case it is close to false (see the
third paragraph in
http://www.osgi.org/blog/2006/04/please-tell-us-what-you-want-from-osgi.html).
There is some complicated workaround that can be used (see
http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg01004.html and the
rest of that thread), but I think it adds other problems, so I think we
should avoid split packages.
But even if
that is not possible now, we have to distinguish between bundles and
(maven) modules I think. The current bootstrap module has one single
reason: the paranoid classloader. It contains all classes that have to
go into WEB-INF lib. Everything else can be loaded from the paranoid
class loader from any destination. So this module is just there two
create a separate jar(!) - not bundle. I'm not sure, but I think most of
this stuff is useless for OSGi anyway as OSGi will do the classloading;
Might be, but o.a.c.classloader is needed in cocoon-core, so I cannot
just ignore cocoon-bootstrap. From your explanation it makes sense to
have it as a separate jar. For the time being it seems simplest to make
it a separate bundle as well.
Is it possible to have an OSGi bundle which exports classes of two jars?
A bundle is packaged as a jar, so it is not possible for two separate
jars. A bundle can contain internal jars that are added to the bundle
internal classpath. There is something called fragments in R4 where a
fragment bundle can add optional things to another bundle. I haven't
studied the details about them though.
<SNIP/>
We have discussed package conventions for blocks before and
o.a.c.<blockname> as package prefix for a block seam to be a reasonable
convention, that package name clashes between block communities.
Yes, this is a good choice, but as we also discussed we can't simply
rename the packages for existing code because of compatibility. So I see
this as a long term goal.
We can go in this direction by tidying up the package structure and
deprecate the split packages during 2.2 and remove them in 3.0.
For cocoon-bootstrap I would suggest that we keep o.a.c.classloader as
is, as the whole package was moved from cocoon-core and as it doesn't
have anything with bootstraping to do AFAICS. o.a.c.servlet can go to
o.a.c.bootstrap.servlet (we could possibly keep and deprecate
o.a.c.[BootstrapClassLoaderManager|ParanoidServlet] in 2.2 and just let
them extend the moved classes in o.a.c.bootstrap.servlet).
Whatever you think is best, just go ahead - these classes are all new
for 2.2 anyway so we can use any package. In addition if you think that
bootstrap is the wrong module name, go ahead and change it.
Ok, I changed that.
o.a.c.util is
most complicated, ClassUtils could go back to cocoon-core as it isn't
used in cocoon-bootstrap, it is less clear what we should do with the
WildCardHelper.
Yes, if you think that it helps, move ClassUtils back to core. The only
solution for the WildCardHelper is to duplicate the code if it's rely
required to have distinct package names. The former version was in the
o.a.c.matching.helper package. We could put it back there.
The WildCardHelper is used outside the matchers, so it made sense to
move it to util. I moved it back to util in core and kept a copy in
bootstrap.
I really think that these package name restrictions of OSGi bundles will
lead to problems in the long run for us.
I'm certain that it will. Modularization is not for free, OTH having a
huge monolith is even more expensive.
Just to stress the portal as an
example, I want to split the code base into several modules(!), one for
the portal core, one for the portlet integration, one for the wsrp4j
integration and so on. Now, all classes have the base package
o.a.c.portal, while the different modules use sub packages like
o.a.c.portal.pluto or o.a.c.portal.wsrp4j; I really hope that we don't
have to give up these package naming conventions just because of the
OSGi bundling.
As long as you don't want to contribute classes to a single package from
several modules, it will be fine.
I currently don't know if each module will be an own
bundle or not and how this will work in OSGi;
I would suggest that each module produce a bundle, everything else seem
complicated. The idea with modules IIRC is that they produce exactly one
artifact.
but I think that the ideal
solution for this would be that I don't have to worry about that and
just write my code. Everything else will then hopefully handled by the
framework I use.
Sure, that would be nice ;) But I have never seen any framework that
doesn't impose any restrictions whatsoever. And currently OSGi is the
main modularization framework in Java and considering the development
pace in the Eclipse community and elsewhere the restrictions seem to
support development rather than hinder it.
/Daniel
