[Dev] [Packages (i686 and x86_64) - Bug #334] [maven] Uses network during build() to download makedepends

labs at parabola.nu labs at parabola.nu
Fri May 17 01:31:32 GMT 2013



Issue #334 has been updated by lukeshu.

Description changed from This is an updated-version of <https://labs.parabola.nu/issues/38>; the process/details have changed.

I'll try to explain this as best I can so that someone without any prior knowledge can understand.

h1. About maven as a package manager

Apache maven, in addition to being a build-system is also a primitive package manager.  Packaging software that uses maven for it's build-system can be a real pain, because it will try to download pre-compiled dependencies during the build; which is against our packaging policies.

About the maven package manager:
 * A package is called an "artifact"
 * An artifact has a `groupId`, a name, and a version.
 * An artifact consists of a `.pom` XML file and (usually) a compiled `.jar` Java file.
 * Artifacts are installed to `/usr/share/maven/repository/$groupId/$artifact/$version/$artifact-$ver.{pom,jar}` (by default, the location can be configured)

Most of the packages in [java] install themselves as an artifact, and symlink the jar file into `/usr/share/java`.

h1. About maven's build process/PKGBUILD

Maven itself uses a bootstrap version of maven to build itself, and in the process downloads some 560 artifacts. I am confident that these are all free software, so the issue isn't "urgent", but it does violate our policies.

I have set up the maven PKGBUILD to record what artifacts it downloads to `$srcdir/downloaded-artifacts.txt` (I have attached a copy of this for convenience); what we need to do is package all of them and add them to `makedepends=()`; I have already done this with `java-antlr2` (2.7.7).

h1. About version proliferation.

Most of the artifacts downloaded are not directly dependencies of maven, but dependencies of dependencies.  This sucks because Java+maven developers tend to over-specify the version that they are dependent on, so all the named versions will be downloaded. For example, it downloads 1.0, 1.0.3, 1.0.4, 1.1, and 1.1.1 of java-commons-logging, each needed by a different artifact.

We should fix this, which requires more in-depth knowledge of the system.

Of course, sometimes multiple major versions are OK, we have java-asm2 and java-asm3. But what's not OK is that asm 3.3.1 is packaged, but it downloads asm 3.1. Also not OK is that antlr 2.7.7 is packaged, but it wants both 2.7.2 and 2.7.7.

h1. Why we include maven, even though it violates our policies.

Right now, most java packages from Arch violate our policies. We are working to fix this. We explicitly allow maven, because it is important in building other packages. to This is an updated-version of <https://labs.parabola.nu/issues/38>; the process/details have changed.

I'll try to explain this as best I can so that someone without any prior knowledge can understand.

h1. About maven as a package manager

Apache maven, in addition to being a build-system is also a primitive package manager.  Packaging software that uses maven for it's build-system can be a real pain, because it will try to download pre-compiled dependencies during the build; which is against our packaging policies.

About the maven package manager:

* A package is called an "artifact"
* An artifact has a `groupId`, a name, and a version.
* An artifact consists of a `.pom` XML file and (usually) a compiled `.jar` Java file.
* Artifacts are installed to `/usr/share/maven/repository/$groupId/$artifact/$version/$artifact-$ver.{pom,jar}` (by default, the location can be configured)

Most of the packages in [java] install themselves as an artifact, and symlink the jar file into `/usr/share/java`.

h1. About maven's build process/PKGBUILD

Maven itself uses a bootstrap version of maven to build itself, and in the process downloads some 560 artifacts. I am confident that these are all free software, so the issue isn't "urgent", but it does violate our policies.

I have set up the maven PKGBUILD to record what artifacts it downloads to `$srcdir/downloaded-artifacts.txt` (I have attached a copy of this for convenience); what we need to do is package all of them and add them to `makedepends=()`; I have already done this with `java-antlr2` (2.7.7).

h1. About version proliferation.

Most of the artifacts downloaded are not directly dependencies of maven, but dependencies of dependencies.  This sucks because Java+maven developers tend to over-specify the version that they are dependent on, so all the named versions will be downloaded. For example, it downloads 1.0, 1.0.3, 1.0.4, 1.1, and 1.1.1 of java-commons-logging, each needed by a different artifact.

We should fix this, which requires more in-depth knowledge of the system.

Of course, sometimes multiple major versions are OK, we have java-asm2 and java-asm3. But what's not OK is that asm 3.3.1 is packaged, but it downloads asm 3.1. Also not OK is that antlr 2.7.7 is packaged, but it wants both 2.7.2 and 2.7.7.

h1. Why we include maven, even though it violates our policies.

Right now, most java packages from Arch violate our policies. We are working to fix this. We explicitly allow maven, because it is important in building other packages.


----------------------------------------
Bug #334: [maven] Uses network during build() to download makedepends
https://labs.parabola.nu/issues/334

Author: lukeshu
Status: open
Priority: freedom issue
Assignee: 
Category: 
Target version: 


This is an updated-version of <https://labs.parabola.nu/issues/38>; the process/details have changed.

I'll try to explain this as best I can so that someone without any prior knowledge can understand.

h1. About maven as a package manager

Apache maven, in addition to being a build-system is also a primitive package manager.  Packaging software that uses maven for it's build-system can be a real pain, because it will try to download pre-compiled dependencies during the build; which is against our packaging policies.

About the maven package manager:

* A package is called an "artifact"
* An artifact has a `groupId`, a name, and a version.
* An artifact consists of a `.pom` XML file and (usually) a compiled `.jar` Java file.
* Artifacts are installed to `/usr/share/maven/repository/$groupId/$artifact/$version/$artifact-$ver.{pom,jar}` (by default, the location can be configured)

Most of the packages in [java] install themselves as an artifact, and symlink the jar file into `/usr/share/java`.

h1. About maven's build process/PKGBUILD

Maven itself uses a bootstrap version of maven to build itself, and in the process downloads some 560 artifacts. I am confident that these are all free software, so the issue isn't "urgent", but it does violate our policies.

I have set up the maven PKGBUILD to record what artifacts it downloads to `$srcdir/downloaded-artifacts.txt` (I have attached a copy of this for convenience); what we need to do is package all of them and add them to `makedepends=()`; I have already done this with `java-antlr2` (2.7.7).

h1. About version proliferation.

Most of the artifacts downloaded are not directly dependencies of maven, but dependencies of dependencies.  This sucks because Java+maven developers tend to over-specify the version that they are dependent on, so all the named versions will be downloaded. For example, it downloads 1.0, 1.0.3, 1.0.4, 1.1, and 1.1.1 of java-commons-logging, each needed by a different artifact.

We should fix this, which requires more in-depth knowledge of the system.

Of course, sometimes multiple major versions are OK, we have java-asm2 and java-asm3. But what's not OK is that asm 3.3.1 is packaged, but it downloads asm 3.1. Also not OK is that antlr 2.7.7 is packaged, but it wants both 2.7.2 and 2.7.7.

h1. Why we include maven, even though it violates our policies.

Right now, most java packages from Arch violate our policies. We are working to fix this. We explicitly allow maven, because it is important in building other packages.



--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://labs.parabola.nu/my/account



More information about the Dev mailing list