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. 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.
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.
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?
I think this is a fundamental flaw in your idea that projects should
maintain their own dependency information. 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.
Scarab is up to about 30+ external dependencies and growing...it is getting
nearly impossible to keep track of all of their sub dependencies.
-jon
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
