I have checked in initial implementation of a module dependency
verifier. You can invoke the standalone tool by running the following
command:
/$WS/hk2/dependency-verifier/run.sh <path to glassfish/modules> [module
jar name].../
WS denotes the directory where you have checked out latest hk2 from trunk.
This tool has been integrated with the hk2-maven-plugin's verify phase.
When we update GF v3 to use 0.3.1 rel of HK2, this plugin would be
active by default. The Mojo can be configured to fail on error; by
default, it just WARNs of missing dependencies. Since GF v3/trunk does
not yet use HK2 version #0.3.1, this goal is not active now. However,
you can still use it by explicitly calling the goal as shown below:
/cd v3;
mvn com.sun.enterprise:hk2-maven-plugin:0.3.1-SNAPSHOT:analyse-dependency
/
This will verify all the modules in v3. If you want to verify a single
module, then you can go to that directory and run the command.
When I run this, I see a few issues in modules in current glassfish. I
hope each module owner would analyse the failures and fix them.
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
>>
>>
>
>