Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rt-pmc] jetty packaging at eclipse-rt: status and questions

ya, go ahead and organize a time...I ought to be able to make pretty
much anything

I am on CST and Hugues is on PST

cheers,
jesse

--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx



On Thu, Apr 8, 2010 at 16:00, Ian Skerrett <ian.skerrett@xxxxxxxxxxx> wrote:
> I would be happy to join a call.
>
> On 4/8/2010 4:31 PM, Hugues Malphettes wrote:
>
> Jesse and I are definitly interested.
> Cheers,
> Hugues.
> PS I did notice indeed that you never implied that a packaged
> Equinox-Jetty distribution was a poor idea.
>
> On Thu, Apr 8, 2010 at 11:35 AM, Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx>
> wrote:
>
>
> Hmmm, I am thinking that there are too many different topics and levels of
> discussion going on in the same thread.  Perhaps we should setup a conf call
> where interested parties can talk about these and get some clarification.
>  Anyone interested?
>
> Jeff
>
>
> On 2010-04-08, at 12:58 PM, Ian Skerrett wrote:
>
>
>
> On 4/8/2010 11:08 AM, Jeff McAffer wrote:
>
>
> One thing I know is that if you try to answer all these questions no package
> will ever get built.   Right now there is no/zero/nadda entry point into
> EclipseRT.  There is a huge gap between the theory of OSGi/EclipseRT and the
> common developer that wants to get started.   Most developersuse servlets
> today and do persistence of data.   This is why I think the
> Jetty/EclipseLink scenerio is so compelling.   I would start with that.
>
>
>
> I agree that doing something simple is good. The thing I really want to
> avoid is putting out one simple sample and then spending years countering
> the initial image that EclipseRT is Equinox+Jetty+EclipseLink. We have seen
> this time and again.  People's first impression is very powerful. That cuts
> both ways. If it is too abstract, they don't get it. If it is too concrete
> then it gets pigeon holed.
>
>
>
> I guess I have more confidence in people's ability to grow and learn once
> they get started.   Right now we make it very difficult for them to
> understand why and how they can get started.   This needs to be fixed.
>
>
>
> So, I am not against any of this but I do want us to at least put some
> thought into the message we are sending and the impact of that message. This
> could result in something as simple as what we name the package to how many
> packages or what's in them. For example, consider the different messaging in
> naming Equinox+Jetty+Eclipse link the following ways:
>      EclipseRT Platform
>      EclipseRT Server Starter Kit
>      Jetty Distro
>
>
>
> I would do some version of EclipseRT Jetty Server Starter Kit.    I would
> NOT call this the EclipseRT Platform or the EclipseRT Package.
>
>
>
>
> These all set completely different contexts and expectations and
> implications.
>
> Related, if there is only one then the implication is, this is it, this is
> *the* EclipseRT deliverable. Two admits the possibility of options.  Three
> allows induction.
>
>
>
> I think you are over analyzing this.  Start with one.  If someone wants to
> do another great do another but unless you start with one you will never get
> to two or three.
>
>
>
>
> BTW, if we are looking for a demonstration app then perhaps Toast
> (http://wiki.eclipse.org/Toast) is a good candidate.  It is already at
> Eclipse and we have demonstrated quite a number of EclipseRT technologies
> (Jetty, RAP, EMF, BIRT, Riena, ECF, p2, Teneo, EclipseLink, ...) integrated
> on both the server and the client. It has snazzy UIs and a whole book of
> documentation :-)
>
>
>
> Sorry but Toast is way too complicated.  It is a nice demo and a wonderful
> book but it is just too much go people to get started.
>
>
>
> The Toast backend is a couple of servlets and some persistence. It is
> independent of the client. Toast has been specifically designed in the CODA
> model where you can take as much or as little as you want/need. You are
> right that Toast in its entirety is too much for an intro example. So the
> approach should be to deliver just the base backend stuff as the initial
> example and then show how it can be extended with all the other EclipseRT
> tech in more advanced examples.
>
>
>
> So maybe one small portion of Toast is included, if it makes sense.
>
>
>
> For example, Dennis at the RT BOF was looking to have a simple Equinox
> platform that had the framework and p2. Users develop bundles and features,
> export them to p2 repos, then start the base platform and install/run their
> stuff.  This might include installing Jetty, EclipseLink, ...
>
> A traditional PDE development flow would have developers write bundles and a
> .product file and then either launch that from the workspace or export and
> run it. They may add further bundles using p2 if the product is p2 enabled.
>
> A traditional server developer ...  (actually I don't know with authority
> what they do)
>
>
>
> Focus on developers writing servlets and need data persistence.   A simple
> CRUD application.
>
>
>
> I'm talking about how they develop not what the develop. What is the
> workflow the audience of this package expects? What workflow do we want them
> to use? That directly impacts the form and content.
>
>
>
> IMHO, you need to start with what they develop.   Developers are looking for
> a solution to their problem.   Give them a solution and then start guiding
> them on how to solve it.
>
>
>
>
>
> The point here is not that any of these is right or wrong.  We simply need
> clarity in what we are trying to support as that drives the form and helps
> set expectations for the consumers.
>
> FWIW, I strongly believe in the CODA approach. We should be stackless from
> the ground up. The trick is to make composition of the software *you* need
> trivially easy.  Think of Yoxos OnDemand
> (http://ondemand.yoxos.com/geteclipse/start) for runtime platforms. Yup, I
> would like some Equinox, some Jetty, a bit o EclipseLink, ...  In the end
> all you are doing is picking features (actually IUs) to compose. This could
> be in a launch config, .product file, export wizard, command shell, ... The
> trick is that these stacks are individual and just right for you.
>
>
>
> CODA is an architecture approach that may come once people understand how to
> build applications using bundles.You can't start with CODA for a common
> developer.   It is just too abstract.
>
>
>
> Agreed 100%. But that does not mean we abandon CODA as the underlying
> principle of our approach so that as devs get more comfortable/familiar the
> shift is not a paradigm change but a transition along a spectrum. CODA
> should inform our direction.
>
>
>
> You are right we shouldn't abandon CODA but we also shouldn't let it make it
> difficult for people to get started.   Telling people there is this endless
> combination of flexibility and you have the power to build whatever you want
> is not an easy starting point for a developer who just wants to learn.
>
>
> _______________________________________________
> rt-pmc mailing list
> rt-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>
>
> _______________________________________________
> rt-pmc mailing list
> rt-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>
>
>
> _______________________________________________
> rt-pmc mailing list
> rt-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>
>
> --
> Ian Skerrett
> Director of Marketing
> Eclipse Foundation
> Tel: 613-224-9461 ext 227
> Blog: ianskerrett.wordpress.com
> Twitter: IanSkerrett
> Plan to attend EclipseCon 2010, March 22-25
> _______________________________________________
> rt-pmc mailing list
> rt-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>
>


Back to the top