Bug 1007437 - Importing mavenized jar with parent pom specified is not handled correctly
Summary: Importing mavenized jar with parent pom specified is not handled correctly
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss BRMS Platform 6
Classification: Retired
Component: Business Central
Version: 6.0.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: CR1
: 6.0.0
Assignee: Toni Rikkola
QA Contact: Radovan Synek
URL:
Whiteboard:
Depends On:
Blocks: bpms6_ux, brms6_ux
TreeView+ depends on / blocked
 
Reported: 2013-09-12 13:37 UTC by Radovan Synek
Modified: 2015-01-29 09:59 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-08-06 20:20:40 UTC
Type: Bug
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1187068 0 unspecified CLOSED Importing mavenized jar with parent pom specified is not handled correctly 2021-02-22 00:41:40 UTC

Internal Links: 1187068

Description Radovan Synek 2013-09-12 13:37:17 UTC
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):
BRMS-6.0.0.ER2

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 13:47:08 UTC
Created attachment 796869 [details]
server log

Comment 2 manstis 2013-09-12 13:50:26 UTC
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 19:32:08 UTC
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 16:43:27 UTC
This bug is located at org.kie.scanner.ArtifactResolver on its getResolverFor(InputStream pomStream) method.

Comment 5 Mario Fusco 2013-09-18 09:38:50 UTC
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 07:43:41 UTC
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 10:59:28 UTC
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 11:53:03 UTC
Verified on BPMS-6.0.0.ER4

Comment 12 Zuzana Krejčová 2013-12-05 18:04:54 UTC
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 18:05:26 UTC
Created attachment 833290 [details]
stacktrace in ER5

Comment 14 Zuzana Krejčová 2013-12-05 18:06:06 UTC
Created attachment 833291 [details]
screenshot with ER5

Comment 15 Mario Fusco 2013-12-06 16:04:41 UTC
Toni is investigating on this.

Comment 16 Toni Rikkola 2013-12-10 11:29:31 UTC
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 12:05:11 UTC
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?

Comment 18 Toni Rikkola 2013-12-13 08:22:31 UTC
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 08:18:00 UTC
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 14:01:01 UTC
Verified with BRMS-6.0.0.CR1


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