The tax man can wait...
Sam Ruby wrote:
>
> Geir Magnusson Jr. wrote:
> >
> > Geir :
> > > I believe that if you are depending
> > > upon a specific released version of a jar
> >
> > Sam:
> > > ....Important bulletin: we interrup this quote to bring you the preferred
> > > completion of this sentence:
> > >
> > > DON'T.
> >
> > And I believe you will state below that you want to 'gump' the
> > automation of things with "exact versions" of dependant jars...
> >
> > If you are doing exact versions anyway, from tagged CVS, what's the
> > point? What changes from day to day?
>
> I do not advocate early binding of any project to exact versions of any
> dependency, from tagged CVS or from any other location.
That's not the issue. It's a build-script dependency that I am
advocating a solution for, not a functional one. And didn't you just
suggest exactly that in the last post? In the context of a snapshot for
users :
Sam Ruby :
>> Now, can we begin a discussion as to what would be maximally useful?
>> Let me start:
>>
>> I believe that a snapshot of *just* the sources of cactus, combined with
>> the exact versions of the dependent jars needed to produce what you see
>> posted on the gump site would be useful to some. That way if Gump
>> reports an error, you can download and unpack a single file and
>> reproduce it. Does anybody else think this would be useful?
And I did have a question about the utility of gump created jars from
CVS versus just having a jar included.
>
> Let me try a different approach. The various jakarta-avalon subprojects
> have jars checked into cvs. Their build processes even default to those
> jars. However, they make it very simple for a developer to substitute
> another version. No need to modify any files in the "image" that you get
> either by doing a cvs checkout or a download of a tgz or zip.
I assume you agree with this? If so, why not do this? I just want a
solution. Doesn't have to be mine :)
>
> I do not advocate early binding of any project to exact versions of any
> dependency, from tagged CVS or from any other location.
That's not the issue. It's a build-script dependency that I am
advocating a solution for, not a functional one. And didn't you just
suggest exactly that in the last post? In the context of a snapshot for
users :
Sam Ruby :
>> Now, can we begin a discussion as to what would be maximally useful?
>> Let me start:
>>
>> I believe that a snapshot of *just* the sources of cactus, combined with
>> the exact versions of the dependent jars needed to produce what you see
>> posted on the gump site would be useful to some. That way if Gump
>> reports an error, you can download and unpack a single file and
>> reproduce it. Does anybody else think this would be useful?
And I did have a question about the utility of gump created jars from
CVS versus just having a jar included.
>
> Commons will fail if it continues down the path of the Turbine tribe.
>
Isn't this the same path as all the other Jakarta projects I just
mentioned? I think the only two Jakarta projects that didn't have jars
were taglibs and struts...
What are you talking about, "the Turbine 'tribe'", and what does it have
to do with this?
> I do not advocate early binding of any project to exact versions of any
> dependency, from tagged CVS or from any other location.
That's not the issue. It's a build-script dependency that I am
advocating a solution for, not a functional one. And didn't you just
suggest exactly that in the last post? In the context of a snapshot for
users :
Sam Ruby :
>> Now, can we begin a discussion as to what would be maximally useful?
>> Let me start:
>>
>> I believe that a snapshot of *just* the sources of cactus, combined with
>> the exact versions of the dependent jars needed to produce what you see
>> posted on the gump site would be useful to some. That way if Gump
>> reports an error, you can download and unpack a single file and
>> reproduce it. Does anybody else think this would be useful?
And I did have a question about the utility of gump created jars from
CVS versus just having a jar included.
>
> - Sam Ruby
>
> P.S. I do not advocate early binding of any project to exact versions of
> any dependency, from tagged CVS or from any other location.
P.S. That's not the issue. It's a build-script dependency that I am
advocating a solution for, not a functional one. And didn't you just
suggest exactly that in the last post? In the context of a snapshot for
users :
Sam Ruby :
>> Now, can we begin a discussion as to what would be maximally useful?
>> Let me start:
>>
>> I believe that a snapshot of *just* the sources of cactus, combined with
>> the exact versions of the dependent jars needed to produce what you see
>> posted on the gump site would be useful to some. That way if Gump
>> reports an error, you can download and unpack a single file and
>> reproduce it. Does anybody else think this would be useful?
And I did have a question about the utility of gump created jars from
CVS versus just having a jar included.
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
