Marshall Schor wrote:
> Thilo Goetz wrote:
>   
>> Marshall Schor wrote:
>>   
>>     
>>> Looking at a previous thread:
>>> http://markmail.org/thread/xrv7qormkenc4hxd I now remember we have made
>>> a change in the behavior to require explicitly listing all the jars in
>>> the install.xml file.  We thought that was OK because the Eclipse
>>> tooling for building pears did this.
>>>
>>> I'm wondering if the right fix for this is to change the maven pear
>>> plugin to operate like the eclipse pear builder plugin, and have it add
>>> the lib jars to the install.xml?  That would fix the issue here, and
>>> likely reduce "breakage" if people rebuild their pears after this release.
>>>
>>> If we did this, I would change the documentation to say ... there is no
>>> need to specify Class Path entries for Jars in the lib directory, when
>>> using the Eclipse plugin pear packager or the Maven Pear Packager.
>>>
>>> Opinions?
>>>     
>>>       
>> You can guess what my opinion about this is from previous
>> conversations.  It leads to the kind of workarounds you have
>> to do we discussed on the users list a week or so ago.  When
>> I build a pear with an ant script, I copy the files I want
>> packaged to a temp dir and the package the pear there, to make
>> sure the [expletive deleted] pear packager really only packages
>> what I want it to, not all my eclipse dot files and whatnot.
>>     

While crawling through the maven pear package code, I found that it
copies the "standard" Pear directories to a spot where it does its
building, and during that copying it omits those pesky "dot" files
(files starting with a ".").  For the curious, see
"removeDotDirectories" (misnamed - should be removeDotFiles I think) in
PearPackagingMojo class.

-Marshall
>> But that's just my opinion.
>>   
>>     
>
> That would be annoying - grabbing dot files, etc.  It sounds to me like
> an improvement request for the Eclipse Pear Packaging Plugin, perhaps to
> default to not including that kind of stuff.  I guess it has a menu to
> pick and choose exactly what you want to include, but it's tedious to
> use, and I'm guessing it doesn't "remember" your previous settings...
>
> The proposal on the table though, is much more focussed - to have the
> maven pear packager add (only) .jar files that are in the pear's lib
> directory.
>
> I'm +1 for doing this, for reasons cited before (and also for enforcing
> a documented ordering of these jars, as follows: the jar that is being
> built (e.g., for the regular expression annotator, it would be the main
> artifact, in maven's terms), followed by whatever the user specifies, if
> anything, followed by the jars in the lib/ in arbitrary order.  And, I
> would remove duplicates :-) ).
>
> Any more opinions?
>
> -Marshall
>
>
>
>   
>> --Thilo
>>
>>   
>>     
>>> -Marshall
>>>
>>> Marshall Schor wrote:
>>>     
>>>       
>>>> Thilo Goetz wrote:
>>>>   
>>>>       
>>>>         
>>>>> On 11/23/2009 15:47, Marshall Schor wrote:
>>>>>     
>>>>>         
>>>>>           
>>>>>> A little more investigation:  I think what is supposed to happen is that
>>>>>> the "install" process for the pear ends up calling
>>>>>> buildComponentClassPath in the InstallationController, which should be
>>>>>> adding all the jars in the lib/ to the classpath.
>>>>>>       
>>>>>>           
>>>>>>             
>>>>> No, the jars should be added to the classpath in the install.xml
>>>>> file when the pear is built.  This is not happening I guess.
>>>>>     
>>>>>         
>>>>>           
>>>> Right.  This can be added to the build.
>>>>   
>>>>       
>>>>         
>>>>> uima-an-regex.jar *is* added to the classpath, the other two are
>>>>> not.  So afaics, this has nothing to do with the changes to
>>>>> buildComponentClassPath.  For example, when you create an eclipse
>>>>> project with the regex annotator in it, complete with all 3 jar
>>>>> files in the lib dir, the pear packaging tool automatically
>>>>> generates the correct classpath.
>>>>>     
>>>>>         
>>>>>           
>>>> I tried "installing" the pear, and found that the
>>>> buildComponentClassPath did create a correct classpath, but wrote it out
>>>> in the installation's metadata/ directory as the file "setenv.txt". 
>>>> This file has a comment at the top which says:
>>>> ### Add the following environment variables
>>>> ### to appropriate existing environment variables
>>>> ### to run the RegularExpressionAnnotator component
>>>>
>>>> Does anyone know how this setenv.txt file is supposed to be used,
>>>> somehow, when the pear is run?  Is there any code which picks it up and
>>>> applies it automatically, or is this just supposed to be a manual 
>>>> operation?
>>>>
>>>> -Marshall
>>>>   
>>>>       
>>>>         
>>>>> --Thilo
>>>>>
>>>>>     
>>>>>         
>>>>>           
>>>>>> Can you say how you are running the pear in a manner where this is not
>>>>>> happening?
>>>>>>
>>>>>> -Marshall
>>>>>>
>>>>>> Marshall Schor wrote:
>>>>>>       
>>>>>>           
>>>>>>             
>>>>>>> Well, this may be due to a misunderstanding on my part.  The issue is
>>>>>>> around what files get added *automatically* to the class path in
>>>>>>> various
>>>>>>> situations.
>>>>>>>
>>>>>>> I know we made a change to remove automatic adding of the files in the
>>>>>>> lib/ when "running" a pear, but I had understood that the pear
>>>>>>> packaging
>>>>>>> was still going to add those files to the generated classpath, when
>>>>>>> creating the pear.  That is what is *not* happening.
>>>>>>>
>>>>>>> Thilo - is that your understanding of what should be happening?  If
>>>>>>> not,
>>>>>>> what do you think should be happening with regard to this?  I remember
>>>>>>> some discussion around not breaking older pear files with our
>>>>>>> changes...
>>>>>>>
>>>>>>> -Marshall
>>>>>>>
>>>>>>> Marshall Schor wrote:
>>>>>>>
>>>>>>>         
>>>>>>>             
>>>>>>>               
>>>>>>>> Thilo Goetz wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>           
>>>>>>>>               
>>>>>>>>                 
>>>>>>>>> Er, I see that this is now all maven based.  I have
>>>>>>>>> no idea how to add the missing jars.  Over to you,
>>>>>>>>> Marshall.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>             
>>>>>>>>>                 
>>>>>>>>>                   
>>>>>>>> OK - will do...
>>>>>>>>
>>>>>>>> -Marshall
>>>>>>>>
>>>>>>>>
>>>>>>>>           
>>>>>>>>               
>>>>>>>>                 
>>>>>>>>> --Thilo
>>>>>>>>>
>>>>>>>>> On 11/23/2009 14:45, Thilo Goetz wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>             
>>>>>>>>>                 
>>>>>>>>>                   
>>>>>>>>>> This is probably a regression from
>>>>>>>>>> https://issues.apache.org/jira/browse/UIMA-1595
>>>>>>>>>>
>>>>>>>>>> I should be able to investigate later today, but
>>>>>>>>>> if anybody else wants a go, feel free.
>>>>>>>>>>
>>>>>>>>>> --Thilo
>>>>>>>>>>
>>>>>>>>>> On 11/23/2009 14:34, Thilo Goetz (JIRA) wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>               
>>>>>>>>>>                   
>>>>>>>>>>                     
>>>>>>>>>>> Regex: pear install.xml is missing 2 of the 3 jar files
>>>>>>>>>>> -------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> Key: UIMA-1676
>>>>>>>>>>> URL: https://issues.apache.org/jira/browse/UIMA-1676
>>>>>>>>>>> Project: UIMA
>>>>>>>>>>> Issue Type: Bug
>>>>>>>>>>> Components: Sandbox-RegexAnnotator
>>>>>>>>>>> Affects Versions: 2.3S
>>>>>>>>>>> Reporter: Thilo Goetz
>>>>>>>>>>> Fix For: 2.3S
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The regex pear file is not packaged correctly. 2 out of 3 jar files
>>>>>>>>>>> are missing from the install.xml file, resulting in
>>>>>>>>>>> ClassNotFoundExceptions when you're trying to run the installed
>>>>>>>>>>> pear.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                 
>>>>>>>>>>>                     
>>>>>>>>>>>                       
>>>>>>>>>             
>>>>>>>>>                 
>>>>>>>>>                   
>>>>>>>>           
>>>>>>>>               
>>>>>>>>                 
>>>>>>>         
>>>>>>>             
>>>>>>>               
>>>>>     
>>>>>         
>>>>>           
>>>>   
>>>>       
>>>>         
>>
>>   
>>     
>
>
>   

Reply via email to