build.default.properties

[Bill Dudney <bd...@mac.com>]

Hi Sean,

In the build.xml file the comments suggest that  
build.default.properties is 'user configurable' but its checked into  
the repo. Are you working on that right now? If not I'd like to add  
build.local.properties to the list of files that are imported.

TTFN,

-bd-

[OT] [was: Re: build.default.properties]

[Manfred Geiler <ma...@gmail.com>]

<OT reason="justforfun">

> I would propose that anyone committing a change that causes a test to
> fail be put in a small interrogation room with the Manfred Geiler Bad
> Cop. Be very afraid.

:-)

Harhaaaar! Who dares?

BTW, for serious interrogation we also need a "Good Cop". Any volunteer?

-Manfred  ;-)


</OT>

Re: build.default.properties

[Martin Marinschek <ma...@gmail.com>]

;)

I can be quite a nuisance for petty criminals as well, so let me in
for the fun.

(This is: if I am not currently being one ;)

regards,

Martin

On 7/8/05, Grant Smith <gr...@marathon-man.com> wrote:
> Grant Smith wrote:
> 
> >
> > I would propose that anyone committing a change that causes a test to
> > fail be put in a small interrogation room with the Manfred Geiler Bad
> > Cop. Be very afraid.
> 
> And don't think you'll go undetected. Sgt Schofield's Subversion Blame
> Tool will root you out in an instant!
>

Re: build.default.properties

[Grant Smith <gr...@marathon-man.com>]

Grant Smith wrote:

>
> I would propose that anyone committing a change that causes a test to 
> fail be put in a small interrogation room with the Manfred Geiler Bad 
> Cop. Be very afraid.

And don't think you'll go undetected. Sgt Schofield's Subversion Blame 
Tool will root you out in an instant!

Re: build.default.properties

[Grant Smith <gr...@marathon-man.com>]

Bill Dudney wrote:

>
> 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. 


+1 !!! We desperately need unit tests integrated. I'm currently creating 
tests externally and it's a pain. If we could also just have a simple 
ant task to run the tests (in each subproject) that would be great.
BTW, what is the status of the Cactus tests in the new SVN layout ? Can 
we somehow consolidate unit tests and the Cactus tests ?

> 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.

I would propose that anyone committing a change that causes a test to 
fail be put in a small interrogation room with the Manfred Geiler Bad 
Cop. Be very afraid.

>
> 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 <bd...@mac.com> 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
>>>>
>>>>
>>>
>>>
>>
>
>
> .
>

Re: build.default.properties

[Sean Schofield <se...@gmail.com>]

> 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

Re: build.default.properties

[Bill Dudney <bd...@mac.com>]

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 <bd...@mac.com> 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
>>>
>>>
>>
>>
>

Re: build.default.properties

[Sean Schofield <se...@gmail.com>]

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 <bd...@mac.com> 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
> >
> 
>

Re: build.default.properties

[Bill Dudney <bd...@mac.com>]

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
>

Re: build.default.properties

[Sean Schofield <se...@gmail.com>]

> 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

Re: build.default.properties

[Bill Dudney <bd...@mac.com>]

Hi Sean,

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. I either have to move build.local.properties import before the  
prop is set or move the setting of the property after the import. Any  
ideas?

TTFN,

-bd-

On Jul 7, 2005, at 2:55 PM, Sean Schofield wrote:

> You can change the order but don't change the overall position.  In
> other words, of those three props files, its ok to have local and the
> user home ones first *but* the other ones referenced earlier need to
> come first.
>
> I believe that will break the "one build rules them all" scheme  
> otherwise.
>
> sean
>
> On 7/7/05, Bill Dudney <bd...@mac.com> wrote:
>
>> One more quick thing...
>>
>> In order to be effective the user controlable files need to be
>> imported before the properties defined in build.xml so I'd like to
>> move the imports to the top (or near the top) of the file.
>>
>> Thanks,
>>
>> -bd-
>>
>> On Jul 7, 2005, at 2:41 PM, Bill Dudney wrote:
>>
>>
>>> Hi Sean,
>>>
>>> In the build.xml file the comments suggest that
>>> build.default.properties is 'user configurable' but its checked
>>> into the repo. Are you working on that right now? If not I'd like
>>> to add build.local.properties to the list of files that are  
>>> imported.
>>>
>>> TTFN,
>>>
>>> -bd-
>>>
>>>
>>
>>
>

Re: build.default.properties

[Sean Schofield <se...@gmail.com>]

You can change the order but don't change the overall position.  In
other words, of those three props files, its ok to have local and the
user home ones first *but* the other ones referenced earlier need to
come first.

I believe that will break the "one build rules them all" scheme otherwise.  

sean

On 7/7/05, Bill Dudney <bd...@mac.com> wrote:
> One more quick thing...
> 
> In order to be effective the user controlable files need to be
> imported before the properties defined in build.xml so I'd like to
> move the imports to the top (or near the top) of the file.
> 
> Thanks,
> 
> -bd-
> 
> On Jul 7, 2005, at 2:41 PM, Bill Dudney wrote:
> 
> > Hi Sean,
> >
> > In the build.xml file the comments suggest that
> > build.default.properties is 'user configurable' but its checked
> > into the repo. Are you working on that right now? If not I'd like
> > to add build.local.properties to the list of files that are imported.
> >
> > TTFN,
> >
> > -bd-
> >
> 
>

Re: build.default.properties

[Bill Dudney <bd...@mac.com>]

One more quick thing...

In order to be effective the user controlable files need to be  
imported before the properties defined in build.xml so I'd like to  
move the imports to the top (or near the top) of the file.

Thanks,

-bd-

On Jul 7, 2005, at 2:41 PM, Bill Dudney wrote:

> Hi Sean,
>
> In the build.xml file the comments suggest that  
> build.default.properties is 'user configurable' but its checked  
> into the repo. Are you working on that right now? If not I'd like  
> to add build.local.properties to the list of files that are imported.
>
> TTFN,
>
> -bd-
>

Re: build.default.properties

[Sean Schofield <se...@gmail.com>]

You're right.  I changed the comments and added back in support for
build.local.properties (be sure to add that to the ignore list if its
not already there.)

I modfied the build file to use build.local.properties.  Let me know
how that works.

sean


On 7/7/05, Bill Dudney <bd...@mac.com> wrote:
> Hi Sean,
> 
> In the build.xml file the comments suggest that
> build.default.properties is 'user configurable' but its checked into
> the repo. Are you working on that right now? If not I'd like to add
> build.local.properties to the list of files that are imported.
> 
> TTFN,
> 
> -bd-
>