[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [stp-dev] WTP/DTP division of labor for STP


To help move this list along, I've started a small wiki page with some references to the discussions on the stp-dev mailing list:

http://wiki.eclipse.org/index.php/STP_Deployment_Framework_Requirements

I have also added a link to this page from the STP wiki (http://wiki.eclipse.org/index.php/STP).

As the STP team is more distributed than other Eclipse project teams that I'm aware of, I think vetting our designs and progress through the wiki will give us the best opportunity to make continual progress while keeping others in the loop more so than a once-a-week IRC meeting can do. I think that this process should be supplemental to our weekly meeting.




-------------------------------------------------------------------------
Kind Regards,

Michael D. Elder
Rational Studio / Services Tools Development    
IBM RTP Lab
Ext: (919) 543-8356
T/L:  441-8356
mdelder@xxxxxxxxxx




Oisin Hurley <ohurley@xxxxxxxx>
Sent by: stp-dev-bounces@xxxxxxxxxxx

04/28/2006 11:17 AM

Please respond to
STP Dev list <stp-dev@xxxxxxxxxxx>

To
STP Dev list <stp-dev@xxxxxxxxxxx>
cc
Subject
[stp-dev] WTP/DTP division of labor for STP





To get a bit of progress on this issue I think it might be a good idea
to focus on a set of concrete requirements rather than just doing a
feature comparison between the [W|D]TP connectivity frameworks.

I've got the luxury of having an equally low level of knowledge of
both such that I don't think I can prejudice the issue :)

However, it's clear to me that there are very urgent requirements
for STP when it comes to talking to deployment targets (runtimes I'll  
call
them).

1. Whatever the connectivity framework, it should be able to contact
a remote, running runtime instance. This means that you can do your
deploy from your development host to a test/preprod host somewhere
else.

2. Whatever the connectivity framework, it should support the  
development
of new connector instances to new runtimes. Now, just a clarification
here: when I use the term 'support' then I do not mean 'allow' :) With
'allow' you can get it done by writing reams of code, with 'support'
the framework makes it easy for you to focus on just the code you need
to talk to your chosen runtime (note that this could be reams too, but
you are at least writing in your area of expertise).

Ok, there are lots of other important requirements - being able to
deploy to a number of runtime instances in a transaction, some access
control, introspection of runtime contents (for containers style
runtimes) and the like, but right now I think these are just icing.

I think that if a connectivity framework can provide these two things,
we would be in a good position to go forward with it.

I'd like to hear some positions on the urgency of the requirements
that I've mentioned above. Also, I'd like to hear from the domain
experts whether or not the WTP/DTP connectivity framework can/cannot
support them and if not is it on the roadmap.

This I feel should give us something a bit more concrete to discuss.

 cheers
  --oh
_______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev