This content has been marked as final. Show 4 replies
With a bit of experimentation, we found the short answer is not to do ANYTHING extra to the web.xml or the portlet.xml. We used our plain-vanilla web.xml that was e.g. used for the input to the Pluto plugin step mentioned above. So in our source control, we've got nothing container-specific for any container in our web.xml or portlet.xml.
To get this JSR portlet running on Oracle Portal we had to do the following:
1. Create a new OC4J instance.
2. Install the portlet container to the OC4J instance. Refer portal development guide section 6.3. This is a separately downloaded component from OTN. (URL in the doco)
3. Deploy portlet WAR to the OC4J instance.
4. In deployment process the portlet container will generate WSRP endpoints for you automatically. Note these enpoint URLs for the next step.
5. Within Portal, register a WSRP provider for the new portlet. The WSRP urls are found back in the configuration screens in step 4.
6. Once registered the portlet will appear in the portlet staging area and can be added as normal.
7. This step is still to come ... how to do at least 4 to 6 from the command line.
We intend to have a continuous integration server, e.g. Hudson or Cruisecontrol, deploy successfully building portlet WARs automatically to the Oracle Portal as above on completion of all successful unit tests ... and then hopefully run the integration tests on the portal pages. Automatically after every check in.
You don't need JDeveloper to write a JSR 168 portlet. You can use any Java IDE, like Eclipse.
You can even write portlets with a text editor and compile them on the command line.
The you need to package your EAR file.
The EAR file needs to be deployed in a WSRP container. This can be done on the command line.
Alternatively, if you are using Enterprise Manager, it is also possible to deploy EAR files using OEM's web interface. No JDeveloper or command line is required.
With respect, it's patently obvious that we know how to develop a portlet without Jdeveloper, because if you read the message you would have been able to discern that this is the way we are accustomed to doing it, and it's faster, easier and more portable that way. I've been doing J2EE development since the first version of the spec and well before there was an Oracle implementation of it.
You don't actually need an EAR file, as a WAR will suffice and the dcmctl command-line utility can supply everything else in its arguments (like, context-path and the like), and it allows each WAR artifact to be deployed in different times, i.e. when they are built on the integration server. I find EAR files usually too heavyweight especially as I rarely write EJBs, as opposed to using e.g. Spring.
Using the web browser is not an option for automated deployment and acceptance testing from an integration build server.
Configuring the portal side of things looks decidedly a different matter and I've not found anyway to do it from the command line, it demands the browser, which is a let-down.
It's terribly disappointing the paucity of information about automation of deployment as opposed to the positively verdant amount of presentations, tutorials and documentation that assumes top-to-bottom Oracle tooling and environment and browser-based configuration. Even where it's actually possible Oracle doesn't seem to want to tell people about it or do as I believe they should, which is regard this form of deployment and configuration as the default way to teach developers how to use their products. None of this helps build and deploy to Oracle products using test-driven development, continuous integration, and automated acceptance testing, all of which are usually regarded as essential parts of a modern developers toolkit by the best minds in the business.
So after we're left alone to discover how to do this by ourselves for a month you can forgive my disappointment at being lectured like I was some neophyte who doesn't know how to make a WAR file with textedit.