মাভেনের নির্ভরতা ব্যবস্থাপনা এবং নির্ভরতার মধ্যে পার্থক্য

Question

মধ্যে পার্থক্য কি dependencyManagementএবং dependencies? আমি অ্যাপাচি মাভেন ওয়েব সাইটে ডকগুলি দেখেছি। দেখে মনে হয় যে এর অধীনে সংজ্ঞায়িত একটি নির্ভরতা dependencyManagementসংস্করণ নির্দিষ্ট না করেই তার শিশু মডিউলগুলিতে ব্যবহার করা যেতে পারে।

উদাহরণ স্বরূপ:

একটি প্যারেন্ট প্রজেক্ট (প্রো-পার) নীচে একটি নির্ভরতা নির্ধারণ করে dependencyManagement:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8</version>
    </dependency>
 </dependencies>
</dependencyManagement>

তারপরে প্রো-পার্টের সন্তানের মধ্যে আমি জুনিটটি ব্যবহার করতে পারি:

  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
    </dependency>
 </dependencies>

যাইহোক, আমি ভাবছি প্যারেন্ট পোমে জুনিট সংজ্ঞা দেওয়া দরকার কিনা? কেন এটি প্রয়োজনীয় মডিউলে সরাসরি সংজ্ঞায়িত করা হয় না?

Answer 1

নির্ভরতা পরিচালনা সমস্ত শিশুদের উত্তরাধিকার সূত্রে প্রাপ্ত নির্ভরতা যুক্ত না করে নির্ভরতা সংস্করণগুলির পরিচালনাকে একীভূত এবং কেন্দ্রিয় করতে দেয়। এটি বিশেষত কার্যকর যখন আপনার কাছে একটি প্রকল্প থাকে (যেমন একাধিক) যা সাধারণ পিতামাতার উত্তরাধিকার সূত্রে আসে।

এর আরেকটি অত্যন্ত গুরুত্বপূর্ণ ব্যবহারের ক্ষেত্রে dependencyManagementহ'ল ট্রানজিটিভ নির্ভরতাগুলিতে ব্যবহৃত শিল্পকর্মগুলির সংস্করণগুলির নিয়ন্ত্রণ। এটি একটি উদাহরণ ছাড়া ব্যাখ্যা করা কঠিন। ভাগ্যক্রমে, এটি ডকুমেন্টেশনে চিত্রিত করা হয়েছে।

Comments

সুতরাং, চাইল্ড প্রজেক্টের পম এর নির্ভরতা ঘোষণার প্রয়োজনীয়তা কি তারা <d dependencyManagement> বিভাগে প্যারেন্ট প্রজেক্টের পমে ঘোষণা করলেও? নির্ভরতা একরকম উত্তরাধিকার করা সম্ভব?

— জনি-বি-গোডে 23'12

হ্যাঁ, আপনি তাদের ব্যবহার করছেন কিনা তা দেখানোর জন্য আপনার এখনও শিশু পিওএম এ সেগুলি সংজ্ঞায়িত করতে হবে। এগুলি প্রকৃতপক্ষে <dependencyManagement>পিতামাতার POM এ থাকায় শিশু প্রকল্পগুলিতে তাদের অন্তর্ভুক্ত করা হয় না । <dependencyManagement>সংস্করণ, স্কোপ এবং প্রতিটি নির্ভরতার জন্য বহিরাগতকরণের কেন্দ্রীকরণে নির্ভরতা আবদ্ধ করা , আপনি কখন এবং কখন এটি ব্যবহার করার সিদ্ধান্ত নেন। নির্ভরতা পরিচালনার জন্য মাভেনের গাইড সমস্ত বিবরণে যায়।

— হটশট 309

দ্বিতীয় অনুচ্ছেদ ( dependencyManagementট্রানজিটিভ নির্ভরতাও নিয়ন্ত্রণ করে) কেবল তখনই সত্য হয় যখন নির্ভরতাগুলি সুস্পষ্টভাবে সেট করা থাকে: stackoverflow.com/questions/28312975/…

— রবার্ট মেটজার

@ জননি-বি-গোউড আপনি এখনও যা করতে পারেন তা হ'ল dependenciesআপনার প্যারেন্ট পমতে একটি নতুন বিভাগ তৈরি করা । আমরা তা করেছি যাতে সমস্ত শিশু প্রকল্পের ডিফল্টরূপে কিছু অ্যাপাচি-কমন্স থাকে এবং সেগুলি সর্বদা ঘোষণা না করে।

— 5

Answer 2

আমি এই প্রশ্নে ফ্যাশনালি দেরিতে আছি, তবে আমি মনে করি এটি গ্রহণীকৃত প্রশ্নের চেয়ে পরিষ্কার সাড়া মূল্যবান (যা সঠিক, তবে প্রকৃত গুরুত্বপূর্ণ অংশটি জোর দেয় না, যা আপনাকে নিজেকে কাটাতে হবে)।

পিতা বা মাতা খুলুন POM সালে মধ্যে মূল পার্থক্য <dependencies>এবং <dependencyManagement>এই হল:

<dependencies>বিভাগে উল্লিখিত নিদর্শনগুলি সর্বদা শিশু মডিউল (গুলি) এর নির্ভরতা হিসাবে অন্তর্ভুক্ত করা হবে।

<dependencyManagement>বিভাগে সুনির্দিষ্ট নিদর্শনগুলি কেবলমাত্র শিশু মডিউলে অন্তর্ভুক্ত হবে যদি সেগুলি <dependencies>শিশু মডিউলের নিজেই বিভাগে নির্দিষ্ট করা থাকে । কেন আপনি ভাল জিজ্ঞাসা? কারণ আপনি পিতামাতার সংস্করণ এবং / বা সুযোগটি নির্দিষ্ট করেছেন এবং শিশু পিওএমের নির্ভরতা নির্দিষ্ট করার সময় আপনি এগুলি ছেড়ে দিতে পারেন। এটি প্রতিটি শিশু মডিউলের সংস্করণ নির্দিষ্ট না করেই শিশু মডিউলগুলির জন্য নির্ভরতার জন্য ইউনিফাইড সংস্করণগুলি আপনাকে সহায়তা করতে পারে।

Comments

কিন্তু এটি কি ওভারহেডের কিছুটা নয়, মূলকে ব্যবহার <dependencyManagement>করে ? চাইল্ড গুলি অনেক ছোট হতে পারে। <dependencies>.pompom

— জেনেজ কুহার

সেটা সত্য. <নির্ভরতা> পরিবর্তে <ডিপেন্ডেন্সি ম্যানেজমেন্ট> ব্যবহার করে একটি ছোট বাচ্চা পোম তৈরি করবে। তবে এটি একটি ব্যয় নিয়ে আসে - এর অর্থ হ'ল সেই নির্ভরতাগুলি সবসময় সমস্ত শিশু মডিউলগুলির জন্য সংজ্ঞায়িত করা হবে। যদি "<d dependencyManagement>" ব্যবহার না করে কেবলমাত্র কয়েকটি শিশু মডিউলগুলির একটি নির্দিষ্ট নির্ভরতা প্রয়োজন তবে কেবলমাত্র প্যারাম পম-এ নির্ভরতা সংস্করণটি নির্ধারণ করে কোন শিশু মডিউলগুলির সেই নির্ভরতা থাকতে হবে তা বেছে নেওয়ার অনুমতি দেওয়া হবে।

— dcoder

@ জেনেজকুহার এটি আমার কাছে বোধগম্য যে আপনি যদি শিশু মডিউলে নির্ভরতা নির্দিষ্ট করে থাকেন তবে এটি পিতামাতার মধ্যে একটিটিকে ছাড়িয়ে যাবে, তবে আমি স্বীকার করি আমার মনে নেই। আমি যখন সুযোগ পাব তখন আমাকে তার জন্য খাঁটি ডকগুলি যাচাই করতে হবে। যদিও এটি সহজ একটি সহজ পিতা-সন্তানের প্রকল্প স্থাপন এবং যাচাই করা সহজ হতে পারে :)

— ডিসকডার

একটি সাধারণ ধারণার জন্য ভাল ব্যাখ্যা - মাভেনের পক্ষে সহজেই নিজের সরঞ্জামটি ব্যাখ্যা করা এতটা কঠিন কেন?

— জিমি_টেরা

আমি যোগ করতে চাই Artifacts specified in the <dependencies> section will ALWAYS be included as a dependency of the child module(s)যে তারা পিতামাতার পাশাপাশি অন্তর্ভুক্ত করা হয়। মনে হয় বাচ্চাদের জন্য নির্ভরতা নির্ধারণ করা সম্ভব নয়, তবে পিতামাতার পক্ষে নয়।

— ক্যাডুসাস

Answer 3

ডকুমেন্টেশন ম্যাভেন সাইটে ভয়ঙ্কর। নির্ভরতা-ব্যবস্থাপনা যা করে তা হ'ল আপনার নির্ভরতা সংজ্ঞাগুলি (সংস্করণ, ব্যতিক্রম ইত্যাদি) প্যারেন্ট পম পর্যন্ত সরানো হয়, তারপরে শিশু পোমগুলিতে আপনাকে কেবল গ্রুপআইডি এবং আর্টিফ্যাক্টআইডি রাখতে হবে। এটি হ'ল (প্যারেন্ট পম শৃঙ্খলা বাদে এবং এর মতো, তবে এটি আসলে জটিল নয় - পিতামাতার স্তরের নির্ভরতাগুলির উপর dependenceManagement জিততে পারে - তবে সেই বা আমদানি সম্পর্কে যদি আপনার কোন প্রশ্ন থাকে তবে ম্যাভেন ডকুমেন্টেশনটি আরও ভাল)।

মাভেন সাইটে 'ক', 'বি', 'সি' আবর্জনা পড়ার পরে এবং বিভ্রান্ত হওয়ার পরে, আমি তাদের উদাহরণটি আবার লিখেছি। সুতরাং আপনার যদি 2 টি প্রকল্প থাকে (প্রজ 1 এবং প্রজ 2) যা একটি সাধারণ নির্ভরতা ভাগ করে (বিটাশার্ড) আপনি সেই নির্ভরতা পিতাম পম পর্যন্ত সরিয়ে নিতে পারেন। আপনি যখন এটির সাথে রয়েছেন, আপনি অন্য যে কোনও নির্ভরতা (আলফা এবং চার্লি) সরিয়ে নিতে পারেন তবে কেবল যদি এটি আপনার প্রকল্পের জন্য সার্থক হয়। সুতরাং পূর্ববর্তী বাক্যগুলিতে বর্ণিত পরিস্থিতির জন্য, এখানে প্যারেন্ট পোমে নির্ভরতা পরিচালনার সমাধান রয়েছে:

<!-- ParentProj pom -->
<project>
  <dependencyManagement>
    <dependencies>
      <dependency> <!-- not much benefit defining alpha here, as we only use in 1 child, so optional -->
        <groupId>alpha</groupId>
        <artifactId>alpha</artifactId>
        <version>1.0</version>
        <exclusions>
          <exclusion>
            <groupId>zebra</groupId>
            <artifactId>zebra</artifactId>
          </exclusion>
        </exclusions>
      </dependency>
      <dependency>
        <groupId>charlie</groupId> <!-- not much benefit defining charlie here, so optional -->
        <artifactId>charlie</artifactId>
        <version>1.0</version>
        <type>war</type>
        <scope>runtime</scope>
      </dependency>
      <dependency> <!-- defining betaShared here makes a lot of sense -->
        <groupId>betaShared</groupId>
        <artifactId>betaShared</artifactId>
        <version>1.0</version>
        <type>bar</type>
        <scope>runtime</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>
</project>

<!-- Child Proj1 pom -->
<project>
  <dependencies>
    <dependency>
      <groupId>alpha</groupId>
      <artifactId>alpha</artifactId>  <!-- jar type IS DEFAULT, so no need to specify in child projects -->
    </dependency>
    <dependency>
      <groupId>betaShared</groupId>
      <artifactId>betaShared</artifactId>
      <type>bar</type> <!-- This is not a jar dependency, so we must specify type. -->
    </dependency>
  </dependencies>
</project>

<!-- Child Proj2 -->
<project>
  <dependencies>
    <dependency>
      <groupId>charlie</groupId>
      <artifactId>charlie</artifactId>
      <type>war</type> <!-- This is not a jar dependency, so we must specify type. -->
    </dependency>
    <dependency>
      <groupId>betaShared</groupId> 
      <artifactId>betaShared</artifactId> 
      <type>bar</type> <!-- This is not a jar dependency, so we must specify type. -->
    </dependency>
  </dependencies>
</project>

Comments

কিছুটা অফ-টপিক প্রশ্ন: নির্ভরতা টাইপ "বার" এর অর্থ কী? আমি মাভেন ডকুমেন্টেশনের পম উদাহরণে দেখেছি কিন্তু কোনও সংজ্ঞা পাইনি। আমি ধরে নিয়েছি এটি "যুদ্ধ" বা "জার" টাইপ ছিল তবে আমি এটি আপনার মতো অন্যান্য উদাহরণে দেখতে পাচ্ছি।

— কেউই

কেউই নয় - সুতরাং এটি অন্য একটি সংরক্ষণাগার ধরণের জন্য কেবল স্থানধারক। 'ফু' ব্যবহার করার মতো। অথবা যদি কেউ এক্সটেনশন 'বার' দিয়ে কাস্টম টাইপ করে থাকে তবে এটি ব্যবহার করা যেতে পারে। এবং সেখানে প্রচুর অস্পষ্ট সংরক্ষণাগার রয়েছে। সর যেমন, jboss পরিষেবা সংরক্ষণাগার।

— ম্যাটিসি

আপনার উদাহরণটি বেশ স্পষ্ট, এবং ডকুমেন্টেশন থেকে আমি নিজের থেকে কী তৈরি করেছি তা পুনরায় নিশ্চিত করে। আপনি কি এটি ম্যাভেন প্রকল্পে জমা দিয়েছেন? আপনার উদাহরণ অধ্যয়ন করে, আমি একটি পিওএম সহজতর করার প্রস্তুতি নিচ্ছি যার উভয়ই রয়েছে এবং এর জন্য কেবল নির্ভরশীলতার ঘোষণার দরকার, যে প্রকল্পের সাথে এটি সম্পর্কিত কোনও বাচ্চা নেই।

— ডেভিড এ গ্রে 21

ঠিক আছে, আমি ডিপেন্ডেন্সি ম্যানেজমেন্ট নোডটি ফেলে রেখেছিলাম, যতক্ষণ না এটি আমার কাছে ঘটে থাকে ততক্ষণে এটি ছেড়ে দেওয়া আমাকে কোনও শিশু পিওএম-এর জন্য ন্যূনতম সংস্করণ স্থাপন করতে দেয় যা পরোক্ষভাবে নির্ভরতা গাছটিতে প্রবেশ করে find উদাহরণস্বরূপ, javax.cache.cache-apI তাড়া করার সময়, আমি একটি উল্লেখযোগ্যভাবে নতুন সংস্করণ ১.০.০ (বনাম ০.০.০) আবিষ্কার করেছি যা পাশাপাশি ব্যবহার করা যেতে পারে।

— ডেভিড এ গ্রে

এই ব্যাখ্যা pefect হয়।

— স্মার্ট কোডার

Answer 4

এটি যেমন আপনি বলেছেন মত; dependencyManagementচাইল্ড পিওএম ফাইলে রেফারেন্সগুলি সহজ করে একটি সাধারণ পিওএম ফাইলের মধ্যে সমস্ত নির্ভরতা তথ্য টানতে ব্যবহৃত হয়।

আপনি যখন একাধিক শিশু প্রকল্পের আওতায় পুনরায় টাইপ করতে চান না এমন একাধিক বৈশিষ্ট্য রয়েছে তখন এটি কার্যকর হয়।

শেষ পর্যন্ত, dependencyManagementএকাধিক প্রকল্প জুড়ে ব্যবহার করার জন্য একটি শৈল্পিকের একটি স্ট্যান্ডার্ড সংস্করণ সংজ্ঞায়িত করতে ব্যবহার করা যেতে পারে।

Comments

সুতরাং, নির্ভরতা উত্তরাধিকারসূত্রে হয় না? চাইল্ড প্রোজেক্টের পোমে যেভাবেই এর ঘোষণা করা দরকার?

— জনি-বি-গোডে

হ্যাঁ, আপনাকে শিশু প্রকল্পগুলিতে যে কোনও উপায়ে ঘোষণা করতে হবে, তবে কোনও সংস্করণ নির্দিষ্ট না করেই।

— পাভেল ভ্লাসভ

আপনি যখন পিতা-মাতার সন্তানের সম্পর্কযুক্ত একাধিক জাভা প্রকল্পগুলিতে সংস্করণগুলি পরিচালনা করতে চান তখন এই দৃশ্যটি কার্যকর।

— অনুজ কুমার

Answer 5

আমার মতে এখনও একটি জিনিস যথেষ্ট পরিমাণে হাইলাইট করা হয়নি এবং তা হ'ল অবাঞ্ছিত উত্তরাধিকার ।

এখানে একটি বর্ধিত উদাহরণ:

আমি আমার parentপোমে ঘোষণা করি :

<dependencies>
        <dependency>
            <groupId>com.google.guava</groupId>
            <artifactId>guava</artifactId>
            <version>19.0</version>
        </dependency>
</dependencies>

বুম! আমি আমার মধ্যে এটা আছে Child A, Child Bএবং Child Cমডিউল:

• কার্যকরভাবে শিশু পোম দ্বারা উত্তরাধিকারসূত্রে প্রাপ্ত
• পরিচালনা করার জন্য একটি একক জায়গা
• চাইল্ড পমসে কোনও কিছুর পুনরায় ঘোষণার দরকার নেই
• আমি এখনও redelcare এবং ওভাররাইড করতে পারেন version 18.0একটি Child Bযদি আমি করতে চাই।

তবে যদি আমি শেষ পর্যন্ত পেয়ারা প্রয়োজন না Child C, এবং ভবিষ্যত Child Dএবং Child Eমডিউলগুলির মধ্যেও না?

তারা এখনও এটির উত্তরাধিকারী হবে এবং এটি অনাকাঙ্ক্ষিত! এটি ঠিক জাভা গড অবজেক্ট কোডের গন্ধের মতো, যেখানে আপনি শ্রেণি থেকে কিছু দরকারী বিট এবং এক টন অযাচিত স্টাফও পেয়ে যান।

এখানেই <dependencyManagement>খেলতে আসে। আপনি যখন এটি আপনার পিতামাতার পোমে যুক্ত করেন, তখন আপনার সমস্ত শিশু এটি দেখে স্টপ করে । এবং এইভাবে আপনাকে প্রতিটি স্বতন্ত্র মডিউলে যেতে বাধ্য হয় যা এটির প্রয়োজন হয় এবং এটি আবার ঘোষণা করে ( Child Aএবং Child Bযদিও সংস্করণ ছাড়াই)।

এবং, স্পষ্টতই, আপনি এটির জন্য করবেন না Child C, এবং এইভাবে আপনার মডিউলটি জোঁক থাকবে।

Comments

<d dependencyManagement> এ উল্লিখিত নির্ভরতা কি প্যারেন্ট পম প্রকল্পের জন্য ডাউনলড হয়ে যাবে?

— জাসপ্রীত জলি

আপনি কি নিশ্চিত যে আমরা যদি <dependencyManagement>প্যারেন্ট পম ব্যবহার করি তবে ডিফল্টরূপে নির্ভরতাগুলি শিশু পমগুলিতে উত্তরাধিকার সূত্রে প্রাপ্ত হবে না? কারণ দস্তাবেজে: maven.apache.org/guides/intr پيداوار/… এর দ্বিতীয় ব্যবহারের ব্যাখ্যা দেওয়ার সময় <dependencyManagement>মনে হচ্ছে এটি ডিফল্টরূপে উত্তরাধিকার সূত্রে প্রাপ্ত হবে। এক লাইনে তারা বলছেন যে: "যখন প্রকল্প বি তে চালিত হয়, তখন ক, ক, ডি, এবং ডি এর সংস্করণ ০.০ ব্যবহার করা হবে তবে তাদের পোমে বর্ণিত সংস্করণ নির্বিশেষে" বি "ব্যবহৃত না হলেও ব্যবহৃত হবে প্রকল্প বি

— চিরাগ সোনি

এটি নিজে চেষ্টা করে দেখুন

— আন্দ্রেজ

Answer 6

সেখানে পার্থক্য outlining কয়েক উত্তর <depedencies>এবং <dependencyManagement>ম্যাভেন সঙ্গে ট্যাগ।

তবে কয়েকটি পয়েন্ট নীচে একটি সংক্ষিপ্তভাবে বিশদভাবে বর্ণনা করা হয়েছে:

1. <dependencyManagement>বিভিন্ন মডিউল জুড়ে ব্যবহৃত সমস্ত নির্ভরতা (চাইল্ড পম স্তরে ব্যবহৃত) একত্রীকরণের অনুমতি দেয় - স্পষ্টতা , কেন্দ্রীয় নির্ভরতা সংস্করণ পরিচালনা
2. <dependencyManagement>প্রয়োজনের ভিত্তিতে সহজেই ডাউনগ্রেড নির্ভরতাগুলি আপগ্রেড / ডাউনগ্রেড করতে দেয়, অন্য পরিস্থিতিতে এটি প্রতিটি শিশু পম স্তরে প্রয়োগ করা প্রয়োজন - ধারাবাহিকতা
3. <dependencies>ট্যাগে সরবরাহিত নির্ভরতা সর্বদা আমদানি করা হয়, যখন <dependencyManagement>প্যারেন্ট পমতে সরবরাহ করা নির্ভরতা কেবল তখনই আমদানি করা হবে যখন চাইল্ড পমের তার <dependencies>ট্যাগটিতে প্রাসঙ্গিকভাবে প্রবেশ রয়েছে ।

Answer 7

দুঃখিত আমি পার্টিতে খুব দেরি করেছি।

mvn dependency:treeকমান্ড ব্যবহার করে পার্থক্যটি ব্যাখ্যা করার চেষ্টা করি

নীচের উদাহরণ বিবেচনা করুন

অভিভাবক POM - আমার প্রকল্প

<modules>
    <module>app</module>
    <module>data</module>
</modules>

<dependencies>
    <dependency>
        <groupId>com.google.guava</groupId>
        <artifactId>guava</artifactId>
        <version>19.0</version>
    </dependency>
</dependencies>

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-lang3</artifactId>
            <version>3.9</version>
        </dependency>
    </dependencies>
</dependencyManagement>

চাইল্ড পিওএম - ডেটা মডিউল

<dependencies>
    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-lang3</artifactId>
    </dependency>
</dependencies>

চাইল্ড পিওএম - অ্যাপ্লিকেশন মডিউলটির কোনও অতিরিক্ত নির্ভরতা নেই, তাই নির্ভরতা খালি রেখে)

 <dependencies>
</dependencies>

mvn dependency:treeকমান্ড চলমান , আমরা নিম্নলিখিত ফলাফল পেতে

Scanning for projects...
------------------------------------------------------------------------
Reactor Build Order:

MyProject
app
data

------------------------------------------------------------------------
Building MyProject 1.0-SNAPSHOT
------------------------------------------------------------------------

--- maven-dependency-plugin:2.8:tree (default-cli) @ MyProject ---
com.iamvickyav:MyProject:pom:1.0-SNAPSHOT
\- com.google.guava:guava:jar:19.0:compile

------------------------------------------------------------------------
Building app 1.0-SNAPSHOT
------------------------------------------------------------------------

--- maven-dependency-plugin:2.8:tree (default-cli) @ app ---
com.iamvickyav:app:jar:1.0-SNAPSHOT
\- com.google.guava:guava:jar:19.0:compile

------------------------------------------------------------------------
Building data 1.0-SNAPSHOT
------------------------------------------------------------------------

--- maven-dependency-plugin:2.8:tree (default-cli) @ data ---
com.iamvickyav:data:jar:1.0-SNAPSHOT
+- org.apache.commons:commons-lang3:jar:3.9:compile
\- com.google.guava:guava:jar:19.0:compile

গুগল পেয়ারা প্রতিটি মডিউলে (প্যারেন্ট সহ) নির্ভরতা হিসাবে তালিকাভুক্ত হয় , তবে অ্যাপাচি কমন্স কেবলমাত্র ডেটা মডিউলে নির্ভরশীল হিসাবে তালিকাভুক্ত হয় (এমনকি পিতামহুল মডিউলটিতেও নয়)

Answer 8

যদি নির্ভরতা শীর্ষ স্তরের পমের নির্ভরতাতা ব্যবস্থাপনা উপাদানকে সংজ্ঞায়িত করা হয়, তবে শিশু প্রকল্পটি নির্ভরতার সংস্করণটিকে স্পষ্টভাবে তালিকাভুক্ত করতে হবে না। যদি শিশু প্রকল্পটি কোনও সংস্করণ সংজ্ঞায়িত করে, এটি শীর্ষ স্তরের POM এর নির্ভরতা ব্যবস্থাপনা বিভাগে তালিকাভুক্ত সংস্করণটিকে ওভাররাইড করে। অর্থাৎ, নির্ভরশীলতা পরিচালন সংস্করণ কেবল তখনই ব্যবহৃত হয় যখন শিশু সরাসরি কোনও সংস্করণ ঘোষণা করে না।

Comments

আমি বিশ্বাস করি এই বিবৃতিটি সঠিক নাও হতে পারে। মাভেনের ডিপেন্ডেন্সি ম্যানেজমেন্ট উদাহরণগুলিতে (# 2), তারা বলে যে একটি সংস্করণ সহ প্যারেন্ট পমতে নির্ধারিত নির্ভরতাগুলি চাইল্ড পম-এ উল্লিখিত সংস্করণটিকে ওভাররাইড করে: "যখন মাভেন প্রকল্পের বি সংস্করণে চালিত হয় শিল্পকর্মের 1.0, সংস্করণ 1.0, এ, বি, সি , এবং d তাদের পোমে বর্ণিত সংস্করণ নির্বিশেষে ব্যবহার করা হবে। "

— দেবদনকে

@devdanke অন্তত, অন্ধকার m2e বিষয় একটি সতর্কবার্তা: সংস্করণ পরিচালিত অগ্রাহ্য ... জন্য ... ।

— জেরোল্ডব্রোজার মনিকার

Answer 9

পিতা বা মাতা খুলুন POM সালে মধ্যে মূল পার্থক্য <dependencies>এবং <dependencyManagement>এই হল:

<dependencies>বিভাগে উল্লিখিত নিদর্শনগুলি সর্বদা শিশু মডিউল (গুলি) এর নির্ভরতা হিসাবে অন্তর্ভুক্ত করা হবে।

বিভাগে সুনির্দিষ্ট নিদর্শনগুলি কেবলমাত্র শিশু মডিউলে অন্তর্ভুক্ত হবে যদি সেগুলি শিশু মডিউলের নিজেই বিভাগে নির্দিষ্ট করা থাকে। কেন আপনি ভাল জিজ্ঞাসা? কারণ আপনি পিতামাতার সংস্করণ এবং / বা সুযোগটি নির্দিষ্ট করেছেন এবং শিশু পিওএমের নির্ভরতা নির্দিষ্ট করার সময় আপনি এগুলি ছেড়ে দিতে পারেন। এটি প্রতিটি শিশু মডিউলের সংস্করণ নির্দিষ্ট না করেই শিশু মডিউলগুলির জন্য নির্ভরতার জন্য ইউনিফাইড সংস্করণগুলি আপনাকে সহায়তা করতে পারে।

Answer 10

কেবল আমার নিজের কথায়, আপনার parent-project2 ধরণের নির্ভরতা সরবরাহ করতে সহায়তা করে:

• অন্তর্নিহিত নির্ভরতা : <dependencies>আপনার বিভাগে সংজ্ঞায়িত সমস্ত নির্ভরতা সমস্ত parent-projectদ্বারা উত্তরাধিকার সূত্রে প্রাপ্তchild-projects
• সুস্পষ্ট নির্ভরতা : আপনাকে নির্বাচন করতে দেয়, নির্ভরতাগুলি আপনার প্রয়োগ করতে দেয় child-projects। এইভাবে, আপনি <dependencyManagement>বিভাগটি ব্যবহার করেন , আপনি যে বিভিন্ন নির্ভরতাগুলি ব্যবহার করতে যাচ্ছেন তা আপনার ভিন্নতার জন্য ঘোষণা করতে child-projects। সর্বাধিক গুরুত্বপূর্ণ বিষয়টি হ'ল, এই বিভাগে, আপনি একটি <version>এমন সংজ্ঞা দেন যাতে আপনার নিজের কাছে এটি আবার ঘোষণা করতে না হয় child-project।

<dependencyManagement>আমার দৃষ্টিকোণ মধ্যে (আমি সংশোধন যদি আমি ভুল বলছি) শুধু আপনি আপনার নির্ভরতা সংস্করণ কেন্দ্রীভূত সাহায্য করে দরকারী। এটি এক ধরণের সহায়ক বৈশিষ্ট্যের মতো।

Answer 11

Eclipse এ, আরও একটি বৈশিষ্ট্য রয়েছে dependencyManagement। dependenciesএটি ব্যতীত কখন ব্যবহৃত হয়, পম ফাইলে ভিত্তিহীন নির্ভরতা লক্ষ্য করা যায়। যদি dependencyManagementএটি ব্যবহার করা হয় তবে অমীমাংসিত নির্ভরতাগুলি পোম ফাইলে নজরে পড়ে না এবং ত্রুটিগুলি কেবল জাভা ফাইলগুলিতেই উপস্থিত হয়। (আমদানি এবং এই জাতীয় ...)

Answer 12

দুজনের মধ্যে পার্থক্যটি ম্যাভেন ওয়েবসাইট ডক্সে উপলব্ধ নির্ভরতা ব্যবস্থাপনা উপাদানটির প্রয়োজনীয় এবং পর্যাপ্ত সংজ্ঞা বলে মনে হয় তা সবচেয়ে ভালভাবে এনেছে:

dependencyManagement

"এইগুলির থেকে উত্তরাধিকারসূত্রে প্রাপ্ত প্রকল্পগুলির জন্য ডিফল্ট নির্ভরতা সম্পর্কিত তথ্য this এই বিভাগের নির্ভরতাগুলি তাত্ক্ষণিকভাবে সমাধান করা হয় না one পরিবর্তে, যখন এর থেকে প্রাপ্ত কোনও পিওএম একটি ম্যাচিং গ্রুপ-আইডি এবং আর্টিফ্যাক্টআইডি দ্বারা বর্ণিত নির্ভরতা ঘোষণা করে, এই বিভাগের সংস্করণ এবং অন্যান্য মানগুলি তারা যদি ইতিমধ্যে নির্দিষ্ট না করে থাকে তবে সেই নির্ভরতার জন্য ব্যবহৃত হয় "" [ https://maven.apache.org/ref/3.6.1/maven-model/maven.html ]

এটি ভিন্ন পৃষ্ঠায় উপলভ্য আরও কিছু তথ্যের সাথে পড়তে হবে:

"..নির্ভরতা ব্যবস্থাপনা বিভাগের সাথে নির্ভরতা রেফারেন্সের সাথে ম্যাচ করার জন্য তথ্যের ন্যূনতম সেটটি আসলে {গ্রুপআইডি, আর্টিফ্যাক্টআইডি, টাইপ, শ্রেণিবদ্ধ}} বেশিরভাগ ক্ষেত্রে, এই নির্ভরতাগুলি কোনও শ্রেণিবদ্ধকারী ছাড়াই জার শিল্পগুলি বোঝায়। টাইপ ফিল্ডের জন্য ডিফল্ট বয়ামি এবং ডিফল্ট শ্রেণিবদ্ধকারী নাল হওয়ায় এটি আমাদের {গ্রুপআইড, আর্টিফ্যাক্টআইডি to এ সেট করা পরিচয়টি শর্টহ্যান্ড করতে দেয়। [ https://maven.apache.org/guides/intr پيداوار/intr پيداوار-to-d dependency-mechanism.html ]

সুতরাং, গ্রুপআইডি, আর্টিফ্যাক্টআইডি, টাইপ, শ্রেণিবদ্ধ, ব্যতীত কেবলমাত্র সংস্করণ নয় - নির্ভরতা উপাদানগুলির সমস্ত উপ-উপাদান (সুযোগ, ব্যতিক্রম ইত্যাদি), বিন্দুতে লকডাউন / ডিফল্টের জন্য উপলব্ধ (এবং এভাবে উত্তরাধিকার সূত্রে প্রাপ্ত এরপরে) আপনি নির্ভরতা এলিমেন্টের মধ্যে নির্ভরতা নির্দিষ্ট করে। আপনি যদি টাইপ এবং শ্রেণিবদ্ধ সাব-এলিমেন্টগুলির সাথে নির্ভরশীলতা নির্দিষ্ট করে থাকেন (যথাক্রমে সব উপ-উপাদানগুলি পরীক্ষা করার জন্য প্রথম শ্রেণীর ওয়েবপৃষ্ঠা দেখুন) যথাক্রমে জার নয় এবং নাল নয়, আপনার প্রয়োজন হবে {গ্রুপআইড, আর্টিফ্যাক্টআইডি, শ্রেণিবদ্ধ, টাইপ} রেফারেন্স (সমাধান) যে নির্ভরতা ব্যবস্থাপনা উপাদান থেকে উত্পন্ন উত্তরাধিকার যে কোনও সময়ে নির্ভরতা। অন্য, {গ্রুপআইডি, আর্টিফ্যাক্টআইডি ice যথেষ্ট হবে যদি আপনি শ্রেণিবদ্ধ এবং টাইপ (যথাক্রমে জার এবং নাল) টাইপ করার জন্য ডিফল্টগুলি ওভাররাইড না করতে চান। সুতরাং সংজ্ঞাতে ডিফল্ট একটি ভাল কীওয়ার্ড; যে কোনও উপ-উপাদান (গুলি) ছাড়াও,

সুতরাং, নির্ভরতা ব্যবস্থার বাইরে যে কোনও নির্ভরতা উপাদান, কিছু নির্ভরশীলতা ব্যবস্থাপনা উপাদান হিসাবে উল্লেখ হিসাবে বা একক হিসাবে অবিলম্বে সমাধান করা হয় (যেমন স্থানীয় সংগ্রহস্থলে ইনস্টল করা এবং শ্রেণিপথগুলির জন্য উপলব্ধ)।