[
http://jira.codehaus.org/browse/MRM-1061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=177548#action_177548
]
Reiner Saddey commented on MRM-1061:
------------------------------------
The technical process of indexing is not an end in itself. So what does Archiva
index for?
The Maven repository format is self contained and does not require any
additional indexing for clients to successfully retrieve or browse artifacts.
Indeed Maven build processes accept file system based repositories (and even
create them on their own as well within ~/.m2/repository).
Basically, indexing is a way to prepare information in advance, that would
otherwise be time consuming to compute on demand. Where could this demand stem
from? Besides some internal processes within Archiva (possibly for efficiently
implementing automatic purges or repository groups, aka virtual repositories)
it's humans (or continuous build systems), that benefit from structural
information, such as 'Used By' and 'Dependency Tree'.
For 'Used By' and 'Dependency Tree' we would like to have two choices to derive
information from:
1. Dependencies as stated in the pom.xml of an artifact
2. Dependencies as having been interpolated during the actual build of an
artifact
However, alternative 2 requires comprehensive access to the information that
has been used within the reactor at the time it was performing the actual build
of an artifact. To my knowledge, as of now, Maven does not specify a format
that would describe how this information should be bound or incorporated within
the pom.xml that results from a Maven build.
If this additional information were supplied in a non-agreed-upon way, any
dependency tree would be bound to be very small and incomplete, showing nodes
whose vertices are unknown, as the nodes most probably would lack the
additional information that would be required to complete the tree (e.g. most,
if not all, artifacts present within repo1.maven.org).
In order to be of relevant use, alternative 2 cannot be implemented in a local
fashion, but instead requires cooperation that is far beyond the reach of any
artifact repository manager that solely accepts what has been produced by
Maven, Hudson or Continuum. It's only them builders and the data they provide
who can help us understand what and how they were doing while producing an
artifact.
In the meantime we should stick to alternative 1 and try to extract information
from the pom.xml in a way that reflects its semantics as truly as possible. In
my opinion, Gwen's suggestion appears to fit the bill for now.
> 'Used By' page incorrect and 'Dependency Tree' page crash when specifying
> dependency version using <dependencyManagement> in parent POM.
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: MRM-1061
> URL: http://jira.codehaus.org/browse/MRM-1061
> Project: Archiva
> Issue Type: Bug
> Components: web application
> Affects Versions: 1.1.3
> Environment: Debian GNU/Linux (unstable), Apache Tomcat 6.0.18
> Reporter: Duncan Doyle
> Fix For: 1.x
>
>
> In our projects we specify the versions of artifacts/dependencies in a parent
> POM using the <dependencyManagement> mechanism. This enables us to easily
> specify the version of an artifact to be used for all the modules in our
> project. However, when looking at the 'Dependencies' page of such a module in
> Archiva, the versions of the dependencies are not listed. Furthermore, when
> opening the 'Dependency Tree' screen, it crashes with the following error:
> {quote}
> org.apache.maven.archiva.common.ArchivaException: Unable to generate graph
> for [com.fortis.fffj:FFFJ-Integration:1.1.1-20090105.220705-5] : Unable to
> create ArchivaArtifact with empty version [junit:junit:null::pom]
> {quote}
> Another problem, that is probably a result of this issue, is that when
> looking at an artifact's 'Used By' page (for example JUNIT), the page does
> not list the modules that use the artifact if the artifact's version is
> specified in the modules parent POM using the <dependencyManagement>
> mechanism.
--
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
