Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
I still like the idea of automatically generating the OSGi manifest
:-). All the general properties (author, documentation, ...) are
available in block.xml
Yes, OTH, I believe that it is in general an anti pattern to have two
reduntant versions of essentially the same info. Considering the
popularity of Eclipse, there will be many people that have experience
with OSGi manifest files, and that will find it confusing to specify
esentially the same info somewhere else. Also take into account that
the Eclipse developers decided to deprecate parts of pluggin.xml,
which is rather well spread, in the interest of avoiding redundancy.
As nothing, except for some experimental code and some webpages is
dependent on the format of block.xml we have far less restrictions
than they have.
Are you proposing to skip block.xml and only have the OSGi manifest or
reducing block.xml and putting every redundant piece of information
into the OSGi manifest?
The later, let the OSGi manifest package dendencies and what happens to
be part of the manifest. Then block.xml specifies whats need to be
specified at the component level and sitemap level.
IMO we should make it easy for the Cocoon blocks to coexist and
colloborate with "pure" bundles (without any Cocoon dependencies) or
Eclipse plugins (if you deploy the needed Eclipse framework bundles).
But it becomes rather abstract to discuss how to split (or not) the
configuration files at this point. We have to let that develop while we
get more experience from implementing the different layers.
I don't think that those general meta information are the real problem
but the dependency information. The declared dependencies should be
the same for the OSGi layer, component management and the sitemap
layer. Declaring them twice will lead to a big mess.
and the information about the exported packages can also be
generated if we seperate between public (exported) and internal
classes and libraries within our directory structure.
[block]
- src
- java
- public
com/mycompany/project/xyz
...
- internal
com/mycompany/project/xyz/impl
...
- lib
- public
- internal
The information about the imported packages can be looked up in the
OSGi manifest of the required block, again at build time.
Yes, in some ideal case this would be nice. But given that our
current set of blocks doesn't fullfill any such standards we
propbably have to do a lot of exports and imports by hand.
here we will have to do a lot of refactoring in any case as we have to
adapt our package name structure IIU OSGi and one of your previous
mails correctly. Moving around some packages will not be the problem
(with SVN and Eclipse).
That's true. What I meant is that we for some of the current blocks and
for the Cocoon core might need to have back compatible solutions with
package structure that is less easy to automatically export and import.
Automatically importing things that one don't need from another block
is not necessarilly a good idea as it imposes more constraints than
necessary and make it harder to change dependecies if one want to.
if it's only about the Import-Package property than I'd say that we
should include them into block.xml as _I_ prefer XML for properties.
Using some XML editor that supports XML schema (e.g. OxygenXML) will
make editing the block descriptor very easy.
I also like XML, but not as much as I dislike unnecessary redundancy ;)
In short, I think that we (usually) don't have to put import/export
packages information into it.
Of course, keeping the OSGi manifest and block.xml seperate is
always an option. Making the block build process handle both
scenarios shouldn't be difficult.
---
I'm a bit confused about the relation between import/export package
and Require-Bundle. Does anybody know about this?
Require-Bundle is part of Eclipse and possibly of OSGi R4 see
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core-home/runtime/runtime.html
and https://bugs.eclipse.org/bugs/show_bug.cgi?id=82855.
thanks, will read it (I think we should create a wiki page with all
the OSGi information we (you) have collected so far)
Sounds like a good idea ;)
/Daniel
