Adam Lally wrote:
<snip>
My general opinion is - warn developers on possible conflicts, but
let them
go their own way.
1) I believe, PEAR Packager may post a warning that adding UIMA JARs to
a PEAR package may lead to conflicts, but it should not prevent
developers
from doing this, because we cannot predict all possible uses of PEAR
packages.
I believe we can make some decisions about what PEAR files can and
can't be used for. The intention of the PEAR is to be able to deploy
the component into a UIMA runtime container of some kind. This WILL
(not may) lead to conflicts if the PEAR contains UIMA framework jars.
So I think it's worthwhile to prevent the user from going wrong in
this way.
I agree with Adam - I think it is worthwhile *preventing* developers
from adding Jars containing UIMA Framework classes
to the lib or Pear component class path. A reoccurring goal of the UIMA
framework
is to help those using it be successful, which this would do.
2) The buildComponentClassPath() method may also warn that the CLASSPATH
contains duplicated entries, but it should not ignore them. The
buildComponentClassPath() method does not control the names of the JARs
added to the CLASSPATH, so I don't believe, it could discover UIMA
JARs in
the component CLASSPATH, because developers are free to use any names
for
their JARs.
You're right that checking jar file names is not the right thing to
do. However, instead it may be possible to attempt to load UIMA
framework classes (such as
org.apache.uima.analysis_component.AnalysisComponent) from the
classpath that the user has specified for their PEAR. If the class is
able to be loaded, you will know that the PEAR is not valid.
I agree with Adam here, and would like to see this kind of check done.
It will result
in a much clearer error message than what is happening today, something
the assembler or
packager of the PEAR will be able to understand and correct.
-Marshall
