I get it. Until we have such single unified tools environment, these
kinds of things will pop up. Even if you have environment, there is no
guarantee that someone else will not do this. Granted, you may not be
including that in your tools release, I believe CDK development is also
at the same stage.
Right now, I see this as just any other eclipse plugin works in in any
of the eclipse environments. That *is* all Teiid requirement. I have no
problems if this delivered as stand-alone plugin to begin with. There is
JIRA and WIKI page
for design /road map and plenty of email discussions.
We have not talked about any JBT integration and I always saw this as an
following task after the tech-preview. Designer is just being integrated
into JBT (yet to be released), so it not new for Teiid tools to be
delivered in this form. I am not saying I advocating against it, with
resources we have this is best we have planned. I have no issues you
shepherding this plugin's integration into JBT. Actually, I welcome it.
On Tue, 2010-03-23 at 16:57 -0500, John Verhaeg wrote:
On Mar 23, 2010, at 4:05 PM, Ramesh Reddy wrote:
> "teiid-dev" mailing list is always used for any communication on this
> project. If you are just ignoring the emails that is not poor
That's not blaming you guys for lack of communication, I'm talking about general
internal communication issues we had early on, none of which I'm going to discuss
further in this forum.
> IMO, just because this is tooling means we need lump any/all Teiid
> tooling into single project. Connector developers kit is a new effort,
> this has nothing do with what Designer does. Yes, this does need to be
> under the umbrella of Teiid or Teiid tools and it is.
I'm not suggesting it all needs to be under one project, that just one possible
option. Considering the use-case and expected user persona, I would expect them to remain
separate. But there ARE common concerns for all tooling when it comes to builds, testing,
integration, packaging, etc.
> Yes. Once this makes into JBT. We are not there yet. Once we request to
> be included in JBT then we will do any necessary work.
This is an effort we initiated, not just something that happened to appear on its own in
some other the community. Waiting until everything is done before you integrate is like
waiting until the end of a development cycle before you attempt integration. That always
becomes problematic, throws off schedules, etc. We know from experience that, if we know
these things will eventually go together in the same environment, we should work with that
in mind from the start, thus allowing for things like milestones...
> I dis-agree. Fedora is pulled from hundreds of places. Also, I have
> mentioned in my emails that this is temporary place holder to get the
> basic framework worked out. This will be pulled into main line Teiid
> under different "folder" or into a separate svn location. Based on the
> facts at the time we felt using source forge was the best option to
I shouldn't have stated it the way I did. I both understand why this decision was
made initially, and agree the hosting location itself doesn't matter. I'm really
trying to point out that we need to officially acknowledge and link to all of this in the
right places within our world, and it all needs to get inserted within our processes for
building, testing, etc.
> All I can say is Teiid community needs to seek out to JBT community if
> this needs to be part of JBT. As part of that integration we have do
> that work. I see this as parallel to the Designer tooling rather than
> part of it.
I was never suggesting this is part of the Designer effort, but should be part of an
overall tooling effort.
> Please share.
I'm talking about efforts around Web/XML services that involve integration with Teiid
and other JBoss projects. We don't have anything concrete enough to even throw out to
the community yet, so expect "something" will be coming in the future.
> Originally Teiid team proposed that, http://teiid.org
be the main
> umbrella site and others spawn from it. That is still a viable option if
> we are willing to put in the work.
I agree pulling Designer under your umbrella would work just as well.
> Yes, once we have a somewhat working plugin, we do need this.
That makes no sense to me. Why not do it now when others might contribute up front
towards the direction that plug-in is going? Is there no roadmap? Aren't there
> Absolutely. IMO, We need to release this in tech preview first. Then we
> can talk about integration into JBT/JBDS.
I have no idea what this means. How are you going to deliver this tech preview BEFORE
talking to the JBT group? Just offer it as a set of plug-ins that you hope works with JBT
and doesn't break or conflict conceptually with anything else? I fear you might be
overestimating the power and/or simplicity of Eclipse's plug-in architecture...
Bottom line is, if we have any plans at all regarding integration with JBT, we should be
talking to them now, not later.