On Mon, 2002-03-25 at 17:11, Jon Scott Stevens wrote:
> on 3/25/02 12:42 PM, "Jason van Zyl" <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 2002-03-25 at 16:33, Jon Scott Stevens wrote:
> >> on 3/25/02 12:16 PM, "Jason van Zyl" <[EMAIL PROTECTED]> wrote:
> >>
> >>> You just need to update-jars.
> >>
> >> Sigh. I DID. Do you see a commons-logging.jar in there?
> >
> > This will have to become a matter of process ... I am guessing that you
> > built your beanutils from CVS which craig must have updated to use the
> > commons-logging API.
>
> Yup. I needed to do that because Scarab depends on things that needed it.
>
> > The jars used for building come from the the
> > central JAR repo which is what the rest of us are building against. A
> > handful of us in irc have been building all day and jeff and I just
> > wiped out our lib.repo's and did the whole bootstrap process.
> >
> > So this is a versioning problem and has to be dealt with. As a first
> > step I think we should try to used released jars where possible unless
> > there is a severe problem with the released version.
> >
> > This is where the process starts so that we can all build reliably. I
> > think we have to decide that the central repository is _the_ source for
> > the jars used in building. I don't know how else things can be stable.
> >
> > I would definitely like to add a mode of building that allows for the
> > type of thing you and I do on a daily basis but for now the JARs used to
> > build maven are specified and they are the JARs that live in the
> > repository.
> >
> > This is totally up for discussion and it's something we should work
> > through because this is going to be a wide scale issue in general.
>
> This is why I told you to check those .jar files into CVS and point at
> specific CVS versions of them.
If you point at a specific version then it shouldn't matter where you
point, right?
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.
> 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.
> 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.
> 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?
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?
You've got two versions of xerces jars in your CVS. How do you make
those work?
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?
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.
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 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.
> -jon
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
