Re: [Mageia-dev] Java-Policy first draft published
Le jeudi 27 janvier 2011 à 02:40 +0100, piep a écrit : Refection about Java_Packaging_Policy : what about a jpackage project for mageia java based rpm ? like others I am still a padawan packager, but I also plan to work on java (and music) packages I follow this thread with interest for few days and I wonder why nobody thinks to just import java packages from jpackage repositories ? Because we already use their rpms. And that's a complex mess of dependencies, with unneeded complexity. For example, if you look at svn://svn.mageia.org/packages/cauldron/jakarta-commons-lang/current/SPECS/jakarta-commons-lang.spec , you can see 1) the copyright of jpackage ( hence my point, but check any java package ) 2) it support gcj and non gcj ( ie twice the work if we want to test ) 3) a weird release ( 2.3.4 ) 4) various %post that should have been converted to trigger ( but since it is not uniform on all distro, they prefered to cut and paste ). Another issue is they package several version of the same software ( like 5 releases of groovy, 3 versions of junit , etc ). This is something requires more ressources. 1) For many years jpackage.org project provides strong rpm packages of java based applications. These packages are used on the professional platform : Red Hat Enterprise Linux. Last time I remember, people from Jpackage were not happy because RHEL people took their rpms and integrated them in Fedora. So I think people on RHEL use RH rpm, not the one from jpackage. Despite the arguments why Mandriva developers left the jpackage project to build their own java packages. http://wiki.mandriva.com/en/Java_Packaging_Policy#Compatibility_with_proprietary_Java_stacks Well, what is not written there is the java stack of Mandriva was done mainly by David Walluck, who is .. a jpackage member. And jpackage was also partially founded by Guillaume Rousse, who also left the project because they were aiming for too complex and unmaintainable goals. After David was hired by RH, Alexander Kurtakov stepped to maintain, to be also hired by RH. The only Ansii fixed some stuff, mainly because he needed to do. We are at the beginning of a new rpm based distribution. It would be stupid and suicidal to work on our own java packages and reinvent the wheel again and again. No, what would be suicidal is to keep the current java packages, done by jpackage whose goal do not correspond to ours. We are using the jpackage rpms, check the specs. So if we do have problem in rebuilding the rpms, using more jpackage rpm do not seems like a solution, except if the problem is We have too much free time. If we want Mageia becomes a major distribution on java application servers also, we have to consider jpackage as source of java packages. Then we can concentrate our java packagers to improve the time to market of jpackage applications and on desktop application (tuxguitar, sweethome3d, JOSM, homeplayer etc..) and all java application that lack in jpackage and why not try to provide them to jpackage. Personally, I do not want Mageia to become a major distribution on java application servers, I want it to be sustainable. And sustainability as clearly demonstrated by previous attempts is quite difficult to achieve by using jpackage rpm. So let's start simple, we will have the time to grow later. Java was a weak point on Mandriva, and I think that seeing the problem twice is enough to not want to see it a 3rd time. Their goals differ totally from ours. First, they still aim to be usable on more than one platform, which usually mean be unintegrated on every platform. In practice, they seems to rather be usable only on RHEL, but well. There would be various technical issues, like keep specs in synchronisation, etc, various organizational issues like not being able to decide our policy without asking to people outside of our organisation, or having to handle out of our svn packages, etc. So let's already take care of what we have. Once packager have demonstrated that the 400 packages will not bitrot alone in the svn, then we can start to think importing more IMHO. Pushing more rpm when the foundation is not maintained is simply a bad idea, like constructing a house on the sand. 6) So why don't we consider jpackage with the new eye of a new distro and consider it as an external java application repository like we already use plf ? Why don't we work closer with the jpackage team to improve the urpmi connection ? PLF was mainly done by mandrake linux people aiming to integrate with mandrake linux, and quickly shared src.rpm, followed mandriva policies, contributed to Mandriva, etc. Jpackage was made based on the (IMHO flawed) assumption that the only issue that prevented packages sharing was binary compatibility, and that it was solved by jvm. Both affirmation are quite wrong, as there is lots of others problem to solve ( like rpm version, various choices made by distribution
Re: [Mageia-dev] Java-Policy first draft published
On Fri, Jan 21, 2011 at 04:47:28PM +0100, Thierry Vignaud wrote: On 21 January 2011 16:14, Michael scherer m...@zarb.org wrote: And they never though about security... Security is not a problem , it is java, no null pointer exception /o\. But that's not only security, there is simply bugs that happen, and API problem ( that IMHO happens more often than security issue ). I've too often see java apps becoming very unstable once they got a null pointer exception until one restarts tomcat/jboss/whatever... More seriously when I was speaking about though about security, I meant people should got shot (twice) if they are OK with downloading a binary from some random site w/o any checks... See what this can lead to… http://www.theregister.co.uk/2011/01/19/mac_linux_bot_vulnerabilities/ Regards, -- Rémy CLOUARD () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
Re: [Mageia-dev] Java-Policy first draft published
On 21 January 2011 00:01, nicolas vigier bo...@mars-attacks.org wrote: Shipping binary jar given by upstream tarball cause trouble because you 1) cannot patch them in case of bug 2) cannot see how and what was compiled That's not very free software friendly, and I think we should refuse that. I've already seen while trying to package java apps, a jar being shipped, but sources not available anywhere on the internet, except after searching for a few hours on an old website on archive.org with broken link to the sources zip, and developers not aware of the issue, because they never tried to find the sources, and always used this binary .jar they found on a random web site. And they never though about security...
Re: [Mageia-dev] Java-Policy first draft published
On Fri, Jan 21, 2011 at 10:06:21AM +0100, Thierry Vignaud wrote: On 21 January 2011 00:01, nicolas vigier bo...@mars-attacks.org wrote: Shipping binary jar given by upstream tarball cause trouble because you 1) cannot patch them in case of bug 2) cannot see how and what was compiled That's not very free software friendly, and I think we should refuse that. I've already seen while trying to package java apps, a jar being shipped, but sources not available anywhere on the internet, except after searching for a few hours on an old website on archive.org with broken link to the sources zip, and developers not aware of the issue, because they never tried to find the sources, and always used this binary .jar they found on a random web site. And they never though about security... Security is not a problem , it is java, no null pointer exception /o\. But that's not only security, there is simply bugs that happen, and API problem ( that IMHO happens more often than security issue ). -- Michael Scherer
Re: [Mageia-dev] Java-Policy first draft published
On 21 January 2011 16:14, Michael scherer m...@zarb.org wrote: And they never though about security... Security is not a problem , it is java, no null pointer exception /o\. But that's not only security, there is simply bugs that happen, and API problem ( that IMHO happens more often than security issue ). I've too often see java apps becoming very unstable once they got a null pointer exception until one restarts tomcat/jboss/whatever... More seriously when I was speaking about though about security, I meant people should got shot (twice) if they are OK with downloading a binary from some random site w/o any checks...
Re: [Mageia-dev] Java-Policy first draft published
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
Re: [Mageia-dev] Java-Policy first draft published
Le 11/01/2011 08:07, Farfouille a écrit : Le 10/01/2011 23:45, Renaud MICHEL a écrit : On lundi 10 janvier 2011 at 21:02, Farfouille wrote : I suppose this page is meant to replace http://mageia.org/wiki/doku.php?id=java_policy Yes I've updated the policy table http://www.mageia.org/wiki/doku.php?id=policies-review with the policy discussed in this thread to avoid confusion.
Re: [Mageia-dev] Java-Policy first draft published
Le 11/01/2011 12:27, Michael Scherer a écrit : Le mardi 11 janvier 2011 à 08:17 +0100, Farfouille a écrit : Le 11/01/2011 00:00, Michael Scherer a écrit : Le lundi 10 janvier 2011 à 21:02 +0100, Farfouille a écrit : The part about Requires should IMHO be pushed in rpm dependency solver . Apologize for maybe a noob question (btw I'm a noob packager waiting for his turn to be trained ;) ) but what do you mean by 'rpm dependency solver' ? Is is a tool to resolve dependencies at user installation time ? A simple link to some kind of explaination will be a perfect answer. It is a script that add requires on build. For example, each time there is a python script, rpm notice it and add the requires on python. See /usr/lib/rpm/find-requires and /usr/lib/rpm/mandriva/find-requires I didn't find anything that deals with java dependencies in these directories. So I think the policy should be kept unchanged for this point. I am not sure for the requires on jpackages-utils, could we explain what it bring ? I'll dig on that during my launch break AFAIU jpackes-utils brings a directory structures and tools to manage JREs. It is required by packaged applications that, at least run on top of JRE (openjdk and sun-java) but as it is also a dependency of, at least, openjdk rpm (didn't check for sun-java nor gcj) it may be removed for java application policy. Can someone confirm this ?
Re: [Mageia-dev] Java-Policy first draft published
On Thu, Jan 20, 2011 at 08:37:23PM +0100, Farfouille wrote: Le 11/01/2011 12:27, Michael Scherer a écrit : Le mardi 11 janvier 2011 à 08:17 +0100, Farfouille a écrit : Le 11/01/2011 00:00, Michael Scherer a écrit : Le lundi 10 janvier 2011 à 21:02 +0100, Farfouille a écrit : The part about Requires should IMHO be pushed in rpm dependency solver . Apologize for maybe a noob question (btw I'm a noob packager waiting for his turn to be trained ;) ) but what do you mean by 'rpm dependency solver' ? Is is a tool to resolve dependencies at user installation time ? A simple link to some kind of explaination will be a perfect answer. It is a script that add requires on build. For example, each time there is a python script, rpm notice it and add the requires on python. See /usr/lib/rpm/find-requires and /usr/lib/rpm/mandriva/find-requires I didn't find anything that deals with java dependencies in these directories. So I think the policy should be kept unchanged for this point. Well, my point is that it should added to this script, rather that being done manually by policy. So yes, while there is nothing, we keep it, but it should be trivial to add and then adapt the policy. I am not sure for the requires on jpackages-utils, could we explain what it bring ? I'll dig on that during my launch break AFAIU jpackes-utils brings a directory structures and tools to manage JREs. It is required by packaged applications that, at least run on top of JRE (openjdk and sun-java) but as it is also a dependency of, at least, openjdk rpm (didn't check for sun-java nor gcj) it may be removed for java application policy. Can someone confirm this ? Well, as I am advocating to have 1 and only 1 supported jvm to start ( because having more just add complexity and insanity, and there is already enough work to do ), maybe the directory structure should be pushed into the jvm. ( now, i guess that the move to have 1 single jvm will be seen as extremely controversial , I know ). -- Michael Scherer
Re: [Mageia-dev] Java-Policy first draft published
On Wed, 12 Jan 2011, Michael Scherer wrote: Le mercredi 12 janvier 2011 à 11:24 -0500, Frank Griffin a écrit : Farfouille wrote: Hi I have published a first draft of Java application package policy. http://mageia.org/wiki/doku.php?id=java_applications_policy Corrections and comments are welcome. 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. That's the same issue for everything. Shipping binary jar given by upstream tarball cause trouble because you 1) cannot patch them in case of bug 2) cannot see how and what was compiled That's not very free software friendly, and I think we should refuse that. I've already seen while trying to package java apps, a jar being shipped, but sources not available anywhere on the internet, except after searching for a few hours on an old website on archive.org with broken link to the sources zip, and developers not aware of the issue, because they never tried to find the sources, and always used this binary .jar they found on a random web site.
Re: [Mageia-dev] Java-Policy first draft published
On Wed, 12 Jan 2011, Frank Griffin wrote: Farfouille wrote: Hi I have published a first draft of Java application package policy. http://mageia.org/wiki/doku.php?id=java_applications_policy Corrections and comments are welcome. 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 Then those applications should be fixed. That's the same with C libraries or other languages. When a program is not working with a newer version of its libraries, it is fixed, instead of keeping both the new and old libraries installed. Unless we want to keep 10 versions of each library, each with their owns bugs and security issues. Only when it is really necessary, multiple versions should be kept. 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. From the policy, it looks like the personal repository for the ID under 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. Nothing should be downloaded from remote maven repositories during RPM builds. All dependencies should be installed from rpm packages only.
Re: [Mageia-dev] Java-Policy first draft published
Le 10/01/2011 21:56, Romain d'Alverny a écrit : On Mon, Jan 10, 2011 at 21:02, Farfouille farfouill...@laposte.net wrote: Licence discrepency : dokuwiki template says licence is 'CC Attribution-Share Alike 3.0 Unported' but web application policy (http://mageia.org/wiki/doku.php?id=web_applications_policy) claims 'Creative Commons Attribution-ShareAlike 2.5 License' (end of the page) I used the quick admin feature of dokuwiki to set it, only the 3.0 Unported was used. I have still to learn/get the differences between these versions (notwithstanding that the By-SA provisions mean the same thing), or whether they are even conflicting (there may be a natural update path in here). Anyway, help/insights (separate thread, please) about this is welcome. Romain Hi, I browsed through 'CC Attribution-Share Alike 3.0 Unported' on http://creativecommons.org/licenses/by-sa/3.0/legalcode and from the hereafter section, I understand that both licences are compatible You may Distribute or Publicly Perform an Adaptation only under the terms of: (i) this License; (ii) a later version of this License with the same License Elements as this License; (iii) a Creative Commons jurisdiction license (either this or a later license version) that contains the same License Elements as this License (e.g., Attribution-ShareAlike 3.0 US)); (iv) a Creative Commons Compatible License. If you license the Adaptation under one of the licenses mentioned in (iv), you must comply with the terms of that license. If you license the Adaptation under the terms of any of the licenses mentioned in (i), (ii) or (iii) (the Applicable License), you must comply with the terms of the Applicable License generally and the following provisions: (I) You must include a copy of, or the URI for, the Applicable License with every copy of each Adaptation You Distribute or Publicly Perform; (II) You may not offer or impose any terms on the Adaptation that restrict the terms of th e Applicable License or the ability of the recipient of the Adaptation to exercise the rights granted to that recipient under the terms of the Applicable License; (III) You must keep intact all notices that refer to the Applicable License and to the disclaimer of warranties with every copy of the Work as included in the Adaptation You Distribute or Publicly Perform; (IV) when You Distribute or Publicly Perform the Adaptation, You may not impose any effective technological measures on the Adaptation that restrict the ability of a recipient of the Adaptation from You to exercise the rights granted to that recipient under the terms of the Applicable License. This Section 4(b) applies to the Adaptation as incorporated in a Collection, but this does not require the Collection apart from the Adaptation itself to be made subject to the terms of the Applicable License. Cheers -- Farfouille
Re: [Mageia-dev] Java-Policy first draft published
On Thu, Jan 13, 2011 at 2:01 AM, Frank Griffin f...@roadrunner.com wrote: No they won't. They won't know anything about the distinction between installing via RPM or via tarball. They'll look in rpmdrake for Eclipse initially, install it from there, and then use the normal Eclipse mechanism to install plugins. They'll do this because we tell them to use rpmdrake to look for software, and they'll do the plugins the way they're used to or the way the Eclipse docs tell them to. I don't agree with you at that point. I always take the tarball from eclipse.org (for eclipse) or netbeans.org (for netbeans) instead of the one's of repository provided by the distro. The reason is quite simple, the one's mentioned above are newer than the one's in the repos (often, not always but everywhere i looked for it, it was so) But there may be people who will first look in rpmdrake or urpmi that's right, but not everybody. -- Mit freundlichen Grüßen Greetings Daniel Kreuter
Re: [Mageia-dev] Java-Policy first draft published
Daniel Kreuter wrote: I don't agree with you at that point. I always take the tarball from eclipse.org http://eclipse.org (for eclipse) or netbeans.org http://netbeans.org (for netbeans) instead of the one's of repository provided by the distro. The reason is quite simple, the one's mentioned above are newer than the one's in the repos (often, not always but everywhere i looked for it, it was so) But there may be people who will first look in rpmdrake or urpmi that's right, but not everybody. Well, I didn't say *everybody*, I was referring to newer users who might actually do what we tell them to :-) The problem is that there is a very high probability that anyone who installs from an RPM will then install plugins directly. Given that, I would question even packaging the base product as an RPM. Then again, there's the concern about whether an RPM-provided package may provide something a tarball does not, or vice-versa. For example, the MDV Java RPMs play all sorts of games with /etc/alternatives and don't (I think) set environment variables like JAVA_HOME. This means that tarball installs of things like Ant need manual tweaking to work correctly with an RPM-based JDK. The RPM-based Ant has wrapper scripts which depend on the /etc/alternatives stuff and determine JAVA_HOME on the fly.
Re: [Mageia-dev] Java-Policy first draft published
On Thu, Jan 13, 2011 at 12:49 PM, Frank Griffin f...@roadrunner.com wrote: Daniel Kreuter wrote: I don't agree with you at that point. I always take the tarball from eclipse.org (for eclipse) or netbeans.org (for netbeans) instead of the one's of repository provided by the distro. The reason is quite simple, the one's mentioned above are newer than the one's in the repos (often, not always but everywhere i looked for it, it was so) But there may be people who will first look in rpmdrake or urpmi that's right, but not everybody. Well, I didn't say *everybody*, I was referring to newer users who might actually do what we tell them to :-) The problem is that there is a very high probability that anyone who installs from an RPM will then install plugins directly. Given that, I would question even packaging the base product as an RPM. I agree with you. I think it's better to build just the basic ide with it's plugins and let the user install the rest via the Eclipse Marketplace (like Subclipse e.g.). But we should consider that some of the plugins will have dependencies which won't be installed via the Marketplace like javaHL which is needed by Subclipse. -- Mit freundlichen Grüßen Greetings Daniel Kreuter
Re: [Mageia-dev] Java-Policy first draft published
Le mercredi 12 janvier 2011 à 11:24 -0500, Frank Griffin a écrit : Farfouille wrote: Hi I have published a first draft of Java application package policy. http://mageia.org/wiki/doku.php?id=java_applications_policy Corrections and comments are welcome. 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. That's the same issue for everything. Shipping binary jar given by upstream tarball cause trouble because you 1) cannot patch them in case of bug 2) cannot see how and what was compiled That's not very free software friendly, and I think we should refuse that. -- Michael Scherer
Re: [Mageia-dev] Java-Policy first draft published
Le 12/01/2011 17:45, Frank Griffin a écrit : Michael Scherer wrote: Le mercredi 12 janvier 2011 à 11:24 -0500, Frank Griffin a écrit : The bit about pre-packaged JARs may cause trouble. That's the same issue for everything. Shipping binary jar given by upstream tarball cause trouble because you 1) cannot patch them in case of bug 2) cannot see how and what was compiled That's not very free software friendly, and I think we should refuse that. Granted, but unless every free software project migrates to Maven, you'd be refusing a lot of popular apps. In theory, the packager of such an application could create supplementary packages for the specific versions of included JARs and build them first from source. But for something like NetBeans or Eclipse, that's going to be a lot of work I propose to keep the restriction, but to allow some exception, mainly blockbuster like Eclipse and Netbeans in order to build an appealing distro. Do you know other softwares that are worth to be exception ? -- Farfouille
Re: [Mageia-dev] Java-Policy first draft published
Farfouille wrote: I propose to keep the restriction, but to allow some exception, mainly blockbuster like Eclipse and Netbeans in order to build an appealing distro. Do you know other softwares that are worth to be exception ? The only one that comes to mind is JBoss, but I'm sure there will be others. Any servlet or EJB container is going to be prone to this.
Re: [Mageia-dev] Java-Policy first draft published
Renaud MICHEL wrote: Or maybe, if the jar in the external dependency plugin is actually the same (or compatible) version as the on from the normal package maybe we could make a plugin package only containing the eclipse related files (plugin.properties) and creating a symlink to the system wide jar. But that mean that eclipse plugins, which are now frequently provided as single jar files, would need to be packaged as files and directories like in older eclipse releases. What do you think? I think we want to consider carefully before we try to replace complex existing plugin installation procedures in various products. This issue is also being discussed relative to Firefox in another thread. Users of things like NetBeans and Eclipse are used to the mechanisms provided by those tools for managing plugin installation, and are not going to take kindly to having to use rpmdrake instead. And in some cases, e.g. Maven, you don't have a choice - if Maven needs it and it isn't there, it will get it from repositories whether or not you have packaged a plugin as an RPM. At some point, you just give up and accept the fact that you can't reform the entire world. As more and more projects migrate to Maven, the problem (sort of) goes away. All of our suggestions here are basically trying to recreate what Maven does without requiring projects to use it.
Re: [Mageia-dev] Java-Policy first draft published
Renaud MICHEL wrote: On mercredi 12 janvier 2011 at 23:54, Frank Griffin wrote : Users of things like NetBeans and Eclipse are used to the mechanisms provided by those tools for managing plugin installation, and are not going to take kindly to having to use rpmdrake instead. Well, I use eclipse everyday (arrive at work, start eclipse and close it at the end of day before leaving) but I don't like its trying to duplicate what package managers do better. I want to know what' installed on may computer, how and where. I think you're the exception. For years I used to grab the pre-build archives and manage their dependencies by hand. A few month ago, I decided to repackage those as rpms with proper dependencies between packages to have urpmi do the work for me. It was a little complicated to find in the features and packages where their dependencies were stored, to extract them automatically at package build. So I was able to split it in many sub-packages to be able to install only what I need. The only downside is that it is built from binary archives and not from source, but for my own use it does work well. I think you're exceptionally industrious. Back to your remark, people who don't like to have eclipse installed via rpm simply won't. They will continue to download the tarball from eclipse.org and install the plugins they want, either from archives or update sites. They can also install only the platform from the rpm and, if the - configuration and -data options are properly added to eclipse startup, they will be able to install in their home dir the plugins they want using the update sites. No they won't. They won't know anything about the distinction between installing via RPM or via tarball. They'll look in rpmdrake for Eclipse initially, install it from there, and then use the normal Eclipse mechanism to install plugins. They'll do this because we tell them to use rpmdrake to look for software, and they'll do the plugins the way they're used to or the way the Eclipse docs tell them to. I won't comment on maven as I don't know how it works (the last time I tried to build from source a program using maven I did not find what options I was supposed to give to the mvn command to have it built). Maven, like Eclipse and NetBeans, has its own infrastructure for obtaining artifacts (sort of like plugins). The difference is that it isn't an active thing like Eclipse plugins. Eclipse won't decide you need something and automatically install it; Maven will. If Maven needs an artifact and it isn't already in your repository (because you installed some RPM that put it there), it will fetch it via HTTP automatically regardless of whether you have an RPM for it or not. The result of all this is that you're wasting your time trying to package plugins and such as RPMs for these products. People aren't going to use rpmdrake for this because they are used to doing it a different way, and you'll end up with an unmaintainable mix of stuff installed via RPM and stuff installed via whatever.
Re: [Mageia-dev] Java-Policy first draft published
Le mardi 11 janvier 2011 à 08:17 +0100, Farfouille a écrit : Le 11/01/2011 00:00, Michael Scherer a écrit : Le lundi 10 janvier 2011 à 21:02 +0100, Farfouille a écrit : The part about Requires should IMHO be pushed in rpm dependency solver . Apologize for maybe a noob question (btw I'm a noob packager waiting for his turn to be trained ;) ) but what do you mean by 'rpm dependency solver' ? Is is a tool to resolve dependencies at user installation time ? A simple link to some kind of explaination will be a perfect answer. It is a script that add requires on build. For example, each time there is a python script, rpm notice it and add the requires on python. See /usr/lib/rpm/find-requires and /usr/lib/rpm/mandriva/find-requires I am not sure for the requires on jpackages-utils, could we explain what it bring ? I'll dig on that during my launch break The same goes for maven and Requires(post), postun. This should be detected by rpm., and we should use filetrigger. Same noob question for filetrigger http://wiki.mandriva.com/en/Development/Tasks/Packaging/Tools/RPM/Filetriggers Basically, if you need to run the same set of script when you add a file somewhere ( like, a menu using xdg ), then a file trigger enable to do it for you once and for all. The goal of both tools is to minimize manual addition to the specs. If we do always the same task, then the computer can do it for us, this allow us to concentrate on others tasks, ensure that no deviation occurs, and so increase reliability and quality. -- Michael Scherer
Re: [Mageia-dev] Java-Policy first draft published
On 10.01.2011 22:02, Farfouille wrote: Hi I have published a first draft of Java application package policy. http://mageia.org/wiki/doku.php?id=java_applications_policy Corrections and comments are welcome. BuildRequires: java-devel [= specific_version] BuildRequires: jpackage-utils These are satisfied by *any* java compiler, however we want packages to be always built by a specific compiler. On Mandriva we solved this by replacing BuildRequires: java-devel with BuildRequires: java-rpmbuild which is used to pull the main java compiler (openjdk on all archs where it is supported, gcj/ecj on others). BuildRequires: ant ... %build ... ant Replace ant with %ant. This ensures ant is called with the specific java compiler as mentioned above. Also, the policy should mention %jar, %java, %javac, %javadoc, %java_home that should be used when those tools/paths are needed. Questions/Points : Section Specfile Template for ant and maven, I am not sure that the definition of Release is correct. Shouldn't it be useful to have a general policy about package name and versioning (like Fedora : http://fedoraproject.org/wiki/Packaging/NamingGuidelines) ? Yes. MDV wiki has something on those, but not much indeed: http://wiki.mandriva.com/en/Development/Howto/RPM_Advanced#Naming_a_package http://wiki.mandriva.com/en/Development/Howto/RPM_Advanced#Releasing_pre-versions As I have never used maven, a deep reread is required Licence discrepency : dokuwiki template says licence is 'CC Attribution-Share Alike 3.0 Unported' but web application policy (http://mageia.org/wiki/doku.php?id=web_applications_policy) claims 'Creative Commons Attribution-ShareAlike 2.5 License' (end of the page) Cheers -- Farfouille -- Anssi Hannula
Re: [Mageia-dev] Java-Policy first draft published
Hi I have published a first draft of Java application package policy. http://mageia.org/wiki/doku.php?id=java_applications_policy Corrections and comments are welcome. Questions/Points : Section Specfile Template for ant and maven, I am not sure that the definition of Release is correct. Shouldn't it be useful to have a general policy about package name and versioning (like Fedora : http://fedoraproject.org/wiki/Packaging/NamingGuidelines) ? As I have never used maven, a deep reread is required Licence discrepency : dokuwiki template says licence is 'CC Attribution-Share Alike 3.0 Unported' but web application policy (http://mageia.org/wiki/doku.php?id=web_applications_policy) claims 'Creative Commons Attribution-ShareAlike 2.5 License' (end of the page) Cheers -- Farfouille
Re: [Mageia-dev] Java-Policy first draft published
On Mon, Jan 10, 2011 at 21:02, Farfouille farfouill...@laposte.net wrote: Licence discrepency : dokuwiki template says licence is 'CC Attribution-Share Alike 3.0 Unported' but web application policy (http://mageia.org/wiki/doku.php?id=web_applications_policy) claims 'Creative Commons Attribution-ShareAlike 2.5 License' (end of the page) I used the quick admin feature of dokuwiki to set it, only the 3.0 Unported was used. I have still to learn/get the differences between these versions (notwithstanding that the By-SA provisions mean the same thing), or whether they are even conflicting (there may be a natural update path in here). Anyway, help/insights (separate thread, please) about this is welcome. Romain
Re: [Mageia-dev] Java-Policy first draft published
Le lundi 10 janvier 2011 à 21:56 +0100, Romain d'Alverny a écrit : On Mon, Jan 10, 2011 at 21:02, Farfouille farfouill...@laposte.net wrote: Licence discrepency : dokuwiki template says licence is 'CC Attribution-Share Alike 3.0 Unported' but web application policy (http://mageia.org/wiki/doku.php?id=web_applications_policy) claims 'Creative Commons Attribution-ShareAlike 2.5 License' (end of the page) I used the quick admin feature of dokuwiki to set it, only the 3.0 Unported was used. I have still to learn/get the differences between these versions (notwithstanding that the By-SA provisions mean the same thing), or whether they are even conflicting (there may be a natural update path in here). Anyway, help/insights (separate thread, please) about this is welcome. I think 3.0 is not ported in french law ( but there is ongoing efforts : http://fr.creativecommons.org/blog.htm ). -- Michael Scherer
Re: [Mageia-dev] Java-Policy first draft published
On lundi 10 janvier 2011 at 21:02, Farfouille wrote :
I have published a first draft of Java application package policy.
http://mageia.org/wiki/doku.php?id=java_applications_policy
Thank you for your work.
I suppose this page is meant to replace
http://mageia.org/wiki/doku.php?id=java_policy
Corrections and comments are welcome.
About the GCJ section, how about replacing it with:
Building GCJ AOT bits is discouraged. If you have a good reason to build
them they must be placed in a sub-package named %{name}-gcj to avoid a
require on java-1.5.0-gcj on the main package, because this will force every
single user to install it even if one wants to use another JVM.
In the section Pre-built JAR files it says This is unacceptable in
Fedora, shouldn't it be changed to mageia? Or perhaps rephrased
differently?
Also about section Pre-built JAR files, maven has his own repository to
resolve dependencies, but ant based build scripts are generally bundled with
their required jars. So to be built against the system installed jars, the
spec file should either:
- add some parameters to ant (if the build.xml supports it) constructed with
build-classpath
- patch the build.xml to use the jars in the standard location
- create symlinks where the build.xml expect them (using build-jar-
repository?)
Cheers
--
Renaud Michel
Re: [Mageia-dev] Java-Policy first draft published
Le 10/01/2011 23:45, Renaud MICHEL a écrit :
On lundi 10 janvier 2011 at 21:02, Farfouille wrote :
I suppose this page is meant to replace
http://mageia.org/wiki/doku.php?id=java_policy
Yes
About the GCJ section, how about replacing it with:
Building GCJ AOT bits is discouraged. If you have a good reason to build
them they must be placed in a sub-package named %{name}-gcj to avoid a
require on java-1.5.0-gcj on the main package, because this will force every
single user to install it even if one wants to use another JVM.
In the section Pre-built JAR files it says This is unacceptable in
Fedora, shouldn't it be changed to mageia? Or perhaps rephrased
differently?
Oops my bad !
Also about section Pre-built JAR files, maven has his own repository to
resolve dependencies, but ant based build scripts are generally bundled with
their required jars. So to be built against the system installed jars, the
spec file should either:
- add some parameters to ant (if the build.xml supports it) constructed with
build-classpath
- patch the build.xml to use the jars in the standard location
- create symlinks where the build.xml expect them (using build-jar-
repository?)
I'll have a look during my lunch break
Cheers
Thank you for proof reading
--
Farfouille
Re: [Mageia-dev] Java-Policy first draft published
Le 11/01/2011 00:00, Michael Scherer a écrit :
Le lundi 10 janvier 2011 à 21:02 +0100, Farfouille a écrit :
The part about Requires should IMHO be pushed in rpm dependency solver .
Apologize for maybe a noob question (btw I'm a noob packager waiting for his
turn to be trained ;) )
but what do you mean by 'rpm dependency solver' ?
Is is a tool to resolve dependencies at user installation time ?
A simple link to some kind of explaination will be a perfect answer.
I am not sure for the requires on jpackages-utils, could we explain what
it bring ?
I'll dig on that during my launch break
The same goes for maven and Requires(post), postun. This should be
detected by rpm., and we should use filetrigger.
Same noob question for filetrigger
The part about 1%{?dist} should be adapted to use %mkrel ( as we didn't
decide to drop it afaik ).
I'll dig on that during my launch break
Thank you for your comments
Cheers
--
Farfouille
