जावा प्रोजेक्ट के लिए वैग्रंट: आपको वीएम में या मेजबान पर संकलन करना चाहिए?


91

यहाँ सवाल है: जब जावा प्रोजेक्ट (या उस मामले के लिए कोई संकलित भाषा परियोजना) के लिए वैग्रंट का उपयोग किया जाता है, तो क्या आपको वीएम में या मेजबान पर संकलन करना चाहिए? इसके अलावा, क्या आप चाहते हैं कि आपका आईडीई और आपके सभी विकास उपकरण वीएम के अंदर से या मेजबान पर चलाए जाएं?

यह बहुत अच्छी तरह से परिभाषित नहीं किया गया लगता है कि कैसे एक जावा आईडीई और संकलन / तैनाती प्रक्रिया एक वैगन वीएम के साथ काम करती है। आम तौर पर मेरी धारणा यह है कि कोड को होस्ट पर संपादित किया जाता है, और VM पर चलाया जाता है, जो गैर-संकलित भाषाओं के लिए बहुत अच्छा काम करता है। स्टैकओवरफ्लो पर अन्य जवाबों से यह अनुमान लगाया गया है कि अतिरिक्त संकलित कदम के कारण संकलित भाषाओं के लिए वैगरेंट कम उपयोगी है, लेकिन मैं अभी भी देखना चाहता हूं कि क्या किया जा सकता है।

कुछ चीजें जो मैंने पहले से ही सोच रखी हैं:

वीएम पर संकलन क्यों

  • यदि मेजबान पर संकलन, जावा स्थापित करने के लिए सॉफ्टवेयर का एक और टुकड़ा है
  • यदि होस्ट पर संकलित किया जाता है, तो होस्ट पर जावा संस्करण को वीएम पर मैन्युअल रूप से तारीख तक रखा जाना चाहिए
  • होस्ट पर संबंधित जावा संस्करण अनुपलब्ध हो सकता है (एक मैक पर कहो)

VM पर IDE क्यों है

  • पर्यावरण और IDE के बीच गहरा एकीकरण, एप्लिकेशन को चलाने के लिए शॉर्टकट का उपयोग कर सकता है
  • दूरस्थ डिबगिंग के बिना जावा अनुप्रयोगों के लिए डिबगर कनेक्ट कर सकते हैं (एक कदम रन / डिबग)

मेज़बान पर संकलन क्यों

  • तेजी से संकलन समय
  • वीएम को जितना संभव हो उतना उत्पादन के करीब रखना चाहता है

मेजबान पर आईडीई क्यों है

  • यह मेजबान पर कोड को संपादित करने और VM पर चलाने के लिए योनि सम्मेलन है
  • बेहतर UI प्रदर्शन (X अग्रेषण और VNC धीमा है)

आपके विचार क्या हैं: क्या मुझे अपना IDE VM या होस्ट के अंदर से चलाना चाहिए? क्या मुझे वीएम या होस्ट के अंदर से संकलन करना चाहिए?

जवाबों:


61

बहुत सोचने और प्रयोग करने के बाद, मैंने यह तय किया है कि वैग्रंट का उपयोग कहां करना है और यह जावा विकास वर्कफ़्लो के साथ कैसे एकीकृत होता है।

JavaEE / तैनात अनुप्रयोगों के लिए, एक वेब सर्वर और एक डेटाबेस सर्वर को कॉन्फ़िगर करना निश्चित रूप से ऐसी चीजें हैं जिनके पास वैग्रंट के उपयोग को वारंट करने के लिए "पर्याप्त" जटिलता है। दो सर्वर और उन्हें कॉन्फ़िगर करने के लिए असंख्य तरीकों के साथ, "एक मशीन से दूसरे पर काम करना" सिंड्रोम के बारे में लाते हुए कॉन्फ़िगरेशन के लिए एक डेवलपर से दूसरे डेवलपर से बाहर निकलना आसान है। इस तरह के सॉफ़्टवेयर के लिए, होस्ट पर कोड को संपादित करना और संकलित करना बेहतर होगा, और आपके उत्पादन वातावरण की नकल करने वाले Vagrant VM पर लागू होगा। वेब सर्वर के लिए परिनियोजन फ़ोल्डर को होस्ट पर एक संकलित लक्ष्य के लिए भी सहानुभूति दी जा सकती है, मैन्युअल रूप से पुन: डिज़ाइन करने की आवश्यकता को हटाते हुए। तो वैग्रंट आपके विकास जीवन चक्र का एक महत्वपूर्ण हिस्सा हो सकता है,

स्वसंपूर्ण जावा अनुप्रयोगों (पुस्तकालयों या डेस्कटॉप अनुप्रयोगों की तरह) के लिए कहानी थोड़ी बदल जाती है। इस मामले में यह पूरी तरह से वैगन के उपयोग को बढ़ाते हुए, होस्ट मशीन को संपादित करने, संकलित करने और चलाने के लिए सबसे अधिक समझ में आता है। यदि आप बड़े जावा आईडीई (एक्लिप्स, नेटबीन्स, इंटेलीज ...) में से एक का उपयोग कर रहे हैं, तो आपके पास पहले से ही जावा मशीन पर स्थापित है। उस समय वैग्रैंट का उपयोग करने के ओवरहेड की तुलना में बहुत कम लाभ होता है, और केवल आपकी विकास प्रक्रिया में जटिलता की एक अतिरिक्त परत डालने का कार्य करता है। ऐसा इसलिए है क्योंकि जब तक आप एक आईडी के साथ जावा को संपादित करने में सक्षम होते हैं तब तक आप मेजबान पर सब कुछ चलाने में सक्षम होते हैं। एक समस्या यह है कि प्रोजेक्ट के लिए आवश्यक जावा का संस्करण होस्ट पर आईडीई चलाने वाले संस्करण से मेल नहीं खा सकता है। सामान्य तौर पर (उम्मीद है) यह बहुत ज्यादा समस्या नहीं है; इस लेखन के रूप में JDK6 एंड-ऑफ-लाइफ है और JDK8 अभी जारी नहीं किया गया है (अनुमान है कि जहां हमें छोड़ देता है)। लेकिन यदि आपको कई संस्करण चलाने की आवश्यकता है, तो आपको आवश्यकतानुसार होस्ट पर JAVA_HOME सेट करने में सक्षम होना चाहिए। यद्यपि यह अतिरिक्त जटिलता का परिचय देता है, यह केवल जावा के विभिन्न संस्करणों का उपयोग करने वाली परियोजनाओं के साथ काम करने के लिए वैग्रैंट रनटाइम बनाए रखने की तुलना में कम जटिलता है।

दिलचस्प सवाल यह है कि कंटेनरलेस वेब एप्लिकेशन का क्या करना है। क्या वेब सर्वर (इस मामले में आवेदन के लिए आंतरिक) को वीएम के अंदर चलाया जाना चाहिए जैसा कि हमने बाहरी वेब सर्वर के लिए किया था? या मेजबान के रूप में हम स्वसंपूर्ण आवेदन के लिए चला रहे हैं? कंटेनरलेस वेब एप्लिकेशन के लिए, चिंता करने के लिए कोई बाहरी वेब सर्वर नहीं है, लेकिन अभी भी एक डेटाबेस होने की संभावना है। इस स्थिति में हम हाइब्रिड दृष्टिकोण अपना सकते हैं। एक कंटेनर रहित वेब ऐप चलाना अनिवार्य रूप से स्टैंडअलोन एप्लिकेशन को चलाने के समान है, इसलिए यह आपके कोड को होस्ट मशीन पर संकलित करने और चलाने के लिए प्रभावी होगा। लेकिन इसमें शामिल एक डेटाबेस के साथ वहाँ अभी भी पर्याप्त जटिलता और विन्यास है कि यह समझ में आता है कि डेटाबेस सर्वर अपने वैगनेंट वीएम पर है।

उम्मीद है कि यह जावा डेवलपर्स को देता है जो वैग्रांट में रुचि रखते हैं कि इसे कैसे उपयोग किया जाए।


Windows OS होस्ट और Linux OS VM के लिए, X11 के माध्यम से होस्ट (Windows) पर चल रहे Linux VM पर IntelliJ को चलाने के बारे में आपके क्या विचार हैं?
केविन मेरेडिथ

3
महान प्रश्न: मैंने इसका उल्लेख नहीं किया, लेकिन मैंने वैग्रेंट वीएम के अंदर आईडीई चलाने के साथ बहुत सारे परीक्षण किए, और पाया कि प्रदर्शन भयानक था ... जवाब देने के लिए एक मेनू पर क्लिक करने में लगभग 12 सेकंड लगे। मैंने ऐसी चीजों की कोशिश की: एक तेज सिफर निर्दिष्ट करें, X11 के लिए संपीड़न का उपयोग करें, और वीएम वीडियो रैम को बढ़ाएं, केवल 4 सेकंड तक प्रतिक्रिया समय प्राप्त करने के लिए जो अभी भी अनुपयोगी था। इसलिए मेरा विचार है कि वैगंट को आईडीई चलाने का इरादा नहीं है।
Jay

मुझे लगता है कि आपको इसे एक शॉट देना चाहिए - हालांकि मैंने वर्चुअलबॉक्स 2 डी त्वरण को सक्षम नहीं किया है क्योंकि यह विंडोज होस्ट के लिए है (और मेरे पास विंडोज होस्ट नहीं था)। अन्य प्रदर्शन विचार जो मुझे आज़माने के लिए नहीं मिले, उनमें शामिल हैं: VMWare के प्रदाता के पास विशेष ग्राफिक्स अनुकूलन होने की अफवाह है, वीआरडीपी की कोशिश कर सकता है जो कि X11 की तुलना में बेहतर प्रदर्शन हो सकता है, NX सर्वर को X11 से तेज होना चाहिए, और अंत में मसाला है- space.org। अगर आपको कुछ भी अच्छा लगता है, तो कृपया यहाँ वापस पोस्ट करें क्योंकि मुझे इसके बारे में सुनना अच्छा लगेगा!
Jay

2
मैंने एक अतिथि VM के अंदर IntelliJ का परीक्षण नहीं किया है (और अतिथि में धीमेपन के साथ सह-कार्यकर्ता के अनुभव नहीं दे सकता है)। हालाँकि, मैंने 'वज्रंट - अप एंड रनिंग' में निम्नलिखित बातें पढ़ीं: Shared folders incur a heavy performance penalty within the virtual machine when there is heavy I/ O, so they should only be used for source files. Any compilation step, database files, and so on should be done outside the shared folder filesystem inside the guest filesystem itself.इस पुस्तक का कथन (वैगरेंट क्रिएटर द्वारा लिखित) मेजबान वीएम में संकलन के खिलाफ तर्क देता है, नहीं?
केविन मेरेडिथ

4
उद्धरण में "वर्चुअल मशीन के भीतर एक भारी प्रदर्शन जुर्माना" का उल्लेख है और मेजबान के लिए एक वैश्विक प्रदर्शन दंड का उल्लेख नहीं है, इसलिए मुझे लगता है कि यहां संदर्भ वीएम के अंदर प्रदर्शन / संचालन के लिए है । उस संदर्भ में, मैं इस उद्धरण की व्याख्या प्रदर्शन की भविष्यवाणी करने के लिए करता हूं, जब अतिथि के रूप में किया गया संकलन अतिथि के रूप में अतिथि बनाम संकलन की सिफारिश करने के विरोध में किया जाता है। क्या आप इस उद्धरण के संदर्भ के बारे में अधिक कह सकते हैं? क्या पुस्तक इस परिदृश्य को विशेष रूप से संबोधित कर रही है? बेशक यह सब वास्तविक परीक्षण के अधीन है :)
Jay

3

मुझे पिछले वर्ष के दौरान इस विषय में दिलचस्पी थी :)

मेरा समाधान झंडे के साथ एक योनि मशीन को कॉन्फ़िगर करना है। उदाहरण के लिए इस ध्वज में से एक डेस्कटॉप गुई को सक्षम करता है क्योंकि कुछ डेवलपर होस्ट मशीन पर कोड करना पसंद करते हैं जबकि अन्य डेस्कटॉप और आईडीई के साथ अधिक एकीकृत वातावरण रखना पसंद करते हैं।

डेस्कटॉप सुस्ती का सामना करने के लिए आपको एक बहुत ही उपयोगी आवारा प्लगइन स्थापित करना चाहिए (हाँ ... योनि में प्लगइन्स हैं जो विकास के माहौल को बेहतर बनाते हैं) इस तरह से: आवारा प्लगइन आवारा- vbguest स्थापित करते हैं यह प्लगइन हर अतिथि पर वर्चुअल बॉक्स अतिथि जोड़ देगा वर्चुअलबॉक्स इंटरफ़ेस का उपयोग करते समय इसे प्रयोग करने योग्य बनाएं। फिर इस तरह से Vagrantfile को संपादित करने के लिए gui को सक्षम करें:

config.vm.provider "virtualbox" करें | vb | vb.gui = सत्य अंत

साझा फ़ोल्डर प्रदर्शन को गति देने के बजाय मैं rsync का उपयोग करने का सुझाव देता हूं: config.vm.synced_folder "./git", "/ home / vagant / git", टाइप करें: "rsync", rsync__exclude: ".git /" इस में। जिस तरह से होस्ट पर स्रोत कोड संपादित किया जाता है और फिर अतिथि को rsync-ed।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.