Re: Need help from Java-developers

[Chris Marusich]

Hi Hartmut,

I want to help, but I'm not sure how much help I can actually provide.
I'm familiar with Java, but I've only worked a little bit with Maven.
Please forgive me if I say anything that is inaccurate or naive!  You
probably know more about Maven than I do.

Hartmut Goebel <address@hidden> writes:

> Hi,
>
> as bootstrapping maven progresses (see my other post), the need for help
> from Java-developers arises.
>
> To finish all the work to be done after maven bootstrapping, some
> experienced Java developers are needed. The following questions need to
> be answered.
>
>   * Designing the maven-build-system as follows:
>       o How to maven commands map to our build phases? Should they map,
>         should there be new ones?

I'm not sure, but whatever seems simplest and works is probably a good
place to start.

>       o Is there a need to clean up the pom-files prior to building,
>         e.g. remove version numbers?

Why would that be necessary?  Will the presence of the version numbers
interfere with the build somehow?

>       o How to make the maven-build-system to never ever include other
>         jar? Perhaps we need to post-process the generated jars.

Speaking of JAR files, shouldn't we try to avoid them entirely?  My
understanding is that they are compressed files, which means the Guix
daemon won't be able to scan them for references.  I don't know if it's
easy to use Maven to build a project without putting the build output
into a JAR file, though.

>       o How to handle pom-files (see below)
>
>   * Which naming conventions should be used for packages? Maven has the
>     notion of "group-id" and "atrtifact". Should this be kept? OTOH,
>     there are very common packages like "commons-io" aka
>     "apache-commons-io".

Whatever is simplest to do is a good place to start.  I think the name
of the Guix package is what matters most, right?  So, maybe the Guix
package definition for apache-commons-io would be
"java-apache-commons-io", but internally within Maven it would use some
other name?  I think this is less important than getting it working in
the first place, so I have no strong opinions on this.

>
>   * Where should the repo-files be kept in Guix? Debian seems to bot
>     them into a dir-structure which I assume is leaned on some
>     file-structure in the maven central repository. See
>     <https://wiki.debian.org/Java/MavenRepoSpec>
>     <https://wiki.debian.org/Java/MavenRepoHelper> and
>     <https://packages.debian.org/jessie/maven-repo-helper>
>

Am I correct in understanding that the "repo-filess" are the files that
Maven uses for doing stuff like fulfilling the dependencies defined in
the POM file?  If so, then I guess we would need to pick an arbitrary
subdirectory to use for this purpose, and that is where all Maven-built
outputs will go.  Would that work?

Is it possible to create a "manifest of files" (e.g., an environment
variable that points to many different locations in the store) that we
can provide to the "maven-build-system"?  If we could do that, maybe we
could trick Maven into treating that collection of files (residing in
the store) as its repository.  It would be nice if we did not have to
propagate all of the dependencies into a single directory just to enable
Maven to discover them.

>
>   * Where to keep the pom-files? Are there other files we need (I've
>     seen "effective pom", and "maven-fragments" in other distros)? Can
>     or should we strip these files, like Debian seems to to with the
>     maven-repo-helper? If so: What do we need? can this be done in guix,
>     is there a maven-plugin, or …?
>

I don't know.  Does Maven expect the POM files for each project to
reside in a specific location?

>
>   * Help finding official sources, homepages, etc. for all
>packages. For
>     many packages the data in the pom is outdated, since e.b.
>     codehaus.org and code.google.com are gone.

For this, I'm sure it might be tough, but we will probably just have to
figure it out on a case-by-case basis.

I'm excited about the prospect of doing Java development with Guix.
Thank you for helping to figure this complicated stuff out.  I hope I
can help a little, too.

-- 
Chris

signature.asc
Description: PGP signature