uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tommaso Teofili <tommaso.teof...@gmail.com>
Subject Re: UIMA Addons 2.3.1 RC 2
Date Wed, 08 Jun 2011 10:25:51 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message