Some thoughts on the dependency handling.
Currently http is used to get the needed jars. I assume that adding ftp as
well won't be hard. If a project is in the same cvs repository as another
project that is dependant on, I might want to specify that that jar's
dependency is found in cvs.
Dependency tree. Where will this reside? For example. Three projects, A B
and C. A depends on B, B depends on C. A is a maven'd project. I update
the jars and my repository is asked for B. I assume here that somehow my
repository needs to know the dependency tree for each jar it handles, I'm
going to hypothesis that there is a dependencies.xml file (or its in
Manifest or whatever). So When I ask for B, I somehow notice I need C
too and get that.
What if B is a maven'd project? It seems to me that it already has its
dependency tree in its project.xml. So there's no need to have the
separate dependency graph, instead when I ask for B (be it thru whatever
protocol) my request notices it is a maven'd project and I update-jars
using its project.xml.
Just my consumer ideas :)
Hen
On 13 Apr 2002, Jason van Zyl wrote:
> On Sat, 2002-04-13 at 08:50, Christian Willy Asmussen wrote:
> > Dear mavens,
> > I just started a new project using maven. For this project I needed torque
> > (decoupled). So I added torque to my POM dependencies in project.xml. All
> > worked fine, maven:update-jars fetched torque.jar just like I expected.
> > Then I wrote a little testing task, like this:
> >
> > <available
> > classpathref="classpath"
> > property="torque.present"
> > classname="org.apache.torque.Torque"
> > />
> >
> > For my surprise, ${torque.present} was never set. I changed it to
> > org.apache.torque.util.SqlEnum and then it worked. So I figured torque's
> > jar was on my classpath. After running and with -debug option several
> > times, I found out that Torque class could not be loaded because some of
> > it's dependencies weren't present. So I copied most of the dependencies
> > from torque's project.xml and then it worked.
> >
> > Question/Suggestion is:
> > - Shouldn't Maven take care of this? The information needed is there and
> > the process is always the same.
>
> Maven will do this not in b4 but in b5. We're using the graph package in
> the commons sandbox so that a project only has to state its direct
> dependencies.
>
> >
> > tks,
> > krico
> > --
> > There is no limit to what you can do
> > if you don't care who gets the credit.
> > - Keynote
> --
> jvz.
>
> Jason van Zyl
> [EMAIL PROTECTED]
>
> http://tambora.zenplex.org
>
>
