packaging lessons from FUDCon hackfest?
by Karsten Wade
Andrew Overholt and Tom Fitzsimmons sat with a guy from Alfresco (Lee
Faus) last Friday in the FUDCon hackfests. Mainly they were doing a
code review with him to see what he has to do to get Alfresco packaged
for Fedora. It was a great effort, and possibly enlightening for
everyone as to the scope of the problem ahead of us to get Java ISVs
packaged in Fedora.
Andrew, Tom -- where there any insights, lessons, ideas, or other
outfalls from that work with Lee?
Two specific areas of interest are:
* Tips, ideas, or plans for Java packaging ==> target
wiki/Packaging/Java
* ISV-specific lessons, tips, etc. ==> target wiki/SIGs/ISV
I'm asking on this list because I think a brain dump from both of you
here would give good exposure. I'm ready to glean content to make the
above wiki updates. :)
- Karsten
--
Karsten Wade, Sr. Developer Community Mgr.
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41
14 years, 11 months
Re: Ownership of /etc/maven/fragments and /usr/share/maven2/poms
by Deepak Bhole
* Jason L Tibbitts III <tibbs(a)math.uh.edu> [2008-06-28 18:23]:
> Sorry for the resend; this should have the correct address for the
> java list.
>
> I hope I'm CC'ing this sufficiently; I do not know if any
> representatives form the Java group are members of fedora-packaging.
>
> I was reviewing my first maven-using package and ran into an issue
> with the Java packaging guidelines. Namely that they specify that
> every maven-using package should own /etc/maven/fragments and
> /usr/share/maven2/poms, which contradicts our usual policy on
> directory ownership by multiple packages.
>
> I don't really understand why the packages would need to own those
> directories; jpackage-utils already serves as a kind of filesystem
> package for java, it already owns /etc/maven and several
> java-related directories in /usr/share, and all of the packages which
> would own files in the two directories at issue already depend on it.
> So I think jpackage-utils should just own /etc/maven/fragments and
> /usr/share/maven2/poms and we can tweak the guidelines to not specify
> that the individual packages own these directory.
>
> Another possibility would be to shift this off to a java-filesystem
> package analogous to our other *-filesystem packages which could own
> these and various other java directories.
>
I think moving them to jpackage-utils would be sufficient, as it owns a
multitude of other java related directories right now. I have put this
down on my TODO list and will get to it on Monday (off today and
tomorrow).
> This would fix ownership issues for 22 packages currently.
>
> Another separate bug related issue is the fact that the contents of
> /etc/maven/fragments do not seem to be configuration files, and so
> probably should not live under /etc. I do not have sufficient Java
> knowledge to propose a solution, however.
>
Correct, technically they are not configuration related files. I'd be happy to
move them, but I am not sure what the best place for them is either :/ ..
suggestions are welcome. The files serve as configuration in the sense
that they provide maven with a "mapping" between where maven expects
jars to be, and where they actually are on the system.
Cheers,
Deepak
14 years, 11 months
[mjj29@debian.org: Re: Developing with Java on Debian]
by Andrew Overholt
Has anyone from JPackage or Fedora spoken with the Debian java people?
----- Forwarded message from Matthew Johnson <mjj29(a)debian.org> -----
> From: Matthew Johnson <mjj29(a)debian.org>
> To: Florian Grandel <jerico.dev(a)gmail.com>
> Cc: debian-java(a)lists.debian.org
> User-Agent: Mutt/1.5.17 (2007-11-01)
> Date: Mon, 30 Jun 2008 14:26:45 +0100
> Subject: Re: Developing with Java on Debian
> X-Mailing-List: <debian-java(a)lists.debian.org> archive/latest/9812
>
> On Mon Jun 30 10:01, Florian Grandel wrote:
> > Hi Java developers,
> >
> >> One problem that I haven't solved so far is how to get the classpath
> >> into the MANIFEST file as was proposed earlier in this thread.
> >
> > As you may have remarked from my earlier posts I am working with the
> > JPackage guys recently. Their "recommendation to Java developers" arguments
> > against adding classpaths to the manifest.
>
> Well, they are wrong.
>
> > Probably the first three arguments do not apply to the Debian
> > environment, but the last one may. I have not yet made up my mind on
> > that. I just didn't want you to loose their arguments:
>
> > "Do not use Class-Path references in MANIFESTs
> >
> > The Class-Path system of MANIFESTs is evil because:
> >
> > * It doesn't work with JDK 1.x.
> > * It only works at runtime, not at build time.
> > * It only works for a specific installation hierarchy.
>
> These are, as you say, not relevant for Debian. I particularly like the
> second point, since their solution of wrapper scripts means maintaining
> two lists of classpath, one in the build system and one in the wrapper
> _anyway_. The specific installation heirarchy thing is interesting. The
> wrapper script is going to have to have _some_ guess at the heirarchy
> and if that doesn't work you are just pushing the problem of creating
> the classpath onto the user, which is clearly bad.
>
> Sufficiently clever build systems should propagate the build CLASSPATH
> to the manifest automatically anyway.
>
> > * It can not be configured.
>
> It's unclear to me what they want to be configured at runtime by
> changing the classpath.
>
> > Wrapper scripts are much versatile and universal. We provide a set of
> > convenient shell helper functions for setting up such Unix scripts easily
> > (see jpackage-utils in project CVS)." [1]
>
> Wrapper scripts without classpath manifest items also result in
> large classpaths containing items you shouldn't have to know about (your
> dependencies' dependencies) and causes unnecessary transitions when
> these change.
>
> > You may also have a look at their build support system as they have some
> > quite useful helper scripts as well. jpackage-utils is available in
> > universe/contrib.
>
> But not available in Debian.
>
> > And as Richard was asking earlier how to identify dependencies within jar
> > packages: I am using Matthew's java-propose-classpath a lot and it works
> > fine (Thank you Matthew!). But sometimes it seems to miss some
> > dependencies, I have not yet found out why.
>
> Hmm, if you can give me a test case, I'd be very interested. It
> _should_ only suffer from giving you too many dependencies when there
> are multiple jars containing the same class.
>
> Matt
> --
> Matthew Johnson
----- End forwarded message -----
14 years, 11 months
Re: /usr/share/eclipse/* -> %{_libdir}/eclipse/
by Andrew Overholt
* Nicolas Mailhot <nicolas.mailhot(a)laposte.net> [2008-06-27 15:17]:
> Le vendredi 27 juin 2008 à 14:14 -0400, Andrew Overholt a écrit :
>
> > Does anyone have any thoughts on this?
>
> I'd rather you worked with Fernando Nasser and the other guys in
> Fedora's java place on common jar deployment rules, instead of
> reinventing the private app root dead-end that makes sharing resources
> next to impossible and encourages library forking and duplication
The JARs are 99% application-specific so putting them into a
subdirectory makes sense to me and follows the guidelines we have in
place. We have no library forking or duplication of the dependent JARs,
either.
Andrew
14 years, 11 months
/usr/share/eclipse/* -> %{_libdir}/eclipse/
by Andrew Overholt
Hi,
In the past we've struggled with multilib issues in the Eclipse SDK
package. Examples include having to re-pack every JAR to have a common
timestamp, shuffling arch-specific JARs off to %{_libdir} thus causing
headaches with upstream mechanisms (which I'm concerned will continue
with the new version), etc.
I just found out today that Debian ships everything in
%{_libdir}/eclipse to avoid these issues. I'm proposing we do the same
for Fedora 10 and beyond.
Pros:
- self-contained installation like upstream
- dramatically speeds up builds
- remove potential for bugs with the multiple locations
- looks like an upstream download
- consistency with other distributions
Cons:
- larger disk footprint for multilib installations (on the order of 100
MB ... although the vast majority of users don't use both)
Does anyone have any thoughts on this?
Thanks,
Andrew
14 years, 11 months
Eclipse plugins outside the Fedora effort
by Mat Booth
Hi all,
There's been question asked on one of my bugs[1] that I'm not
confident I know the answer to. Essentially, he's asking what the
policy is on using Eclipse plugins that are outside the Fedora effort.
I don't know of any formal documentation and my gut feeling is that
everything should just work, if you don't mind extra the configuration
because of the lack of really tight integration that comes with Fedora
packaged plugins. But I'm still new to Fedora as a contributor so I
though I'd garner a second opinion to make sure I'm not lying my arse
off.
Any thoughts?
Regards,
Mat
[1] https://bugzilla.redhat.com/show_bug.cgi?id=452442#c2
--
Mat Booth
www.matbooth.co.uk
14 years, 11 months
compatible provides?
by Benjamin Reed
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Would it be possible to add compatible provides to the openjdk -devel
package? Since OpenNMS uses Tomcat and/or Jetty, and does not
precompile it's JSP files, we require a JDK at runtime.
Unfortunately, there are no provides that are the same across OpenJDK
and Sun's Java:
Sun JDK:
[ranger@nen ~]$ rpm -q --provides jdk
jre = 1.5.0_15
j2sdk = 1.5.0_15
j2re = 1.5.0_15
jaxp_parser_impl
xml-commons-apis
jdk = 2000:1.5.0_15-fcs
jaxp_parser_impl
xml-commons-apis
jdk = 2000:1.6.0_05-fcs
OpenJDK:
[ranger@localhost opennms-1.6]$ rpm -q --provides \
~ java-1.6.0-openjdk-devel
java-1.6.0-devel = 1:1.6.0.0
java-1.7.0-icedtea-devel = 0:1.7.0.0-0.999
java-devel = 1:1.6.0
java-devel-openjdk = 1:1.6.0.0
java-sdk = 1:1.6.0
java-sdk-1.6.0 = 1:1.6.0.0
java-sdk-1.6.0-openjdk = 1:1.6.0.0
java-sdk-openjdk = 1:1.6.0.0
lib.so
libunpack.so
java-1.6.0-openjdk-devel = 1:1.6.0.0-0.13.b09.fc9
- --
Benjamin Reed
The OpenNMS Group
http://www.opennms.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFITZstUu+jZtP2Zf4RAn2lAKCBTG40bO7w0rC/8tPSmegwZFoJ5wCeIMUC
04m2D8MnA0EGEfQdYn5zPxM=
=dayB
-----END PGP SIGNATURE-----
14 years, 11 months
ant possibly broken when using 'ant generate.wsdl' from axis2 examples
by Timothy Selivanow
Hi,
I'm going through the quickstart sample from axis2 and found an error
that only occurs while using the packaged ant in Fedora 8 and 9. Here
is the error I receive:
$ ant generate.wsdl
Buildfile: build.xml
compile.service:
generate.wsdl:
BUILD FAILED
/home/timothys/projects/lib/java/axis2-1.4/samples/quickstart/build.xml:53: java.lang.ExceptionInInitializerError
Total time: 0 seconds
When run with '-debug', I see *lots* of the following errors:
Caused by: org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: Invalid class
loader hierarchy. You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed.
When I use upstream's ant and set ANT_HOME to that, the error does not
occur and the build succeeds. I'm very new to java et al., so I don't
know if I am missing something, or if this is a bug in the way things
are packaged...
--Tim
14 years, 12 months
