The "more or less" part is kind of meaningless, since the blueprints themselves are "recommended conventions" or "guidelines [...] intended to assist developers". Nevertheless, for those literally minded, this is what I mean:The tree used is illustrated in more details below.
- There is more layers between a "myapp1" and "myapp1-war" - a folder called "modules". It is insignificant, but I thought I'd mention it.
- There are no classes or libraries included in a WAR (to end up under
WEB-INF/classes
orWEB-INF/lib
, respectively). All compiled source (whether from modules or components) is packaged into utility JARs that live off the root of the EAR, each component/module built/packaged into its own utility JAR. The WAR'sMETA-INF/MANIFEST.MF
has a Class-Path attribute that lists the utility JARs.- All third-party libraries are gathered together in a single place, to be shared among all applications. The actual inclusion of libraries for compilation and/or packaging of particular applications is handled by the build scripts (in our case, by property files, conforming to a given format, that parameterize the build scripts). For the purposes of IDE-based development, the dependencies can be set as desired for proper compilation. The build script will package and deploy the right set of JARs, and these will not be changed in the process of regular development/debugging (if they must change, a rebuild/redeploy will be required).
archive
attribute of project-module
tag
in .mymetadata
for a project named foo
is
set to foo.war
. This will affect the deployment.
foo.jar
in place of a
foo.jar
JAR) per se:
WAS has a problem with it with
respect to J2EE application clients.
-Xj9
vs reloadingEnabled
attribute. Certainly the former is necessary to keep
WAS in sync with code in IDE, but it does not
seem sufficient... O well, MyEclipse does not pay me,
so why bother...
d:/mysourceroot
, hereafter referred to as
SOURCEROOT
, which is where the tree such as the one below
is located:
|-apps | |-- myapp1 | |---META-INF | | |---application.xml | | | |---modules | |---myapp1-war | | |---src | | |---web | | |---mypage.jsp | |---myapp1-jar | |---src | |---java | |---com | |---foo | |---X.java |-components |--comp1 |---src |---java |---com |---bar |---Y.java
-war
, and utility JAR project
folders have names ending with -jar
.
System{Out,Err}.log
to console
as step 5 suggests, because when you run standalone, you
have no way of looking at the logs. The reverse is not true. If you do not
redirect the logs, you can always create a quick
External Tool launch
configuration in [My]Eclipse that will run tail -f
on
those WAS log files, and get the logs piped nicely to your
console. If you do that, be sure to kill those tail
launches when restarting WAS.
For arguments to the VM that runs WebSphere I (
YMMV) like:
-Xj9 -Xjit
If run via MyEclipse, those are "Optional VM arguments" in MyEclipse's
WAS setup. If run separately for whatever reason, as above,
those those are specified in WAS Administration Console,
under "Servers - Application Servers - <server> - Java and Process Management - Process Definition - Java Virtual Machine - Generic JVM arguments".
For convenience,most of the steps below are automated byorg.hrum.misc.MyEclipseWorkspaceCreator
class. It is not intended to be used flexibly and repetitively to set up every developer. Rather, it should be tweaked and run by someone who will set up this environment, if needed. Then the person running it should just export/make available appropriate Eclipse settings for the rest. This class assumes one more level of folders between theSOURCEROOT
andapps
- in our case, one for each team working on a suite of applications. This is for historical reasons, based on how project repositories were set up in source control, and can be easily tweaked in the code. If you wish to use it:
- Perform the step to create
WORKSPACE
below.- Stop Eclipse.
- Modify the
MyEclipseWorkspaceCreator
program as you wish and run.- Point MyEclipse to the workspace created above by giving it the option
-data WORKSPACE
, and start it.- In the workspace, right-click, choose "Import", then "Existing projects into workspace". Browse to
SOURCEROOT
, and import all projects found.- Do the step above with
WORKSPACE
as root this time.- Continue with step "Set up EAR deployment policy" below
d:\dev
, and refer to it, hereafter, as
WORKSPACE
.
Make sure there is no overlap betweenPoint MyEclipse to the workspace created above by giving it the optionWORKSPACE
andSOURCEROOT
.
-data WORKSPACE
, and start it.
SOURCEROOT/apps/myapp1/modules/myapp1-jar
,
SOURCEROOT/components/comp1
, etc.). Set up
build path (project/JAR dependencies) as appropriate. If not all
dependencies are created yet, you will come back to this
later anyway.
x.jar
is deployed in an application, a folder named
x.jar
containing classes will work just as
well. Therefore:
component1
is packaged into
component1.jar
, make the output folder
component1.jar
.
SOURCEROOT
(to reiterate: not in
WORKSPACE
) - so:
<web-uri>
specified under
myapp1/META-INF/application.xml
.
<context-root>
from the above-mentioned
application.xml
.
src/web
as "Web root folder" (since
this is per the blueprint).
dummysrc
for the "Source folder"
(so as not to conflict with the src/web
; in our
setup, we do not have any Java code under a Web project, only
under utility JARs).
WORKSPACE
-- that is, we will keep default location
-appName
argument to one
of them JACL scripts.) We assume it's the same as
<display-name>
from application.xml
.
META-INF
folder from the EAR project
created above.
SOURCEROOT/apps/myapp1/META-INF
folder, and "Finish".
If you understand what is being accomplished above you can set it as your workspace policy, or you can come up with the one that works for you.
You may use "Order and Export" tab to keep dependencies streamlined as you wish, it will have no bearing on deployment strategy as presented here.
WEB-INF/ibm-web-ext.xmi
:
<webappext:WebAppExtension>
tag, set
the element
reloadingEnabled="true"
.
<jspAttributes>
tag so that
Beware of what setting
reloadEnabled="true"
in deployedObject
tag of
deployment.xml
means -- it results
in recycling the application. This is not what I want, so I set it
to false
. See also
Hot-deploy to WAS resulting in app restart topic on MyEclipse forums.