On Mon, 2002-03-25 at 19:54, Jon Scott Stevens wrote:
> 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.
So those shouldn't go in the repository. That's simple enough. How to
deal with several changes made in a repository a day is another matter
to sort out.
> > 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.
That's what I'm trying to promote with the use of Maven, cross project
uniformity in the area of development, building and documentation. The
problems that are encountered and the solutions that ensue are part of
the process.
> >> 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.
And I'm interested in making this type of build work, but I went for the
low-hanging fruit first which are projects that build against JARs that
are retrieved from a common repository.
> >> 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?
>
> ?
In this case here there is a backward incompatibility and you would try
to sort it out.
> > 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...
Well, we could start by not putting those sorts of things into the
repository. Even if you put 10 different versions into central
repository they could be differentiated by name but really there should
be a practice of only updating the repository on a periodic basis, not
for every change. But I think what you're really looking for is the
ability to build against sources you have checked out which is a fair
and I will try to make that work.
> 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.
My mistake, two jars with xml parser APIs.
> > 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.
Well, we just plain don't agree there. I can't see how dependency
management is not the sole responsibility of the project.
> > 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.
Yes, but I'm not the only developer here. You can do just as much as I
can to make the Gump build work. I'm taking a different approach which I
feel will be sustainable in the long. I consider the failures temporary.
I don't agree with the way Gump works, but that shouldn't stop you from
editing the gump descriptors.
> >> 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.
I'm am trying to look beyond a single project here. I don't feel the
system is broken. Many of us now can build with Maven and it is by no
means perfect but I will make it work. Even for you if you will give it
half a chance. If you are looking to build against sources you have
checked out then I can do that.
I'm not going to stop trying to make Maven work and it's not only me at
this point. For this one aspect of Turbine, there has never been more
cooperation among our developers in trying to get Maven to work. I don't
believe I'm alone when I say that I think Maven will ultimately make
this whole process easier and make the inter project processes easier
too.
> -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]>
