On Nov 28, 2005, at 6:02 AM, Aaron Mulder wrote:
I'm sorry, but I object if you can't use an "arbitrary URI" configId
as a parentId, assuming you're using neither the assembly plugin nor
the packaging plugin. As in, you deploy a configuration with an
arbitrary URI using the command-line deployer or the console deployer,
then another one that depends on the first one. Please make sure that
works before you commit the changes.
I ran a section of the tck that uses other tck configurations as
parents, and it all worked fine.
I'd like to reemphasize more specifically that this change includes the
dependency tags, and that one effect is that you have to put jars into
the geronimo repository according to its structure. Yesterday someone
said they had put a jar in the geronimo repo at foo/foo-1.0.jar. This
will no longer work: you will need to put the jar in the repo at
foo/jars/foo-1.0.jar and refer to it as
<dependency>
<uri>foo/foo/1.0/jar</uri>
</dependency>
or
<dependency>
<groupId>foo</groupId>
<artifactId>foo</artifactId>
<version>1.0</version>
</dependency>
IMO this is a very good thing as it allows us to change the internal
structure of the repository without breaking applications. e.g. we
could use a maven 2 structured repo.
thanks
david jencks
Thanks,
Aaron
On 11/28/05, David Jencks <[EMAIL PROTECTED]> wrote:
I have a large number of changes on my machine related to the proposed
new configId format and I would like to commit them before they get
out
of sync.
To review, it is a URI of the form
groupId/artifactId/version/type
where type is "car" for configurations. The same format is used for
dependencies, although the type is "jar". In plans, you can always
use
the expanded form
<import>
<groupId>foo</groupId>
<type>car</type>
<artifactId>bar</artifactId>
<version>1.0</version>
</import>
or for dependencies
<dependency>
<groupId>foo</groupId>
<artifactId>bar</artifactId>
<version>1.0</version>
</dependency>
It is definitely possible to use an arbitrary URI for a configId,
although I don't know how successful using an arbitrary uri for a
parentId will be. While you could use the packaging plugin with a
configId of some other format, I don't think the assembly plugin would
be able to find it.
Are there any objections to my committing this sometime monday
afternoon or evening?
thanks
david jencks