PXCustomPlatformProject

Custom Platform Project

Fabrizio Giudici and Wade Chandler

Work in progress

This is a project to create a special project which can be used to link together different NB RCP/Platform source and binary artifacts. This should help them more easily be used as dependencies. The chosen scheme should also allow this project to seamlessly work with the current NB RCP project support.

Project Tracked In IssueZilla as Issue 148571.

Contents


Project Type

This would be a new project type. It will be able to bring all types of artifacts or dependencies together into a single platform. Bring these things together into a single platform allows this to seamlessly integrate into the current NetBeans IDE RCP support. The project type should support or provide:

  1. New Project Wizard
  2. Project Properties Panel plus all needed requirements
  3. build.xml along with a set of other project files and build scripts linking things together
  4. Custom Ant classes and tasks used by the IDE
  5. The ability to manage source, binary, and auto-update dependencies/artifacts. These and technically the types should be something pluggable or registered in the XML files system. This can allow the project support to be modular in itself and the different pieces to be added systematically and new things to be integrated seamlessly such as Maven or Ivy repositories and support.

New Project Wizard

Description

Just as all projects in the IDE have to begin with a few simple questions, so shall a custom platform project:

  1. The user will choose something like New->Project->NetBeans Modules->Custom Platform
  2. The first panel will provide the user fields to allow them to enter the platform name and the directory where the project should be placed and if the user would like to set it as the main project.
  3. The second panel will provide the user the chance to select the initial source type dependencies.
  4. The third panel will provide the user the chance to select or enter binary dependencies.
  5. The fourth panel will provide the user the chance to select or enter auto-update center
  6. The next panel is a simple finish screen which gives the user the chance to go back and make changes if needed.

We may need to think through possible ways to make the wizard panels pluggable. We definitely need to think about making the buttons on the different dependencies screens pluggable. This would provide the ability to make other areas pluggable including the project structure. This would allow the system to grow. To make the structure pluggable we can have a directory where sub-build files may be placed which can use shared Ant scripts and other resources.

Screen Mockups

@todo

Project Properties Panel

Description

This is the panel, predictably enough, accessed by right clicking on a project and choosing Properties.

This will provide much of the same things as the wizard panels.

  1. A place to change the name of the platform
  2. A hierarchy describing the dependencies. This would be in the Left view of the properties dialog. Something like Libraries with sub panels Source,Binary, and Auto-Update. Of course if this is modular in design then more of these may be possible to add.
  3. A panel for Source dependency management
  4. A panel for Binary dependency management
  5. A panel for Auto-Update dependency management

Screen Mockups

@todo

Project Structure

@todo

Custom Ant

@todo

Types of Dependencies

  • Source
  • Module Project
  • Library Wrapper Project (pseudo source)
  • Suite Project
  • Binary
  • JAR
  • NBM
  • Platform
  • URL to Platform
  • URL to NBM
  • URL to JAR
  • Auto-Update
  • catalog.xml local file system file
  • http based auto-update URLs
  • other URL based auto-update sources which could exist

Note's and other things to help air out the design

Fabrizio's Initial Notes

  1. The user selects "Tools / Create NetBeans Platform"
  2. A wizard appears
  3. The first page asks for: 1) the platform name and 2) the directory where the platform will be created; furthermore a list of sources appears, with add / remove buttons. Sources can be: 1) the current IDE platform, 2) the http:// URLs for the Update Centers, 3) Custom specified directory where a catalog.xml(.gz) and .nbm files have been previously stored and 4) Custom http:// URLs for other Update Centers.
  4. The user fills in the data and presses "Next".
  5. Relevant information are downloaded from the internet and eventually loaded from the local directories, and a list of available modules and related dependencies is built. In the meantime a "Please wait" message is presented to the user.
  6. When all information has been downloaded, a panel similar to the one in the old plugin manager appears: at the left the list of available modules with checkboxes and other properties, at the right a detail pane with all the relevant information about the selected plugin.
  7. The user selects some modules by checking the checkboxes. Broken dependencies are shown in a red colored warning at the bottom of the panel.
  8. The user presses a button "Resolve missing dependencies" and the wizard automatically adds all the requested modules. A check is performed if there are still missing modules or inconsistencies; if they are present, the wizard refuses to proceed.
  9. There are not inconsistencies, so the user presses "Next".
  10. A new panel asks whether the new platform should be "flat" (a single cluster with the platform name will be created) or "not flat" (FIND A BETTER TERMINOLOGY), in which case multiple clusters will be created and every module put into its originating cluster. The user presses "Next".
  11. If the modality is "not flat" and there are modules not tagged with a cluster, another panel appears with a list of all the relevant modules, asking for the user to fill in a name for the cluster to put them into.
  12. The final operation is to create two directories: $TARGET_DIRECTORY$/nbm/ which is populated with all the relevant .nbm files and $TARGET_DIRECTORY$/platform where .nbm files are properly expanded - this latter directory can be feed in the platform manager. In the latter directory, the needed boot files are placed:

./THIRDPARTYLICENSE.txt ./core ./core/org-openide-filesystems.jar ./core/core.jar ./lib ./lib/nbexec.exe ./lib/org-openide-util.jar ./lib/boot.jar ./lib/org-openide-modules.jar ./lib/nbexec ./LICENSE.txt ./DISTRIBUTION.txt

WE HAVE A PROBLEM HERE: if the source platform was the current IDE, we can copy these files from there. If it was the platfrom from another IDE version (e.g. I'm using the IDE 6.1 but I want to create a platform based on 6.5) I don't know where to get those files from, as AFAIK they are not available in the Update Center.

  1. In the final panel a checkbox appears asking whether the user wants to import immediately the freshly created platform into the IDE.

Wade's reply to Fabrio's Initial Notes

Writing things here as I didn't want to change the Wiki just yet without talking it over. My ideas are slightly different yet similar and will probably require more work. At least they'll touch Ant, scripts, and RCP code to pull off.

>1. The user selects "Tools / Create NetBeans Platform"

What I write here goes with some other parts of my email.

What about: New->Project->NetBeans Modules->NetBeans Platform Deployment Project?

or something to that effect. See the rest of the email and we can come back to a name.

> 3. The first page asks for: 1) the platform name and 2) the >directory where the platform will be created; furthermore a list of >sources appears, with add / remove buttons. Sources can be: 1) the >current IDE platform, 2) the http:// URLs for the Update Centers, 3) >Custom specified directory where a catalog.xml(.gz) and .nbm files have >been previously stored and 4) Custom http:// URLs for other Update >Centers.

Do we really just want to go binary? Now, I suppose it could be binary if we had an Ant script which is generated which then lets the user build a binary platform, and that way they could include their dist directories. Either way I'm thinking here we could build a binary platform, but it would be basically a deployment project, and could be a sources project instead.

1) The wizard asks for the name and the directory where it will be created. 2) The wizard then asks for different forms of sources and a single *main* suite or platform. The main is where the branding and all is taken for the final result. The other things they user can choose are in a table which is similar to the libraries table of JSE project now, so there is a set of buttons running down the right side of the table such as "Add Platform", "Add NBM", "Add JARs as Library Wrapper" (could have a special editor for this which allows a set of JARS to be built versus just a file selection dialog, and we'd need an edit button for this entry type, "Add NetBeans Platform Deployment Project", "Add Suite Project", "Add Module Project", "Add Library Wrapper Project", "Add Auto-Update File", "Add Auto-Update URL", "Add Auto-Update Center". Maybe this different types of buttons could be broken out into their own wizard panels actually, so as laid out in the project properties: Libraries -Binary -Source -Auto-Update


>4. The user fills in the data and presses "Next".

After this a project will be created in the scenario I'm suggesting.

> 5. Relevant information are downloaded from the internet and >eventually loaded from the local directories, and a list of available >modules and related dependencies is built. In the meantime a "Please >wait" message is presented to the user.

This would all be done in the output window as Ant would take care of all this.

> 6. When all information has been downloaded, a panel similar to >the one in the old plugin manager appears: at the left the list of >available modules with checkboxes and other properties, at the right a >detail pane with all the relevant information about the selected >plugin.

This could be taken care of the project properties panels, or have a "Properties" button for each source.

> 7. The user selects some modules by checking the checkboxes. >Broken dependencies are shown in a red colored warning at the bottom of >the panel.

Maybe could have a button to do this. Work like resolve dependencies does now.


> 8. The user presses a button "Resolve missing dependencies" >and the wizard automatically adds all the requested modules. A check is >performed if there are still missing modules or inconsistencies; if >they are present, the wizard refuses to proceed.

In this case all things have to be resolved for the build to work anyways. An icon can express the issues on the project type as happens with other projects now.

> 9. There are not inconsistencies, so the user presses "Next". >10. A new panel asks whether the new platform should be "flat" (a >single cluster with the platform name will be created) or "not flat" >(FIND A BETTER TERMINOLOGY), in which case multiple clusters will be >created and every module put into its originating cluster. The user >presses "Next". >11. If the modality is "not flat" and there are modules not >tagged with a cluster, another panel appears with a list of all the >relevant modules, asking for the user to fill in a name for the cluster >to put them into.

This could be on a per dependency basis. That would make it more flexible. It would all be included on the libraries panels. I suppose an option to make *all* dependencies flat or clustered could then be added to turn on or off all of them.

>12. The final operation is to create two directories: >$TARGET_DIRECTORY$/nbm/ which is populated with all the relevant .nbm >files and $TARGET_DIRECTORY$/platform where .nbm files are properly >expanded - this latter directory can be feed in the platform manager. >In the latter directory, the needed boot files are placed: >./THIRDPARTYLICENSE.txt >./core >./core/org-openide-filesystems.jar >./core/core.jar >./lib >./lib/nbexec.exe >./lib/org-openide-util.jar >./lib/boot.jar >./lib/org-openide-modules.jar >./lib/nbexec >./LICENSE.txt >./DISTRIBUTION.txt >WE HAVE A PROBLEM HERE: if the source platform was the current IDE, >we can copy these files from there. If it was the platfrom from another >IDE version (e.g. I'm using the IDE 6.1 but I want to create a platform >based on 6.5) I don't know where to get those files from, as AFAIK they >are not available in the Update Center.

Do we really need to worry about this? Can't they just download that Platform anyways? That is a pretty big download. I guess though if we make the buttons in the dependencies something which are registered in the layer system, and do the same for project panels, and we make the Ant script capable of running scripts from a sub folder in the project hierarchy then folks can add what ever kinds of modules they want to do what ever they want with this system. We could even build it piece by piece that way, so we could get the binary stuff working first then add sources then auto-update...

>1. In the final panel a checkbox appears asking whether the user >wants to import immediately the freshly created platform into the IDE.

At this point it would just be up to the user to build the project when they needed. The final panel would just finish out if the user is satisfied with their selections and doesn't click back.

What do you think? Too much? Essentially what I envision is all dependencies would be built before we unpack and put together the platform. Ant will have to build all the sub source dependencies. There are no files which can actually be added to this project type other than if the user customizes the Ant script or adds some of their own Ant files to the directory structure through the "Files" window. This would solve a lot and could bring resources together.

If we make it smart enough then maybe we could have it build faster by only building those things which have changed. One possible solution is to have a special bit of Ant that is included from the private directory only if the IDE is running. This could make the system only try to build sub source dependencies when they have been changed during the IDE session. Along with that we could have a checkbox like other project types have which tells the project to not build the sub dependencies and to only handle binary things. This would mean that it would assume the binary files are in place and to only pull over the binary files which are modified. Ant would handle a lot of that for us I think as it keeps a cache of what it has moved from place to place and timestamps etc.

Anyways, that is my rough idea, and I need to work out some details related the work flow, which while trying to generally work them out there are some rough edges which need sorted, but I think some really neat things are doable by doing things this way which don't really impact the base NB RCP support other than complimenting them. We should technically even be able to provide refactoring support for areas which don't work correctly based on changes we make.

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo