THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
This is a proposed redesign of the layout in SVN and the way we use Maven, to enable broader use of standard tooling and approaches for development and release.
As the new design takes shape over time, it will be documented here:
Maven use design as top level project
This redesign could be part of our move to a TLP (top level project), assuming we graduate 
.
...
- Non Hierarchical POM layout (flat layout) causing problems
- Release plugin doesn't work
- may be fixed in latest version of Release Plugin
- Assembly plugin "modules" doesn't work
- because it requires the aggregator pom to be in the parent directory of the modules, I think
- m2eclipse works nicely with hierarchical layout
- prototyped this already, and can make things work with hierarchical directory layout
- Simple things like checking out all of uima - uimaj, uima-as, sandbox, (uimacpp - work on this later) from SVN with one export, and then being able to build, doesn't work
- Current extract & build requires copying over / merging separate SVN checkouts
- Release plugin doesn't work
...
Currently the website is maintained completely manually. More standards could enable automatic creation of various developer reports, updating the download page as part of the release process, etc.
Design
Principles:
- top level in svn tree:
- (same) uima - overall top
- (same) uimaj - java sdk for framework
- (same) uimacpp - cpp for framework
- (same) uima-as - uima addon for asynch scaleout
- (same) sandbox - for developing things, not all released, not necessarily well documented, etc.
- (same) site
- (same) uima - overall top
- new top level things:
- under uima
- (no)internal-tools - things not in normal binary distributions, but used in building, etc. Reason for not doing: not needed, reduce change. Instead, change rest of build to pull these when needed as mvn dependencies.
- super-poms - non-aggregate poms in the super-pom hierarchy
- each individual pom under this would be in a directory (flat organization) named to indicate role of the pom.
- (maybe later?) annotators - released and more fully documented/supported annotators from the sandbox (called out because of importance)
- (maybe later?) add-ons - released and more fully documented/ supported add-ons, such as simple-server
- under uima
Each of these (other than site) are "releasable" and have trunk/branch/tag nodes.
Some of these have individually releasable parts (e.g., each pom in super-poms, each annotator in annotators), while others are multi-module projects (like uimaj).
It should be possible (he said bravely) to do releases of parts individually, even when the trunk/tag/branch is at a higher level. For doing this, let's follow a convention, of naming the tag with a name-part starting with the releasable-part name.
- For example, with sandbox/trunk/projXyz the tag would be sandbox/tags/projXyz-version-number-etc
- see what the convention is for maven "release" plugin and follow that?
- To give a counter-example, what we're not doing is something like
- (not doing) sandbox/projXyz/trunk
- (not doing) sandbox/projXyz/tags/version-number-etc ...
After thinking that redesigning svn layout was important, I now think that's not the case, but what is important is to change how the build works, as follows:
- make each component independently buildable
- This is the main "fix". There are several things in the current build that violate this.
- We have a custom docbook build - that uses a "checked-out" docbook tool project, that currently has to be in a certain directory hierarchy relationship with the project being built. This is fixable by no longer using our own docbook tooling, and instead using the recently developed docbkx maven plugin.
- We also have dependencies on parent POMs. This can be fixed by making those dependencies use poms in the maven repository (or the local repository). This requires that any updates to these POMs be put in either the local repo or separately "released".
- I've noticed that many projects have moved to this style, and name their parent poms with release numbers like "1", "2", etc. For instance, the common Apache "parent" pom is at release "7".
- It would be good to reduce POM changes in parent poms by isolating the POMs to particular functions. For instance, we currently often mix up the "aggregator" pom function (<modules>) with being a parent. The aggregator will change with every release - it will include particular items at particular levels for the release, while the parent poms will likely change less often.
- We also have dependencies on particular files, such as common license / notice files. These kinds of common resources are now being handled by the maven remote-dependency plugin. The Apache Parent POM does this, for instance, and we can move to using this same style of dependency, to remove any requirement for particular checkout hierarchy.
- This is the main "fix". There are several things in the current build that violate this.
Because of this, I don't think that any change is required in the current svn tree; we can use other use cases to motivate incremental changes to the svn tree structure, as needed.
- One possible change is to create a new top level svn node holding non-released tooling (e.g., the projects uimaj-internal-tools and uimaj-jet-expander) - and move these there. This will enable source releases to be just the zipped up sources of the svn checkout (after maybe moving some license & notice files around as needed).
- a new top level svn node called "build" has been created, and holds build-related things such as maven parent poms, resources needed by the build processes, etc.
- separate "aggregate" and "super" poms
- for super poms - put in containing super-poms project
- for aggregate poms - just leave in flat organization - tools should now support this
- scm element in pom needs to point to where this pom is, in the svn tree (to make releasing conventional)
- change relative links in pom structure to assume the layout that m2eclipse would create
- m2eclipse, when you say to Eclipse->import, say uimaj/trunk into workspace, checks out trunk as a uniquely name folder in the workspace, and then "imports" from there. If another trunk is imported, say, sandbox/trunk, into the workspace, then m2eclipse checks out that trunk under another uniquely named folder in the workspace.
- Therefore, our convention for locating relative things (if we don't get them using repository dependencies) will be
No Format