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?
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).
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.
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)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
