Developed RAD-6 Plugin Extention

sorry that it took so long but i was not at work...

this is the tarball with the plugin.
some hints for RAD6 users

• do not use java classes in a war project, put all java classes in dependent projects
• best thing to do is to make all jars in the war project provided and put them in the ear dependencys
• there will be a classpath directory included in ejb projects here you can put your generated ejb classes for nor i use the websphere-ant jobs in the project-pom to generate them. (in the package phase overwiting the jar and the client-jar and copieing the classes to the classes-folder included by this plugin, the ant-job does not generate the java files...)
• the META-INF of the ejb project MUST!!! be a toplevel folder so include this top-level-folder in your resources list of the pom (the java files can stay in src/main/java
• don't forget to fill the ".cvsignore" files especialy the jar's and wars in the ear-project's and the war-project's

regards,
Ritchie

There is no plans to support RAD in m2eclipse plugin.
You may suggest this for adding into maven-eclipse plugin that runs from the command line.

Sorry but i don't understand how to use your archive.

What is the way to use it ?

to install this plugin (at least at the time of this post), you must first comment out all of the existing repository configurations (there are 5 I believe...just do a search for "central" in the project..)

after you have it installed into your local m2 repository, you can run:

at.uniqa.maven.plugin:maven-rad-plugin:clean
at.uniqa.maven.plugin:maven-rad-plugin:rad6

It doesn't look like this project supports portlet development yet...can I help? I'd imagine the update would be pretty trivial (since web projects already are working)

I have not much time to spend for support on this plugin, i made/appened it for a customer (UNIQA Austria).

But still any extentions are welcome, and as long as there is no own project and it is not integerated in the eclipse plugin we should post them here. i have not the time to make and support a seperate project.

Because the project (i worked on) ended successfuly, i do not work on this plugin anymore (for now). Please feel free to contact me, i will give you an email kontact of the responsible person in UNIQA Austria. They are happy to meet and work together with others also using Maven-2, RAD6 and websphere. They also ported or working on porting a lot of the was-5/6 admin ant tasks to maven-2 goals for websphere-6 integration tests.

in this updated version i deleted the localreposetorys (sorry for that) so it should build anywhere now.

Thank you for your answer Mike.

Working with RAD6 on dynamic web project, i meet various difficulties. Here is my process :
1- Creation of a dynamic web project inside RAD6 using the project Wizard.
2- Using Maven to import our specific resources (img, css, xml, jsp ...) with an archetype:create goal. After that, i have a pom.xml at the root of my project.
3- Using Maven and your rad6 goal to update .classpath and other resources for RAD6.

At this step, i don't understand why your goal create a src/main/webapp directory in which are placed all the dependencies mentionned in the pom.xml. I know that this is the Maven structure. But when i deploy (with RAD6) my project to WebSphere, the dependencies are not copied. For RAD6, dependencies, web.xml and all you need for the war are in the WebContent directory.

So, is there something i missed ?

Hi,

you did it the wrong way around, at least as i do it. this plugin is
designed to work the maven way and adapting the project in such a
way that it also works in RAD-6. So there should NOT be a "WebContent"
directory there should be "src/main/webapp" as a webcontent.

all dependent libraries are copied into src/main/webapp/WEB-INF/lib .
this directory should be ignored in scm.

regards,
Ritchie

Unfortunately, I can't seem to get the WebService creation wizard in RAD 6.0.1.1 (Interim fix 002) working with the webSourceDirectory set to src/main/webapp .

I have attached an alternative version that works with the WebContent dir. (NB: both warSourceDirectory and webXml configuration properties must be set accordingly on the maven-war-plugin also).

regards
Lee

Alternative version of this plugin that uses the WebContent directory for web content files.

Can you please rework this contribution as a patch to the maven-eclipse-plugin? RAD is based on Eclipse, so it would be best to integrate this support with that plugin.

Thats getting difficult... and i do not have the time to do this right now.. (it was based on an 4 months old version of eclipse:eclipse )..

But almost all differences are all in additional workers. (by intended design of the eclipse plugin) .

Some of these workers i copied for my wtp 1.5 patch that i posted a while ago, i had the some same problems there as i had in RAD6.

When you realy need a rework as a patch, i can send you the contact in the company for whom i made the plugin (UNIQA).
maybe they have some resources free for rework (when it realy gets integerated in the official version of eclipse:eclipse).

.

I'm working on porting this to the eclipse plugin. I've got the implementation ported, but I'm still working through some issues with testing...I'll be committing to http://svn.apache.org/repos/asf/maven/plugins/branches/MECLIPSE-137 until I get this resolved.

RAD 7 is round the corner. My company might roll out RAD 7 as soon as it gets available.
Given that this plugin was specifically tailored for RAD 6, is it likely that this plugin might not work for RAD 7.

to Girish Khemani:
Yes probably because RAD-6 is based on eclipse 3.0 and RAD-7 will be based on eclipse 3.2

It is just the question how mutch of IBM's special stull they left over.... I also posted some fixes for the eclipse-plugin for eclipse 3.2 they were partly extracted from this RAD-6 plugin.

to John Casey:
the testing was copied from the original (old) eclipse-plugin and adaped to fit the RAD-6 needs, the structure of the test was rather bad but i did not have the time to resolve this testing problems. from what i read on the mailing lists the maven-plugin test enviorment has improved a lot. so it is probably the best to create new test cases.

John,

The changes to the eclipse plugin so far retain the hard-coded path of src/main/webapp/.... Would it be possible to honour the configuration setting of the maven-war-plugin (or else enable us to specify this web resources directory path via a new maven-eclipse-plugin configuration setting)?

Lee,

This should be pretty easy to expose as a configuration point. I'll take a quick look at that today, if you like.

Girish,

I was actually hoping that, once we had some file formats to look at, we could devise a plan to support both RAD versions. I'm not sure whether this will require parallel implementations within the maven-eclipse-plugin or not (haven't seen the file formats...), but either way, I think it's going to be important to support both, since many people won't be switching overnight.

Richard,

I think I managed to understand the tests well enough in there to rework them into the new testing format...I'm not 100% sure, but as I understand things, they are testing the functionality in question. Please let me know if you find this statement to be incorrect.

John,

I have attached a patch file containing an initial attempt at honouring the warSourceDirectory setting on the maven-war-plugin, based on something done elsewhere in the maven-eclipse-plugin.

It also contains a modification to the RadWebSettingsWriter to include referenced projects within the same RAD workspace - they were not getting loaded when launching the web app in a test server.

regards
Lee

This file contains the changes my organization needed. This includes several months of bug fixes and feature additions so I'll hit the highlights, and these are from memory as I am doing this from home and not on company time.

Primary bug fix (that I can remember)...
– Rad6ApplicationXMLWriter.java:
changed:
private static final String XMLNS_SCHEMA_LOCATION = "xmlns:schemaLocation";
to:
private static final String XMLNS_SCHEMA_LOCATION = "xsi:schemaLocation";

Primary functionality changes (that I can remember)...

Added...
– AbstractRad6Writer.java:
This class provides some functionality that I found myself needing in several of the other writers. Things such as:
getMetaInfDirectory()
getWarSourceDirectory()
getJ2eeSpecVersion()
getWarContextRoot() - this one was interesting... could probably be written better but seems to work nicely. I don't know a better way to share configuration information between plugins (i.e. maven-war-plugin looking something up from the maven-ear-plugin of a sibling project)

Added...
– Rad6CvsIgnoreWriter.java:
This class creates or appends to the .cvsignore files for CVS projects. My organization needed this for easier transition to using the plugin as we had hundreds of projects with the Eclipse/RAD specific configuration files checked into CVS. Now that the Eclipse/RAD plugin so lovingly configures all these files dynamically we had lots of questions from users wondering if they needed to commit their "dot" files back to CVS every time they ran the plugin. My goal was to keep all that junk out of version control and let the POM+Eclipse/RAD plugin abstract away the details of IDE configuration. This will add things like "target" ".*" "MANIFEST.MF" to the appropriate .cvsignore files in the projects. This functionality could be equally necessary for subversion or other version control systems. Also the ability to enable/disable this feature is needed for users who don't use CVS, I have not implemented that.

Modified...
– Rad6ApplicationXMLWriter.java
Added support for multiple J2EE specification versions (i.e. 1.3 as well as the default of 1.4).
createNewApplicationXml() will now create the appropriate 1.3 spec application.xml
Added support for custom WAR context roots to be maintained.
updateApplicationXml() uses getWarContextRoot() from the AbstractRad6Writer

– Rad6J2EEWriter.java
Added support for multiple J2EE specification versions (i.e. 1.3 as well as the default 1.4).
writeModuleTypeFacetCore() will now write the .j2ee file specific to the j2eeSpecVersion

– Rad6ManifestWriter.java
Refactored to take advantage of the AbstractRad6Writer.getMetaInfDirectory()

– Rad6WarClasspathWriter.java
Refactored to take advantage of the AbstractRad6Writer.getRelativeWebInfDirectory()

– Rad6WebSettingsWriter.java
writeModuleTypeFacetCore() updated to use getWarContextRoot() instead of hardcoding the artifactId and use the AbstractRad6Writer.getRelativeWarSourceDirectory()

I hope this helps anyones struggling with similar issues.

Hi,

i try to use this plugin, but i have no clue in which order i have to use the packages above. When i only use maven-rad-plugin.tar.gz then the test will fail. When i also use the MECLIPSE-137-maven-rad-plugin.zip than nothing works. Can anybody explain me how to do it in the right way?

Thanx,
Ulf

as far as i can see thes plugin is integrated in maven-eclipse-plugin-2.3 so use that one

You are right, the plugin is apparently integrated in version 2.3. I found some documentation here:

http://maven.apache.org/plugins/maven-eclipse-plugin/rad-mojo.html

and apparently the plugin works (at least I can create some rad project files).

Shouldn't this jira issue be updated to indicate this fact?

What about RAD 7?

Seems that John fixed this in 2.3 and forgot to close