1:58 p.m.
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?
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 ?
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 ?
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.
/max
3:08 a.m.
Hi Max,
On 10/29/2012 07:58 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.
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
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.
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. 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.
/max
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
Best regards,
-- Jirka
8:19 a.m.
> 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?
> 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 ?
> 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 ?
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.
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 ?
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.
/max
4:27 a.m.
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
4:52 a.m.
>>> 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
10:25 a.m.
Hey Max,
Once again - you an inspiration - see here:
https://github.com/jboss-reddeer/reddeer/wiki/Frequently-asked-questions
;-)
-- Len
----- Original Message -----
From: "Max Rydahl Andersen" <max.andersen(a)gmail.com>
To: "jbosstools-dev jbosstools-dev" <jbosstools-dev(a)lists.jboss.org>
Cc: "ldimaggi DiMaggio" <ldimaggi(a)redhat.com>, "psrna Srna"
<psrna(a)redhat.com>
Sent: Monday, October 29, 2012 2:58:52 PM
Subject: Red Deer Info?
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?
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 ?
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 ?
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.
/max
--
Len DiMaggio (ldimaggi(a)redhat.com)
JBoss by Red Hat
314 Littleton Road
Westford, MA 01886 USA
tel: 978.392.3179
cell: 781.472.9912
http://www.redhat.com
http://community.jboss.org/people/ldimaggio
2:09 a.m.
Thanks, so I'm still missing answers to:
Why us this not just build and published as any other plugins we use ? At least while its
maturing so we don't need yet another p2 site to mirror/maintain ?
At face-to-face last year we talked about working on getting the requirements features qe
was doing that now seems part of reddeer made compatible/usable as part of normal unit
testing - any movement on that?
Reddeer seem to use log4j which is not exactly eclipse/osgi friendly - why is that ?
Why so many plugins in the git repo but just need to import reddeer.swt?
Is red deer a replacement or an addon for swt bot? The FAQ seem to indicate both?
If addon - cool, but why is it then missing features swt bot has?
Have any of this been contributed back to swtbot? I.e. we got committers on swtbot(Mikael)
so if its useful would that make more sense?
Sent from a mobile device
On 30/10/2012, at 16.29, Len DiMaggio <ldimaggi(a)redhat.com> wrote:
Hey Max,
Once again - you an inspiration - see here:
https://github.com/jboss-reddeer/reddeer/wiki/Frequently-asked-questions
;-)
-- Len
From: "Max Rydahl Andersen" <max.andersen(a)gmail.com>
To: "jbosstools-dev jbosstools-dev" <jbosstools-dev(a)lists.jboss.org>
Cc: "ldimaggi DiMaggio" <ldimaggi(a)redhat.com>, "psrna Srna"
<psrna(a)redhat.com>
Sent: Monday, October 29, 2012 2:58:52 PM
Subject: Red Deer Info?
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?
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 ?
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 ?
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.
/max
--
Len DiMaggio (ldimaggi(a)redhat.com)
JBoss by Red Hat
314 Littleton Road
Westford, MA 01886 USA
tel: 978.392.3179
cell: 781.472.9912
http://www.redhat.com
http://community.jboss.org/people/ldimaggio
<RHxJBpngthumb.png>
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
4435
days inactive
4437
days old
jbosstools-dev@lists.jboss.org
6 comments
5 participants
participants (5)
-
Jiri Peterka -
Len DiMaggio -
Max Andersen -
Max Rydahl Andersen -
Max Rydahl Andersen