[
http://jira.codehaus.org/browse/MRRESOURCES-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269512#action_269512
]
Andrew Phillips commented on MRRESOURCES-55:
--------------------------------------------
Implementation note: the suggested patch completely preserves the original
codepath, for minimum impact on existing code. A "cleaner" implementation could
let
{noformat}
ProcessRemoteResourcesMojo.downloadBundles
{noformat}
*always* call the new 7-arg version of {{Downloader.download}}
{noformat}
public File download(groupId, artifactId, version, type, classifier,
localRepository, remoteRepositories)
{noformat}
Equally, {{DefaultDownloader.download}} itself could always call
{noformat}
artifactFactory.createDependencyArtifact(groupId, artifactId, versionRange,
type, classifier, scope)
{noformat}
but then the defaulting logic ("if no type then type = 'jar' etc.") that is
currently in {{ArtifactFactory}} would have to be "lifted up" to
{{DefaultDownloader}} or even {{ProcessRemoteResourcesMojo}}, which seems like
abstraction leakage.
> Support groupId:artifactId:version:type and
> groupId:artifactId:version:type:classifier as resource bundle references
> --------------------------------------------------------------------------------------------------------------------
>
> Key: MRRESOURCES-55
> URL: http://jira.codehaus.org/browse/MRRESOURCES-55
> Project: Maven 2.x Remote Resources Plugin
> Issue Type: New Feature
> Affects Versions: 1.2
> Reporter: Andrew Phillips
> Attachments: MRRESOURCES-55-preserve-original-codepath-patch.txt
>
>
> Currently, the RR plugin only support groupId:artifactId:version as an
> identifier for a remote bundle. However, there are quite a few use cases
> (e.g. platform-specific bundles) where it would be very useful to be able to
> identify bundles additionally by classifier. The current workaround we use -
> different versions - works, but isn't particularly elegant or semantically
> accurate.
> The proposal therefore is to also allow identifiers of the type
> groupId:artifactId:version:type:classifier
> As Brett pointed out in an IRC chat, this automatically adds the type to the
> identifier as well. One could ignore it or enforce 'jar' (the current
> default), but on the other hand there seems to be no reason *not* to allow
> types such as 'zip', or even 'war' or 'ear'. Only 'pom' doesn't make much
> sense.
> Two potential implementations, with tests, are attached.
--
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
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
