on 3/25/02 2:06 PM, "Jason van Zyl" <[EMAIL PROTECTED]> wrote:
> If you point at a specific version then it shouldn't matter where you
> point, right?
The problem is that the -dev version of a .jar means nothing specific. It is
the date that it was built that has meaning. If that .jar file is checked
into cvs, then it has added meaning based on cvs version number assigned to
it.
> You are having a problem because we are using different versions but we
> are not distinguishing between the versions in the name. The JAR in the
> central lib.repo is named commons-beanutils.jar and so is the one you
> have on your system. So they have to be versioned at which point the
> update-jars process whould have brought down the jar you needed. You
> would have been able to build scarab and maven each with their own
> version.
>
> I think this is a matter of process and the central lib repo hasn't been
> cleaned up because there still really hasn't been much of a consensus
> about the structure of the central repository.
Bingo.
>> This is also why Gump is so friggen
>> important. Building everything from CVS head and making sure it doesn't
>> break each other is very important and this proves it.
>
> No argument here. I'm not sure how this is relevant to the problem at
> hand. You had a problem building because versions weren't distinguished
> and because you built with an unreleased jar. I'm not sure how craig
> intends for the next release of the commons-logging API to be runtime
> compatible which is the problem.
Right...well, scarab tends to rely on cutting edge because it has been the
motivation for quite a lot of development...especially with things like
Torque...I personally don't believe in working around bugs or missing
features...I would much rather fix the bug or add the feature to the primary
project and use the version of the .jar with the fix in it.
>> You can't rely on a .jar file name to be the same one that you are using.
>> You need external data, such as a CVS version number, to back up that
>> information.
>
> What? I find that a little hard to swallow. Most projects are not like
> Scarab in that you try to build everything from CVS all the time and
> check in the result of the build you just did. Not that this can't be
> accommodated: if you want to build from your checked out version a of
> project then that should be allowed.
>
> But I think that most projects try to build from a released version of a
> project.
Right and scarab doesn't.
>> In this case, my ${lib.repo} could contain:
>>
>> commons-logging-1.0.jar
>> commons-logging-1.0-r1.8.jar
>> commons-logging-1.0-r1.9.jar
>>
>> One thing that currently bothers me the most is that there are 5 turbine
>> projects all with different dependencies on individual jar file versions
>> because you or someone else forgets or doesn't have the time to remember to
>> update the deps.list file correctly. However, each of these turbine projects
>> are used together. For example, one *might* have:
>>
>> jakarta-turbine-3
>> commons-logging-0.1.jar
>> jakarta-turbine-fulcrum
>> commons-logging-0.2.jar
>>
>> Now, Scarab depends on both projects, am I expected to also check in two
>> different .jar files and somehow make them work together?
>
> What would you do if Turbine 3 and Fulcrum were actually separate
> projects?
?
> Turbine 3 has a stated dependency of servlet-2.2.jar, you have a
> snapshot of the servlet api from December checked into Scarab's CVS and
> tomcat4 uses the 2.3 servlet API. How do you get all those to work
> together?
We only build against that .jar file. We don't actually use it. Since things
are backwards compatible, it isn't an issue.
> You also have a velocity-1.3-dev.jar checked into Scarab's CVS which
> more then likely different than other people's velocity-1.3-dev.jar
> because it is just that, a dev jar. How do you get those to work
> together?
Bingo...that is the problem I'm talking about...no way to know and
update-jars isn't good with that either because things are just in the
filesystem and not checked into CVS...
nice things is that vel has been very backwards compatible.
> You've got two versions of xerces jars in your CVS. How do you make
> those work?
No I don't.
> Torque has a stated dependency of village 1.5.2 and you've got 1.5.3
> checked into Scarab's CVS. How do you make those work together?
They are backwards compatible.
> We somehow manage to get things to work. And it will get better as the
> process gets fleshed out.
>
>> I think this is a fundamental flaw in your idea that projects should
>> maintain their own dependency information.
>
> Huh? What do you call deps.list, or default.properties, or a
> build.properties with all the listed JARs required for building.
A flaw.
> Projects track their dependency information, it's part of a project's
> routine and I would argue that they have to in order to make any sort of
> real dependency resolution possible. Sam admittedly fixes things by
> trial and error because he is not familiar with projects dependencies.
> If each project stated it's direct dependencies a graph can constructed
> that will include direct and indirect dependencies for a particular
> project. I argue this can be done without keeping everything together:
> the information may be gathered together periodically to perform a
> massive builds but it's not required they be stored together.
I haven't seen Turbine* correctly build in Gump in a LONG time.
>> I think that Sam was on the right
>> track with having everything stored in a central location because it makes
>> it easier to keep track of things.
>
> I don't see how any group of individuals can track a projects
> dependencies more accurately then the developers themselves. I don't
> think I've seen a single individual supply a patch for a gump descriptor
> that wasn't from Jakarta, or if there have been it's been so few and far
> between that I forget. Managing dependency information is the domain of
> the project.
>
>> Scarab is up to about 30+ external dependencies and growing...it is getting
>> nearly impossible to keep track of all of their sub dependencies.
>
> Yes, it would can become very difficult without a graph which is what I
> fully intend to use. So if it becomes nearly impossible for you to track
> Scarab's dependencies what are you going to do? Again I'm not sure what
> you're driving at.
I'm driving at the fact that the current system is broken.
-jon
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
