[DONE] Suggested addition to Java Package Guidelines

In the Java Package Guidelines there are shell scripts that run the java jar or class file. Shouldn't the $@ be added as a parameter, to feed parameters to the java application?
For instance, I wrote the following for Logisim:
#!/bin/sh
"$JAVA_HOME/bin/java" -jar '/usr/share/java/logisim/logisim.jar' $@
Last edited by Marcel- (2014-04-11 10:32:43)

If you change that, I suggest to add an "exec", too. We don't need a useless shell in the background, right?
#!/bin/sh
exec "$JAVA_HOME/bin/java" -jar '/usr/share/java/logisim/logisim.jar' $@
Incidentally, I'm not sure what the current policy on hashbangs is (#!/usr/bin/sh?, indifference?).
I believe "/bin/sh" is required by POSIX and must provide a POSIX compliant shell, so /bin/sh is the portable hashbang. If you want bash, usr /usr/bin/bash I guess.
Last edited by progandy (2014-04-09 23:14:10)

Similar Messages

Perl packaging guidelines: request for a new official policy

feature request about this here: http://bugs.archlinux.org/task/18113
*edit*
Ok, the new version of pacpan is out: http://xyne.archlinux.ca/info/pacpan
It's only in my repo for now. I'll move this version to the AUR after some feedback.
After some initial debugging (if necessary), I would like to request that the official Perl packaging guidelines be changed to recommend using pacpan as a tool to aid packaging CPAN packages. In many cases it will provide a fully working PKGBUILD by default and in those cases when it doesn't, the provided PKGBUILD will be a very good starting point. It can also be used for comparison to existing PKGBUILDs.
Packagers will find the following functions useful (please see the info page for some output examples):
pacpan --get-pkgbuilds [pkgs]
This will print out default PKGBUILDs for the specified packages. Packages may be specified with the standard pacman package names (e.g. perl-foo-bar) or with the CPAN names (e.g. Foo-Bar for a distribution, Foo::Bar for a module). Pacpan will map modules to their distributions uniquely and thus prevent package conflicts when attempting to package different modules which are in the same distrbution.
It will also provide a comprehensive provides array which will ensure dependency resolution when dealing with dependencies specified in META.yml on CPAN.
Pacpan is also able to detect depends, makedepends and optdepends for CPAN packages.
Of course this depends on the presence and correctness of the META.yml file on CPAN, but this is present for (nearly?) all active distributions.
pacpan --check-local
This will inspect local perl packages and determine if local CPAN packages are named according to the packaging guidelines. It will also determine which modules a package provided by directly matching the files owned by the package according to pacman against the modules provided by those files, including version numbers where available. This will show packagers mistakes in the package and suggest changes to correct them. There is also a function for regular users to update the provides array of perl packages in the local database to ensure dependency resolution while waiting for packagers to correct their PKGBUILDs.
Last edited by Xyne (2010-02-01 22:35:47)

The reason to include modules in the provides array is to enable finer tuning of dependencies. If the modules within a distribution ever change, there would be no need to change the depends array of all packages which had specified that distribution instead of the modules that they actually depend on. It also makes searching easier as someone who is looking for the functionality of a particular module will be able to find it via a pacman search.
If that is really an issue, then it would be trivial to remove the provides from the PKGBUILDs that the code generates. If we could strictly enforce the packaging guidelines in the official repos and the AUR then I suppose it might make sense to ignore modules completely, but I don't see how it hurts to list them in the provides array.
With the current code that I have, I think I have full module-to-distribution resolution and all PKGBUILDs generated by the code for a requested package or module map to the corresponding distribution. The pacpan rewrite is complete and I'm working on plugging the backend into bauerbill right now to handle dependency resolution, installation and makedeps removal. I hope to release the code soon (maybe today, depending on how productive I am), at which point we can really get this discussion going with a feature request on the bug tracker.

Suggestions for substituting a package name that constantly changes

I work with an organization that constantly changes their package names. I am tired of going to each program and changing them on a whim. I wanted to know if there is a procedure for making package names replaceable. This would be mostly a preventive method used to avoid using "find and replace" in huge, enterprise projects.
For example, one day it is as follows:
package com.megacorp.myclass;
The next day I want it to be changed as follows:
package com.mymegacorp.myclass;
Maybe the approach I was looking for was something like a .properties file or context containing the package name and I would substitute it using a variable like the following:
package ${constantly.changing.megacorp.name}.myclass;
This example my not be clear. Feel free to swing away as I cry tears of BLooD. Any info or suggestions would be greatly appreciated though. Thanks.

Refactoring is definitely what this kind of thing would be called. What you suggested isn't supported in Java, so you'd have to use some third party preprocessor-like tool (I've never looked into this sort of thing, I don't know what's out there) to replace your placeholders. It would have to become part of your build process, and could possibly introduce new bugs to your code if it didn't work properly every time. That sounds a lot more dangerous and dependent than using Eclipse's (or whatever IDE you fancy) refactor function, which is dead simple, and only has to be done once each time the package names change, so you can refactor, test, and forget about it.

Towards an Arch OCAML packaging guidelines

I'm not an OCaml programmer so I'm posting a preliminary howto in the hopes folks will give input and we can put it up on the wiki. I think the lack of standardization (and packages in general) is quite sad and we should be able to rather effortlessly do better. Much of the following info I hijacked from the debian package guidelines.
* Bytecode executables should have "options=(!strip)", since we're x86 only we don't really have to worry about native code compiler availability.
* Libraries/bindings should be prefixed with ocaml-.
* Libraries should provide META files. Since these seem to differ across various distros it seems reasonable to try and support both fedora and debian if possible, otherwise it seems debian seems to have more force and should be a priority (also they have lots of prewritten META's to hijack). Since our findlib doesn't setup a META.x directory META files should be placed under `ocamlfind printconf destdir`/library-name and should be called META.
* I have found that -j1 is often needed, maybe we should note this as it's bitten me a few times.
I wish I could comment on documentation but I don't know anything about it. Input on this would be appreciated. I assume they have a tool like doxygen, haddock, javadoc, etc.
Please give suggestions! Thanks.
Follows is a more formalised wiki page, I stole some stuff from the lisp guidelines:
== Background ==
At the moment, there are relatively few ocaml packages available in the Arch repositories. This means that at some point or another, more will likely appear. It is useful, therefore, to figure out now, while there are few packages, how they should be packaged. Therefore, this page stands as a proposed packaging guideline for lisp packages. Keep in mind, however, that this is a work in progress; if you disagree with some of the ideas suggested here, feel free to edit the page and propose something better.
== Bytecode and Native code ==
If Bytecode is produced make sure to include "options=('!strip')".
Probably should give mention of something here. I'm not educated enough to comment but intuitively native would be the way to go.
== Findlib ==
Packagers are encouraged to create META packages if a library does not provide one. The Debian folks seem to have a good foundation to build on or provide. Compatibility with Debian should be an interest. Fedora also supplies META packages for various libraries which may differ from those supplied by Debian. It is sometimes possible to be compatible with both distributions and this is hence encouraged when sensible.
== Directory Structure ==
Given that our current findlib package does not setup a metadir META packages should be placed under `ocamlfind printconf destdir`.
Maybe a comment here about executables and/or documentation?
== Example PKGBUILD ==
<pre>
pkgname=ocaml-mysql
pkgver=1.0.4
pkgrel=1
license=('LGPL')
arch=('i686' 'x86_64')
pkgdesc="Objective Caml (OCaml) mysql library."
url="http://raevnos.pennmush.org/code/ocaml-mysql/"
depends=('ocaml' 'ocaml-findlib')
source=("http://raevnos.pennmush.org/code/ocaml-mysql/$pkgname-$pkgver.tar.gz")
md5sums=('76f1282bb7299012669bf40cde78216b')
install=ocaml-mysql.install
options=('!strip')
build() {
cd $srcdir/$pkgname-$pkgver
mkdir -p "$pkgdir/$(ocamlfind printconf destdir)"
mkdir -p "$pkgdir/$(ocamlfind printconf destdir)/stublibs"
./configure || return 1
make || return 1
make opt || return 1
env DESTDIR="$pkgdir" \
OCAMLFIND_DESTDIR="$pkgdir/$(ocamlfind printconf destdir)" \
make install || return 1
</pre>
== Things you, the reader, can do ==
* Maintain lisp packages following these guidelines
* Update and fix problems with these guidelines
* Keep up with what's changed here
* Provide (polite) thoughts, feedback, and suggestions both on this document and to people's work.
* Translate this page and future updates to this page.

Nice Work! One question: Can you explain what you expect from the mentioned meta-packages? Maybe it is obvious to a experienced ocaml programmer, but not to me.:)

Java packages ASAP

how do I add a java package so that when I do javac from any directory it can use the java package? Please help.

I think the answer is in the CLASSPATH environment variable.
If you use a win32 system you should add the path of the class to the CLASSPATH variable
Addition is done by putting a ';' and appending the path to the directory.
Hope this helps.

Problem with Java-Packages in JavaFX-Scripts

Hello!
What I'm trying to do is using a class I've built in my project in a JavaFX-Script, my problem is that the compiler keeps telling me my package wouldn't exist.
My filestructure is basically the following:
src
|-com.foo.java
|-- MyClass.java
|-com.foo.javafx
|-- MyFXScript.fx
I've tried importing the package or just writing the fully qualified classname when trying to create an instance, the messages didn't differ. I'm not at home right now so I don't remember the exact compiler-message, but it was something like "Package does not exist: com.foo.java".
Any ideas? :-)
Kind regards,
Joshua
Edited by: gnrx on Jan 12, 2009 5:55 AM

It works on my system.
MyClass.java
package com.foo.java;
public class MyClass {
    @Override
    public String toString() {
        return "My Class";
MyFXScript.fx
package com.foo.javafx;
import com.foo.java.*;
var myClass = new MyClass();
println(myClass);standard-run:
My Class
browser-run:
jws-run:
midp-run:
run:
BUILD SUCCESSFUL (total time: 3 seconds)

Problem finding native methods in java packages

Hi,
I have a java class which uses some native methods written in OCamL. I wrote a C file which calls the OCamL code, and created the corresponding shared library using the jni. I then tested my java file and everything works fine, I can nicely call the OCamL functions. However, I need this java file to be included in a package, but whenever I add the line:
package somepackage;
on top of the java code, my java file simply doesn't seem to find the C and OCamL implementation anymore :
javac -cp :./path/of/somepackage
-Djava.library.path=/full/path/of/somepackage MyProgram args
Exception in thread "main" java.lang.UnsatisfiedLinkError:functionName
at somepackage.ClassName.functionName(NativeMethod)
I have of course put everything (java, C, .h , libsomelibrary.so, and OCamL files) in a directory called somepackage, and written another java file which creates an instance of the first one from outside the package, imports the package, and calls its methods in main(). It just doesn't work anymore.
I then added a simple hello-world function (not C nor OCamL code) to the java file inside the package. And when invoked from outside, it worked. Question is then... Am I forgetting something to be done, in order to get C and CamL files efectively included in the java package (same as "package somepackage;" in C or OCaml, perhaps)??? Why isn't the java file able to find them inside its very own directory (having into account that without the package definition it worked well)?
Thanks,
PS Im using jsdk 1.4.1 on lunyx redhat 8.0

Did you change the name of the function in the library, too?
If the function name was
"Java_YourClass_functionname",
it should be now
"Java_path_to_your_package_YourClass_functionname".

Java package compile errors

I use a batch file to compile a java package. And I got the following errors:
TabPages: Java: 29: Cannot solve symbol
Symbol: class JSPFactory
Location: package JSP
JSPFactory = javax.Servlet.jsp.JSPFactory.getDefaulfFactory();
Note: Some input files use or override a deprecated APT.
Note: Recompile with -deprecation for details.
I am using New Atlanta servletExec 3.1 and IIS server. Can anyone help me figure our the above errors? Thanks!

if I add the "set classpath=".,C:/javax" to the begining of the batch file, will this override the classpath that I set in the Environment window? I am worried about this since we have a bunch of environment variables already been set there.
I tried to add the ";c:\javax" at the end of the classpath on my Environment window, and rebooted the server, but still got the same error message. Did I have some syntax error? What does the dot before ";C:/javax" mean? I deleted it when I added them to the classpath.
It will cause too much trouble to add the "javac XXX.java -classpath=".;C"/javax" to each file that needs this package because we don't have a single command for compiling a single java file. We have a huge amount of java files and we just use a single "javac -d" to compile every file under several folders. Our batch file is as follows:
del /F/Q ..\classes
javac -d ..\classes *.java htmltool\html\*.java ises\*.java DropDown\*.java frmselection\*.java grid\*.java treeView\*.java reportTreeMenu\*.java hs\types\*.java
del /F ..\lib\grid.jar
del /F ..\lib\TreeView.jar
cd ..\classes
jar cf ..\lib\grid.jar grid
rmdir /S/Q grid
jar cf ..\lib\TreeView.jar treeView
rmdir /S/Q treeView
cd ..\javasrc
Another thing is that: we have exact the same classpath and batch file on another server which works fine, and its classpath doesn't include explicitly stuff like";c:\javax", but we never have prolbem compiling the java source. So do I miss something else?

Java package inclusion

i have a java package,not built in but someone made it,now i need to use to calcualte some values.
this is the link of file i want to use,i dont know much about Java, can anyone please advise me how i can easily use this package in my java program? i dont know how it should appear in same class path.thanks

i been trying to read this and work it out, but dint
work,any chance anyone could check out this
http://www.jstott.me.uk/coord/ site and tell me how
it wold work pzzOn the very first page that you linked, in the very first paragraph under the examples section, is the following paragraph:
The coord-conv classes are very easy to use. Remember that the coord-conv.jar file should appear on your classpath before you can compile your code that uses it. Also remember that you have to import the package:
If you don't know how to add the coord-conv.jar to your classpath, re-read the following: Setting the class path. Pay particularly close attention to the end, where it says:
But when classes are stored in an archive file (a .zip or .jar file) the class path entry is the path to and including the .zip or .jar file. For example, to use a class library that is in a .jar file, the command would look something like this:C:> java -classpath C:\java\MyClasses\myclasses.jar utility.myapp.CoolYou would use a similar technique when compiling with javac. If these instructions are difficult to understand, take the time to go through a basic tutorial, such as what I posted earler: Essentials, Part 1, Lesson 1: Compiling & Running a Simple Program. You'll need to get at least some basic familiarity with the language before you begin programming in it.

Problem on how to create a .h file in a java package !!

Hello,
Please help me!! I have a problem generating a header file inside a java package. As I do not think eclipse IDE can do that, I then have to use the command as following in the command prompt instead.
D:\myJava\workspace\myJNI\bin>javah sysHookJNI/PollThread
javadoc: error -Illegal package name "sysHookJNI/PollThread"
sysHookJNI is my package name and PollThread is my class name. I think it should works because I compiled it with similar format as>java sysHookJNI/PollThread.java and it outputs the PollThread.class, but in fact it doesnot !>_<.
Can anyone suggest me what I should do?
Big thanks in advance,
Neth

Thank you so much !!
But after I got that point my old problem is still not solved with that. After my sysHookJNI.PollThread.h is generated, I compiled everything over and then run Test by
: java Test and the Exceptions are occurred as:
Exception in thread "Thread-0" java.lang.UnsatisfiedLinkError: sysHookJNI.PollThread.checkKeyboardChanges()V     at sysHookJNI.PollThread.checkKeyboardChanges(Native Method)
     at sysHookJNI.PollThread.run(PollThread.java:21)
And this is my PollThread.java (actually I took it from Jacob )
//PollThread.java
package sysHookJNI;
import java.io.*;
public class PollThread extends Thread
     public native void checkKeyboardChanges();
     private KeyboardHook kbh;
     public PollThread( KeyboardHook kh )
          kbh = kh;
          System.loadLibrary("syshook");
     public void run()
          for(;;)
               checkKeyboardChanges();
               yield();
     void Callback( boolean ts, int vk, boolean ap, boolean ek )
          KeyboardEvent event = new KeyboardEvent( this, ts, vk, ap, ek );
          if( ts )
               kbh.keyPressed( event );
          else
               kbh.keyReleased( event );
}Anyone has any suggestion about this problem? I really have no clue about it!! it keeps complains the same things no matter I regenerated header file or not.. T_T
Btw, shall I make a new post about this problem?
Thanks for your time,
Edited by: Nethie on Nov 1, 2009 2:37 PM

Properties files in a Java package not included in DC build

We are developing a Portal Standalone DC and i have a JspDynPage component within it. and i need to do internationalization in it. so as part of that i want to keep multiple resource bundles(properties) so that i could manage my properties files easily, For example
MSS.properties
MSS_es.properties
ESS.properties
LSO.properties
since portal by default has no way to do this bcos it allows only one resourcebundle to specify in portalapp.xml file, i have kept the resource bundles in java package like
com.companyname.portal.resources.
when i export from NWDS with selection of "i want to add non java resources into jar " option from windows->preferences->enterprise portal ->application development studio, it exports all the properties files as part of the par and everything works. but when i do the DC build it ignores all my properties files and it is not working. any suggestions on how to resolve this??? does SAP provide any other way of handling multiple properties files inside a PAR?????

We are using NWDS 2004 SP19. and yes i have defined three default SCs as dependencies. I tested with 2004s NWDS and it seems work fine. I am able to resovle this issue by moving my properties files into another java DC and create public part in java DC and use those public parts in Portal application DC.
So The problem of not including the properties files into Jar seems to be issue only in Portal Application DC not in Java DC. thanks everyone for the quick responses..

Free Java Packages

Hi,
This post might be a bit off topic, but I'll be glad if someone could help.
I am currently creating a GUI project using Swing. I wanted to know if I could get a list of some free Java packages that I could include in my project.
Eg. A voice recognition package that I can build my GUI around, etc.
A link to such a website with the packages would be very helpful.
Thanks

If you want voice recognition, I suggest you wait
about 5 years. Unless your users have to use this
system for some reason, they are more likely to find
a keyboard easier and less error prone.I used voice recognition about 10 years ago and if was possible to train it to recognice commands from a person. I used it to enable computers for people who coldn't operate normal input devices. Voice recognition is also use today by doctors to control operating equipment and by fighter pilots in situations you need both hands free.

Compiling java packages

I want to compile a complete java package from single command .
Say i hv package as following
javadir
javadir/a/b/*.java
javadir/c/*.java
javadir/a/d/*.java
i want to compile all these java files in one go without explicitly giving paths
any suggestions??

Duplicate post - make replies to
http://forum.java.sun.com/thread.jspa?threadID=584435&tstart=0

System.load(PATH_TO_LIB) issue inside java package

Hi all,
sorry if this has been asked somewhere, but I just could not find any answer of it. I simply want to load a library by using System.load(ABSOLUTE_PATH_TO_LIB) and call its native function. I could get this to work if I call this function in a class without having any package to it.
However, when I moved the class into a package, e.g. com.test package, I will get java.lang.UnsatisfiedLinkError exception. I am certain the System.load could still reference to the lib I pointed to, just that the library is not really loaded and resulting in this error when I call the native method. Any help would be greatly appreciated, thanks in advance.
Sudi

Hi, thanks for the reply.
I have found the problem, the problem was not in the System.load, as I mentioned earlier, I can load the library, but I got unsatisfied link error when I call the native function inside a java package.
The reason to this is the C native function actually does not allow me to call the function from a java package. If I want to call it from a package, then I have to regenerate the header file and the C source code, namely every functions gonna have the package name follow, e.g. au_com_siab_java_helloworld. something similiar to that. Too bad, this is an existing library that I am trying to use and I don't have the source code to change. Thanks all.

Debian type package guidelines for Arch.

Well, maybe not as anal or strick.
With the recent breed of Debian based distro's coming out (Ubuntu in particular) and with a Debian release just around the corner, there has been a lot of talk regarding this distro. So I decided to take a closer look in this flavour of Linux.
I myself coming from Slackware, have heard and used (very little) Debian before in the past decided to take a look at how far this distro has come since my first encounter with it.
Reading a lot of the Slashdot comments and Osnews comments I noticed that the hardcore/avid Debian users made a lot of good argument points regarding the "superiority" of there distro compared to the rest.
They argue the ease of Apt-get/dpkg and how powerful these tools are and how you only need to install Debian once. Especially now that the installer has been given a huge facelift, it is much easier to install Debian than previous versions.
Now none of that really sounds very enticing as Arch has Pacman, with Arch's rolling-release packaging scheme and the fact that I think the Arch installer is by far the fastest install I have ever done of a Linux system before, I see no reason to use Debian in place of Arch, at least not for what I use my system for.
But the one thing that stood out that made a lot of sense was the fact that Debian has a very strict packaging guideline. Things for menu's, config files and the works all had a standard place in a Debian system, making all of the packages very intergrated and work well together on the same system. Due to these guidelines, one can argue that the package quality for a .DEB, compared to most others is much higher. That is not to say it's perfect, as even on the "stable" branch there are packages that don't always work, but that is very rare.
What I'm getting to is I think that Arch should adopt something similar. I didn't really think it through to much as it is just an idea and I want to see what others think of this.
Basically there should be an offical set of documents that outline where configs go (/etc usually) where large packages go (in Arch /opt) and menu entries etc. This way new maintainers or people who would like to learn Arch's packaging system would know the "right way" for an Arch system, which would, in my opinion, skip a lot of the headaches of malfunctioning packages in the repos.
Another thing Debian has which is an okay idea is they have a system in place that checks the packages being submitted to the repos follow the guidelines and if the packages don't check out they are rejected, as to keep the system clean regarding standards.
Now the AUR (I forget what it's called) system being developed does what again? I only heard about it but didn't do enough digging to find out what its for exactly.
I don't know how to explain my idea exactly, but I thought I would throw it out there anyway and see what people have to say, if anything at all .

We have a not-all-that-strict guideline in the official documentation...
http://www.archlinux.org/docs/en/guide/ … guidelines
And we don't have things like menu specifications, because we haven't figured them out yet.
We also have namcap which checks for some packaging guideline checking in iit.
Most of the stuff you talked about is there, in the works, or being planned.

[DONE] Suggested addition to Java Package Guidelines

Similar Messages

Maybe you are looking for