Re: [jbosstools-dev] Red Deer Info?
>>> 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