Hi Sahoo!
I've cc'd the dev alias so others can follow along. What I was missing
was indeed "<unpackBundle>true</unpackBundle>", thanks for pointing this
out.
More comments inline.
Thanks!
Ken
Sahoo wrote:
> Ken Paulsen wrote:
>>
>> Hi Sahoo / Jerome:
>>
>> I fixed the repackaging of jsftemplating.jar and this fixed all the
>> problems I was having. The facesconfig.xml file is found at startup
>> when using the hk2_import_bundle property, the files I wasn't able to
>> find are now being found (now that they exist). I'm sorry for the
>> false alarm, too many different test and configurations -- I somehow
>> missed the obvious problem.
> In my first email, I asked you to check if faces-config.xml was indeed
> packaged inside jsftemplating.jar or not. Any way that's irrelevant,
> now that the issues has been identified and fixed.
I thought I did check, however, apparently my check was done incorrectly
-- sorry! I guess I had too many versions of that jar file laying
around and must have looked at the wrong one.
>> Anyway, I'm now running into another problem, which is probably also
>> a small error on my part. Perhaps you have an idea of why this is a
>> problem:
>>
>> admingui/jsftemplating/pom.xml <-- repackages jsftemplating.jar and
>> installs it in the local .m2 directory.
>> admingui/pom.xml <-- Defines the repackaged jsftemplating.jar as a
>> dependency.
> Why is this dependency there? Remove this.
>> admingui/core/pom.xml <-- uses admingui/pom.xml as its parent
>>
>> Problem: if I build in admingui (mvn install), it fails in the "core"
>> sub-module with hundreds of error messages related to not finding
>> jsftemplating classes for example:
>>
>>
>> /glassfish/v3/admingui/core/src/main/java/org/glassfish/admingui/handlers/SampleHandlers.java:52:
>>
>> package com.sun.jsftemplating.layout.descriptors.handler does not
>> exist
>> import
>> com.sun.jsftemplating.layout.descriptors.handler.HandlerContext;
>>
> This is happening, because maven tries to use target/classes in
> compiler classpath for projects that are same in the same maven
> reactor and maven-bundle-plugin does not extract the repackaged jar in
> target/classes unless asked to do so. That's why, if you look at any
> of the distributions/pom.xml, we actually configure
> maven-bundle-plugin to extract the jar like this:
> (taken from v3/distributions/external/sysnet-registration/pom.xml)
>
> * <!-- Maven uses the output directory
> (target/classes)
> rather than the final bundle, when compiling against
> projects in the same reactor (ie. the same build).
> Since this jar comprises of classes that come from
> some other jar and other modules depend on this
> artifact, we need to unpack.
> -->
> <unpackBundle>true</unpackBundle>
> *
> Check maven-bundle-plugin documentation for more details. If you do
> this in the pom.xml where you are repackaging jsftemplating, your
> problem would be solved. I wish this discussion were taking place in
> dev@, as this is beneficial to others as well.
This fixed the problem! Thanks for all your help and your patience!
Ken