Talk:FR3403603 Mavenize

This Wiki is read-only for reference purposes to avoid broken links.

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
    • glassfish:
      • libs-external
        • ...
      • libs-in-ears
        • ...
    • tomcat
      • ...

WDYT?

Tobi 07:01, 23 November 2011 (UTC) Where do the settings from ADempiereEnv.properties go

Goal: beeing able to run adempiere ear without using RUN_Setup

• Adempiere/build.xml loads ADempiereEnv.properties and puts them into the following files by copying with "filtering='yes'"
  • target setupJBoss:
    • /jboss/server/adempiere/conf/jboss-service.xml
    • /jboss/server/adempiere/conf/login-config.xml
    • /jboss/server/adempiere/deploy/jboss-web.deployer/server.xml
  • targets setupNonWin/setupNonWin
    • utils/myDBcopy.[sh, bat]
    • utils/myEnvironment.[sh, bat]
    • utils/RUN_GetAdempiere.[sh, bat]
    • utils/RUN_PutExport.[sh, bat]
    • utils/RUN_[UnixEnv.sh, WinEnv.bat]

• How does adempiere find the DB-settings?
  • Intersting, but afaiu not really relevant
    • utils/RUN_server2 basically executes myEnvironment and then starts $JBOSS_HOME/bin/run
    • utils/myEnvironment exportd an number of environment variables, including the jdbc-URL
  • Here is how it works
    • Both Setup and SilentSetup (package org.compiere.install) use the class ConfigurationClass same package to create ADempiere.propperties
    • ADempiereEnv.properties is loaded by load()
    • The result is stored to Adempiere.properties by save() with encryption
    • ADempiere_Home is taken from the environment variable

Tobi 07:38, 23 November 2011 (UTC) How should jar-signing really be done?

• I think it should be done during build/release, not at rollout time
• So, how should it be done properly during build/release?
  • What is the keystore?
    • The keystore is a file that is used
      • in SSL-Connections to the adempiere server (see jboss\server\adempiere\deploy\jboss-web.deployer\server.xml)
      • then signing class files for the webstart application
    • The keystore is a file that contains keys. It is secured with a Keystore Passowrd
    • Each key pair contained in the keystore can additionally be secured with a key of its own.
      • Note In adempiere, no particular key password is given. That means, the keys can be accessed with the keystore password

• What needs to be secret about the keystore and what doesn't
  • In order to add and remove keys, you need to have the keystore password.
  • In order to sign jars (->Webstart), you need to have it, too
  • When configuring an SSL connection, you need to specify in in the config file that is rolled out to the customer!

• Conclusions:
  • if the files are signed at build time, e.g. for an adempiere-release, there is no point in trying keeping the keystore password secret.
  • jar-singing for jnlp is just done because the classes need to be signed in order for webstart with all permissions to work

• If you are a building a customized adempiere for a customer, it might make sense to use your or keystore with a secret password

• Open: Im pretty sure there can be done a lot with certificates a and keychain and stuff like that, to achive these goals:
  • have an adempiere-keystore with secret passwords that is used to sign official adempiere releases
  • have the adempiere-keys signed by a CA or something
  • have some sort of sub-keys to distribute, so that the passwords of those keys can e.g. been put into config files rolled out to the customer