[kepler-dev] netbeans RCP investigation
ian.brown at hsbcib.com
ian.brown at hsbcib.com
Wed Jun 4 01:16:34 PDT 2008
A couple of weeks ago I spent some time looking into what would be
required to re-implement the ptolemy vergil application as a netbeans RCP
application. The main purpose was to understand what problems would be
encountered and to allow us to better estimate the work involved in going
down such a route.
I have put a recent version of the source tree onto my private web-space.
Please don't publish the URL too much because I have limited bandwidth and
pay for exceeding it (it's enough for anyone on this list to download it -
but if you want to make it more public then please make local copy and
publish that URL). To compile, you will need Netbeans 6.1. I used JDK 6
but you should be able to use JDK 5 too.
Initial feedback from Christopher is copied below.
ptnb220508_src.zip is the clean source tree. You should be able to
just
unzip it and then load it as a netbeans project (using netbeans 6.1).
More
details are in the file attached (NBConversion.txt - which is also in
the
source zip).
The files are in this directory:
http://www.ijbrown.net/ptolemy/
Ian
----- Forwarded by Ian BROWN/IBEU/HSBC on 04/06/2008 09:04 -----
"Christopher Brooks" <cxh at eecs.berkeley.edu>
Sent by: cxh at EECS.Berkeley.EDU
24/05/2008 02:35
Mail Size: 16312
To
Ian BROWN/IBEU/HSBC at HSBC
cc
eal at eecs.berkeley.edu
Subject
Re: netbeans RCP
Entity
Investment Banking Europe - IBEU
Hi Ian,
I know you are away and all, but I thought I'd send a round of email
so that Edward knows the status.
The Netbeans RCP Ptolemy client looks very promising!
I've taken the contents of your NBConversion.txt and reproduced it
below. My comments are interspersed.
Ian writes.
> Some notes on converting Ptolemy to a netbeans Rich Client Platform
> (RCP) application.
>
> Source code organisation
> ~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> The first thing to note is that the Ptolemy II source code is arranged
> on disk in the manner of a C++ program. There is one large source
> tree which contains the source code in addition to the data and the
> tests. The selection criteria for which files make it into the final
> distribution is coded into the various makefiles. In Java, the
> convention is that the filesystem directly represents the classes that
> are shipped. This leads to shipping source files and unit test files
> occupying separate paths in the file-system. Current IDEs such as
> netbeans and eclipse assume this layout for projects that they build.
>
> The first step was to re-organise the layout of the PTII files to more
> closely reflect the layout of a standard Java application. This
> involved separating the source files from the test files and also
> splitting the monolithic single JAR structure into a number of
> independent modules.
Ideally, we would be able to stick with the basic structure we have.
I'd like to be able to run both the currently make based Ptolemy
build, the Eclipse based Ptolemy build and the NetBeans based Ptolemy
build.
In general, I think we need to have some sort of manifest files that
list the files and directories that should be in each package.
Currently, we are using makefiles for this, but I'm more than willing
to move to something else. I don't think the "jar up everything"
approach will work for us because we don't necessarily want to ship
everything.
We need to keep the tests close to the source or else they won't get
updated, run and moved as necessary. We consider source code
to be a form of publication and that the source code should be
available at runtime for viewing by the user.
Ptolemy is a research project, so new work appears in the directory
hierarchy, but is not necessarily shipped in a release. I think we
need to keep a directory structure so that the modules are manageable.
Ptolemy is all about hierarchy, we should use hierarchy in our module
system. A flat list of packages is not going to scale well.
That said, we can do quite a bit more with refactoring the code
to break dependency loops etc. I look forward to reviewing
the build system on which the Kepler team is working.
> Build Instructions
> ~~~~~~~~~~~~~~~~~~
>
> You will need Netbeans 6.1
>
> Open the ptnb project from within netbeans and press the run
> button. This should compile and launch the application. To build a
> stand-alone zip distribution, right click the 'Ptolemy on Netbeans'
> project and select the appropiate action from the context menu.
Worked for me! There are plenty of warnings that I should
clean up though.
> Changes made to the PTII source files
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> The primary aim has been to alter the original source code as little
> as possible. It was necessary in some places though to break the
> coupling to vergil. In particular,
> ptolemy.vergil.basic.BasicGraphController is tightly coupled to
> ptolemy.vergil.basic.BasicGraphFrame via the get/setGraphFrame()
> member. This is used by the derived controllers to notify changes via
> the status bar amongst other things. In Netbeans RCP, we want to use
> the various xxxGraphControllers - but we will not be using the
> xxxGraphFrame classes. This is because we will replace the frames with
> GUI components provided by the netbeans platform.
>
> To break the coupling, I define an interface IGraphFrame which
> BasicGraphFrame and my netbeans based frame both implement. This
> allows me to continue using the GraphControllers.
I'll see about folding this in.
> Edited Configuration._removeEntity() so that it does not try and exit
> the runtime. We need to let netbeans RCP deal with that.
Is there is some way to tell if we are under netbeans?
Perhaps by checking a property?
I modified ptolemy.util.StringUtilities.exit() so that if
the ptolemy.ptII.doNotExit property is set then we don't exit.
So, the Netbeans specific code could set this.
> Classloading issues
> ~~~~~~~~~~~~~~~~~~~
>
> Splitting the application into a number of independent modules means
> that we need to be a bit more careful with the class
> loaders. PlotBox.java needed to be changed to specify the class loader
> when calling ptolemy.util.FileUtilities.nameToURL()
I fixed PlotBox and took a look at other uses of nameToURL().
There are some places where we have a static method, so
getClass().getClassLoader() will not work.
There are some places where we could be getting a resource from any
package.
We can handle these as necessary.
> The Moml loader needed to be changed to specify the system class
> loader for the netbeans platform (allowing it to access all plug-ins
> that are loaded). For details, see:
>
http://bits.netbeans.org/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/classpath.html
I'll look into this.
> Package Visibility
> ~~~~~~~~~~~~~~~~~~
>
> TableauFrame$ExtensionFileFilter was defined with package
> visibility. This causes problems when accessing it from the same
> package but different JAR. Not sure why - almost certainly a
> classloader issue. In any case, I changed it to protected access so
> that PlotTableauFrame can access it from a separate plug-in jar.
I made this change. There are other changes for NetBeans
in TableauFrame though.
> Modularisation
> ~~~~~~~~~~~~~~
>
> A main goal was to have independently loadable modules. I want a user
> to be able to develop a module and install it into the system without
> needing any changes to the source or configuration of the base
> system. In the existing vergil set-up this is not possible because the
> configuration files need to be changed.
Agreed. Editing configurations is harder than it should be, most
users won't do it. The user library was supposed to make it easier
for users to add a few actors. We have a contract to make it easier
to create configurations.
> I wanted a module to be able to implement a number of directors &
> actors and then to be able to supply its own configuration file that
> would be dynamically grafted into the configuration tree upon
> initialisation. Using the Lookup API (an extension to the Service
> Provider API available in Java 6 ... but available in Java 5) this
> is reasonably simple. I define a service provider interface in
> ptolemy.configs called ConfigProvider, defined as follows:
>
> public interface ConfigProvider {
> /** @return the URL to a configuration file. */
> public URL getConfigPath();
> }
>
> Each module needs to implement this interface and then advertise it in
> META-INF/services. For example, the DE Domain plug-in implements it as
> follows:
>
> public class DEDomainConfigProvider implements ConfigProvider {
> public URL getConfigPath() {
> URL configurationURL = null;
> try {
> configurationURL =
FileUtilities.nameToURL("$CLASSPATH/ptolemy/configs/DEDomain.xml", null,
> this.getClass().getClassLoader());
> } catch (IOException ex) {
>
Logger.getLogger(DEDomainConfigProvider.class.getName()).log(Level.SEVERE,
null, ex);
> }
> return configurationURL;
> }
> }
Looks promising!
> When the application starts, the singleton top level window component,
> ModelsTopComponent loads the main configuration and then grafts in any
> other configurations provided by all of the ConfigProvider services
> that it finds. The code looks as follows:
>
> protected void _readConfiguration() throws Exception {
> URL configurationURL = FileUtilities
> .nameToURL("$CLASSPATH/ptolemy/configs/configuration.xml",
> null, this.getClass().getClassLoader());
> System.out.println("ConfigurationURL: " + configurationURL);
> _configuration =
MoMLApplication.readConfiguration(configurationURL);
>
> MoMLParser parser = ParserAttribute.getParser(_configuration);
>
> Lookup lookup = Lookup.getDefault();
> Template template = new
Template(ptolemy.configs.ConfigProvider.class);
> Result result = lookup.lookup(template);
> Collection<ptolemy.configs.ConfigProvider> configs =
result.allInstances();
> for (ptolemy.configs.ConfigProvider c : configs){
> parser.setContext(_configuration);
> URL cfgURL = c.getConfigPath();
> System.out.println("ConfigurationURL: " + cfgURL);
> parser.parse(cfgURL, cfgURL);
> }
> }
>
> This implementation gives us all the funcionality that we need. A user
> can download a plug-in module via an on-line portal which could
> provide new directors and actors. When the application is restarted,
> these new actors and directors will be available for use as if they
> were part of the core application.
>
> For more information about the Lookup API and how it compares with the
> standard Java service provider Interface, see the article by John
> O'Conner:
>
http://java.sun.com/developer/technicalArticles/javase/extensible/index.html
I'll look into this!
> Remaining issues with dependencies
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> ptolemy.domains.fsm.modal.ModalModel extends
> ptolemy.domains.ct.kernel.CTCompositeActor. This means that the FSM
> domain depends on the CT domain. The problem here is that the
> data.properties.lattice depends on the FSM domain. This means that you
> cannot easily separate FSM, CT and the core.
This is a long standing problem, it would be nice to fix this.
> The data.properties
> package also references the ptolemy.domains.dde.kernel.NullToken class
> which is a pain. It's the only class referenced though so I have just
> included this single class in the core and externalised the rest of
> the dde package.
data.properties is optional and need not be supported yet. Perhaps
we should move this directory out of data? Currently, data
has just Kore code in it. Perhaps data.properties could be an
extension to data?
> Ian Brown
> May 2008
I have a couple of todo items above. I think the big issue
is how to structure the source code. I'd like to leave the files
where they are, or at least have a hierarchical directory structure of
packages.
There is also an issue of how best to work together. I could start
checking in code in ptolemy.apps and see how it goes.
Also, I'll leave it to you to send email about this to Kepler-dev.
It does seem like there is a certain amount of common interest,
especially in the extensions mechanism and the refactoring for
BasicGraphFrame.
_Christopher
--------
It's almost time for me to head off on holiday for a week.
Still, found some time today to extend the netbeans RCP
implementation.
Additions are as follows:
1. Models tree now displays hierarchy of model as well as the models
that
are open.
2. Double clicking on a node in the model tree (or selecting view from
the
context menu) shows that composite entity in a graph editor.
3. FSMs display correctly.
I'll upload the source to my web-space in a little while. I've also
synched with the latest CVS source as from this morning.
Enjoy,
Ian
"Christopher Brooks" <cxh at eecs.berkeley.edu>
Sent by: cxh at EECS.Berkeley.EDU
20/05/2008 17:44
Mail Size: 8728
To
Ian BROWN/IBEU/HSBC at HSBC
cc
eal at eecs.berkeley.edu
Subject
Re: netbeans RCP
Entity
Investment Banking Europe - IBEU
The files are in this directory:
http://www.ijbrown.net/ptolemy/
I look forward to you feedback.
Ian
************************************************************
HSBC Bank plc may be solicited in the course of its placement efforts
for
a new issue, by investment clients of the firm for whom the Bank as a
firm
already provides other services. It may equally decide to allocate to
its
own proprietary book or with an associate of HSBC Group. This
represents a
potential conflict of interest. HSBC Bank plc has internal
arrangements
designed to ensure that the firm would give unbiased and full advice
to
the corporate finance client about the valuation and pricing of the
offering as well as internal systems, controls and procedures to
identify
and manage conflicts of interest.
HSBC Bank plc
Registered Office: 8 Canada Square, London E14 5HQ, United Kingdom
Registered in England - Number 14259
Authorised and regulated by the Financial Services Authority.
************************************************************
************************************************************
HSBC Bank plc may be solicited in the course of its placement efforts for
a new issue, by investment clients of the firm for whom the Bank as a firm
already provides other services. It may equally decide to allocate to its
own proprietary book or with an associate of HSBC Group. This represents a
potential conflict of interest. HSBC Bank plc has internal arrangements
designed to ensure that the firm would give unbiased and full advice to
the corporate finance client about the valuation and pricing of the
offering as well as internal systems, controls and procedures to identify
and manage conflicts of interest.
HSBC Bank plc
Registered Office: 8 Canada Square, London E14 5HQ, United Kingdom
Registered in England - Number 14259
Authorised and regulated by the Financial Services Authority.
************************************************************
-----------------------------------------
SAVE PAPER - THINK BEFORE YOU PRINT!
This transmission has been issued by a member of the HSBC Group
"HSBC" for the information of the addressee only and should not be
reproduced and/or distributed to any other person. Each page
attached hereto must be read in conjunction with any disclaimer
which forms part of it. Unless otherwise stated, this transmission
is neither an offer nor the solicitation of an offer to sell or
purchase any investment. Its contents are based on information
obtained from sources believed to be reliable but HSBC makes no
representation and accepts no responsibility or liability as to its
completeness or accuracy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-dev/attachments/20080604/546c76d3/attachment-0001.htm
More information about the Kepler-dev
mailing list