1 2 Previous Next 20 Replies Latest reply on Mar 27, 2006 2:18 PM by st-lotfi

    JBoss Eclipse IDE Portal Plugin requirement discussion

      I'd like to start a discussion about the functionality requirements we envision being a part of the JBossIDE Portal Plugin here. I will take Roy's initial scribbles from here:

      http://jira.jboss.com/jira/browse/JBPORTAL-624

      and Kevin's initial contribution as a starting place. Here's the list I've come up with:

      - A Portlet skeleton app wizard that generates:
      --- A Portlet class
      --- Standard and jboss portal descriptors
      --- An ant build script
      - An jboss-portlet.xml editor with auto completion on common values (should be derived from WTP XML editor for smooth integration) including:
      --- Completion on class implementation names
      --- Completion on IDs etc seen in other standard descriptors (portlet.xml)
      - JBossPortal classpath libraries tied to JBossPortlet projects for simplicity sake
      - A standalone Portlet wizard that modifies existing descriptors / creates a portlet class

      Feel free to add anything as I'm no Portal expert, I'm sure this is just scratching the surface =)

        • 1. Re: JBoss Eclipse IDE Portal Plugin requirement discussion

          What I outlined in the jira task are just phase 1 goals. They are by no means to be considered a complete and finished task.

          Its a basic portlet plugin/wizard. Nothing more. If there are more ideas from the community, I'm willing to hear them.

          • 2. Re: JBoss Eclipse IDE Portal Plugin requirement discussion

            Here are a couple of features that could (not necessarily in stage 1) be added:

            configuration of init / instance parameters in the wizard, with member variables and getters/setters created in the skeleton code and descriptor

            context menu to add parameter to an existing portlet class (with corresponding entry created in descriptor)

            refactor -> rename parameter

            ability to specify skeleton code type in wizard, e.g PrintWriter http code, pure jsp based, struts based, faces etc.

            delete parameter, with usage checking (can't remove parameter if member variable referenced in code)

            I'm sure people can think of more, but these are just off the top of my head.

            Cheers,
            KEv.

            • 3. Re: JBoss Eclipse IDE Portal Plugin requirement discussion
              starksm64

              So this goes back to my thread about how stuff like this gets integrated into the ide. Can I just check for updates and pull this down (once the plugin is uploaded)? Portal is not in the current ide 1.5 so this is also recurring issue of how developers and users get access to new plugins and their dependencies. If I have all of 30 mins to look at something in order to contribute, I don't want to spend those 30 mins just getting the plugin and dependencies into the ide (I have an infinitely fast connection so download does not count).

              • 4. Re: JBoss Eclipse IDE Portal Plugin requirement discussion

                Kev,

                The enhancements you point out are in my head but not on paper, thanks for posting them. I would like to have a JSF Portlet option that stubs out the jsf descriptor, and am not overly concerned with struts or any other framework right now.

                • 5. Re: JBoss Eclipse IDE Portal Plugin requirement discussion
                  andy.miller

                  After looking at the demo, things look good as a starting point. I have one suggestion though.

                  I would like to see the project be able to use the packaging cofigurations, and have the Java code build through the standard Java Builder (class files in the bin directory) in Eclipse. It looks like the project wizard is creating an Ant build.xml file, and that is the only build and deploy mechanism. If you use the packaging stuff from JBoss IDE, then you can do the "right-click->deploy to..." stuff.

                  This would make it feel more like an integrated piece of JBoss IDE.

                  Thanks.

                  Andy

                  • 6. Re: JBoss Eclipse IDE Portal Plugin requirement discussion

                     

                    So this goes back to my thread about how stuff like this gets integrated into the ide. Can I just check for updates and pull this down (once the plugin is uploaded)? Portal is not in the current ide 1.5 so this is also recurring issue of how developers and users get access to new plugins and their dependencies.


                    Since this is an initial contribution (therefore experimental), all we have right now is some source code that needs to be launched through a runtime launch configuration of Eclipse. When the code becomes slightly more mature (i.e.. right now it still needs to be "formalized" with LGPL headers, package / class name refactoring, etc) and ready for an initial release, we will make a binary distribution zip that is easily unzipped into an eclipse installation (just like we did for the JBossCache IDE). At this point, it will also be rolled into our nightly build that users can always obtain the latest from. I don't think it makes since to provide a "nightly" update site, but I might be persuaded otherwise.

                    • 7. Re: JBoss Eclipse IDE Portal Plugin requirement discussion

                      This will be worth us adding to the portal downloads in sourceforge as well. Meaning, our roadmaps will have to synch.

                      • 8. Re: JBoss Eclipse IDE Portal Plugin requirement discussion

                        Sure -- this is the reason for the push of the "JEMS Milestones" synchronization. Do you mind if the initial / preview / whatever release is arbitrary? It helps give the users a good taste of what's to come without waiting for a "big" IDE release =)

                        • 9. Re: JBoss Eclipse IDE Portal Plugin requirement discussion

                          Hi guys
                          Respsonses to a couple of points:

                          Roy,
                          I take your point that you are primarily looking at skeleton development of JSF-type portlets. However, do you agree that it would be good to develop in such a way that in the future it would be possible to "plugin to the plugin" other skeleton producers? So if someone feels that they prefer to develop X-type portlets, they can develop a class (which conforms to some as-yet unwritten) API which provides the skeleton in some other format?

                          Andy,
                          The generated Ant build file purely provides a packaging facility. creating a .war file from the contents of the bin directory and the contents of the resources directory. I will quite happily look at changing this to use the JBoss IDE packaging stuff :)

                          Marshall,
                          Yes, unfortunately at the moment it needs to be launched in a runtime configuration. I did make an update site on my server at home, but it's no use because when you deploy the plugin to a "main" Eclipse, and try to make a new project, the wizard fails because it can't find class org.eclipse.ui.wizards.newresource.BasicNewResourceWizard. I don't understand this because the plugin's descriptor states that it has a dependency on org.eclipse.ui, which is the plugin that contains the unfound class. I'm still trying to figure out why this is happening.

                          Still, at the very least this proto-plugin has generated some discussion :)

                          Cheers,
                          KEv.

                          • 10. Re: JBoss Eclipse IDE Portal Plugin requirement discussion
                            tuomas_kiviaho

                            WTP itself is capable of producing .war but of course antscript doesn't generate direct need for WTP to be installed.

                            Maven2 product descriptor instead/accompanied with the script would bring value that WTP is not providing, like support for continuous builds, archetypes (initial directory layout) that you can have an impact on, indirect dependencies between project and jboss portal + as specific libraries and more that Ant in a form of highly sophisticated shell scripting environment is not aimed for.

                            Of course more closer coupling with JBoss IDE would overlap some of the features maven is offering, like built-in classpaths, but then again plugin would be bound to the lifecycle of the IDE.

                            I'd be happy to see overlapping features of the IDE and maven to be replaced in favor of maven so that jboss people would have more time to concentrate on JEMS products themselves, but that another story...

                            • 11. Re: JBoss Eclipse IDE Portal Plugin requirement discussion

                              Kevin,

                              One suggestion on your code generation -- we have decided to standardize on FreeMarker as our "template engine of choice" for codegen in JBossIDE.

                              It would probably be beneficial for you to adopt FreeMarker as this would make your codegen as pluggable as possible (see HibernateTools excellent extendability WRT artifact generation)

                              • 12. Re: JBoss Eclipse IDE Portal Plugin requirement discussion

                                Nice! I'll definitely work that in, I was looking at going that route anyway, but now I know which template engine you like I don't need to do any research on which one to use...

                                • 13. Re: JBoss Eclipse IDE Portal Plugin requirement discussion

                                   

                                  "rincewind23" wrote:
                                  I take your point that you are primarily looking at skeleton development of JSF-type portlets. However, do you agree that it would be good to develop in such a way that in the future it would be possible to "plugin to the plugin" other skeleton producers? So if someone feels that they prefer to develop X-type portlets, they can develop a class (which conforms to some as-yet unwritten) API which provides the skeleton in some other format?


                                  Yes. This is a good idea, that I did not consider. o_0

                                  • 14. Re: JBoss Eclipse IDE Portal Plugin requirement discussion
                                    legolas

                                    What about an option to generate a Portlet skeleton only compliant to the standard API? I mean without anything specific to JBoss Portal.

                                    Using the dynamicity feature a war file compliant to the Java Portlet standard (JSR168) can be easily deployed into JBoss portal. That means there's no need to add the specific JBoss descriptors to the bundle and would increase the usability of the eclipse plugin drastically.

                                    I really appreciate the effort you're making in getting a proper eclipse plugin for portlet development, thanks in advance and if I can find the time I'd like to aid in the realization.

                                    Cheers,
                                    Marcel

                                    1 2 Previous Next