Wonderful, can we update the node-launcher-equinox tests to use these by default then? Do we have any examples of those types of config so I can do this, or doc on what to do?
...ant On Sat, May 23, 2009 at 6:09 PM, Raymond Feng <[email protected]> wrote: > There are already two options to control the discovery: > > 1) -configuration (or osgi.configuration.area system property): Pointing to > an equinox configuration folder that contains a config.ini which lists all > the bundles > 2) -bundles: Pointing to a list of files (we can enhance it to support URLs) > for OSGi bundles > > Thanks, > Raymond > -------------------------------------------------- > From: "ant elder" <[email protected]> > Sent: Saturday, May 23, 2009 12:50 AM > To: <[email protected]> > Subject: Re: ** WARNING ** node-impl2 can cause hard to diagnose errors with > OSGi > >> On Mon, May 11, 2009 at 10:28 AM, ant elder <[email protected]> wrote: >> >>> (2) We need to find a better long term solution for >>> node-launcher-equinox as having it work by just finding modules in the >>> parent directory is only going to continue to make the build unstable. >>> Maven is the canonical build for Tuscany so module code needs to play >>> properly with that. It also doesn't seem great for the modularity >>> story to say that while Tuscany is designed to be really modular and >>> composable but actually we must have only a single impl of each >>> function as part of the build - and this isn't some theoretical >>> academic discussion as we do have multiple implementations of things >>> in 1.x which will be brought into 2.x so we need to avoid random >>> indeterminate combinations of the modules being used in different >>> peoples builds. >>> >>> I guess we need some configuration mechanism for node-launcher-equinox >>> to tell it which modules to use, does anyone else have any >>> suggestions? >>> >> >> I've just wasted some time tracking down yet another one of these >> build problems caused by node-launcher-equinox finding things not in >> the build so I'm still keen to find a better approach. I wonder if >> the more declarative approach to system service discovery thats being >> discussed in that other ML thread could help this. >> >> ..ant > >
