[
https://issues.apache.org/jira/browse/UIMA-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13531314#comment-13531314
]
Marshall Schor commented on UIMA-2523:
--------------------------------------
In uimaj, the "aggregate" projects are only there to allow cd'ing to them and
doing mvn install, mvn test, etc., on just that subpart. So, for instance, if
you're working on the docbooks, you might only want to compile all the
docbooks. If you're working on the eclipse plugins, you might only want to
rebuild those, etc.
For small projects, these are just extra structure without sufficient purpose,
and (I agree) should be omitted.
The reason for having a "parent-pom" locally within a project is that when it's
time to release, you may find you need some change to the build/parent-pom.
Without the local parent-pom in the project, you would
1) change the build/parent-pom. This has it's own release/version number.
2) test etc., that this didn't break other builds :-)
3) do a "release" candidate for the build/parent-pom
4) call for a [VOTE] to release that
5) publish the release
This is quite a bit of work. In contrast, having a local parent-pom lets you
put any change you may need as an "override" to the current build/parent-pom,
and release that as part of your release. That's the only reason for having a
local parent-pom. If you don't need this, you can just point your projects
directly to the build/parent-pom.
At this point, I agree with you to minimize confusion to current uima-fit users.
I agree with you about uimafit having its own trunk/tag/branches, because it
will make it easier when it comes out of the sandbox :-), and they are planned
to have their own release cycles.
I'll change it to that structure.
> 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
