dev@glassfish.java.net

modularization & OSGi

From: Jerome Dochez <Jerome.Dochez_at_Sun.COM>
Date: Thu, 28 Aug 2008 12:02:05 -0700

Hi All

I just have committed some fixes to remove unwanted dependencies
between modules and kernel. There should not be any module depending
on kernel (there is still one but I will fix it later), and if you
happen to need to import a class located in the kernel module, please
talk to me first.

I have also seen places when people started using OSGi APIs directly,
I have said in previous communications, including the engineering
meeting that I do not want any OSGi API usage in the V3 codebase. The
simple reason is that we want to have the flexibility to run V3
without an OSGi runtime (embedded scenario) and we can do that by
providing a mock-up implementation of the hk2 interfaces which
provides us with an isolation layer. So all OSGi direct usage should
be wrapped in an hk2 interface so we can ensure that a mockup
implementation can be done. We already have external users/companies
using V3 in such a scenario, it's important we don't break them.

Also I have seen some people editing their pom.xml and adding
hardcoded version numbers in the dependency list like 10.0-SNAPSHOT
instead of ${glassfish.version}. this is *really* bad and I will not
be hunting this time for whoever did this but this is my final
warning, I will be a lot less accommodating next time. Hardcoding
version is bad because it will make the job of releasing impossible
without tweaking those pom.xml.

Finally, changes to pom.xml is complicated I have to agree so when you
add a new module, when you change the distribution or when you change
a maven plugin configuration, I want to review the changes or I want
Sahoo to review the changes.

Thanks, jerome