You are viewing a plain text version of this content. The canonical link for it is here.
Posted to alexandria-dev@jakarta.apache.org by Jason van Zyl <jv...@apache.org> on 2001/08/22 02:59:26 UTC

[gump] adding version info

Hi Sam,

Do you mind if I add some version info? I have added version info to the
jakarta-turbine-3 descriptor and everything appears fine. Geir said he would
help in making JJAR use the Gump descriptors so I'm going to make him keep
his promise! (Well it wasn't actually a promise but ... :-))

-- 

jvz.

Jason van Zyl

http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons



---------------------------------------------------------------------
To unsubscribe, e-mail: alexandria-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: alexandria-dev-help@jakarta.apache.org


Re: [gump] adding version info

Posted by Jason van Zyl <jv...@apache.org>.
On 8/22/01 12:35 AM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:

> I am on vacation for 3 days, so if you don't hear from me, that's why.
> If you do hear from me, then be startled as I didn't think I had inet
> connectivity where I am going...  One thing I do want to note - we talk
> about JJAR as real - it isn't yet, it's a nice little commons-sandbox
> project that is coming along nicely.  Something to keep in mind. More
> inline.
> 
> Jason van Zyl wrote:
>> 
>> On 8/21/01 10:05 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>> 
>>> Our discussion revolved around making JJAR work against the gump
>>> information repository rather than it's own information repository.
>>> 
>>> My personal belief is that either
>>> 
>>> 1) Gump should use JJAR to get dependency information.  Using tools is
>>> good.
>> 
>> I think that all of a projects information should be stored in a single
>> location. Gump has full inter-project dependencies, but what it lacks is the
>> version info to build a release with stated versions of packages, and the
>> project descriptors don't currently state their latest version. A few
>> additions and building a project with specific versions of packages will be
>> possible. This info will also be enough for a JJAR like task to assist with
>> a build.
> 
> Two things come to mind - First, if Gump has this all, it doesn't need
> JJAR.  Of course, if a JJAR exists, Gump should consider using it.

More to the point, Gump existed first as a tool which housed a set of
project descriptors. JJAR should have considered making additions to the
descriptors present before rolling new ones.
 
> I think that if we are going to produce a repository of project
> information, it should be such that it doesn't tie tools together.  For
> example, Gump has information thats specific to what gump does (whatever
> gump does - seems like gump is scope-creeping :).  JJAR has needs
> specific to JJAR.

Having all the information together wouldn't impede any individual tool. If
there was a common set of project descriptors and a small toolset for
parsing these descriptors (the digester tools I'm working on) than the
objects created from the parsed XML could be used in any fashion desired.
 
> So imagine that gump had gump stuff, jjar had jjar stuff, and in the
> center is a dependency repository, containing enough information for
> both to use, but no extra tool-specific drek.

You see it as an isolated dependency repository, I see it as a unified
descriptor for a project. JJAR is an example of a tool that could use the
project descriptors to glean dependency information. I don't see the
dependency information as a separate body of information, I see it as part
of the overall set of project information.

> Of course, if this was
> the case, then gump could use jjar, which would use the same info that
> gump would have referenced if it needed repository information. (Leading
> back, of course, to the "Why not just use JJAR?" question)

Again, you are basing this on the assumption that separating the dependency
information from the rest of the project information as good. I don't see it
this way. I consider the descriptors in the gump repository as the
descriptors for projects. The descriptors were started here so that Gump
could use them but I think the uses of the descriptors reaches far beyond
what Gump currently does with them. I wouldn't use JJAR because you've
duplicated everything except version numbers in the definition of a
dependency. That is very easy to add to the descriptors in the Gump
repository.

The majority of the descriptors are on the order of 1k, I think maintaining
this descriptor is well within the means of the average developer working on
a project. I think talking about the Gump descriptors as being monolithic is
a bit like making a mountain out of molehill. The dependency info is
integral to the project and that information can be used by JJAR regardless
of whatever other information is present. I think having a separate
dependency repository that is not part of what is currently available will
be a maintenance problem and uneccessary. A project descriptor right now is
primarily dependency information and I don't see the addition of version
information as problem in the slightest. It won't interfere with Gump and
the information can be used for many other tools.
 
> The counterargument might be that having one comprehensive repository of
> project information is a Good Thing (which it prollie is...).  However,
> I wonder if its possible to have that sort of beastie in a manageable
> way....  

Again, I don't consider a 1k file a beastie or burden ;-)

> projects use different build methods (we can browbeat here in
> Jakarta, but what about sourceforge and others?)

This would also include telling people to use JJAR, so what is your point.
People will choose what they choose but I would bet that the majority of
people would use a system and standards that we decided on here. I don't
think infinite flexibility in a build system is necessarily a good thing. If
this is your "people might not use ant and use make, and those </ant> tags
are drek in the descriptors" argument, well ... I don't have much sympathy
for projects that don't use ant. I'll give you that. But even this
information could be added to the descriptors but I think it uncessary
because people who use make for java projects are masochists anyway ;-)
 
>> 
>> I am fully aware of the need for version info because I plan to use Gump to
>> build distributions of the TDK in a reliable way that will let any Turbine
>> developer who wants to participate managing releases do so in a consistent
>> fashion. We obviously must use stated versions of tools. This would allow a
>> rigourous build of a distribution that would be consistent across machines.
>> 
> 
> Is this consistant with Gumps 'mission' or is this something new?
> 
>>> 2) If Gump doesn't want to depend on external tools and must define its
>>> own dependency information, then it should make that dependency set free
>>> of any gump specific schema structure or data, so that it can be shared
>>> as widely as possible and let all tools that use it (gump included)
>>> evolve in their own way w/o affecting the others.
>> 
>> Again I see it as project information as a whole, if you have a better
>> layout for dependencies I think it should be added the descriptors in the
>> gump repository. I don't see them as gump descriptors. I see them as project
>> descriptors that gump utilizes. I think that many, many tools can use these
>> descriptors JJAR among them.
> 
> I agree in theory - however, I worry about it being practical to keep a
> comprehensive repository of information.

Again, a 1k file maybe 2k if you're really lucky.
 
> The version dependency that JJAR needs is fairly simple and
> straightforward - simply a list of versions and where I can find a jar
> of each version. It doesn't matter how or where the project is created
> and managed - as long as I can grab jars, that's all JJAR needs.  It
> really is all JJAR 'customers' need.  Dumb-simple.

That's great, that information will be in the descriptors in the gump
repository. You don't even have to worry about the drek information. Take
what you need for your tool, leave the rest behind.
 
> To summarize, I am indeed willing to try and work together
> - I mean I
> did initiate by trying to figure out what Gump needs and tailoring JJAR
> to provide that.

Yes, but this discussion was never brought to the attention of anyone on the
alexandria list because I would have immediately asked why you didn't
consider augmenting the descriptors already present. You assumed people
would be pleased. Maybe they are but I'm not. I think of it as fragmenting
information that should be consolidated and would never have agreed to
separating out the the dependency information.
 
> However, I tend to be a minimalist, and wonder if Gump would be better
> off depending on another dedicated tool to provide the services that it
> needs wrt dependencies.

Why when it is simpler to augment what we have with a version attribute and
a latest version attribute? We have dependency information for 87 different
projects now, we simply need to add some version info and the descriptors
will provide information for a wider set of tools.
 
> Off to Montana.  Big sky.  No broadband.
> 
> geir

-- 

jvz.

Jason van Zyl

http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons



---------------------------------------------------------------------
To unsubscribe, e-mail: alexandria-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: alexandria-dev-help@jakarta.apache.org


Re: [gump] adding version info

Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
I am on vacation for 3 days, so if you don't hear from me, that's why. 
If you do hear from me, then be startled as I didn't think I had inet
connectivity where I am going...  One thing I do want to note - we talk
about JJAR as real - it isn't yet, it's a nice little commons-sandbox
project that is coming along nicely.  Something to keep in mind. More
inline.

Jason van Zyl wrote:
> 
> On 8/21/01 10:05 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> 
> > Our discussion revolved around making JJAR work against the gump
> > information repository rather than it's own information repository.
> >
> > My personal belief is that either
> >
> > 1) Gump should use JJAR to get dependency information.  Using tools is
> > good.
> 
> I think that all of a projects information should be stored in a single
> location. Gump has full inter-project dependencies, but what it lacks is the
> version info to build a release with stated versions of packages, and the
> project descriptors don't currently state their latest version. A few
> additions and building a project with specific versions of packages will be
> possible. This info will also be enough for a JJAR like task to assist with
> a build.

Two things come to mind - First, if Gump has this all, it doesn't need
JJAR.  Of course, if a JJAR exists, Gump should consider using it.

I think that if we are going to produce a repository of project
information, it should be such that it doesn't tie tools together.  For
example, Gump has information thats specific to what gump does (whatever
gump does - seems like gump is scope-creeping :).  JJAR has needs
specific to JJAR.

So imagine that gump had gump stuff, jjar had jjar stuff, and in the
center is a dependency repository, containing enough information for
both to use, but no extra tool-specific drek.  Of course, if this was
the case, then gump could use jjar, which would use the same info that
gump would have referenced if it needed repository information. (Leading
back, of course, to the "Why not just use JJAR?" question)

The counterargument might be that having one comprehensive repository of
project information is a Good Thing (which it prollie is...).  However,
I wonder if its possible to have that sort of beastie in a manageable
way....  projects use different build methods (we can browbeat here in
Jakarta, but what about sourceforge and others?)
 
> 
> I am fully aware of the need for version info because I plan to use Gump to
> build distributions of the TDK in a reliable way that will let any Turbine
> developer who wants to participate managing releases do so in a consistent
> fashion. We obviously must use stated versions of tools. This would allow a
> rigourous build of a distribution that would be consistent across machines.
> 

Is this consistant with Gumps 'mission' or is this something new?

> > 2) If Gump doesn't want to depend on external tools and must define its
> > own dependency information, then it should make that dependency set free
> > of any gump specific schema structure or data, so that it can be shared
> > as widely as possible and let all tools that use it (gump included)
> > evolve in their own way w/o affecting the others.
> 
> Again I see it as project information as a whole, if you have a better
> layout for dependencies I think it should be added the descriptors in the
> gump repository. I don't see them as gump descriptors. I see them as project
> descriptors that gump utilizes. I think that many, many tools can use these
> descriptors JJAR among them.

I agree in theory - however, I worry about it being practical to keep a
comprehensive repository of information.

The version dependency that JJAR needs is fairly simple and
straightforward - simply a list of versions and where I can find a jar
of each version. It doesn't matter how or where the project is created
and managed - as long as I can grab jars, that's all JJAR needs.  It
really is all JJAR 'customers' need.  Dumb-simple.

To summarize, I am indeed willing to try and work together - I mean I
did initiate by trying to figure out what Gump needs and tailoring JJAR
to provide that.

However, I tend to be a minimalist, and wonder if Gump would be better
off depending on another dedicated tool to provide the services that it
needs wrt dependencies.

Off to Montana.  Big sky.  No broadband.

geir

-- 
Geir Magnusson Jr.                           geirm@optonline.net
System and Software Consulting
Developing for the web?  See http://jakarta.apache.org/velocity/
Well done is better than well said - New England Proverb

---------------------------------------------------------------------
To unsubscribe, e-mail: alexandria-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: alexandria-dev-help@jakarta.apache.org


Re: [gump] adding version info

Posted by Jason van Zyl <jv...@apache.org>.
On 8/21/01 10:05 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:

> Our discussion revolved around making JJAR work against the gump
> information repository rather than it's own information repository.
> 
> My personal belief is that either
> 
> 1) Gump should use JJAR to get dependency information.  Using tools is
> good.

I think that all of a projects information should be stored in a single
location. Gump has full inter-project dependencies, but what it lacks is the
version info to build a release with stated versions of packages, and the
project descriptors don't currently state their latest version. A few
additions and building a project with specific versions of packages will be
possible. This info will also be enough for a JJAR like task to assist with
a build.

I am fully aware of the need for version info because I plan to use Gump to
build distributions of the TDK in a reliable way that will let any Turbine
developer who wants to participate managing releases do so in a consistent
fashion. We obviously must use stated versions of tools. This would allow a
rigourous build of a distribution that would be consistent across machines.
 
> 2) If Gump doesn't want to depend on external tools and must define its
> own dependency information, then it should make that dependency set free
> of any gump specific schema structure or data, so that it can be shared
> as widely as possible and let all tools that use it (gump included)
> evolve in their own way w/o affecting the others.

Again I see it as project information as a whole, if you have a better
layout for dependencies I think it should be added the descriptors in the
gump repository. I don't see them as gump descriptors. I see them as project
descriptors that gump utilizes. I think that many, many tools can use these
descriptors JJAR among them.
 
> I have a whole bunch of reasons for both, but I won't bore y'all with
> them.
> 
> geir
> 

-- 

jvz.

Jason van Zyl

http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons



---------------------------------------------------------------------
To unsubscribe, e-mail: alexandria-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: alexandria-dev-help@jakarta.apache.org


Re: [gump] adding version info

Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Jason van Zyl wrote:
> 
> On 8/21/01 9:50 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> 
> > Jason van Zyl wrote:
> >>
> >> On 8/21/01 9:16 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> >>
> >>> Jason van Zyl wrote:
> >>>>
> >>>> Hi Sam,
> >>>>
> >>>> Do you mind if I add some version info? I have added version info to the
> >>>> jakarta-turbine-3 descriptor and everything appears fine. Geir said he
> >>>> would
> >>>> help in making JJAR use the Gump descriptors so I'm going to make him keep
> >>>> his promise! (Well it wasn't actually a promise but ... :-))
> >>>
> >>> I don't think it was even close to a promise...
> >>
> >> I will interpret that as you're not interested in helping. Fair enough, as
> >> long as we're clear on the issue.
> >
> > Huh?  You even stated above it wasn't a promise.
> 
> I was joking about the promise. You simply said you would help in the
> attempt to make JJAR work with the descriptors in the gump repository,
> that's all. I interpreted the 'not even close to a promise' bit as meaning
> it's not likely you will help. Feel free to clarify the point.

No problem.

Our discussion revolved around making JJAR work against the gump
information repository rather than it's own information repository.

My personal belief is that either

1) Gump should use JJAR to get dependency information.  Using tools is
good.

2) If Gump doesn't want to depend on external tools and must define its
own dependency information, then it should make that dependency set free
of any gump specific schema structure or data, so that it can be shared
as widely as possible and let all tools that use it (gump included)
evolve in their own way w/o affecting the others.

I have a whole bunch of reasons for both, but I won't bore y'all with
them.

geir


-- 
Geir Magnusson Jr.                           geirm@optonline.net
System and Software Consulting
Developing for the web?  See http://jakarta.apache.org/velocity/
Well done is better than well said - New England Proverb

---------------------------------------------------------------------
To unsubscribe, e-mail: alexandria-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: alexandria-dev-help@jakarta.apache.org


Re: [gump] adding version info

Posted by Jason van Zyl <jv...@apache.org>.
On 8/21/01 9:50 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:

> Jason van Zyl wrote:
>> 
>> On 8/21/01 9:16 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>> 
>>> Jason van Zyl wrote:
>>>> 
>>>> Hi Sam,
>>>> 
>>>> Do you mind if I add some version info? I have added version info to the
>>>> jakarta-turbine-3 descriptor and everything appears fine. Geir said he
>>>> would
>>>> help in making JJAR use the Gump descriptors so I'm going to make him keep
>>>> his promise! (Well it wasn't actually a promise but ... :-))
>>> 
>>> I don't think it was even close to a promise...
>> 
>> I will interpret that as you're not interested in helping. Fair enough, as
>> long as we're clear on the issue.
> 
> Huh?  You even stated above it wasn't a promise.

I was joking about the promise. You simply said you would help in the
attempt to make JJAR work with the descriptors in the gump repository,
that's all. I interpreted the 'not even close to a promise' bit as meaning
it's not likely you will help. Feel free to clarify the point.

-- 

jvz.

Jason van Zyl

http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons



---------------------------------------------------------------------
To unsubscribe, e-mail: alexandria-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: alexandria-dev-help@jakarta.apache.org


Re: [gump] adding version info

Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Jason van Zyl wrote:
> 
> On 8/21/01 9:16 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> 
> > Jason van Zyl wrote:
> >>
> >> Hi Sam,
> >>
> >> Do you mind if I add some version info? I have added version info to the
> >> jakarta-turbine-3 descriptor and everything appears fine. Geir said he would
> >> help in making JJAR use the Gump descriptors so I'm going to make him keep
> >> his promise! (Well it wasn't actually a promise but ... :-))
> >
> > I don't think it was even close to a promise...
> 
> I will interpret that as you're not interested in helping. Fair enough, as
> long as we're clear on the issue.

Huh?  You even stated above it wasn't a promise.

-- 
Geir Magnusson Jr.                           geirm@optonline.net
System and Software Consulting
Developing for the web?  See http://jakarta.apache.org/velocity/
Well done is better than well said - New England Proverb

---------------------------------------------------------------------
To unsubscribe, e-mail: alexandria-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: alexandria-dev-help@jakarta.apache.org


Re: [gump] adding version info

Posted by Jason van Zyl <jv...@apache.org>.
On 8/21/01 9:16 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:

> Jason van Zyl wrote:
>> 
>> Hi Sam,
>> 
>> Do you mind if I add some version info? I have added version info to the
>> jakarta-turbine-3 descriptor and everything appears fine. Geir said he would
>> help in making JJAR use the Gump descriptors so I'm going to make him keep
>> his promise! (Well it wasn't actually a promise but ... :-))
> 
> I don't think it was even close to a promise...

I will interpret that as you're not interested in helping. Fair enough, as
long as we're clear on the issue.

-- 

jvz.

Jason van Zyl

http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons



---------------------------------------------------------------------
To unsubscribe, e-mail: alexandria-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: alexandria-dev-help@jakarta.apache.org


Re: [gump] adding version info

Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Jason van Zyl wrote:
> 
> Hi Sam,
> 
> Do you mind if I add some version info? I have added version info to the
> jakarta-turbine-3 descriptor and everything appears fine. Geir said he would
> help in making JJAR use the Gump descriptors so I'm going to make him keep
> his promise! (Well it wasn't actually a promise but ... :-))

I don't think it was even close to a promise...

-- 
Geir Magnusson Jr.                           geirm@optonline.net
System and Software Consulting
Developing for the web?  See http://jakarta.apache.org/velocity/
Well done is better than well said - New England Proverb

---------------------------------------------------------------------
To unsubscribe, e-mail: alexandria-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: alexandria-dev-help@jakarta.apache.org