Marshall Schor wrote: > I'm thinking about some re-org of our SVN layout based on these > observations > > -We're getting a lot of components. Many of these are on somewhat > different release cycles. > > -We initially had a "main" node, a cpp node, a site note and a sandbox > node. The sandbox was for new-ish things. As some of these things get > more "mainline" - it would make sense to have them perhaps under another > node to indicate that. The idea would be that things in the sandbox > were user-beware, but things in this other node were more "dependable" > and "proven". > Possible names for this other node might be: "parts". Or we might want > to have several names that categorized the kinds of things - such as > "annotators", "servers", "embeddings", "corpora", "typeSystems", > "tools", etc. > > -The SVN conventions lean toward having branches and tags which are one > level above the thing being released. Right now, for sandbox projects, > these are 2 levels above the released thing. I think that, going > forward, it would be better to go with the convention, following the > convention-over-configuration philosophy, because the components are not > likely to all be released on the same release cycle (although that would > be a nice "goal" - like Eclipse does with it's many-part major releases). > > Other opinions? > > -Marshall > > +1 for having an organization structure based on component type such as tools, UIMA core, annotators, etc. But if we change the structure we should also move the current tools we ship with the UIMA core bundle to have one place where the user gets tools for UIMA.
The separation of UIMA core, tools, annotators also has disadvantage. We never come to the point to have a rich UIMA framework download where some real analytics are embedded and work out of the box. If we want to do that we have to think about a special "analytics package" where some pre-configured analysis is included with a special set of descriptors. -- Michael
