Re: [platform-update-dev] questions about the Install/Update spec

[Patrick_Mueller@xxxxxxx]

Sorry, I'm replying from Lotus Notes, so I don't know how this will appear.  Hopefully readable :-)

I hear what you're saying.  And it's probably the right answer.  Usually, it's better to take baby steps anyway; nested features or feature pre-reqs can be added in later if really required.  For now, we can certainly live without them.

Since you anticipated my question "I knew this would come", best to add this to your doc to alleviate having to answer again in the future ...

wrt: latest release.  I'm just coming off of WSDD development (eclipse r1), haven't installed an eclipse in months, have no idea what M4 is, or why you'd be asking me to host it.  Wow, am I ever in the dark! :-)  I need to get a stable eclipse up, and I do have a site we've been hosting some of our eclipse r1 downloadable plugins in, which is what I assume you're asking about.  If you want to just post status in the ML as it starts coming along, that'd be great.

Patrick Mueller
patrick_mueller@xxxxxxx

celek@xxxxxxxxxx Sent by: platform-update-dev-admin@xxxxxxxxxxx 03/25/2002 12:22 PM Please respond to platform-update-dev

To:        platform-update-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [platform-update-dev] questions about the Install/Update spec

Hello Patrick
[snip]
It appears features can pre-req plugins, but not other features.  It seems like it would be nice to allow features to pre-req other features.  In fact, I think for my purposes, having plugins reference features would be the nicest thing to do.  For instance, I might have a feature that installs some non-plugin data, which is actually a runtime library, meant to be consumed by a programmer using Eclipse.  As an example, most of the 'runtimes' and 'technologies' stuff out of WSDD.  I might also have an Eclipse plugin that can be used against the runtime libraries.  Note that I'm not going to push the issue of cross-linking jars within plugins, more the user experience of "I've installed some runtimes, now I want the tools".  Installing the tools without the runtimes basically doesn't make sense, but installing the runtimes without the tools does.  So, what I really want is for the plugin, whi! ch will likely be a feature in it'!
 s own right, to pre-req the feature that contains the runtime. 

Also, I'm curious about not being able to nest features.  It sort of seems like a natural thing to do.  If you look at WSDD, it would be wonderful if you could press a button and download ALL the features, instead of having to pick all of them individually.  ie, pick the 'All WSDD Features', which just pointed to all the individual features. 

<CE>
Sigh ;-)
I knew this would come... ok let me explain our vision

let's focus on the job. WHen you create a 'product' (either runtime or tool) you know the exact list of plugins this products require (in our example there will be runtime1, runtime2, tool1 and tool2).
When you build the runtime product, you will need runtime1 and runtime2 plugin
When you need tool product you will need tool1 and tool2 but you will require plugin1 and 2 to be installed.

If you go the way -require feature- you will have to 'require' the 'runtime' product in the 'tool' product with some kind of policy (if not found install or if not found fail)

if you do not go this way, ie you have the tool product require all the 4 plugins, you can still achieve the same
1) if you package the runtime plugins they will be installed if they do not exist
2) if you do not package the runtime plugins and they are not already installed, the install will fail

of course it means you produce the 4 plugins, if you do not produce the 4 plugins, you still have the require tag in feature.xml that allows you to loosely reference another feature (like a 3rd party or a feature you didn;t produce)

The philosphy of having a complete list os the following. At one point your tester will say. yep, this configuration is the correct one. And what you will want to do is to take a snapshot of the config and tag it 'supported' (ie you will want to get the complete list of all the plugins neede for the tool) Some of them you may have on your server, some you may not.  The spec also allows you to separate the plugins/non-plugins from the feature.xml description, so you can have more than one feature.xml pointing to a plugin.

Hopefully , future tools will help you create the snapshot.

Re the pick-all feature, cut and paste all plugins in a new feature.xml. 
I know your answer will be, "well, I want to have this feature point to other features so I will not have to change it... I will just change the pointed features ...et voila :-)"
My answer is , yep, but because you are a professional, you will try to test this 'All features' feature. And thus come back to case #1 where, when you are satisfied with the feature, and your organization will support it, you will tag it, thus create the list of the exact plugins.

As stated before, if you still want some kind of 'pointers' check the require tag of feature.xml...

One of your concern will be, ok but what if there is just a new version of a plugin... If your support team wants to support it, they will need to test it, thus back to #1.

The goal is to have the development team package plugins, the test/build/release team to create the feature.jar and the Site admisnistrator to place the different files in the correct places.

Let us know
</CE>


Lastly, what is the current state of this work in Eclipse, and do you have any milestones for it, if it's not functional right now? 

<CE>
Sigh 2 ;-)
I broke it... M4 will not work.
The nightly build may be what you want unless you can wait for integration build.

I am attempting to  eat my own dog foood and *may* release a fix for M4 on an http site ... can you host it ?
</CE>



Patrick Mueller
patrick_mueller@xxxxxxx


<CE>

Christophe Elek

celek@xxxxxxxxxx

</CE>