maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tamás Cservenák (JIRA) <j...@codehaus.org>
Subject [jira] Commented: (MINDEXER-19) Make ArtifactContextProduces smarter about main artifact selection
Date Wed, 30 Mar 2011 08:38:22 GMT

    [ http://jira.codehaus.org/browse/MINDEXER-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=261910#action_261910
] 

Tamás Cservenák commented on MINDEXER-19:
-----------------------------------------

For history' sake, here is the description of the problem:


The JBoss Nexus introduces Audit information files stored as "artifactId-version.ext.audit.json".
The problem is that these "metafiles" _violates_ the M2 repository layout in a way, that repositories
with this Audit information now have _more than one main artifacts_. As proof, here is an
example: In case of [Apache Avalon Framework 4.1.5|https://repository.jboss.org/nexus/content/repositories/thirdparty-releases/apache-avalon/avalon-framework/4.1.5/],
where _real_ main artifact is of type "jar", you can address both ("real" and "fake") main
artifacts as this below, making Maven download and consume them:

{noformat}
  <dependency>
    <groupId>apache-avalon</groupId>
    <artifactId>avalon-framework</artifactId>
    <version>4.1.5</version>
    <type>jar</type>
  </dependency>
{noformat}

Note: the "type" is redundant, but I added just for clarity sake ("JAR" is the default dependency
type in Maven).

Having this as dependency in a project, produces this expected build output:

{noformat}
cstamas@marvin test$ mvn -s settings.xml clean install
[INFO] Scanning for projects...
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building test Maven Mojo 1.0+-SNAPSHOT
[INFO] ------------------------------------------------------------------------
Downloading: https://repository.jboss.org/nexus/content/repositories/thirdparty-releases/apache-avalon/avalon-framework/4.1.5/avalon-framework-4.1.5.jar
Downloaded: https://repository.jboss.org/nexus/content/repositories/thirdparty-releases/apache-avalon/avalon-framework/4.1.5/avalon-framework-4.1.5.jar
(72 KB at 21.8 KB/sec)
....
{noformat}

But alas, modifying the "type" node of the dependency, clearly shows that the "jar.audit.json"
is treated the same way as the jar by Maven. Just modify in your "test" project the dependency,
change it's type from "jar" to "jar.audit.json":

{noformat}
  <dependency>
    <groupId>apache-avalon</groupId>
    <artifactId>avalon-framework</artifactId>
    <version>4.1.5</version>
    <type>jar.audit.json</type>
  </dependency>
{noformat}

And build it:

{noformat}
cstamas@marvin test$ mvn -s settings.xml clean install
[INFO] Scanning for projects...
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building test Maven Mojo 1.0+-SNAPSHOT
[INFO] ------------------------------------------------------------------------
Downloading: https://repository.jboss.org/nexus/content/repositories/thirdparty-releases/apache-avalon/avalon-framework/4.1.5/avalon-framework-4.1.5.jar.audit.json
[WARNING] Checksum validation failed, no checksums available from the repository for https://repository.jboss.org/nexus/content/repositories/thirdparty-releases/apache-avalon/avalon-framework/4.1.5/avalon-framework-4.1.5.jar.audit.json
Downloaded: https://repository.jboss.org/nexus/content/repositories/thirdparty-releases/apache-avalon/avalon-framework/4.1.5/avalon-framework-4.1.5.jar.audit.json
(189 B at 0.1 KB/sec)
....
{noformat}

This proves, that the GAV apache-avalon : avalon-framework : 4.1.5 in JBoss repository _has
two main artifacts_ with different types.

Note: same stands for POM, there is "artifactId-version.pom.audit.json" present also. This
is important in discussion below.

---

Now, what this causes in Maven Indexer is next problem: Indexer expects following assumptions
to be true: in GAV directory (the ["version directory"|https://repository.jboss.org/nexus/content/repositories/thirdparty-releases/apache-avalon/avalon-framework/4.1.5/]
_it's expected to have one main artifact, and 0 or more classified (artifacts with classifier)
artifacts_.

What happens, is that Indexer finds multiple extensions ("pom.audit.json", "jar" and "jar.audit.json")
for same GAV (apache-avalon:avalon-framework:4.1.5). Indexer also maintains _index uniqueness_
based on GAV. Hence, the _first "artifact suspect" file it stumbles upon_ becomes indexed,
and the second is just skipped (uniqueness check fails on GAV). Here, the "pom.audit.json"
(which is not ".pom", but neither ".pom.sha1" or ".pom.md5" that are filtered out or "recognized"
as artifact POM or checksums as part of M2 repository layout) is stumbled upon first, and
is taken/considered as main artifact.

Indexer _intentionally_ cannot take the POM -> artifact matching route, since _figuring
out artifact extension_ out of POM "packaging" is not always possible (think 3rd party extensions,
like "nexus-plugin" packaging is actually "jar" extension, etc). Hence, it goes the artifact
-> POM route (which is trivial, strip off extension and replace it with ".pom"). This is
one of the oldest limitations in Indexer code.

But, the "heuristics" fails here, since GAV parser (that parses file's path to "reengineer"
it's GAV) _succeeds_ in parsing the "pom.audit.json" file path resulting in GAV "apache-avalon:avalon-framework:4.1.5"
and extension "pom.audit.json", and assumption is made _this is the main artifact_ (parsed
GAV would contain classifier if classifier is present). 

Clearly, this is where Indexer fails, since in this very case, packaging set in POM is known
("jar"), but due to initial requirements when Indexer was implemented, this check (to "crank
up the POM and parse it"), was sacrificed over _speed_ of scanning. The POM reading would
still not offer "full solution", again, think non-core packagings and 3rd party build extensions.


This again raises the general question: "What is the extension of packaging FOO?" -- to have
answered without having ArtifactHandler access (this happens in Nexus, not in Maven). The
other way ("What is the packaging of extension FOO?") is even more tricky and impossible,
since packaging to extension mapping is not _bijective_ (ie. packaging "ear" and "nexus-plugin"
both produce extension "jar", just like packaging "jar" is).


Possible solutions:

a) stop using "artifactId-version.ext.audit.json" as auditing JSON filename, but change it
to something that "breaks" the M2 layout, like this ".artifactId-version.ext.audit.json" (prepend
with dot). This will make Indexer skip this file (will not be considered as artifact), but
also Nexus will _hide it_ while browsing the repository (direct request to file will still
work, only "browsing" the repository will not show it).

b) Introduce some "skip it" extension in Indexer (this needs to be added to Maven Indexer),
like ".noindex". If the filename _ends_ with exactly this string, Indexer should skip it,
not consider it for indexing (so the Audit JSON filename would be "artifactId-version.ext.audit.json.noindex").

c) move off to attributes to store audit information


> Make ArtifactContextProduces smarter about main artifact selection
> ------------------------------------------------------------------
>
>                 Key: MINDEXER-19
>                 URL: http://jira.codehaus.org/browse/MINDEXER-19
>             Project: Maven Indexer
>          Issue Type: Improvement
>    Affects Versions: 4.0.0
>            Reporter: Tamás Cservenák
>
> Make ArtifactContextProduces smarter about main artifact selection.
> See https://issues.sonatype.org/browse/NEXUS-4187
> Main problem here is that repository in issue above is _not obeying_ M2 repository layout.
> At least an improvement could be, to prefer "core packaging" (those known by Maven Core)
over others, but this will not fix the issue with new packagings introduced by extensions.

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

       

Mime
View raw message