On Sun, 2003-08-17 at 00:16, Jason van Zyl wrote:
On Sat, 2003-08-16 at 16:35, Luke Taylor wrote:
I think the problem is that you might want to put shared dependencies
into a parent project file for a reactor project which has, for example,
20 sub-projects/components. But if perhaps
On Sat, 2003-08-16 at 19:19, Jason van Zyl wrote:
On Sat, 2003-08-16 at 12:11, Mark McBride wrote:
My group is currently running into the same problem.What we are doing is
declaring all our system/lib jars in a projects.xml which all our
projects extend. This is nice in respect to ensure
out dependencies by
name and then copying them into the project.xml. I think this would be
very useful and shows where project.xml as a jelly script would be
desirable.
Why not just use XML entities?
I think this is a good idea, but wanted to hear what you guys have to
say.
Also I
Mark,
Mark McBride [EMAIL PROTECTED] wrote on 17/08/2003 02:11:52 AM:
My group is currently running into the same problem.What we are doing is
declaring all our system/lib jars in a projects.xml which all our
projects extend. This is nice in respect to ensure that everyone is
Jason van Zyl wrote:
Dependencies are inherited in an aggregate fashion. So if you have
common dependencies then you can state them in a parent project. In much
the same way the Jelly tag builds are setup.
I did not wish to put all of the depends
into a parent project as that would force each
Is the idea of a dependency role not something that would possibly help
here ?
Aside of basic-roles like building, running-tests, etc, a project
should even be able to specify roles depending on the runtime behaviour
expected.
Dependency inclusion (which is planned in some maven future I
On Sat, 2003-08-16 at 16:35, Luke Taylor wrote:
Jason van Zyl wrote:
Dependencies are inherited in an aggregate fashion. So if you have
common dependencies then you can state them in a parent project. In much
the same way the Jelly tag builds are setup.
I did not wish to put all
Jason van Zyl wrote:
On Sat, 2003-08-16 at 16:35, Luke Taylor wrote:
Jason van Zyl wrote:
Dependencies are inherited in an aggregate fashion. So if you have
common dependencies then you can state them in a parent project. In much
the same way the Jelly tag builds are setup.
I did not wish to
My group is currently running into the same problem.What we are doing is
declaring all our system/lib jars in a projects.xml which all our
projects extend. This is nice in respect to ensure that everyone is
building/debugging against the libraries that are in production. We are
actually using this
On Sat, 2003-08-16 at 12:11, Mark McBride wrote:
My group is currently running into the same problem.What we are doing is
declaring all our system/lib jars in a projects.xml which all our
projects extend. This is nice in respect to ensure that everyone is
building/debugging against the
and then copying them into the project.xml. I think this would be
very useful and shows where project.xml as a jelly script would be
desirable.
I think this is a good idea, but wanted to hear what you guys have to
say.
Also I was talking to James about the problem of versioning
dependencies in general
page
and some bad tests I made). He suggested using x:parse
xml=../../dependencies.xml/ and then selecting out dependencies by
name and then copying them into the project.xml. I think this would be
very useful and shows where project.xml as a jelly script would be
desirable.
I think
Jason Dillon wrote:
So I thought about using properties like
'dependency.commons-logger.version=1.0.3' and then specify the property
as the content for version/, which works fine if the property is
defined in the child modules project.properties, or if the property is
in the parent and the
13 matches
Mail list logo
