Unfortunately, according to JSR-88, CAR means a client JAR. :( Oh, well, not much we can do about that.
Anyway, in terms of meaningful issues, I think we should also consider "zip" a valid type, for people who still deploy dependencies as ZIPs (aargh! Oracle drivers). And I do think we need to consider "jar" the most common value for <dependency> and possibly <include> elements, though granted not for <import> or parentId. I think I'd be happy with Dain's proposal to split out the configId values so you must separately specify group, artifact, and version in the deployment planheader, and then someone referring to it must specify the artifact, the group if it was originally specified, and the version and type if they want to. Thanks, Aaron On 1/26/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > Do you think this is something people will be typeing often. My > guess is that the defaults will work 98% and I think most of our > users will either use our maven plugins (and ant ones one day) or the > eclipse tooling to manage these, so they would never type them anyway. > > On Jan 26, 2006, at 1:14 PM, Matt Hogstrom wrote: > > > I kind of like the string form as its easier to type. It works > > well if you take Dain's ideas and reverse the version and the type > > so you have: > > > > geronimo/foo - Means I'll take what's current in the server > > geronimo/foo/car - If you want to be specific about it being a car > > or other type > > geronimo/foo/car/[1.0,2.0( - If you need to be really specific. > > I'm gut it telling me that this deviation from the maven standard > format will cause us big pains later, but I don't have any thing > specific. > > > How many different types are there? If its limited and can > > generally be derived from a context then perhaps the existing > > ordering works. > > I think the most common types are jar, ear, war, rar and car. In the > context of a configId, parentId, or import the most common type by a > long shot is car. The only other type I commonly see is rar, for all > the connectors. > > > I'm ok with the second form if its the easier. > > Good to know. I think we need to chew on this one for a while before > making any moves :) > > -dain >
