[aerogear-dev] [Android] Android project structure for final

Karel Piwko kpiwko at redhat.com
Mon Mar 4 10:26:43 EST 2013


On Fri, 1 Mar 2013 17:01:36 +0100
Matthias Wessendorf <matzew at apache.org> wrote:

> On Fri, Mar 1, 2013 at 4:04 PM, Summers Pittman <supittma at redhat.com> wrote:
> > On 03/01/2013 09:24 AM, Matthias Wessendorf wrote:
> >> On Fri, Mar 1, 2013 at 3:17 PM, Summers Pittman <supittma at redhat.com>
> >> wrote:
> >>> On 03/01/2013 06:59 AM, Kris Borchers wrote:
> >>>> On Mar 1, 2013, at 12:38 AM, Matthias Wessendorf <matzew at apache.org>
> >>>> wrote:
> >>>>
> >>>>> On Fri, Mar 1, 2013 at 2:02 AM, Douglas Campos <qmx at qmx.me> wrote:
> >>>>>> On 28/02/2013, at 20:07, Summers Pittman <supittma at redhat.com> wrote:
> >>>>>>
> >>>>>>> aerogear-android-tests: This will house all of the Aerogear tests for
> >>>>>>> Android.
> >>>>>> You mean moving all the tests? Can't this be only for integration
> >>>>>> tests, and the unit tests stay on the aerogear-android project?
> >>>>> I'd also prefer to have the unit tests for each of the libs
> >>>>> (aerogear-android + aerogear-android-support) being in there.
> >>>> I can see one reason to have the unit tests in a separate project. I
> >>>> assume both aerogear-android and aerogear-android-support would have
> >>>> pretty much identical tests since their functionality should be the
> >>>> same, right? It would be a pain to have to maintain multiple sets of the
> >>>> same tests across projects.
> >>> This would be a benefit, yes.
> >> ... ok - but I guess we have to be disciplined to exec. the tests...
> >> It's too easy to forget that :)
> > Not really, any decent build tool/IDE can be configured to run the test
> > project with your code.
> 
> yes... I know.... but the key-word here is 'can' :-)

I bit late for the discussion. Fortunately, I agree with the outcome :-). 

Separated tests does only make testing from IDE more complicated, otherwise it
has advantages. It should not be that difficult to set up a job that would
execute integration tests on our Jenkins instance in a regular manner. I
can work with Summers on that.

> 
> But yeah, lets do the split, for 1.0.0.Final
> 
> -M
> 
> 
> >>
> >>
> >> -M
> >>
> >>
> >>
> >>>>> Only integration tests should be a totally independent project,
> >>>>> consuming the other libs (aerogear-android + aerogear-android-support)
> >>>>> and having tests against em.
> >>>>>
> >>>>> -M
> >>>>>
> >>>>>
> >>>>>> -- qmx
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> aerogear-dev mailing list
> >>>>>> aerogear-dev at lists.jboss.org
> >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>>>
> >>>>> --
> >>>>> Matthias Wessendorf
> >>>>>
> >>>>> blog: http://matthiaswessendorf.wordpress.com/
> >>>>> sessions: http://www.slideshare.net/mwessendorf
> >>>>> twitter: http://twitter.com/mwessendorf
> >>>>> _______________________________________________
> >>>>> aerogear-dev mailing list
> >>>>> aerogear-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>> _______________________________________________
> >>>> aerogear-dev mailing list
> >>>> aerogear-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>> _______________________________________________
> >>> aerogear-dev mailing list
> >>> aerogear-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >>
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> 



More information about the aerogear-dev mailing list