First let me say that the reorg is a great first step to getting
things in place to do some focused testing.
You have the beginnings of being able to build against the api
subproject with the api.classes.dir property so we are at least
partly there.
I like having the independently buildable subprojects for a couple of
reasons;
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.
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.
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.
And we also have a huge task to get unit testing in place, the easier
that is the better.
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.
Anyway sorry for the long message and thanks again Sean for all the
hard work.
TTFN,
-bd-
On Jul 7, 2005, at 3:49 PM, Sean Schofield wrote:
Bill,
I see your point but I think that this goal should apply to the
tomahawk subproject. IMO it doesn't make much sense to support
building impl without also building api. Why would you ever separate
the two (even for testing?)
I definitely see the advantage in compiling tomahawk against RI and
MyFaces and there is support for that now. Being able to compile imp
using an api.jar is tricky because what if I just want to runt the
"compile" target. Then there is no myfaces-api.jar to run against ...
I think test cases for each subproject would be good. (There is a
small number of legacy ones and they have not been ported over.) I
don't have any bright ideas at the moment.
What to do you think about all of this?
sean
On 7/7/05, Bill Dudney <[EMAIL PROTECTED]> wrote:
Hi Sean,
Perhaps I misunderstand the reasoning behind the sub-projects.
What I expected was that each subproject was build-able on its own as
a 'deliverable' chunk. If I wanted to I could grab the sub-projects
I'm interested in and work only with those (i.e. if I only care about
impl I could have an api.jar file around and work on the impl code
alone).
Do I have it wrong? If so no big deal I can go work in current for
now.
The use case is for testing purposes. I'd like to have a set of tests
for api, a set for impl etc. Then the new developer to myfaces can
make a change in one of the subproject, run the tests there and be
relatively sure that they have not broken anything. Its part of the
safety net concept we talked about before the reorg got started.
TTFN,
-bd-
On Jul 7, 2005, at 3:06 PM, Sean Schofield wrote:
The problem is I've got shared checked out as 'myfaces-shared'
instead of shared so the shared.src.dir property points to the
wrong
spot.
Why did you do this? The "suggested" approach is to check out using
the *current* shortcut. (I'm working on the documentation for that
now btw.)
Can you give me a use case for building in the manner you are
describing?
sean
