Re: [cdt-dev] CMake plugins

[Martin Weber <fifteenknots505@xxxxxxxxx>]

Am Montag, 20. November 2017, 16:10:12 CET schrieb Doug Schaefer:
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> > Behalf Of Martin Weber
> > Sent: Saturday, November 18, 2017 4:53 PM
> > To: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
> > Subject: Re: [cdt-dev] CMake plugins
> > 
> > Am Donnerstag, 9. November 2017, 20:36:03 CET schrieb Doug Schaefer:
> > > Well, the good news is that all we have today in the CDT is the Core
> > > Build integration and project templates. Plenty of room to expand and
> > > grow that in other areas, especially the editor. I look forward to all
> > > of your contributions and help.
> > 
> > Good news!
> > All original copyright holders of CmakeEd approved to change the license
> > to EPL. I will mail the approvals PM, if requested.
> 
> That's awesome. Thank you for getting that together. I think that action of
> changing the copyright notices would be sufficient evidence of the
> agreement.

Actually, I did not change the copyright lines in each source file. I changed 
the license in the main license file, in the pom and in the feature.xml to 
EPL. These were the only location mentioning 'CPL' or 'common public'.
The source files did not and do not mention any license, so I did not take a 
step to add these. But that can be added, if required.

IMHO changing the license is a thing between me and the to original authors, I 
do not see that eclipse.org should be concerned. BTW: I did change the license 
already (yesterday). 

...

> 
> > NOTE: CmakeEd roughly follows the releases cycles of cmake as they evolve
> > their language, which is about every 3-4 weeks currently. EPP cycles are
> > much longer.
> 
> Does the language actually change every 3-4 weeks? Are these minor releases
> or maintenance releases. Projects can release maintenance releases at

Those are minor releases [1]. Most of the time cmake learns some new keywords 
[2] or commands, the syntax stays nearly unchanged. Since I recently added a 
script that updates that can update syntax highlighting data and tool tips 
data from cmake source. That makes it easy to cope with cmake`s release cycles 
now.

...

> We can make CMake be its own component so it has a clean slate. And CDT
> doesn't have 65K open issues. It's only around 4k. And if we actually
> triage them, there would be way less.
> > - cmake itself is not tied to just C/C++. According to [1], cmake can
> > generate build scripts to compile at least eight source languages. I
> > think it`s better to have CmakeEd below some kind of 'Eclipse Source
> > Editors' umbrella.
> 
> That same argument could be made for most CDT features like build and debug.
> Only the editor and source navigation are C/C++ specific. And we have plans
> to bring target management into the fold.
> 
> We could make it a subproject of CDT. There are certain project management
> things that need to be done for Eclipse projects, release reviews, CQ's,
> etc. It's a non-trivial amount of work that we're already doing in CDT. It
> is well documented here: https://eclipse.org/projects/handbook if you
> haven't already seen it.

Yes the project management things are a lot of work to do, nothing I really 
like to deal with. So either lets make it a subcomponent of CDT or put it 
under some other umbrella umbrella under eclipse.org.
I already filed a project proposal [3], but today I cannot find it. Maybe you 
could chime in there.


About the project code itself: I inherited in 2016 and did not touch much of 
its code (only fixed 2 annoying bugs).
My contribution mainly were: Move project from SF to github, keeping ist 
change history. Add a build script (maven tycho). Set up CI to build from 
pristine source and upload artifact  to bintray. Plus I added a composite 
update site and made the marketplace point to it, as you already know.

The plugin also comes with cmake documentation in form of eclipse help, but 
that is really outdated. This bloat could/should be removed, no-one ever 
raised an issue about the outdated docs, and each user of cmake has the docs 
already on disk.

Awaiting to here how to proceed,
	Martin

[1] https://cmake.org/files/v3.9/?C=M;O=A
[2] https://cmake.org/cmake/help/v3.9/release/3.9.html
[3] https://www.eclipse.org/forums/index.php/f/202/

-- 
Cd wrttn wtht vwls s mch trsr.