Bug 1007437

Created attachment 796869 [details]
server log

The last time I asked about this (can't remember whether it was you or Toni) I was told this had been fixed; i.e. GAV details in an uploaded JAR were resolved from the parent if necessary?

Porcelli will work with Mario to get this fixed as it probably involves changes on both front end and back end.

This bug is located at org.kie.scanner.ArtifactResolver on its getResolverFor(InputStream pomStream) method.

We have 2 mechanisms in drools to parse a pom, both taking an InputStream containing the pom.xml file as argument. The first one is in kie-ci and can be used as it follows:

MavenProject mavenProject = MavenProjectLoader.parseMavenPom(pomStream);

Since it internally uses aether and we didn't want such a dependency in drools, we implemented a second custom made parser in drools-compiler that can be invoked like:

PomModel pomModel = MinimalPomParser.parse("pom.xml", pomStream);

However I wrote a quick test to check that both those mechanisms are working correctly with the pom contained in the jar attached to this ticket.

Nevertheless importing that jar on drools-wb I am seeing that it cannot retrieve the group Id and the version of the project (for some reason it resolves the artifact correctly). Talking with Toni we found that there is probably a third mechanism in guvnor that parses the pom file and it is not behaving as expected in this case. I suggested him to reuse one of the 2 algorithms already implemented in drools instead of fixing the third one. 

Toni is about to investigate what guvnor does on this regard.

I unified the parsing for pom.xml data in guvnor.
I found one bug. The popup that allows the user to pick a dependency from the internal m2 repo was not showing group and version for jars that defined these values in the pom.xml parent block.
 
There are still some issue when building projects with mavenised jars as dependencies in drools-wb. So chatted with Mario and giving this back to him.

That last issue was caused by the fact that guvnor still wasn't parsing the pom file correctly. In particular it was using the parent artifactId even when not necessary. I fixed this here https://github.com/droolsjbpm/guvnor/commit/24b9a1574

Verified on BPMS-6.0.0.ER4

Fails again with ER5 - tested with the attached jar as well as others.
The main message is "JBWEB000065: HTTP Status 500 - Unable to parse File 'pom.xml'".

I will add the stacktrace and screenshot next.

Created attachment 833290 [details]
stacktrace in ER5

Created attachment 833291 [details]
screenshot with ER5

Toni is investigating on this.

This worked for a while since we used a more forgiving methods for parsing the pom.xml. 

The reason for failure for why this is failing now is:
"[FATAL] Non-resolvable parent POM: Could not transfer artifact org.optaplanner:optaplanner:pom:6.0.0.Beta3 from/to central (http://repo.maven.apache.org/maven2): No connector available to access repository central (http://repo.maven.apache.org/maven2) of type default using the available factories FileRepositoryConnectorFactory, WagonRepositoryConnectorFactory"

Meaning that the parent pom was not found for this artifact. The upload worked for me on the first try, then I removed optaplanner artifacts from my local repository, tried to upload again and managed to reproduce this.

We could force uploading the jar, like we by mistake did before, but then the builds will still fail since the jars we force upload are missing dependencies. The better way to add mavenized dependencies is adding the dependencies into the projects pom.xml files and letting the build download them from the remote Maven repositories. This will keep the internal Maven repository in better shape.

Situation in 1018220 and this BZ could use a more informative error message.

Since the bug this BZ originally was for does not exists at this point and the real bug is we need a better way to inform the user, I think we should close this.

Toni,
I was also able to replicate this issue on ER5, even if the parent pom of the artifact being uploaded is present in my local repository (.m2). Maven tries to download it from central repo and of course fails. I have this problem only with artifacts (and parent pom) downloaded from some remote repositories. When I try to upload artifact that has been built on my machine, it finishes successfully.

Could this be somehow connected with the following issue?
http://jira.codehaus.org/browse/MNG-5185, i.e. the artifact cannot be found because it came from a different repo?

Not sure. I tested with master and to my surprise it allowed me to upload. 6.0.x still fails. 
I need to do some code comparing to figure this out.

Ok, works now without code changes. Must have been fixed by either a change in Drools core or in other dependencies that the workbench has.

Verified with BRMS-6.0.0.CR1