Re: Help needed from Java developer to finish maven

[Hilco Wijbenga]

Hi Hartmut,

On 21 April 2017 at 03:46, Hartmut Goebel <address@hidden> wrote:
> I'm seeking for help from some skilled Java developer. I nearly finished
> bootstrapping maven: I made it to start up, but now fails with this
> error message:
>
> org.apache.maven.InternalErrorException: Internal error:
> com.google.inject.ProvisionException: Unable to provision, see the
> following errors:
>
> 1) null returned by binding at org.eclipse.sisu.wire.LocatorWiring
>  but parameter 1 of
> org.eclipse.aether.transport.wagon.WagonTransporterFactory.<init>() is
> not @Nullable
>   while locating org.eclipse.aether.transport.wagon.WagonConfigurator
>     for parameter 1 at
> org.eclipse.aether.transport.wagon.WagonTransporterFactory.<init>(Unknown 
> Source)
>   while locating org.eclipse.aether.transport.wagon.WagonTransporterFactory
>   while locating java.lang.Object annotated with *
>
> I assume this means some meta-date file is missing in one of the jars
> (like plexus/components.xml or sisu/javax.inject.Named), but I was not
> able to find any missing file or data. may.
>
> Any tipps?

(I've been lurking on this ML, I know very little about Guix or Guile.
I had hoped to use Guix for my own packages in my $HOME but that seems
difficult.)

When the Maven devs want to cut a new release they run Maven's
thousands of unit and integration tests before offering it to the
community for a test drive. Only after all that is successful, is the
new Maven release announced to the world. I had a look at
maven-with-guix-versions.patch and I notice that you are changing
various version numbers and replacing some JARs with other JARs. Why
would you do that? Why do you expect the end result to work well? Or
at all? How would anyone be able to trust this patched Maven? (BTW,
Logback is an SLF4J implementation so your comment there makes no
sense.)

You obviously put a lot of effort into this so you must have had a
good reason to make those changes. I'm guessing that you have a very
different goal in mind than I think you do. :-) So what is that goal?
What are you trying to achieve? I'll try to take a few guesses with
comments/suggestions.

1. Offer Maven as a Guix package so one can easily install Maven and
be productive as a Java dev
* For this scenario you don't want to change Maven. You need to be
able to trust your build tool. You need to be able to get support from
the Maven community which is not going to happen if your Maven is
patched and behaving abnormally.
* I would suggest to take the tarball available at
http://maven.apache.org/download.cgi and extract it "into" the Guix
store. It comes with a bunch of JARs that you could replace with links
to wherever they are in the Guix store. Each could be a separate
package. There are also a couple of OS specific files for Jansi which
you can probably treat the same as JARs (i.e. replace with a link to
somewhere else). With that and $MAVEN_HOME/bin on $PATH, Maven should
work. You now have one issue left: the $MAVEN_HOME/lib/ext directory.
It should be possible for a dev to put Maven extensions in that
directory (Maven will pick them up automatically when starting up). I
don't know how one would handle that in Guix.

2. Offer JARs as Guix packages
* Don't try to build the JAR, simply download it from Maven Central
(for example) and make it available in the Guix store.
* The POM (or one of its parents) has information like author(s),
license, and web site. If it's not available there, use a default like
http://www.gnu.org if the web site is missing.

3. Offer JARs as Guix packages by building them from source
* I think this is what you are aiming for? I would suggest installing
Maven as in (1) and then invoking the build with
"-Dmaven.repo.local=/some/tmp/location" (or with "--settings
/some/tmp/location/guix-settings.xml"). Ignoring all direct and
transitive dependencies of this one JAR, you're done. (After the
build, you can remove /some/tmp/location.) This should actually get
you pretty far because tools that use JARs would have an explicit list
of necessary JARs. (Maven is a good example, the lib directory
contains everything that is needed.)

I hope this is of use to you. If you have more questions, ask away.

Cheers,
Hilco