We are doing something similar in order to take advantage of WebSphere's Wsdl2Java ant task implementation as part of our Maven build. We store the WSDL in source control and generate the derived Java types with the Maven build. As with Chris' case, we don't need an actual WebSphere instance in the build environment, just the jars extracted from the runtime [ pom for WebSphere 6.0 included below ]
We see the chief advantage of doing is that we can are guaranteed to detect gross inconsistencies between the WSDL and Java at build time, rather than runtime which is possible if one relies on a manually initiated IDE-centric process to generate the Java from the WSDL. <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> <modelVersion>4.0.0</modelVersion> <groupId>org.example</groupId> <artifactId>wsdl2java-support</artifactId> <packaging>pom</packaging> <name>WSDL Generation Support</name> <version>1.0-SNAPSHOT</version> <description> Contains the dependencies required to support WSDL generation during the Maven build. </description> <dependencies> <dependency> <groupId>ant-contrib</groupId> <artifactId>ant-contrib</artifactId> <version>1.0b2</version> </dependency> <dependency> <groupId>ant</groupId> <artifactId>ant-trax</artifactId> <version>1.6.5</version> </dependency> <dependency> <groupId>org.example.dependencies</groupId> <artifactId>wsanttasks</artifactId> <version>6.0.2.25</version> </dependency> <dependency> <groupId>org.example.dependencies</groupId> <artifactId>ffdc</artifactId> <version>6.0.2.25</version> </dependency> <dependency> <groupId>org.example.dependencies</groupId> <artifactId>webservices</artifactId> <version>6.0.2.19</version> </dependency> <dependency> <groupId>org.example.dependencies</groupId> <artifactId>bootstrap</artifactId> <version>6.0.2.25</version> </dependency> <dependency> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> <version>1.0.4</version> </dependency> <dependency> <groupId>commons-discovery</groupId> <artifactId>commons-discovery</artifactId> <version>0.4</version> </dependency> <dependency> <groupId>org.example.dependencies</groupId> <artifactId>emf</artifactId> <version>6.0.2.25</version> </dependency> <dependency> <groupId>org.example.dependencies</groupId> <artifactId>wccm_base</artifactId> <version>6.0.2.25</version> </dependency> <dependency> <groupId>org.example.dependencies</groupId> <artifactId>deployutils</artifactId> <version>6.0.2.25</version> </dependency> <dependency> <groupId>org.example.dependencies</groupId> <artifactId>classloader</artifactId> <version>6.0.2.25</version> </dependency> <dependency> <groupId>org.example.dependencies</groupId> <artifactId>wsdl4j</artifactId> <version>6.0.2.25</version> </dependency> <dependency> <groupId>org.example.dependencies</groupId> <artifactId>ras</artifactId> <version>6.0.2.25</version> </dependency> <dependency> <groupId>org.example.dependencies</groupId> <artifactId>wsexception</artifactId> <version>6.0.2.25</version> </dependency> <dependency> <groupId>javax.j2ee</groupId> <artifactId>j2ee</artifactId> <version>1.4</version> </dependency> </dependencies> </project> jon seymour IBM GBS (Sydney) On Fri, Jun 13, 2008 at 10:32 AM, <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
