generate descriptors for our components

[GoogleCodeExporter]

We aren't very consistent about providing descriptor files for our
components.  One example is that we have a ClassifierAnnotator.xml but no
SequentialClassifierAnnotator.xml (or any of the other components in that
package.)

Original issue reported on code.google.com by pvogren@gmail.com on 5 May 2009 at 7:55

[GoogleCodeExporter]

Per our recent conversation on the UIMA users list.  I think we should generate 
our
XML descriptor files rather than creating them manually.  To this end I have 
created
the class org.cleartk.DescriptorFiles for generating descriptor files.  I think 
we
should run this code is part of our build.  I am happy for all of our descriptor
files that currently exists scattered throughout our source code to disappear.  
And
for all generated descriptor files to be dumped into a single directory -e.g. 
"desc".  

What do you think?

Original comment by pvogren@gmail.com on 10 Jun 2009 at 10:26

• Changed title: generate descriptors for our components

[GoogleCodeExporter]

Yes, please remove all XML descriptor files. Everything should be generated from
org.cleartk.DescriptorFiles.

If we're planning on distributing the generated XML files, I think they should
probably still be in the src/ folder though so that they can be imported by 
name. I
mean, if we're still going to support XML descriptor files, we should support 
them in
a way that encourages best practices (importing them by name, not by location).

If we're not planning on distributing the XML files with the ClearTK jar, 
instead
requiring users who want them to run org.cleartk.DescriptorFiles, then I agree 
that a
desc/ folder makes more sense.

Original comment by steven.b...@gmail.com on 10 Jun 2009 at 11:38

[GoogleCodeExporter]

I made a fair bit of progress on this issue in recent days.  Here is a summary 
of the
changes:

- The updated UUTUC so that it now has two new annotation types
    - @SofaCapability - this specifies the input and output sofas for the AnalysisEngine
/ CollectionReader
    - @ConfigurationParameter - this specifies member variables are initialized from
configuration parameters from the UimaContext
- I added two new factory methods to UUTUC:
    - AnalysisEngineFactory.reflectPrimitiveDescription - creates an
AnalysisEngineDescription from the class definition using reflection
    - CollectionReaderFactory.reflectDescription
- I added new factory methods to ClearTKComponents which simplify calling the 
above
two methods for this project.
- worked on script that generates descriptor files -
org.cleartk.descriptor.GenerateDescriptorFiles.  Many of the descriptor files 
that
describe simple components can be generated with a single line of code that 
looks
like this:

        writeCollectionReader(Ace2005GoldReader.class, outputDirectory);
        writePrimitiveDescription(TreebankGoldAnnotator.class, outputDirectory);

Original comment by pvogren@gmail.com on 23 Jul 2009 at 3:29

[GoogleCodeExporter]

I have created a test for this issue
DescriptorCoverageTest.testNoDescriptorsInSrcMain which fails if there are 
descriptor
files in the src/main/java folder - the location of the remaining descriptor 
files
that were manually created.  I have commented out this test so that it does not
prevent us from packaging and deploying the toolkit project.  However, if you 
are
working on this issue, then you should uncomment this test and make sure it 
passes
before closing this issue.  

Original comment by pvogren@gmail.com on 27 Aug 2009 at 3:11

[GoogleCodeExporter]

Before closing this issue you should remove the following two tests:

org.cleartk.DescriptorCoverageTest.testImportByLocation()
org.cleartk.DescriptorCoverageTest.testSrcDescriptorsAreCoveredByTests()

in toolkit.

Original comment by pvogren@gmail.com on 16 Nov 2009 at 11:45

[GoogleCodeExporter]

this is done!

Original comment by pvogren@gmail.com on 16 Dec 2009 at 11:28

• Changed state: Fixed