Re: [jbosstools-dev] Teiid Designer and TP

btw. we kind of already have an "orbit" site for eclipes plugins: http://download.jboss.org/jbosstools/updates/requirements/ its not a single site per-se but contains subsites for the appropriate bits (putting them in one big one would be bad to use with Tycho since then *everything* in here would be considered the target platform). What is my biggest concern is though how often your dependencies actually needs updating ? On my first look I see these as "true" stable dependencies: And then this looks like something very often updated runtime component which is better managed within teiid project similar to how we got a org.jbosstools.forge.runtime bundle in Forge to allow bundling a specific runtime for ease-of-use. Two additional questions from me after thinking about this over the weekend is: 1) What is "com.springsource.org.objensis.jar" ? why is this osgi jar in the mockito plugin and not the original jar from http://code.google.com/p/objenesis/downloads/list ? 2) if these are not just the original jar rebuilt for osgi should we not be giving these unique names ? i.e. org.jbosstools.orbit.org.jaxen or similar ? (just like springsource does for their own repackaging?) /max On 05 Oct 2012, at 18:35, Max Rydahl Andersen <max.andersen(a)redhat.com&gt; wrote: >> Teiid Designer (TD) comprises part of jboss tools and provides an eclipse UI client interface for >> modelling and deploying virtual databases (vdbs) to a teiid server, which in turn is deployed in jboss. >> >> I have begun a discussion with mistria this afternoon on the possibility of a 3rd party P2 plugin >> repository that would serve as part of the Teiid Designer target platform. > > ok, cool - similar discussions are going on for how we handle this for soa-tooling in general/per part. > > Optimally we would like to avoid having a custom P2 repo for every release X every component, but we need to start somewhere :) > >> >> Background: >> >> TD (unreleased version 8) uses a target platform of: >> * http://download.jboss.org/jbosstools/updates/development/juno (JBT milestone build) >> * http://download.jboss.org/jbosstools/updates/juno/SR0/ (Eclipse Juno Target Platform) >> >> Thus, TD is a consumer of both the jbosstools TP and jbosstools features. > > okey - would be cool to know which features TD is using (just out of interest to understand what API's are actually used - remember JBT dont really have any API's outside AS tools currently) > >> However, contained in the current TD codebase are the following wrapped plugins, ie. wrapping >> 3rd-party built/released jars: >> > > How many of these are already in eclipse orbit ? > > The teiid_embedded_query sounds like something that are very version specific ? Does this > have to be matching the target server still ? > > Do I read it right above that teiid_embedded_query is simply wrapping those jars and only exposing limited API ? > i.e. commons-cli.jar, jboss-as-cli.jar does sound like things that easily could come problematic if exposed to rest of the eclipse plugin stack. > >> All of these jars are obtained from external websites, including the teiid jars (sf.net/projects/teiid). >> >> Problem: >> >> Everytime, an update of these jars is required, the new set of jars must be downloaded, included in >> the TD codebase and committed to the TD repository. > > Yes, you are basically updating the Target Platform. > >> Since we fetch the jbosstools and eclipse plugins from the target platform, it would be advantageous >> if these wrapped-plugins could be broken out into their own repository, ideally with no jars >> actually in the code repository then automatically built and served as features in a P2 repository. >> This P2 repository is then used by TD developers and TD build infrastructure. > > Yes - a Teiid targetplatform, optimally one that have these jars unified with the other "ontop" tooling set > so we know these can be installed together. > >> >> For example, with the teiid jars, a new release is uploaded to sf.net by the teiid team, downloaded >> by TD dev, fully wrapped as plugin/plugins and added to the P2 repository. > > hmm - do you really put a full unique teiid jar into the teiid plugin release s? > >> Discussion so far: >> >> * Mistria introduced me to the maven-dependency-plugin:get goal that could be executed during the >> generate-resources phase to download release jars build-time > > k > >> * Mistria also pointed out his new maven plugin that can take several platforms as input and produce >> a single target file > > hmm...which is that ? :) > >> * We agreed that this sounds very much like a jboss version of Eclipse Orbit and considered the use >> of this repository across all jboss projects rather than just TD (an external deps + JBoss.org stuff >> packaged as OSGi bundle in a p2 repo) > > Yes, similar idea have come up before. > > I see JBoss Tools Orbit as something else than a Target Platform - Orbit would be actual input to the actual target platform and what is later pointed to for updatesites. > >> * Unlike Eclipse Orbit, we would wrap existing release jars rather than rebuild project from source > > well, depends on the jars I guess - if Eclipse Orbit already have something rebuilt we could consider using that - > but that all depends about matching jars/apis. > >> * So a suggestion was made that given a project X normally has additional X.tools and/or X.designer >> projects, the latter should be responsible for shipping X as OSGI bundles > > What worries me is the "shipping as osgi bundles" since that is *not* trivial if we start exposing stuff that > becomes runtime version dependent - just something to be extremely careful about. > > its the reason why we refrained from re-bundling dmr.jar/as7 client library as osgi libraries since we needed to be sure > our Server tools could use multiple version of this at the same time from the tools. > > Just something to consider. > >> * Need approval since this represents an independent project. However, I would like to limit it at >> first to being a TD focused project until either other's find a use for it and/or it proves itself >> useful > > well, we already have plenty of jars that are candidates for this (i.e. mockito.jar) - my main concern is the mix of runtime aspects into tools as osgi > bundles since it can limit our ability to be multi-runtime compatible. > > *that said* i'm all for the creation of a JBoss Tools Orbit project in which we can add content after review that can be shared > and properly versioned. > >> * Consider a small independent P2 update site that is built manually and locally at first then move >> to automation when that is working > > yes, sounds cool - create it as a standalone github project and we can go to set that up. > >> Questions for getting started: >> >> * The hosting location for this P2 update site. Do I / Is it possible to have access to >> download.jboss.org to upload such a site? > > yes - I don't see a problem for that - we just need to figure out the rules/conventions for how this JBoss Tools Orbit should work. > > i.e. it would be anything but eclipse plugins. The jars can't modify overall system state (i.e. versions of jboss-modules or was it logging changed system behavior that might be good for one plugin but terrible for others). > > But yes, Definitely a big +1 for creation of a JBoss Tools Orbit kind of repo. > > /max >