Sorry for the late response, holiday vaction... I think we don't need to be too formal with our decision process right now. As long as nobody expresses any serious disagreements then we can assume a decision is made. Otherwise, voting one a contentious idea seems best.
-Chris "David J. Orme" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 12/28/2006 02:16 PM Please respond to Nebula Dev <[email protected]> To [email protected] cc Subject [nebula-dev] Re: nebula-dev Digest, Vol 9, Issue 22 > I think we are all in agreement regarding the new way to package things. I > don't think we need a vote of any kind. Re governance, as far as I know > there isn't an Eclipse mandated process within projects other than > "meritocracy". Okay. Perhaps having committers vote on questions (3 +1s and no -1s is typical for projects I've worked on) can help to establish what we all feel has merit. While we're small, maybe 3 +1s is overkill. Perhaps we should assume that as long as no committer votes against something (-1), that the idea has merit. (Voting -1 would require some justification/concern/counter-proposal in order to be valid). > I also like what Ian mentioned. Each widgets/component could > independently decide to participate in a given Nebula release. This will > give us alot more flexibility. Sure. > So now we need to go about creating new projects for each widget and > moving the existing code within. As far as packaging, I am planning on > working on an automated build for Nebula. So I'll try to combine the two > together. Perhaps we can have a common build script which does the common > stuff, and can be customized for each component. I really like this idea. Best regards, Dave Orme "David J. Orme" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 12/22/2006 01:31 PM Please respond to Nebula Dev <[email protected]> To [email protected] cc Subject [nebula-dev] Re: nebula-dev Digest, Vol 9, Issue 20 OK, here's what I understand to be on the table and where I am on each: 1 project per control: +1 Control jars inside our current zip file format should be in Eclipse plugin format: +1 Keep the existing zip format, including other helpful things like snippets.zip, etc: +1 If we want to have a single distribution for all Nebula controls, I'm OK with that, but that would be an additional decision on the table. Chris, what's the governance model here? Do we need 3 +1s from committers on a decision? I don't see a general governance document like we have in Platform and Tools, either at the top-level project level or in our subproject's web site; am I missing something? Regards, Dave Orme ------------------------------ Date: Thu, 21 Dec 2006 11:27:11 -0800 From: Ian Bull <[EMAIL PROTECTED]> Subject: Re: [nebula-dev] Re: one plugin per control To: Nebula Dev <[email protected]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=UTF-8; format=flowed Are we talking about packaging widgets, or the structure of CVS? Should these be the same? I guess I am not officially a committer yet, but I really like 1 zip per control. I think we could then take a poll of who wants to be in a release (we have sort of already done this), and these could all be packaged up as a Nebula release (we can export a bunch of plugins as a Zip). Then if someone wants to try out all the widgets they can do this. I'm not sure if we have decided on how to go with JFace style widgets, that is if a widget is available in two different forms. Is this two different plugins (one that depends on another) or just 1 and you can access it in either way? If we go with the second approach then we have: org.eclipse.nebula.grid org.eclipse.nebula.ctabletree org.eclipse.nebula.compositetable org.eclipse.nebula.pgroup org.eclipse.nebula.pshelf org.eclipse.nebula.graph (zest graph) However this doesn't help if and when we move to SWT, since the JFace and SWT parts must be separated then. Although I guess if we forced package conventions within the plugins (SWT and JFace must be in separate packages and the SWT package must not have eclipse.ui dependencies this would work). Cheers, Ian David J. Orme wrote: > OK, I think that's two +1s; one from Chris and one from me. Do we > have a third committer on board? What do the rest of you think? > > > Regards, > > Dave Orme > > ----- > Message: 1 > Date: Thu, 21 Dec 2006 11:09:45 -0500 > From: Christopher J Gross <[EMAIL PROTECTED]> > Subject: Re: [nebula-dev] Re: nebula-dev Digest, Vol 9, Issue 17 > To: Nebula Dev <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii" > > I don't have a problem with this. I don't think we should worry about > including a src.zip but I'm board with snippets and javadoc. Most people > don't care about the source. Re javadoc, ideally I'd like to include a > help plugin that added the javadoc to the main Eclipse help. > > > "David J. Orme" <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > 12/21/2006 11:51 AM > Please respond to > Nebula Dev <[email protected]> > > > To > [email protected] > cc > > Subject > [nebula-dev] Re: nebula-dev Digest, Vol 9, Issue 17 > > > I've been thinking about this and I'm still supportive, but don't want to > lose some of the benefits of how we do things now. > > One advantage we have right now is that we provide closer to one-stop > shopping for people who download our controls. > > What I mean is that inside the download zip, we all provide a JAR for the > widget itself and a separate JavaDoc directory, all at once. In > CompositeTable, I've extended this idea and made my build script also > include a src.zip and a snippets.zip so that when someone downloads > CompositeTable, they really have *everything* they need to get started > with it. We can get away with this because our controls are really small > downloads to begin with, so throwing all the documentation, source code, > and snippets into the distribution makes sense. > > If we were to move to one plugin per control, I would still want the > download file to be a ZIP containing the plugin jar, plus all the > stuff it > currently has (snippets.zip, src.zip, JavaDoc, etc). There is no reason > to make our users download five tiny things in order to use a control. > One > download should be sufficient. > > > Regards, > > Dave Orme > > > ------------------------------------------------------------------------ > > _______________________________________________ > nebula-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/nebula-dev > ------------------------------ Message: 3 Date: Fri, 22 Dec 2006 10:02:59 -0500 From: Christopher J Gross <[EMAIL PROTECTED]> Subject: Re: [nebula-dev] Re: nebula-dev Digest, Vol 9, Issue 17 To: Nebula Dev <[email protected]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: roland.vcf Type: application/octet-stream Size: 224 bytes Desc: not available Url : https://dev.eclipse.org/mailman/listinfo/nebula-dev/attachments/20061222/e9d4395f/roland.obj ------------------------------ Message: 4 Date: Fri, 22 Dec 2006 10:10:39 -0500 From: Christopher J Gross <[EMAIL PROTECTED]> Subject: Re: [nebula-dev] Re: one plugin per control To: Nebula Dev <[email protected]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" Comments inline... [EMAIL PROTECTED] wrote on 12/21/2006 02:27:11 PM: > Are we talking about packaging widgets, or the structure of CVS? Should > these be the same? > I think we are kinda talking about both the structure of the projects and the packaging. I think its all related. > > I guess I am not officially a committer yet, but I really like 1 zip per > control. I think we could then take a poll of who wants to be in a > release (we have sort of already done this), and these could all be > packaged up as a Nebula release (we can export a bunch of plugins as a > Zip). Then if someone wants to try out all the widgets they can do this. One zip that includes all the plugins is a good idea. I like that idea better than one plugin with all the code. > I'm not sure if we have decided on how to go with JFace style widgets, > that is if a widget is available in two different forms. Is this two > different plugins (one that depends on another) or just 1 and you can > access it in either way? If we go with the second approach then we have: > > org.eclipse.nebula.grid > org.eclipse.nebula.ctabletree > org.eclipse.nebula.compositetable > org.eclipse.nebula.pgroup > org.eclipse.nebula.pshelf > org.eclipse.nebula.graph (zest graph) > > However this doesn't help if and when we move to SWT, since the JFace > and SWT parts must be separated then. Although I guess if we forced > package conventions within the plugins (SWT and JFace must be in > separate packages and the SWT package must not have eclipse.ui > dependencies this would work). > > Cheers, > Ian Two different plugins that depend on each other. So for example, for Grid we would have org.eclipse.swt.nebula.grid (only depends on SWT) org.eclipse.swt.nebula.nebface.grid (depends on SWT, the grid plugin and JFace) The idea is to make the widgets available the same way normal SWT widgets are available. As either the base widget with a simpler API, or wrapped by a viewer. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: https://dev.eclipse.org/mailman/listinfo/nebula-dev/attachments/20061222/3173fb56/attachment.html ------------------------------ _______________________________________________ nebula-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/nebula-dev End of nebula-dev Digest, Vol 9, Issue 20 ***************************************** _______________________________________________ nebula-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/nebula-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: https://dev.eclipse.org/mailman/listinfo/nebula-dev/attachments/20061228/e31e8d53/attachment.html ------------------------------ _______________________________________________ nebula-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/nebula-dev End of nebula-dev Digest, Vol 9, Issue 22 ***************************************** _______________________________________________ nebula-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/nebula-dev
_______________________________________________ nebula-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/nebula-dev
