Re: [Mageia-dev] Java-Policy first draft published

[Dexter Morgan]

On Mon, Jan 10, 2011 at 9:02 PM, 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.
>
> 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
>
>

hi,

maybe we should modify the templates to use maven instead of maven2
wdyt ?

Re: [Mageia-dev] Java-Policy first draft published

[Michael Scherer]

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 ve

Re: [Mageia-dev] Java-Policy first draft published

[piep]

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 ?



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 project, "jpp6", provides rpm packages built on java6 
(JavaRuntimeEnvironment 1.6) and more than 2700 packages are ready to be 
installed on any rpm based system.

see : http://www.jpackage.org/browser/browse.php?jppversion=6.0

This is not the 400 packages of Mandriva project. Jpackage provides most 
of all java applications from the apache foundation (tomcat, maven, 
glassfish, hibernate, jakarta etc...) but also the J2EE application 
server "jboss" (from Red Hat now).


"jpp6" project is still under "Work In Progress" (WIP) state but I guess 
the number of package will reach the number of the actual "stable" 
version 5 : 3327 rpms.

see : http://www.jpackage.org/browser/browse.php?jppversion=5.0


2) JavaRuntimeEnvironment 1.6 aka java6 VM is the version provided in 
Mandriva cooker (and now Mageia caultron I guess) and it already 
provides the "jpackage-utils" package which is necessary to run packages 
from a jpackage repository.

Jpackage now (jpp6) uses java compiler : openjdk

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 



	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. 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.




3) If you want to test the jpackage repository on your actual distro.

3.1) add a jpackage repository in mandriva cooker. (test on mdv cooker 
dec 2010)


3.1.1) add the jpackage key

# rpm --import http://www.jpackage.org/jpackage.asc

(ref : http://jpackage.org/gpgkey.php)

3.1.2) replace jpackage-utils-1.7.5 by jpackage-utils-5.0.0
(I guess final version will be jpackage-utils-6.0.0)

# rpm -Uvh 
http://vesta.informatik.rwth-aachen.de/ftp/pub/comp/Linux/jpackage/6.0/generic/free/RPMS/jpackage-utils-5.0.0-2.jpp6.noarch.rpm


3.1.3) add the jpackage-6.0-generic-free depot

The standard command provides an error :
# urpmi.addmedia jpackage-6.0-generic 
http://vesta.informatik.rwth-aachen.de/ftp/pub/comp/Linux/jpackage/6.0/generic/free 
with hdlist.cz

adding medium "jpackage-6.0-generic"
...retrieving failed: curl failed: exited with 22

no metadata found for medium

This is because urpmi runs the following command :
/usr/bin/curl -q -s --location-trusted -R -f --disable-epsv 
--connect-timeout 60 --anyauth --stderr - -O 
http://vesta.informatik.rwth-aachen.de/ftp/pub/comp/Linux/jpackage/6.0/generic/free/reconfig.urpmi


and this reconfig.urpmi does not exist on the jpackage depot (I guess 
this is a mismatch between "urpmi" version)


solution :
# urpmi.addmedia --probe-synthesis jpackage-6.0-generic-free 
http://vesta.informatik.rwth-aachen.de/ftp/pub/comp/Linux/jpackage/6.0/generic/free/RPMS


3.1.4) add the jpackage-6.0-generic-non-free depot (empty depot on 
2010-dec but can be useful)
# urpmi.addmedia --probe-synthesis jpackage-6.0-generic-non-free 
http://vesta.informatik.rwth-aachen.de/ftp/pub/comp/Linux/jpackage/6.0/generic/non-free/RPMS




4) some major application already packaged on jpp6 :
ant
glassfish
hibernate
jakarta
jboss
log4j
lucene
maven
saxon
tomcat
xerces
xalan
wsdl4j
etc...

see "Available Groups" for more details
http://mirrors.dotsrc.org/jpackage/6.0/generic/free/repoview/index.html


5) some old links found about Co-existence_with_JPackage:
http://wiki.mandriva.com/en/Java_Packaging_Policy#Co-existence_with_JPackage
http://wiki.mandriva.com/en/Policies/Java/JPackage


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 ?



long life to Mageia,
Pierrick Hervé

Re: [Mageia-dev] Java-Policy first draft published

[Remy CLOUARD]

On Fri, Jan 21, 2011 at 04:47:28PM +0100, Thierry Vignaud wrote:
> On 21 January 2011 16:14, Michael scherer  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

[Michael scherer]

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

[Thierry Vignaud]

On 21 January 2011 16:14, Michael scherer  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

[Michael scherer]

On Fri, Jan 21, 2011 at 10:06:21AM +0100, Thierry Vignaud wrote:
> On 21 January 2011 00:01, nicolas vigier  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

[Frank Griffin]

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 ?

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.

Re: [Mageia-dev] Java-Policy first draft published

[Thierry Vignaud]

On 21 January 2011 00:01, nicolas vigier  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

[nicolas vigier]

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  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

[nicolas vigier]

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

[Michael scherer]

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

[Farfouille]

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

[Farfouille]

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

[Farfouille]

Le 10/01/2011 21:56, Romain d'Alverny a écrit :
> 
> On Mon, Jan 10, 2011 at 21:02, Farfouille  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

[Daniel Kreuter]

On Thu, Jan 13, 2011 at 12:49 PM, Frank Griffin  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

[Michael Scherer]

Le mercredi 12 janvier 2011 à 20:49 +0100, Farfouille a écrit :
> 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.

Then we will move it to non free, as we do not have the source code for
what we ship. 

Not being able to rebuild it from sources is a non go for core.

-- 
Michael Scherer

Re: [Mageia-dev] Java-Policy first draft published

[Frank Griffin]

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.

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

[Daniel Kreuter]

On Thu, Jan 13, 2011 at 2:01 AM, Frank Griffin  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

[Frank Griffin]

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

[Renaud MICHEL]

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.
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.

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.

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).

-- 
Renaud Michel

Re: [Mageia-dev] Java-Policy first draft published

[Frank Griffin]

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

[Frank Griffin]

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]

On mercredi 12 janvier 2011 at 22:41, 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.

Looking at fedora's eclipse plugins packages, it seems they are symlinking 
directly the jars from their system bundle in the eclipse plugins directory, 
with full package and version as symlink name.
I thought some eclipse specific files (like plugin.properties) were required 
inside the jar, but it seems not.

-- 
Renaud Michel

Re: [Mageia-dev] Java-Policy first draft published

[Renaud MICHEL]

On mercredi 12 janvier 2011 at 17:45, Frank Griffin wrote :
> 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 don't know for netbeans (maybe it is the same as eclipse), but eclipse 
needs anyway all of its dependencies inside his own plugins directory, so it 
would anyway be hard to use other system installed jars.
But the source of the required version could probably be included in the 
src.rpm of the requiring plugins and built/installed before them (but I 
actually have no idea how eclipse plugins are built from source).

The problem is, many eclipse plugins (or plugins collections actually) have 
dependencies on the same libs (for example xalan and xerces) which they all 
provide in their zip archive. We cannot have them in each package that need 
them as it would create file conflicts between those packages.
So we would need to create separate packages for those "external 
dependencies plugins". They could be built from their own source (from the 
official project) and then the real plugins would depend on them.
That would probably require a special naming convention for dependencies 
between plugins (as the package doesn't provide "xalan" but "xalan as an 
eclipse plugin")

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?

-- 
Renaud Michel

Re: [Mageia-dev] Java-Policy first draft published

[Farfouille]

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

[Frank Griffin]

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

Re: [Mageia-dev] Java-Policy first draft published

[Michael Scherer]

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

[Frank Griffin]

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.

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.

> As I have never used maven, a deep reread is required
>
>
>   

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  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.

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 !

Re: [Mageia-dev] Java-Policy first draft published

[Anssi Hannula]

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

[Michael Scherer]

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

[Farfouille]

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

Re: [Mageia-dev] Java-Policy first draft published

[Farfouille]

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

[Michael Scherer]

Le lundi 10 janvier 2011 à 21:02 +0100, Farfouille a écrit :
> 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 part about Requires should IMHO be pushed in rpm dependency solver .

I am not sure for the requires on jpackages-utils, could we explain what
it bring ?

The same goes for maven and Requires(post), postun. This should be
detected by rpm., and we should use filetrigger.

The part about 1%{?dist} should be adapted to use %mkrel ( as we didn't
decide to drop it afaik ).

-- 
Michael Scherer

Re: [Mageia-dev] Java-Policy first draft published

[Renaud MICHEL]

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

[Michael Scherer]

Le lundi 10 janvier 2011 à 21:56 +0100, Romain d'Alverny a écrit :
> On Mon, Jan 10, 2011 at 21:02, Farfouille  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

[Romain d'Alverny]

On Mon, Jan 10, 2011 at 21:02, Farfouille  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

[Farfouille]

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