RFC: Arch Java Packaging Guidelines

cactus · 2005-06-12 02:38:10

I think this is the key issue with the java packaging guideline. I was under the impression that java apps were meant to be more or less standalone. Much like the applications in osX, everything in one file. Just drop in and go so to speak.

I have no clue how to reconcile what might be considered a more "classical" outlook on java packaging, with the present day...where java apps are using a ton of external libraries (which I think defeats the point of using java, but my opinion is not important in this regard).

I believe this is the key issue, and I also believe that I have no idea which side of the fence to fall on.

Dusty · 2005-06-12 03:45:25

I hate fences.

My reason for trying to divy up the jar files is that its like static linking, including them all in one place, what a waste.

I just realized something though; as javaws becomes more and more prevalent, maybe installing stuff like this won't happen so much. Javaws is unique in that it is truly dynamic linking; it downloads the latest version of the library from the network.

Perhaps rather than making a java packaging standard I should be figuring out how to javaws open source applications that I use regularly.

Dusty

chane · 2005-06-13 15:50:59

5. Other files distributed with the package should be stored in a directory named after the package under /usr/share. You may need to set the location of this directory in a variable like MYPROJ_HOME inside the shellscript.

This is a good idea for static files that are distributed with an application. Do you also invision newly created files going here also?

The one I'm thinking of is James http://james.apache.org which is an email server. Hence, where to store user mailboxes (not user in the I can log into the linux server sense; but user in the I have an email account that I access via POP/SMTP/IMAP sense).

Right now I bundle everything in /opt (which I might have to continue doing sense this application also includes a pretty hefty application server (Avalon). However, I'm asking because I'm not sure how I feel about storing user mailboxs in /usr/share......

Chris....

Dusty · 2005-06-13 16:00:38

chane wrote:

This is a good idea for static files that are distributed with an application. Do you also invision newly created files going here also?

Not really, as /usr may be mouted read only. I expected config type files to go in /etc. However, a mail server.... I guess it should probably go in /var?

Right now I bundle everything in /opt (which I might have to continue doing sense this application also includes a pretty hefty application server (Avalon).

Can avalon be incorporated into its own package?

Dusty

Dusty · 2005-06-13 16:21:26

I included some minor edits to try to account for these changes.

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

Dusty

chane · 2005-06-13 18:15:23

Dusty wrote:

Can avalon be incorporated into its own package?

That's a good question that I don't know the answer too since I have not tried to repackage James. I'm not sure it's really worth the effort since the project has been discontinued and I don't know of another application that uses Avalon (although I'm sure they exist). James will be eventually moving to a different framework than Avalon (as with all open source timing is unknown).

All the rest of the packages included with James though can probably we easily broken out.

Chris....

Dusty · 2005-06-15 15:57:37

Another Java question...

I packaged a few of the Jakarta Commons libs required by groovy as commons-cli, commons-logging, etc. I also packaged some other java libraries under rather generic names, asm, bsf, etc. I received an e-mail suggesting these be changed to something specifying they're Java based. It depends on the lib (ie: you wouldn't want to name a package java-junit, I don't think?), but do you think I should add a suggestion to the name that java libraries with generic names be prepended with the title 'java-', such as we do with python libs?

Dusty

cactus · 2005-06-15 17:26:47

Dusty wrote:

but do you think I should add a suggestion to the name that java libraries with generic names be prepended with the title 'java-', such as we do with python libs?

yes.

chane · 2005-06-15 17:55:57

Dusty wrote:

do you think I should add a suggestion to the name that java libraries with generic names be prepended with the title 'java-', such as we do with python libs?

Actually, no I wouldn't.

The files are stored in /usr/share/java right - which should be a huge giveaway that they are java files.

Second, I would append .jar to the filenames as that is common practice when creating java files....

....or rereading what you wrote, do you mean the package names? If that is what you meant I'm kinda torn. If you are packaging an application like Eclipse, what makes that different than Emacs (other than the language it is written in) - they are both editor (please no flames on the merits of one over the other).

Chris....

cactus · 2005-06-15 18:04:30

I was under the impression he meant package names, and I think he was referring to common names. Something like "network". You would want "java-network" as apposed to just "network". He did qualify his statement by meaning only generic names, so Eclipse would not fall under that, as it is not a generic name which could cause problems with other package names.

chane · 2005-06-15 18:20:14

yup I think your right and that is a good idea then.....need more sleep

Dusty · 2005-06-15 18:53:51

Yes, I did mean the package names.

Edit: I've updated the doc.

Dusty

Dusty · 2005-06-16 20:19:35

I haven't really made many changes, but here's my latest version:

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

The reason I post again is that I'm proposing this is the final version and I wanted final polish type feedback.

Dusty

arooaroo · 2005-06-16 20:42:10

Seems fine to me.

Dusty · 2005-06-18 17:55:57

Ok, there's some discussion on this on the tur-users mailing list. A lot of things are probalbly going to change. You can read about it in this thread:

http://www.archlinux.org/pipermail/tur- … 01145.html

Feel free to comment here if you like.

Dusty

Dusty · 2005-06-21 20:57:19

Yet another release based on the TUR discussion. This version has major changes. Its also shorter, simpler, and more flexible. Yay!

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

Dusty

Arch Linux

#26 2005-06-12 02:38:10

Re: RFC: Arch Java Packaging Guidelines

#27 2005-06-12 03:45:25

Re: RFC: Arch Java Packaging Guidelines

#28 2005-06-13 15:50:59

Re: RFC: Arch Java Packaging Guidelines

#29 2005-06-13 16:00:38

Re: RFC: Arch Java Packaging Guidelines

#30 2005-06-13 16:21:26

Re: RFC: Arch Java Packaging Guidelines

#31 2005-06-13 18:15:23

Re: RFC: Arch Java Packaging Guidelines

#32 2005-06-15 15:57:37

Re: RFC: Arch Java Packaging Guidelines

#33 2005-06-15 17:26:47

Re: RFC: Arch Java Packaging Guidelines

#34 2005-06-15 17:55:57

Re: RFC: Arch Java Packaging Guidelines

#35 2005-06-15 18:04:30

Re: RFC: Arch Java Packaging Guidelines

#36 2005-06-15 18:20:14

Re: RFC: Arch Java Packaging Guidelines

#37 2005-06-15 18:53:51

Re: RFC: Arch Java Packaging Guidelines

#38 2005-06-16 20:19:35

Re: RFC: Arch Java Packaging Guidelines

#39 2005-06-16 20:42:10

Re: RFC: Arch Java Packaging Guidelines

#40 2005-06-18 17:55:57

Re: RFC: Arch Java Packaging Guidelines

#41 2005-06-21 20:57:19

Re: RFC: Arch Java Packaging Guidelines

Board footer