Hello Siarhei. No, we don't need to generate the stubs and ties in the IDE for a remote deployment. However, obviously you would have to do that when using the local test environment, and I use the IDE to do that. It is much easier (and more natural for me at least) to have the IDE to generate such things than to use maven for that task. So I simply skip it.
We do not deploy from a CI environment, and probably never will do so. All (most?) of our application communicate with one or more mainframes, and they sometimes need to deploy their code as well... :-) That would not work from a CI environment, as it requires more manual integration with other code (on the M/F). However, if the app was _entirely_ self contained, ie did everything itself and have no other external links etc, then I may consider gettting the build to do it, but at this point, I don't see the point. Basically, the model that I have in my head at the moment, is that we'll use CI to automate the builds, run the tests, produce the reports, and (when I work out how to) upload the ear to the remote server but not deploy it. We have a web app (deploy site) that allows us deploy our ear artifacts to the necessary instances, retrieve logs from production etc. That is what we have to use to deploy apps, that we can only do in our system test (real websphere on AIX) env. We have a separate team that manages the websphere environment for us. When we deploy, and the stubs and ties are done for us, here is the output: ADMA5018I: The EJBDeploy command is running on enterprise archive (EAR) file /tmp/app38179.ear. Starting workbench. framework search path: /ibmapp2/websphere61/base/deploytool/itp/plugins Creating the project. Deploying jar DiallerEJB-1.0-SNAPSHOT Generating deployment code Invoking RMIC. Writing output file Shutting down workbench. EJBDeploy complete. 0 Errors, 0 Warnings, 0 Informational Messages ADMA5007I: The EJBDeploy command completed on /ibmapp2/websphere61/deploymgr/wstemp/wstemp/app_11a7f4e92be/dpl/dpl_dial.ear I would recommend that you (well, everyone really) do a manual deployment of an ear file using the admin console, just so that they understand what is done and the issues involved. -Chris "Siarhei Dudzin" <[EMAIL PROTECTED]> wrote on 13/06/2008 08:09:36: > Hi Chris, > > This is very interesting approach. Does that mean you have to actually > generate stubs&sceletons in IDE before you can build with maven? > How do you deploy your apps to a server in CI environment? Do you use hot > deployment (then you might have timing issues) or do you not deploy at all > and only do unit testing? > > > Regards, > Siarhei > > On Wed, Jun 11, 2008 at 3:35 AM, <[EMAIL PROTECTED]> wrote: > > > Hi. > > > > I do not get maven to actually generate the EJB deployment code, WebSphere > > itself will do it at deployment time, so I do. If nothing else, this will > > give you a list of the jars that you need. > > > > > The following message has been automatically added by the Internet mail > gateway to comply with the Group's Information Security requirements. > > "This e-mail has arrived via the Internet, and therefore you should be > cautious about its origin and content. Replies which contain sensitive > information and / or legal/contractual obligations are particularly vulnerable. > > In these cases you should not reply unless you are authorised to do so, > and adequate encryption is employed." > > If you have any questions, please contact the IS Service Desk. ********************************************************************** CAUTION - This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must: - Not use, copy, distribute or disclose it to anyone other than the addressee; - Notify the sender via return email; and - Delete the message (and any related attachments) from your computer immediately. Internet emails are not necessarily secure. Australian Associated Motors Insurers Limited ABN 92 004 791 744 (AAMI), and its related entities, do not accept responsibility for changes made to this message after it was sent. Unless otherwise stated, views expressed within this email are the author's own and do not represent those of AAMI. ********************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
