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

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
>


Back to the top