Sądzę, że postawiłem to pytanie w sposób jasny i zwięzły. Dlaczego pytam?Czy poprawianie Ruby Gems jest analogią do JARów Java?
Mam wyjaśnić uczniom ramy Ruby on Rails, co wymaga pewnych analogii ze środowiskiem Java (ponieważ kurs jest dość zorientowany na Javę). Nie mam praktycznego doświadczenia z Ruby on Rails, ale wyczuwam analogię Gem/Jar.
Czy ktoś może rzucić więcej światła na tę kwestię?
Jako krótką odpowiedź powiedziałbym: tak, jest ważna.
Jako długą odpowiedź, odpowiedziałbym: tak, jest ważna, ale istnieje kilka ważnych różnic, które możesz chcieć opisać.
Słoiczek ma pewne cechy, które bardzo różnią się od klejnotu. Pliki JAR są spakowanymi bibliotekami wykonywalnymi, które zwykle muszą jawnie deklarować zależność w trakcie wykonywania programu Java w czasie wywołania (deklarując słoik jako zależność podczas wywoływania interpretera Java). Słoik ma na sobie niewielką strukturę inną niż kilka dobrze zdefiniowanych lokalizacji plików (np. Struktura katalogów musi odzwierciedlać ścieżkę pakietu).
Klejnot to deskryptor do instalowania biblioteki w systemie na stałe, a także pakiet funkcji udostępnianych do zadeklarowania zależności w czasie wykonywania. Klejnot ma ścisłą składnię wersjonowania jako część jego definicji, a klejnoty są rozprowadzane z kilku scentralizowanych repozytoriów, które wydają przyzwoitą ilość wysiłku, aby zapewnić wyjątkowość w nazwach klejnotów. Klejnoty mogą jawnie zadeklarować swoje zależności na innych klejnotach. (Porównaj z JARami, w których musisz upewnić się, że masz wszystkie zależności dla słoika spełnione w czasie wywołania, a słoiki nie przyjmują jawnie odpowiedzialności za deklarację zależności LUB rozdzielczość). Dodatkowo istnieje kilka opcjonalnych funkcji wbudowanych w narzędzie klejnotów, które mogą być całkiem wygodne, na przykład możesz zadeklarować domyślny plik wykonywalny, aby można było wywołać klejnot, jeśli użytkownik chce "uruchomić klejnot", i możesz zadeklarować zestaw testów jednostkowych na klejnot, aby użytkownik instalujący klejnot mógł zapewnić jego funkcjonalność.
Możesz również opisać swoim uczniom, że RubyGems to narzędzie stworzone niezależnie od samego języka Ruby i że przynosi korzyści po wielu niedogodnościach i skargach, które powstały w wyniku zarządzania słoikami, były dobrze widoczne po latach Java rozwój.
Nie jestem pewien, jest to takie proste ...
myślę, że Gem jest w zasadzie to samo, co słoiku, ale Gem musi mieć nazwę i wersję, słoik nie ma to, hm, powiedzmy ..., ograniczenia.
Mechanizm Jar został stworzony do pakowania i tylko do pakowania. Najważniejszym IMHO w Gem jest projekt RubyGems Zestaw funkcji RubyGems jest nieco większy niż tylko opakowanie, w tym dystrybucji pakietów i instalacji.
Uważam, że mechanizm dystrybucji i instalacji Apache Maven jest najbliższy społeczności Java z klejnotów Ruby.
dzięki za analogię do maven –
W prosty sposób porównanie ich z JAR jest wystarczająco dobre dla podstawowej klasy Ruby. Aby uzyskać bardziej szczegółowe wyjaśnienie, patrz odpowiedź holychao. Analizy, która przychodzi mi do głowy, to to, że Gem jest dla Ruby, co CPAN dla Perla.
+1; + ponieważ dostarczyłeś wyczerpującą odpowiedź, przyjmuję to :) –
@animal - https: //en.wikipedia.org/wiki/RubyGems mówi mi, że RubyGems sam jest napisany w ruby i jest menedżerem pakietów dla języka programowania ruby, więc trochę się różnuję, kiedy mówisz "RubyGems to narzędzie stworzone niezależnie od samego języka Ruby". Ale muszę powiedzieć, że zarządzanie relacjami przez RubyGems, aby odróżnić je od słoika, jest dobrze wyjaśnione. W rzeczywistości to dlatego deweloperzy java potrzebują narzędzia do zarządzania zależnościami, jak maven. – nanosoft