any voluntaries for support java educational software
Hi! Currently in Educational:Desktop BS project [1] there are 7 educational programs written in java and next Scilab version will be available soon under java, so it would be great, if someone (experienced java packager) can review and improve these packages. The list of already packaged software: 1. Netbeans 2. Geogebra 3. Geonext 4. Xlogo 5. jMemorize 6. Pauker 7. BlueJ
From this list only jMemorize is actually build in java environment and all other packages are using pre-build jars, although only BlueJ does not provide source code.
All bugs against this programs can be found in openSUSE Education bugzilla [2]. There are also other useful educational programs not yet packaged. Thanks in advance. Kirill. -- [1] https://build.opensuse.org/project/show?project=Education%3Adesktop [2] http://www.opensuse-education.org/index.php?module=pnMantis&func=main&task=1 -- To unsubscribe, e-mail: opensuse-java+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-java+help@opensuse.org
From this list only jMemorize is actually build in java environment and
all other packages are using pre-build jars, although only BlueJ does not provide source code. I found several java progams/libs are not providing sufficient information to build from source, don't provide the source code easily for download at all or don't provide a build mechanism outside their IDE or don't know how to
Kirill, [....] provide this ( I had this with a few projects using eclipse) Not all project developers are as cooperative as those developing jMemorize. [...] I don't know eclipse myself, but if someone could provide a manual how to archive the source so that it can be easily used for building, e.g. in the wiki in the JAVA section, that would be great. Then I could just point them to this and kindly ask to follow these steps. Denny -- To unsubscribe, e-mail: opensuse-java+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-java+help@opensuse.org
On Friday 16 May 2008 22:52:18 Kirill Kirillov wrote:
Hi!
Currently in Educational:Desktop BS project [1] there are 7 educational programs written in java and next Scilab version will be available soon under java, so it would be great, if someone (experienced java packager) can review and improve these packages.
Hi Kirill, as Denny said, most of this Java packages are withouth source codes and including the prebuild jars into the distribution is not possible.
The list of already packaged software: 1. Netbeans
We are working in home:jtulach [1], with developers from Sun, but we have some necessary software only in Factory (mainly the openjdk6) and a java stack in Factory is very unstable, so we are waiting to release of 11.0 to continue of this work.
2. Geogebra 3. Geonext 7. BlueJ Are not under OSS license.
4. Xlogo 6. Pauker Have source codes, but the packages in OBS are unusable, because they used a binary jars. So it's necessary to improve this packages.
5. jMemorize Could be included - I'll look on the package asap.
Best regards Michal Vyskocil -- To unsubscribe, e-mail: opensuse-java+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-java+help@opensuse.org
В Пнд, 19/05/2008 в 10:10 +0200, Michal Vyskocil пишет: > > The list of already packaged software: > > 1. Netbeans > We are working in home:jtulach [1], with developers from Sun, but we > have some necessary software only in Factory (mainly the openjdk6) and > a java stack in Factory is very unstable, so we are waiting to release > of 11.0 to continue of this work. Good luck. > > 2. Geogebra > > 3. Geonext > > 7. BlueJ > Are not under OSS license. 8. Cademia (not yet in BS even as binaries) 9. GreenFoot (not yet in BS even as binaries) >From http://www.geogebra.org/download/license.txt 1) GeoGebra Installer, Language and Documentation Files License: Creative Commons Attribution-NonCommercial-NoDerivs 3.0 2) GeoGebra Application and Source Code License: GNU General Public License GeoGebra is very interesting and mature program with many awards, is it really impossible to include it adding documentation as separate package with CC license? IMHO, it is "must have" educational program. About BlueJ, GreenFoot, GeoNext, Cademia, the last two projects can send their source code after e-mail request, IMHO, it's worth to discuss with developers possibility of direct building their applications in build service. > > 4. Xlogo > > 6. Pauker > Have source codes, but the packages in OBS are unusable, because they > used a binary jars. So it's necessary to improve this packages. There is no java package guidelines in openSUSE wiki as for qt and gtk applications and I've packaged Xlogo using pre-build binary to provide educators with this program, IMHO, better to have such kind of packages, than to have nothing. > > 5. jMemorize > Could be included - I'll look on the package asap. Thanks. Kirill. -- To unsubscribe, e-mail: opensuse-java+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-java+help@opensuse.org
On Monday 19 May 2008 15:07:03 Kirill Kirillov wrote:
В Пнд, 19/05/2008 в 10:10 +0200, Michal Vyskocil пишет:
The list of already packaged software: 1. Netbeans
Hi,
We are working in home:jtulach [1], with developers from Sun, but we have some necessary software only in Factory (mainly the openjdk6) and a java stack in Factory is very unstable, so we are waiting to release of 11.0 to continue of this work.
Good luck. Thanks.
2. Geogebra 3. Geonext 7. BlueJ
Are not under OSS license.
8. Cademia (not yet in BS even as binaries) 9. GreenFoot (not yet in BS even as binaries)
You're rigth, I've only readed an Czech translation, which tolds about "non-commercional use" only. I'm glad, that this is the opensource software.
About BlueJ, GreenFoot, GeoNext, Cademia, the last two projects can send their source code after e-mail request, IMHO, it's worth to discuss with developers possibility of direct building their applications in build service.
Well done, as I've understood, you are in contact with developers, so if you could get a source codes, it's great. If you've got the source codes, you're welcome to contact me (via e-mail, this ML, or IRC) and I try to help you with build.
4. Xlogo 6. Pauker
Have source codes, but the packages in OBS are unusable, because they used a binary jars. So it's necessary to improve this packages.
There is no java package guidelines in openSUSE wiki as for qt and gtk applications and I've packaged Xlogo using pre-build binary to provide educators with this program, IMHO, better to have such kind of packages, than to have nothing.
yes, I know, that the Java section in wiki is poor, but I've a too much another work, so there's no time to write something to wiki :-( - and also my English skills are not very good ;-). Currently we only have a http://en.opensuse.org/Java/Packaging/Overview If anyone could helps with Java sections in wiki, it would be great - I've it in my TODO, but currently at the bottom of the list.
5. jMemorize
Could be included - I'll look on the package asap.
Thanks.
Kirill.
Best Regards Michal Vyskocil -- To unsubscribe, e-mail: opensuse-java+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-java+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michal Vyskocil wrote:
[...]
| yes, I know, that the Java section in wiki is poor, but I've a too much
| another work, so there's no time to write something to wiki :-( - and
| also my English skills are not very good ;-).
|
| Currently we only have a http://en.opensuse.org/Java/Packaging/Overview
|
| If anyone could helps with Java sections in wiki, it would be great -
| I've it in my TODO, but currently at the bottom of the list.
I had a quick look at it, fixed some spelling and rewrote parts of the
spec file (e.g. never "rm -rf $RPM_BUILD_ROOT" except in the %clean
section).
cheers
- --
~ -o) Pascal Bleser
В Втр, 20/05/2008 в 22:39 +0200, Pascal Bleser пишет:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Michal Vyskocil wrote: [...] | yes, I know, that the Java section in wiki is poor, but I've a too much | another work, so there's no time to write something to wiki :-( - and | also my English skills are not very good ;-). | | Currently we only have a http://en.opensuse.org/Java/Packaging/Overview | | If anyone could helps with Java sections in wiki, it would be great - | I've it in my TODO, but currently at the bottom of the list.
I had a quick look at it, fixed some spelling and rewrote parts of the spec file (e.g. never "rm -rf $RPM_BUILD_ROOT" except in the %clean section).
Thanks for useful template spec, but I've one question: which of these two paths is correct: 1) %__install -d -m 0755 "%{buildroot}%{_datadir}/%{name}" 2) %__install -d -m 0755 "%{buildroot}%{_datadir}/java/%{name}" Kirill. -- To unsubscribe, e-mail: opensuse-java+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-java+help@opensuse.org
Kirill Kirillov napsal(a):
Thanks for useful template spec, but I've one question: which of these two paths is correct: 1) %__install -d -m 0755 "%{buildroot}%{_datadir}/%{name}" 2) %__install -d -m 0755 "%{buildroot}%{_datadir}/java/%{name}"
For installation of Java jar files, please, use: %{buildroot}%{_javadir}/%{name} E.g on x86_64 %{_javadir} will expand to /usr/share/java You can also have a look at packages in distribution to see how the directory structure looks like. Regards, Ales -- To unsubscribe, e-mail: opensuse-java+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-java+help@opensuse.org
On Wednesday 28 May 2008 07:42:34 Ales Nosek wrote:
Kirill Kirillov napsal(a):
Thanks for useful template spec, but I've one question: which of these two paths is correct: 1) %__install -d -m 0755 "%{buildroot}%{_datadir}/%{name}" 2) %__install -d -m 0755 "%{buildroot}%{_datadir}/java/%{name}"
For installation of Java jar files, please, use:
%{buildroot}%{_javadir}/%{name}
E.g on x86_64 %{_javadir} will expand to /usr/share/java
You can also have a look at packages in distribution to see how the directory structure looks like.
Regards, Ales
Maybe we'll add an usage of these macros to Package Convetions on wiki ... MV -- To unsubscribe, e-mail: opensuse-java+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-java+help@opensuse.org
Hi Pascal, Any help is appreciated. And I hope java software packaging is getting more popular and we will have more java software available soon on OBS :-) Thanks for your help on cleaning up the file. I started the section on Java packaging, as there wasn't anything yet and I found a number of Java packages in opensuse aren't actually "build" - as such during the packaging process. Look at the "Jarnal" build script in Factory ;-) [...]
I had a quick look at it, fixed some spelling and rewrote parts of the spec file (e.g. never "rm -rf $RPM_BUILD_ROOT" except in the %clean section). Why not? I cleans the directory before building ... not really necessary anymore with OBS though...
cheers
Also, a few questions remain: Why did you replace all the {name} variables with the actual name? What is better in using "%__install ..." over "install ..." ? "$RPM_BUILD_ROOT" has been replaced with "%{buildroot}" too, any advantage here? I hope you'll find some time in future to do more sanity check in the java packaging section of the wiki! Cheers, Denny -- To unsubscribe, e-mail: opensuse-java+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-java+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Denny Beyer wrote:
| Any help is appreciated. And I hope java software packaging is getting
more
| popular and we will have more java software available soon on OBS :-)
|
| Thanks for your help on cleaning up the file.
| I started the section on Java packaging, as there wasn't anything yet
and I
| found a number of Java packages in opensuse aren't actually "build" -
as such
| during the packaging process.
Well personally, I don't see the point of "always building".
It's JVM bytecode. It's portable. No point in building (except to make
sure it compiles and runs with JDK 1.4 if 1.4 is all you have and you
don't trust upstream saying it runs with 1.4).
| Look at the "Jarnal" build script in Factory ;-)
|
| [...]
|> I had a quick look at it, fixed some spelling and rewrote parts of the
|> spec file (e.g. never "rm -rf $RPM_BUILD_ROOT" except in the %clean
|> section).
| Why not? I cleans the directory before building ... not really necessary
| anymore with OBS though...
It's a potential race condition that can be used to delete directories
as root when someone replaces the $RPM_BUILD_ROOT directory with a
symlink to, say, /
;)
Furthermore, it isn't needed at all, as rpmbuild already takes care of
doing so properly (and without the race).
| Also, a few questions remain:
| Why did you replace all the {name} variables with the actual name?
|
| What is better in using "%__install ..." over "install ..." ?
%__install is more portable.
On some platforms (e.g. AIX), a capable "install" binary might not be
"install" but "ginstall" or "/usr/local/bin/install" (instead of
"/usr/bin/install") or "/opt/gnu/install" etc...
It's not very likely that the packages would be rebuilt on a non-Linux
platform but if so, the tools can be configured properly through the
rpmmacros file.
Personally, when there's a macro, I use the macro.
| "$RPM_BUILD_ROOT" has been replaced with "%{buildroot}" too, any
advantage
| here?
None, besides using the macro instead of the environment variable.
Just a matter of taste on this one.
cheers
- --
~ -o) Pascal Bleser
On Thursday 29 May 2008 07:11:41 Pascal Bleser wrote: [snip]
Well personally, I don't see the point of "always building". It's JVM bytecode. It's portable. No point in building (except to make sure it compiles and runs with JDK 1.4 if 1.4 is all you have and you don't trust upstream saying it runs with 1.4).
Hi, the source code is really necessary for a future maintenance - patching of the appliaction distributed as jar(s) file(s) is possible, but it is a hell! I understand, that for BuildService only it is not important, because there's no maintenance - maintaner could update to newest version, if its necessary. But that package is unusable for openSUSE and vill not be included to the distribution. Yes, there may be some packages, which are in binary form only, but this is a historicall reason. We preffer to replace them by normall source based packages. So, the packaging of jars is possible, but is not really regular and peoples *have* to know it. The python packages also contains the source (py) and a bytecode (pyc/pyo) files. I know, that in the Java upstream is using of the jars regular and using of the source codes and building the own jars not, so its a harder way, but the only possible for the openSUSE and other Linux distributions. [snip]
None, besides using the macro instead of the environment variable. Just a matter of taste on this one.
One advantage of using macros instead of enviroment variables is, that the macros are expanded in the scripplets (%post/%pre/...), but the environment variables not. So an output of the rpm -q --scripts will be different. Best Regards Michal Vyskocil -- To unsubscribe, e-mail: opensuse-java+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-java+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michal Vyskocil wrote:
| On Thursday 29 May 2008 07:11:41 Pascal Bleser wrote:
| [snip]
|> Well personally, I don't see the point of "always building".
|> It's JVM bytecode. It's portable. No point in building (except to
|> make sure it compiles and runs with JDK 1.4 if 1.4 is all you have
|> and you don't trust upstream saying it runs with 1.4).
|
| Hi,
Hi Michal
| the source code is really necessary for a future maintenance - patching
| of the application distributed as jar(s) file(s) is possible, but it is
| a hell!
Mmmm.. yeah, OK, that is indeed a valid reason.
| I understand, that for BuildService only it is not important, because
| there's no maintenance - maintaner could update to newest version, if
| its necessary. But that package is unusable for openSUSE and vill not
Correct.
| be included to the distribution.
OK, makes sense.
[...]
| [snip]
|> None, besides using the macro instead of the environment variable.
|> Just a matter of taste on this one.
|
| One advantage of using macros instead of environment variables is, that
| the macros are expanded in the scripplets (%post/%pre/...), but the
| environment variables not. So an output of the rpm -q --scripts will be
| different.
True, forgot about that one :)
But I always use macros wherever possible anyway ;)
cheers
- --
~ -o) Pascal Bleser
participants (5)
-
Ales Nosek -
Denny Beyer -
Kirill Kirillov -
Michal Vyskocil -
Pascal Bleser