From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/20110122/002303.html | 93 +++++++++++++++++++++++++++++++++ 1 file changed, 93 insertions(+) create mode 100644 zarb-ml/mageia-dev/20110122/002303.html (limited to 'zarb-ml/mageia-dev/20110122/002303.html') diff --git a/zarb-ml/mageia-dev/20110122/002303.html b/zarb-ml/mageia-dev/20110122/002303.html new file mode 100644 index 000000000..d4285215c --- /dev/null +++ b/zarb-ml/mageia-dev/20110122/002303.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] Java-Policy first draft published + + + + + + + + + +

[Mageia-dev] Java-Policy first draft published

+ Michael scherer + misc at zarb.org +
+ Sat Jan 22 08:37:19 CET 2011 +

+
+ +
On Fri, Jan 21, 2011 at 08:22:26AM -0500, Frank Griffin wrote:
+> nicolas vigier wrote:
+> >
+> > Nothing should be downloaded from remote maven repositories during RPM
+> > builds. All dependencies should be installed from rpm packages only.
+> >
+> >
+> >   
+> So you propose that we package every version of every maven plugin and
+> dependency as RPMs and basically reinvent the entire Maven artifact
+> architecture ?
+
+Technically, that's mavven reinventing rpm architecture.
+ 
+> It's not a question of "use the most current or fix it".  POMs allow the
+> author to specify the version of the artifact, and it doesn't matter
+> whether it would work with a later version or not, because Maven will be
+> no more tolerant of a version mismatch than RPM would be.  It simply
+> won't build unless you rewrite the POM, in which case you can kiss
+> upstream support goodbye.
+
+Well, than, this is our support or the upstream one.
+
+If maven powered rpms are not supportable ( ie patchable by us, rebuildable by us, and
+inspectable by us, and anybody else ), then
+we should not ship it in core. If one solution is to take random binary packages
+without having built from the source code ourself and without being able to do
+so for whatever reason, non-free is for that.
+
+Sure, that's bad PR for java and maven. But we do some promises on what is in core, and
+I think using maven and taking various jar from the internet do not let us fullfill
+thees promises, this is a good enough reason to not ship them in core.
+ 
+-- 
+Michael Scherer
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1