Policy change proposal, Re: Bug#176628: sablevm: package incorrctly provides java1-runtime
Hi On Tue, Jan 14, 2003 at 11:04:22AM +0100, Grzegorz B. Prokopski wrote: > retitle 176628 java.awt.* classess don't work as expected for > java1-runtime > thanks > > W li?cie z pon, 13-01-2003, godz. 18:26, Stephen Zander pisze: > > Package: sablevm > > Version: 1.0.5-1 > > Severity: important > > > > According to the Java policy, packages that provide java1-runtime must > > support the the complete java runtime environment. As sablevm fails > > to provide working java.awt.* classes, the provides on this package is > > incorrect. Please remove it until such time as sablevm has working > > support for java.awt.*. > > I searched for "runtime" in Java Policy (as found in java-common > package) and couldn't find such explict statment. "Java virtual machines must provide java-virtual-machine and depend on java-common. They can also provide the runtime environment that the package contains (java1-runtime and/or java2-runtime). If it does not provide the files itself it must depend on the needed runtime environment." So the policy is a bit vauge. I suggest that we change it to the following: "Java virtual machines must provide java-virtual-machine and depend on java-common. They may also provide a runtime environment (java1-runtime and/or java2-runtime) if it contains the complete set of runtime files. If it does not provide the files itself it must depend on the needed runtime environment." > But even if it were there - I *refuse* to remove this Provides: because > Sablevm _does_ provide java1 runtime env. with the expeption of things > which don't work yet. *These things* I belive can be easily called bugs > for simplicity. > > Severity "important" seems to be the right one here: > "important - a bug which has a major effect on the usability of a > package, without rendering it completely unusable to everyone" > > We all know that the fight for free Java (tfffj) is only beginning. > And I don't think we would support free java and free software by > marking every of today's free JVMs and their classlibs as unusable > because of some lacks or bugs. Especially when there's effort under > way to remove them. > > The Java Policy is to help us, to support us and to guide us. Agreed. But in some cases it is good that it forbid some things. In this case it is probably ok to keep the provide line, but only if you can see fixes to the bugs in the (near?) future. If not you should drop it and wait until it is (at least about to) be fixed. > The Java Policy is for us, not the other way. Agreed too. It is for us, not a specific person. Regards, // Ola > Kind regards > > Grzegorz B. Prokopski > -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy change proposal, Re: Bug#176628: sablevm: packageincorrctly provides java1-runtime
W liście z nie, 19-01-2003, godz. 17:23, Ola Lundqvist pisze: > Hi > > On Tue, Jan 14, 2003 at 11:04:22AM +0100, Grzegorz B. Prokopski wrote: > > retitle 176628 java.awt.* classess don't work as expected for > > java1-runtime > > thanks > > > > W li?cie z pon, 13-01-2003, godz. 18:26, Stephen Zander pisze: > > > Package: sablevm > > > Version: 1.0.5-1 > > > Severity: important > > > > > > According to the Java policy, packages that provide java1-runtime must > > > support the the complete java runtime environment. As sablevm fails > > > to provide working java.awt.* classes, the provides on this package is > > > incorrect. Please remove it until such time as sablevm has working > > > support for java.awt.*. > > > > I searched for "runtime" in Java Policy (as found in java-common > > package) and couldn't find such explict statment. I meant statment that says that it MUST provide such and such features to be allowed to provide java-virtual-machine. > "Java virtual machines must provide java-virtual-machine and depend on java-common. > They can also provide the runtime environment that the package contains > (java1-runtime and/or java2-runtime). If it does not provide the files itself it > must depend on the needed runtime environment." > > So the policy is a bit vauge. I suggest that we change it to the following: > > "Java virtual machines must provide java-virtual-machine and depend on java-common. > They may also provide a runtime environment (java1-runtime and/or java2-runtime) > if it contains the complete set of runtime files. If it does not provide the files > itself it must depend on the needed runtime environment." I personally wouldn't do random changes here and there in the policy. I don't know what is "complete set of runtime files". You either gonna explain this further or you'd better give it up. And I doubt that if you say that I should just conform to some Sun Java standard - _any_ of free JVMs (and especially their classlib) actually does it right. Personally I find Java Policy good enough and I don't see any benefit from such changes. _Everybody_ know that free JVMs are not perfect. > > The Java Policy is to help us, to support us and to guide us. > > Agreed. But in some cases it is good that it forbid some things. In this > case it is probably ok to keep the provide line, but only if you can see > fixes to the bugs in the (near?) future. If not you should drop it and > wait until it is (at least about to) be fixed. I'd just say that SableVM is actively maintained and the things will be fixed one by one. But - as it is the rule for almost every free software - it will take time. I don't think that putting more LAW into the mix will gain us anything. If your app doesn't work with some JVM - file a bug and either help fixing it or wait for a fix or switch to another JVM if there's any legaly working alternative. > > The Java Policy is for us, not the other way. > Agreed too. It is for us, not a specific person. You mean it's not for _me_? :-/ Let's give it up. In Poland we have a say like that: "A cup of tee doesn't get sweeter by stiring [mixing]" (which means that you can't do much w/o sugar) Best regards Grzegorz B. Prokopski -- Grzegorz B. Prokopski <[EMAIL PROTECTED]> Debian http://www.debian.org/ signature.asc Description: PGP signature
Re: Policy change proposal, Re: Bug#176628: sablevm: package incorrctly provides java1-runtime
Hello On Sun, Jan 19, 2003 at 08:03:56PM +0100, Grzegorz B. Prokopski wrote: > W li?cie z nie, 19-01-2003, godz. 17:23, Ola Lundqvist pisze: *SNIP* > > > > > > I searched for "runtime" in Java Policy (as found in java-common > > > package) and couldn't find such explict statment. > I meant statment that says that it MUST provide such and such features > to be allowed to provide java-virtual-machine. I understood that. > > "Java virtual machines must provide java-virtual-machine and depend on >java-common. > > They can also provide the runtime environment that the package contains > > (java1-runtime and/or java2-runtime). If it does not provide the files itself it > > must depend on the needed runtime environment." > > > > So the policy is a bit vauge. I suggest that we change it to the following: > > > > "Java virtual machines must provide java-virtual-machine and depend on >java-common. > > They may also provide a runtime environment (java1-runtime and/or java2-runtime) > > if it contains the complete set of runtime files. If it does not provide the files > > itself it must depend on the needed runtime environment." > I personally wouldn't do random changes here and there in the policy. Well these are not random changes. As you might have noted I'm the one that is responsible for the writing of this policy. That is why I can tell that it is a bit vauge. The reason is that what you missed is what I intended to write (but failed to clarify) in the current policy. But right now the policy has been somewhat accepted as a normal Debian policy I have to make proposals as everybody else. If there becomes a consensus about that this is a good thing, I'll update the policy as normal. Should I see your mail here as an objection, or do you have a second alternative? > I don't know what is "complete set of runtime files". You either gonna > explain this further or you'd better give it up. And I doubt that if If so, We'll have to define it. > you say that I should just conform to some Sun Java standard - _any_ > of free JVMs (and especially their classlib) actually does it right. If you have better definitions on how to define java1-runtime and/or java2-runtime, I'm grateful for such propositions. > Personally I find Java Policy good enough and I don't see any benefit > from such changes. _Everybody_ know that free JVMs are not perfect. Yes, I know that free JVMs are not perfect too. Actually sun/ibm etc ones is not perfect either. They are sometimes buggy, incomplete, etc. I do not say that you should not provide java1-runtime. What I say is that the package should not provide things if it can not satisfy the requirements, at least in the (near?) future. If sablewm is, say 99% (or less I do not really know) complete then this is ok. But if it is just, say 80% complete... then no. I'm not able to tell exact requirements right now and therefore I want to discuss this politely on this list. > > > The Java Policy is to help us, to support us and to guide us. > > > > Agreed. But in some cases it is good that it forbid some things. In this > > case it is probably ok to keep the provide line, but only if you can see > > fixes to the bugs in the (near?) future. If not you should drop it and > > wait until it is (at least about to) be fixed. > I'd just say that SableVM is actively maintained and the things will > be fixed one by one. But - as it is the rule for almost every free > software - it will take time. I sure know that. > I don't think that putting more LAW into the mix will gain us anything. > If your app doesn't work with some JVM - file a bug and either help > fixing it or wait for a fix or switch to another JVM if there's any > legaly working alternative. > > > > The Java Policy is for us, not the other way. > > Agreed too. It is for us, not a specific person. > You mean it's not for _me_? :-/ The policy is here to define good common practice. I think that if someone tells that they provide things, without actually doing it, that can be seen as a bug. > Let's give it up. I intend to have a clear and precise policy. It is not really clear in all aspects right now which you pointed out (even if not intentional). That is why I want to make this proposal. Best regards, // Ola > In Poland we have a say like that: > "A cup of tee doesn't get sweeter by stiring [mixing]" > (which means that you can't do much w/o sugar) > > Best regards > > Grzegorz B. Prokopski > -- > Grzegorz B. Prokopski <[EMAIL PROTECTED]> > Debian http://www.debian.org/ -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --
Re: Policy change proposal - JVMs Provides: requirements
Hi! I know you're the person who maitains java-common, Java Policy and I really admire your work you do in that area. In my initial mail I already proposed that "not meeting the criteria" is just a bug, maybe even RC in some cases. I don't know what 99% or what 80% is. Fact is that aside of Kaffe, the other free JVMs use indirectly (like gcj) or directly one single source of it's classpath lisbrary - GNU Classpath. I really doubt if this project has reached 80% of what java 1.2 (especially in the area of graphical interfaces) should be. I think that *I* would use GNU Classpath as the 100% here (then we can have JVMs that support more than 100% ;-). But I don't really expect you to write it down to the policy. About SableVM - I can only say that currently SableVM is not able to use all of the features of GNU Classpath. But OTOH I am sure it will get better. It's being worked on. But getting back to the topic. You can treat my mail as an objection because it's still not really clear what the proposed change in Java Policy would gain us. It's still vague. It seem to need more detailed description or no changes at all. I'd agree to discuss it... probably on d-java? - yes. As for my proposals, I think I'd do it this way: 1. Define exactly what requirements must be met for JVM to be able to _legally_ provide java-virtual-machine, java*-runtime etc. 2. Just file bugs on JVM when the program you want to run - doesn't work. As usual. Nothing new. The bug will either get fixed or not. The only question is whether it's RC (or a set of bugs can be treated as RC) or not. That's sth. we *could* clarify. One question that is bugging me all the time and I am really curious what's the correct answer: Do we actually have a problem? Will having exact policy in this area gain us anything? (Read: Do we rally want our free JVMs to be either kept out of testing or kept w/o Provides: that can bring them to real live in many uses?) Regards Grzegorz B. Prokopski PS: I'll wait to see what other have to say on that topic. -- Grzegorz B. Prokopski <[EMAIL PROTECTED]> Debian http://www.debian.org/ signature.asc Description: PGP signature
Re: Policy change proposal - JVMs Provides: requirements
On Sun, Jan 19, 2003 at 10:22:23PM +0100, Grzegorz B. Prokopski wrote: > Hi! Hi again. > > > I know you're the person who maitains java-common, Java Policy > and I really admire your work you do in that area. Thanks a lot! I appriciate it. > In my initial mail I already proposed that "not meeting the criteria" > is just a bug, maybe even RC in some cases. Hmm ... I thought you objected that it can be RC. If so then we are telling the same things but in different ways. :) > I don't know what 99% or what 80% is. Fact is that aside of Kaffe, > the other free JVMs use indirectly (like gcj) or directly one single > source of it's classpath lisbrary - GNU Classpath. I really doubt if this > project has reached 80% of what java 1.2 (especially in the area of > graphical interfaces) should be. I think that *I* would use GNU > Classpath as the 100% here (then we can have JVMs that support more > than 100% ;-). But I don't really expect you to write it down to > the policy. Hmm. It it that bad. I was not aware of that actually. In some way we have to define java1-runtime in a good way. Define it against a moving target (like classpath) might not be a good thing. On the other hand it might be the best way... > About SableVM - I can only say that currently SableVM is not able to use > all of the features of GNU Classpath. But OTOH I am sure it will get > better. It's being worked on. And I forgot to tell that I admire everyone that are working to make a free alternative. I'm sure it will be better. > But getting back to the topic. > You can treat my mail as an objection because it's still not really > clear what the proposed change in Java Policy would gain us. Ok. It is a good point. > It's still vague. It seem to need more detailed description or no > changes at all. I'd agree to discuss it... probably on d-java? - yes. Let's continue on debian-java, then. > As for my proposals, I think I'd do it this way: > 1. Define exactly what requirements must be met for JVM to be able > to _legally_ provide java-virtual-machine, java*-runtime etc. Then we can agree on that. The problem is to define it... :( > 2. Just file bugs on JVM when the program you want to run - doesn't > work. As usual. Nothing new. The bug will either get fixed or not. No nothing new. > The only question is whether it's RC (or a set of bugs can be > treated as RC) or not. That's sth. we *could* clarify. Yes that has to be clarified. > One question that is bugging me all the time and I am really curious > what's the correct answer: > > Do we actually have a problem? Good question! :) > Will having exact policy in this area gain us anything? Yes I actually think so. The thing we gain is that users can be less confused. If they apt-get things, they tend to think that things should work. If they by (mistake?) got another virtual-machine for their java app they can be pretty disapointed. I become that from time to time... :) This gain nothing to us, but something to the end user. > (Read: Do we rally want our free JVMs to be either kept out of testing > or kept w/o Provides: that can bring them to real live in many uses?) Well actually I do not think it is a good thing to release with a provides line that is not really functional. But I can also accept the other posistion, that says that this is better than non-free alternatives. I agree on both and I'm no longer so sure about this. What do other people think about this issue? Best regards, // Ola > Regards > > Grzegorz B. Prokopski > > PS: I'll wait to see what other have to say on that topic. > > -- > Grzegorz B. Prokopski <[EMAIL PROTECTED]> > Debian http://www.debian.org/ -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy change proposal - JVMs Provides: requirements
--- Ola Lundqvist <[EMAIL PROTECTED]> wrote: > On Sun, Jan 19, 2003 at 10:22:23PM +0100, Grzegorz > B. Prokopski wrote: > > I don't know what 99% or what 80% is. Fact is that > aside of Kaffe, > > the other free JVMs use indirectly (like gcj) or > directly one single > > source of it's classpath lisbrary - GNU Classpath. > I really doubt if this > > project has reached 80% of what java 1.2 > (especially in the area of > > graphical interfaces) should be. I think that *I* > would use GNU > > Classpath as the 100% here (then we can have JVMs > that support more > > than 100% ;-). But I don't really expect you to > write it down to > > the policy. > > Hmm. It it that bad. I was not aware of that > actually. In some way > we have to define java1-runtime in a good way. > Define it against > a moving target (like classpath) might not be a good > thing. On the > other hand it might be the best way... Well, seems like you guys are looking for some numbers ;) Check the japitools JDK API compatibility pages at http://rainbow.netreach.net/~sballard/japi/ > > As for my proposals, I think I'd do it this way: > > 1. Define exactly what requirements must be met > for JVM to be able > > to _legally_ provide java-virtual-machine, > java*-runtime etc. > > Then we can agree on that. The problem is to define > it... :( I don't understand the term 'legally' in this context. What legal requirements are there? best regards, dalibor topic __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy change proposal - JVMs Provides: requirements
W liście z nie, 19-01-2003, godz. 23:17, Dalibor Topic pisze: > --- Ola Lundqvist <[EMAIL PROTECTED]> wrote: > > On Sun, Jan 19, 2003 at 10:22:23PM +0100, Grzegorz > > B. Prokopski wrote: > > > > I don't know what 99% or what 80% is. Fact is that > > aside of Kaffe, > > > the other free JVMs use indirectly (like gcj) or > > directly one single > > > source of it's classpath lisbrary - GNU Classpath. > > I really doubt if this > > > project has reached 80% of what java 1.2 > > (especially in the area of > > > graphical interfaces) should be. I think that *I* > > would use GNU > > > Classpath as the 100% here (then we can have JVMs > > that support more > > > than 100% ;-). But I don't really expect you to > > write it down to > > > the policy. > > > > Hmm. It it that bad. I was not aware of that > > actually. In some way > > we have to define java1-runtime in a good way. > > Define it against > > a moving target (like classpath) might not be a good > > thing. On the > > other hand it might be the best way... > > Well, seems like you guys are looking for some numbers > ;) Check the japitools JDK API compatibility pages at > http://rainbow.netreach.net/~sballard/japi/ Thanks for the link. However in this case the APIs are compared, not if they really work. There's a lot of stubs in GNU Classpath, so I doubt if this comparison method is sutiable for our purpose. Every JVM that uses GNU Classpath would get same results. It's comparison of classpaths not JVMs. > > > As for my proposals, I think I'd do it this way: > > > 1. Define exactly what requirements must be met > > for JVM to be able > > > to _legally_ provide java-virtual-machine, > > java*-runtime etc. > > > > Then we can agree on that. The problem is to define > > it... :( > > I don't understand the term 'legally' in this context. > What legal requirements are there? Legally - after meeting the (future, planned) requirements of Java Policy for the JVMs that want to have such Provides:. Regards Grzegorz B. Prokopski -- Grzegorz B. Prokopski <[EMAIL PROTECTED]> Debian http://www.debian.org/ signature.asc Description: PGP signature
Re: JAVA_HOME policy
On 10 Jan 2003, Joe Phillips wrote: > #2 is a bit trickier. tools.jar is needed in some cases, most notably > servlet/jsp containers need it in order to compile JSP at runtime. My > JBOSS packages fall into this category. tools.jar is installed > somewhere under JAVA_HOME, JBOSS needs tools.jar and so needs JAVA_HOME. Technically, no. Only the web container needs tools.jar. Not jboss. When jboss-catalina or jboss-jetty get installed, they should be the ones that go looking for tools.jar, and add it to jboss' deploy dirs(or to their own internal classpath). JBoss itself shouldn't do this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
request feedback on JBOSS debs
On Fri, 2003-01-17 at 22:28, Andrew Savory wrote: > On Tue, 14 Jan 2003, Joe Phillips wrote: > > > I spent yesterday rebuilding and testing my debs. The versions > > currently on my company site[1] have been tested to properly start/stop > > the server without exceptions. > > Just been trying the debs out (apt-get install jboss jboss-doc), and came > across the following problems: I'm glad to see interest. I'm also glad to get feedback. I'm assuming the above are the only packages you installed (jboss and jboss-doc) - you're definitely missing some files then. It would explain bad permissions and missing files as you found... > log4j:ERROR setFile(null,false) call failed. > java.io.FileNotFoundException: /usr/share/jboss/server/default/log/boot.log > (Permission denied) > > (Fixed by chown -R jboss /usr/share/jboss) Actually, not fixed by that command. /usr/share/jboss/server/default is not found in jboss or jboss-doc packages. > org.jboss.deployment.DeploymentException: url > file:/usr/share/jboss/server/default/conf/jboss-service.xml could not be > opened, does it exist? > > (Fixed by apt-get install jboss-server-all, then editing > /etc/default/jboss and setting which server to start to "all") See above comment. > After all that, there's still no sign of life from JBoss on 8080 or > 8082... :-( I expect that you would see jboss on 8080 after installing jboss-server-all and editing /etc/default/jboss. You didn't mention but I hope you set your JAVA_HOME properly within /etc/default/jboss? This is likely to be a long email so bear with me... I just now installed my packages on my laptop, a machine on which I have never installed these packages. Here's what I did (kindof following your general steps) to get jboss up on 8080. 1- apt-get install jboss-server-all this brings in jboss, libjboss3-java, libjboss3-client-java, jboss-tomcat 2- edit /etc/default/jboss - set JAVA_HOME to my j2sdk 1.4.1 installation - set server to 'all' - enabled (uncommented) console output to /var/log/jboss/console.log 3- start jboss with /etc/init.d/jboss start waited until I saw the following in /var/log/jboss/console.log... 23:42:25,611 INFO [Server] JBoss (MX MicroKernel) [3.0.2 Date:200209111840] Started in 0m:51s:521ms 4- hit http://localhost:8080/jmx-console with my browser My system is Debian stable with Ximian GNOME packages, custom 2.4.18 kernel package, and custom Sun j2sdk-1.4.1 packages. I'm going to cover details on how the packages are put together and what motivated my decisions, I'm happy to take comments and feedback. I'm also assuming the reader has some experience installing and running JBOSS from a binary distribution. The thing to note here is that the 'jboss' package isn't the full JBOSS and neither is 'jboss-server-all'. In order to get the *whole* JBOSS as distributed on sourceforge, with minor changes, you need to install all the jboss-server-X packages (where X is all, default and minimal). Each is installed under a /usr/share/jboss/server/X directory. This is how a JBOSS zip/tarball installs by default. Unfortunately, I can see where 'jboss-server-all' would be confusing. Generally, you would only want one of those packages. By default, the packages come configured to attempt to run the 'default' server. You saw this in your error messages. This is also why installing jboss-server-all (and not changing /etc/default/jboss) doesn't fix the errors you saw. Each of the jboss-server-X packages' postinstall scripts takes care of properly setting ownership and permissions on /usr/share/jboss/server/X files. Also, some of the directories or files under /usr/share/jboss/server/X are symlinks to more Debianized locations (eg /var/log/jboss/X or /etc/jboss/X) to be more in line with Debian policy. It comes down to, in general, you want jboss-server-minimal, jboss-server-default or jboss-server-all installed. /etc/default/jboss needs to have the server set appropriately to match which server you wish to run. My jboss package recommends one of the above three packages but apt-get won't force you to install a recommended package. I chose not to depend on the server packages because you *can* use jboss without them, if you build your own jboss-server equivalent package. In fact, this is what my company is doing in production. We have a jboss-server-isg package which is essentially a tweaked jboss-server-default. Our custom server package installs under /usr/share/jboss/server/isg/ and requires us to set JBOSS_SERVER=isg in /etc/default/jboss. Originally, I considered creating a single server directory, say /usr/share/jboss/server/default/ removing the all and minimal directories. I figured all jboss-server-X packages could install there, with minimal being a subset of default being a subset of all. I'm not so sure they're strictly subsets though. I also figured that developers familiar with the three servers in jboss alre
Re: JBoss debs?
On Sat, 11 Jan 2003, Greg Wilkins wrote: > + lobby the JBoss project to make any changes that may > assist you with your packaging (not sure of how successful > that will be). Good fucking luck. JBoss upstream has been resistant to any suggestions on how they package their dependants.
Re: JBoss debs?
On 10 Jan 2003, Joe Phillips wrote: > how's very soon? > > you can find my packages for 3.0.2 + tomcat at > http://debian.innovationsw.com/ > > I have plans for 3.2 next. I have jboss debs of 2.4(upto 2.4.7). All properly split. Depends on other java debs in debian(where I can). All non-free and non-packaged stuff is in jboss-contrib. Has a dh_jboss, for those building jboss-using debs. Splits the config files into fragments, that get automatically rebuilt into full files whenever a jboss using deb is installed. I had this all working last december. Unfortunately, 3.0 was a radical change, config wise, so I haven't been able to make 3.0 debs yet. -- [EMAIL PROTECTED]:~/brainfood/jboss/debian$ grep ^Package jboss-2.4.7/debian/control Package: jboss Package: jboss-server Package: jboss-transaction Package: jboss-catalina-service Package: jboss-client Package: jboss-admin Package: jboss-common Package: jnp-server Package: jnp-client Package: jbossmq Package: jbossmq-client Package: jbosssx Package: jbosssx-client Package: jboss-contrib-hsqldb Package: jboss-contrib-oswego Package: jboss-contrib-tyrex Package: jboss-contrib-castor Package: jboss-contrib Package: jboss-dev Package: jboss-docs Package: jboss-jdbc-postgresql Package: jboss-jdbc-mysql Package: jboss-mail
Re: JBoss debs?
On Sun, 2003-01-19 at 01:42, Adam Heath wrote: > On 10 Jan 2003, Joe Phillips wrote: > > > how's very soon? > > > > you can find my packages for 3.0.2 + tomcat at > > http://debian.innovationsw.com/ > > > > I have plans for 3.2 next. > > I have jboss debs of 2.4(upto 2.4.7). All properly split. Depends on other > java debs in debian(where I can). All non-free and non-packaged stuff is in > jboss-contrib. Has a dh_jboss, for those building jboss-using debs. Splits > the config files into fragments, that get automatically rebuilt into full > files whenever a jboss using deb is installed. Yeah...I downloaded your sources at one point. Still need to read through your work. My packages are completely my own mess. > Unfortunately, 3.0 was a radical change, config wise, so I haven't been able > to make 3.0 debs yet. Well I'd be happy to take comments and or work with you in improving my 3.x series of packages. By now you should have seen my long email discussing some of the problems I'm seeing. I'd like to hear your suggestions. Right now, I don't expect to see a whole lot of help from upstream in 'fixing' their distro. We'll see what happens with time. -joe -- Innovation Software Group, LLC - http://www.innovationsw.com/ Business Automation Specialists UNIX, Linux and Java Training
Re: JBoss debs?
On 19 Jan 2003, Joe Phillips wrote: > Yeah...I downloaded your sources at one point. Still need to read > through your work. My packages are completely my own mess. > > > Unfortunately, 3.0 was a radical change, config wise, so I haven't been able > > to make 3.0 debs yet. > > Well I'd be happy to take comments and or work with you in improving my > 3.x series of packages. I might be able to convince my boss to doing more work on them. > By now you should have seen my long email discussing some of the > problems I'm seeing. I'd like to hear your suggestions. I had, but hadn't read it. I'll get a reply back to you tomorrow, most likely.
Policy change proposal, Re: Bug#176628: sablevm: package incorrctly provides java1-runtime
Hi On Tue, Jan 14, 2003 at 11:04:22AM +0100, Grzegorz B. Prokopski wrote: > retitle 176628 java.awt.* classess don't work as expected for > java1-runtime > thanks > > W li?cie z pon, 13-01-2003, godz. 18:26, Stephen Zander pisze: > > Package: sablevm > > Version: 1.0.5-1 > > Severity: important > > > > According to the Java policy, packages that provide java1-runtime must > > support the the complete java runtime environment. As sablevm fails > > to provide working java.awt.* classes, the provides on this package is > > incorrect. Please remove it until such time as sablevm has working > > support for java.awt.*. > > I searched for "runtime" in Java Policy (as found in java-common > package) and couldn't find such explict statment. "Java virtual machines must provide java-virtual-machine and depend on java-common. They can also provide the runtime environment that the package contains (java1-runtime and/or java2-runtime). If it does not provide the files itself it must depend on the needed runtime environment." So the policy is a bit vauge. I suggest that we change it to the following: "Java virtual machines must provide java-virtual-machine and depend on java-common. They may also provide a runtime environment (java1-runtime and/or java2-runtime) if it contains the complete set of runtime files. If it does not provide the files itself it must depend on the needed runtime environment." > But even if it were there - I *refuse* to remove this Provides: because > Sablevm _does_ provide java1 runtime env. with the expeption of things > which don't work yet. *These things* I belive can be easily called bugs > for simplicity. > > Severity "important" seems to be the right one here: > "important - a bug which has a major effect on the usability of a > package, without rendering it completely unusable to everyone" > > We all know that the fight for free Java (tfffj) is only beginning. > And I don't think we would support free java and free software by > marking every of today's free JVMs and their classlibs as unusable > because of some lacks or bugs. Especially when there's effort under > way to remove them. > > The Java Policy is to help us, to support us and to guide us. Agreed. But in some cases it is good that it forbid some things. In this case it is probably ok to keep the provide line, but only if you can see fixes to the bugs in the (near?) future. If not you should drop it and wait until it is (at least about to) be fixed. > The Java Policy is for us, not the other way. Agreed too. It is for us, not a specific person. Regards, // Ola > Kind regards > > Grzegorz B. Prokopski > -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: Policy change proposal, Re: Bug#176628: sablevm: package incorrctly provides java1-runtime
W liście z nie, 19-01-2003, godz. 17:23, Ola Lundqvist pisze: > Hi > > On Tue, Jan 14, 2003 at 11:04:22AM +0100, Grzegorz B. Prokopski wrote: > > retitle 176628 java.awt.* classess don't work as expected for > > java1-runtime > > thanks > > > > W li?cie z pon, 13-01-2003, godz. 18:26, Stephen Zander pisze: > > > Package: sablevm > > > Version: 1.0.5-1 > > > Severity: important > > > > > > According to the Java policy, packages that provide java1-runtime must > > > support the the complete java runtime environment. As sablevm fails > > > to provide working java.awt.* classes, the provides on this package is > > > incorrect. Please remove it until such time as sablevm has working > > > support for java.awt.*. > > > > I searched for "runtime" in Java Policy (as found in java-common > > package) and couldn't find such explict statment. I meant statment that says that it MUST provide such and such features to be allowed to provide java-virtual-machine. > "Java virtual machines must provide java-virtual-machine and depend on > java-common. > They can also provide the runtime environment that the package contains > (java1-runtime and/or java2-runtime). If it does not provide the files > itself it > must depend on the needed runtime environment." > > So the policy is a bit vauge. I suggest that we change it to the following: > > "Java virtual machines must provide java-virtual-machine and depend on > java-common. > They may also provide a runtime environment (java1-runtime and/or > java2-runtime) > if it contains the complete set of runtime files. If it does not provide the > files > itself it must depend on the needed runtime environment." I personally wouldn't do random changes here and there in the policy. I don't know what is "complete set of runtime files". You either gonna explain this further or you'd better give it up. And I doubt that if you say that I should just conform to some Sun Java standard - _any_ of free JVMs (and especially their classlib) actually does it right. Personally I find Java Policy good enough and I don't see any benefit from such changes. _Everybody_ know that free JVMs are not perfect. > > The Java Policy is to help us, to support us and to guide us. > > Agreed. But in some cases it is good that it forbid some things. In this > case it is probably ok to keep the provide line, but only if you can see > fixes to the bugs in the (near?) future. If not you should drop it and > wait until it is (at least about to) be fixed. I'd just say that SableVM is actively maintained and the things will be fixed one by one. But - as it is the rule for almost every free software - it will take time. I don't think that putting more LAW into the mix will gain us anything. If your app doesn't work with some JVM - file a bug and either help fixing it or wait for a fix or switch to another JVM if there's any legaly working alternative. > > The Java Policy is for us, not the other way. > Agreed too. It is for us, not a specific person. You mean it's not for _me_? :-/ Let's give it up. In Poland we have a say like that: "A cup of tee doesn't get sweeter by stiring [mixing]" (which means that you can't do much w/o sugar) Best regards Grzegorz B. Prokopski -- Grzegorz B. Prokopski <[EMAIL PROTECTED]> Debian http://www.debian.org/ signature.asc Description: PGP signature
Re: Policy change proposal, Re: Bug#176628: sablevm: package incorrctly provides java1-runtime
Hello On Sun, Jan 19, 2003 at 08:03:56PM +0100, Grzegorz B. Prokopski wrote: > W li?cie z nie, 19-01-2003, godz. 17:23, Ola Lundqvist pisze: *SNIP* > > > > > > I searched for "runtime" in Java Policy (as found in java-common > > > package) and couldn't find such explict statment. > I meant statment that says that it MUST provide such and such features > to be allowed to provide java-virtual-machine. I understood that. > > "Java virtual machines must provide java-virtual-machine and depend on > > java-common. > > They can also provide the runtime environment that the package contains > > (java1-runtime and/or java2-runtime). If it does not provide the files > > itself it > > must depend on the needed runtime environment." > > > > So the policy is a bit vauge. I suggest that we change it to the following: > > > > "Java virtual machines must provide java-virtual-machine and depend on > > java-common. > > They may also provide a runtime environment (java1-runtime and/or > > java2-runtime) > > if it contains the complete set of runtime files. If it does not provide > > the files > > itself it must depend on the needed runtime environment." > I personally wouldn't do random changes here and there in the policy. Well these are not random changes. As you might have noted I'm the one that is responsible for the writing of this policy. That is why I can tell that it is a bit vauge. The reason is that what you missed is what I intended to write (but failed to clarify) in the current policy. But right now the policy has been somewhat accepted as a normal Debian policy I have to make proposals as everybody else. If there becomes a consensus about that this is a good thing, I'll update the policy as normal. Should I see your mail here as an objection, or do you have a second alternative? > I don't know what is "complete set of runtime files". You either gonna > explain this further or you'd better give it up. And I doubt that if If so, We'll have to define it. > you say that I should just conform to some Sun Java standard - _any_ > of free JVMs (and especially their classlib) actually does it right. If you have better definitions on how to define java1-runtime and/or java2-runtime, I'm grateful for such propositions. > Personally I find Java Policy good enough and I don't see any benefit > from such changes. _Everybody_ know that free JVMs are not perfect. Yes, I know that free JVMs are not perfect too. Actually sun/ibm etc ones is not perfect either. They are sometimes buggy, incomplete, etc. I do not say that you should not provide java1-runtime. What I say is that the package should not provide things if it can not satisfy the requirements, at least in the (near?) future. If sablewm is, say 99% (or less I do not really know) complete then this is ok. But if it is just, say 80% complete... then no. I'm not able to tell exact requirements right now and therefore I want to discuss this politely on this list. > > > The Java Policy is to help us, to support us and to guide us. > > > > Agreed. But in some cases it is good that it forbid some things. In this > > case it is probably ok to keep the provide line, but only if you can see > > fixes to the bugs in the (near?) future. If not you should drop it and > > wait until it is (at least about to) be fixed. > I'd just say that SableVM is actively maintained and the things will > be fixed one by one. But - as it is the rule for almost every free > software - it will take time. I sure know that. > I don't think that putting more LAW into the mix will gain us anything. > If your app doesn't work with some JVM - file a bug and either help > fixing it or wait for a fix or switch to another JVM if there's any > legaly working alternative. > > > > The Java Policy is for us, not the other way. > > Agreed too. It is for us, not a specific person. > You mean it's not for _me_? :-/ The policy is here to define good common practice. I think that if someone tells that they provide things, without actually doing it, that can be seen as a bug. > Let's give it up. I intend to have a clear and precise policy. It is not really clear in all aspects right now which you pointed out (even if not intentional). That is why I want to make this proposal. Best regards, // Ola > In Poland we have a say like that: > "A cup of tee doesn't get sweeter by stiring [mixing]" > (which means that you can't do much w/o sugar) > > Best regards > > Grzegorz B. Prokopski > -- > Grzegorz B. Prokopski <[EMAIL PROTECTED]> > Debian http://www.debian.org/ -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5
Re: Policy change proposal - JVMs Provides: requirements
Hi! I know you're the person who maitains java-common, Java Policy and I really admire your work you do in that area. In my initial mail I already proposed that "not meeting the criteria" is just a bug, maybe even RC in some cases. I don't know what 99% or what 80% is. Fact is that aside of Kaffe, the other free JVMs use indirectly (like gcj) or directly one single source of it's classpath lisbrary - GNU Classpath. I really doubt if this project has reached 80% of what java 1.2 (especially in the area of graphical interfaces) should be. I think that *I* would use GNU Classpath as the 100% here (then we can have JVMs that support more than 100% ;-). But I don't really expect you to write it down to the policy. About SableVM - I can only say that currently SableVM is not able to use all of the features of GNU Classpath. But OTOH I am sure it will get better. It's being worked on. But getting back to the topic. You can treat my mail as an objection because it's still not really clear what the proposed change in Java Policy would gain us. It's still vague. It seem to need more detailed description or no changes at all. I'd agree to discuss it... probably on d-java? - yes. As for my proposals, I think I'd do it this way: 1. Define exactly what requirements must be met for JVM to be able to _legally_ provide java-virtual-machine, java*-runtime etc. 2. Just file bugs on JVM when the program you want to run - doesn't work. As usual. Nothing new. The bug will either get fixed or not. The only question is whether it's RC (or a set of bugs can be treated as RC) or not. That's sth. we *could* clarify. One question that is bugging me all the time and I am really curious what's the correct answer: Do we actually have a problem? Will having exact policy in this area gain us anything? (Read: Do we rally want our free JVMs to be either kept out of testing or kept w/o Provides: that can bring them to real live in many uses?) Regards Grzegorz B. Prokopski PS: I'll wait to see what other have to say on that topic. -- Grzegorz B. Prokopski <[EMAIL PROTECTED]> Debian http://www.debian.org/ signature.asc Description: PGP signature
Re: Policy change proposal - JVMs Provides: requirements
On Sun, Jan 19, 2003 at 10:22:23PM +0100, Grzegorz B. Prokopski wrote: > Hi! Hi again. > > > I know you're the person who maitains java-common, Java Policy > and I really admire your work you do in that area. Thanks a lot! I appriciate it. > In my initial mail I already proposed that "not meeting the criteria" > is just a bug, maybe even RC in some cases. Hmm ... I thought you objected that it can be RC. If so then we are telling the same things but in different ways. :) > I don't know what 99% or what 80% is. Fact is that aside of Kaffe, > the other free JVMs use indirectly (like gcj) or directly one single > source of it's classpath lisbrary - GNU Classpath. I really doubt if this > project has reached 80% of what java 1.2 (especially in the area of > graphical interfaces) should be. I think that *I* would use GNU > Classpath as the 100% here (then we can have JVMs that support more > than 100% ;-). But I don't really expect you to write it down to > the policy. Hmm. It it that bad. I was not aware of that actually. In some way we have to define java1-runtime in a good way. Define it against a moving target (like classpath) might not be a good thing. On the other hand it might be the best way... > About SableVM - I can only say that currently SableVM is not able to use > all of the features of GNU Classpath. But OTOH I am sure it will get > better. It's being worked on. And I forgot to tell that I admire everyone that are working to make a free alternative. I'm sure it will be better. > But getting back to the topic. > You can treat my mail as an objection because it's still not really > clear what the proposed change in Java Policy would gain us. Ok. It is a good point. > It's still vague. It seem to need more detailed description or no > changes at all. I'd agree to discuss it... probably on d-java? - yes. Let's continue on debian-java, then. > As for my proposals, I think I'd do it this way: > 1. Define exactly what requirements must be met for JVM to be able > to _legally_ provide java-virtual-machine, java*-runtime etc. Then we can agree on that. The problem is to define it... :( > 2. Just file bugs on JVM when the program you want to run - doesn't > work. As usual. Nothing new. The bug will either get fixed or not. No nothing new. > The only question is whether it's RC (or a set of bugs can be > treated as RC) or not. That's sth. we *could* clarify. Yes that has to be clarified. > One question that is bugging me all the time and I am really curious > what's the correct answer: > > Do we actually have a problem? Good question! :) > Will having exact policy in this area gain us anything? Yes I actually think so. The thing we gain is that users can be less confused. If they apt-get things, they tend to think that things should work. If they by (mistake?) got another virtual-machine for their java app they can be pretty disapointed. I become that from time to time... :) This gain nothing to us, but something to the end user. > (Read: Do we rally want our free JVMs to be either kept out of testing > or kept w/o Provides: that can bring them to real live in many uses?) Well actually I do not think it is a good thing to release with a provides line that is not really functional. But I can also accept the other posistion, that says that this is better than non-free alternatives. I agree on both and I'm no longer so sure about this. What do other people think about this issue? Best regards, // Ola > Regards > > Grzegorz B. Prokopski > > PS: I'll wait to see what other have to say on that topic. > > -- > Grzegorz B. Prokopski <[EMAIL PROTECTED]> > Debian http://www.debian.org/ -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: Policy change proposal - JVMs Provides: requirements
--- Ola Lundqvist <[EMAIL PROTECTED]> wrote: > On Sun, Jan 19, 2003 at 10:22:23PM +0100, Grzegorz > B. Prokopski wrote: > > I don't know what 99% or what 80% is. Fact is that > aside of Kaffe, > > the other free JVMs use indirectly (like gcj) or > directly one single > > source of it's classpath lisbrary - GNU Classpath. > I really doubt if this > > project has reached 80% of what java 1.2 > (especially in the area of > > graphical interfaces) should be. I think that *I* > would use GNU > > Classpath as the 100% here (then we can have JVMs > that support more > > than 100% ;-). But I don't really expect you to > write it down to > > the policy. > > Hmm. It it that bad. I was not aware of that > actually. In some way > we have to define java1-runtime in a good way. > Define it against > a moving target (like classpath) might not be a good > thing. On the > other hand it might be the best way... Well, seems like you guys are looking for some numbers ;) Check the japitools JDK API compatibility pages at http://rainbow.netreach.net/~sballard/japi/ > > As for my proposals, I think I'd do it this way: > > 1. Define exactly what requirements must be met > for JVM to be able > > to _legally_ provide java-virtual-machine, > java*-runtime etc. > > Then we can agree on that. The problem is to define > it... :( I don't understand the term 'legally' in this context. What legal requirements are there? best regards, dalibor topic __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Policy change proposal - JVMs Provides: requirements
W liście z nie, 19-01-2003, godz. 23:17, Dalibor Topic pisze: > --- Ola Lundqvist <[EMAIL PROTECTED]> wrote: > > On Sun, Jan 19, 2003 at 10:22:23PM +0100, Grzegorz > > B. Prokopski wrote: > > > > I don't know what 99% or what 80% is. Fact is that > > aside of Kaffe, > > > the other free JVMs use indirectly (like gcj) or > > directly one single > > > source of it's classpath lisbrary - GNU Classpath. > > I really doubt if this > > > project has reached 80% of what java 1.2 > > (especially in the area of > > > graphical interfaces) should be. I think that *I* > > would use GNU > > > Classpath as the 100% here (then we can have JVMs > > that support more > > > than 100% ;-). But I don't really expect you to > > write it down to > > > the policy. > > > > Hmm. It it that bad. I was not aware of that > > actually. In some way > > we have to define java1-runtime in a good way. > > Define it against > > a moving target (like classpath) might not be a good > > thing. On the > > other hand it might be the best way... > > Well, seems like you guys are looking for some numbers > ;) Check the japitools JDK API compatibility pages at > http://rainbow.netreach.net/~sballard/japi/ Thanks for the link. However in this case the APIs are compared, not if they really work. There's a lot of stubs in GNU Classpath, so I doubt if this comparison method is sutiable for our purpose. Every JVM that uses GNU Classpath would get same results. It's comparison of classpaths not JVMs. > > > As for my proposals, I think I'd do it this way: > > > 1. Define exactly what requirements must be met > > for JVM to be able > > > to _legally_ provide java-virtual-machine, > > java*-runtime etc. > > > > Then we can agree on that. The problem is to define > > it... :( > > I don't understand the term 'legally' in this context. > What legal requirements are there? Legally - after meeting the (future, planned) requirements of Java Policy for the JVMs that want to have such Provides:. Regards Grzegorz B. Prokopski -- Grzegorz B. Prokopski <[EMAIL PROTECTED]> Debian http://www.debian.org/ signature.asc Description: PGP signature
Re: JAVA_HOME policy
On 10 Jan 2003, Joe Phillips wrote: > #2 is a bit trickier. tools.jar is needed in some cases, most notably > servlet/jsp containers need it in order to compile JSP at runtime. My > JBOSS packages fall into this category. tools.jar is installed > somewhere under JAVA_HOME, JBOSS needs tools.jar and so needs JAVA_HOME. Technically, no. Only the web container needs tools.jar. Not jboss. When jboss-catalina or jboss-jetty get installed, they should be the ones that go looking for tools.jar, and add it to jboss' deploy dirs(or to their own internal classpath). JBoss itself shouldn't do this.
