You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Age Mooy <am...@home.nl> on 2003/03/04 23:11:52 UTC
POM repository and dependency references
Hi,
Jason has mentioned the idea of a POM repository a few times on this
list. I don't know exactly what he proposes to do with it but I have
also been thinking about something like that lately.
I have built quite a lot of Turbine 2.x/Torque webapps the last few
months and when writing the project.xml for these projects, I keep
running into the same problem. For each new webapp project I have to
manually copy all the dependencies from the turbine-2 and db-torque
project descriptors. If I upgrade from Turbine 2.2.0 to 2.2.1 or 2.3, I
have to check the Turbine project.xml to see if any of the dependencies
changed and make the relevant corrections in my own project.xml
Things would be a lot simpler if I could just say something like this:
<dependencies>
<dependency ref="turbine-2.2.0"/>
<dependency ref="torque-3.0.0"/>
<dependencies>
and Maven would lookup the relevant dependencies in a (local/remote) POM
repository somehow.
Is this what the proposed POM repository would be used for ? If not, how
about implementing something like this ?
Age
RE: POM repository and dependency references
Posted by "Stanley,Michael P." <ms...@mitre.org>.
Some comments:
- Runtime and compile time are rarely different (as far as source
compile goes)
- I can see Plugin Dependencies as a possible type
- Test Time should probably extend runtime.
I like the notion of dependency type. Do you see this as an attribute
of dependency? It would be possible to have each type could map to a
Class Realm (or class realm reference) - is what your thinking.
Plugins, like javac, junit, etc, could have default class realm
references. It would then also be possible for each plugin to provide a
property that can override this. Default (not explicitly stated) could
be 'global' type that is shared across all realms. Is this enough
extensibility?
This would be nice and could help avoid some of the JAR override
collisions occurring in the dependency resolution (that Jason was
talking about in Plexus).
- Mike
P.S. I'm addicted to Maven. I have to get back to work before I lose
my job :-) Since I joined this list I barely sleep, and I wake up
excited.
> -----Original Message-----
> From: Jason van Zyl [mailto:jason@zenplex.com]
> Sent: Tuesday, March 04, 2003 10:16 PM
> To: Turbine Maven Developers List
> Subject: Re: POM repository and dependency references
>
> On Tue, 2003-03-04 at 22:11, Colin Sampaleanu wrote:
> > Jason van Zyl wrote:
> >
> > >On Tue, 2003-03-04 at 21:40, Colin Sampaleanu wrote:
> > >
> > >
> > >>Jason van Zyl wrote:
> > >>
> > >>>I doubt the full dependency resolution will be in beta-9. We need
to
> > >>>start pushing POMs into the repository. Once there we can build a
> > >>>database of anything related to projects. The top on my list is
the
> > >>>dependency graph of all projects.
> > >>>
> > >>What are your thoughts on handling compile-time vs test-time vs
run-
> time
> > >>dependencies. I appreciate the existing dependency system, it's a
lot
> > >>better than ant with no dependencies at all, but it'd be nice to
be
> able
> > >>to differentiate between the various uses somehow.
> > >>
> > >Dependencies can state types so we could do anything we like
really.
> The
> > >default type is of 'jar' but we could use a type of 'test'. In the
POM
> > >currently there is no distinction between compile-time and
test-time.
> > >This could be changed easily. As for run-time, this is simply the
> > >aggregration of compile-time dependencies of the dependencies
stated in
> > >the source POM.
> > >
> > >But we could definitely mark them as I don't want to leave people
> > >crippled when there are problems with the resolution mechanism. You
> will
> > >always be able to state things as verbosely as you wish so maybe a
> > >'run-time' type could be added for those who don't want to use the
> > >transitive dependency resolution mechanism.
> > >
> > >
> > I don't think it's safe to make that assumption that run-time
> > dependencies are always the aggregation of the compile-time
dependencies
> > from the POMs (although it's probably a safe default). While plugins
> > normally declare most of the real compile-time only dependencies,
you
> > could still have a compile-time only dependency for any arbitrary
code
> > you call from maven.xml (as a hypothetical example, let's say
calling
> > out to a transform tool of some sort, or to a dependency analyzer,
or
> > whatever). Even with plugins, sometimes you also need to add a
> > dependency to handle a broken plugin that doesn't properly declare
it's
> > dependencies.
>
> Obviously this needs to be changed in order for this to work.
>
> > In an ideal world :-), I'd like to be able to build a related group
of
> > projects/artifacts, have maven resolve all the compile time
> > dependencies, and when the artifacts are in the repository, be able
to
> > say, that one needs these dependencies to run, and these to run
tests,
> > etc. I think it's a safe assumption to say that people will come out
> > with other dependency categorizations, so the best scheme is one
that is
> > extensible, and doesn't force duplication of declarations.
>
> I agree.
>
> > >
> > >The general rule of thumb I follow is to make things as convenient
and
> > >easy as possible but always allow full verbosity and final control
in
> > >the POM so a project can decide what they want to do and aren't
whacked
> > >by any magic behaviour.
> > >
> > >
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
turbine-maven-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: turbine-maven-dev-
> help@jakarta.apache.org
> --
> jvz.
>
> Jason van Zyl
> jason@zenplex.com
> http://tambora.zenplex.org
>
> In short, man creates for himself a new religion of a rational
> and technical order to justify his work and to be justified in it.
>
> -- Jacques Ellul, The Technological Society
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
turbine-maven-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
turbine-maven-dev-help@jakarta.apache.org
Re: POM repository and dependency references
Posted by Jason van Zyl <ja...@zenplex.com>.
On Tue, 2003-03-04 at 22:11, Colin Sampaleanu wrote:
> Jason van Zyl wrote:
>
> >On Tue, 2003-03-04 at 21:40, Colin Sampaleanu wrote:
> >
> >
> >>Jason van Zyl wrote:
> >>
> >>>I doubt the full dependency resolution will be in beta-9. We need to
> >>>start pushing POMs into the repository. Once there we can build a
> >>>database of anything related to projects. The top on my list is the
> >>>dependency graph of all projects.
> >>>
> >>What are your thoughts on handling compile-time vs test-time vs run-time
> >>dependencies. I appreciate the existing dependency system, it's a lot
> >>better than ant with no dependencies at all, but it'd be nice to be able
> >>to differentiate between the various uses somehow.
> >>
> >Dependencies can state types so we could do anything we like really. The
> >default type is of 'jar' but we could use a type of 'test'. In the POM
> >currently there is no distinction between compile-time and test-time.
> >This could be changed easily. As for run-time, this is simply the
> >aggregration of compile-time dependencies of the dependencies stated in
> >the source POM.
> >
> >But we could definitely mark them as I don't want to leave people
> >crippled when there are problems with the resolution mechanism. You will
> >always be able to state things as verbosely as you wish so maybe a
> >'run-time' type could be added for those who don't want to use the
> >transitive dependency resolution mechanism.
> >
> >
> I don't think it's safe to make that assumption that run-time
> dependencies are always the aggregation of the compile-time dependencies
> from the POMs (although it's probably a safe default). While plugins
> normally declare most of the real compile-time only dependencies, you
> could still have a compile-time only dependency for any arbitrary code
> you call from maven.xml (as a hypothetical example, let's say calling
> out to a transform tool of some sort, or to a dependency analyzer, or
> whatever). Even with plugins, sometimes you also need to add a
> dependency to handle a broken plugin that doesn't properly declare it's
> dependencies.
Obviously this needs to be changed in order for this to work.
> In an ideal world :-), I'd like to be able to build a related group of
> projects/artifacts, have maven resolve all the compile time
> dependencies, and when the artifacts are in the repository, be able to
> say, that one needs these dependencies to run, and these to run tests,
> etc. I think it's a safe assumption to say that people will come out
> with other dependency categorizations, so the best scheme is one that is
> extensible, and doesn't force duplication of declarations.
I agree.
> >
> >The general rule of thumb I follow is to make things as convenient and
> >easy as possible but always allow full verbosity and final control in
> >the POM so a project can decide what they want to do and aren't whacked
> >by any magic behaviour.
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-maven-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-maven-dev-help@jakarta.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
Re: POM repository and dependency references
Posted by Colin Sampaleanu <co...@exis.com>.
Jason van Zyl wrote:
>On Tue, 2003-03-04 at 21:40, Colin Sampaleanu wrote:
>
>
>>Jason van Zyl wrote:
>>
>>>I doubt the full dependency resolution will be in beta-9. We need to
>>>start pushing POMs into the repository. Once there we can build a
>>>database of anything related to projects. The top on my list is the
>>>dependency graph of all projects.
>>>
>>What are your thoughts on handling compile-time vs test-time vs run-time
>>dependencies. I appreciate the existing dependency system, it's a lot
>>better than ant with no dependencies at all, but it'd be nice to be able
>>to differentiate between the various uses somehow.
>>
>Dependencies can state types so we could do anything we like really. The
>default type is of 'jar' but we could use a type of 'test'. In the POM
>currently there is no distinction between compile-time and test-time.
>This could be changed easily. As for run-time, this is simply the
>aggregration of compile-time dependencies of the dependencies stated in
>the source POM.
>
>But we could definitely mark them as I don't want to leave people
>crippled when there are problems with the resolution mechanism. You will
>always be able to state things as verbosely as you wish so maybe a
>'run-time' type could be added for those who don't want to use the
>transitive dependency resolution mechanism.
>
>
I don't think it's safe to make that assumption that run-time
dependencies are always the aggregation of the compile-time dependencies
from the POMs (although it's probably a safe default). While plugins
normally declare most of the real compile-time only dependencies, you
could still have a compile-time only dependency for any arbitrary code
you call from maven.xml (as a hypothetical example, let's say calling
out to a transform tool of some sort, or to a dependency analyzer, or
whatever). Even with plugins, sometimes you also need to add a
dependency to handle a broken plugin that doesn't properly declare it's
dependencies.
In an ideal world :-), I'd like to be able to build a related group of
projects/artifacts, have maven resolve all the compile time
dependencies, and when the artifacts are in the repository, be able to
say, that one needs these dependencies to run, and these to run tests,
etc. I think it's a safe assumption to say that people will come out
with other dependency categorizations, so the best scheme is one that is
extensible, and doesn't force duplication of declarations.
>
>The general rule of thumb I follow is to make things as convenient and
>easy as possible but always allow full verbosity and final control in
>the POM so a project can decide what they want to do and aren't whacked
>by any magic behaviour.
>
>
Re: POM repository and dependency references
Posted by Jason van Zyl <ja...@zenplex.com>.
On Tue, 2003-03-04 at 21:40, Colin Sampaleanu wrote:
> Jason van Zyl wrote:
>
> >On Tue, 2003-03-04 at 18:57, Age Mooy wrote:
> >
> >
> >>Great ! That's exactly what I meant.
> >>Is this going to be in the b9 release ?
> >>
> >>
> >
> >I doubt the full dependency resolution will be in beta-9. We need to
> >start pushing POMs into the repository. Once there we can build a
> >database of anything related to projects. The top on my list is the
> >dependency graph of all projects.
> >
> >
> What are your thoughts on handling compile-time vs test-time vs run-time
> dependencies. I appreciate the existing dependency system, it's a lot
> better than ant with no dependencies at all, but it'd be nice to be able
> to differentiate between the various uses somehow.
Dependencies can state types so we could do anything we like really. The
default type is of 'jar' but we could use a type of 'test'. In the POM
currently there is no distinction between compile-time and test-time.
This could be changed easily. As for run-time, this is simply the
aggregration of compile-time dependencies of the dependencies stated in
the source POM.
But we could definitely mark them as I don't want to leave people
crippled when there are problems with the resolution mechanism. You will
always be able to state things as verbosely as you wish so maybe a
'run-time' type could be added for those who don't want to use the
transitive dependency resolution mechanism.
The general rule of thumb I follow is to make things as convenient and
easy as possible but always allow full verbosity and final control in
the POM so a project can decide what they want to do and aren't whacked
by any magic behaviour.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-maven-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-maven-dev-help@jakarta.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
Re: POM repository and dependency references
Posted by Colin Sampaleanu <co...@exis.com>.
Jason van Zyl wrote:
>On Tue, 2003-03-04 at 18:57, Age Mooy wrote:
>
>
>>Great ! That's exactly what I meant.
>>Is this going to be in the b9 release ?
>>
>>
>
>I doubt the full dependency resolution will be in beta-9. We need to
>start pushing POMs into the repository. Once there we can build a
>database of anything related to projects. The top on my list is the
>dependency graph of all projects.
>
>
What are your thoughts on handling compile-time vs test-time vs run-time
dependencies. I appreciate the existing dependency system, it's a lot
better than ant with no dependencies at all, but it'd be nice to be able
to differentiate between the various uses somehow.
RE: POM repository and dependency references
Posted by Age Mooy <am...@home.nl>.
> > Great ! That's exactly what I meant.
> > Is this going to be in the b9 release ?
>
> I doubt the full dependency resolution will be in beta-9. We
> need to start pushing POMs into the repository. Once there we
> can build a database of anything related to projects. The top
> on my list is the dependency graph of all projects.
I can wait :)
Keep up the good work.
Age
RE: POM repository and dependency references
Posted by Jason van Zyl <ja...@zenplex.com>.
On Tue, 2003-03-04 at 18:57, Age Mooy wrote:
> Great ! That's exactly what I meant.
> Is this going to be in the b9 release ?
I doubt the full dependency resolution will be in beta-9. We need to
start pushing POMs into the repository. Once there we can build a
database of anything related to projects. The top on my list is the
dependency graph of all projects.
> Age
>
>
> > The idea is to be able to have a dependency on a POM, and all the
> > dependencies of that POM are 'inherited' for your project.
> >
> > For this to be workable, we need many more POMs to be deployed.
> >
> > See http://www.ibiblio.org/maven/plexus/poms/ for an example.
> >
> > As part of the repository audit, I've got a whole heap of
> > projects that we
> > can create POMs for, from the repository audit file.
> >
> > See
> >
> http://jakarta.apache.org/turbine/maven/reference/plugins/repository/tas
> ks.html
> > for details about what's happening there.
> >
> > Creating these directories and files is item 2 & 3 for me.
> > Item 1 I've
> > delegated to Jason already.
> > --
> > dIon Gillard, Multitask Consulting
> > Blog: http://www.freeroller.net/page/dion/Weblog
> > Work: http://www.multitask.com.au
> >
> >
> > "Age Mooy" <am...@home.nl> wrote on 05/03/2003 09:11:52 AM:
> >
> > > Hi,
> > >
> > > Jason has mentioned the idea of a POM repository a few
> > times on this
> > > list. I don't know exactly what he proposes to do with it
> > but I have
> > > also been thinking about something like that lately.
> > >
> > > I have built quite a lot of Turbine 2.x/Torque webapps the last few
> > > months and when writing the project.xml for these projects, I keep
> > > running into the same problem. For each new webapp project
> > I have to
> > > manually copy all the dependencies from the turbine-2 and db-torque
> > > project descriptors. If I upgrade from Turbine 2.2.0 to
> > 2.2.1 or 2.3,
> > > I have to check the Turbine project.xml to see if any of the
> > > dependencies changed and make the relevant corrections in my own
> > > project.xml
> > >
> > > Things would be a lot simpler if I could just say something
> > like this:
> > >
> > > <dependencies>
> > > <dependency ref="turbine-2.2.0"/>
> > > <dependency ref="torque-3.0.0"/>
> > > <dependencies>
> > >
> > > and Maven would lookup the relevant dependencies in a
> > (local/remote)
> > > POM repository somehow.
> > >
> > > Is this what the proposed POM repository would be used for
> > ? If not,
> > > how about implementing something like this ?
> > >
> > > Age
> > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > > turbine-maven-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > turbine-maven-dev-help@jakarta.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > turbine-maven-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > turbine-maven-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-maven-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-maven-dev-help@jakarta.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
RE: POM repository and dependency references
Posted by di...@multitask.com.au.
It depends how quickly we can get the work done. It's definitely a desired
1.0 feature.
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
"Age Mooy" <am...@home.nl> wrote on 05/03/2003 10:57:36 AM:
>
> Great ! That's exactly what I meant.
> Is this going to be in the b9 release ?
>
> Age
>
>
> > The idea is to be able to have a dependency on a POM, and all the
> > dependencies of that POM are 'inherited' for your project.
> >
> > For this to be workable, we need many more POMs to be deployed.
> >
> > See http://www.ibiblio.org/maven/plexus/poms/ for an example.
> >
> > As part of the repository audit, I've got a whole heap of
> > projects that we
> > can create POMs for, from the repository audit file.
> >
> > See
> >
> http://jakarta.apache.org/turbine/maven/reference/plugins/repository/tas
> ks.html
> > for details about what's happening there.
> >
> > Creating these directories and files is item 2 & 3 for me.
> > Item 1 I've
> > delegated to Jason already.
> > --
> > dIon Gillard, Multitask Consulting
> > Blog: http://www.freeroller.net/page/dion/Weblog
> > Work: http://www.multitask.com.au
> >
> >
> > "Age Mooy" <am...@home.nl> wrote on 05/03/2003 09:11:52 AM:
> >
> > > Hi,
> > >
> > > Jason has mentioned the idea of a POM repository a few
> > times on this
> > > list. I don't know exactly what he proposes to do with it
> > but I have
> > > also been thinking about something like that lately.
> > >
> > > I have built quite a lot of Turbine 2.x/Torque webapps the last few
> > > months and when writing the project.xml for these projects, I keep
> > > running into the same problem. For each new webapp project
> > I have to
> > > manually copy all the dependencies from the turbine-2 and db-torque
> > > project descriptors. If I upgrade from Turbine 2.2.0 to
> > 2.2.1 or 2.3,
> > > I have to check the Turbine project.xml to see if any of the
> > > dependencies changed and make the relevant corrections in my own
> > > project.xml
> > >
> > > Things would be a lot simpler if I could just say something
> > like this:
> > >
> > > <dependencies>
> > > <dependency ref="turbine-2.2.0"/>
> > > <dependency ref="torque-3.0.0"/>
> > > <dependencies>
> > >
> > > and Maven would lookup the relevant dependencies in a
> > (local/remote)
> > > POM repository somehow.
> > >
> > > Is this what the proposed POM repository would be used for
> > ? If not,
> > > how about implementing something like this ?
> > >
> > > Age
> > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > > turbine-maven-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > turbine-maven-dev-help@jakarta.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > turbine-maven-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > turbine-maven-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-maven-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
turbine-maven-dev-help@jakarta.apache.org
>
RE: POM repository and dependency references
Posted by Age Mooy <am...@home.nl>.
Great ! That's exactly what I meant.
Is this going to be in the b9 release ?
Age
> The idea is to be able to have a dependency on a POM, and all the
> dependencies of that POM are 'inherited' for your project.
>
> For this to be workable, we need many more POMs to be deployed.
>
> See http://www.ibiblio.org/maven/plexus/poms/ for an example.
>
> As part of the repository audit, I've got a whole heap of
> projects that we
> can create POMs for, from the repository audit file.
>
> See
>
http://jakarta.apache.org/turbine/maven/reference/plugins/repository/tas
ks.html
> for details about what's happening there.
>
> Creating these directories and files is item 2 & 3 for me.
> Item 1 I've
> delegated to Jason already.
> --
> dIon Gillard, Multitask Consulting
> Blog: http://www.freeroller.net/page/dion/Weblog
> Work: http://www.multitask.com.au
>
>
> "Age Mooy" <am...@home.nl> wrote on 05/03/2003 09:11:52 AM:
>
> > Hi,
> >
> > Jason has mentioned the idea of a POM repository a few
> times on this
> > list. I don't know exactly what he proposes to do with it
> but I have
> > also been thinking about something like that lately.
> >
> > I have built quite a lot of Turbine 2.x/Torque webapps the last few
> > months and when writing the project.xml for these projects, I keep
> > running into the same problem. For each new webapp project
> I have to
> > manually copy all the dependencies from the turbine-2 and db-torque
> > project descriptors. If I upgrade from Turbine 2.2.0 to
> 2.2.1 or 2.3,
> > I have to check the Turbine project.xml to see if any of the
> > dependencies changed and make the relevant corrections in my own
> > project.xml
> >
> > Things would be a lot simpler if I could just say something
> like this:
> >
> > <dependencies>
> > <dependency ref="turbine-2.2.0"/>
> > <dependency ref="torque-3.0.0"/>
> > <dependencies>
> >
> > and Maven would lookup the relevant dependencies in a
> (local/remote)
> > POM repository somehow.
> >
> > Is this what the proposed POM repository would be used for
> ? If not,
> > how about implementing something like this ?
> >
> > Age
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > turbine-maven-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> turbine-maven-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> turbine-maven-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> turbine-maven-dev-help@jakarta.apache.org
>
RE: POM repository and dependency references
Posted by Jason van Zyl <ja...@zenplex.com>.
On Tue, 2003-03-04 at 20:31, Stanley,Michael P. wrote:
> > On Tue, 2003-03-04 at 19:46, Stanley,Michael P. wrote:
> > > Cool.
> > >
> > > Question: What happens when dependencies collide? i.e. in my
> > > dependency I state that I depend on projectX version 1.3 and
> projectY
> > > version 2.0. projectY version 2.0 has dependency on a different
> version
> > > of projectX. How will situations like these be resolved?
> >
> > It would be easy enough to detect differing versions. Typically during
> > integration work I use the JAR override mechanism to make sure that
> I'm
> > using the same version of all the JARs that go into the final work.
> > Often I have to diddle the versions to get things to work correctly.
>
> Hmmm... I'm a little confused. Bear with me. Is the plan to put POM in
> the repository, to allow projects auto-resolve dependencies (of
> dependencies)? This is what I assume is being suggested.
Yes, once all the POMs are there we can build something using a tool
like jisp to make a deadly fast resolution mechanism. But this involves
some careful sychronization, efficient diffing using something like
jarsync (java rsync implementation). In the plexus plugin I'm just
recursively dragging down POMs and looking stuff up. Definitely not good
enough for general building but good enough for creating a runtime.
> If so what is
> the JAR override mechanism? What do you mean diddle the versions? With
> JAR override does the order dependencies are listed modify
> dependency/version resolution?
If you are integrating 30 different components it is likely you're going
to get components declaring dependencies on the same artifactId with
differing versions. Including multiple versions of the same package
leads to linkage errors and other classloading nonsense. So I use the
JAR override to make sure the same version of, say, beanutils is used
instead of collecting three different versions of beanutils. By diddle I
mean that sometimes I have to trial and error select among the versions
until I find one that works with everything.
>
>
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
RE: POM repository and dependency references
Posted by "Stanley,Michael P." <ms...@mitre.org>.
> On Tue, 2003-03-04 at 19:46, Stanley,Michael P. wrote:
> > Cool.
> >
> > Question: What happens when dependencies collide? i.e. in my
> > dependency I state that I depend on projectX version 1.3 and
projectY
> > version 2.0. projectY version 2.0 has dependency on a different
version
> > of projectX. How will situations like these be resolved?
>
> It would be easy enough to detect differing versions. Typically during
> integration work I use the JAR override mechanism to make sure that
I'm
> using the same version of all the JARs that go into the final work.
> Often I have to diddle the versions to get things to work correctly.
Hmmm... I'm a little confused. Bear with me. Is the plan to put POM in
the repository, to allow projects auto-resolve dependencies (of
dependencies)? This is what I assume is being suggested. If so what is
the JAR override mechanism? What do you mean diddle the versions? With
JAR override does the order dependencies are listed modify
dependency/version resolution?
>
> > - Mike
> >
> > > -----Original Message-----
> > > From: dion@multitask.com.au [mailto:dion@multitask.com.au]
> > > Sent: Tuesday, March 04, 2003 6:45 PM
> > > To: Turbine Maven Developers List
> > > Subject: Re: POM repository and dependency references
> > >
> > > The idea is to be able to have a dependency on a POM, and all the
> > > dependencies of that POM are 'inherited' for your project.
> > >
> > > For this to be workable, we need many more POMs to be deployed.
> > >
> > > See http://www.ibiblio.org/maven/plexus/poms/ for an example.
> > >
> > > As part of the repository audit, I've got a whole heap of projects
> > that we
> > > can create POMs for, from the repository audit file.
> > >
> > > See
> > >
> >
http://jakarta.apache.org/turbine/maven/reference/plugins/repository/tas
> > ks
> > > .html
> > > for details about what's happening there.
> > >
> > > Creating these directories and files is item 2 & 3 for me. Item 1
I've
> > > delegated to Jason already.
> > > --
> > > dIon Gillard, Multitask Consulting
> > > Blog: http://www.freeroller.net/page/dion/Weblog
> > > Work: http://www.multitask.com.au
> > >
> > >
> > > "Age Mooy" <am...@home.nl> wrote on 05/03/2003 09:11:52 AM:
> > >
> > > > Hi,
> > > >
> > > > Jason has mentioned the idea of a POM repository a few times on
this
> > > > list. I don't know exactly what he proposes to do with it but I
have
> > > > also been thinking about something like that lately.
> > > >
> > > > I have built quite a lot of Turbine 2.x/Torque webapps the last
few
> > > > months and when writing the project.xml for these projects, I
keep
> > > > running into the same problem. For each new webapp project I
have to
> > > > manually copy all the dependencies from the turbine-2 and
db-torque
> > > > project descriptors. If I upgrade from Turbine 2.2.0 to 2.2.1 or
> > 2.3, I
> > > > have to check the Turbine project.xml to see if any of the
> > dependencies
> > > > changed and make the relevant corrections in my own project.xml
> > > >
> > > > Things would be a lot simpler if I could just say something like
> > this:
> > > >
> > > > <dependencies>
> > > > <dependency ref="turbine-2.2.0"/>
> > > > <dependency ref="torque-3.0.0"/>
> > > > <dependencies>
> > > >
> > > > and Maven would lookup the relevant dependencies in a
(local/remote)
> > POM
> > > > repository somehow.
> > > >
> > > > Is this what the proposed POM repository would be used for ? If
not,
> > how
> > > > about implementing something like this ?
> > > >
> > > > Age
> > > >
> > > >
> > > >
> > > >
> >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > turbine-maven-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> > > turbine-maven-dev-help@jakarta.apache.org
> > > >
> > >
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > turbine-maven-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > turbine-maven-dev-help@jakarta.apache.org
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
turbine-maven-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: turbine-maven-dev-
> help@jakarta.apache.org
> --
> jvz.
>
> Jason van Zyl
> jason@zenplex.com
> http://tambora.zenplex.org
>
> In short, man creates for himself a new religion of a rational
> and technical order to justify his work and to be justified in it.
>
> -- Jacques Ellul, The Technological Society
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
turbine-maven-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
turbine-maven-dev-help@jakarta.apache.org
RE: POM repository and dependency references
Posted by Jason van Zyl <ja...@zenplex.com>.
On Tue, 2003-03-04 at 19:46, Stanley,Michael P. wrote:
> Cool.
>
> Question: What happens when dependencies collide? i.e. in my
> dependency I state that I depend on projectX version 1.3 and projectY
> version 2.0. projectY version 2.0 has dependency on a different version
> of projectX. How will situations like these be resolved?
It would be easy enough to detect differing versions. Typically during
integration work I use the JAR override mechanism to make sure that I'm
using the same version of all the JARs that go into the final work.
Often I have to diddle the versions to get things to work correctly.
> - Mike
>
> > -----Original Message-----
> > From: dion@multitask.com.au [mailto:dion@multitask.com.au]
> > Sent: Tuesday, March 04, 2003 6:45 PM
> > To: Turbine Maven Developers List
> > Subject: Re: POM repository and dependency references
> >
> > The idea is to be able to have a dependency on a POM, and all the
> > dependencies of that POM are 'inherited' for your project.
> >
> > For this to be workable, we need many more POMs to be deployed.
> >
> > See http://www.ibiblio.org/maven/plexus/poms/ for an example.
> >
> > As part of the repository audit, I've got a whole heap of projects
> that we
> > can create POMs for, from the repository audit file.
> >
> > See
> >
> http://jakarta.apache.org/turbine/maven/reference/plugins/repository/tas
> ks
> > .html
> > for details about what's happening there.
> >
> > Creating these directories and files is item 2 & 3 for me. Item 1 I've
> > delegated to Jason already.
> > --
> > dIon Gillard, Multitask Consulting
> > Blog: http://www.freeroller.net/page/dion/Weblog
> > Work: http://www.multitask.com.au
> >
> >
> > "Age Mooy" <am...@home.nl> wrote on 05/03/2003 09:11:52 AM:
> >
> > > Hi,
> > >
> > > Jason has mentioned the idea of a POM repository a few times on this
> > > list. I don't know exactly what he proposes to do with it but I have
> > > also been thinking about something like that lately.
> > >
> > > I have built quite a lot of Turbine 2.x/Torque webapps the last few
> > > months and when writing the project.xml for these projects, I keep
> > > running into the same problem. For each new webapp project I have to
> > > manually copy all the dependencies from the turbine-2 and db-torque
> > > project descriptors. If I upgrade from Turbine 2.2.0 to 2.2.1 or
> 2.3, I
> > > have to check the Turbine project.xml to see if any of the
> dependencies
> > > changed and make the relevant corrections in my own project.xml
> > >
> > > Things would be a lot simpler if I could just say something like
> this:
> > >
> > > <dependencies>
> > > <dependency ref="turbine-2.2.0"/>
> > > <dependency ref="torque-3.0.0"/>
> > > <dependencies>
> > >
> > > and Maven would lookup the relevant dependencies in a (local/remote)
> POM
> > > repository somehow.
> > >
> > > Is this what the proposed POM repository would be used for ? If not,
> how
> > > about implementing something like this ?
> > >
> > > Age
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> turbine-maven-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > turbine-maven-dev-help@jakarta.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> turbine-maven-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> turbine-maven-dev-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-maven-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-maven-dev-help@jakarta.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
RE: POM repository and dependency references
Posted by "Stanley,Michael P." <ms...@mitre.org>.
Cool.
Question: What happens when dependencies collide? i.e. in my
dependency I state that I depend on projectX version 1.3 and projectY
version 2.0. projectY version 2.0 has dependency on a different version
of projectX. How will situations like these be resolved?
- Mike
> -----Original Message-----
> From: dion@multitask.com.au [mailto:dion@multitask.com.au]
> Sent: Tuesday, March 04, 2003 6:45 PM
> To: Turbine Maven Developers List
> Subject: Re: POM repository and dependency references
>
> The idea is to be able to have a dependency on a POM, and all the
> dependencies of that POM are 'inherited' for your project.
>
> For this to be workable, we need many more POMs to be deployed.
>
> See http://www.ibiblio.org/maven/plexus/poms/ for an example.
>
> As part of the repository audit, I've got a whole heap of projects
that we
> can create POMs for, from the repository audit file.
>
> See
>
http://jakarta.apache.org/turbine/maven/reference/plugins/repository/tas
ks
> .html
> for details about what's happening there.
>
> Creating these directories and files is item 2 & 3 for me. Item 1 I've
> delegated to Jason already.
> --
> dIon Gillard, Multitask Consulting
> Blog: http://www.freeroller.net/page/dion/Weblog
> Work: http://www.multitask.com.au
>
>
> "Age Mooy" <am...@home.nl> wrote on 05/03/2003 09:11:52 AM:
>
> > Hi,
> >
> > Jason has mentioned the idea of a POM repository a few times on this
> > list. I don't know exactly what he proposes to do with it but I have
> > also been thinking about something like that lately.
> >
> > I have built quite a lot of Turbine 2.x/Torque webapps the last few
> > months and when writing the project.xml for these projects, I keep
> > running into the same problem. For each new webapp project I have to
> > manually copy all the dependencies from the turbine-2 and db-torque
> > project descriptors. If I upgrade from Turbine 2.2.0 to 2.2.1 or
2.3, I
> > have to check the Turbine project.xml to see if any of the
dependencies
> > changed and make the relevant corrections in my own project.xml
> >
> > Things would be a lot simpler if I could just say something like
this:
> >
> > <dependencies>
> > <dependency ref="turbine-2.2.0"/>
> > <dependency ref="torque-3.0.0"/>
> > <dependencies>
> >
> > and Maven would lookup the relevant dependencies in a (local/remote)
POM
> > repository somehow.
> >
> > Is this what the proposed POM repository would be used for ? If not,
how
> > about implementing something like this ?
> >
> > Age
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
turbine-maven-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> turbine-maven-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
turbine-maven-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
turbine-maven-dev-help@jakarta.apache.org
Re: POM repository and dependency references
Posted by di...@multitask.com.au.
The idea is to be able to have a dependency on a POM, and all the
dependencies of that POM are 'inherited' for your project.
For this to be workable, we need many more POMs to be deployed.
See http://www.ibiblio.org/maven/plexus/poms/ for an example.
As part of the repository audit, I've got a whole heap of projects that we
can create POMs for, from the repository audit file.
See
http://jakarta.apache.org/turbine/maven/reference/plugins/repository/tasks.html
for details about what's happening there.
Creating these directories and files is item 2 & 3 for me. Item 1 I've
delegated to Jason already.
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
"Age Mooy" <am...@home.nl> wrote on 05/03/2003 09:11:52 AM:
> Hi,
>
> Jason has mentioned the idea of a POM repository a few times on this
> list. I don't know exactly what he proposes to do with it but I have
> also been thinking about something like that lately.
>
> I have built quite a lot of Turbine 2.x/Torque webapps the last few
> months and when writing the project.xml for these projects, I keep
> running into the same problem. For each new webapp project I have to
> manually copy all the dependencies from the turbine-2 and db-torque
> project descriptors. If I upgrade from Turbine 2.2.0 to 2.2.1 or 2.3, I
> have to check the Turbine project.xml to see if any of the dependencies
> changed and make the relevant corrections in my own project.xml
>
> Things would be a lot simpler if I could just say something like this:
>
> <dependencies>
> <dependency ref="turbine-2.2.0"/>
> <dependency ref="torque-3.0.0"/>
> <dependencies>
>
> and Maven would lookup the relevant dependencies in a (local/remote) POM
> repository somehow.
>
> Is this what the proposed POM repository would be used for ? If not, how
> about implementing something like this ?
>
> Age
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-maven-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
turbine-maven-dev-help@jakarta.apache.org
>
RE: POM repository and dependency references
Posted by "Stanley,Michael P." <ms...@mitre.org>.
> On Tue, 2003-03-04 at 20:10, Stanley,Michael P. wrote:
> > > The problem with this is that I would still have to manually
maintain
> > my
> > > own macro file to make sure the dependencies listed for the
projects
> > it
> > > contains are up to date. But if Maven simply has access to a
public
> > > version of the turbine-2.2.0 POM, it can always resolve the
correct
> > > dependencies from there. Cut out the middle man :)
> >
> > I agree making the POM available can help resolve dependencies. I'm
> > curios to see how the dependency graph will be implemented.
>
> A very rough version works in the plexus plugin to resolve all the
> dependencies.
Cool. I'll take a look at it.
>
> > The macro capability would still be pretty cool/useful, since it can
> > help with things other than just dependencies. In my previous email
I
> > suggest a way to share macro files within the repository.
> >
> > Any interest in this type of functionality?
>
> Macros in the POM? No I would rather not see a macro facility popping
up
> in the POM. I really don't think it's necessary. Full transitive
> dependencies will be supported.
Cool and I understand why.
- Mike
>
> > - Mike
> >
> > >
> > > Age
> > >
> > >
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > turbine-maven-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > turbine-maven-dev-help@jakarta.apache.org
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
turbine-maven-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: turbine-maven-dev-
> help@jakarta.apache.org
> --
> jvz.
>
> Jason van Zyl
> jason@zenplex.com
> http://tambora.zenplex.org
>
> In short, man creates for himself a new religion of a rational
> and technical order to justify his work and to be justified in it.
>
> -- Jacques Ellul, The Technological Society
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
turbine-maven-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
turbine-maven-dev-help@jakarta.apache.org
RE: POM repository and dependency references
Posted by Jason van Zyl <ja...@zenplex.com>.
On Tue, 2003-03-04 at 20:10, Stanley,Michael P. wrote:
> > The problem with this is that I would still have to manually maintain
> my
> > own macro file to make sure the dependencies listed for the projects
> it
> > contains are up to date. But if Maven simply has access to a public
> > version of the turbine-2.2.0 POM, it can always resolve the correct
> > dependencies from there. Cut out the middle man :)
>
> I agree making the POM available can help resolve dependencies. I'm
> curios to see how the dependency graph will be implemented.
A very rough version works in the plexus plugin to resolve all the
dependencies.
> The macro capability would still be pretty cool/useful, since it can
> help with things other than just dependencies. In my previous email I
> suggest a way to share macro files within the repository.
>
> Any interest in this type of functionality?
Macros in the POM? No I would rather not see a macro facility popping up
in the POM. I really don't think it's necessary. Full transitive
dependencies will be supported.
> - Mike
>
> >
> > Age
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> turbine-maven-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> turbine-maven-dev-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-maven-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-maven-dev-help@jakarta.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
RE: POM repository and dependency references
Posted by "Stanley,Michael P." <ms...@mitre.org>.
> The problem with this is that I would still have to manually maintain
my
> own macro file to make sure the dependencies listed for the projects
it
> contains are up to date. But if Maven simply has access to a public
> version of the turbine-2.2.0 POM, it can always resolve the correct
> dependencies from there. Cut out the middle man :)
I agree making the POM available can help resolve dependencies. I'm
curios to see how the dependency graph will be implemented.
The macro capability would still be pretty cool/useful, since it can
help with things other than just dependencies. In my previous email I
suggest a way to share macro files within the repository.
Any interest in this type of functionality?
- Mike
>
> Age
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
turbine-maven-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
turbine-maven-dev-help@jakarta.apache.org
RE: POM repository and dependency references
Posted by Age Mooy <am...@home.nl>.
> Instead of a POM repository, how about a Global POM Macros
> file. (thinking out loud)
>
> There can even be the similar hierarchy to properties files.
> pom-macros.xml in Maven directory -> project directory ->
> user directory
>
> the macros file can contain stuff like
>
> <macro id="turbine-2.2.0">
> <dependency>
> ...
> </dependency>
> <dependency>
> ...
> </dependency>
> ...
> </macro>
>
> which can be placed in your POM as follows
>
> <dependencies>
> <macro ref="turbine-2.2.0">
> </dependencies>
The problem with this is that I would still have to manually maintain my
own macro file to make sure the dependencies listed for the projects it
contains are up to date. But if Maven simply has access to a public
version of the turbine-2.2.0 POM, it can always resolve the correct
dependencies from there. Cut out the middle man :)
Age
RE: POM repository and dependency references
Posted by "Stanley,Michael P." <ms...@mitre.org>.
Instead of a POM repository, how about a Global POM Macros file.
(thinking out loud)
There can even be the similar hierarchy to properties files.
pom-macros.xml in Maven directory -> project directory -> user directory
the macros file can contain stuff like
<macro id="turbine-2.2.0">
<dependency>
...
</dependency>
<dependency>
...
</dependency>
...
</macro>
which can be placed in your POM as follows
<dependencies>
<macro ref="turbine-2.2.0">
</dependencies>
where turbine-2.2.0 would be replaced with the content of the matching
macro. This can be useful for things like organization, developer
teams, etc.
Actually I don't see much use for the maven directory and user directory
ones since macro files would need to be shared with developers.
I could even see how a macro file may become an artifact in a project's
repository. This will introduce the problem of having more than one
macro file, so a macro 'load file' would be needed. Maybe something
like
<macroload file="./project-macros.xml"/>
Hmmm.... This would introduce possible collisions in macro
ids/references.
This can be addressed with a type of namespacing...
<macroload id="project" file="./project-macros.xml"/>
... later on in the same POM or POM inheritance tree ...
<macro ref="project:turbine-2.2.0"/>
This would be extremely cool!
What are your thoughts? How does this line up with the POM repository
(goals and implementation)?
- Mike
> -----Original Message-----
> From: Age Mooy [mailto:amooy@home.nl]
> Sent: Tuesday, March 04, 2003 5:12 PM
> To: 'Turbine Maven Developers List'
> Subject: POM repository and dependency references
>
> Hi,
>
> Jason has mentioned the idea of a POM repository a few times on this
> list. I don't know exactly what he proposes to do with it but I have
> also been thinking about something like that lately.
>
> I have built quite a lot of Turbine 2.x/Torque webapps the last few
> months and when writing the project.xml for these projects, I keep
> running into the same problem. For each new webapp project I have to
> manually copy all the dependencies from the turbine-2 and db-torque
> project descriptors. If I upgrade from Turbine 2.2.0 to 2.2.1 or 2.3,
I
> have to check the Turbine project.xml to see if any of the
dependencies
> changed and make the relevant corrections in my own project.xml
>
> Things would be a lot simpler if I could just say something like this:
>
> <dependencies>
> <dependency ref="turbine-2.2.0"/>
> <dependency ref="torque-3.0.0"/>
> <dependencies>
>
> and Maven would lookup the relevant dependencies in a (local/remote)
POM
> repository somehow.
>
> Is this what the proposed POM repository would be used for ? If not,
how
> about implementing something like this ?
>
> Age
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
turbine-maven-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
turbine-maven-dev-help@jakarta.apache.org