diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20110112/002088.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20110112/002088.html | 150 |
1 files changed, 150 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20110112/002088.html b/zarb-ml/mageia-dev/20110112/002088.html new file mode 100644 index 000000000..171eb3829 --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002088.html @@ -0,0 +1,150 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Java-Policy first draft published + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Java-Policy%20first%20draft%20published&In-Reply-To=%3C4D2DD5A9.3040301%40roadrunner.com%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="002091.html"> + <LINK REL="Next" HREF="002090.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Java-Policy first draft published</H1> + <B>Frank Griffin</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Java-Policy%20first%20draft%20published&In-Reply-To=%3C4D2DD5A9.3040301%40roadrunner.com%3E" + TITLE="[Mageia-dev] Java-Policy first draft published">ftg at roadrunner.com + </A><BR> + <I>Wed Jan 12 17:24:09 CET 2011</I> + <P><UL> + <LI>Previous message: <A HREF="002091.html">[Mageia-dev] 12/01/2011 meeting +</A></li> + <LI>Next message: <A HREF="002090.html">[Mageia-dev] Java-Policy first draft published +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#2088">[ date ]</a> + <a href="thread.html#2088">[ thread ]</a> + <a href="subject.html#2088">[ subject ]</a> + <a href="author.html#2088">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Farfouille wrote: +><i> Hi +</I>><i> +</I>><i> I have published a first draft of Java application package policy. <A HREF="http://mageia.org/wiki/doku.php?id=java_applications_policy">http://mageia.org/wiki/doku.php?id=java_applications_policy</A> +</I>><i> +</I>><i> Corrections and comments are welcome. +</I>><i> +</I> +The bit about pre-packaged JARs may cause trouble. In theory, it's +great, but many applications depend upon certain versions of their +utility JARs, and can't all run with the latest versions. Any such app +would have a Requires for its specific version, which would prevent the +utility JAR from being updated with a newer version for other apps. +This is why EJB allows EJB apps to include their own specific versions +of utility JARs, which are visible to them but not to other apps or the +container itself, and also why Maven uses versioned artifacts. + +An extreme example of such an app is NetBeans, which includes its own +versions of Ant and Maven. + +Also, for such apps, upstream developers may refuse to investigate +issues unless the shipped versions of supplemental JARs are being used. + +><i> As I have never used maven, a deep reread is required +</I>><i> +</I>><i> +</I>><i> +</I> +Maven POMs allow the packager to specify required other objects +("artifacts") not only for building the package but for execution as +well. There are central Maven repositories which contain versioned +artifacts for commonly-used projects, e.g. JUnit, and many companies +have site-wide repositories of their own. Finally, every user of Maven +has a personal repository located in $HOME/.m2, which is why the policy +has code for creating this directory. + +Repositories are seached for needed artifacts from the most local (the +user's personal repository) to the most remote (the central Maven +repositories) as directed by a settings.xml file in the user's .m2 +directory or <repositories> tags in the individual pom.xml files. The +general intent is to obtain artifacts from the "closest" repository. +Company repositories are not just the central location for +company-specific artifacts, but also a local cache for central Maven +repository artifacts. + +><i>From the policy, it looks like the personal repository for the ID under +</I>which RPM builds the package is wiped clean for every package, and thus +every needed artifact will be downloaded from the remote repositories +for every build. If that's the case, it's an awful waste of bandwidth, +since many of these artifacts are used for every Maven project. + +We might want to consider having a central repository for each system, +which would be one level above the individual users' personal +repositories, and would be used before more remote repositories. There +is no harm to allowing artifacts to accumulate there, since all +artifacts are versioned. Cleanup might be possible through filetriggers +if a tool identified all dependent artifacts for each installed Maven +package, and deleted ones no longer used by anything installed. If +there were such a repository, say under /var, then it should be used for +builds rather than an individual repository tied to the RPM userid. + +There's also the issue of allowing company or site repositories to be +used if they exist. For packages installed during system installation, +there would be no way for a sysadmin to specify local repositories +unless the install were modified to allow it, but few if any Java +packages (much less Maven ones) are installed at that time. For later +package installs, perhaps a dynamic settings.xml could be created for +the build using XML fragments in something like an +/etc/maven/repositories.d with the same sort of numeric prefix +preference that chkconfig uses to establish precedence. + +Finally, there's the issue of using repository artifacts on the system +in the execution-time CLASSPATHs for the Maven applications. Maven has +a plugin which will build a single huge JAR containing an application's +classes as well as classes from every JAR artifact on which it depends, +and many docs recommend this as the way to distribute an application, +but it consumes quite a bit of space as every app is carrying its own +copy of every supplemental utility class it needs when it could probably +find the identical classes in the versioned artifacts in a system +repository. This ties in to the build-classpath and +build-jar-repository capabilities for non-Maven apps. + +By the way, the policy should probably contain full usage instructions +for build-classpath and build-jar-repository as well as a description of +the uses to which they are put. + +Good Work ! + + + +</PRE> + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="002091.html">[Mageia-dev] 12/01/2011 meeting +</A></li> + <LI>Next message: <A HREF="002090.html">[Mageia-dev] Java-Policy first draft published +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#2088">[ date ]</a> + <a href="thread.html#2088">[ thread ]</a> + <a href="subject.html#2088">[ subject ]</a> + <a href="author.html#2088">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |