Difference between revisions of "Talk:FR3403603 Mavenize"
Line 11: | Line 11: | ||
[[User:Tobi|Tobi]] 06:00, 25 October 2011 (UTC) | [[User:Tobi|Tobi]] 06:00, 25 October 2011 (UTC) | ||
*I think the two questions above are meanwhile settled. OK To remove them? | *I think the two questions above are meanwhile settled. OK To remove them? | ||
+ | |||
+ | |||
+ | [[User:Tobi|Tobi]] 08:14, 21 November 2011 (UTC) How to organize "assembly" directory | ||
+ | |||
+ | Here is how I arrived at the qustion: | ||
+ | |||
+ | Right now, there is this problem: the dependency jars are inside the ear, but it seems that they must explicitly be declared in the application.xml to be found by the classloader. | ||
+ | Of course there are alternatives: | ||
+ | They could be moved in the jboss-server's lib directory, this would have the added benefit that the installer could use them, too. | ||
+ | Or, I think there is some additional jboss-descriptor xml file that can be added to the ear for them to be loaded from within the the ear. | ||
+ | |||
+ | But what I really want to get at: I think this decision should be left to the deployer. It might make sense to move those jars into a jboss lib directory (e.g. if you have further web apps that want to use them, too), and I might sense not to do it, | ||
+ | depending on one's individual situation. | ||
+ | |||
+ | So, the actual question is: How should we organize the general directory structure? | ||
+ | |||
+ | Suggestion: | ||
+ | assembly-Directory: Should contain a number of poms for different selections and combinations of the avaiable building blocks. | ||
+ | That assembly directory could looks like this: | ||
+ | |||
+ | assembly | ||
+ | *adempiere-ear | ||
+ | **incl-libs => generally, all subproject ears assume that the libs are *not* provided at runtime, and thus need to be within the ear itself | ||
+ | ***zk_client => pom declares only the libs neccesary to run the ZK webapp | ||
+ | ***zk_client-swing_client => pom declares the libs to run webapp and jnlp client | ||
+ | ***zk_client-swing_client-mobile_ui | ||
+ | ***zk_client-mobile_ui | ||
+ | **excl-libs => generally, all subproject ears assume that the libs are provided at runtime, and thus do not need to be within the ear itself | ||
+ | ***zk_client | ||
+ | ***zk_client-swing_client | ||
+ | ***zk_client-swing_client-mobile_ui | ||
+ | ***zk_client-mobile_ui | ||
+ | **adempiere-dist | ||
+ | ***jboss: all sub projects generate archives (one zip, one tar.gz) that contains jboss together with certain applications | ||
+ | ****libs-external: in the sub probjects, the dependencies are within a common jboss lib directory | ||
+ | *****zk_client | ||
+ | *****... | ||
+ | ****libs-in-ears: in the subprojects, all dependencies are within the respective ears and wars | ||
+ | ***glassfish: | ||
+ | ****libs-external | ||
+ | *****... | ||
+ | ****libs-in-ears | ||
+ | *****... | ||
+ | ***tomcat | ||
+ | ****... |
Revision as of 01:14, 21 November 2011
Questions/Note/Work proposals
from Freepath (Silvano):
1. I noticed you put a pom into tools/cctools with the dependencies: if its ok with you, i'll start moving the dependencies into to the master pom, and refactr 'base', so to have a first compiling module. Once all are happy with how it look/work, this can be used as a reference for the other modules. WDYT ?
2. Its usually a good idea to specify the character encoding (project.build.sourceEncoding property). Usually this is set as UTF-8. Applying this on a an already existin project may have side effects (the most commone case is local specific character in comments). It may raise some issue, but i believe its worth doing. WDYT ?
Tobi 06:00, 25 October 2011 (UTC)
- I think the two questions above are meanwhile settled. OK To remove them?
Tobi 08:14, 21 November 2011 (UTC) How to organize "assembly" directory
Here is how I arrived at the qustion:
Right now, there is this problem: the dependency jars are inside the ear, but it seems that they must explicitly be declared in the application.xml to be found by the classloader. Of course there are alternatives: They could be moved in the jboss-server's lib directory, this would have the added benefit that the installer could use them, too. Or, I think there is some additional jboss-descriptor xml file that can be added to the ear for them to be loaded from within the the ear.
But what I really want to get at: I think this decision should be left to the deployer. It might make sense to move those jars into a jboss lib directory (e.g. if you have further web apps that want to use them, too), and I might sense not to do it, depending on one's individual situation.
So, the actual question is: How should we organize the general directory structure?
Suggestion: assembly-Directory: Should contain a number of poms for different selections and combinations of the avaiable building blocks. That assembly directory could looks like this:
assembly
- adempiere-ear
- incl-libs => generally, all subproject ears assume that the libs are *not* provided at runtime, and thus need to be within the ear itself
- zk_client => pom declares only the libs neccesary to run the ZK webapp
- zk_client-swing_client => pom declares the libs to run webapp and jnlp client
- zk_client-swing_client-mobile_ui
- zk_client-mobile_ui
- excl-libs => generally, all subproject ears assume that the libs are provided at runtime, and thus do not need to be within the ear itself
- zk_client
- zk_client-swing_client
- zk_client-swing_client-mobile_ui
- zk_client-mobile_ui
- adempiere-dist
- jboss: all sub projects generate archives (one zip, one tar.gz) that contains jboss together with certain applications
- libs-external: in the sub probjects, the dependencies are within a common jboss lib directory
- zk_client
- ...
- libs-in-ears: in the subprojects, all dependencies are within the respective ears and wars
- libs-external: in the sub probjects, the dependencies are within a common jboss lib directory
- glassfish:
- libs-external
- ...
- libs-in-ears
- ...
- libs-external
- tomcat
- ...
- jboss: all sub projects generate archives (one zip, one tar.gz) that contains jboss together with certain applications
- incl-libs => generally, all subproject ears assume that the libs are *not* provided at runtime, and thus need to be within the ear itself