Igor,
I think the requirements are more difficult than I suspect
you are thinking of. The important need is to assign a qualifier for each
plugin project based upon the last modification to that plugin. A single build,
in the extreme case, could assign 50 unique qualifiers to the 50 plugins that
get built. We need to have is the same qualifier every time that an
unchanged plugin is built. The reason that this is important has to do with how
p2 updates work. Say that we are building a p2 enabled client that contains 80
plugins that are built from source in addition to more than 160 eclipse plugins
(included via target platform). Now let’s say we need to fix a problem
with one of the plugins. This fix involves changing a few source files in a
single plugin. If we allow every build to generate a new version of every
plugin (by using a single qualifier for the build) then every user will
download all 80 plugins when they update the application. Contrast that to the
case where the new build assigns every plugin (except the one changed) the same
qualifier that was assigned to that plugin the last time that it was built (in
fact the same one that was assigned after the last change to that plugin). The
result is an p2 repository that when the user updates their client, p2 will
recognize that there is only a single changed plugin and download that only one
plugin. Clearly we need the second case.
To accomplish this we can not specify a single qualifier
using the –DforceContextQualifier property. It assigns the
same qualifier to every plugin. To accomplish what is needed in a shell script,
the script would need to update the build.properties file in every plugin that
will be built, then launch the mvn build. Now, it is possible to do this, but
the script would need to duplicate a lot of the work that mvn does to follow
the POM module hierarchy and determine which plugin projects are going to be
built, so that it knows which build.properties files must have the
forceContextQualifier set.
BuildQualifierMojo, provides an elegant way to accomplish what is
needed, except that given mvn restrictions (no mojos can be run before
default-validate) and the current binding to the validate phase, we can not use
the pom to bind a new mojo to run before it. Also BuildQualifierMojo does
not support the skip property, so you can not update the pom to keep the
default version from running and move the execution to a later phase in the
lifecycle
I did find a way to test the concept which works, today. But I
don’t feel comfortable assuming that it will safe tomorrow. You can add
new bindings for the build-qualifier and validate-version goals to the
generate-resources phase and add the custom qualifier calculation to validate.
Today this works; the default build-qualifier does its standard processing,
then the second invocation runs and resets project properties with the
qualifier that we really want to use. This is way to dependent upon the
internal operation of BuildQualifierMojo.
I suspect that an alternative, given today’s limitations would be
for the new mojo that calculates a plugin’s qualifier to directly set the
buildQualifier property and completely ignore the qualifier produced by
BuildQualifierMojo.
Getting proper qualifiers setup for p2 builds is always a complicated,
but important issue. Hopefully, tycho can provide the hooks required accomplish
this.
Thanks
Rich