Re: Updating Jakarta Commons packages
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Petter Reinholdtsen wrote:
> [Barry Hawkins]
>
>>General Recommendations
>>1. Use version numbers almost always. Our current policy[0] shows this
>>as optional, but I believe it should be more the standard we follow by
>>default. Java libraries, in this case Jakarta Commons libraries, are
>>almost always vulnerable to incompatibilities between major versions.
>>Seasoned Ant users and Maven as a whole[1] (thanks Trygve Laugstøl) have
>>chosen versioned .jar files to address this.
>
> Sounds like you are proposing so-name versioning for Java. Done
> right, it is a good idea. Done wrong it isn't. :)
>
> The librariy packages should have a version number that changes
> whenever there is an incompatible change in the library binary. No
> more, and no less. That way programs using the library only need to
> rebuild with newer dependencies when needed, and it will keep working
> across library upgrades as long as the library is backward compatbile.
[...]
I didn't particularly have so versioning in mind, but I guess that is a
close analog. I think I follow what you are saying in theory; could you
use the example of Jakarta Commons Collections included in the original
post to explain how your suggestions would either agree with the
proposal or differ from it?
>>2. Do not prefix the source package with "lib". Libraries, at least
>>most of the ones worth packaging, almost always ship their docs in
>>the tarballs. Having a source package whose name matches the binary
>>package for the library itself loosely implies that is all it's for.
>>Since some libraries also ship with examples and testing frameworks,
>>this can become even more confusing, as can be seen in the one bug
>>for libcommons-collections3-java[3].
>
> I do not understand this argument. There are several lib* packages
> with both binaries and documentation included. I do not see that as a
> problem.
[...]
We could certainly have a policy that a given library installs both its
.jars and its documentation; in some ways I think that would simplify
matters. As it stands, the Java libraries look like they are taking a
varied approach. I would think that users who employ these libraries on
production machines would certainly want to be able to exclude the
documentation, so having separate binaries for that
> As for the java "programs", several of the packages is lacking
> wrappers to start them in /usr/bin/, and I suspect that is the main
> reason people perceive the packages as libraries only. If people
> believe that, that is. I don't believe it.
I am not sure I follow what you are saying here. Are you saying that
certain packages for Java which are applications lack wrapper scripts?
That certainly makes sense. I don't understand the part that you don't
believe. If you could unpack that a bit more, that would be great. I
want to be sure I understand. Thanks for the time investment in
reviewing and replying.
Thanks,
- --
Barry Hawkins
All Things Computed
site: www.alltc.com
weblog: www.yepthatsme.com
Registered Linux User #368650
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCa9BHHuKcDICy0QoRAka0AJ9hp3yX5kgPR0wkC2JnnT28QahG7QCeOpsl
ydm/mnA6dNSsqqLrbUC3NXs=
=V2jp
-----END PGP SIGNATURE-----
Reply to: