Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
<snip/>
Just want to mention that I don't think that our users need to know
about OSGi at all if they don't want. They have to describe their
block in the descriptor (block.xml) and the rest will be done
automatically.
Maybe or maybe not ;) The OSGi manifest is mainly about exporting and
importing Java packages, which are concerns that we haven't discussed
in any detail for the block descriptor. We could put this info in the
block.xml and generate the manifest file automatically from it.
In Eclipse they didn't go that way. There was some info in their
pluggin descriptor that overlapped with the OSGi manifest. They
depreciated this infor from the pluggin descriptor and recommend
people to use the OSGi manifest instead. I would prefer that we do
the same and consider the OSGi manifest and the block.xml as taking
care of different concerns.
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.
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.
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.
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.
/Daniel
