Re: maven build system - new insights

[Hartmut Goebel]

Hi,

Am 31.01.19 um 18:06 schrieb Julien Lepiller:

Here are my 2cent:

> We found that we need more plugins to be able to build maven projects, and 
> that requires some metadata in the jar file. This metadata is generated by 
> maven-plugin-tools-generators, and maybe we can write a thin java wrapper 
> around it, or use sxml to generate the file.

Regarding the thin java layer it might be interesting to have a look at
Debians build helpers which might contains some of what we need.
Unfortunately it is not well documented (at least i did not find it
quickly), but asking the Debian Java packagers might be helpful.


> If we are going to use mvn and not xmvn, we could change the ant-build-system 
> to generate the repository structure you describe

There seems to be a maven task for doing so: install:install-file [1].


> and have a phase to build a union of these with symlinks. Hopefully, maven 
> will follow the symlinks.

The drawback of this approach is: This only works within the
build-system. Since within a normal environment or profile, there will
be no such unison repo. Thus for every day's work, users will still
download artifacts from the Internet and will not be able to use those
already installed on the system.

One of the points I like at Xmvn is that is does not try to reach out to
the internet. And users should be able to simply replace mvn by xmvn to
ensure only "well known" packages are used.


> It seems we don't need more info in the jar files themselves, but we need to 
> install the pom.xml file alongside the jar itself. Additionnaly, we need 
> "parent poms" because they contain properties and values used by our packages 
> and maven will want to read those.

For the jar an pom-files, install:install-file could help [1]. For the
parent poms I have no idea, beside the Debians build helpers having some
"DebianDependencies" class.


> Xmvn looks very cool, but that's still 32 more packages to build properly and 
> generate metadata for, so it's not clear if that's an advantage when we 
> already have a maven package? I'm also a bit worried that it miqht not work 
> properly, as it's an equivalent of 3.0.0, but we have a newer version of 
> maven.

Oh, I missed one relevant point: these 32 packages are also dependencies
of maven. Thus they are already available. :-) It just that we most
probable could throw out 16 packages from the manual bootstrap. (There
are 3 additional xmvn packages, though.)

The version 3.0.0 is the Xmvn version which seems to be unrelated to maven.

Prior to going down the Xmvn-road we should collect a list of questions
to ask the developers. E.g. [2] say: "Some parts of XMvn require
Gradle". If we need these parts for bootstrapping this would be a
show-stopper.

> We will also need to override dependency and plugin versions for maven to 
> find guix' versions, so we'll need a parser and generator for pom.xml files.

Maybe some xml-search-replace would suffice? E.g. implemented using
SXPATH [3]


[1] https://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html
[2] https://github.com/fedora-java/xmvn/blob/master/README.md
[3] https://www.gnu.org/software/guile/manual/html_node/SXPath.html

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | address@hidden               |
| www.crazy-compilers.com | compilers which you thought are impossible |