Maven repo / mvnosgi broken (again)

[maggu2810]

I hope this is not related to #89 (e.g. the bugfix for that).

I have a "real" pom, a jar and the generated mvnosgi pom. In the content page the mvnosgi pom is a child of the jar (ok, this was expected), the real pom is no child. The generated Maven repository contains the mvnosgi pom and the jar at the expected location location. The location of the real pom does not contain the jar. So, at this GAV location the pom and the jar is expected. Caused by the missing jar it could not be fetched by the real GAV.

[maggu2810]

I updated to from a custom 0.9.0-SNAPSHOT to the 0.9.4 release, refreshed the channel aspects. Problem still present.

[ctron]

So the "real" pom must either be a child of the JAR, or have the GAV information as meta data, supplied by the Maven upload process or the Maven import process.

[maggu2810]

I cannot remember, but I thought that the two files (jar + pom) have been uploaded using Maven. Will deploy a jar later and check this. But I can test this not until the end of the week. I set a reminder and report...

[maggu2810]

• I am using the master of yesterday.
• I created a new channel
• I added a newly created deploy group + key
• I added the mvnosgi channel aspect (and all that dependencies).
• I started mvn deploy

  ~/workspace/projects/package-drone/git/parent $ mvn clean verify deploy -DaltDeploymentRepository=pdrone::default::http://deploy:f9c3c7f6cd6567a01e424a3fb8e5c0e4b323e14e6645e4de42b2b9bf7ccc216e@m3800:8080/maven/7622B88D-CDB9-4F5C-A7D5-302E754B6968

http://127.0.0.1:8080/maven/7622B88D-CDB9-4F5C-A7D5-302E754B6968/de/dentrassi/package/drone/de.dentrassi.osgi.converter/1.0.0-SNAPSHOT/

..
de.dentrassi.osgi.converter-1.0.0-20150617.171502-1.pom
de.dentrassi.osgi.converter-1.0.0-20150617.171502-1.pom.md5
de.dentrassi.osgi.converter-1.0.0-20150617.171502-1.pom.sha1
maven-metadata.xml
maven-metadata.xml.md5
maven-metadata.xml.sha1

http://127.0.0.1:8080/maven/7622B88D-CDB9-4F5C-A7D5-302E754B6968/mvnosgi/de.dentrassi.osgi.converter/1.0.0.20150317-1103/

..
de.dentrassi.osgi.converter-1.0.0.20150317-1103.jar
de.dentrassi.osgi.converter-1.0.0.20150317-1103.jar.md5
de.dentrassi.osgi.converter-1.0.0.20150317-1103.jar.sha1
de.dentrassi.osgi.converter-1.0.0.20150317-1103.pom
de.dentrassi.osgi.converter-1.0.0.20150317-1103.pom.md5
de.dentrassi.osgi.converter-1.0.0.20150317-1103.pom.sha1

So, I think there is something wrong.

[ctron]

Forgive me, but I don't see it.

[maggu2810]

Shouldn't there be a jar file also in the first URL?

[ctron]

Indeed.

[ctron]

I will have a look at this after the milestone 4, next week.

[ctron]

I had to re-schedule this to m6. Sorry.

[maggu2810]

No problem at all. If it would be urgent, I had inspected it myself in detail.

[ctron]

I am just dumping what I found out in the following comments ...

Ok, so what I found out it that the maven repository aggregator seems not to consider the JAR anymore which is place beside (as sibling) to the JAR file. But I am not sure if this is actually correct from the upload process.

[ctron]

So I think that one of the changes we made for mvnosgi is the cause of that.

The current maven repository generator expects the POM to be a child of the JAR:

 - jar1
    -> pom1
 - jar2
    -> pom2

This can be achieved by either generating or extracting the POM file from the JAR file. However in the past (and it should be brought back) it was possible to deploy jar and pom side by side. Since gradle for example does not embed the POM file into the JAR file. So the layout will be:

 - jar1
 - pom1
 - jar2
 - pom2

Which should be supported as well.

[afischer211]

What are the implications of this bug? My build-jobs deploys a bunch of artifacts with own pom-file, so I have always a list of sibling pom and jar-files in my channels...

[ctron]

Right now the implications are that a simple maven deploy cannot generate the data for a simple maven download. Unless you have the pom extractor which extracts POMs from JARs.

This should not be required! So I made a fix which looks good. But since there are so many possible combinations now, I want to make a few test cases before making the next milestone release. Fortunately testing this one is rather easy. At least when you got defined what is "correct". There are a few special cases where I still have to think what the best approach is. Like when you have provided, extracted and sub-pom maven coordinates at the same time.

As a result uploaded maven artifacts should be downloadable the same way they got uploaded. Without any additional processing.