Sam Ruby wrote:
>
> Geir Magnusson Jr wrote:
> >
> > I am not talking about a nightly build. I know I said that originally,
> > but I misspoke, and clarified on a later post.
> >
> > I mean a 'nightly snapshot', a tgz or zip of the CVS to make it easy for
> > people to grab a copy of what we are working on and play w/ it without
> > having to get a CVS client. In many places, such 'foreign software' is
> > verboten by corporate IT departments, and just getting a tgz or zip is
> > so much easier.
>
> You think I am missing what you are saying. I think that you are missing
> what I am saying. Lets start over.
Ok. Just to be clear, the issue that got this started was :
" 2) jakarta-commons/build/lib
contains common jars used for building."
>
> Gump does a daily cvs extract. Runs a bunch of builds. Runs a bunch of
> tests. Posts the results for all to see.
Great! I love it! I support it. I depend on it. I no longer do my
daily ritual to make sure the CVS of Velocity is clean and buildable
every night.
>
> I am quite willing to combine together input from various sources to
> produce a snapshot to your specifications.
Great. But then it isn't a 'jakarta-commons snapshot'. It's a
'Gump-built construct'. I like the idea, but, if not orthogonal, it's
at least tangential to what I was trying to do.
And isn't this a bit much to avoid putting an Ant jar in the top level
directory of jakarta-commons' CVS?
I understand what you are trying to do. I think its a good thing, and
should start including the individual components in the gump testing
framework. Once I get a better handle on how to build beanutils, I'll
put together a Gump test.xml and send it.
But it's not clear that to avoid CVS-ing an ant.jar for building, we
need to make Gump the central snapshot engine, which is what you seem to
be proposing.
> My two cents is that it actually is better for the snapshot to actually
> match what is posted.
Do you mean posted into that project's CVS? I agree 100%. Do you mean
posted into any CVS in Jakarta-land? I don't believe that's right for
users.
And I believe that a snapshot could should be deterministic, reflecting
the state of the project. Anything else might be confusing, as a
developer just can't look at what the CVS is to solve a user problem,
but has to work through the external Gump process to see what is
'wrong', if something is wrong.
> My motivation is that I want to increase the number of people who actually
> care about Gump reported failures.
I care big time, and will reflect that in anything I work on.
However, 'Gump happiness' isn't our product. It's a tool to help make
the product better through testing the cross dependencies of functional
components within and outside of the Jakarta universe.
My motivation is to lower the barrier to entry so a user can grab a
tarball or zip that is the current state of the project, start the build
process. I don't think they should be forced to alter their classpath,
or alter the executable path, or download lots of stuff.
Even as simple as CPAN-like facility, where after checking the users
environment, the build script would go off to Jakarta-central to get the
jar it needs would be cool. Only downside would be for the users where
internet access is tightly controlled, something common in corporate
environments.
Would still have to include Ant though.
I think what you are proposing would solve my issues, but I think that
1) it makes the snapshot no longer a snapshot
2) it adds the Monte Carlo aspect of inflicting any problems with a
component build upon a hapless user.
Suppose that someone checked in to Ant's CVS something that caused a
problem. Now, if we got Gump to monte-carlo build the nightly snapshots
for every jakarta project, every jakarta project snapshot would be
broken for that day. Doesn't seem right.
I guess if we just can specify a specific CVS tag, so we could include
ant-1.2 or ant-1.3 specifically, that would be fine, as that solves #2.
And maybe #1 isn't a big deal.
>
> I presume that you have an assumption that the snapshot matches bit for bit
> what is in a single cvs module. My presumption is only that it can be
> produced without requiring human intervention.
Yes, I presume that. That's why I thought it was called a 'snapshot'.
And it can be produced w/o human intervention via cron and an Ant script
(unless I have to build Ant first :)
> My offer to upload binaries to your specifications still stands.
That's fine. Maybe we should do that - I assume the specification
includes a specific version number. Or if not, can you build in a
'regression' mechanism so if you lose when playing CVS russian roulette,
you can fall back to the project specified version? Of course the
question that brings up is how to determine if soemthing like JUnit,
which you build from the CVS head, is 'correct'.
But I still don't see where the problem comes in for the non-functional
dependencies. Has anyone run across this, including all the parts
needed to build in a project download, and having it 'go wrong'?
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
