Depchecker.

[Ryan Shaw <ry...@stanfordalumni.org>]

Suppose the following scenario:

Excalibur has subprojects foo and bar, 
where foo depends on bar.

I build foo, which has a dependency on 
bar.jar, so bar gets built too. So far
so good.

Now, I do a CVS update. A new feature 
has been added to foo, which depends 
on a new method that has been added to
bar.

Then I try to build foo again.

What seems to happen next is: depchecker
looks for bar.jar. It exists, since I
built it before, so depchecker assumes
the dependency is satisfied. Yet the
foo build fails, because the new method
foo needs is not in the old bar.jar.

This failure is difficult to track down
(for someone unfamiliar with bar) since
depchecker seems to be happy.

It would be nice if depchecker could
see that some bar src files are newer
than bar.jar, and thus delete bar.jar
and rebuild.

You could argue that since public 
methods of foo changed, the version 
number on the jar should have changed,
and the dependency entry in the foo
subproject's default.properties ought
to have changed as well. But I think
that this is an unreasonable expectation
for subprojects under heavy development.

Ryan


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Depchecker.

[Jeff Turner <je...@socialchange.net.au>]

On Tue, Apr 23, 2002 at 11:33:07AM -0400, Peter Royal wrote:
> On Saturday 20 April 2002 04:00 am, Leo Simons wrote:
> > I have a shell script being run in every startup that updates all
> > CVS modules I'm currently working with/on, then runs ant against all
> > of them. After my coffee, my email, my sandwich and my daily news
> > gathering, it's usually done and I start work.

Sounds a lot like what Gump does. Eg, if you set up a Gump workspace
specifying which projects to build, then './update.sh all' will do a CVS
checkout/update, and './build.sh all' will build them all in the correct
order.

Wonder if anyone is really using Gump to order their entire Jakarta
playpen like this..


--Jeff

> Care to share? :)
> -pete
> 
> -- 
> peter royal -> proyal@apache.org

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Depchecker.

[Leo Simons <ma...@leosimons.com>]

The sandwich? No.

Basically its "for x in dirlist
  cd /cvs-mods/x
  cvs update
  cd .."

except more ugly as I suck at shell scripts...and then
at that somewhere during the startup.

- Leo



On Tue, 2002-04-23 at 17:33, Peter Royal wrote:
> On Saturday 20 April 2002 04:00 am, Leo Simons wrote:
> > I have a shell script being run in every startup that updates all
> > CVS modules I'm currently working with/on, then runs ant against all
> > of them. After my coffee, my email, my sandwich and my daily news
> > gathering, it's usually done and I start work.
> 
> Care to share? :)
> -pete
> 
> -- 
> peter royal -> proyal@apache.org
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Depchecker.

[Peter Royal <pr...@apache.org>]

On Saturday 20 April 2002 04:00 am, Leo Simons wrote:
> I have a shell script being run in every startup that updates all
> CVS modules I'm currently working with/on, then runs ant against all
> of them. After my coffee, my email, my sandwich and my daily news
> gathering, it's usually done and I start work.

Care to share? :)
-pete

-- 
peter royal -> proyal@apache.org

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Depchecker.

[Leo Simons <le...@apache.org>]

> Yes, that would work. I suppose the question boils down to, what
> semantics do you want to associate with 'cvs update'? Your way, every
> 'cvs update' implies "I trust this new code and wish to use it in all
> projects". I don't think that's *always* what people think when they do
> an update. Maybe they just want to look at the code, not use it. Maybe
> they're just creatures of habit like me and unthinkingly type 'cvs
> update' before starting any work.

I have a shell script being run in every startup that updates all
CVS modules I'm currently working with/on, then runs ant against all
of them. After my coffee, my email, my sandwich and my daily news
gathering, it's usually done and I start work.

Every single module in there that makes this not work, I dislike...it
is nice not having to start your day thinking about who broke what and
why =)

> I think the semantics of 'cvs update' should be "synch these files with
> the repository"; nothing more. Then an extra step, 'ant dist.lite',
> means "I trust this code enough to want to use it in other projects".

A big "me too" here!

- Leo

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Depchecker.

[Jeff Turner <je...@socialchange.net.au>]

On Fri, Apr 19, 2002 at 11:31:05PM +0900, Ryan Shaw wrote:
> Jeff Turner wrote:
> 
> > So you absolutely *need* isolation from external changes. Isolation is
> > necessary until the moment when you can say "yes my code works fine",
> > and can tick off that variable. Then, and only then, should you consider
> > the effects of other variable changes.
> > 
> > The build system supports this isolation principle in another way.
> > You'll notice that the default target is 'jar', which builds a jar in
> > build/lib/. However, the depchecking system runs the 'dist.lite' target,
> > which builds a jar in dist/, and this is where the "excalibur-*.jar"
> > properties point to.
> > 
> > The thinking behind this is that build/lib/*.jar will change on every
> > build, and it's API contracts are not stable enough even for other
> > subprojects to rely on. So there's a dist/ directory, whose jars are
> > *intended* to be relied on by other subprojects. They are relatively
> > stable, and only built on demand by other subprojects, instead of "by
> > accident" when the user types 'ant'.
> 
> I see what you saying. However, I think this increases the risk that
> people will check in broken code, because their code works with the
> "dist" jar, and they forget to check to see if it actually builds 
> with the latest "build" code.

Yes it does. Luckily we've got Gump. Broken code can go at most 6 hours
before a Gump run catches it.

> This is bad, because it means the people to discover this won't be
> the ones who understand how to fix it (the developers of the broken
> code).
>
> But, like I said, I see the isolation argument too. But can't this
> be achieved by not doing a CVS update when you have half-developed
> code in your source tree? Wait until the part you are actively 
> developing is stable. *Then* update, and rest assured that depchecker
> will verify that your new code works smoothly with the very latest
> CVS code before you checkin. Saves you getting scolded by GUMP later.

Yes, that would work. I suppose the question boils down to, what
semantics do you want to associate with 'cvs update'? Your way, every
'cvs update' implies "I trust this new code and wish to use it in all
projects". I don't think that's *always* what people think when they do
an update. Maybe they just want to look at the code, not use it. Maybe
they're just creatures of habit like me and unthinkingly type 'cvs
update' before starting any work.

I think the semantics of 'cvs update' should be "synch these files with
the repository"; nothing more. Then an extra step, 'ant dist.lite',
means "I trust this code enough to want to use it in other projects".
This is the way Jakarta Commons works.

So there's pros and cons. It boils down to what the regular committers
want (I'm not one). If any of them prefer less isolation, then speak up
and I'll see what can be done.


--Jeff

> Ryan
> 

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Depchecker.

[Ryan Shaw <ry...@stanfordalumni.org>]

Jeff Turner wrote:

> So you absolutely *need* isolation from external changes. Isolation is
> necessary until the moment when you can say "yes my code works fine",
> and can tick off that variable. Then, and only then, should you consider
> the effects of other variable changes.
> 
> The build system supports this isolation principle in another way.
> You'll notice that the default target is 'jar', which builds a jar in
> build/lib/. However, the depchecking system runs the 'dist.lite' target,
> which builds a jar in dist/, and this is where the "excalibur-*.jar"
> properties point to.
> 
> The thinking behind this is that build/lib/*.jar will change on every
> build, and it's API contracts are not stable enough even for other
> subprojects to rely on. So there's a dist/ directory, whose jars are
> *intended* to be relied on by other subprojects. They are relatively
> stable, and only built on demand by other subprojects, instead of "by
> accident" when the user types 'ant'.

I see what you saying. However, I think this increases the risk that
people will check in broken code, because their code works with the
"dist" jar, and they forget to check to see if it actually builds 
with the latest "build" code.

This is bad, because it means the people to discover this won't be
the ones who understand how to fix it (the developers of the broken
code).

But, like I said, I see the isolation argument too. But can't this
be achieved by not doing a CVS update when you have half-developed
code in your source tree? Wait until the part you are actively 
developing is stable. *Then* update, and rest assured that depchecker
will verify that your new code works smoothly with the very latest
CVS code before you checkin. Saves you getting scolded by GUMP later.

Ryan

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Depchecker.

[Jeff Turner <je...@socialchange.net.au>]

On Fri, Apr 19, 2002 at 06:11:18PM +0900, Ryan Shaw wrote:
> Suppose the following scenario:
> 
> Excalibur has subprojects foo and bar, where foo depends on bar.
> 
> I build foo, which has a dependency on bar.jar, so bar gets built too.
> So far so good.
> 
> Now, I do a CVS update. A new feature has been added to foo, which
> depends on a new method that has been added to bar.
> 
> Then I try to build foo again.
> 
> What seems to happen next is: depchecker looks for bar.jar. It exists,
> since I built it before, so depchecker assumes the dependency is
> satisfied. Yet the foo build fails, because the new method foo needs
> is not in the old bar.jar.
> 
> This failure is difficult to track down (for someone unfamiliar with
> bar) since depchecker seems to be happy.

This is an excellent point, and I hope your email raises awareness of
this potential problem.

> It would be nice if depchecker could see that some bar src files are
> newer than bar.jar, and thus delete bar.jar and rebuild.

Or just always run the 'jar' target, and rely on Ant's built-in
checks...

But while this would be good in some scenarios, it would be disastrous
in others, because it introduces extra variables in development.

Say that while you're happily working on project foo, someone ELSE
modifies project bar. This would be dreadful; you're now at the mercy of
anyone who checks in buggy code, or changes the API contract.  Say your
half-developed foo code starts behaving weirdly; is it your fault, or
due to some change in bar? So now, instead of just focusing on improving
foo, you must *also* ensure that the modifications in bar are
acceptable. Extra variables, extra complexity, and as Frank Herbert
might have said, "complexity is the mind-killer".

So you absolutely *need* isolation from external changes. Isolation is
necessary until the moment when you can say "yes my code works fine",
and can tick off that variable. Then, and only then, should you consider
the effects of other variable changes.

The build system supports this isolation principle in another way.
You'll notice that the default target is 'jar', which builds a jar in
build/lib/. However, the depchecking system runs the 'dist.lite' target,
which builds a jar in dist/, and this is where the "excalibur-*.jar"
properties point to.

The thinking behind this is that build/lib/*.jar will change on every
build, and it's API contracts are not stable enough even for other
subprojects to rely on. So there's a dist/ directory, whose jars are
*intended* to be relied on by other subprojects. They are relatively
stable, and only built on demand by other subprojects, instead of "by
accident" when the user types 'ant'.

> You could argue that since public methods of foo changed, the version
> number on the jar should have changed, and the dependency entry in the
> foo subproject's default.properties ought to have changed as well. But
> I think that this is an unreasonable expectation for subprojects under
> heavy development.

Only if multiple subprojects are undergoing heavy development together,
by one author. I'd suggest that is a relatively infrequent situation
compared to that outlined above. 


--Jeff

> Ryan

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>