Kohsuke,
Your point about static analysis is well taken. When we switch to using
maven-bundle-plugin (which wraps bnd), bnd will be our static analyser.
Since it generates proper Import-Package by statically analysing
classes, we won't see so many NoClassDefFoundError. Even then, people
have to be careful about specifying dependencies, because we may still
see ClassNotFoundException for Class.forName scenarios or occasional
NoClassDefFoundError in case of improper packaging/distribution. Today,
we can't use Import-Package and hence maven-bundle-plugin, because we
have many split-package scenarios which can only be supported by use of
Require-Bundle. After tp2, we have to spend some time in designing the
modules. We should prioritise this.
I hope the point made in my earlier email is not lost because of this
email - people still have to ensure that their changes works on OSGi
mode. Specifying dependency correctly is the necessary part of it,
testing should still be done on OSGi mode.
Thanks,
Sahoo
Kohsuke Kawaguchi wrote:
>
> I think the root cause of the problem is the inconsistent behavior
> between compiler and OSGi runtime. Those problems should have caused a
> compile time error, instead of runtime NoClassDefError.
>
> The coverage of QL will be limited by its nature, and more to the
> point, no matter how many tests we run, we will never get to 100% code
> coverage. That means we can end up leaving NoClassDefErrors in some
> rarely used parts of our code (like error handling), waiting to
> explode at the production site.
>
> This is not to say that we should watch QL tests in OSGi mode closely,
> but don't we clearly need some kind of static code analyzer that
> identifies the references to classes that a module cannot see?
>
>
> I mean, this is the whole point of static typing. If we can't even
> detect a fatal problem until we run the code, we might just as well
> program in a typeless language.
>
>
> Sahoo wrote:
>> Because of changes made by some developers in last couple of weeks,
>> v3 build off trunk was not running on Felix. The tp2 branch was OK
>> most of the time. The failure on trunk went unnoticed for a long time
>> because SQE had switched off Felix mode for QL. They have now changed
>> QL to run both on HK2 as well as Felix mode. I have just now fixed
>> [1] the code in trunk, so server can run on Felix mode again. *Please
>> do not break Felix mode*. Run *latest* QL before checking in. It is
>> mandatory that any change you make is compatible on both Felix as
>> well as HK2 mode. You are therefore encouraged to run dev tests on
>> both modes. The instructions to run on Felix mode could not be
>> simpler. It is given below:
>>
>> Option 1: Using env var:
>> export GlassFish_Platform=Felix
>> asadmin start-domain or java -jar glassfish-$version.jar
>>
>> Option 2: Using system property:
>> java -DGlassFish_Platform=Felix -jar glassfish-$version.jar
>>
>> You can start in one mode, stop and restart in another.
>>
>> Thanks for your cooperation,
>> Sahoo
>>
>> [1] http://fisheye4.cenqua.com/changelog/glassfish-svn/?cs=20614
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>>
>
>