Overlord Contributor Quickstart Ideas

[eric.wittmann]

In order to get a developer up and going as quickly as possible we are thinking about putting together a contributor quickstart.  This thread is intended to figure out what items should be included in such a quickstart (and how).  Here are some initial thoughts I had.

My thought was that the quickstart would be one or more Ant scripts that would set up a dev environment for overlord.  The script could do some or all of the following:

• Fork all Overlord projects into the developer's github.com/USERNAME space.  (This can be done using github APIs)
• Clone all forked Overlord projects into a local directory.  (Done using git, obviously)
• Download and install Eclipse.  (Ant can download Eclipse easily enough - although as the Eclipse version changes the download links might break)
• Install any appropriate Eclipse plugins.  (Not sure how to do this - perhaps we could simply provide a version of Eclipse that's already configured with necessary plugins?)
• Generate one or more Eclipse workspace, complete with projects already imported and Overlord code formatter installed.  (This can either be maintained as source or perhaps Eclipse has an API we can use to generate workspaces and import projects?)
• Set up any relevant development runtime systems (jetty based?  tomcat based?)
  • Add appropriate launch targets to the Eclipse workspaces?
• Include documentation on how to modify code and submit a pull request (creating branches in github, committing code, generating pull requests, etc)

The goal should be to get a new developer up and running and contributing as quickly as possible.  I believe Kurt Stam already has a start on something like this...

[objectiser]

Eric, thanks for starting this thread.

I hadn't considered such an automated approach - I was thinking primarily about providing a simple set of instructions that could easily be followed to get up and running. That does not necessarily preclude the automated steps you mention, and may actually be a useful first step towards greater automation.

However a couple of points:

• I don't think any step should be 'overlord wide' - i.e. a user is probably specifically interested in one aspect of overlord (as each area is quite distinct), so they may not be too impressed having multiple cloned repos and Eclipse workspaces setup when they are only interested in one. So think it would be good if they could just select the area they are interested in, and have the automated scripts just do the steps for that area.
• Level of maintenance required for these scripts - as you mention, having to setup Eclipse and relevant plugins/config - as the version of Eclipse and these plugins change, it can cause issues that would need to be investigated. Not to say the manual instructions wouldn't have some of the same issues.
• Not all developers will use Eclipse, so manual instructions would be required to enable developer to setup their IDE of choice
• Developer may not want a fresh environment - they may want to develop in an existing Eclipse environment that includes other code/plugins etc.

I think automating where it makes sense would be good - but would prefer to start with just a manual description as the baseline, and then see where the most pain is before deciding how to improve it.

In terms of suggestion for where to provide these instructions, I would propose using the wiki associated with a governance.github.com repo, which would provide the main website for the Overlord project?

[jorgemoralespou_2]

Hi,

Sorry for disrupting, but as I was reading this thread, I wanted to throw you some help. First of all, I agree with Gary on his comments, and apart from that, I'll show you how to install an Integration Stack plugins in eclipse (tested with for JBDS)

 ./jbdevstudio -nosplash -application org.eclipse.equinox.p2.director -repository https://devstudio.jboss.com/updates/7.0/,https://devstudio.jboss.com/updates/7.0/integration-stack/ -installIU org.eclipse.bpmn2.feature.feature.group,org.eclipse.bpmn2.modeler.feature.feature.group,org.eclipse.bpmn2.modeler.jboss.runtime.feature.feature.group,org.fusesource.ide.camel.editor.feature.feature.group,org.fusesource.ide.runtimes.feature.feature.group,org.fusesource.ide.server.extensions.feature.feature.group,org.guvnor.tools.feature.feature.group,org.jboss.tools.bpel.feature.feature.group,org.jboss.tools.esb.feature.feature.group,org.jboss.tools.jbpm.common.feature.feature.group,org.jboss.tools.jbpm.convert.feature.feature.group,org.jboss.tools.jbpm3.feature.feature.group,org.jboss.tools.runtime.drools.detector.feature.feature.group,org.jboss.tools.runtime.esb.detector.feature.feature.group,org.jboss.tools.runtime.jbpm.detector.feature.feature.group,org.jbpm.eclipse.feature.feature.group,org.switchyard.tools.bpel.feature.feature.group,org.switchyard.tools.bpmn2.feature.feature.group,org.switchyard.tools.feature.feature.group

If you automate it, or provide instructions, this can be of help.

Cheers

[eric.wittmann]

That's fantastic, thanks Jorge!

Regarding Gary's points - I completely agree that we should start from documentation and automate iteratively.  I think much or perhaps all of the dev environment can be automated, but I don't know how much effort we really want to put into that.

Gary Brown - I also agree that we should be able to configure just a single project.  So if/when we automate, the script should ask which projects they are interested in.  That said, I'm not too concerned if the script clones all of the relevant projects without asking first.  That doesn't seem like a big deal to do without asking.

[kurtstam]

Hi Eric,

Yeah what you describe is pretty much captured in: Governance/overlord · GitHub. Minus the eclipse workspace setup, but I think most people have their own preference there anyway. My vote would be to add the other overlord projects to this as well. I think Overlord as a whole would benefit from this. You can simply delete projects you don't want if you want to focus on just one project, as it always easier to remove then to add.

Cheers,

--Kurt

[objectiser]

Here is an initial stab at some contributor guidelines: https://github.com/Governance/overlord/wiki/Contributor-Guidelines

Let me know your thoughts, or please edit as approriate.