Forgot to mention - we are not building javahelp, it is picked up from
maven repository as binary dependency...
Snjezana Sevo-Zenzerovic wrote:
> Bobby,
>
> modules that have real compile time dependency on javahelp are upgrade
> tool and verifier. The purpose of packager/glassfish-common-tmp
> reference is to place javahelp jar into shared glassfish-common
> package and make it available at runtime for both upgrade tool and
> verifier.
>
> That being said, I am working on separating javahelp into its own
> packager module, but the idea remains the same. We need packager
> reference only if someone is really using javahelp...
>
> Thanks,
>
> Snjezana
>
>
> Bobby Bissett wrote:
>> I'm looking for modules that use/build javahelp. As far as I can
>> tell, no one is building it -- is that right?
>>
>> These modules depend on it (I guess):
>>
>> hostname% find . -name "pom.xml" | xargs grep javahelp
>> ./extras/upgrade/upgrade-jar/pom.xml:
>> <Class-Path>kernel.jar admin-cli.jar stax-osgi.jar admin-cli-l10n.jar
>> javahelp-2.0.02.jar</Class-Path>
>> ./extras/upgrade/upgrade-jar/pom.xml:
>> <artifactId>javahelp</artifactId>
>> ./packager/glassfish-common-tmp/pom.xml: <!-- javahelp jar -->
>> ./packager/glassfish-common-tmp/pom.xml:
>> <artifactId>javahelp</artifactId>
>> ./verifier/verifier-impl/pom.xml:
>> <artifactId>javahelp</artifactId>
>>
>> Is "packager/glassfish-common-tmp" considered a module? I've been
>> asked to check on javahelp dependencies (or vice versa) and don't
>> have the brain power to understand what the packager stuff above is
>> about. Someone put the javahelp jar file in the modules directory, so
>> it seems that someone is depending on it.
>>
>> Thanks,
>> Bobby
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>