Talk:FR3403603 Mavenize

From ADempiere
Jump to: navigation, search
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?

Different "threads"

How to organize "assembly" directory Tobi 08:14, 21 November 2011 (UTC)

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?

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

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


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

  • 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

Current shortcomings Tobi 07:36, 25 November 2011 (UTC)

Note: all of this can and should be fixed

  • There should be more documentation. With maven, it can be kept and maintained within the actual projects (see http://maven.apache.org/plugins/maven-site-plugin-3.0-beta-3/examples/creating-content.html)
  • patches.jar and customization.jar are not applied. It's possible to do this, but urrently there are differnt ideas on whether it's desirable or if small updates/customizatins should be applied differently.
  • Only JBoss-4.2.3.GA is supported (no Glassfish, Tomcat)
  • I think the directory structure needs an overhaul to be more intuitive
  • Size of the project
    • When working with the whole project and importing all modules into Eclipse (3.7), there are problems of eclipse hanging, status not updated, large RAM consumtion and further problems due to the size of the project
      • Maybe we should really start working with subsets, not with all projects at once
    • Also, Jenkins has trouble building it all at once (in particular, if you want to build the site, too)
      • It might make sense to have a multitude of different build jobs, one for each module
  • The webstore application is currently not part of the distribution, due to some jar compatibility issues (http://www.mail-archive.com/users@tomcat.apache.org/msg35677.html)
  • You need to point the browser to http://<server>:8080/admin/ (http://<server>:8080/ doesn't automaticall forward)