On Mon, Sep 30, 2013 at 01:27:38PM +0200, Mickael Istria wrote:
On 09/30/2013 11:50 AM, Max Rydahl Andersen wrote:
>i'm leaning more and more towards the continous composite site is
>causing more damage and hiding more issues
>than it is worth having.
The big benfit of this continuous composite site is what you describe here:
>[...]some components (such as JST) probably have too high a
>dependency on Common in base to make it feasible...but if we could
>have these components explicitly point to a "snapshot" of the site
>(not the composited site) until release time this might be doable.
it does though cause constant updates and redownloads because it always changes.
Often unnecessary ones and it also hides cyclic dependencies.
We'll need standardized URLs, and we'll need each component to
define
its dependencies in a pom.
Then we can go for configuation such as
<properties>
<buildType>snapshot</buildType> <!-- Can be snapshot, integration,
release -->
</properties>
<repository>
<layout>p2</layout>
<
url>http://download.jboss.org/jbosstools/updates/jbosstools-base/1.4.0...
</repository>
The URL pattern needs to control required version (set in pom), and
buildType (default value in pom, overridable via command-line).
I would probably move ${buildType} higher up so you don't get a intermingle of
temporary vs final builds.
But yes, this is the general idea I and Denis been pushing on for a while but not done
because of
the lack of stability in parent and target platforms (we build against released versions
not a constant moving one). But now that is fixed I think this is worth looking into for
sure.
We can't easily use a target definition for that as they don't
allow
properties.
Yeah ...I was actually wondering if we could use something like the "merge two
targets" file maven plugin you have to
do property replacement ? ...but I guess thats problematic since the replacement actually
need to happen at build time of
the one using the target platform and not whne actually building/releasing the target
platform.