Thanks, Ed. This is what I *think* is the state of play is now. AFAICT There is no mechanism in P2 for interrupting the process and saying "do you want to add update site x?". So this means adding lots of notes to documentation that no-one will read :), or to hope that people read the feature description which would say something like "requires foo, available at http://foo.org/updates";. The other approach is to queue the user to do it separately. The way that Subversion does it is to wait until you actually try to use Subversion, and then have it launch the discovery mechanism. This is probably about the only way around the issue, but even with all of the improvements, it is pretty much an anti-pattern. Xtext has an exceedingly clever way of handling getting the ANTLR parser when it hasn't been installed (i.e. through the Modeling project discovery or P2). Since the dependency is only at design time, there is a prompt to console, and when the user enters yes on console, it grabs the lib.
The real solution to all of this is the discovery mechanism which provides the aggregation. So with Cedric's fine work on the Modelling project discovery mechanism there is a very easy path to installation. We just need a notice saying that it includes non-Eclipse IP with a pointer to this disclaimer: http://www.eclipse.org/amp/installing/about_discovery.php. So that handles the regular user path. We can't do that with the update site, and I think it is important to provide everything from Indigo so that even if user's can't install everything from Eclipse Indigo alone, they can grab all of the Eclipse org content from the Indigo site. This avoids the problem of having to host Eclipse project stuff offsite. In setting up my first Indigo for M4, I discovered that you'll break the aggregation build if you try to put in a feature that uses another update site. So it's not an option anyway. :( I think what I'm going to have to do is include everything *but* the LWJGL support in my feature and then (the anti-pattern) trigger the discovery mechanism for when LWJGL is not installed. I sure hope we eventually get a better solution for Eclipse 3D lib support.. cheers, Miles On Dec 19, 2010, at 10:09 AM, Ed Merks wrote: > Miles, > > Sorry for the slow reply. I'd suggest finding out what Xtext is doing. > Also, it seems to me that SVN support faces similar problems and I think when > you install SVN support (Subversion) it points you at offsite connectors. So > it will be interesting to see how that fits within the legal frameworks; I'm > really not sure. Generally such dependencies still need to be IP approved and > must be of the "works-with" variety. I.e., your software works well > without it but has some more bells and whistles when it's available. I'm not > sure how that applies for SVN though because it seems to me useless without > the connectors... > > I don't have any objections in principle, but definitely it's good to see how > others (e.g, Xtext) are tackling this and to coordinate your efforts with > Cedric... > > Cheers, > Ed > > > Miles Parker wrote: >> Hi all, >> >> I'm just wanting to coordinate adding AMP to the custom category for >> Modeling for M4. I anticipate having only an SDK feature, no runtime and no >> examples since the examples are projects imported through cheat sheets. >> >> If possible I'd like to figure out how to include extensions (mainly 3D >> support which is a key feature for AMP and GEF3D depends on) without >> cluttering up the Modeling category. I'd like to have just one extension >> with reference to the common things people will need, but those would >> require third party (non-Eclipse IP approved) update site reference to >> install. This is what we're already doing for the Discovery site. I know >> that XText has a similar issue with the ANTLR parser, but I'm not sure >> whether there is a reference to this dependency or not from XText and I >> can't mark mine as optional. So a) technically is it possible to have a >> dependency on non-Eclipse P2 site form B3 aggregator (I don't want to break >> M4 build!!) and b) legally can/should we have dependencies on non-IP >> approved third party sites in Indigo site (it already exists on AMP site), >> and most importantly c) how does PMC feel about having that in Modeling >> category? (The concern I could see is if someone jus t > c >> licks on the whole modeling category, that's going to prevent a simple >> click-through install.) >> >> cheers, >> >> Miles >> _______________________________________________ >> modeling-pmc mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/modeling-pmc >> > > _______________________________________________ > modeling-pmc mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/modeling-pmc _______________________________________________ xtext-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/xtext-dev
