Bug 1007437 - Importing mavenized jar with parent pom specified is not handled correctly
Importing mavenized jar with parent pom specified is not handled correctly
Product: JBoss BRMS Platform 6
Classification: JBoss
Component: Business Central (Show other bugs)
Unspecified Unspecified
high Severity high
: CR1
: 6.0.0
Assigned To: Toni Rikkola
Radovan Synek
: Regression
Depends On:
Blocks: bpms6_ux/brms6_ux
  Show dependency treegraph
Reported: 2013-09-12 09:37 EDT by Radovan Synek
Modified: 2015-01-29 04:59 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-08-06 16:20:40 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
mavenized jar (568.48 KB, application/x-java-archive)
2013-09-12 09:37 EDT, Radovan Synek
no flags Details
server log (89.60 KB, text/x-log)
2013-09-12 09:47 EDT, Radovan Synek
no flags Details
stacktrace in ER5 (15.38 KB, text/x-log)
2013-12-05 13:05 EST, Zuzana Krejčová
no flags Details
screenshot with ER5 (38.07 KB, image/png)
2013-12-05 13:06 EST, Zuzana Krejčová
no flags Details

  None (edit)
Description Radovan Synek 2013-09-12 09:37:17 EDT
Created attachment 796864 [details]
mavenized jar

Description of problem:
uploading mavenized jar with parent pom specified (see the attached jar) ends up with error in server log, when trying to add this jar to project as dependency (saying that groupId and version is missing - which is observable in UI as well)

Version-Release number of selected component (if applicable):

Steps to Reproduce:
1. import attached jar into Asset repository
2. choose this artifact as dependency of your project
3. see the server log & UI

Expected results:
mavenized jar should be handled properly and groupId and version should be taken from the parent pom element
Comment 1 Radovan Synek 2013-09-12 09:47:08 EDT
Created attachment 796869 [details]
server log
Comment 2 manstis 2013-09-12 09:50:26 EDT
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?
Comment 3 Edson Tirelli 2013-09-16 15:32:08 EDT
Porcelli will work with Mario to get this fixed as it probably involves changes on both front end and back end.
Comment 4 Alexandre Porcelli 2013-09-17 12:43:27 EDT
This bug is located at org.kie.scanner.ArtifactResolver on its getResolverFor(InputStream pomStream) method.
Comment 5 Mario Fusco 2013-09-18 05:38:50 EDT
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.
Comment 6 Toni Rikkola 2013-09-19 03:43:41 EDT
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.
Comment 7 Mario Fusco 2013-09-19 06:59:28 EDT
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
Comment 11 Radovan Synek 2013-10-15 07:53:03 EDT
Verified on BPMS-6.0.0.ER4
Comment 12 Zuzana Krejčová 2013-12-05 13:04:54 EST
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.
Comment 13 Zuzana Krejčová 2013-12-05 13:05:26 EST
Created attachment 833290 [details]
stacktrace in ER5
Comment 14 Zuzana Krejčová 2013-12-05 13:06:06 EST
Created attachment 833291 [details]
screenshot with ER5
Comment 15 Mario Fusco 2013-12-06 11:04:41 EST
Toni is investigating on this.
Comment 16 Toni Rikkola 2013-12-10 06:29:31 EST
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.
Comment 17 Radovan Synek 2013-12-11 07:05:11 EST
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?
Comment 18 Toni Rikkola 2013-12-13 03:22:31 EST
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.
Comment 19 Toni Rikkola 2014-01-08 03:18:00 EST
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.
Comment 20 Radovan Synek 2014-01-22 09:01:01 EST
Verified with BRMS-6.0.0.CR1

Note You need to log in before you can comment on or make changes to this bug.