Created attachment 914094 [details]
pom1.xml

Created attachment 914095 [details]
pom2.xml

They are empty simply because neither pom itself nor parent pom(s) contain information about version of given dependency. IIRC xmvn-install checks for such inconsistencies and stops the build if metadata doesn't contain all necessary information. So even current version of javapackages-tools shouldn't really cause any problems. It would be probably nice to print some warning in mvn_artifact and maybe fail the build there. This will be addressed in javapackages-tools 4.2.0.

(In reply to Michal Srb from comment #3)
> They are empty simply because neither pom itself nor parent pom(s) contain
> information about version of given dependency.

These POMs would be incorrect with upstream Maven, but XMvn always allowed unset versions. In these cases it is assumed that version is SYSTEM.

> IIRC xmvn-install checks for
> such inconsistencies and stops the build if metadata doesn't contain all
> necessary information.

Yes it does.

> So even current version of javapackages-tools
> shouldn't really cause any problems.

The problem is that generated reactor file is invalid and xmvn-install will fail.

[ERROR] Artifact installation failed
org.fedoraproject.xmvn.tools.install.impl.ArtifactInstallationException: Artifact dependency must have requested version set
	at org.fedoraproject.xmvn.tools.install.impl.InstallationPlan.validate(InstallationPlan.java:118)
	at org.fedoraproject.xmvn.tools.install.impl.InstallationPlan.<init>(InstallationPlan.java:55)
	at org.fedoraproject.xmvn.tools.install.impl.DefaultInstaller.install(DefaultInstaller.java:298)
	at org.fedoraproject.xmvn.tools.install.cli.InstallerCli.run(InstallerCli.java:65)
	at org.fedoraproject.xmvn.tools.install.cli.InstallerCli.main(InstallerCli.java:86)

What I used as workaround:

# Workaround for rhbz#1115409
sed -i 's|<ns1:requestedVersion></ns1:requestedVersion>|<ns1:requestedVersion>SYSTEM</ns1:requestedVersion>|' .xmvn-reactor

(In reply to Mikolaj Izdebski from comment #4)
> (In reply to Michal Srb from comment #3)
> > They are empty simply because neither pom itself nor parent pom(s) contain
> > information about version of given dependency.
> 
> These POMs would be incorrect with upstream Maven, but XMvn always allowed
> unset versions. In these cases it is assumed that version is SYSTEM.
> 

So should I set requestedVersion to "SYSTEM" in cases like this? If so, then maybe xmvn-install and other tools don't have to be so strict about it and assume that requestedVersion is SYSTEM if not specified otherwise. Current behavior of mvn_artifact with empty version is a bit ugly, but it would be easy to skip whole requestedVersion if it's empty.


> 
> The problem is that generated reactor file is invalid and xmvn-install will
> fail.

The problem from my POW is that there is no real definition of valid reactor file. If we assume that reactor file should conform to metadata XSD, then requestedVersion doesn't have to be specified at all (it has minOccurs=0).

(In reply to Michal Srb from comment #6)
> (In reply to Mikolaj Izdebski from comment #4)
> > (In reply to Michal Srb from comment #3)
> > > They are empty simply because neither pom itself nor parent pom(s) contain
> > > information about version of given dependency.
> > 
> > These POMs would be incorrect with upstream Maven, but XMvn always allowed
> > unset versions. In these cases it is assumed that version is SYSTEM.
> > 
> 
> So should I set requestedVersion to "SYSTEM" in cases like this? If so, then
> maybe xmvn-install and other tools don't have to be so strict about it and
> assume that requestedVersion is SYSTEM if not specified otherwise. Current
> behavior of mvn_artifact with empty version is a bit ugly, but it would be
> easy to skip whole requestedVersion if it's empty.

I can make it optional in XMvn.

> > The problem is that generated reactor file is invalid and xmvn-install will
> > fail.
> 
> The problem from my POW is that there is no real definition of valid reactor
> file. If we assume that reactor file should conform to metadata XSD, then
> requestedVersion doesn't have to be specified at all (it has minOccurs=0).

Reactor file (installation plan) must be valid metadata (conform to XSD) and addtionally pass these checks:

https://github.com/mizdebsk/xmvn/blob/2.0.0/xmvn-tools/xmvn-install/src/main/java/org/fedoraproject/xmvn/tools/install/impl/InstallationPlan.java#L75-L137

XMvn will now use default value SYSTEM if requestedVersion is not specified. But empty requestedVersion is still incorrect.

Commit 6a98089 in javapackages-tools sets requestedVersion to "SYSTEM" if it couldn't be determined, so requestedVersion should never be empty now.

My change that made requestedVersion optional seems to break maven.prov:

Traceback (most recent call last):
  File "/usr/lib/rpm/maven.prov", line 56, in <module>
    builder = TagBuilder()
  File "/usr/lib/rpm/maven.prov", line 49, in __init__
    for artifact in mdata.get_provided_artifacts():
  File "/usr/lib/python2.7/site-packages/javapackages/metadata/metadata.py", line 100, in get_provided_artifacts
    artifact = MetadataArtifact.from_metadata(a)
  File "/usr/lib/python2.7/site-packages/javapackages/metadata/artifact.py", line 143, in from_metadata
    for dep in metadata.dependencies.dependency}
  File "/usr/lib/python2.7/site-packages/javapackages/metadata/artifact.py", line 143, in <setcomp>
    for dep in metadata.dependencies.dependency}
  File "/usr/lib/python2.7/site-packages/javapackages/metadata/dependency.py", line 85, in from_metadata
    requestedVersion = metadata.requestedVersion.strip()
AttributeError: 'NoneType' object has no attribute 'strip'

Good catch, it should be fixed in 4b24185.

Fixed in Rawhide.