Comment 1 Eclipse Webmaster 2007-07-29 09:23:29 EDT

Changing OS from Mac OS to Mac OS X as per bug 185991

Comment 2 Daniel Weber 2008-02-19 07:32:59 EST

Created attachment 90056 [details]
cdt based implementation of a CppBeautifier

An XPand post processor for C/C++ code formatting based on cdt's code formatter. Is uses some internal cdt classes to do its job, but this was he only way to get this to work outside an Eclipse runtime. Use it like this (from an oaw workflow): 

   <!--  Use c++ beautifier with a custom set of options -->
   <component class="oaw.xpand2.Generator">
      <expand value="CreateCppSource::root FOR 'CustomFormat'"/>
      <outlet path='src-gen'/>
      <beautifier class="org.openarchitectureware.xpand2.output.CppBeautifier"  
                  configFile="custom.xml"/>
   </component>
 
In order to create a configuration file, use cdt's preferences to set formatter options and then export that configuration to a file. 

The code to load options from the formatter properties file has been *copied* from JavaBeautifier, as it is private there ==> loadFile and readConfig should be moved to somewhere else and used by both beautifiers (check the @todos in CppBeautifier).

The only cdt plug-in that is required is org.eclipse.cdt.core (tested against version 4.0.2).

Comment 3 Bernd Kolb 2008-02-21 12:41:04 EST

Thanks Daniel,

We will apply that to the HEAD at M2T

Comment 4 Karsten Thoms 2009-11-28 08:37:36 EST

Created attachment 153300 [details]
Plugin proposal org.eclipse.xpand.adapter.cdt incl. example

The attachment contains is the adopted version for M2T Xpand. The implementation of the postprocessor is contained in a new plugin org.eclipse.xpand.adapter.cdt, which has plugin dependency to org.eclipse.cdt.core.

As an alternative the postprocessor could also go to the org.eclipse.xpand project when the dependency to CDT is loosely coupled with Import-Package. But the new adapter plugin seems to be most appropriate solution.

Comment 5 Dennis Huebner 2009-12-01 14:05:09 EST

Hi,
Xpand adapters, such as XSD or UML2, provide at least a typesystem imlementation, so I think that "adapter" is not a well-fitting name for an additional post processor implementation.
Maybe something like org.eclipse.xpand.support.cdt?

Best regards,
Dennis.

(In reply to comment #4)
> Created an attachment (id=153300) [details]
> Plugin proposal org.eclipse.xpand.adapter.cdt incl. example
> 
> The attachment contains is the adopted version for M2T Xpand. The
> implementation of the postprocessor is contained in a new plugin
> org.eclipse.xpand.adapter.cdt, which has plugin dependency to
> org.eclipse.cdt.core.
> 
> As an alternative the postprocessor could also go to the org.eclipse.xpand
> project when the dependency to CDT is loosely coupled with Import-Package. But
> the new adapter plugin seems to be most appropriate solution.

Comment 6 Karsten Thoms 2009-12-01 16:15:15 EST

It is not defined that "adapter" means "tooladapter". It can be seen as a bridge which introduces non-trivial dependencies to third party features, as to the XSD SDK, CDT, WST, EMF Compare, ATL or whatever. I don't see it as an requirement that an adapter-plugin requires an implementation of a type system. It can also be a set of extensions, workflow components, transformations.

However, introducing a plugin "category" 'support' would be also OK.

Comment 7 Karsten Thoms 2009-12-06 08:08:41 EST

- Committed plugin "org.eclipse.xpand.support.cdt" to CVS.
- Added plugin to org.eclipse.xpand.sdk-feature

Changes to org.eclipse.xpand.releng
- Added plugin to xpand.map.
- Added plugin to team project sets.
- Added ${downloadMirror}/tools/cdt/releases/galileo/dist/cdt-master-6.0.1.zip to build.properties

Comment 8 Karsten Thoms 2009-12-06 08:08:50 EST

Created attachment 153886 [details]
mylyn/context/zip

Comment 9 Karsten Thoms 2009-12-09 14:33:56 EST

Improved the implementation of the initial CppBeautifier. It had problems to resolve the default settings when deployed as plugin and caused ugly NullPointerException. Further it reloaded the configuration for each file.

Next step is to integrate the plugin into the build. Therefore the org.eclipse.cdt.core plugin has been added to build.properties. Including the Zipped update site from CDT into dependencyUrls lead to failing build. Now added the CDT update site as repositoryUrl and the plugin as to-be-installed.

Comment 10 Karsten Thoms 2009-12-10 16:51:10 EST

The plugin had to be removed from the SDK feature again. It caused that clients install CDT with the SDK, which is not wanted. It should be examined further how we integrate support plugins into the build.

Comment 11 Karsten Thoms 2011-08-22 16:10:37 EDT

The plugin has been made available in the feature org.eclipse.xpand.support, already for Helios release. I consider this as closed now.

Comment 12 Karsten Thoms 2013-02-21 08:11:55 EST

Bug resolved before Xpand 1.2 release date => Closing