Hi Hugo, Your are right, that this component should be IDE aware in the sense, that is has an api that future IDE implementations could use. I had this in mind, but since my main knowlegde lies in swing implementation, this was my first thought. I do have some knowlegde in eclipse plugins building, and from this I gather that it shouldn't be too hard to write the editor in that way, that the components would be reusable.
And I think that would be a great start for the community to skip in and do the DIE stuff. I will create a sourceforge project and keep this list informed. To Andrea: I have to disagree. Although normal xml editing shouldnt scare any decent developer, the main disadvantage in the hivemodule writing lies not in how to do xml tags and keep them correct, but in the knowlegde of how the contributions to an excisting configuration point should look like. In my last company I was the development lead of a very big swing ui (1.5 million lines of code) and we had a really big hivemind backbone (I still wonder, if our project is the biggest use of hivemind) with > 110 services, > 60 configuration points and > 50 schemata. And the project was split into round about 30 libraries. Now some developer had to use some functionality in our baseframework, he had to know the exact schema of the configuration point, which meant digging into the source code. (Ok, we could have used the hivedocs more excessivly, but the generation of the hivedocs was not integrated in our continous build environment). So this kind of editor, we are talking about would have greatly improved their work, because the editor would take over the part of knowing how those contributions shoudl look like. This has nothing to do with having the knowledge of writing valid xml. Greetings, Christian. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
