[
https://issues.apache.org/jira/browse/UIMA-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13531232#comment-13531232
]
Richard Eckart de Castilho commented on UIMA-2523:
--------------------------------------------------
I understand the benefit in the UIMA super-pom (in build/parent-pom). I'm
afraid, I do not understand the benefit of having a hierarchical Maven
structure in which the "parent-pom" and the "aggregate-pom" are sub-module,
like in uimaj and uima-as. I believe you tried to explain the concept above,
but I don't get it. The "aggregate-pom" is pretty much empty except for the
modules which could just as well be in the uimaj pom. The "parent-pom" also
contains very little information which could also just as well be in the uimaj
pom. I have the impression that both, the "parent-pom" and "aggregate-pom" are
still artifacts from the time when uimaj had a flat project structure. In which
way does this setup facilitate maintenance?
Right now would feel most comfortable just leaving the module structure as is,
except changing the parent pom of uimafit-parent to org.apache.uima:parent-pom
in the near future.
If you wish to harmonize with the other UIMA sub-projects, I would suggest as a
compromise to:
* rename *uimafit* to *uimafit-core* and *uimafit-parent* to *uimafit*.
Although, I believe, that users may be confused by the move and I can already
imagine many adding "uimafit" (the pom version) to their dependencies, in
particular because in the past the jar version has had that name.
* going without an extra uimafit-parent artifact. So far, personally, I see no
benefit in introducing yet another "uimafit-parent" pom.
In our old subversion, we had the "uimafit-parent" POM directly in the trunk
folder.
To be in line with UIMAJ, UIMA AS, it seems we would have to use such a
structure and naming convention:
{noformat}
sandbox
trunk
uimafit
uimaj-fit-core
uimaj-fit-spring
uimaj-fit-examples
{noformat}
I have to admit though, I find that quite ugly. I would prefer uimaFIT (and
btw. also TextMarker) getting their own trunk/tags/branches folders. Then we
could just stick to the existing module structure. There would still be a name
duplication in the svn (see two time "uimafit" below), but the upper one would
not contain any artifacts, just be used as an organizational folder.
{noformat}
sandbox
uimafit
tags
branches
trunk (artifactId: uimafit-parent)
uimafit (artifactId: uimafit)
uimafit-spring (artifactId: uimafit-spring)
uimafit-examples (artifactId: uimafit-examples)
{noformat}
Since we agreed that uimaFIT and TextMarker can maintain independent release
cycles, it seems sensible to me that they get their own svn structures.
> Rename module folders
> ---------------------
>
> Key: UIMA-2523
> URL: https://issues.apache.org/jira/browse/UIMA-2523
> Project: UIMA
> Issue Type: Bug
> Components: Sandbox-uimafit
> Reporter: Richard Eckart de Castilho
> Priority: Minor
>
> The module folders in uimaFIT do not match the artifactIds. The module
> folders use the capitalization "uimaFIT" while the artifactIds use "uimafit".
> The folders should be renamed to use the lower-case variant and the module
> section of the aggregator POM should be adjusted accordingly.
> The currently different capitalization might cause problems in Eclipse when
> patches are applied, as Eclipse uses the artifactId as the project name and
> consequently workspace locations have different names than their respective
> directories on the file system (cf. UIMA-2522).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
