[jbosstools-dev] How should we deal with components of projects which have not changed since JBT 4.1.0.Final (eg., jbosstools-base/runtime) ?

Max Rydahl Andersen manderse at redhat.com
Mon Sep 30 09:32:51 EDT 2013


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/${buildType}</url>
></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.


>
>-- 
>Mickael Istria
>Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
>My blog <http://mickaelistria.wordpress.com> - My Tweets 
><http://twitter.com/mickaelistria>


More information about the jbosstools-dev mailing list