Community
Participate
Working Groups
After reading more about maven-properties-plugin, it seems like it might be a good idea to use that to specify the many properties we are interested in during our builds. We would both want to "read" it, and also to "write it" as part of the build output. We currently do that via bash -- during production builds -- with a file named build_eclipse_org.shsource and we write them (and others) back out to a files named buildproperties.properties which is "at the top" of each build (drop) directory. I do not think we can give up those mechanisms up completely (at least initially). For one, they currently "do work" as well as set variables. Also, when we write them out, we also write buildproperties.shsource (for rebuilding from bash), and buildproperties.php (for use in displaying the build's "download pages". But, it might help solve some long-standing enhancement requests. (e.g. bug 404843 and bug 424136). This will take some experimentation. I *think* I have heard this maven-properties-plugin mechanism is fully compatible with Tycho, but am not positive. Also, am not sure if there are limits on which properties can be specified ... such as do not know if "profiles" can be specified or "toolchain" locations? But seems worth investigating. The "big advantage" is that more than one property file can be specified, so ideally, we can have one "fixed" one, say that varies per stream, one "production one" for production runs, and then one in each repository root (as sibling of its pom) that would "take effect" for "build-individual-bundles runs", which (I am hoping) could override "production properties".
Another advantage of this approach is, for example, we can define some URLs as normal ... "http://... " but when "running on Eclipse.org" we can use "file://" for improved efficiency (and less stress on infrastructure).
Even though properties can not be used for "dependencies" I think they will still have a use for things such as making "N" the default for "local builds".
