[jbosstools-dev] Red Deer Info?

[Jiri Peterka]

Hi Max,
On 10/30/2012 02:19 PM, Max Rydahl Andersen wrote:
>>> I asked this on https://github.com/jbosstools/jbosstools-integration-tests/pull/3 but I assume noone saw it since the issue is closed, so repeating it here:
>>>
>>> How is this red deer stuff going to work ? which updatesites will contain it ? I did not realize these are actually eclipse plugins - and thus not just maven dependencies. by reddeer being on its own the maintanence of those updatesites and releases needs to be done fully before we should have tests depending on them, right?
>> Please see,
>> https://github.com/jboss-reddeer/reddeer/wiki/Getting-Started ,
>> "Installing RedDeer" section and "RedDeer and Maven/Tycho" section.
> cool - but why?
why what? I don't follow.
>
>>> I saw today there is something like p2-reddeer.rhcloud.com/stable - what is that and why are we publishing this way and how are this stuff supposed to be used ?
>> Yes, there are update sites for last stable, particular stable versions
>> and dev branch update site
> cool - but why have this as separate ?
it's meant as standalone project because it's not a jboss or 
jbt-specific  so it makes sense to have it like that IMO. One day it can 
be part of Eclipse (or JBoss project group maybe, who knows). Looking 
back to SWTBot  before it was part of Eclipse it had been also single 
standalone project as far as I remember. If you are asking for multiple 
version sites they provide freedom for test developers to choose to go 
to higher version when they want and when they have time to do it 
without breaking any tests. Yes, there are more ways how to achieve this.
>
>>> There have been no info/news on this but now alot of our tests is suddenly dependent on this making our builds rely on something that is *not* mirrored nor communicated how to use afaik ?
>> There is some initial info here
>> https://github.com/jboss-reddeer/reddeer/wiki but still we are working
>> on it
> fine - but why are we adding this as a separate project to jbosstools when its only jbosstools that needs it ?
Thing is that RedDeer is not a JBT aware. There is no single JBT 
dependency in RedDeer and it's meant as general Eclipse testing 
framework. So specific JBT-API based on RedDeer will be part of JBoss 
Tools placed in JBT repo, no doubt about it.

>
> and if others need it why not use the jbosstools updatesites for this instead of separate maintancne for it ?
>
> We have jbosstools target platform and setup copying/mirroring of these to avoid data getting lost AND to avoid the build being slower when adding new p2 repos.
>
>
>>> Did I miss something ? i.e. i'm still not following why we want to have separate infrastructure for something this eclipse specific ? but first of all i'm worried about having jbosstools code dependent on something like this very unknown reddeer.
>> RedDeer was initiated to overcome some problems and shortcomings from
>> SWTBot usage and to bring desired features for functional test
>> development. Related to JBT it's meant to be used only for
>> integration/functional tests. During SVN times we decided  to have it as
>> independent of JBT builds and make it available as a project for (not
>> only JBT) functional testing on Eclipse.
> Yeah, I heard this but never saw any info on it except an initial email where I asked the same questions - why
> create a separate project/build setup for this - its just overhead.
Explained above.
>
>> Currently there is a code on
>> Github, wiki on Github and builds on OpenShift. When RedDeer is mature
>> enough we can consider further steps. Related to dependencies and builds
>> it's stable as far as OpenShift site is stable.
> why not just add these repos as part of the jbosstools base tests builds ?
again, it's not JBT related, it's general eclipse testing framework (in 
some aspects similar to swtbot)
>
> Look, i'm fine you try and create a separate project for testing - thats your choice to do this; - what i'm not fine about is adding additional p2 repos midstream into the build of jbosstools.
>
> Thats *not* something that we ever done before (For good reasons: speed, maintanence, reproducibilit etc.) and if it were to happen you add new dependencies then please raise this on the mailing list since it
> affects everyone, its not just the Brno Office that works on this.
I see, to fit it in your schema it would be good for you if it's part of 
target platform (similar to SWTBot). No problem with that except I'm not 
sure if there is a good way howto perform updates smoothly. If there is 
a good solution for it I'm in.
>
> /max
>
>
>
Jirka