uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: UIMA Addons 2.3.1 RC 2
Date Wed, 08 Jun 2011 13:37:32 GMT
ok, I think we should go ahead and set up this new folder in svn.  Do you want
to do it, or would you like me to do it?

-Marshall

On 6/8/2011 6:25 AM, Tommaso Teofili wrote:
> 2011/6/7 Marshall Schor <msa@schor.com>
>
>> Re: the assembly -
>>
>> The Apache default assembly (see
>>
>> http://repo1.maven.org/maven2/org/apache/apache/resources/apache-source-release-assembly-descriptor/1.0.3/
>> ) they don't use <moduleSets> - they just use one file set and zip up
>> whatever
>> is exported from SVN.
>>
>> I think this would make sense for us, and solve this "flattening" issue
>> that
>> happens when using moduleSets.
>>
>> But it has one issue:  it packages up everything in the svn export.  So
>> this
>> would include those things we're not releasing.
>>
>> Two ways to fix this:
>>
>> 1) do that little bit of SVN reorg - create another "top level" SVN point
>> for
>> the addons, and move just those projects we're releasing from sandbox, to
>> that.
>>
>> 2) Use the ability of the assembly descriptor configuration to have
>> includes/excludes, and use those to subset the export to just what we need.
>>  I
>> think this is more error-prone, though, and involves doing a special step
>> when
>> release "tags" the project - you have to go into the tag and delete the
>> things
>> not being released.
>>
>> So I think approach 1) is better.
>>
> +1 I think this is the way to go also to avoid confusion between what is an
> established addon and what is under development in the sandbox.
> Tommaso
>
>
>> -Marshall
>>
>> On 6/6/2011 5:09 PM, Marshall Schor wrote:
>>> On 6/6/2011 12:21 PM, Tommaso Teofili wrote:
>>>> Hello Marshall,
>>>>
>>>> 2011/6/6 Marshall Schor <msa@schor.com>
>>>>
>>>>> I svn "exported" the tag, and diff'ed it to the source-release.
>>>>>
>>>>> There are a few differences; although they are not required to be the
>> same,
>>>>> it's
>>>>> simpler if they are (mostly).  This is because otherwise we have to
>>>>> carefully
>>>>> check and confirm that each thing which isn't the same, is OK.  Here's
>> a
>>>>> list of
>>>>> the differences I found.
>>>>>
>>>>> 1) The SVN is organized differently for the osgi components - they are
>>>>> subdirectories in the addons-osgi-runtime folder, but in the source
>>>>> release,
>>>>> they appear at the top level.  Does the default behavior of the
>>>>> source-assembly
>>>>> change this nesting to a "flat" structure, or are we overriding the
>> default
>>>>> somehow?
>>>>>
>>>> I didn't make any special configuration to do that so I assume it to be
>> the
>>>> default behavior.
>>> I took a quick look - the default assembly for source-release is using
>> the
>>> <moduleSet> technique to include all the sources.   There is one
>> <moduleSet> -
>>> and this would lose any hierarchy that may be present in how the files
>> are
>>> stored in SVN.
>>>
>>> Since the layout is different, the build-from-sources (using the
>> source-release)
>>> will fail I think.  (It already fails, but this is due to the
>>> AlchemyApiAnnotator not being found (due to renaming).
>>>
>>> I think this might be fixable by overriding - to have two <moduleSets>
-
>> one for
>>> everything that's going under addons-osgi-runtime folder, and another one
>> for
>>> all the rest.  Each would have its own <outputDirectory> to direct the
>> files to
>>> the right spot.  You can see the default descriptor being used that you
>> would
>>> need to override, in
>>>
>> build/uima-build-resources/src/main/resources/assemblies/multimodule-source-release.xml.
>>>
>>>>> 2) The alchemy-annotator is named two different ways:  in the
>>>>> source-release it
>>>>> is called "alchemy-annotator", but in the SVN export it is called
>>>>> "AlchemyAPIAnnotator"
>>>>>
>>>> I think this depends on the artifactId which is "alchemy-annotator" but
>> the
>>>> directory is called AlchemyAPIAnnotator, I wasn't sure about how to
>> handle
>>>> it as the "alchemy-annotator" artifactId came from the previous donated
>>>> project; however I  think it'd be good to change it to
>> AlchemyAPIAnnotator.
>>> +1, because it has to match for the build-from sources to work, I think.
>>>
>>> -Marshall
>>>

Mime
View raw message