2011/6/7 Marshall Schor <[email protected]> > 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 <[email protected]> > >> > >>> 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 > > >
