Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re[2]: [equinox-dev] ProSyst contribution

Ok, then we will start with the incubator. The ProSyst dependencies
mean that in the initial version of the code we will be using some
util classes which will be also put into the incubator (clear under
EPL). Later we could optimize the code to fit better with the existing
Equinox implementation and to avoid any redundancy.

The proposed committers will maintain the code also in the future.

Dimitar

-----Original Message-----
>From: Jeff_McAffer@xxxxxxxxxx  
>Received: Dienstag, 13. März 2007, 09:38  
>To: equinox-dev@xxxxxxxxxxx
>CC:  
>Subject: Re: [equinox-dev] ProSyst contribution 

JM> +1

JM> The incubator is the right initial home for this.  I'm not particularly
JM> fussed if the Prosyst dependencies are removed before or after.  The code
JM> can evolve once it is in the repo or it can be put in in working form.

JM> Jeff





JM> BJ Hargrave <hargrave@xxxxxxxxxx> 
JM> Sent by: equinox-dev-bounces@xxxxxxxxxxx
JM> 03/12/2007 12:11 PM
JM> Please respond to
JM> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>


JM> To
JM> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
JM> cc

JM> Subject
JM> Re: [equinox-dev] ProSyst contribution






JM> This is really great.

JM> I propose we take the code into the incubator area (once proper paperwork
JM> is in place) to enable code reviews, etc. before we consider promoting to
JM> the main equinox project.

JM> Also, I think the dependencies on non-open source code (e.g. ProSyst util
JM> classes) must, of course, be remove before we put the code in the 
JM> incubator. Otherwise we will have no way to build and run it.

JM> We already have a Config Admin impl (which Simon pointed out I still need
JM> to code review... :-) and a DS impl. But the current DS impl is a bit 
JM> wonky and I am very much intrested to see if the ProSyst version is 
JM> suitable to replace it.

JM> BJ Hargrave
JM> Senior Technical Staff Member, IBM
JM> OSGi Fellow and CTO of the OSGi Alliance
JM> hargrave@xxxxxxxxxx

JM> office: +1 386 848 1781
JM> mobile: +1 386 848 3788




JM> Dimitar Valtchev <d.valtchev@xxxxxxxxxxx> 
JM> Sent by: equinox-dev-bounces@xxxxxxxxxxx
JM> 03/12/2007 11:01 AM
JM> Please respond to
JM> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>


JM> To
JM> Jeff_McAffer@xxxxxxxxxx
JM> cc
JM> equinox-dev@xxxxxxxxxxx
JM> Subject
JM> [equinox-dev] ProSyst contribution






JM> Hi Jeff,

JM> Following our conversation at EclipseCon we finalized the ideas for a
JM> possible initial ProSyst contribution to Equinox. We could donate the
JM> following OSGi services, which do not have a full Equinox
JM> implementation yet:

JM> 1. Initial Provisioning
JM> 2. IO Connector Service Specification
JM> 3. Wire Admin Service Specification
JM> 4. Configuration Admin Service Specification
JM> 5. Declarative Services Specification

JM> We can provide working implementations with packages in the Equinox
JM> namespace comparatively fast but removing the dependencies on some
JM> ProSyst util classes will take more time.

JM> The developers who will be responsible for this work are Pavlin Dobrev
JM> and Teodor Todorov. Both of them are involved with ProSyst OSGi
JM> implementation and participate in the OSGi EG. I think it makes sense
JM> to add them as Equinox committers.

JM> Please let me know if you support the suggested approach.

JM> Best regards,
JM> Dimitar

JM> _______________________________________________
JM> equinox-dev mailing list
JM> equinox-dev@xxxxxxxxxxx
JM> https://dev.eclipse.org/mailman/listinfo/equinox-dev


JM> _______________________________________________
JM> equinox-dev mailing list
JM> equinox-dev@xxxxxxxxxxx
JM> https://dev.eclipse.org/mailman/listinfo/equinox-dev

 



Back to the top