FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 11-03-2010, 04:27 PM
Ville Skyttä
 
Default Changes in Java packaging guidelines - RFC

On Wednesday 03 November 2010, Stanislav Ochotnicky wrote:

> FYI the versionless jar/javadocs files are now in the draft (thanks for
> the suggestion, somehow none of us thought of that)

Thanks for considering it.

> But keep those comments coming, we'll try to keep working on the
> guidelines to reflect current needs of packagers.

Some other things off the top of my head, in no particular order:

1) I'd like to see crosslinking of javadocs at least a SHOULD, and I wouldn't
mind a MUST at all. I'm also leaning towards making it a MUST for javadoc
packages that crosslink with other javadoc packages require the ones they
crosslink with.

2) Regarding wrapper scripts, I'd like to point out the %jpackage_script macro
for creating them. Here's one example of it in action:
https://bugzilla.redhat.com/attachment.cgi?id=457277
Also, most invocations of it will want to set the last argument of it to true
(such as in the example above) to make jpackage-utils stuff prefer a JRE over
a full Java SDK (assuming of course that they work with just a JRE installed
and don't require the full SDK) to avoid problems like these:
https://bugzilla.redhat.com/show_bug.cgi?id=461683
https://bugzilla.redhat.com/show_bug.cgi?id=498831

3) In my opinion, the whole alternatives setup in the JRE and SDK packages
should be purged. It's a relic from times that are long gone, and at the
moment causes just complexity and possibilities for breakage; it kind of even
encourages breakage by giving people the option to easily switch between
_incompatible_ java implementations (e.g. versions) for the system default
Java, breaking programs' expectations. environment-modules would sound like a
more appropriate solution for switching the Java implementation when needed.
I'm not holding my breath for this to happen too soon, but hope that it
sometime will.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-03-2010, 06:11 PM
Nicolas Mailhot
 
Default Changes in Java packaging guidelines - RFC

Le mercredi 03 novembre 2010 à 19:27 +0200, Ville Skyttä a écrit :

> 3) In my opinion, the whole alternatives setup in the JRE and SDK packages
> should be purged. It's a relic from times that are long gone,

Having a semi-sane way to install multi-vendor multi-version JVMs is
still needed EPEL side. Expensive apps like SAP still make you install
the specific JVM they've been qualified against. Please do not add
Fedora/RHEL fragmentation to the ongoing Fedora/JPackage fragmentation.

--
Nicolas Mailhot

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-03-2010, 06:32 PM
Alexander Kurtakov
 
Default Changes in Java packaging guidelines - RFC

> On Wednesday 03 November 2010, Ville Skyttä wrote:
> > On Wednesday 03 November 2010, Stanislav Ochotnicky wrote:
> > FYI the versionless jar/javadocs files are now in the draft (thanks for
> > the suggestion, somehow none of us thought of that)
>
> Thanks for considering it.
>
> > But keep those comments coming, we'll try to keep working on the
> > guidelines to reflect current needs of packagers.
>
> Some other things off the top of my head, in no particular order:
>
> 1) I'd like to see crosslinking of javadocs at least a SHOULD, and I
> wouldn't mind a MUST at all. I'm also leaning towards making it a MUST
> for javadoc packages that crosslink with other javadoc packages require
> the ones they crosslink with.
>
There is no sane way to make javadoc crosslink in a sane way, i.e. without
patching builds. That's why I would say let's postpone this until we can tell
packagers HOWTO do it.

> 2) Regarding wrapper scripts, I'd like to point out the %jpackage_script
> macro for creating them. Here's one example of it in action:
> https://bugzilla.redhat.com/attachment.cgi?id=457277
> Also, most invocations of it will want to set the last argument of it to
> true (such as in the example above) to make jpackage-utils stuff prefer a
> JRE over a full Java SDK (assuming of course that they work with just a
> JRE installed and don't require the full SDK) to avoid problems like
> these:
> https://bugzilla.redhat.com/show_bug.cgi?id=461683
> https://bugzilla.redhat.com/show_bug.cgi?id=498831
I didn't know about this macro. We should definitely document it on the wiki
and add it as tip to the guidelines.

>
> 3) In my opinion, the whole alternatives setup in the JRE and SDK packages
> should be purged. It's a relic from times that are long gone, and at the
> moment causes just complexity and possibilities for breakage; it kind of
> even encourages breakage by giving people the option to easily switch
> between _incompatible_ java implementations (e.g. versions) for the system
> default Java, breaking programs' expectations. environment-modules would
> sound like a more appropriate solution for switching the Java
> implementation when needed. I'm not holding my breath for this to happen
> too soon, but hope that it sometime will.
There are other way more important things to fix and being able to switch java
is still usable in a number of cases (despite the problems it causes).

Alex
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-03-2010, 06:32 PM
Ville Skyttä
 
Default Changes in Java packaging guidelines - RFC

On Wednesday 03 November 2010, Nicolas Mailhot wrote:
> Le mercredi 03 novembre 2010 à 19:27 +0200, Ville Skyttä a écrit :
> > 3) In my opinion, the whole alternatives setup in the JRE and SDK
> > packages should be purged. It's a relic from times that are long gone,
>
> Having a semi-sane way to install multi-vendor multi-version JVMs is
> still needed EPEL side. Expensive apps like SAP still make you install
> the specific JVM they've been qualified against.

But such JVMs do not need to be made the system default at all, people can
just run $expensive_app with it by whatever means they like (e.g. direct
modification of $PATH, $JAVA_HOME, etc _for that specific app_).

Providing an easy way for admins to alter the system default JVM to something
which will break expectations of software _we_ ship (in Fedora or EPEL) just
doesn't make sense to me.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-03-2010, 06:49 PM
Nicolas Mailhot
 
Default Changes in Java packaging guidelines - RFC

Le mercredi 03 novembre 2010 Ã* 21:32 +0200, Ville Skyttä a écrit :
> On Wednesday 03 November 2010, Nicolas Mailhot wrote:
> > Le mercredi 03 novembre 2010 Ã* 19:27 +0200, Ville Skyttä a écrit :
> > > 3) In my opinion, the whole alternatives setup in the JRE and SDK
> > > packages should be purged. It's a relic from times that are long gone,
> >
> > Having a semi-sane way to install multi-vendor multi-version JVMs is
> > still needed EPEL side. Expensive apps like SAP still make you install
> > the specific JVM they've been qualified against.
>
> But such JVMs do not need to be made the system default at all, people can
> just run $expensive_app with it by whatever means they like (e.g. direct
> modification of $PATH, $JAVA_HOME, etc _for that specific app_).

When you pass a certain level of expensiveness, ISVs just assume the
*only* jvm on the system will be the one they require (quite simply the
software price is many times the price of hardware, so there is no
reason to share the hardware with anything else).

It never ceases to astonish me how software “giants” have come to depend
on the quick and dirty hacks we did JPackage-side æons agos, and never
thought of redirecting some of their huge cash flow to fund something a
little more robust. Then again, given how it would have likely ended
(lsb, foo-grade linux), maybe it's better that way.

--
Nicolas Mailhot

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-03-2010, 07:28 PM
Ville Skyttä
 
Default Changes in Java packaging guidelines - RFC

On Wednesday 03 November 2010, Nicolas Mailhot wrote:
> Le mercredi 03 novembre 2010 Ã* 21:32 +0200, Ville Skyttä a écrit :
> > On Wednesday 03 November 2010, Nicolas Mailhot wrote:
> > > Le mercredi 03 novembre 2010 Ã* 19:27 +0200, Ville Skyttä a écrit :
> > > > 3) In my opinion, the whole alternatives setup in the JRE and SDK
> > > > packages should be purged. It's a relic from times that are long
> > > > gone,
> > >
> > > Having a semi-sane way to install multi-vendor multi-version JVMs is
> > > still needed EPEL side. Expensive apps like SAP still make you install
> > > the specific JVM they've been qualified against.
> >
> > But such JVMs do not need to be made the system default at all, people
> > can just run $expensive_app with it by whatever means they like (e.g.
> > direct modification of $PATH, $JAVA_HOME, etc _for that specific app_).
>
> When you pass a certain level of expensiveness, ISVs just assume the
> *only* jvm on the system will be the one they require (quite simply the
> software price is many times the price of hardware, so there is no
> reason to share the hardware with anything else).

Ok. So again, for what do you need the alternatives stuff for in this
scenario?

Either you abide by their assumption and just install their JVM and no others
(no alternatives needed because The Can Be Only One), or you don't and install
several JVMs or only the Fedora/EL one at which point you've already broken
their expectation and thus their support may be in a so-so state (no
alternatives needed because the damage is already done (alternatives or not)
or there is only the one Fedora/EL JVM installed).

> It never ceases to astonish me how software “giants” have come to depend
> on the quick and dirty hacks we did JPackage-side æons agos, and never
> thought of redirecting some of their huge cash flow to fund something a
> little more robust.

Ditto. But in retrospect, I wish we hadn't bent over and done those hacks
But that was a long time ago, those were different times and it's easy to be
smart later. I still believe it's time to stop encouraging use of that cruft,
at the very least in Fedora, then later in slower moving distros.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-03-2010, 08:14 PM
Nicolas Mailhot
 
Default Changes in Java packaging guidelines - RFC

Le mercredi 03 novembre 2010 à 22:28 +0200, Ville Skyttä a écrit :
> On Wednesday 03 November 2010, Nicolas Mailhot wrote:
> > Le mercredi 03 novembre 2010 à 21:32 +0200, Ville Skyttä a écrit :
> > > On Wednesday 03 November 2010, Nicolas Mailhot wrote:
> > > > Le mercredi 03 novembre 2010 à 19:27 +0200, Ville Skyttä a écrit :
> > > > > 3) In my opinion, the whole alternatives setup in the JRE and SDK
> > > > > packages should be purged. It's a relic from times that are long
> > > > > gone,
> > > >
> > > > Having a semi-sane way to install multi-vendor multi-version JVMs is
> > > > still needed EPEL side. Expensive apps like SAP still make you install
> > > > the specific JVM they've been qualified against.
> > >
> > > But such JVMs do not need to be made the system default at all, people
> > > can just run $expensive_app with it by whatever means they like (e.g.
> > > direct modification of $PATH, $JAVA_HOME, etc _for that specific app_).
> >
> > When you pass a certain level of expensiveness, ISVs just assume the
> > *only* jvm on the system will be the one they require (quite simply the
> > software price is many times the price of hardware, so there is no
> > reason to share the hardware with anything else).
>
> Ok. So again, for what do you need the alternatives stuff for in this
> scenario?

You need it to keep the jvm packaging modular and not have to package
the same jvm in multiple ways (jvm-as-system-default,
jvm-as-secondary-jvm, jvm-a-for-mixing-with-jvm-b, etc). For practical
purposes the "Enterprise" market is still stuck where JPackage was when
we added alternatives (which, btw, I hate dearly).

And it's unreasonable to expect those ISVs to change when Fedora has not
managed to package a working JBoss. If the Red Hat Java packaging can
not even be used with the top Red Hat Java product, what is there to
say? (and on this subject, I don't think Fedora Java can be dissociated
from Red Hat java)

The main reason other project members went for the packaging changes I
proposed in JPackage at the time (what people call the JPackage
guidelines now) is that I got the then top floss java application,
tomcat, to work with them (which was a beast to do alone before others
joined the ship). I find it worrying that Java packaging changes are
proposed now, but nobody seems to have taken the time to repackage a big
demanding java app with the new guidelines as a reality check.

But those who do the work decide, that was true then and is true now,
and I'm definitely not doing java packaging anymore. So feel free to
ignore me.

--
Nicolas Mailhot

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-03-2010, 08:33 PM
Alexander Kurtakov
 
Default Changes in Java packaging guidelines - RFC

> Le mercredi 03 novembre 2010 à 22:28 +0200, Ville Skyttä a écrit :
> > On Wednesday 03 November 2010, Nicolas Mailhot wrote:
> > > Le mercredi 03 novembre 2010 à 21:32 +0200, Ville Skyttä a écrit :
> > > > On Wednesday 03 November 2010, Nicolas Mailhot wrote:
> > > > > Le mercredi 03 novembre 2010 à 19:27 +0200, Ville Skyttä a écrit :
> > > > > > 3) In my opinion, the whole alternatives setup in the JRE and SDK
> > > > > > packages should be purged. It's a relic from times that are long
> > > > > > gone,
> > > > >
> > > > > Having a semi-sane way to install multi-vendor multi-version JVMs
> > > > > is still needed EPEL side. Expensive apps like SAP still make you
> > > > > install the specific JVM they've been qualified against.
> > > >
> > > > But such JVMs do not need to be made the system default at all,
> > > > people can just run $expensive_app with it by whatever means they
> > > > like (e.g. direct modification of $PATH, $JAVA_HOME, etc _for that
> > > > specific app_).
> > >
> > > When you pass a certain level of expensiveness, ISVs just assume the
> > > *only* jvm on the system will be the one they require (quite simply the
> > > software price is many times the price of hardware, so there is no
> > > reason to share the hardware with anything else).
> >
> > Ok. So again, for what do you need the alternatives stuff for in this
> > scenario?
>
> You need it to keep the jvm packaging modular and not have to package
> the same jvm in multiple ways (jvm-as-system-default,
> jvm-as-secondary-jvm, jvm-a-for-mixing-with-jvm-b, etc). For practical
> purposes the "Enterprise" market is still stuck where JPackage was when
> we added alternatives (which, btw, I hate dearly).
>
> And it's unreasonable to expect those ISVs to change when Fedora has not
> managed to package a working JBoss. If the Red Hat Java packaging can
> not even be used with the top Red Hat Java product, what is there to
> say? (and on this subject, I don't think Fedora Java can be dissociated
> from Red Hat java)
>
> The main reason other project members went for the packaging changes I
> proposed in JPackage at the time (what people call the JPackage
> guidelines now) is that I got the then top floss java application,
> tomcat, to work with them (which was a beast to do alone before others
> joined the ship). I find it worrying that Java packaging changes are
> proposed now, but nobody seems to have taken the time to repackage a big
> demanding java app with the new guidelines as a reality check.

Most of these changes are nothing new but bringing guidelines closer to
reality and removing some stuff that is causing nothing but confusion. And they
have been verified during the recent Maven 2.2.1 update and the ongoing Maven 3
work. Maven may not be as big as Tomcat if we speak in LOC but Maven is really
changing the way Java packaging is done.

Regards,
Alex

>
> But those who do the work decide, that was true then and is true now,
> and I'm definitely not doing java packaging anymore. So feel free to
> ignore me.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-03-2010, 08:35 PM
Jesse Keating
 
Default Changes in Java packaging guidelines - RFC

On 11/3/10 2:14 PM, Nicolas Mailhot wrote:
> And it's unreasonable to expect those ISVs to change when Fedora has not
> managed to package a working JBoss. If the Red Hat Java packaging can
> not even be used with the top Red Hat Java product, what is there to
> say? (and on this subject, I don't think Fedora Java can be dissociated
> from Red Hat java)

JBoss isn't in Fedora because JBoss seems to require lots of things that
are older than what we ship in Fedora. I see this is a problem with
JBoss, not Fedora.

--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-03-2010, 08:54 PM
Alexander Kurtakov
 
Default Changes in Java packaging guidelines - RFC

> On 11/3/10 2:14 PM, Nicolas Mailhot wrote:
> > And it's unreasonable to expect those ISVs to change when Fedora has not
> > managed to package a working JBoss. If the Red Hat Java packaging can
> > not even be used with the top Red Hat Java product, what is there to
> > say? (and on this subject, I don't think Fedora Java can be dissociated
> > from Red Hat java)
>
> JBoss isn't in Fedora because JBoss seems to require lots of things that
> are older than what we ship in Fedora. I see this is a problem with
> JBoss, not Fedora.

Well JBoss is not even a single product it's a bunch of products - see
http://www.jboss.org/projects/matrix. And both projects have to improve and
colaborate to get things working. On our(Fedora) site we have a long way to go
before having maven 3 working, rpm maven autoprovides/requires and so on and
so on to make it easier for contributors.

Regards,
Alex

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 06:26 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org