Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tycho-user] Running a custom plugin before

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

 

 

Confidentiality Notice: This electronic message transmission, including any attachment(s), may contain confidential, proprietary, or privileged information from Chemical Abstracts Service (“CAS”), a division of the American Chemical Society (“ACS”). If you have received this transmission in error, be advised that any disclosure, copying, distribution, or use of the contents of this information is strictly prohibited. Please destroy all copies of the message and contact the sender immediately by either replying to this message or calling 614-447-3600.


Back to the top