Local build passes.
Maven is installable in fully-modularized chroot.

Basic Maven functionality works, but it can't build much until java module is fixed - nothing provides fontconfig(x86-64) needed by java-1.8.0-openjdk-1:1.8.0.144-5.b01.module_b7449e02.x86_64

maven-local (from java module) is not installable either: nothing provides mvn(org.apache.maven.plugins:maven-javadoc-plugin) needed by maven-local-5.0.0-7.module_b7449e02.noarch

Now I noticed that java module got dep on fonts added, which I didn't see before. After re-testing with fonts module, Maven smoke test passed. So everything (in default install profile of maven) seems to work from my PoV.

The point of the `rationale` component field is to document why that particular component is there.  "Generated" isn't particularly useful.  "Autogenered -
 runtime dependency of X." would be better.

I've updated yaml file, but I have serious doubts if it's better than before.

The rationale fields might be a bit overwhelming, but that's just how it is if a component is needed for building or running many things. I don't know how the tool which you used for generating that works in detail, but maybe you could format the rationale field a bit differently -- YAML lets you spread strings over several lines for instance. E.g.

[...]
            apache-commons-beanutils:
                rationale: >
                    Runtime dependency of apache-commons-digester,
                        apache-commons-validator.
                    Build dependency of apache-commons-configuration,
                        apache-commons-digester, apache-commons-jxpath,
                        apache-commons-validator.
            apache-commons-cli:
[...]

Anyway, here's your review:

- yamllint isn't entirely happy:

nils@gibraltar:/tmp> yamllint maven.yaml 
maven.yaml
  1:1       warning  missing document start "---"  (document-start)
  6:81      error    line too long (83 > 80 characters)  (line-length)
  7:81      error    line too long (84 > 80 characters)  (line-length)
[...]
  263:81    error    line too long (114 > 80 characters)  (line-length)
  264:81    error    line too long (101 > 80 characters)  (line-length)
  266:81    error    line too long (139 > 80 characters)  (line-length)

  -> add the three dashes -- not sure why yamllint flags the long lines as an error

Assuming that you'll add the missing document start dashes, this module is APPROVED.

Things to watch for:

* you don't filter anything out; make sure all subpackages you generate have
  their runtime dependencies satisfied

* you ship quite a lot of packages in standard paths but only maven itself is
  listed in the API block; does it mean no one can rely on anything else you
  provide?

* hopefully you plan to stop buildrequiring the bootstrap module at some point
  in the future

(In reply to Nils Philippsen from comment #5)
>   -> add the three dashes -- not sure why yamllint flags the long lines as
> an error

I'll reformat rationales. And someone should fix modulemd spec, as I based my work on it - it doesn't start with three dashes either. (https://pagure.io/modulemd/issue/49)

> Assuming that you'll add the missing document start dashes, this module is
> APPROVED.

Thanks!


(In reply to Petr Šabata from comment #6)
> * you don't filter anything out; make sure all subpackages you generate have
>   their runtime dependencies satisfied

Instead of filtering subpackages, I disable them with %bcond_* build conditionals (hence all the macros in modulemd).

Almost all dependencies are satisfied, except two binary packages:

- hawtjni requires autoconf and automake, which are part of autotools module, which is not runtime dependency of maven module. I think that's fine since hawtjni is not part of default install profile, isn't it? I don't want to filter it out as it's build-dependency of some packages (will be needed once I get rid of build-depending on bootstrap).

- python3-javapackages requires python3, python3-lxml and python3-six. I assume they will be modularized some time "soon". Again, python3-javapackages is not part of default install profile but will be needed, so can't be filtered.

> * you ship quite a lot of packages in standard paths but only maven itself is
>   listed in the API block; does it mean no one can rely on anything else you
>   provide?

I'm not sure about exact criteria for classifying package as module API and honestly, I haven't thought about this too much. I've put only maven there as API can always be extended, but shrinking it may be more tricky.

> * hopefully you plan to stop buildrequiring the bootstrap module at some
> point
>   in the future

Yes, of course. The plan is to replace buildrequires on bootstrap with: platform, java, autotools, python3 and maven module itself (older version). Most of packages in this module are built with Maven, so there's no other way around that...

(fedrepo-req-admin):  The Pagure repository was created at https://src.fedoraproject.org/modules/maven

Imported to dist-git: https://src.fedoraproject.org/modules/maven/c/b69d939f4238a25fcabcf219e0f37065a0445531

maven-master-20170907234122 was successfully built in Koji.

Refs:
https://koji.fedoraproject.org/koji/buildinfo?buildID=967933
https://mbs.fedoraproject.org/module-build-service/1/module-builds/924
https://pdc.fedoraproject.org/rest_api/v1/unreleasedvariants?variant_uid=maven-master-20170907234122

(In reply to Mikolaj Izdebski from comment #7)
> Almost all dependencies are satisfied, except two binary packages:
> 
> - hawtjni requires autoconf and automake, which are part of autotools
> module, which is not runtime dependency of maven module. I think that's fine
> since hawtjni is not part of default install profile, isn't it? I don't want
> to filter it out as it's build-dependency of some packages (will be needed
> once I get rid of build-depending on bootstrap).
> 
> - python3-javapackages requires python3, python3-lxml and python3-six. I
> assume they will be modularized some time "soon". Again,
> python3-javapackages is not part of default install profile but will be
> needed, so can't be filtered.

Then your module should (eventually) runtime-depend on them. Mind that depending on a module doesn't mean that its packages get installed, but that they are available. E.g. in the case of hawtjni you want the autofoo packages available so your users can install the hawtjni package.