You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Thilo Goetz <tw...@gmx.de> on 2009/06/29 11:13:26 UTC
Building the eclipse update site
All,
I was trying to follow up on Burn's comments on
https://issues.apache.org/jira/browse/UIMA-1326
So I tried to build the eclipse update site to
be able to (easily) install our eclipse plugins.
I tried to follow the instructions on our web
site, but I was unable to find the feature jars
I'm supposed to copy. Where are those supposed
to end up at? Thanks.
--Thilo
Re: Building the eclipse update site
Posted by Jörn Kottmann <ko...@gmail.com>.
Hello
> Despite all this, I'm able to run our plugins from
> eclipse. Everything seems to be working normally.
> I get a small number of plugin-not-found warings at
> startup, and continuous JDOM warnings throughout,
> but that doesn't seem to affect functionality.
>
Everytime I try to run the Cas Editor from eclipse
it needs a bit hacking.
The uimaj-ep-runtime plugin is not really recognized,
only when I copy it over into the eclipse plugin folder.
The Cas Editor cannot load its classes. The default Bundle-ClassPath is
./ and thats fine when the plugin is packaged, but its not
fine for the eclipse set up where the classes live in target/classes.
When I try to have both paths on the Bundle-ClassPath the felix
plugin complains and fails.
Jörn
Re: Document collections [was: Re: Building the eclipse update site]
Posted by Marshall Schor <ms...@schor.com>.
Jörn Kottmann wrote:
> Jörn Kottmann wrote:
>> The proposed changes would move the project model out
>> of the Cas Editor into a new project with the advantage that
>> it can be used by other tooling too. Like an analysis engine launcher
>> which needs a document collection to run the AE or a PEAR
>> runner.
>
> Should we split the Cas Editor for the 2.3.0 release or should we
> wait for the release after 2.3.0 ?
>
> In my opinion we should wait and rebuild the project model
> based on the Cas Editor project model. This would have the advantage
> that we can consider new requirements we may get
> from other tooling like an AE debug launcher or multi view support
> for the Cas Editor.
>
> It also has the disadvantage that the Cas Editor users have
> to convert their projects one day.
>
This could wait for the next release, IMHO, because I think it might
take more that the time left :-) given all the other things on our plate
to get done... And, I agree that the understanding of use case /
requirements might improve with a bit more time and discussion.
-Marshall
> Jörn
>
>
>
Re: Document collections [was: Re: Building the eclipse update site]
Posted by Thilo Goetz <tw...@gmx.de>.
Jörn Kottmann wrote:
> Jörn Kottmann wrote:
>> The proposed changes would move the project model out
>> of the Cas Editor into a new project with the advantage that
>> it can be used by other tooling too. Like an analysis engine launcher
>> which needs a document collection to run the AE or a PEAR
>> runner.
>
> Should we split the Cas Editor for the 2.3.0 release or should we
> wait for the release after 2.3.0 ?
Waiting is fine with me, I'm in no rush atm.
--Thilo
>
> In my opinion we should wait and rebuild the project model
> based on the Cas Editor project model. This would have the advantage
> that we can consider new requirements we may get
> from other tooling like an AE debug launcher or multi view support
> for the Cas Editor.
>
> It also has the disadvantage that the Cas Editor users have
> to convert their projects one day.
>
> Jörn
Re: Document collections [was: Re: Building the eclipse update site]
Posted by Jörn Kottmann <ko...@gmail.com>.
Jörn Kottmann wrote:
> The proposed changes would move the project model out
> of the Cas Editor into a new project with the advantage that
> it can be used by other tooling too. Like an analysis engine launcher
> which needs a document collection to run the AE or a PEAR
> runner.
Should we split the Cas Editor for the 2.3.0 release or should we
wait for the release after 2.3.0 ?
In my opinion we should wait and rebuild the project model
based on the Cas Editor project model. This would have the advantage
that we can consider new requirements we may get
from other tooling like an AE debug launcher or multi view support
for the Cas Editor.
It also has the disadvantage that the Cas Editor users have
to convert their projects one day.
Jörn
Re: Document collections [was: Re: Building the eclipse update site]
Posted by Jörn Kottmann <ko...@gmail.com>.
Thilo Goetz wrote:
> Jörn Kottmann wrote:
>
>> Thilo Goetz wrote:
>>
>>> Jörn Kottmann wrote:
>>>
>>>
>>>> Thilo Goetz wrote:
>>>>
>>>>
>>>>> Jörn Kottmann wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Jörn Kottmann wrote:
>>>>>>
>>>>>>
>>>>>>>> A collection of text documents that you can run
>>>>>>>> analysis on. If I understand correctly, the Cas
>>>>>>>> Editor currently requires XCAS/XmiCAS files. It
>>>>>>>> would be nice if users could just add their text
>>>>>>>> files and then either create annotations manually
>>>>>>>> with the Cas Editor, or automatically by running
>>>>>>>> some analysis and then view the results using the
>>>>>>>> Cas Editor. Then we could add results comparison
>>>>>>>> etc. See
>>>>>>>> http://dl.alphaworks.ibm.com/technologies/tap/text_analysis_perspective.pdf
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> for a (outdated) description of what we have
>>>>>>>> in-house. It's geared more towards a business user
>>>>>>>> than a developer, but the ideas of document collections
>>>>>>>> and the development cycle are equally applicable.
>>>>>>>> If there was enough interest here, I think that
>>>>>>>> would be a good direction to go in.
>>>>>>>>
>>>>>>>>
>>>>>>> Yes for me it sounds like the right way.
>>>>>>> We could also use it for debugging an AE, then
>>>>>>> a user defines a debug configuration and adds
>>>>>>> the collection as document source.
>>>>>>>
>>>>>>>
>>>>>> How would you define the format of a document collection ?
>>>>>>
>>>>>> To open a CAS document the document itself and a type system
>>>>>> for the document is needed.
>>>>>>
>>>>>> In the Cas Editor right now an Input Collection is a Corpus folder
>>>>>> which
>>>>>> contains xmi/xcas files
>>>>>> in one directory together with the project type system the files
>>>>>> can be
>>>>>> loaded by UIMA. Though
>>>>>> it has be criticized for not allowing sub directories for structuring
>>>>>> its documents.
>>>>>>
>>>>>> Jörn
>>>>>>
>>>>>>
>>>>> That's perfectly fine, we do this in a similar way.
>>>>> What would be good though is to distinguish between
>>>>> text documents and "CAS documents" (be they XCAS, XMI
>>>>> or some other format). So you could start your work
>>>>> by importing some text documents, then annotate them
>>>>> in various ways (manually, or with coded annotators).
>>>>> The CASes would reside in a different folder, and you
>>>>> could derive any number of CAS collections from the
>>>>> same set of source text documents. We find that way
>>>>> of working very convenient.
>>>>>
>>>>>
>>>> We could reuse the code which is in the Cas Editor right
>>>> now and move it into a new plugin which provides the document
>>>> collections and type system to other plugins.
>>>>
>>>> The Cas Editor should be independent of the project model because
>>>> people who use the Cas Editor do not necessarily want to it.
>>>>
>>>>
>>> +1, couldn't agree more. In fact, I would like to integrate
>>> the CAS editor into our tooling, that would be a good test
>>> case how independent it is. I don't know when I'll get around
>>> to playing with that, but it's definitely on my to do list.
>>>
>>>
>> Ok, then lets split the Cas Editor into the editing part and project
>> model. For the project model part we have to create a new eclipse
>> project, e.g. uimaj-ep-base. The remaining Cas Editor should be independent
>> of the project model which means uimaj-ep-base depends on the Cas Editor
>> (to add the
>> document provider extension to it).
>>
>> After we are done with that, we can look into uimaj-ep-base and see how
>> it fits our needs
>> and how it can be used by the other eclipse based tooling.
>>
>> Jörn
>>
>
> +1, that would be great. I would like to be able to use
> the CAS Editor sometimes not to edit CASes, but to simply
> display them. For example, you could imagine some Eclipse
> tooling that runs UIMA analysis and displays the results
> in the CAS Editor, without first materializing the CAS on
> disk. So with your proposed changes, I should be able to
> do that, right?
>
That is already possible. You must implement your own
CAS provider which knows how to get the CAS object
and config settings from your tooling.
The proposed changes would move the project model out
of the Cas Editor into a new project with the advantage that
it can be used by other tooling too. Like an analysis engine launcher
which needs a document collection to run the AE or a PEAR
runner.
Jörn
Re: Document collections [was: Re: Building the eclipse update site]
Posted by Thilo Goetz <tw...@gmx.de>.
Jörn Kottmann wrote:
> Thilo Goetz wrote:
>> Jörn Kottmann wrote:
>>
>>> Thilo Goetz wrote:
>>>
>>>> Jörn Kottmann wrote:
>>>>
>>>>
>>>>> Jörn Kottmann wrote:
>>>>>
>>>>>>> A collection of text documents that you can run
>>>>>>> analysis on. If I understand correctly, the Cas
>>>>>>> Editor currently requires XCAS/XmiCAS files. It
>>>>>>> would be nice if users could just add their text
>>>>>>> files and then either create annotations manually
>>>>>>> with the Cas Editor, or automatically by running
>>>>>>> some analysis and then view the results using the
>>>>>>> Cas Editor. Then we could add results comparison
>>>>>>> etc. See
>>>>>>> http://dl.alphaworks.ibm.com/technologies/tap/text_analysis_perspective.pdf
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> for a (outdated) description of what we have
>>>>>>> in-house. It's geared more towards a business user
>>>>>>> than a developer, but the ideas of document collections
>>>>>>> and the development cycle are equally applicable.
>>>>>>> If there was enough interest here, I think that
>>>>>>> would be a good direction to go in.
>>>>>>>
>>>>>> Yes for me it sounds like the right way.
>>>>>> We could also use it for debugging an AE, then
>>>>>> a user defines a debug configuration and adds
>>>>>> the collection as document source.
>>>>>>
>>>>> How would you define the format of a document collection ?
>>>>>
>>>>> To open a CAS document the document itself and a type system
>>>>> for the document is needed.
>>>>>
>>>>> In the Cas Editor right now an Input Collection is a Corpus folder
>>>>> which
>>>>> contains xmi/xcas files
>>>>> in one directory together with the project type system the files
>>>>> can be
>>>>> loaded by UIMA. Though
>>>>> it has be criticized for not allowing sub directories for structuring
>>>>> its documents.
>>>>>
>>>>> Jörn
>>>>>
>>>> That's perfectly fine, we do this in a similar way.
>>>> What would be good though is to distinguish between
>>>> text documents and "CAS documents" (be they XCAS, XMI
>>>> or some other format). So you could start your work
>>>> by importing some text documents, then annotate them
>>>> in various ways (manually, or with coded annotators).
>>>> The CASes would reside in a different folder, and you
>>>> could derive any number of CAS collections from the
>>>> same set of source text documents. We find that way
>>>> of working very convenient.
>>>>
>>> We could reuse the code which is in the Cas Editor right
>>> now and move it into a new plugin which provides the document
>>> collections and type system to other plugins.
>>>
>>> The Cas Editor should be independent of the project model because
>>> people who use the Cas Editor do not necessarily want to it.
>>>
>>
>> +1, couldn't agree more. In fact, I would like to integrate
>> the CAS editor into our tooling, that would be a good test
>> case how independent it is. I don't know when I'll get around
>> to playing with that, but it's definitely on my to do list.
>>
> Ok, then lets split the Cas Editor into the editing part and project
> model. For the project model part we have to create a new eclipse
> project, e.g. uimaj-ep-base. The remaining Cas Editor should be independent
> of the project model which means uimaj-ep-base depends on the Cas Editor
> (to add the
> document provider extension to it).
>
> After we are done with that, we can look into uimaj-ep-base and see how
> it fits our needs
> and how it can be used by the other eclipse based tooling.
>
> Jörn
+1, that would be great. I would like to be able to use
the CAS Editor sometimes not to edit CASes, but to simply
display them. For example, you could imagine some Eclipse
tooling that runs UIMA analysis and displays the results
in the CAS Editor, without first materializing the CAS on
disk. So with your proposed changes, I should be able to
do that, right?
--Thilo
Re: Document collections [was: Re: Building the eclipse update site]
Posted by Jörn Kottmann <ko...@gmail.com>.
Thilo Goetz wrote:
> Jörn Kottmann wrote:
>
>> Thilo Goetz wrote:
>>
>>> Jörn Kottmann wrote:
>>>
>>>
>>>> Jörn Kottmann wrote:
>>>>
>>>>
>>>>>> A collection of text documents that you can run
>>>>>> analysis on. If I understand correctly, the Cas
>>>>>> Editor currently requires XCAS/XmiCAS files. It
>>>>>> would be nice if users could just add their text
>>>>>> files and then either create annotations manually
>>>>>> with the Cas Editor, or automatically by running
>>>>>> some analysis and then view the results using the
>>>>>> Cas Editor. Then we could add results comparison
>>>>>> etc. See
>>>>>> http://dl.alphaworks.ibm.com/technologies/tap/text_analysis_perspective.pdf
>>>>>>
>>>>>>
>>>>>> for a (outdated) description of what we have
>>>>>> in-house. It's geared more towards a business user
>>>>>> than a developer, but the ideas of document collections
>>>>>> and the development cycle are equally applicable.
>>>>>> If there was enough interest here, I think that
>>>>>> would be a good direction to go in.
>>>>>>
>>>>>>
>>>>> Yes for me it sounds like the right way.
>>>>> We could also use it for debugging an AE, then
>>>>> a user defines a debug configuration and adds
>>>>> the collection as document source.
>>>>>
>>>>>
>>>> How would you define the format of a document collection ?
>>>>
>>>> To open a CAS document the document itself and a type system
>>>> for the document is needed.
>>>>
>>>> In the Cas Editor right now an Input Collection is a Corpus folder which
>>>> contains xmi/xcas files
>>>> in one directory together with the project type system the files can be
>>>> loaded by UIMA. Though
>>>> it has be criticized for not allowing sub directories for structuring
>>>> its documents.
>>>>
>>>> Jörn
>>>>
>>>>
>>> That's perfectly fine, we do this in a similar way.
>>> What would be good though is to distinguish between
>>> text documents and "CAS documents" (be they XCAS, XMI
>>> or some other format). So you could start your work
>>> by importing some text documents, then annotate them
>>> in various ways (manually, or with coded annotators).
>>> The CASes would reside in a different folder, and you
>>> could derive any number of CAS collections from the
>>> same set of source text documents. We find that way
>>> of working very convenient.
>>>
>> We could reuse the code which is in the Cas Editor right
>> now and move it into a new plugin which provides the document
>> collections and type system to other plugins.
>>
>> The Cas Editor should be independent of the project model because
>> people who use the Cas Editor do not necessarily want to it.
>>
>
> +1, couldn't agree more. In fact, I would like to integrate
> the CAS editor into our tooling, that would be a good test
> case how independent it is. I don't know when I'll get around
> to playing with that, but it's definitely on my to do list.
>
Ok, then lets split the Cas Editor into the editing part and project
model. For the project model part we have to create a new eclipse
project, e.g. uimaj-ep-base. The remaining Cas Editor should be independent
of the project model which means uimaj-ep-base depends on the Cas Editor
(to add the
document provider extension to it).
After we are done with that, we can look into uimaj-ep-base and see how
it fits our needs
and how it can be used by the other eclipse based tooling.
Jörn
Re: Document collections [was: Re: Building the eclipse update site]
Posted by Thilo Goetz <tw...@gmx.de>.
Jörn Kottmann wrote:
> Thilo Goetz wrote:
>> Jörn Kottmann wrote:
>>
>>> Jörn Kottmann wrote:
>>>
>>>>> A collection of text documents that you can run
>>>>> analysis on. If I understand correctly, the Cas
>>>>> Editor currently requires XCAS/XmiCAS files. It
>>>>> would be nice if users could just add their text
>>>>> files and then either create annotations manually
>>>>> with the Cas Editor, or automatically by running
>>>>> some analysis and then view the results using the
>>>>> Cas Editor. Then we could add results comparison
>>>>> etc. See
>>>>> http://dl.alphaworks.ibm.com/technologies/tap/text_analysis_perspective.pdf
>>>>>
>>>>>
>>>>> for a (outdated) description of what we have
>>>>> in-house. It's geared more towards a business user
>>>>> than a developer, but the ideas of document collections
>>>>> and the development cycle are equally applicable.
>>>>> If there was enough interest here, I think that
>>>>> would be a good direction to go in.
>>>>>
>>>> Yes for me it sounds like the right way.
>>>> We could also use it for debugging an AE, then
>>>> a user defines a debug configuration and adds
>>>> the collection as document source.
>>>>
>>> How would you define the format of a document collection ?
>>>
>>> To open a CAS document the document itself and a type system
>>> for the document is needed.
>>>
>>> In the Cas Editor right now an Input Collection is a Corpus folder which
>>> contains xmi/xcas files
>>> in one directory together with the project type system the files can be
>>> loaded by UIMA. Though
>>> it has be criticized for not allowing sub directories for structuring
>>> its documents.
>>>
>>> Jörn
>>>
>>
>> That's perfectly fine, we do this in a similar way.
>> What would be good though is to distinguish between
>> text documents and "CAS documents" (be they XCAS, XMI
>> or some other format). So you could start your work
>> by importing some text documents, then annotate them
>> in various ways (manually, or with coded annotators).
>> The CASes would reside in a different folder, and you
>> could derive any number of CAS collections from the
>> same set of source text documents. We find that way
>> of working very convenient.
>
> We could reuse the code which is in the Cas Editor right
> now and move it into a new plugin which provides the document
> collections and type system to other plugins.
>
> The Cas Editor should be independent of the project model because
> people who use the Cas Editor do not necessarily want to it.
+1, couldn't agree more. In fact, I would like to integrate
the CAS editor into our tooling, that would be a good test
case how independent it is. I don't know when I'll get around
to playing with that, but it's definitely on my to do list.
--Thilo
>
> Jörn
Re: Document collections [was: Re: Building the eclipse update site]
Posted by Jörn Kottmann <ko...@gmail.com>.
Thilo Goetz wrote:
> Jörn Kottmann wrote:
>
>> Jörn Kottmann wrote:
>>
>>>> A collection of text documents that you can run
>>>> analysis on. If I understand correctly, the Cas
>>>> Editor currently requires XCAS/XmiCAS files. It
>>>> would be nice if users could just add their text
>>>> files and then either create annotations manually
>>>> with the Cas Editor, or automatically by running
>>>> some analysis and then view the results using the
>>>> Cas Editor. Then we could add results comparison
>>>> etc. See
>>>> http://dl.alphaworks.ibm.com/technologies/tap/text_analysis_perspective.pdf
>>>>
>>>> for a (outdated) description of what we have
>>>> in-house. It's geared more towards a business user
>>>> than a developer, but the ideas of document collections
>>>> and the development cycle are equally applicable.
>>>> If there was enough interest here, I think that
>>>> would be a good direction to go in.
>>>>
>>>>
>>> Yes for me it sounds like the right way.
>>> We could also use it for debugging an AE, then
>>> a user defines a debug configuration and adds
>>> the collection as document source.
>>>
>> How would you define the format of a document collection ?
>>
>> To open a CAS document the document itself and a type system
>> for the document is needed.
>>
>> In the Cas Editor right now an Input Collection is a Corpus folder which
>> contains xmi/xcas files
>> in one directory together with the project type system the files can be
>> loaded by UIMA. Though
>> it has be criticized for not allowing sub directories for structuring
>> its documents.
>>
>> Jörn
>>
>
> That's perfectly fine, we do this in a similar way.
> What would be good though is to distinguish between
> text documents and "CAS documents" (be they XCAS, XMI
> or some other format). So you could start your work
> by importing some text documents, then annotate them
> in various ways (manually, or with coded annotators).
> The CASes would reside in a different folder, and you
> could derive any number of CAS collections from the
> same set of source text documents. We find that way
> of working very convenient.
We could reuse the code which is in the Cas Editor right
now and move it into a new plugin which provides the document
collections and type system to other plugins.
The Cas Editor should be independent of the project model because
people who use the Cas Editor do not necessarily want to it.
Jörn
Document collections [was: Re: Building the eclipse update site]
Posted by Thilo Goetz <tw...@gmx.de>.
Jörn Kottmann wrote:
> Jörn Kottmann wrote:
>>
>>> A collection of text documents that you can run
>>> analysis on. If I understand correctly, the Cas
>>> Editor currently requires XCAS/XmiCAS files. It
>>> would be nice if users could just add their text
>>> files and then either create annotations manually
>>> with the Cas Editor, or automatically by running
>>> some analysis and then view the results using the
>>> Cas Editor. Then we could add results comparison
>>> etc. See
>>> http://dl.alphaworks.ibm.com/technologies/tap/text_analysis_perspective.pdf
>>>
>>> for a (outdated) description of what we have
>>> in-house. It's geared more towards a business user
>>> than a developer, but the ideas of document collections
>>> and the development cycle are equally applicable.
>>> If there was enough interest here, I think that
>>> would be a good direction to go in.
>>>
>> Yes for me it sounds like the right way.
>> We could also use it for debugging an AE, then
>> a user defines a debug configuration and adds
>> the collection as document source.
> How would you define the format of a document collection ?
>
> To open a CAS document the document itself and a type system
> for the document is needed.
>
> In the Cas Editor right now an Input Collection is a Corpus folder which
> contains xmi/xcas files
> in one directory together with the project type system the files can be
> loaded by UIMA. Though
> it has be criticized for not allowing sub directories for structuring
> its documents.
>
> Jörn
That's perfectly fine, we do this in a similar way.
What would be good though is to distinguish between
text documents and "CAS documents" (be they XCAS, XMI
or some other format). So you could start your work
by importing some text documents, then annotate them
in various ways (manually, or with coded annotators).
The CASes would reside in a different folder, and you
could derive any number of CAS collections from the
same set of source text documents. We find that way
of working very convenient.
--Thilo
Re: Building the eclipse update site
Posted by Jörn Kottmann <ko...@gmail.com>.
Jörn Kottmann wrote:
>
>> A collection of text documents that you can run
>> analysis on. If I understand correctly, the Cas
>> Editor currently requires XCAS/XmiCAS files. It
>> would be nice if users could just add their text
>> files and then either create annotations manually
>> with the Cas Editor, or automatically by running
>> some analysis and then view the results using the
>> Cas Editor. Then we could add results comparison
>> etc. See
>> http://dl.alphaworks.ibm.com/technologies/tap/text_analysis_perspective.pdf
>>
>> for a (outdated) description of what we have
>> in-house. It's geared more towards a business user
>> than a developer, but the ideas of document collections
>> and the development cycle are equally applicable.
>> If there was enough interest here, I think that
>> would be a good direction to go in.
>>
> Yes for me it sounds like the right way.
> We could also use it for debugging an AE, then
> a user defines a debug configuration and adds
> the collection as document source.
How would you define the format of a document collection ?
To open a CAS document the document itself and a type system
for the document is needed.
In the Cas Editor right now an Input Collection is a Corpus folder which
contains xmi/xcas files
in one directory together with the project type system the files can be
loaded by UIMA. Though
it has be criticized for not allowing sub directories for structuring
its documents.
Jörn
Re: Building the eclipse update site
Posted by Jörn Kottmann <ko...@gmail.com>.
> A collection of text documents that you can run
> analysis on. If I understand correctly, the Cas
> Editor currently requires XCAS/XmiCAS files. It
> would be nice if users could just add their text
> files and then either create annotations manually
> with the Cas Editor, or automatically by running
> some analysis and then view the results using the
> Cas Editor. Then we could add results comparison
> etc. See
> http://dl.alphaworks.ibm.com/technologies/tap/text_analysis_perspective.pdf
> for a (outdated) description of what we have
> in-house. It's geared more towards a business user
> than a developer, but the ideas of document collections
> and the development cycle are equally applicable.
> If there was enough interest here, I think that
> would be a good direction to go in.
>
Yes for me it sounds like the right way.
We could also use it for debugging an AE, then
a user defines a debug configuration and adds
the collection as document source.
Jörn
Re: Building the eclipse update site
Posted by Thilo Goetz <tw...@gmx.de>.
Jörn Kottmann wrote:
>
>>> The project model of the Cas Editor does not really fit what we
>>> need now in my opinion. We have to rework that.
>>> It was made for the RCP Cas Editor version, but now the Cas Editor
>>> is more like a tool which just shows/edits CAS files.
>>>
>>> We could try to make a general model where a user configures a type
>>> system
>>> per project and use that in all our plugins. This would lead to a
>>> simplification
>>> of the Cas Editor and the removal of some (legacy) features.
>>>
>>
>> Then add a notion of input document collection, and a
>> way to launch UIMA processing like in CVD, and we can
>> get rid of the Swing based tooling altogether.
>>
> Can you please elaborate on what you mean with input document collection ?
A collection of text documents that you can run
analysis on. If I understand correctly, the Cas
Editor currently requires XCAS/XmiCAS files. It
would be nice if users could just add their text
files and then either create annotations manually
with the Cas Editor, or automatically by running
some analysis and then view the results using the
Cas Editor. Then we could add results comparison
etc. See
http://dl.alphaworks.ibm.com/technologies/tap/text_analysis_perspective.pdf
for a (outdated) description of what we have
in-house. It's geared more towards a business user
than a developer, but the ideas of document collections
and the development cycle are equally applicable.
If there was enough interest here, I think that
would be a good direction to go in.
--Thilo
>
> Jörn
Re: Building the eclipse update site
Posted by Jörn Kottmann <ko...@gmail.com>.
>> The project model of the Cas Editor does not really fit what we
>> need now in my opinion. We have to rework that.
>> It was made for the RCP Cas Editor version, but now the Cas Editor
>> is more like a tool which just shows/edits CAS files.
>>
>> We could try to make a general model where a user configures a type system
>> per project and use that in all our plugins. This would lead to a
>> simplification
>> of the Cas Editor and the removal of some (legacy) features.
>>
>
> Then add a notion of input document collection, and a
> way to launch UIMA processing like in CVD, and we can
> get rid of the Swing based tooling altogether.
>
Can you please elaborate on what you mean with input document collection ?
Jörn
Re: Building the eclipse update site
Posted by Thilo Goetz <tw...@gmx.de>.
Jörn Kottmann wrote:
> Thilo Goetz wrote:
>>
>> I was able to successfully build the update site and install
>> into Eclipse 3.5. I tested the CDE and JCasGen, seems to work
>> fine. Joern, what's a good way to quickly test the CAS Editor?
>>
>>
>
> Create a "NLP" project and add a type system to it,
> create a folder and add it as corpus folder under project
> properties. Now you can copy a xcas/xmi file into the corpus
> folder or use the NLP/Document wizard to import a txt or rtf file.
Works!
>
> The project model of the Cas Editor does not really fit what we
> need now in my opinion. We have to rework that.
> It was made for the RCP Cas Editor version, but now the Cas Editor
> is more like a tool which just shows/edits CAS files.
>
> We could try to make a general model where a user configures a type system
> per project and use that in all our plugins. This would lead to a
> simplification
> of the Cas Editor and the removal of some (legacy) features.
Then add a notion of input document collection, and a
way to launch UIMA processing like in CVD, and we can
get rid of the Swing based tooling altogether.
>
>> To make this work, I had to do the following:
>>
>> - Manually copy the CAS Editor plugin jar from where it's built
>> to the update site's plugin directory. All other plugin jars
>> are copied there automatically.
>>
> When I tested I had to copy all plugin jars manually.
You're right. I must not have cleaned up properly.
--Thilo
>
> Jörn
Re: Building the eclipse update site
Posted by Jörn Kottmann <ko...@gmail.com>.
Thilo Goetz wrote:
>
> I was able to successfully build the update site and install
> into Eclipse 3.5. I tested the CDE and JCasGen, seems to work
> fine. Joern, what's a good way to quickly test the CAS Editor?
>
>
Create a "NLP" project and add a type system to it,
create a folder and add it as corpus folder under project
properties. Now you can copy a xcas/xmi file into the corpus
folder or use the NLP/Document wizard to import a txt or rtf file.
The project model of the Cas Editor does not really fit what we
need now in my opinion. We have to rework that.
It was made for the RCP Cas Editor version, but now the Cas Editor
is more like a tool which just shows/edits CAS files.
We could try to make a general model where a user configures a type system
per project and use that in all our plugins. This would lead to a
simplification
of the Cas Editor and the removal of some (legacy) features.
> To make this work, I had to do the following:
>
> - Manually copy the CAS Editor plugin jar from where it's built
> to the update site's plugin directory. All other plugin jars
> are copied there automatically.
>
When I tested I had to copy all plugin jars manually.
Jörn
Re: Building the eclipse update site
Posted by Thilo Goetz <tw...@gmx.de>.
Marshall Schor wrote:
> I don't believe the UIMA-AS target is called, unless you call it
> explicitly. Can you say a bit more why you needed to remove it?
True. I meant this:
<target name="build-features" depends="init">
<makeFeatureJar project-name="uimaj-eclipse-feature-deployeditor"
org-name="org.apache.uima.deployeditor"
version="2.3.0.incubating-SNAPSHOT"/>
<makeFeatureJar project-name="uimaj-eclipse-feature-runtime"
org-name="org.apache.uima.runtime"
version="2.3.0.incubating-SNAPSHOT"/>
<makeFeatureJar project-name="uimaj-eclipse-feature-tools"
org-name="org.apache.uima.tools"
version="2.3.0.incubating-SNAPSHOT"/>
</target>
The uimaj-eclipse-feature-deployeditor is not there, so the
build-features target fails.
--Thilo
>
> -Marshall
>
> Thilo Goetz wrote:
>> Marshall Schor wrote:
>>
>>> At this point, the build procedure is:
>>>
>>> 1) run the build.xml in the uimaj-eclipse-update-site project with the
>>> target set to build-features. You can do this in Eclipse by right
>>> clicking the build.xml file and picking Run-As Ant-build ...
>>>
>>> 2) copy the features built here into the same project's top level
>>> features folder
>>>
>>> 3) run the build.xml with the "all" target to build the updatesite
>>>
>>> The reason for this convolution: as I recall, this was done to provide
>>> some committer-intentional action when putting things into the top level
>>> features folder - things put there should be release-approved things
>>> that have been voted out (of course, excepting all this "testing").
>>> This I think is why we want a better build method that builds the
>>> feature jars - so they can be part of the set of files reviewed and
>>> voted on for the release.
>>>
>>> Still not working (for reasons I have no idea) - the update site seems
>>> to have the cas editor jar, but there is no plugin installed for it.
>>>
>>> It would be good to have another pair of eyes look at this - maybe
>>> there's some misspelling somewhere...
>>>
>>> -Marshall
>>>
>>>
>> I was able to successfully build the update site and install
>> into Eclipse 3.5. I tested the CDE and JCasGen, seems to work
>> fine. Joern, what's a good way to quickly test the CAS Editor?
>>
>> To make this work, I had to do the following:
>>
>> - Manually copy the CAS Editor plugin jar from where it's built
>> to the update site's plugin directory. All other plugin jars
>> are copied there automatically.
>>
>> - Remove the UIMA-AS target.
>>
>> After that it worked like a charm.
>>
>> --Thilo
>>
>>
>>
Re: Building the eclipse update site
Posted by Marshall Schor <ms...@schor.com>.
I don't believe the UIMA-AS target is called, unless you call it
explicitly. Can you say a bit more why you needed to remove it?
-Marshall
Thilo Goetz wrote:
> Marshall Schor wrote:
>
>> At this point, the build procedure is:
>>
>> 1) run the build.xml in the uimaj-eclipse-update-site project with the
>> target set to build-features. You can do this in Eclipse by right
>> clicking the build.xml file and picking Run-As Ant-build ...
>>
>> 2) copy the features built here into the same project's top level
>> features folder
>>
>> 3) run the build.xml with the "all" target to build the updatesite
>>
>> The reason for this convolution: as I recall, this was done to provide
>> some committer-intentional action when putting things into the top level
>> features folder - things put there should be release-approved things
>> that have been voted out (of course, excepting all this "testing").
>> This I think is why we want a better build method that builds the
>> feature jars - so they can be part of the set of files reviewed and
>> voted on for the release.
>>
>> Still not working (for reasons I have no idea) - the update site seems
>> to have the cas editor jar, but there is no plugin installed for it.
>>
>> It would be good to have another pair of eyes look at this - maybe
>> there's some misspelling somewhere...
>>
>> -Marshall
>>
>>
>
> I was able to successfully build the update site and install
> into Eclipse 3.5. I tested the CDE and JCasGen, seems to work
> fine. Joern, what's a good way to quickly test the CAS Editor?
>
> To make this work, I had to do the following:
>
> - Manually copy the CAS Editor plugin jar from where it's built
> to the update site's plugin directory. All other plugin jars
> are copied there automatically.
>
> - Remove the UIMA-AS target.
>
> After that it worked like a charm.
>
> --Thilo
>
>
>
Re: Building the eclipse update site
Posted by Thilo Goetz <tw...@gmx.de>.
Marshall Schor wrote:
> At this point, the build procedure is:
>
> 1) run the build.xml in the uimaj-eclipse-update-site project with the
> target set to build-features. You can do this in Eclipse by right
> clicking the build.xml file and picking Run-As Ant-build ...
>
> 2) copy the features built here into the same project's top level
> features folder
>
> 3) run the build.xml with the "all" target to build the updatesite
>
> The reason for this convolution: as I recall, this was done to provide
> some committer-intentional action when putting things into the top level
> features folder - things put there should be release-approved things
> that have been voted out (of course, excepting all this "testing").
> This I think is why we want a better build method that builds the
> feature jars - so they can be part of the set of files reviewed and
> voted on for the release.
>
> Still not working (for reasons I have no idea) - the update site seems
> to have the cas editor jar, but there is no plugin installed for it.
>
> It would be good to have another pair of eyes look at this - maybe
> there's some misspelling somewhere...
>
> -Marshall
>
I was able to successfully build the update site and install
into Eclipse 3.5. I tested the CDE and JCasGen, seems to work
fine. Joern, what's a good way to quickly test the CAS Editor?
To make this work, I had to do the following:
- Manually copy the CAS Editor plugin jar from where it's built
to the update site's plugin directory. All other plugin jars
are copied there automatically.
- Remove the UIMA-AS target.
After that it worked like a charm.
--Thilo
Re: Building the eclipse update site
Posted by Jörn Kottmann <ko...@gmail.com>.
> Still not working (for reasons I have no idea) - the update site seems
> to have the cas editor jar, but there is no plugin installed for it.
>
> It would be good to have another pair of eyes look at this - maybe
> there's some misspelling somewhere...
>
I followed the steps above to create the update site and
then deployed it into a local tomcat instance together with
the plugin jars in the plugin folder.
After the install into an eclipse 3.5 instance the Cas Editor
was installed and worked, I did not test the other plugins.
Jörn
Re: Building the eclipse update site
Posted by Thilo Goetz <tw...@gmx.de>.
Marshall Schor wrote:
> At this point, the build procedure is:
>
> 1) run the build.xml in the uimaj-eclipse-update-site project with the
> target set to build-features. You can do this in Eclipse by right
> clicking the build.xml file and picking Run-As Ant-build ...
>
> 2) copy the features built here into the same project's top level
> features folder
>
> 3) run the build.xml with the "all" target to build the updatesite
>
> The reason for this convolution: as I recall, this was done to provide
> some committer-intentional action when putting things into the top level
> features folder - things put there should be release-approved things
> that have been voted out (of course, excepting all this "testing").
> This I think is why we want a better build method that builds the
> feature jars - so they can be part of the set of files reviewed and
> voted on for the release.
I don't remember the history of this, but it seems to
me we can just create the update site, zip it up and
submit it for the release review just like the other
artifacts we create. People who want to try it out
can install directly from the zip file, eclipse had
support for this at least back in 3.4, if not earlier.
Anybody know of any reasons why we shouldn't do this?
--Thilo
>
> Still not working (for reasons I have no idea) - the update site seems
> to have the cas editor jar, but there is no plugin installed for it.
>
> It would be good to have another pair of eyes look at this - maybe
> there's some misspelling somewhere...
>
> -Marshall
>
Re: Building the eclipse update site
Posted by Marshall Schor <ms...@schor.com>.
I looked in the 3.4.2 Eclipse help, and found a page:
Java development user guide -> Reference -> Preferences ->Java -> Debug
-> Detail Formatters,
which showed a table which included a column for "default", but that
column is "blank". In other pages, it isn't...
So I think there may be no default.
-Marshall
P.S., There was a page for "heap walking". This is a new feature of
Java 6, which is supported by Eclispe now:
http://eclipse-debug.blogspot.com/2006/08/whole-lotta-instances.html
I've not used this myself (having just discovered it), but instead have
used it indirectly, when I used JMX to take a heap dump, and then used
jhat (comes with java 6) to diagnose what's taking lots of memory, by
following references backwards - you first use the histogram view of
jhat to find the big and/or frequent objects, then follow backwards to
see who's holding refs to these that shouldn't be...
Jörn Kottmann wrote:
> Marshall Schor wrote:
>> The debug plugin adds the capability for Eclipse to show structured
>> values in the debugger for UIMA objects.
>>
>> It is briefly described here:
>> http://incubator.apache.org/uima/downloads/releaseDocs/2.2.2-incubating/docs/html/tutorials_and_users_guides/tutorials_and_users_guides.html#ugr.tug.aae.viewing_UIMA_objects_in_eclipse_debugger
>>
>>
>> I've found it quite useful when looking at UIMA objects.
>>
>> Most people don't know it's there though ;-) so it could use some better
>> advertising.
>>
> Interesting.
>
> Do you know why the PREF_SHOW_DETAILS variables is set to INLINE_ALL ?
> What is the default ?
>
> Jörn
>
>
>
>
Re: Building the eclipse update site
Posted by Jörn Kottmann <ko...@gmail.com>.
Marshall Schor wrote:
> The debug plugin adds the capability for Eclipse to show structured
> values in the debugger for UIMA objects.
>
> It is briefly described here:
> http://incubator.apache.org/uima/downloads/releaseDocs/2.2.2-incubating/docs/html/tutorials_and_users_guides/tutorials_and_users_guides.html#ugr.tug.aae.viewing_UIMA_objects_in_eclipse_debugger
>
> I've found it quite useful when looking at UIMA objects.
>
> Most people don't know it's there though ;-) so it could use some better
> advertising.
>
Interesting.
Do you know why the PREF_SHOW_DETAILS variables is set to INLINE_ALL ?
What is the default ?
Jörn
Re: Building the eclipse update site
Posted by Marshall Schor <ms...@schor.com>.
The debug plugin adds the capability for Eclipse to show structured
values in the debugger for UIMA objects.
It is briefly described here:
http://incubator.apache.org/uima/downloads/releaseDocs/2.2.2-incubating/docs/html/tutorials_and_users_guides/tutorials_and_users_guides.html#ugr.tug.aae.viewing_UIMA_objects_in_eclipse_debugger
I've found it quite useful when looking at UIMA objects.
Most people don't know it's there though ;-) so it could use some better
advertising.
-Marshall
Jörn Kottmann wrote:
> I am wondering if it is a good idea to install the debug plugin over
> the update site.
>
> What is the purpose of this plugin ?
>
> Jörn
>
Re: Building the eclipse update site
Posted by Jörn Kottmann <ko...@gmail.com>.
I am wondering if it is a good idea to install the debug plugin over
the update site.
What is the purpose of this plugin ?
Jörn
Re: Building the eclipse update site
Posted by Marshall Schor <ms...@schor.com>.
At this point, the build procedure is:
1) run the build.xml in the uimaj-eclipse-update-site project with the
target set to build-features. You can do this in Eclipse by right
clicking the build.xml file and picking Run-As Ant-build ...
2) copy the features built here into the same project's top level
features folder
3) run the build.xml with the "all" target to build the updatesite
The reason for this convolution: as I recall, this was done to provide
some committer-intentional action when putting things into the top level
features folder - things put there should be release-approved things
that have been voted out (of course, excepting all this "testing").
This I think is why we want a better build method that builds the
feature jars - so they can be part of the set of files reviewed and
voted on for the release.
Still not working (for reasons I have no idea) - the update site seems
to have the cas editor jar, but there is no plugin installed for it.
It would be good to have another pair of eyes look at this - maybe
there's some misspelling somewhere...
-Marshall
Re: Building the eclipse update site
Posted by Jörn Kottmann <ko...@gmail.com>.
> I prefer simplicity, and would like the Cas Editor installed just like
> all the other tooling, when you install the tooling. Then it is ready
> if and when needed :-).
>
+1
Jörn
Re: Building the eclipse update site
Posted by Marshall Schor <ms...@schor.com>.
Jörn Kottmann wrote:
> Marshall Schor wrote:
>> After some extra thought - it seems to me that the caseditor might not
>> want to be a separate feature, but instead be included with the tools.
>>
>> So - I won't do another uimaj-eclipse-feature-caseditor project, but
>> rather update the existing uimaj-eclipse-feature-tools to include this
>> plugin.
>>
>> Let's discuss further, if you think it should be a separate feature.
>>
> What would be the advantage of having a separate feature
> for the Cas Editor ?
I don't see any advantage. (One tiny advantage - if one was not using
any of the other tooling, you could save the disk space of having the
jars available (note there is no memory used by uninvoked plugins).
>
> Most important for me is that the Cas Editor can be installed
> via the update site like our other plugins, but that is possible
> with both ways.
I prefer simplicity, and would like the Cas Editor installed just like
all the other tooling, when you install the tooling. Then it is ready
if and when needed :-).
-Marshall
>
> Jörn
>
>
>
>
Re: Building the eclipse update site
Posted by Jörn Kottmann <ko...@gmail.com>.
Marshall Schor wrote:
> After some extra thought - it seems to me that the caseditor might not
> want to be a separate feature, but instead be included with the tools.
>
> So - I won't do another uimaj-eclipse-feature-caseditor project, but
> rather update the existing uimaj-eclipse-feature-tools to include this
> plugin.
>
> Let's discuss further, if you think it should be a separate feature.
>
What would be the advantage of having a separate feature
for the Cas Editor ?
Most important for me is that the Cas Editor can be installed
via the update site like our other plugins, but that is possible
with both ways.
Jörn
Re: Building the eclipse update site
Posted by Marshall Schor <ms...@schor.com>.
After some extra thought - it seems to me that the caseditor might not
want to be a separate feature, but instead be included with the tools.
So - I won't do another uimaj-eclipse-feature-caseditor project, but
rather update the existing uimaj-eclipse-feature-tools to include this
plugin.
Let's discuss further, if you think it should be a separate feature.
-Marshall
Re: Building the eclipse update site
Posted by Marshall Schor <ms...@schor.com>.
Next - a workaround to build the feature jars for 2.3 version.
I modified the build.xml to include this, and ran it:
<!-- temp work-around for no feature jars being built - build them here
to use this, call this out as an explicit ant target to run -->
<target name="build-features" depends="init">
<makeFeatureJar project-name="uimaj-eclipse-feature-caseditor"
org-name="org.apache.uima.caseditor"
version="2.3.0.incubating-SNAPSHOT"/>
<makeFeatureJar project-name="uimaj-eclipse-feature-deployeditor"
org-name="org.apache.uima.deployeditor"
version="2.3.0.incubating-SNAPSHOT"/>
<makeFeatureJar project-name="uimaj-eclipse-feature-runtime"
org-name="org.apache.uima.runtime"
version="2.3.0.incubating-SNAPSHOT"/>
<makeFeatureJar project-name="uimaj-eclipse-feature-tools"
org-name="org.apache.uima.tools"
version="2.3.0.incubating-SNAPSHOT"/>
</target>
After I ran that target, I re-ran the main target ("all"), and it
reported building the site OK. Now to "test" it...
-Marshall
Re: Building the eclipse update site
Posted by Marshall Schor <ms...@schor.com>.
Agreeing with what Thilo found earlier: It appears that there is a 1/2
done change to the process regarding the feature jars. The result is
the build of the feature jars was taken out of the update site build.xml
script, but no build for this exists elsewhere. Hence, no feature jars
are being built (if this is wrong, please let me know :-) ). The
comments say this was moved back to the normal maven process, but as
Thilo has noted, this isn't true.
Investigating a bit more...
-Marshall
Re: Building the eclipse update site
Posted by Marshall Schor <ms...@schor.com>.
Well, there's more egg on my face :-)
The correction below is wrong - the version should be
2.3.0.incubation-SNAPSHOT
(I forgot the -SNAPSHOT).
With that fix, the update site actually built, and installed partially
successfully into Eclipse 3.5 (which I didn't even know had been
released). Partially - the CDE installed. However the cas editor did
not. Probably something amiss with my guesses for its configuration, or
more typos needing fixing.
So, more to do. I'll commit the changes so far, and update the website
build instructions, using the current work-around of running an extra
target to build the missing feature jars.
I'm sure that this build process can be improved :-) but now we'll at
least have some portion of a working start.
-Marshall
Marshall Schor wrote:
> ... Typo in the stanzas for feature, they had the attribute
> version="2.2.2.incubating" - should be
> 2.3.0.incubating-SNAPSHOT.
>
> <!-- keep old features listed here - to permit the update site to
> provide the older features -->
> <feature
> url="features/org.apache.uima.tools_2.3.0.incubating-SNAPSHOT.jar"
> id="org.apache.uima.tools" version="2.3.0.incubating">
> <category name="uima-tooling-and-runtimes"/>
> </feature>
> <feature
> url="features/org.apache.uima.runtime_2.3.0.incubating-SNAPSHOT.jar"
> id="org.apache.uima.runtime" version="2.3.0.incubating">
> <category name="uima-tooling-and-runtimes"/>
> </feature>
>
>> <feature
>> url="features/org.apache.uima.tools_2.3.0.incubating-SNAPSHOT.jar"
>> id="org.apache.uima.tools" version="2.2.2.incubating">
>> <category name="uima-tooling-and-runtimes"/>
>> </feature>
>> <feature
>> url="features/org.apache.uima.runtime_2.3.0.incubating-SNAPSHOT.jar"
>> id="org.apache.uima.runtime" version="2.2.2.incubating">
>> <category name="uima-tooling-and-runtimes"/>
>> </feature>
>>
>> After I added these, I get build errors. Investigating .. more to come...
>>
>> -Marshall
>>
>>
>>
>>
>>
>
>
>
Re: Building the eclipse update site
Posted by Marshall Schor <ms...@schor.com>.
... Typo in the stanzas for feature, they had the attribute
version="2.2.2.incubating" - should be
2.3.0.incubating-SNAPSHOT.
<!-- keep old features listed here - to permit the update site to
provide the older features -->
<feature
url="features/org.apache.uima.tools_2.3.0.incubating-SNAPSHOT.jar"
id="org.apache.uima.tools" version="2.3.0.incubating">
<category name="uima-tooling-and-runtimes"/>
</feature>
<feature
url="features/org.apache.uima.runtime_2.3.0.incubating-SNAPSHOT.jar"
id="org.apache.uima.runtime" version="2.3.0.incubating">
<category name="uima-tooling-and-runtimes"/>
</feature>
>
> <feature
> url="features/org.apache.uima.tools_2.3.0.incubating-SNAPSHOT.jar"
> id="org.apache.uima.tools" version="2.2.2.incubating">
> <category name="uima-tooling-and-runtimes"/>
> </feature>
> <feature
> url="features/org.apache.uima.runtime_2.3.0.incubating-SNAPSHOT.jar"
> id="org.apache.uima.runtime" version="2.2.2.incubating">
> <category name="uima-tooling-and-runtimes"/>
> </feature>
>
> After I added these, I get build errors. Investigating .. more to come...
>
> -Marshall
>
>
>
>
Re: Building the eclipse update site
Posted by Marshall Schor <ms...@schor.com>.
Thilo Goetz wrote:
> Marshall Schor wrote:
>
>> Thilo Goetz wrote:
>>
>>> ...
>>> I have tried looking into those issues, but I'm a
>>> little puzzled by our whole eclipse plugin setup.
>>> The plugins are done in a way that looks very odd
>>> to me, but that may just be my lack of experience.
>>> None of the plugins (except for the cas editor)
>>> has a proper manifest. They don't declare their
>>> dependencies, nor what they export. The dependency
>>> management seems to be done in the features, where
>>> it needs to be done by hand. Can anybody confirm
>>> or refute this?
>>>
>>>
>>>
>> The plugins are built by the org.apache.felix project's
>> maven-bundle-plugin. The doc for how this plugin works is here:
>> (Darn - apache.org is down, so I can't confirm these urls, but here they
>> are anyway)
>> http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
>> (type org.apache.felix maven bundle into google)
>>
>> What is supposed to happen is that the "instructions" in the maven
>> configuration create the manifest.
>>
>> If this isn't happening, then something's amiss with this process.
>>
>
> Marshall,
>
> at what stage of the build process is that supposed
> to happen?
>
It happens when you run the normal mvn install, either on the specific
plugin, or on one of the upper level POMs which includes the plugins as
subprojects.
I did find a significant omission in the instructions. After the normal
maven build process to produce the jars, and the manual copying of the
to-be-released versions of the jars to the uimaj-eclipse-update-site
project "plugins" folder, you need to edit the uimaj-eclipse-update-site
project's "site.xml" file, and "add" (don't modify) stanzas for the new
version. This means adding lines like:
<feature
url="features/org.apache.uima.tools_2.3.0.incubating-SNAPSHOT.jar"
id="org.apache.uima.tools" version="2.2.2.incubating">
<category name="uima-tooling-and-runtimes"/>
</feature>
<feature
url="features/org.apache.uima.runtime_2.3.0.incubating-SNAPSHOT.jar"
id="org.apache.uima.runtime" version="2.2.2.incubating">
<category name="uima-tooling-and-runtimes"/>
</feature>
After I added these, I get build errors. Investigating .. more to come...
-Marshall
Re: Building the eclipse update site
Posted by Thilo Goetz <tw...@gmx.de>.
Marshall Schor wrote:
>
> Thilo Goetz wrote:
>> ...
>> I have tried looking into those issues, but I'm a
>> little puzzled by our whole eclipse plugin setup.
>> The plugins are done in a way that looks very odd
>> to me, but that may just be my lack of experience.
>> None of the plugins (except for the cas editor)
>> has a proper manifest. They don't declare their
>> dependencies, nor what they export. The dependency
>> management seems to be done in the features, where
>> it needs to be done by hand. Can anybody confirm
>> or refute this?
>>
>>
> The plugins are built by the org.apache.felix project's
> maven-bundle-plugin. The doc for how this plugin works is here:
> (Darn - apache.org is down, so I can't confirm these urls, but here they
> are anyway)
> http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
> (type org.apache.felix maven bundle into google)
>
> What is supposed to happen is that the "instructions" in the maven
> configuration create the manifest.
>
> If this isn't happening, then something's amiss with this process.
Marshall,
at what stage of the build process is that supposed
to happen?
--Thilo
>
> I'll attempt to rebuild this and see what happens.
>
> -Marshall
Re: Building the eclipse update site
Posted by Jörn Kottmann <ko...@gmail.com>.
Marshall Schor wrote:
> Next issue:
>
> There is a new feature for 2.3.0, the caseditor. In the current build
> approach, each feature needs a separate "feature" project (Eclipse likes
> this organization). There was no uimaj-eclipse-feature-caseditor
> project, so I made one :-) and will check it in shortly.
>
> Meanwhile, there's some information I need to properly set up this
> project. Feature projects have a <requires> element that enables
> Eclipse to find and install other plugins this one depends on.
>
> The stanza is:
>
> <requires>
> <import plugin="org.apache.uima.runtime" version="2.3.0"
> match="greaterOrEqual"/>
> </requires>
>
> I took a guess that this plugin requires the runtime plugin. Is that
> correct? Does it require any others?
>
Yes that are the plugins it requires also:
org.eclipse.jface.text
org.eclipse.text
org.eclipse.ui.editors
org.eclipse.ui.workbench.texteditor
org.eclipse.ui.ide
org.eclipse.ui
org.eclipse.ui.workbench
org.eclipse.core.runtime
org.eclipse.core.resources
Jörn
Re: Building the eclipse update site
Posted by Marshall Schor <ms...@schor.com>.
Next issue:
There is a new feature for 2.3.0, the caseditor. In the current build
approach, each feature needs a separate "feature" project (Eclipse likes
this organization). There was no uimaj-eclipse-feature-caseditor
project, so I made one :-) and will check it in shortly.
Meanwhile, there's some information I need to properly set up this
project. Feature projects have a <requires> element that enables
Eclipse to find and install other plugins this one depends on.
The stanza is:
<requires>
<import plugin="org.apache.uima.runtime" version="2.3.0"
match="greaterOrEqual"/>
</requires>
I took a guess that this plugin requires the runtime plugin. Is that
correct? Does it require any others?
-Marshall
Re: Building the eclipse update site
Posted by Marshall Schor <ms...@schor.com>.
Thilo Goetz wrote:
> ...
> I have tried looking into those issues, but I'm a
> little puzzled by our whole eclipse plugin setup.
> The plugins are done in a way that looks very odd
> to me, but that may just be my lack of experience.
> None of the plugins (except for the cas editor)
> has a proper manifest. They don't declare their
> dependencies, nor what they export. The dependency
> management seems to be done in the features, where
> it needs to be done by hand. Can anybody confirm
> or refute this?
>
>
The plugins are built by the org.apache.felix project's
maven-bundle-plugin. The doc for how this plugin works is here:
(Darn - apache.org is down, so I can't confirm these urls, but here they
are anyway)
http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
(type org.apache.felix maven bundle into google)
What is supposed to happen is that the "instructions" in the maven
configuration create the manifest.
If this isn't happening, then something's amiss with this process.
I'll attempt to rebuild this and see what happens.
-Marshall
Re: Building the eclipse update site
Posted by Marshall Schor <ms...@schor.com>.
Sorry, I started looking at this, but got distracted by the July 4th
holiday ;-) Looking at it again, now... -Marshall
Thilo Goetz wrote:
> Thilo Goetz wrote:
>
>> Thilo Goetz wrote:
>>
>>> All,
>>>
>>> I was trying to follow up on Burn's comments on
>>> https://issues.apache.org/jira/browse/UIMA-1326
>>>
>>> So I tried to build the eclipse update site to
>>> be able to (easily) install our eclipse plugins.
>>> I tried to follow the instructions on our web
>>> site, but I was unable to find the feature jars
>>> I'm supposed to copy. Where are those supposed
>>> to end up at? Thanks.
>>>
>>> --Thilo
>>>
>> After some trial and error, I figured this out on
>> my own. The instructions are slightly wrong, as
>> the feature jars do not need to be copied, they
>> are actually generated during the ant build. What
>> also threw me was that the ant build was complaining
>> I should be setting up and using a *maven* profile
>> with an eclipse.home property set. I tried that,
>> and it didn't do anything for me, while simply
>> defining an ant property worked fine. So I'll be
>> fixing those instructions.
>>
>> --Thilo
>>
>
> I feel a little weird talking to myself here. If
> anybody has any advice for me, let me know...
>
> So I can build the eclipse update site, the features
> install into an eclipse, but they don't work. I
> get a bunch of errors, independent of the eclipse
> version. At first I thought I was using too new an
> eclipse, but I went from 3.5 via 3.4.2 back to 3.3,
> still the same problem. I'm not going to put the
> whole log file in this email, I don't see the point.
> I think I'm still doing something wrong with the
> update site build, but I have no idea what it is.
>
> I have tried looking into those issues, but I'm a
> little puzzled by our whole eclipse plugin setup.
> The plugins are done in a way that looks very odd
> to me, but that may just be my lack of experience.
> None of the plugins (except for the cas editor)
> has a proper manifest. They don't declare their
> dependencies, nor what they export. The dependency
> management seems to be done in the features, where
> it needs to be done by hand. Can anybody confirm
> or refute this?
>
> My understanding of how this should be done in eclipse
> is that the individual plugins maintain their
> dependencies in their manifest/plugin.xml. The
> dependency list of the feature is computed automatically
> from the dependencies of the plugins.
>
> Despite all this, I'm able to run our plugins from
> eclipse. Everything seems to be working normally.
> I get a small number of plugin-not-found warings at
> startup, and continuous JDOM warnings throughout,
> but that doesn't seem to affect functionality.
>
> So I'm back to my original question: how do I build
> the update site so the result actually works?
>
> --Thilo
>
>
>
Re: Building the eclipse update site
Posted by Thilo Goetz <tw...@gmx.de>.
Thilo Goetz wrote:
> Thilo Goetz wrote:
>> All,
>>
>> I was trying to follow up on Burn's comments on
>> https://issues.apache.org/jira/browse/UIMA-1326
>>
>> So I tried to build the eclipse update site to
>> be able to (easily) install our eclipse plugins.
>> I tried to follow the instructions on our web
>> site, but I was unable to find the feature jars
>> I'm supposed to copy. Where are those supposed
>> to end up at? Thanks.
>>
>> --Thilo
>
> After some trial and error, I figured this out on
> my own. The instructions are slightly wrong, as
> the feature jars do not need to be copied, they
> are actually generated during the ant build. What
> also threw me was that the ant build was complaining
> I should be setting up and using a *maven* profile
> with an eclipse.home property set. I tried that,
> and it didn't do anything for me, while simply
> defining an ant property worked fine. So I'll be
> fixing those instructions.
>
> --Thilo
I feel a little weird talking to myself here. If
anybody has any advice for me, let me know...
So I can build the eclipse update site, the features
install into an eclipse, but they don't work. I
get a bunch of errors, independent of the eclipse
version. At first I thought I was using too new an
eclipse, but I went from 3.5 via 3.4.2 back to 3.3,
still the same problem. I'm not going to put the
whole log file in this email, I don't see the point.
I think I'm still doing something wrong with the
update site build, but I have no idea what it is.
I have tried looking into those issues, but I'm a
little puzzled by our whole eclipse plugin setup.
The plugins are done in a way that looks very odd
to me, but that may just be my lack of experience.
None of the plugins (except for the cas editor)
has a proper manifest. They don't declare their
dependencies, nor what they export. The dependency
management seems to be done in the features, where
it needs to be done by hand. Can anybody confirm
or refute this?
My understanding of how this should be done in eclipse
is that the individual plugins maintain their
dependencies in their manifest/plugin.xml. The
dependency list of the feature is computed automatically
from the dependencies of the plugins.
Despite all this, I'm able to run our plugins from
eclipse. Everything seems to be working normally.
I get a small number of plugin-not-found warings at
startup, and continuous JDOM warnings throughout,
but that doesn't seem to affect functionality.
So I'm back to my original question: how do I build
the update site so the result actually works?
--Thilo
Re: Building the eclipse update site
Posted by Thilo Goetz <tw...@gmx.de>.
Thilo Goetz wrote:
> All,
>
> I was trying to follow up on Burn's comments on
> https://issues.apache.org/jira/browse/UIMA-1326
>
> So I tried to build the eclipse update site to
> be able to (easily) install our eclipse plugins.
> I tried to follow the instructions on our web
> site, but I was unable to find the feature jars
> I'm supposed to copy. Where are those supposed
> to end up at? Thanks.
>
> --Thilo
After some trial and error, I figured this out on
my own. The instructions are slightly wrong, as
the feature jars do not need to be copied, they
are actually generated during the ant build. What
also threw me was that the ant build was complaining
I should be setting up and using a *maven* profile
with an eclipse.home property set. I tried that,
and it didn't do anything for me, while simply
defining an ant property worked fine. So I'll be
fixing those instructions.
--Thilo