Legfrissebb hír 2009. szeptemberi, levlistán automata üzenetek és néhány kérdés. Update van pár 2010-es is, de pl. legfrissebb compatilility csomag 1.6.0-14-hez van...
Érdemes küzdeni vele? Van jobb alternatíva? Inkább kézzel mindent?
- 1580 megtekintés
Hozzászólások
Én a kézzel összerakásnak vagyok híve. Nagyon sok régi cucc van benne, meg minek is ennyi vacak. Ráadásul keverve vannak az eszközök és a könyvtárak (library). Az eszközök még jók lennének, hogy egyben vannak, de a könyvtárak kezelésére más eszköz való (pl. Maven). Amúgy is javasolt úgy elkészíteni minden Java-s projektet, hogy környezetfüggetlen legyen, ebben egy kész környezet meg csak hátráltat.
- A hozzászóláshoz be kell jelentkezni
Köszönöm, szerintem nálam is ez lesz.
- A hozzászóláshoz be kell jelentkezni
Azért a JPackage használatának is vannak előnyei...
Nem vagyok biztos benne, hogy komoly szerveren "kézzel összerakott" Java alkalmazásoknak kell futni.
A JPackage segítségével meg könnyen gyárthatók az adott RH Enterprise vagy Fedora környezettel kompatibilis RPM csomagok. Lehet, hogy a Sun JDK-val most kicsit lemaradtak, de azért van ott még párezer más érdekes Java csomag, pl a
http://mirrors.dotsrc.org/jpackage/6.0/generic/SRPMS.free/
könyvtárban mai keltezésűek is...
- A hozzászóláshoz be kell jelentkezni
Nem értem igazán, hogy miért kellene RPM/DEB/stb csomag... ha egy Java kliensről van szó, akkor bele kell tenni egy darab JAR-ba mindent és dupla kattintással indul a legtöbb oprendszeren, esetleg a WebStart se az ördögtől való dolog. Itt inkább egy InstallShield szerű alkalmazás a jobb megoldás, mint az IzPack, vagy a többi ingyenes-fizetős telepítő program.
Ha szerverbe kerülő alkalmazásról van szó, ahhoz szinte mindenféle alkalmazás-szerverhez létezik deploy tool, amely okosabban és jobban megoldja az új modul kihelyezését, mint egy Linux-os csomagkezelő...
--
http://wiki.javaforum.hu/display/FREEBSD
- A hozzászóláshoz be kell jelentkezni
Mas kerdes, hogy az okos deployment tool-okkal nem lehet peldaul konzisztencia ellenorzest csinalni, vagyis hogy a fajlok modosultak-e, mig a jobb package managerekkel lehet, mert letaroljak a telepitett fajlok checksumjat.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Szerintem elég baj az, ha módosulnak a fájlok, az meg pláne baj, ha ezt csak package managerrel veszik észre... :)
A hot-deploy és egyéb érdekességek nehezen kivitelezhetőek egy csomagkezelővel, nem beszélve egyes alkalmazás szerverek farm-deploy tudásáról.
--
http://wiki.javaforum.hu/display/FREEBSD
- A hozzászóláshoz be kell jelentkezni
postinstall scripttel csak azt nem csinalsz meg, amit nem akarsz, erre minden csomagkezelo lehetoseget ad. Ja, hogy nincs rendes cli felulet a specialis deployhoz? Hat, az ij kategoria.
Egyebkent meg, amit lentebb is irt a kollega: a shared jar kezeles is konnyebb csomagkezelovel, es igy nem lesz fenn minden szar lib 5-6x ugyanazzal a verzioval. Gentoonal megoldottak, hogy parhuzamosan annyi, egymassal inkompatibilis lib lehet fenn, amennyit csak akarsz, csak jo verziotol kell fuggeni.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Valóban, és máris minden meg van oldva :-)
$ ls -lS $(locate javaws.jar)
-rw-r--r--. 1 root root 915558 okt 1 22.33 /usr/lib/jvm/java-1.6.0-sun-1.6.0.21/jre/lib/javaws.jar
-rw-r--r--. 1 root root 822317 okt 1 22.16 /opt/jre1.6.0_21/lib/javaws.jar
-rw-r--r--. 1 root root 822317 júl 26 22.43 /usr/local/geogebra/jre/lib/javaws.jar
-rw-r--r--. 1 root root 807831 aug 31 15.13 /usr/local/scilab-5.3.0-beta-3/thirdparty/java/lib/javaws.jar
-rw-r--r--. 1 root root 644132 2008 ápr 21 /opt/matlab7/sys/java/jre/glnx86/jre/lib/javaws.jar
-rw-r--r--. 1 root root 638948 2007 jan 24 /opt/maple12/jre.IBM_INTEL_LINUX/lib/javaws.jar
$ rpm -qif $(locate javaws.jar)
file /opt/jre1.6.0_21/lib/javaws.jar is not owned by any package
file /opt/maple12/jre.IBM_INTEL_LINUX/lib/javaws.jar is not owned by any package
file /opt/matlab7/sys/java/jre/glnx86/jre/lib/javaws.jar is not owned by any package
Name : java-1.6.0-sun-plugin Relocations: (not relocatable)
Version : 1.6.0.21 Vendor: (none)
Release : 1.0.cf Build Date: 2010. okt. 1., péntek, 22.34.50 CEST
Install Date: 2010. okt. 1., péntek, 22.58.49 CEST Build Host: xxxx
Group : User Interface/Desktops Source RPM: java-1.6.0-sun-1.6.0.21-1.0.cf.nosrc.rpm
Size : 4027169 License: Oracle Corporation Binary Code License
Signature : (none)
URL : http://java.sun.com/javase/6
Summary : Sun Java browser plugin
Description :
This package contains the Sun Java browser plugin and Java Web Start.
file /usr/local/geogebra/jre/lib/javaws.jar is not owned by any package
file /usr/local/scilab-5.3.0-beta-3/thirdparty/java/lib/javaws.jar is not owned by any package
Végül is 1 helyett 6 db javaws.jar nem olyan nagy dolog, a programok működnek, a diszken elférnek, semmi gond.
De ha minden komolyabb programnak saját libc.so, libX11.so, libxml2.so, stb. könyvtára lenne, az még sokat lendítene az ügyön!
Ja, hogy ilyet normális ember nem mond/nem gondol? Hát igen, a Java az egészen más.
Java security bug esetén meg külön élvezet lehet összevadászni és egyenként javítani az érintett komponenseket.
Amúgy én nem sok jóra számítok az olyan "deploy tool" alkalmazásakor, amely okosabbnak képzeli magát a host OS-nél, annak csomagkezelőjénél.
Hint: pl. SELinux + speciális jogok.
Persze a HUP-ról (is) ismert, hogy az ilyen problémákra van egyszerű megoldás:
setenforce 0
- A hozzászóláshoz be kell jelentkezni