myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Schofield <sean.schofi...@gmail.com>
Subject Re: build.default.properties
Date Fri, 08 Jul 2005 18:19:31 GMT
> 1) we have to explicitly call out the dependencies (i.e. impl on api)
> so that if we mistakenly introduce a circular dependency (like the
> UIData thing this morning) we can catch it easily.

I think we can achieve this by reworking the build script.  We can
have different classpaths and then specify them in the
build.properties of the subproject.  I think we should do this no
matter what because most of us will be building using current and we
don't want to accidentally introduce dependencies as you point out.

> 2) Small chunk of stuff to bite off for new developers. Someone
> joining the dev team (or thinking about it) could just grab the api
> code to start with and once groked could move onto the impl code.

I guess I can see some advantage to working on just api but I still
think share + impl are pretty much inseparable.

> 3) Testing, if we could build each project independently we could
> have tests focused on that particular subproject. Agreed that we are
> not getting around the impl->api dependency so api would have to be
> available in some form (the classes dir mentioned above would be one
> way) but the developer of the test could focus just on the impl
> project and test that in relative isolation.
> 
> Most if no all this could also be done with the 'current' project as
> well so its no that big of a deal. But I like to try to minimize
> things so that newbies can get started quicker and easier.

I think that depends on how you test the subprojects.  What kinds of
tests do we envision writing for api for example?  So far I've heard a
suggestion of writing a test to "click" on all of the examples. 
That's a great idea but that's really a test of several subprojects
combined.

I'm not really opposed to your suggestion, just curious.  I will try
to work on item#1 this weekend.  That should bring us closer to what
you are trying to achieve.
 
> And we also have a huge task to get unit testing in place, the easier
> that is the better.

If we could get consensus on consolidating the examples that would
also be good.  I'd say we should do this and a few other steps
(nightly builds, website enhancements) before deploying the unit
tests.

> BTW: what is the general consensus among us regarding tests? I'd love
> to see a set of automated integration tests that at least clicked
> through the whole sample/simple example tree as a starter and then
> build from that. I'm willing to start it but its very hard to
> maintain if we are not all committed to running the tests before we
> commit.

Tests are great but I am not particularly creative at implementing
web-based tests.  I like the idea of compiling and deploying the
webapps and clicking through the application.  Even if people do not
run the tests before commiting, we can at least run them nightly and
report failures to the dev list.

It would be interesting to see how Maven could help here.  I'm not
sure about how Maven is going to fit into all of this but it seems to
have nice testing and reporting features.  If we write cactus and
junit tests and use ant can they be ported over to Maven?

> Anyway sorry for the long message and thanks again Sean for all the
> hard work.

Your welcome.  Thank you for your interest in testing ;-)

I'm definitely looking forward to seeing your test ideas come to life.
 There are some legacy tests that I didn't really know how to deal
with.  You can check the "before_svn_reorg" tag and find them if
you're interested.  We'll also have to figure out how we're going to
automate the tests and from which machine.

> -bd-

sean

Mime
View raw message