[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[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 <irbull@xxxxxxxxx>
Subject: Re: [nebula-dev] Re: one plugin per control
To: Nebula Dev <nebula-dev@xxxxxxxxxxx>
Message-ID: <458AE00F.7000402@xxxxxxxxxx>
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 <chris.gross@xxxxxxxxxx>
> Subject: Re: [nebula-dev] Re: nebula-dev Digest, Vol 9, Issue 17
> To: Nebula Dev <nebula-dev@xxxxxxxxxxx>
> Message-ID:
> <OF1541DFC7.B4A15C7E-ON8525724B.00584C2E-8525724B.0058C909@xxxxxxxxxx>
> 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" <djo@xxxxxxxxxxxxxxxxxxxxxxxxx>
> Sent by: nebula-dev-bounces@xxxxxxxxxxx
> 12/21/2006 11:51 AM
> Please respond to
> Nebula Dev <nebula-dev@xxxxxxxxxxx>
>
>
> To
> nebula-dev@xxxxxxxxxxx
> 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
> nebula-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/nebula-dev
>
------------------------------
Message: 3
Date: Fri, 22 Dec 2006 10:02:59 -0500
From: Christopher J Gross <chris.gross@xxxxxxxxxx>
Subject: Re: [nebula-dev] Re: nebula-dev Digest, Vol 9, Issue 17
To: Nebula Dev <nebula-dev@xxxxxxxxxxx>
Message-ID:
<OF8928B43B.DB3F9B27-ON8525724C.00529AD1-8525724C.0052AB9F@xxxxxxxxxx>
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 <chris.gross@xxxxxxxxxx>
Subject: Re: [nebula-dev] Re: one plugin per control
To: Nebula Dev <nebula-dev@xxxxxxxxxxx>
Message-ID:
<OFBD09868A.4440E63F-ON8525724C.0052C083-8525724C.00535F31@xxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"
Comments inline...
nebula-dev-bounces@xxxxxxxxxxx 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
nebula-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/nebula-dev
End of nebula-dev Digest, Vol 9, Issue 20
*****************************************
