The following comment has been added to this issue:
Author: Brian Ewins
Created: Tue, 5 Aug 2003 4:13 AM
Body:
Just another viewpoint: the point of ids is to allow dependencies to be looked up in
jelly. They have to be independent of version to avoid ripple changes from
dependencies, but other than that, there is no requirement for ids to be derived from
other dependency attributes - its just convenient.
This being the case, some consideration should be given to 'id-as-alias' - an id being
assignable by a user as a short name for the dependency.
One potential advantage: suppose we have a 'master' list of dependencies inherited
into our projects - something that basically says the versions of each jar (this is
the way we used to work with ant). In maven, if we want to add property info - such as
'war.bundle' - we have to completely respecify the dependency. It would make more
sense to be able to mention the dependency by id and add properties to it.
To make this work, the logic currently used for groupid/artifactid/id would change to:
if (!id) {
// derive id from group/artifact
if (artifactid) {
if (groupid) {
id = groupid:artifactid
} else {
id = artifactid
}
}
} else {
// derive artifact/group from id
if (id contains ':') {
// inverse of id from g/a above
// I think this can be made backwards compatible
// however I think it should be dropped in favour
// of POM upgrade scripts
if (!artifactid) {
groupid = prefix
artifactid = suffix
}
} else {
// normal shorthand
if (!artifactid) {
artifactid = id
}
if (!groupid) {
groupid = artifactid
}
}
}
Using the logic above, the user can use id to assign short, unique, and meaningless
names if the other dependency attributes are set. If no other attributes are set, it
functions as it does today - as a quick way of specifying a dependency.
A third position on the id thing is that you might as well use the unversioned
filename in the repo if you are going to be adding in the rest of the dependency
attributes, ie the id of:
/foo/bars/baz-1.0.bar
should be
/foo/bars/baz.bar, not foo+baz or foo:baz:bar.
This is a blindingly obvious system for users, its still easy to parse into
group/artifact ids, or derive that information when its missing if you are given a
partial id.
---------------------------------------------------------------------
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-194
Here is an overview of the issue:
---------------------------------------------------------------------
Key: MAVEN-194
Summary: Two dependiencise having the same id but diffrent type should not be
assumed as duplicats
Type: Bug
Status: Reopened
Priority: Major
Time Spent: Unknown
Remaining: Unknown
Project: maven
Fix Fors:
1.0-final
Versions:
1.0-beta-8
Assignee: Jason van Zyl
Reporter: Michal Maczka
Created: Sun, 12 Jan 2003 10:22 AM
Updated: Mon, 4 Aug 2003 12:56 PM
Description:
Currently in case of following dependincies in POM:
<dependencies>
<dependency>
<id>mydep</id>
<version>1.0.1</version>
<type>war</type>
</dependency>
</dependencies>
<dependencies>
<dependency>
<id>mydep</id>
<version>1.0.1</version>
<type>jar</type>
</dependency>
</dependencies>
only the first dependency will be availabe in dependency list.
Solution:
Both "id" and "type" should be used in org.apache.maven.project.BaseObject and two
dependincies should
be assumed as equal only if
dep1.id == dep2.id
&&
dep1.type == dep2.type
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
