On Mon, 2002-03-25 at 15:55, Jon Scott Stevens wrote:
> Maven's build-bootstrap.xml has lines like this...
>
> <path id="classpath">
> <pathelement location="${lib.repo}/dom4j-1.3.jar"/>
> <pathelement location="${lib.repo}/commons-util-1.0-rc2-dev.jar"/>
> <pathelement location="${lib.repo}/commons-lang-0.1-dev.jar"/>
> <pathelement location="${lib.repo}/commons-beanutils.jar"/>
> <pathelement location="${lib.repo}/commons-collections.jar"/>
> <pathelement location="${lib.repo}/commons-io.jar"/>
> <pathelement location="${lib.repo}/commons-graph.jar"/>
> <pathelement location="${lib.repo}/log4j-1.1.3.jar"/>
> <pathelement location="${lib.repo}/stratum-1.0-b2-dev.jar"/>
> <pathelement location="${lib.repo}/velocity-1.3-dev.jar"/>
> <pathelement location="${basedir}/bootstrap"/>
> </path>
>
> Thus, it makes it very difficult to build because I have no way to
> externally define the names of the .jar files.
I'm not sure I understand.
There is an update-jars target in the bootstrap that will bring down the
necessary jars. We want these specific versions used because that's what
we've tested with.
> -jon
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
On Mon, 2002-03-25 at 21:07, Jon Scott Stevens wrote: > on 3/25/02 4:50 PM, "Jason van Zyl" <jv...@zenplex.com> wrote: > > > 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. > > But I also don't feel comfortable fixing things because the way I would do > things is much differently than the way that you would do things. In an attempt to get things working with Gump I have asked Sam that he make a concession and not try to build Maven (which has a circ dep problem), but let me install it on the main Gump machine so that I can get try to get the turbine builds working. > > If you are looking to build against sources you have > > checked out then I can do that. > > I think I have been saying that all along. Gump is the same thing. Building > against sources one has checked out. > > > 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. > > When? I am trying right by getting Maven integrated with Gump! > -jon > > > -- > To unsubscribe, e-mail: <ma...@jakarta.apache.org> > For additional commands, e-mail: <ma...@jakarta.apache.org> -- jvz. Jason van Zyl jvanzyl@apache.org http://tambora.zenplex.org -- To unsubscribe, e-mail: <ma...@jakarta.apache.org> For additional commands, e-mail: <ma...@jakarta.apache.org>
On Mon, 2002-03-25 at 21:07, Jon Scott Stevens wrote: > on 3/25/02 4:50 PM, "Jason van Zyl" <jv...@zenplex.com> wrote: > > > 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. > > But I also don't feel comfortable fixing things because the way I would do > things is much differently than the way that you would do things. That may be so, but that has little or nothing to do with the gump descriptors. All you have to do is edit the gump descriptors they don't have any bearing on the turbine repositories or the way we build anything. So if we are strictly talking about making the gump build work then you should have felt free to do whatever you saw fit. At this point I am now in the gump.covalent.net machine and have installed Maven and am trying to integrate Maven with Gump. Sam has let me bypass the circular dependency problem that I encountered the first time I tried this in order to get things going again. > > If you are looking to build against sources you have > > checked out then I can do that. > > I think I have been saying that all along. Gump is the same thing. Building > against sources one has checked out. You do not do the same thing that Gump does. Distinctly different. You do not build xerces and ant before you build Scarab. You are selective in what you build from sources. This is the kind of build I'm talking about, the kind of build you and I actually do on a daily basis. I don't think you would want to use Gump for your Scarab runbox. > > 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. > > When? I am trying right now. > -jon > > > -- > To unsubscribe, e-mail: <ma...@jakarta.apache.org> > For additional commands, e-mail: <ma...@jakarta.apache.org> -- jvz. Jason van Zyl jvanzyl@apache.org http://tambora.zenplex.org -- To unsubscribe, e-mail: <ma...@jakarta.apache.org> For additional commands, e-mail: <ma...@jakarta.apache.org>
on 3/25/02 4:50 PM, "Jason van Zyl" <jv...@zenplex.com> wrote: > 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. But I also don't feel comfortable fixing things because the way I would do things is much differently than the way that you would do things. > If you are looking to build against sources you have > checked out then I can do that. I think I have been saying that all along. Gump is the same thing. Building against sources one has checked out. > 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. When? -jon -- To unsubscribe, e-mail: <ma...@jakarta.apache.org> For additional commands, e-mail: <ma...@jakarta.apache.org>
On Mon, 2002-03-25 at 19:54, Jon Scott Stevens wrote:
> on 3/25/02 2:06 PM, "Jason van Zyl" <jv...@zenplex.com> 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
on 3/25/02 2:06 PM, "Jason van Zyl" <jv...@zenplex.com> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
On Mon, 2002-03-25 at 17:11, Jon Scott Stevens wrote:
> on 3/25/02 12:42 PM, "Jason van Zyl" <jv...@zenplex.com> wrote:
>
> > On Mon, 2002-03-25 at 16:33, Jon Scott Stevens wrote:
> >> on 3/25/02 12:16 PM, "Jason van Zyl" <jv...@zenplex.com> 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
on 3/25/02 12:42 PM, "Jason van Zyl" <jv...@zenplex.com> wrote:
> On Mon, 2002-03-25 at 16:33, Jon Scott Stevens wrote:
>> on 3/25/02 12:16 PM, "Jason van Zyl" <jv...@zenplex.com> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
On Mon, 2002-03-25 at 16:33, Jon Scott Stevens wrote: > on 3/25/02 12:16 PM, "Jason van Zyl" <jv...@zenplex.com> 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. 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. > -jon > > [220][ ~/checkout/jakarta-turbine-maven ]% dir > total 56 > 0 drwxrwxr-x 17 jon staff 534 Mar 25 13:11 ./ > 0 drwxr-xr-x 120 jon staff 4036 Mar 25 12:40 ../ > 4 -rw-rw-r-- 1 jon staff 43 Feb 21 19:47 .cvsignore > 0 drwxrwxr-x 7 jon staff 194 Mar 25 12:40 CVS/ > 0 drwxrwxr-x 3 jon staff 58 Mar 25 13:11 bootstrap/ > 0 -rw-rw-r-- 1 jon staff 0 Mar 25 13:11 bootstrap.report > 12 -rw-rw-r-- 1 jon staff 8360 Mar 24 15:17 build-bootstrap.xml > 4 -rw-rw-r-- 1 jon staff 3574 Mar 14 14:23 build.xml > 0 drwxrwxr-x 5 jon staff 126 Mar 25 12:40 conf/ > 4 -rw-rw-r-- 1 jon staff 1215 Mar 24 13:09 jakarta-turbine-maven.xml > 0 drwxrwxr-x 2 jon staff 24 Mar 25 13:11 maven/ > 4 -rw-rw-r-- 1 jon staff 762 Mar 14 17:36 project.properties > 8 -rw-rw-r-- 1 jon staff 7452 Mar 24 10:16 project.xml > 4 -rw-rw-r-- 1 jon staff 321 Mar 25 09:12 release-todo > 0 drwxrwxr-x 13 jon staff 398 Mar 25 12:41 src/ > 16 -rw-rw-r-- 1 jon staff 13668 Mar 25 13:11 velocity.log > 0 drwxrwxr-x 28 jon staff 908 Mar 25 12:41 xdocs/ > [221][ ~/checkout/jakarta-turbine-maven ]% ant -f build-bootstrap.xml > update-jars > Buildfile: build-bootstrap.xml > > update-jars: > [get] Getting: > http://jakarta.apache.org/turbine/jars/stratum-1.0-b2-dev.jar > [get] Not modified - so not downloaded > [get] Getting: http://jakarta.apache.org/turbine/jars/log4j-1.1.3.jar > [get] Not modified - so not downloaded > [get] Getting: > http://jakarta.apache.org/turbine/jars/velocity-1.3-dev.jar > [get] Not modified - so not downloaded > [get] Getting: http://jakarta.apache.org/turbine/jars/dom4j-1.3.jar > [get] Not modified - so not downloaded > [get] Getting: > http://jakarta.apache.org/turbine/jars/commons-util-1.0-rc2-dev.jar > [get] Not modified - so not downloaded > [get] Getting: > http://jakarta.apache.org/turbine/jars/commons-graph.jar > [get] Not modified - so not downloaded > [get] Getting: > http://jakarta.apache.org/turbine/jars/commons-lang-0.1-dev.jar > [get] Not modified - so not downloaded > [get] Getting: http://jakarta.apache.org/turbine/jars/commons-io.jar > [get] Not modified - so not downloaded > [get] Getting: > http://jakarta.apache.org/turbine/jars/commons-beanutils.jar > [get] Not modified - so not downloaded > [get] Getting: > http://jakarta.apache.org/turbine/jars/commons-collections.jar > [get] Not modified - so not downloaded > [get] Getting: > http://jakarta.apache.org/turbine/jars/velocity-dvsl-0.43.jar > [get] Not modified - so not downloaded > [get] Getting: http://jakarta.apache.org/turbine/jars/jdepend.jar > [get] Not modified - so not downloaded > > BUILD SUCCESSFUL > > Total time: 4 seconds > [222][ ~/checkout/jakarta-turbine-maven ]% ant -f build-bootstrap.xml > Buildfile: build-bootstrap.xml > > compile: > [delete] Deleting directory > /Users/jon/checkout/jakarta-turbine-maven/bootstrap > [mkdir] Created dir: /Users/jon/checkout/jakarta-turbine-maven/bootstrap > [javac] Compiling 19 source files to > /Users/jon/checkout/jakarta-turbine-maven/bootstrap > [jar] Building jar: /Users/jon/java/maven.jar > > generate-build: > [delete] Deleting directory > /Users/jon/checkout/jakarta-turbine-maven/maven > [mkdir] Created dir: /Users/jon/checkout/jakarta-turbine-maven/maven > [echo] > maven.home = /Users/jon/maven > > [create-build-system] Generating to file > /Users/jon/checkout/jakarta-turbine-maven/bootstrap.report > > BUILD FAILED > > java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory > at > org.apache.commons.beanutils.ConvertUtils.<clinit>(ConvertUtils.java) > at org.apache.stratum.xo.Mapper.treeWalk(Unknown Source) > at org.apache.stratum.xo.Mapper.map(Unknown Source) > at org.apache.stratum.xo.Mapper.map(Unknown Source) > at org.apache.stratum.xo.Mapper.map(Unknown Source) > at > org.apache.maven.BaseProjectTask.initControlContext(BaseProjectTask.java:116 > ) > at > org.apache.velocity.texen.ant.TexenTask.execute(TexenTask.java:480) > at > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:104) > at org.apache.tools.ant.Task.perform(Task.java:217) > at org.apache.tools.ant.Target.execute(Target.java:184) > at org.apache.tools.ant.Target.performTasks(Target.java:202) > at org.apache.tools.ant.Project.executeTarget(Project.java:601) > at org.apache.tools.ant.Project.executeTargets(Project.java:560) > at org.apache.tools.ant.Main.runBuild(Main.java:454) > at org.apache.tools.ant.Main.start(Main.java:153) > at org.apache.tools.ant.Main.main(Main.java:176) > > Total time: 5 seconds > org/apache/commons/logging/LogFactory > [223][ ~/checkout/jakarta-turbine-maven ]% > > > -- > To unsubscribe, e-mail: <ma...@jakarta.apache.org> > For additional commands, e-mail: <ma...@jakarta.apache.org> -- jvz. Jason van Zyl jvanzyl@apache.org http://tambora.zenplex.org -- To unsubscribe, e-mail: <ma...@jakarta.apache.org> For additional commands, e-mail: <ma...@jakarta.apache.org>
on 3/25/02 12:16 PM, "Jason van Zyl" <jv...@zenplex.com> wrote:
> You just need to update-jars.
Sigh. I DID. Do you see a commons-logging.jar in there?
-jon
[220][ ~/checkout/jakarta-turbine-maven ]% dir
total 56
0 drwxrwxr-x 17 jon staff 534 Mar 25 13:11 ./
0 drwxr-xr-x 120 jon staff 4036 Mar 25 12:40 ../
4 -rw-rw-r-- 1 jon staff 43 Feb 21 19:47 .cvsignore
0 drwxrwxr-x 7 jon staff 194 Mar 25 12:40 CVS/
0 drwxrwxr-x 3 jon staff 58 Mar 25 13:11 bootstrap/
0 -rw-rw-r-- 1 jon staff 0 Mar 25 13:11 bootstrap.report
12 -rw-rw-r-- 1 jon staff 8360 Mar 24 15:17 build-bootstrap.xml
4 -rw-rw-r-- 1 jon staff 3574 Mar 14 14:23 build.xml
0 drwxrwxr-x 5 jon staff 126 Mar 25 12:40 conf/
4 -rw-rw-r-- 1 jon staff 1215 Mar 24 13:09 jakarta-turbine-maven.xml
0 drwxrwxr-x 2 jon staff 24 Mar 25 13:11 maven/
4 -rw-rw-r-- 1 jon staff 762 Mar 14 17:36 project.properties
8 -rw-rw-r-- 1 jon staff 7452 Mar 24 10:16 project.xml
4 -rw-rw-r-- 1 jon staff 321 Mar 25 09:12 release-todo
0 drwxrwxr-x 13 jon staff 398 Mar 25 12:41 src/
16 -rw-rw-r-- 1 jon staff 13668 Mar 25 13:11 velocity.log
0 drwxrwxr-x 28 jon staff 908 Mar 25 12:41 xdocs/
[221][ ~/checkout/jakarta-turbine-maven ]% ant -f build-bootstrap.xml
update-jars
Buildfile: build-bootstrap.xml
update-jars:
[get] Getting:
http://jakarta.apache.org/turbine/jars/stratum-1.0-b2-dev.jar
[get] Not modified - so not downloaded
[get] Getting: http://jakarta.apache.org/turbine/jars/log4j-1.1.3.jar
[get] Not modified - so not downloaded
[get] Getting:
http://jakarta.apache.org/turbine/jars/velocity-1.3-dev.jar
[get] Not modified - so not downloaded
[get] Getting: http://jakarta.apache.org/turbine/jars/dom4j-1.3.jar
[get] Not modified - so not downloaded
[get] Getting:
http://jakarta.apache.org/turbine/jars/commons-util-1.0-rc2-dev.jar
[get] Not modified - so not downloaded
[get] Getting:
http://jakarta.apache.org/turbine/jars/commons-graph.jar
[get] Not modified - so not downloaded
[get] Getting:
http://jakarta.apache.org/turbine/jars/commons-lang-0.1-dev.jar
[get] Not modified - so not downloaded
[get] Getting: http://jakarta.apache.org/turbine/jars/commons-io.jar
[get] Not modified - so not downloaded
[get] Getting:
http://jakarta.apache.org/turbine/jars/commons-beanutils.jar
[get] Not modified - so not downloaded
[get] Getting:
http://jakarta.apache.org/turbine/jars/commons-collections.jar
[get] Not modified - so not downloaded
[get] Getting:
http://jakarta.apache.org/turbine/jars/velocity-dvsl-0.43.jar
[get] Not modified - so not downloaded
[get] Getting: http://jakarta.apache.org/turbine/jars/jdepend.jar
[get] Not modified - so not downloaded
BUILD SUCCESSFUL
Total time: 4 seconds
[222][ ~/checkout/jakarta-turbine-maven ]% ant -f build-bootstrap.xml
Buildfile: build-bootstrap.xml
compile:
[delete] Deleting directory
/Users/jon/checkout/jakarta-turbine-maven/bootstrap
[mkdir] Created dir: /Users/jon/checkout/jakarta-turbine-maven/bootstrap
[javac] Compiling 19 source files to
/Users/jon/checkout/jakarta-turbine-maven/bootstrap
[jar] Building jar: /Users/jon/java/maven.jar
generate-build:
[delete] Deleting directory
/Users/jon/checkout/jakarta-turbine-maven/maven
[mkdir] Created dir: /Users/jon/checkout/jakarta-turbine-maven/maven
[echo]
maven.home = /Users/jon/maven
[create-build-system] Generating to file
/Users/jon/checkout/jakarta-turbine-maven/bootstrap.report
BUILD FAILED
java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
at
org.apache.commons.beanutils.ConvertUtils.<clinit>(ConvertUtils.java)
at org.apache.stratum.xo.Mapper.treeWalk(Unknown Source)
at org.apache.stratum.xo.Mapper.map(Unknown Source)
at org.apache.stratum.xo.Mapper.map(Unknown Source)
at org.apache.stratum.xo.Mapper.map(Unknown Source)
at
org.apache.maven.BaseProjectTask.initControlContext(BaseProjectTask.java:116
)
at
org.apache.velocity.texen.ant.TexenTask.execute(TexenTask.java:480)
at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:104)
at org.apache.tools.ant.Task.perform(Task.java:217)
at org.apache.tools.ant.Target.execute(Target.java:184)
at org.apache.tools.ant.Target.performTasks(Target.java:202)
at org.apache.tools.ant.Project.executeTarget(Project.java:601)
at org.apache.tools.ant.Project.executeTargets(Project.java:560)
at org.apache.tools.ant.Main.runBuild(Main.java:454)
at org.apache.tools.ant.Main.start(Main.java:153)
at org.apache.tools.ant.Main.main(Main.java:176)
Total time: 5 seconds
org/apache/commons/logging/LogFactory
[223][ ~/checkout/jakarta-turbine-maven ]%
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
On Mon, 2002-03-25 at 16:12, Jon Scott Stevens wrote: > Also...seems someone forgot a .jar file... > You just need to update-jars. -- jvz. Jason van Zyl jvanzyl@apache.org http://tambora.zenplex.org -- To unsubscribe, e-mail: <ma...@jakarta.apache.org> For additional commands, e-mail: <ma...@jakarta.apache.org>
Also...seems someone forgot a .jar file...
BUILD FAILED
java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
at
org.apache.commons.beanutils.ConvertUtils.<clinit>(ConvertUtils.java)
at org.apache.stratum.xo.Mapper.treeWalk(Unknown Source)
at org.apache.stratum.xo.Mapper.map(Unknown Source)
at org.apache.stratum.xo.Mapper.map(Unknown Source)
at org.apache.stratum.xo.Mapper.map(Unknown Source)
at
org.apache.maven.BaseProjectTask.initControlContext(BaseProjectTask.java:116
)
at
org.apache.velocity.texen.ant.TexenTask.execute(TexenTask.java:480)
at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:104)
at org.apache.tools.ant.Task.perform(Task.java:217)
at org.apache.tools.ant.Target.execute(Target.java:184)
at org.apache.tools.ant.Target.performTasks(Target.java:202)
at org.apache.tools.ant.Project.executeTarget(Project.java:601)
at org.apache.tools.ant.Project.executeTargets(Project.java:560)
at org.apache.tools.ant.Main.runBuild(Main.java:454)
at org.apache.tools.ant.Main.start(Main.java:153)
at org.apache.tools.ant.Main.main(Main.java:176)
Total time: 5 seconds
org/apache/commons/logging/LogFactory
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
On Mon, 2002-03-25 at 16:10, Jon Scott Stevens wrote:
> on 3/25/02 11:55 AM, "Jason van Zyl" <jv...@zenplex.com> wrote:
>
> >> <path id="classpath">
> >> <pathelement location="${lib.repo}/dom4j-1.3.jar"/>
> >> <pathelement location="${lib.repo}/commons-util-1.0-rc2-dev.jar"/>
> >> <pathelement location="${lib.repo}/commons-lang-0.1-dev.jar"/>
> >> <pathelement location="${lib.repo}/commons-beanutils.jar"/>
> >> <pathelement location="${lib.repo}/commons-collections.jar"/>
> >> <pathelement location="${lib.repo}/commons-io.jar"/>
> >> <pathelement location="${lib.repo}/commons-graph.jar"/>
> >> <pathelement location="${lib.repo}/log4j-1.1.3.jar"/>
> >> <pathelement location="${lib.repo}/stratum-1.0-b2-dev.jar"/>
> >> <pathelement location="${lib.repo}/velocity-1.3-dev.jar"/>
> >> <pathelement location="${basedir}/bootstrap"/>
> >> </path>
> >>
> >> Thus, it makes it very difficult to build because I have no way to
> >> externally define the names of the .jar files.
> >
> > I'm not sure I understand.
> >
> > There is an update-jars target in the bootstrap that will bring down the
> > necessary jars. We want these specific versions used because that's what
> > we've tested with.
>
> My dom4j-1.3.jar is called: "dom4j-full-1.3.jar"
>
> How can I set that?
You can't and we don't want you to because in that particular case there
is a parser included in the jar which can potentially cause problems.
I've even add a build-bootstrap.sh script so that it's easier.
As a general rule of process I think that the 'full' variety of jars be
avoided and let the update-jars take care of pulling down what's
necessary as people always run into problems with xml parsers being
included (like in xmlrpc) and having logkit stuffed in the 'full'
velocity jar.
> -jon
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
on 3/25/02 11:55 AM, "Jason van Zyl" <jv...@zenplex.com> wrote:
>> <path id="classpath">
>> <pathelement location="${lib.repo}/dom4j-1.3.jar"/>
>> <pathelement location="${lib.repo}/commons-util-1.0-rc2-dev.jar"/>
>> <pathelement location="${lib.repo}/commons-lang-0.1-dev.jar"/>
>> <pathelement location="${lib.repo}/commons-beanutils.jar"/>
>> <pathelement location="${lib.repo}/commons-collections.jar"/>
>> <pathelement location="${lib.repo}/commons-io.jar"/>
>> <pathelement location="${lib.repo}/commons-graph.jar"/>
>> <pathelement location="${lib.repo}/log4j-1.1.3.jar"/>
>> <pathelement location="${lib.repo}/stratum-1.0-b2-dev.jar"/>
>> <pathelement location="${lib.repo}/velocity-1.3-dev.jar"/>
>> <pathelement location="${basedir}/bootstrap"/>
>> </path>
>>
>> Thus, it makes it very difficult to build because I have no way to
>> externally define the names of the .jar files.
>
> I'm not sure I understand.
>
> There is an update-jars target in the bootstrap that will bring down the
> necessary jars. We want these specific versions used because that's what
> we've tested with.
My dom4j-1.3.jar is called: "dom4j-full-1.3.jar"
How can I set that?
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
On Mon, 2002-03-25 at 16:13, Jon Scott Stevens wrote: > ant -f build-bootstrap.xml clean > Buildfile: build-bootstrap.xml > > BUILD FAILED > > Target `clean' does not exist in this project. In this case running to bootstrap again wipes everything out before proceeding with the bootstrap process. > Total time: 1 second > > > -jon > > > -- > To unsubscribe, e-mail: <ma...@jakarta.apache.org> > For additional commands, e-mail: <ma...@jakarta.apache.org> -- jvz. Jason van Zyl jvanzyl@apache.org http://tambora.zenplex.org -- To unsubscribe, e-mail: <ma...@jakarta.apache.org> For additional commands, e-mail: <ma...@jakarta.apache.org>
ant -f build-bootstrap.xml clean Buildfile: build-bootstrap.xml BUILD FAILED Target `clean' does not exist in this project. Total time: 1 second -jon -- To unsubscribe, e-mail: <ma...@jakarta.apache.org> For additional commands, e-mail: <ma...@jakarta.apache.org>