R.Apel | 1 Aug 09:39 2008

Re: Packaging batik 1.7

Our batik package set should provide split jars as well as a monolithic one.
Back in 1.5 it used to be like that, and in fact some pieces of software do require the monolithic stuff while
others require specific named individual libraries to build and/or run.
On Nov 22 2004 Ville obsoleted the -monolithic package.
I would be in favour of reintroducing this as xmlgraphics-batik-monolithic, just containing all classes
from the split jar files from the main package (i.e. no applications).

Regarding Obsoletes and compat symlinks, there don't seem to exist indications of non-compatibility in
release notes or equivalent files. We may then verify that any package which BR batik-1.6 still builds
well with batik-1.7. If so, proceed with Obsoletes/Provides/Compat...

-----Ursprüngliche Nachricht-----
Von: jpackage-discuss-bounces@...
[mailto:jpackage-discuss-bounces <at> zarb.org] Im Auftrag von David Walluck
Gesendet: Donnerstag, 31. Juli 2008 17:18
An: Discussion about JPackage project
Betreff: [JPackage-discuss] Packaging batik 1.7

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I am finishing up a batik 1.7 package.

I would like to call it xmlgraphics-batik since we already ship xmlgraphics-commons and
xmlgraphics-fop. Should the package Provides/Obsoletes batik, or be parallel installable with it? In
the case where it would replace batik, I believe it could provide a couple symlinks in /usr/share/javafor
backwards compatibility.

JPackage 1.7 ships batik 1.6 with split jars. Fedora (and Mandriva) ship batik 1.7 with a single monolithic
jar (called batik-all.jar).
(Continue reading)

Fernando Nasser | 1 Aug 15:34 2008
Picon

Re: Packaging batik 1.7

+1

I've been telling David the same thing.

The package is now called xmlgraphics-batik but I think it should 
provide 'batik' = %{version}-%{release} as well and the monolithic batik 
jar should be in %{javadir} as usual.

Fernando

R.Apel@... wrote:
> Our batik package set should provide split jars as well as a monolithic one.
> Back in 1.5 it used to be like that, and in fact some pieces of software do require the monolithic stuff while
others require specific named individual libraries to build and/or run.
> On Nov 22 2004 Ville obsoleted the -monolithic package.
> I would be in favour of reintroducing this as xmlgraphics-batik-monolithic, just containing all
classes from the split jar files from the main package (i.e. no applications).
> 
> Regarding Obsoletes and compat symlinks, there don't seem to exist indications of non-compatibility in
release notes or equivalent files. We may then verify that any package which BR batik-1.6 still builds
well with batik-1.7. If so, proceed with Obsoletes/Provides/Compat...
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: jpackage-discuss-bounces@...
[mailto:jpackage-discuss-bounces <at> zarb.org] Im Auftrag von David Walluck
> Gesendet: Donnerstag, 31. Juli 2008 17:18
> An: Discussion about JPackage project
> Betreff: [JPackage-discuss] Packaging batik 1.7
> 
(Continue reading)

Fernando Nasser | 1 Aug 15:45 2008
Picon

Re: [JPackage-announce] [RPM (5.0)] glassfish-jaxb-2.1.4-4.jpp5

This are brand new packages, I guess that is still coming.  It is better 
than the binaries or the useless api-only we had before.

The thing is that it is very difficult to build these Glassfish APIs (+ 
implementations).  They are designed to be built in bulk with the rest 
of Glassfish inside NetBeans.

Please feel free to add the alternatives, I am sure Clive wouldn't mind.

Cheers,
Fernando

R.Apel@... wrote:
> Why not use symlinks and alternatives?
> 
> There are other sources/codings for this api.
> 
> These files conflict with those other providers.
> 
> Who cancelled the API-Spec naming convention we have been widely using?
> 
> install -d -m 755 $RPM_BUILD_ROOT%{_javadir}
> install -m 644 dist/lib/jaxb-api.jar $RPM_BUILD_ROOT%{_javadir}/jaxb-api.jar
> install -m 644 dist/lib/jaxb-api.jar $RPM_BUILD_ROOT%{_javadir}/jaxb_2_1_api.jar 
> 
> -----Ursprüngliche Nachricht-----
> Von: jpackage-announce-bounces@...
[mailto:jpackage-announce-bounces <at> zarb.org] Im Auftrag von David Walluck
> Gesendet: Dienstag, 22. Juli 2008 22:17
> An: jpackage-announce@...
(Continue reading)

Fernando Nasser | 1 Aug 15:52 2008
Picon

Re: redstone-xmlrpc (replacement formarquee-xmlrpc)

Aren't the comments above the SourceNN line enough?
I like to cut and paste from there...  It is easier than having to 
explode the previous tar ball.  Also, the .spec file is easier to 
recover if something goes wrong, and the contents of the tar ball should 
match exactly what the svn export or wget or whatever upstream provides...

We have this practice of adding comments above the SourceNN line as one 
of our (yet unwritten) guidelines.  It is even in the Draft ones I am 
typing for us to comment on.

Or is this script thing for some really complex cases of source 
gathering?  In this case, perhaps keeping it in a separate Source99 
wouldn't be preferrable?  I guess rpmlint may give a warning about 
source not used, but the script would still be more easily accessible.

R.Apel@... wrote:
> Good idea!
> +1 
> 
> -----Ursprüngliche Nachricht-----
> Von: jpackage-discuss-bounces@...
[mailto:jpackage-discuss-bounces <at> zarb.org] Im Auftrag von Jason Corley
> Gesendet: Donnerstag, 31. Juli 2008 16:44
> An: Discussion about JPackage project
> Betreff: Re: [JPackage-discuss] redstone-xmlrpc (replacement formarquee-xmlrpc)
> 
>> - include comments on how to reproduce Source0
> 
> One of the things I've done lately is to include the script used to generate the tarball in the tarball
itself.  See the ecj package for what I've done if interested.
(Continue reading)

Fernando Nasser | 1 Aug 15:54 2008
Picon

Re: -repolib packages

The need of repolib subpackages will go away with JBoss AS 5.

Maybe we can even find a way to backport that into JBoss AS 4.2.3 build, 
but these things require time we don't currently have, as we are trying 
to get a JPP 5 Beta by the end of the summer.

David Walluck wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> R.Apel@... wrote:
> | Is there some documentation about the purpose and mechanism of
> | -repolib subpackages?
> 
> The repolib packages are for building jbossas only. These are hard
> copies of the jars for the buildmagic repository that jbossas uses for
> building.
> 
> There's a problem with directory ownership in *all* repolib packages,
> which I hope to fix eventually.
> 
> | Could somebody perhaps point me to some discussion archives?
> 
> I found this thread to which only Jason Corley responded:
> <https://www.zarb.org/pipermail/jpackage-discuss/2007-January/010853.html>.
> 
> - --
> Sincerely,
> 
> David Walluck
(Continue reading)

R.Apel | 1 Aug 16:42 2008

Re: [JPackage-announce] [RPM(5.0)] glassfish-jaxb-2.1.4-4.jpp5

Never had a look at the sun-jaxb-2.1-api and sun-jaxb-2.1-impl packages ?

Are these expected to be different from the "glassfish APIs" ?

I would say these are the same code, but organized such as to be build without netbeans and not in bulk with the
rest of glassfish.

(Btw, if renaming to "glassfish-jaxb-*" and/or downgrading is required, we could do so).

-----Ursprüngliche Nachricht-----
Von: jpackage-discuss-bounces@...
[mailto:jpackage-discuss-bounces <at> zarb.org] Im Auftrag von Fernando Nasser
Gesendet: Freitag, 1. August 2008 15:46
An: Discussion about JPackage project
Betreff: Re: [JPackage-discuss] [JPackage-announce] [RPM(5.0)] glassfish-jaxb-2.1.4-4.jpp5

This are brand new packages, I guess that is still coming.  It is better than the binaries or the useless
api-only we had before.

The thing is that it is very difficult to build these Glassfish APIs (+ implementations).  They are designed
to be built in bulk with the rest of Glassfish inside NetBeans.

Please feel free to add the alternatives, I am sure Clive wouldn't mind.

Cheers,
Fernando

R.Apel@... wrote:
> Why not use symlinks and alternatives?
> 
(Continue reading)

Fernando Nasser | 1 Aug 17:03 2008
Picon

Re: [JPackage-announce] [RPM(5.0)] glassfish-jaxb-2.1.4-4.jpp5

R.Apel@... wrote:
> Never had a look at the sun-jaxb-2.1-api and sun-jaxb-2.1-impl packages ?
> 

Ah, when we looked there was only the api part. I guess we missed the 
announcement of the impl one.

> Are these expected to be different from the "glassfish APIs" ?
> 

The glassfish ones are open source and people (like the JBoss guys) can 
submit fixes, some have commit access and some can even do releases.

I think the Sun ones are "closed" develpment.

> I would say these are the same code, but organized such as to be build without netbeans and not in bulk with
the rest of glassfish.
> 

Maybe, I can't really tell.

> (Btw, if renaming to "glassfish-jaxb-*" and/or downgrading is required, we could do so).
> 

Maybe we should keep both and make sure the alternatives is used.  But 
we must be careful if there are two API levels.  We had a plan for how 
to avoid alternatives switching the api level, it is in the list 
archives.  We should recue that for the new Guidelines page.

Cheers,
(Continue reading)

David Walluck | 1 Aug 17:33 2008

Re: Packaging batik 1.7


R.Apel@... wrote:
| Nov 22 2004 Ville obsoleted the -monolithic package. I would be in
| favour of reintroducing this as xmlgraphics-batik-monolithic, just
| containing all classes from the split jar files from the main package
| (i.e. no applications).

This is easy enough to do, but I don't see the functional difference of
doing $(build-classpath xmlgraphics-batik) on a directory vs.
$(build-classpath batik-all).

I think also we'd install batik-all as
/usr/share/java/xmlgraphics-batik-all.jar so that $(build-classpath
xmlgraphics-batik) doesn't also add the '-all' jar in addition to the
split jars.

| Regarding Obsoletes and compat symlinks, there don't seem to exist
| indications of non-compatibility in release notes or equivalent
| files. We may then verify that any package which BR batik-1.6 still
| builds well with batik-1.7. If so, proceed with
| Obsoletes/Provides/Compat...

Right now, since the name changed, parallel install works. So, in the
meantime it's not hurting much to have both.

The only issue I found is that now xmlgraphics-fop meeds to be updated
to 0.95, but this requires xml-commons 1.3.04 for the svg support.

--
Sincerely,
(Continue reading)

R.Apel | 1 Aug 17:39 2008

Re: Packaging batik 1.7

OK,

The difference with the monolithic jar is when you are building against some maven2 pom.xml:

If it states something like "batik-all" among the dependencies, you will need to patch it adding many of the
split jars ...

-----Ursprüngliche Nachricht-----
Von: jpackage-discuss-bounces@...
[mailto:jpackage-discuss-bounces <at> zarb.org] Im Auftrag von David Walluck
Gesendet: Freitag, 1. August 2008 17:34
An: Discussion about JPackage project
Betreff: Re: [JPackage-discuss] Packaging batik 1.7

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

R.Apel@... wrote:
| Nov 22 2004 Ville obsoleted the -monolithic package. I would be in 
| favour of reintroducing this as xmlgraphics-batik-monolithic, just 
| containing all classes from the split jar files from the main package 
| (i.e. no applications).

This is easy enough to do, but I don't see the functional difference of doing $(build-classpath
xmlgraphics-batik) on a directory vs.
$(build-classpath batik-all).

I think also we'd install batik-all as
/usr/share/java/xmlgraphics-batik-all.jar so that $(build-classpath
xmlgraphics-batik) doesn't also add the '-all' jar in addition to the split jars.
(Continue reading)

David Walluck | 1 Aug 18:02 2008

Re: Packaging batik 1.7


R.Apel@... wrote:
| If it states something like "batik-all" among the dependencies, you
| will need to patch it adding many of the split jars ...

As I understand it, the xmlgraphics-batik-monothlic package will
Provides/Obsolete: batik and provide symlinks for batik-all.jar. This
will retain compatibility with the batik 1.7 currently in Fedora 9,
although it would also Obsolete it.

However, there are some issues:

1.) Should it also Provide batik.jar? This would satisfy the upgrade to
1.5, however in 1.6 we have them split and the *directory* is called batik.

2.) We could provide only batik-all.jar in '-monolithic' and also
provide a symlink from /usr/share/java/xmlgraphics-batik to
/usr/share/java/batik.

Now the problem is that only one package can Provides/Obsolete: batik.
Proposal #1 satisfies the batik 1.5 layout, whereas proposal #2
satisfies the batik 1.6 layout.

In order to satisfy both requirements, I would propose that we just ship
batik-all.jar in the main package even though it's a duplication of classes.

--
Sincerely,

David Walluck
(Continue reading)


Gmane