uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard Eckart de Castilho (JIRA)" <...@uima.apache.org>
Subject [jira] [Commented] (UIMA-2523) Rename module folders
Date Thu, 13 Dec 2012 17:44:13 GMT

    [ 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

* 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


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.

    trunk              (artifactId: uimafit-parent)
      uimafit          (artifactId: uimafit)
      uimafit-spring   (artifactId: uimafit-spring)
      uimafit-examples (artifactId: uimafit-examples)

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

View raw message