Re: [cdt-core-dev] CProject extension

[Pierre-Alexandre Masse <pmasse@xxxxxxxxxx>]

Our main idea is to provide more specific C Projects: C Application
project, C library project, Kernel project, ... This projects have
mostly cover by CDT but we would like to add a couple of specific
functions to them and in our mind it really makes sense to use CDT as
our core and base, and to just extend it to manage specificities of each
project.

As you said CProject and CModelManager are internal and therefore
shouldn't be subclassed or even accessed directly.
So to extend, we want to create other C Project using the ICProject
interface, and we want to use Natures to make them used by CDT.
Our problem today is that CDT knows only about the CNATURE and is not
flexible in accepting any other natures which would extend it. 

To sum up, the issues we would like to resolve are:
- non ability of CDT to accept other nature than the CNATURE
- references to classes like CProject, BinaryContainer, ArchiveContainer
and others inside the core of CDT when interface could be used (-> to
allow people to extend CDT using the interface which are exposed as the
implementation is not and should not)

In my mind the second point doesn't look like a big deal. But my
knowledge of CDT is far from complete and I may miss some difficulties.
If anyone can validate or explain me what could be a problem, that would
be nice.

The first point is not very complicated either and I started a
prototype. Here is what I did for this prototype:
- created an extension point that I called the CProjectNature to define
id and class of other c nature.
- get all connected extension ids when the CModelManager starts
- completed the CModelManager.hasCNature to check if the nature is of
one connected to the extension point
- created an ICProjectNature interface:
	public interface ICProjectNature extends IProjectNature {
		public ICProject createCProject(ICElement parent, IProject project);
	}
- added 'implement ICProjectNature' to the CProjectNature class
definition and implemented the interface.
- created a CModelManager.getCProjectNature(IProject) to return the
ICProjectNature of a project
- modified the CModelManager.create(ICElement,IProject) to call the
ICProjectNature.createCProject method instead of doing a 'new CProject'


I can send you a zip file of the modified org.eclipse.cdt.core if you
want.

Does it make sense ? Do you think the direction is correct or do you
have anyother ideas, adjustments, comments ... ?

To answer you question about entry points, I considered that people
creating new CProjectNature and CProject type will create their own
wizard and therefore will manage their project configuration
(association builder - project - nature). Does it make sense ?

I still have some cleanup to do but it already runs.
Also, as I don't have any approval yet from the eclipse team, I
minimized my changes in the cdt core and therefore the integration is
not the best it could be.

I hope it answers your questions. If you have more, do not hesitate,
keep going :) 
Comments and questions are more than welcomed.


Pierre-Alexandre


On Thu, 2003-06-05 at 11:54, Alain Magloire wrote:
> > 
> > Hi,
> > 
> > we are trying to create specific project type to extend CDT and add some
> > functionalities. In this process, I tried to understand how I could
> > create plugins that would extend cdt. And I have met at least one issue
> > for which I didn't find a way to turn around: the CModelManager creates
> > only CProject objects and therefore if I subclass CProject my object is
> > never going to be created by CDT. Tell me if I miss anything ....
> > 
> > If I understand well, to extend CDT I should create new natures, but I
> > can't find how to use natures to extend the CProject. Again maybe I miss
> > something here...
> > 
> > So with all of that, I thought we could make CDT a little bit more
> > generic to allow to extend CProject. I thought that the CModelManager
> > could create CProject (or others) based on the Nature of the IProject. I
> > guess we would need also a CNature interface to create the CProject.
> > 
> > Does that make sense ? or did I miss anything ?
> > If it makes sense, we (MontaVista) are ready to work on it and
> > contribute it back to the community.
> > 
> 
> Cool!
> 
> > If you need more details or have questions, let me know.
> > 
> 
> Yes more details 8-)
> What is it you want to achieve.
> 
> CProject and CModelManager are not meant to be visible nor
> subclass, this is why they are in
> 
> org.eclipse.cdt.internal.core.model.*
>              ^^^^^^^^^^^^
> 
> Notice the "internal", we could probably inforce this
> by changing the class scope to be package .. but probably not practical 8)
> 
> The entry point for creating a "C Project" is via the wizards.
> 
> For example org.eclipse.cdt.ui.wizards.StdMakeProjectWizard.java
> creates a C Project and set the Builder to be the default make builder
> i.e. spawning("make").
> 
> Other methods are helpfull in the
> 	org.eclipse.cdt.core.CCorePlugin
> and 
> 	org.eclispse.cdt.core.model.CoreModel
> 
> 
> 
> _______________________________________________
> cdt-core-dev mailing list
> cdt-core-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-core-dev
> 
>