[jbosstools-dev] Red Deer Info?

[Max Rydahl Andersen]

don't cross post to internal and public mailing lists - putting this on jbosstools-dev.

> Good,  we have  an agreement here, either TP or a mirror. Martin is already discussing this with Nick what will works better (adding exadel to cc).  Log4j objection noted.

As discussed yesterday on irc you told swtbot itself was using log4j and thus its not reddeer using/configuring it, but swtbot.
 
> We will try to find a better solution for logging. Related to it's maturity it's more about a definition. There are some initial versions with some API which is usable. For me maturity is level when all API that is expected will be implemented. So currently there are 2 versions out + dev release and there is no reason to have it with jbt tests because RedDeer has it's own tests cases.

Thats fine - but we should be fine just using one version of Red Deer at the time, right?

if not, then its obviously not supposed to be build and used yet ?

/max


> 
> -- Jirka
> 
> On 10/31/2012 10:52 AM, Max Rydahl Andersen wrote:
>>>>>> 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.
>> No, i'm asking that we treat any external dependency equally - if reddeer is supposed to be independent and not part of JBT then JBT should have it as part of its target platform or at least part of its builds for sanity and speed.
>> 
>>>>>> 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.
>> Yes, fine - but as a dependency its using log4j for logging (bad form/not good), its not available from a stable site and it seems its development is done completely internally and without considering other alternatives/better ways of doing what it does.
>> 
>> Thats my objections to it.
>> 
>>>>> 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.
>> not explained above - the project is still said to be immature, not releasable and still want to be separate from the one usecase its used with. That just seems backwards to me.
>> 
>>>>> 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)
>> yes fine - so it should be treated like such a dependency - be mirrored in/part of the target platform.
>> 
>>>> 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.
>> My suggestion:
>> Either do a release of RedDeer as an external project and get it mirrored in or simply build reddeer as part of jboss tools sites until its mature to stand on its own.
>> 
>> /max
>