You are right of course that splitting the code into more files does not
necessarily make it more readable.
So what I did was to mainly the code more readable. I think in the
current state also someone who sees the code
for the first time should be able to understand it pretty fast. So for
example the main and launch methods explain the big picture without
going into the details.
http://svn.apache.org/repos/asf/karaf/trunk/main/src/main/java/org/apache/karaf/main/Main.java
About the dependencies. I fully agree that we should keep the main code
simple and that we should not introduce more dependencies.
After all it should just be the bootstrap and hand over to the real OSGi
code as soon as possible.
So what I thought about using a feature is the following:
We currently have startup.properties with:
mvn\:org.ops4j.base/ops4j-base-lang/1.3.0 = 5
mvn\:org.apache.servicemix.bundles/org.apache.servicemix.bundles.junit/3.8.2_4
= 5
...
We generate this from a pom.xml and a feature.xml that are located in
framework.
So we already a an equivalent feature:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<features
xmlns="http://karaf.apache.org/xmlns/features/v1.0.0"name="framework-3.0.0-SNAPSHOT";>
<feature name="framework"version="3.0.0-SNAPSHOT"description="Karaf core
feature">
<bundle
start-level="5"start="true">mvn:org.ops4j.base/ops4j-base-lang/1.3.0</bundle>
<bundle
start-level="5"start="true">mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.junit/3.8.2_4</bundle>
...
</feature>
</features>
What I planned is to read the feature using jaxb or even plain dom and xpath in
the simplest way possible to read the framework feature and extract the
same informations we have in startup.properties. We could have a property in
the config.properties that specifies the mvn url of the framework feature file
and the
feature name.
This should be just some few lines of code. Additionally we can keep the
startup.properties loading code and use it if there is a startup.properties
file. I would prefer to
completely remove the startup.properties but if David needs it we can keep it.
The advantage of removing startup.properties would be that we can also remove
the functionality of the startup.properties generation which is quite
complicated as it needs to
use the feature service code outside of OSGi.
Christian
Am 07.05.2012 09:00, schrieb Guillaume Nodet:
Christian, I don't care about the fact that the main class is 3000 lines or
split into 30 files of 100 lines each.
What I care about is that the main jar is so simple so we don't ever have
to touch it.
The main reason is that while you can update all the bundles in the osgi
framework, if you have to change the main jar, you need a manual
intervention.
So the less code we have in main the better. This implies that we don't
handle features or OBR there and this also implies that we should not try
to do a real maven resolution here too (but that's not the case right now
afaik).
As for simplifying the startup.properties and config.properties handling,
that sounds like a good idea. The original code comes from Felix directly
and only had minor modifications to do what we want, but some features are
clearly not used.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
