mabrarov commented on a change in pull request #24:
URL: https://github.com/apache/maven-ear-plugin/pull/24#discussion_r523751706



##########
File path: src/site/apt/modules.apt.vm
##########
@@ -116,6 +116,30 @@ EAR Modules
 
   * <<moduleId>> - sets the id of the module in the generated application.xml.
 
+  * <<libDirectory>> - sets archive directory which contains Java libraries 
(JARs)
+  packaged into archive. Default is <<<null>>> meaning that archive doesn't
+  contain packaged libraries.
+  If libraries are located at the root of archive then use single slash ('/')
+  to configure that.
+  If <<<libDirectory>>> is <<<null>>> then <<<Class-Path>>> setting of module
+  <<<MANIFEST.MF>>> is modified to reference libraries which are packaged in 
EAR.
+  Modification here means:
+
+    * If <<<MANIFEST.MF>>> has no <<<Class-Path>>> setting then it is added.
+
+    * Existing elements of <<<Class-Path>>> setting which match libraries 
packaged
+    in EAR are replaced with references to the matching libraries in EAR.
+
+    * Other libraries packaged in EAR are appended to <<<Class-Path>>> setting 
in order
+    of EAR dependency on library if
+    {{{./ear-mojo.html#skipClassPathModification}skipClassPathModification}} 
parameter
+    is false.
+
+  If <<<libDirectory>>> is not <<<null>>> and if

Review comment:
       Sorry, but I didn't get your note. 
   `libDirectory` here is a property of EAR module. It's not the target 
location where the shared libraries of skinny EAR module are moved (refer to 
`defaultLibBundleDir` option of plugin configuration). It's the source location 
inside EAR module from which shared libraries (libraries of EAR module which 
are among EAR dependencies) are moved.
   `libDirectory` has default value depending on type of EAR module, so it's 
not always `null`. The need of `libDirectory` property comes from modules with 
non-standard layout. For example, JBoss Packaging Maven Plugin can package SAR 
putting libraries into a user defined directory of SAR (i.e. not into the 
default root of SAR).

##########
File path: src/site/apt/modules.apt.vm
##########
@@ -116,6 +116,30 @@ EAR Modules
 
   * <<moduleId>> - sets the id of the module in the generated application.xml.
 
+  * <<libDirectory>> - sets archive directory which contains Java libraries 
(JARs)
+  packaged into archive. Default is <<<null>>> meaning that archive doesn't
+  contain packaged libraries.
+  If libraries are located at the root of archive then use single slash ('/')
+  to configure that.
+  If <<<libDirectory>>> is <<<null>>> then <<<Class-Path>>> setting of module
+  <<<MANIFEST.MF>>> is modified to reference libraries which are packaged in 
EAR.
+  Modification here means:
+
+    * If <<<MANIFEST.MF>>> has no <<<Class-Path>>> setting then it is added.
+
+    * Existing elements of <<<Class-Path>>> setting which match libraries 
packaged
+    in EAR are replaced with references to the matching libraries in EAR.
+
+    * Other libraries packaged in EAR are appended to <<<Class-Path>>> setting 
in order
+    of EAR dependency on library if
+    {{{./ear-mojo.html#skipClassPathModification}skipClassPathModification}} 
parameter
+    is false.
+
+  If <<<libDirectory>>> is not <<<null>>> and if

Review comment:
       Sorry, but I didn't get your note.
   
   `libDirectory` here is a property of EAR module. It's not the target 
location where the shared libraries of skinny EAR module are moved (refer to 
`defaultLibBundleDir` option of plugin configuration). It's the source location 
inside EAR module from which shared libraries (libraries of EAR module which 
are among EAR dependencies) are moved.
   
   `libDirectory` has default value depending on type of EAR module, so it's 
not always `null`. The need of `libDirectory` property comes from modules with 
non-standard layout. For example, JBoss Packaging Maven Plugin can package SAR 
putting libraries into a user defined directory of SAR (i.e. not into the 
default root of SAR).




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
[email protected]


Reply via email to