Our current handling of .NET elements with a single class named CodeElement is not very flexible and is not a very good object-oriented design. I have attached a sample project that includes the modified MBEL source as well as a suggested reimplementation of how we should handle .NET elements. Note that the API is not set but they are there in hopes of starting some useful discussion. The API is modeled after JDT's IJavaElement structure.
The API's functionality is shown in the two classes in the org.emonic.base.views package. To see the API in action, you can use the org.emonic.core.Main class.
To see the it visually, you can modify your launch configuration to include the 'assembly2' plug-in project and then launch your second Eclipse instance. Now, open the 'Project Explorer' view and look for a dll in one of your projects or folders. You should see that it is now expandable. Expand it, a background job will run parsing the file, after it is completed, you should see all of the declared namespaces below it. Expanding those namespaces will show you the classes contained within it, and so on.
Please note that the code under the edu.arizona.cs.mbel package namespace is licensed under the LGPL. Note that the code here is not the same as what you will be able to download at the website as I have made some changes.
'assembly2' Eclipse project zip file
Logged In: YES
user_id=1858080
Originator: NO
Any changes here?
Logged In: YES
user_id=1299552
Originator: YES
> Any changes here?
They haven't replied to me with regards to a license change for MBEL. But I think I will move forward with making it a SourceForge project either way some time this week (and just have it licensed under the LGPL until they do reply with a "yes" or "no"). I can start making changes to CodeElement so that it will implement IDotNetElement if no one has any problems with that.
Logged In: YES
user_id=1299552
Originator: YES
The MBEL project has been created at SourceForge and I have committed both the original and the modified code to CVS. You can find the project here: http://sourceforge.net/projects/mbel
I will update the emonic.base code to add some features I've written in the past few weeks within the next day or two. This will introduce a plug-in dependency on edu.arizona.cs.mbel2, so please checkout that project from CVS into your Eclipse workspace.
Logged In: YES
user_id=1299552
Originator: YES
I've just committed the MBEL-related features into CVS. Please perform a CVS update and also checkout the mbel2 project from the MBEL SourceForge CVS repository if you haven't done so already. There are still some missing things like images and the duplication of properties in the 'Object Browser' and the like but the basics are in place. If you wish to view the XML documentation for an assembly, it must have the same name as the assembly except for the file extension itself, hence, NAnt.CompressionTasks.dll's documentation file should be NAnt.CompressionTasks.xml. Currently, the parser will only parse documentation that's created by the compiler. Since monodoc uses a different format, this functionality will not be available for code that is documented by monodoc.
Logged In: YES
user_id=1299552
Originator: YES
All the DLL analysis / retrieval information by emonicinformator should no longer be instances of CodeElement but other concrete implementations of the IDotNetElement interface.
For recordkeeping purposes in case we need to revert, the major changes were performed in the classes below.
Affected classes:
CSharpQuickAssistProcessor - 1.7 > 1.8
CodeElement - 1.24 > 1.25
CodeInformator - 1.67 > 1.68
DllInfo - 1.41 > 1.42