Hi,
the bundle generator certainly has some limitations. I would really
like to have an advanced graphical tool which can generate code using
different templates. Unfortunately, we lack man power for this kind of
project.
I am not in my office this week, so I can not look at the code of the
bundle generator right now, but I hope my comments below are still
correct.
Am 15.02.2010 17:26, schrieb Tangi Meyer:
Hi Sascha,
Thank you for your answer.
I have some questions regarding bundles generation:
- when I'm creating my mainApp bundle, I cannot uncheck the use
GUI_SUPPORT option and this creates a view class in another
repository/bundle ... If I uncheck the GUI_SUPPORT option then,
the generated CMAKE files still embed references to Qt which
causes CMAKE to not work. I will try to post some snapshots.
It is important to understand that the code for the executable (e.g.
for ExtApp.exe or your own) which is generated by the bundle generator
does not belong to any bundle. It is something "external" to the set
of bundles, which should just be a really small wrapper which calls
the berry::Starter::Start method.
Ok that is how I see it.
The generator is not able to generate code for an executable only. I
don't know right now why you can't switch off GUI_SUPPORT, but once
enabled and you run CMake configure, the files are generated. Turning
it off afterwards does not delete the already generated files.
However, you can just delete the generated bundle.
I did it just after my last email.
You may still include the executable code in a bundle directory and
merge the bundles CMakeLists.txt file and the one for the executable.
This is done for example in the org.blueberry.osgi bundle, which also
defines an executable (see its CMakeLists.txt file). But this is just
some CMake stuff.
I have been mixing CMake and bundle generation problems but I'm
starting to improve ... :)
- how are the dependencies in the bundle generator handled? I'm
trying to use the required plugins option but I do not see the
impact of it. In particular, my mainApp requires every include and
dependencies repositories to be set by hand ...
The dependencies you can declare in the bundle generator are
dependencies between bundles only. They do not apply to the
executable. Those dependencies are written into the bundles
MANIFEST.MF file and the build system uses them to set up the include
paths and linker dependencies properly. The OSGi runtime also uses the
dependencies when loading a bundle - it ensures that all the bundles
it depends on are loaded before.
Ok.
You should not need to add additional dependencies (in CMake) to your
executable. It should only depend on org.blueberry.osgi, which takes
care of the rest. All other dependencies to other bundles or external
libraries should ideally be handled be some of your own bundles.
This is not the case for the ExtApp so that confused me a little.
Yes, I forgot about the Poco Libraries. They are included explicitly in
the CMakeLists.txt for ExtApp (for Poco::Path etc.). But there shouldn't
be any other libraries (except for some special cases, who knows...)
- concerning the workbench, I will basically have to generate a
bundle and then modify by hand the CMAKE files and C++ files?
Basically, yes. You should not need to touch the CMakeLists.txt file
of the generated bundle. Just add the source files to the files.cmake
file and add your own implementation of IApplication as an extension
in your plugin.xml file (and in the manifest.cpp file).
OK.
I will come back to you if I have other questions that pop to my mind.
Please do so :-)
Here is one!
Is there a mean to specify the use of only a limited number of plugins
from the MITK Bundles repository?
E.g. shall I exclud them from the application toolbar? or specify
direct access to the plugin repository through the Poco datapath
management in myApp.cpp?
There is no way right know to exclude specific bundles from a bundle
repository (directory). I can think of the following options:
- In the MITK CMake configuration, you could just enable those bundles
you really want (no compilation/linking step needed). Disabling a bundle
just deletes its MANIFEST.MF file in the binary bundle directory, so the
bundle will not be found at runtime.
- If you do not change the MITK source code itself, you could copy (or
better, symbolic link) the subset of bundles you are interested in to
another directory and add this directory in your MyApp.ini file.
The code in ExtApp.cpp which hard-codes the bundle directories has only
been included for simplicity. Having a ExtApp.ini (or myApp.ini) file
listing the bundle directories is enough (and overwrites the hard-coded
settings).
I would advise against removing specific entries in the application
toolbar. You would have to rely on specific bundle ids and would only
exclude certain elements (views) from such bundles. They are still known
to the system and may be started by other means and execute code.
Best,
Sascha
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
