RFC: Arch Java Packaging Guidelines

Dusty · 2005-06-05 22:07:13

I'm trying to work on standardizing the java packaging procedures. I've written a draft document outlining a standard that could be followed.

http://www.buchuki.com/misc/archjava.html

If anybody has any comments, ideas, or suggestions, let me know. The devs have already had a look at it and seem to be pleased.

Thanks,
Dusty

arooaroo · 2005-06-06 09:39:37

The only thing that sticks out here is for the situation where a Java app comes bundled with a local JRE. This is common for simplifying deployment and for eliminating with regression bugs from one version to the next.

I suggest the guidelines tackle this type of instance too.

iphitus · 2005-06-06 09:55:29

Aye, ive got a copy of novell's groupwise groupware and email client here, and it is able to be installed in /usr/ in /bin and /lib/. It includes its own jre but if you remove it, it will detect the system one. so theres kinda another exception to the rule....

Dusty · 2005-06-06 15:41:52

I thought I'd covered cases like these by saying something like "Certain very large packages will not fit into this scenario very well. As with other difficult packages in ArchLinux, these can be placed in /opt"

I am SURE I worte that somewhere, but I don't see it, lol. Thanks for bringing it up, I'll edit it when I get home.

Dusty

medicated · 2005-06-06 15:44:28

Gooood idea.

phrakture · 2005-06-06 15:47:50

not to "rock the boat" - but are the alot of java packages in arch currently? I don't usually notice when something is in java or python or something like that because they include nice shell wrappers....

arooaroo · 2005-06-06 15:57:57

Dusty wrote:

I thought I'd covered cases like these by saying something like "Certain very large packages will not fit into this scenario very well. As with other difficult packages in ArchLinux, these can be placed in /opt"
I am SURE I worte that somewhere, but I don't see it, lol. Thanks for bringing it up, I'll edit it when I get home.
Dusty

Some packages may not actually be large if it weren't for the bundling of the JRE. The issue is, should you recommend to packagers that they try and remove the reliance on the local JRE and rely on Arch's system-wide JRE? As I mentioned, local JREs are bundled for two reasons:

1) Simplify deployment, i.e., means client need worry about installing the JRE themselves.
2) Avoid regression bugs. This is where certain features of the Java platform work fine with say, 1.4.2, but not with 1.5.

If #1, then I say packager should attempt to remove reliance of local JRE. If #2, then they shouldn't. However, devs aren't normally overly-explicit in justifying their choice, and so it may not be obvious. Say the packager assumes #1, but it was in fact #1 & #2. Quick testing by the packager shows that the program *appears* to be running ok, but may in fact be prone to bugs when used properly.

It's a difficult issue.

Dusty · 2005-06-06 16:43:50

Phrakture: You're right, to the end user its transparent, but its making a mess of the filesystem. The problem is that all java programmers seem to want to make things easy for the end user by including all the dependency jars in their installer. Great! Only, when you do that with numerous open source programs, you end up with a lot of duplication. Take a look, for example, at ant and groovy, which both include junit, amoung other things. So does Eclipse and netbeans, come to think of it, and these include their own copies of ant!

Arooaroo: Can you tell me a specific package that includes the JRE? I know netbeans can, but they also have a package that doesn't include it, so that's the one that would be installed on Arch if there was an Arch package for it...

I will mention it... maybe I'll make an "exceptions" section.

Dusty

chane · 2005-06-06 17:28:24

One small item: I would recommend for popular dependency jars, including the major version number in the name. For example
- jakarata-commons-collections-2
- jakarata-commons-collections-3

or
- hibernate-2
- hibernate-3

since many apps could depend on one version or the other and usually within a major version the api's don't change such that a conflict is caused if the jar is upgraded from 2.1 to 2.2 during it's lifetime.

just my 2 cents. I like the idea of a standard packaging structure for java apps.....

Chris....

arooaroo · 2005-06-06 18:13:10

Dusty wrote:

Arooaroo: Can you tell me a specific package that includes the JRE? I know netbeans can, but they also have a package that doesn't include it, so that's the one that would be installed on Arch if there was an Arch package for it...
I will mention it... maybe I'll make an "exceptions" section.

I don't know of any open source Java apps. It's very common in the commerical world, like IDEA Intellij. However, it's always good to be aware of all the possiblities for this RFC.

Dusty · 2005-06-06 19:12:00

chane wrote:

One small item: I would recommend for popular dependency jars, including the major version number in the name. For example
- jakarata-commons-collections-2
- jakarata-commons-collections-3

I did make mention of it, but its not exactly sensible. How would you suggest I rewrite this section?:

archjava wrote:

Exceptions to this rule may be made (at the packager's discretion) if there appears to be a need to have two versions of a specific jar. Even in this case, they names should probably not be version specific, but something like myprog.jar and myprog2.jar.

BTW, I will be rewriting the second draft from scratch. My second drafts always make a lot more sense... ;-)

Dusty

chane · 2005-06-07 16:22:11

Dusty wrote:

chane wrote:
One small item: I would recommend for popular dependency jars, including the major version number in the name. For example
- jakarata-commons-collections-2
- jakarata-commons-collections-3
I did make mention of it, but its not exactly sensible. How would you suggest I rewrite this section?:
Dusty

That's a tough one. And it probably gets a it depends answer like the one you have in the document

archjava wrote:

Exceptions to this rule may be made (at the packager's discretion) if there appears to be a need to have two versions of a specific jar. Even in this case, they names should probably not be version specific, but something like myprog.jar and myprog2.jar.

I would advocate some type of "smart" numbering in the jar file so that one does not have to open the jar file to determine what version it contains. Also a lot of jar files do not contain enough information in the META file to determine what the version number is for the included classes. I usually discourage "smart" number but in this case I think it will make it a lot clearer when deciding which jar file to use when creating new packages and when reading the startup scripts.

I would encourage all dependency jar files to include some portion of the version number because you never know when an incompatible change is going to be made.

I would have the original packager include as little of the version number to uniquely identify the two (or more) packages. I mention that because I'm used to most projects only changing the API in a non-compatible way with major version numbers - but not all projects might feel that way...

Also, I agree that the "end" package (i.e., eclipse) doesn't need a version number.

This issue also means that packagers probably do not want to include all of the jars from /usr/share/java but rather want to list all of the specific jars to use. I realize that is in the doc already. Maybe the doc could be reformated to have a bulleted list (headings?) to clearly indicate the specific steps that need to be done to package. All of which are contained within the Arch Java Packaging section....

A second topic which doesn't really relate to this issue is how to deploy war items to tomcat. Or any other application server...maybe a seperate document....

Chris....

Dusty · 2005-06-08 03:13:40

I've rewritten the document from scratch including some of the suggestions here. Its shorter and more readable now. Let me know if I omitted anything... ;-)

Dusty

arooaroo · 2005-06-08 08:35:35

Dusty wrote:

Let me know if I omitted anything... ;-)

It's looks like you omitted everything! Clicking on the link gives a blank page.

Dusty · 2005-06-08 14:53:06

Oh dear, I seem to have killed it (does anybody know XHTML CPR?). I bet the copy on my machine is blank too, as I was moving old and new copies around. I'll look into it later.

Dusty

phrakture · 2005-06-08 15:07:12

arooaroo wrote:

Dusty wrote:
Let me know if I omitted anything... ;-)
It's looks like you omitted everything! Clicking on the link gives a blank page.

ahahahaha, that was nicely done!

Dusty, if you used vim, it backs-up files by default, he he he, so you could just grab "myfile~" he he he

Dusty · 2005-06-08 17:08:17

The problem was on my web server, apparently I filled the disk quota. Serves me right for cheaping out ($25 CAN per year) and then trying to store real programs and scripts there. ;-)

The page is back, I think, unless I uploaded the old version.

Dusty

Dusty · 2005-06-10 16:30:26

I was just thinking about something, I need some opinions.

In Arch packages, we say you gotta recompile from source to optimize for i686. However, with Java packages, bytecode is bytecode, to the best of my knowledge. So is there any reason not to download a binary instead of compiling from source when using Java packages?

The only reason I can think of against it is that if you compile a package with Java 5, you'll probably get a somewhat better optimization than if the site-distributed binary was compiled with Java 1.3 or 1.4.

The reason I ask is that I've been converting a few packages, and it seems like a lot of java developers don't really expect you to download the source unless you are going to work on the project. In other words, its not easy to just download and build like it is with most C packages. You end up with cruft, screwy build files, maven files, weird makefiles, etc.

So I was thinking, should I add a point to the system saying that if compiling from scratch is extremely difficult, it may be all right to use a distributed binary. However the preferred method is to compile all code from source?

Dusty

arooaroo · 2005-06-10 17:59:46

I'd say there's no advantage of recompiling the source. Stick with the binary classes and package them. The efficency gains are all in the JRE.

cactus · 2005-06-10 18:16:20

I would agree. One of the benefits of the Java architecture is "write once, hope it runs everywhere." Recompiling, I would think, defeats one of the major gains had by using java.

This presupposes that you are using the Java JVM though. If you are using another JVM, then you would probably want to recompile. Similarly if you were trying to make extensive use of gcj, then of course compiling would be necessary.

So, I guess it would probably be safe to say that recompiling is not necessary, unless you are dealing with one of those edge cases.

Dusty · 2005-06-10 18:48:03

oh good, I was actually expecting opposition on this point. :-)

Dusty

arooaroo · 2005-06-10 18:55:07

Well, at least you weren't disappointed then

Dusty · 2005-06-10 18:57:14

hmmm? No, I don't like recompiling and rebuilding jar files... I just expected others to prefer it, since that's what we do with AL.

Dusty

Dusty · 2005-06-10 21:01:10

Updated to include the no rebuild clause, first step...

http://www.buchuki.com/misc/archjava.html

Dusty

Dusty · 2005-06-12 00:07:28

Ok, I have another question...

lets say the dudes that built the program included some other libraries, but rather than including outside jars, they unjarred them and included them with their main jar file. JEdit does this, including files from asm, gnu regexp, and some others.

My problem is, do we remove these and depend on the original jars or not? The reason its a sticky issue is that there is every possibility that they hacked the files they are including. In JEdit's case, maybe they made a change to the asm or regexp classes. Without getting intimate with the source, I can't know for sure...

I should add a guideline for this case... laziness is saying leave the packed files in place, they aren't hurting anybody, but perfectionism is saying it would follow the guidelines better if they were removed to their own packages.

What do people think?

Dusty

Arch Linux

#1 2005-06-05 22:07:13

RFC: Arch Java Packaging Guidelines

#2 2005-06-06 09:39:37

Re: RFC: Arch Java Packaging Guidelines

#3 2005-06-06 09:55:29

Re: RFC: Arch Java Packaging Guidelines

#4 2005-06-06 15:41:52

Re: RFC: Arch Java Packaging Guidelines

#5 2005-06-06 15:44:28

Re: RFC: Arch Java Packaging Guidelines

#6 2005-06-06 15:47:50

Re: RFC: Arch Java Packaging Guidelines

#7 2005-06-06 15:57:57

Re: RFC: Arch Java Packaging Guidelines

#8 2005-06-06 16:43:50

Re: RFC: Arch Java Packaging Guidelines

#9 2005-06-06 17:28:24

Re: RFC: Arch Java Packaging Guidelines

#10 2005-06-06 18:13:10

Re: RFC: Arch Java Packaging Guidelines

#11 2005-06-06 19:12:00

Re: RFC: Arch Java Packaging Guidelines

#12 2005-06-07 16:22:11

Re: RFC: Arch Java Packaging Guidelines

#13 2005-06-08 03:13:40

Re: RFC: Arch Java Packaging Guidelines

#14 2005-06-08 08:35:35

Re: RFC: Arch Java Packaging Guidelines

#15 2005-06-08 14:53:06

Re: RFC: Arch Java Packaging Guidelines

#16 2005-06-08 15:07:12

Re: RFC: Arch Java Packaging Guidelines

#17 2005-06-08 17:08:17

Re: RFC: Arch Java Packaging Guidelines

#18 2005-06-10 16:30:26

Re: RFC: Arch Java Packaging Guidelines

#19 2005-06-10 17:59:46

Re: RFC: Arch Java Packaging Guidelines

#20 2005-06-10 18:16:20

Re: RFC: Arch Java Packaging Guidelines

#21 2005-06-10 18:48:03

Re: RFC: Arch Java Packaging Guidelines

#22 2005-06-10 18:55:07

Re: RFC: Arch Java Packaging Guidelines

#23 2005-06-10 18:57:14

Re: RFC: Arch Java Packaging Guidelines

#24 2005-06-10 21:01:10

Re: RFC: Arch Java Packaging Guidelines

#25 2005-06-12 00:07:28

Re: RFC: Arch Java Packaging Guidelines

Board footer