You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2010/11/18 16:26:46 UTC
Next "improvement" to UIMA build approach
The current build approach has some issues. A major one is that the trunk is
not currently buildable (because uimaj projects have a parent pom dependency at
version 1 which is only in the staging area, and not really released yet).
After some iterations and discussions with colleagues, here's the next
"improvement" which I think will fix these problems. The main idea is to make
the "main" aggregator project for each multi-module build (e.g., the "uimaj"
project for the uimaj SDK) also be a parent-pom for all those modules in the
multi-module build, as is conventional Maven practice.
We would still keep the build tooling overall parent-pom, but would decouple
releases of that from releases of things that use it. So, for instance, we
would release parent-pom, version 1, and then when we found "issues" in it while
trying to release the uimaj project, we would address those issues by making
changes in the uimaj's pom (overriding if needed the parent-pom-1). At some
arbitrary time in the future, we could "promote" any changes that were done that
ought to be shared with other projects to the common build parent-pom. A key
point here is that this promotion and subsequent release of the project-wide
parent pom would be completely decoupled from the release of the uimaj project.
Some scenarios, assuming we've voted and released the parent-pom tooling.
1) scenario: checkout uimaj trunk or tag, and build it:
svn co https://svn.apache.org/repos/asf/uima/uimaj/trunk (or some tag)
cd uimaj
mvn install
The uimaj/trunk/uimaj pom would have a dependency on the released version of the
common project-wide parent-pom, at version 1, and it would be found, just like
any other released maven artifact, in maven central; the other poms in the
trunk/uimaj would, in turn, have as a parent, the trunk/uimaj pom.
1a) scenario: check out, patch, and build just one jar:
svn co https://svn.apache.org/repos/asf/uima/uimaj/trunk/uimaj-core (for
instance)
(apply patch)
cd uimaj-core
mvn install
2) scenario: Build from the source tarball (from a release, or from a
uimaj-distr/target build, or from a release candidate)
unzip the tarball
cd uimaj
mvn install
This would work just the same as svn checkout.
3) scenario: needing to fix a problem in the build of uimaj: Here the fix would
be made to the uimaj project, which is serving as the parent pom to all the
submodules. Sometime after the release is made, a separate decision could be
made to move the build change to the overall project parent-pom. On a separate
schedule, that could be released; once it was released, the uimaj project's pom
could be updated to depend on the new release level, and the part moved up to
the common parent for sharing with other projects could be removed.
4) Scenario: working with eclipse: this would work as before (described here:
http://uima.apache.org/building-uima.html#building-from-eclipse )
This seems to me to combine the best attributes of keeping this local and
contained, and over time, factoring out common things that should be shared for
consistency and reliability among all the uima projects.
I'd like to do this change. It would involve:
1) voting out the already existing parent-pom-1 and uima-build-resources-1
artifacts so they could be put in Maven central, and referred to.
2) creating the uimaj project as the overall aggregator and parent-pom of the
uimaj projects, and having it depend on the released version one of the
projet-wide pom
Then we could continue with our efforts to release uimaj, and iterating as
needed, locally within the uimaj project, to get it out, without disturbing the
parent-pom-1.
Please let me know if you feel it's OK for me to try this approach.
-Marshall Schor
Re: Next "improvement" to UIMA build approach
Posted by Tommaso Teofili <to...@gmail.com>.
2010/11/18 Marshall Schor <ms...@schor.com>
> The current build approach has some issues. A major one is that the trunk
> is
> not currently buildable (because uimaj projects have a parent pom
> dependency at
> version 1 which is only in the staging area, and not really released yet).
>
> After some iterations and discussions with colleagues, here's the next
> "improvement" which I think will fix these problems. The main idea is to
> make
> the "main" aggregator project for each multi-module build (e.g., the
> "uimaj"
> project for the uimaj SDK) also be a parent-pom for all those modules in
> the
> multi-module build, as is conventional Maven practice.
>
+1 also it's easy to understand for common Maven users
>
> We would still keep the build tooling overall parent-pom, but would
> decouple
> releases of that from releases of things that use it. So, for instance, we
> would release parent-pom, version 1, and then when we found "issues" in it
> while
> trying to release the uimaj project, we would address those issues by
> making
> changes in the uimaj's pom (overriding if needed the parent-pom-1). At
> some
> arbitrary time in the future, we could "promote" any changes that were done
> that
> ought to be shared with other projects to the common build parent-pom. A
> key
> point here is that this promotion and subsequent release of the
> project-wide
> parent pom would be completely decoupled from the release of the uimaj
> project.
>
> Some scenarios, assuming we've voted and released the parent-pom tooling.
>
> 1) scenario: checkout uimaj trunk or tag, and build it:
>
> svn co https://svn.apache.org/repos/asf/uima/uimaj/trunk (or some tag)
> cd uimaj
> mvn install
>
> The uimaj/trunk/uimaj pom would have a dependency on the released version
> of the
> common project-wide parent-pom, at version 1, and it would be found, just
> like
> any other released maven artifact, in maven central; the other poms in the
> trunk/uimaj would, in turn, have as a parent, the trunk/uimaj pom.
>
>
> 1a) scenario: check out, patch, and build just one jar:
> svn co https://svn.apache.org/repos/asf/uima/uimaj/trunk/uimaj-core (for
> instance)
> (apply patch)
> cd uimaj-core
> mvn install
>
> 2) scenario: Build from the source tarball (from a release, or from a
> uimaj-distr/target build, or from a release candidate)
> unzip the tarball
> cd uimaj
> mvn install
>
> This would work just the same as svn checkout.
>
> 3) scenario: needing to fix a problem in the build of uimaj: Here the fix
> would
> be made to the uimaj project, which is serving as the parent pom to all the
> submodules. Sometime after the release is made, a separate decision could
> be
> made to move the build change to the overall project parent-pom. On a
> separate
> schedule, that could be released; once it was released, the uimaj project's
> pom
> could be updated to depend on the new release level, and the part moved up
> to
> the common parent for sharing with other projects could be removed.
>
> 4) Scenario: working with eclipse: this would work as before (described
> here:
> http://uima.apache.org/building-uima.html#building-from-eclipse )
>
> This seems to me to combine the best attributes of keeping this local and
> contained, and over time, factoring out common things that should be shared
> for
> consistency and reliability among all the uima projects.
>
> I'd like to do this change. It would involve:
>
> 1) voting out the already existing parent-pom-1 and uima-build-resources-1
> artifacts so they could be put in Maven central, and referred to.
> 2) creating the uimaj project as the overall aggregator and parent-pom of
> the
> uimaj projects, and having it depend on the released version one of the
> projet-wide pom
>
> Then we could continue with our efforts to release uimaj, and iterating as
> needed, locally within the uimaj project, to get it out, without disturbing
> the
> parent-pom-1.
>
> Please let me know if you feel it's OK for me to try this approach.
>
>
Yes Marshall it sounds good.
+1
Tommaso
> -Marshall Schor
>
Re: Next "improvement" to UIMA build approach
Posted by Adam Lally <al...@alum.rpi.edu>.
On Thu, Nov 18, 2010 at 1:18 PM, Eddie Epstein <ea...@gmail.com> wrote:
> On Thu, Nov 18, 2010 at 10:26 AM, Marshall Schor <ms...@schor.com> wrote:
> > The current build approach has some issues. A major one is that the
> trunk is
> > not currently buildable (because uimaj projects have a parent pom
> dependency at
> > version 1 which is only in the staging area, and not really released
> yet).
>
> As I understand it, releasing the parent pom will immediately solve most if
> not
> all current build problems.
>
>
+1. Trunk building => good.
-Adam
Re: Next "improvement" to UIMA build approach
Posted by Eddie Epstein <ea...@gmail.com>.
On Thu, Nov 18, 2010 at 10:26 AM, Marshall Schor <ms...@schor.com> wrote:
> The current build approach has some issues. A major one is that the trunk is
> not currently buildable (because uimaj projects have a parent pom dependency at
> version 1 which is only in the staging area, and not really released yet).
As I understand it, releasing the parent pom will immediately solve most if not
all current build problems.
> After some iterations and discussions with colleagues, here's the next
> "improvement" which I think will fix these problems. The main idea is to make
> the "main" aggregator project for each multi-module build (e.g., the "uimaj"
> project for the uimaj SDK) also be a parent-pom for all those modules in the
> multi-module build, as is conventional Maven practice.
And this step will further reduce the need to make updates to the parent pom.
> Some scenarios, assuming we've voted and released the parent-pom tooling.
These all look good to me.
> I'd like to do this change. It would involve:
>
> 1) voting out the already existing parent-pom-1 and uima-build-resources-1
> artifacts so they could be put in Maven central, and referred to.
> 2) creating the uimaj project as the overall aggregator and parent-pom of the
> uimaj projects, and having it depend on the released version one of the
> projet-wide pom
+1
Re: Next "improvement" to UIMA build approach
Posted by Marshall Schor <ms...@schor.com>.
Thanks, Jukka. That looks even more general than what I was thinking; I'll set
it up that way.
-Marshall
On 11/19/2010 5:17 AM, Jukka Zitting wrote:
> Hi,
>
> On Thu, Nov 18, 2010 at 5:26 PM, Marshall Schor <ms...@schor.com> wrote:
>> After some iterations and discussions with colleagues, here's the next
>> "improvement" which I think will fix these problems. The main idea is to make
>> the "main" aggregator project for each multi-module build (e.g., the "uimaj"
>> project for the uimaj SDK) also be a parent-pom for all those modules in the
>> multi-module build, as is conventional Maven practice.
> There are cases where you may want to put things in the aggregator POM
> that you don't want inherited by other modules. To avoid that problem
> I'd recommend adding a separate parent module to the build. For
> example, in Jackrabbit our build structure is:
>
> org.apache.jackrabbit:jackrabbit (the aggregator)
> +-- :jackrabbit-parent (the parent)
> +-- :jackrabbit-api
> +-- :jackrabbit-jcr-commons
> ...
>
> All modules, including the aggregator, inherit the included parent
> POM. That parent POM on the other hand inherits another project-wide
> POM (that then inherits the org.apache:apache POM...) that we maintain
> and release separately pretty much like you described.
>
> BR,
>
> Jukka Zitting
>
>
Re: Next "improvement" to UIMA build approach
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Nov 18, 2010 at 5:26 PM, Marshall Schor <ms...@schor.com> wrote:
> After some iterations and discussions with colleagues, here's the next
> "improvement" which I think will fix these problems. The main idea is to make
> the "main" aggregator project for each multi-module build (e.g., the "uimaj"
> project for the uimaj SDK) also be a parent-pom for all those modules in the
> multi-module build, as is conventional Maven practice.
There are cases where you may want to put things in the aggregator POM
that you don't want inherited by other modules. To avoid that problem
I'd recommend adding a separate parent module to the build. For
example, in Jackrabbit our build structure is:
org.apache.jackrabbit:jackrabbit (the aggregator)
+-- :jackrabbit-parent (the parent)
+-- :jackrabbit-api
+-- :jackrabbit-jcr-commons
...
All modules, including the aggregator, inherit the included parent
POM. That parent POM on the other hand inherits another project-wide
POM (that then inherits the org.apache:apache POM...) that we maintain
and release separately pretty much like you described.
BR,
Jukka Zitting