[eclipse-poky] Eclipse plugin development on timo/maven

[Paul Eggleton]

On Thursday, 25 January 2018 2:42:58 PM NZDT Tim Orling wrote:
> > 1) We have a yocto-bsp tool available in the Yocto Project Tools menu provided by the plugin - I suspect we should just drop this since the underlying yocto- bsp tool this will be calling is now gone.
> > 
> > [Scott]  I agree.
> [Tim] We should file a bug to track that.

Done:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=12509 
 

> > 2) If I try to create a new project, there don't seem to be any project templates available that look like they are provided by the plugin, is that expected? I know we used to have these in much older versions of
> > the plugin.
> > 
> > [Scott] If I do New Project... -> C/C++ Project -> Next -> C or C++ Managed Build Project
> > 
> [Tim] Also we are trying to move away from Yocto specific things, when the upstream provided types can be reused. Less prone to breakage and less maintenance.

Right, makes sense.
 
> > There is a category on the lower left for Yocto Project SDK Autotools Project.   These are provided by our plugin.   We may want to make them more prominent in the wizard...something for discussion.
> > 
> [Tim] Agreed. I also have an icon in WIP that could be used to more prominently identify YP project types. It is similar to the favicon for the yoctoproject.org site.
> 
> > I'm [Scott] not feeling very well today, and seem to be feeling worse, so I'm going to miss our call this afternoon.   My current status:   
> > 
> > 1) I think we are ready to move what's now on timo/maven to master.   We have to send notice about our plans to yocto mailing list...and get feedback before doing so...I suggest we also send our plans for 2.5 and 2.6 and ongoing eclipse-poky development...along with notice about eclipse-poky mailing list.
> > 
> [Tim] Agreed. I would like Scott and Paul to drive that email.

Sure, I'll take what Scott has written in the earlier private email and send it out tomorrow.

> > 2) Once on master my plan is to remove RSE references.   This should be easy now that bb commander is going.
> > 
> [Tim] There was discussion on the cross-projects issues Eclipse mailing list that RSE might be disabled for Photon, so this is the right direction to move. Get rid of it and figure out how to provide whatever functionality was there previously if needed.

Sounds good to me.

> > 3) Once in master I'm also going to introduce the new plugin that uses org.eclipse.remote to redirect autotools makefile gen to docker container.
> > 
> [Tim] I would like to get Oxygen.2 patch and setup.sh package version parsing fix into master, then merge master to oxygen-master, then “freeze” oxygen-master and apply a rebased timo/maven as the new master (or rather, I will create a timo/maven.2 which will be rebased on master). From then on master will be only new development and all bug fixes will be back ported to the specific oxygen-master or neon-master branches.

Also sounds good to me, FWIW.
 
> > I guess another question is can we get commit rights for direct-to-master commits (?)  
> > 
> [Tim] Sorry, but Yocto Project workflow is email patches only. We cannot deviate from that until we get approval from RP and others on the Advisory Board and there are not a lot of compelling reasons for them to agree to that change.
>
> Instead, we should investigate whether EGit can generate email patches or you can work on a eclipse-poky-contrib branch and use the Yocto Project “create-pull-request” script or equivalent. You can always direct commit to a feature branch all you want, especially if it is on eclipse-poky-contrib. You can even erase history as long as nobody is depending on it.

Right that's the way we tend to operate; it does take a little getting used to but it works well as long as there are people reviewing the patches / pull requests sent in and there's someone who is merging them.

> > Sorry about the no-show today.
> > 
> [Tim] Hope you are feeling better soon.

Likewise.
 
> >> One thing I realized, however, is that this launch config won't work on
> >> windows.   This is not an immediate concern, but we will need to deal with
> >> it.   In fact, the target definitions that we have also won't work on
> >> windows.    One question for discussion:  do we want to have separate target
> >> definition files for OS/archs...e.g. linux/x86_64, win32/x86_64?    Along
> >> those lines...do we need/want to support all of mac, linux, win X 
> >> x86_32, x86_64?
> > 
> > I would say let's start small - Linux and Windows 64-bit and then go from there. At minimum we should have a bug open for Windows support if we don't already.
> 
> [Tim] I believe we will run into issues with the Docs not being buildable on Windows, although it is possible MSYS2 (or MINGW) can satisfy the build dependencies (as mentioned in prior email about building the docs). Currently, those dependencies are HOST tools and not built as -native tools by YP.

Could we just disable doc generation on Windows as a start? Presumably we could even cheat and build the docs on Linux and then bring the resulting built docs in when we build the Windows version - a bit hacky but it would help if getting the doc tools working on Windows is too painful.

I was all set to create a bug and then I realised I might need to put be a bit more specific than "Get plugin working on Windows 64-bit" - Scott, what do you want to actually sign up for? :)

Cheers,
Paul

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre