[kepler-dev] Proposed Future Kepler Configuration System

[David Welker]

Hi Christopher,

Thanks for your suggestion. A couple of thoughts on your ideas regarding 
closely integrating with Eclipse or Netbeans.

1) The scope of your suggestion is much greater than the incremental 
configuration project I had in mind. It goes quite a way beyond mere 
configuration and perhaps has implications for distribution, integration 
with other tools, how modules are defined and interact, how we build, 
and how developers work. It is not clear to me to what extent one can 
choose to just buy into these platforms incrementally, without more or 
less converging onto the Netbeans or Eclipse way of doing things. This 
would be a rather large, rather than small, effort. It would be a major 
decision.

2) To really integrate with Netbeans or Eclipse would involve very 
significant refactoring of the GUI. (There will, of course, be some 
refactoring of how the GUI is configured with the project I am 
contemplating, but probably on a smaller scale.) My question is Ptolemy 
in doing that sort of work? I could imagine a scenario (after careful 
evaluation of costs and benefits) where Ptolemy and Kepler work towards 
a common standard based on either Eclipse or Netbeans. But I think the 
costs for Kepler are much higher if we were to try to go it alone 
(because so many changes are implied in Vergil by such a move).

3) I can definitely imagine benefits to closely integrating Kepler with 
Eclipse or Netbeans. For example, allowing users to modify actor code by 
right-clicking on it from inside of Kepler. It could also define a more 
convenient distribution model, allowing us to more seamlessly provide 
updates to users. I can also imagine costs associated with the 
complexity of integrating Kepler into either of these ecosystems.

4) If the goal is to simplify configuration, then integration with 
Eclipse or Netbeans likely contradicts that goal. Configuration would be 
more complicated, because both Netbeans and Eclipse have fairly complex 
configuration systems in place. I could roll out a custom configuration 
system that is simpler and easier to use much faster than we could 
integrate with either the Eclipse or Netbeans ecosystem. So, any 
decision to integrate with these ecosystems should be based on concrete 
benefits provided by integrating with the tool sets available in these 
platforms, not any illusions that this would simplify configuration.

5) If we use either Netbeans or Eclipse as a platform, why we would not 
be officially "blessing" one IDE over another, we would in fact be 
favoring one over another. The best tools for making Netbeans plugins 
and modules for Netbeans is Netbeans itself. The same is true of 
Eclipse. We should realize that if we do decide to integrate with a 
particular IDE, we are making one IDE much easier to use than others, 
even while not officially preventing the use of other tools.

Overall, after an initial examination, I am somewhat skeptical that we 
should be integrating with either Eclipse or Netbeans. I think it would 
be a fairly large amount of work, would make configuration more complex 
and not simpler, and would in a de facto way tie us to a particular IDE. 
Right not, I am not entirely convinced that the concrete benefits I see 
(mainly having to do with distribution of new modules and perhaps 
integrating the code development capabilities of Eclipse or Netbeans 
with Kepler/Ptolemy) are worth the work and added complexity. But, I am 
definitely open and am willing to be convinced.

David



> Hi David,
>
> Thanks for summing up the current configuration details.
>
> I suggest reviewing how Eclipse and Netbeans do platform rich client
> platforms (RCP).  Is it necessary to invent yet another system?
> You may want to compare and contrast your design with prior art as
> they have addressed similar issues.
>
> _Christopher
>
> David Welker wrote:
>> Hello everyone,
>>
>> I have done a basic review of the current Kepler Configuration System 
>> and have developed a proposal for a new Kepler Configuration System.
>>
>> Please see my proposal here:
>>
>> https://dev.kepler-project.org/developers/teams/framework/kepler-configuration/proposed-future-kepler-configuration-system/ 
>>
>>
>> Also, I have briefly documented a subset of the existing 
>> configuration files. If anyone wants to add to or elaborate on that 
>> documentation, they should feel free to do so. That basic 
>> documentation is available here:
>>
>> https://dev.kepler-project.org/developers/teams/framework/kepler-configuration/current-kepler-configuration/ 
>>
>>
>> Anyway, I am moving forward with a prototype that implements my 
>> proposal. However, in parallel, I would like to have a discussion 
>> about how people feel about the proposal and any additional 
>> configuration-related features that they would like to see.
>>
>> Thanks!
>>
>> David Welker
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at kepler-project.org
>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>