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.
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
>
>
