Adding WSDL 2.0 Generation
by Ted Jones
In order to facilitate a REST architecture for our web service model based VDBs ( see TEIIDDES-122 ), we need to enable the HTTP binding spec support that WSDL 2.0 provides. Currently, our web service model generates WSDL 1.1. I would like to keep this behavior and add an option to the VDB web services tab to optionally generate WSDL 2.0. The WSDL 1.1 would still be generated according to the model definition, but we would convert to WSDL 2.0 using an Apache project called Woden . The 2.0 version of the wsdl would then be saved with the VDB. This way there would be no model changes required.
One issue I see here is that we could not re-import the WSDL without modifications to the importer for the web services model. That has always been something we have strived for in the past. Granted, we are not claiming support for WSDL 2.0 importing at this time but if we are generating it, it seems like we should go both ways?
Any thoughts on this approach to WSDL 2.0 generation?
Thanks,
Ted
14 years, 11 months
Re: [teiid-designer-dev] Re: [teiid-dev] 6.1 Release
by John Doyle
I'm a connector developer and this release was not immaterial from my perspective, its an embarrassment. NONE of my stuff works. And just to be clear, this is not because of any defect in Teiid, but because of Designer problems that I identified too late to get fixed.
But you know what, I don't care, it's done. I'm asking about 6.1. What are we going to differently for 6.1 to produce a release that is interesting and meaningful to users. Unless we patch the 6.0.0 Designer, which we don't want to do, you won't be able to use any of my connectors with a 6.0.0 Designer and a 6.1 Teiid either. So we have to get 6.1 Teiid to work with 6.1 Designer as I see it.
I've already stated how I think we should do this, leave Teiid in the unstable bucket until we have validated that Teiid and Designer work together. Then move them both to stable, which is the new 'GA'. How you you all think we should accomplish this?
~jd
----- "Steven Hawkins" <shawkins(a)redhat.com> wrote:
> What seems to be disturbing everyone is what the definition of a
> community release is. Ultimately that's up to the community, so kudos
> to us for having this discussion. Also, I don't take John's comment
> below as inflammatory, rather many of you heard me say the same prior
> to open sourcing that notion of a Teiid only initial release was
> immaterial from the perspective of most end users (but not connector
> developers).
>
> In a perfect world with respect to initial community releases, they
> would have been done at the edge of a productization cycle. Our
> timing was instead to go open source (or at least make public
> announcements) in the middle of a development cycle. The 6.0.0
> release of Teiid from an product perspective would be a milestone, but
> was done for the community for two reasons. First it was considered
> desirable to have a release close to the project announcement date.
> The other reason, which is more important, was to establish the
> independent nature of Teiid development. We may not all agree with
> those points, but there it stands.
>
> To sum up the best parts of this discussion:
>
> Does the Teiid 6.0.0 release matter to most users - Not really.
>
> Will there be synchronization between future Teiid and Teiid Designer
> releases - Not really.
>
> Will we be in the habit of patch releases - Not really.
>
> Do we need modularize our software more - Yes. A better separation of
> Teiid Designer's usage of Teiid's code, separating out projects for
> "large" connectors, soap services, etc.
> All need to be explored. We've made the jump from 1 code base to 3,
> we can do more if needed.
>
> ----- Original Message -----
> From: "John Verhaeg" <jverhaeg(a)redhat.com>
> To: "John Doyle" <jdoyle(a)redhat.com>
> Cc: teiid-designer-dev(a)lists.jboss.org, teiid-dev(a)lists.jboss.org,
> "Van Halbert" <vhalbert(a)redhat.com>, "Steven Hawkins"
> <shawkins(a)redhat.com>
> Sent: Thursday, April 23, 2009 10:36:19 AM GMT -06:00 US/Canada
> Central
> Subject: Re: [teiid-designer-dev] Re: [teiid-dev] 6.1 Release
>
>
> On Apr 23, 2009, at 10:29 AM, John Doyle wrote:
>
> >
> > I agree with this as long as the predicate is that there is a
> > version of tooling (Designer or other) that we have validated to
> > work with the Teiid release (excepting the new features in the Teiid
>
> > release as you described above).
> >
>
> Agreed. That's why I'm pretty much considering Teiid as a whole as
> unreleased, regardless of what version the Teiid Server team is
> working on. The difficult part is figuring out a way to convey this
>
> effectively to the community. Backing off a little on what I said
> before, it certainly would have been ideal in my mind if the very
> first version of Teiid wasn't released until Designer was ready, but
>
> that ship has sailed.
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
--
John Doyle
Senior Software Engineer
JBoss, a division of Red Hat
Office: 978.392.3916
Email: jdoyle(a)redhat.com
14 years, 11 months
Re: [teiid-designer-dev] Re: [teiid-dev] 6.1 Release
by John Doyle
I'm not really interested in criticizing the 6.0 release, but I'm interested in learning from it and doing better. I think all future releases of Teiid have to have some tooling that works with it. If it's the previous version of Designer that supports it with the exception of new features X and Y, then I think that's acceptable alternative. If it's the forthcoming alternative tooling, that's fine too. I think it greatly undermines the value of a the release, and is the best way to make a patch release a probability, but it's an improvement. But I think every release has to have tooling that works on the day we release or none of them will matter to users. Can we agree to that?
IMHO, I think we should break the releases apart only when we have the modularity allows us to do it in a verifiable way. Until we have APIs and SPIs that aren't in flux, how will we know and communicate to the community which version of our tools work with which version of Teiid? This seems to me like more work in the long run if we do it without the technical underpinnings already in place. Let's complete the modularization and then cut the cord.
Can you expand on what you mean by "the independent nature of Teiid development"?
~jd
----- "Steven Hawkins" <shawkins(a)redhat.com> wrote:
> What seems to be disturbing everyone is what the definition of a
> community release is. Ultimately that's up to the community, so kudos
> to us for having this discussion. Also, I don't take John's comment
> below as inflammatory, rather many of you heard me say the same prior
> to open sourcing that notion of a Teiid only initial release was
> immaterial from the perspective of most end users (but not connector
> developers).
>
> In a perfect world with respect to initial community releases, they
> would have been done at the edge of a productization cycle. Our
> timing was instead to go open source (or at least make public
> announcements) in the middle of a development cycle. The 6.0.0
> release of Teiid from an product perspective would be a milestone, but
> was done for the community for two reasons. First it was considered
> desirable to have a release close to the project announcement date.
> The other reason, which is more important, was to establish the
> independent nature of Teiid development. We may not all agree with
> those points, but there it stands.
>
> To sum up the best parts of this discussion:
>
> Does the Teiid 6.0.0 release matter to most users - Not really.
>
> Will there be synchronization between future Teiid and Teiid Designer
> releases - Not really.
>
> Will we be in the habit of patch releases - Not really.
>
> Do we need modularize our software more - Yes. A better separation of
> Teiid Designer's usage of Teiid's code, separating out projects for
> "large" connectors, soap services, etc.
> All need to be explored. We've made the jump from 1 code base to 3,
> we can do more if needed.
>
> ----- Original Message -----
> From: "John Verhaeg" <jverhaeg(a)redhat.com>
> To: "John Doyle" <jdoyle(a)redhat.com>
> Cc: teiid-designer-dev(a)lists.jboss.org, teiid-dev(a)lists.jboss.org,
> "Van Halbert" <vhalbert(a)redhat.com>, "Steven Hawkins"
> <shawkins(a)redhat.com>
> Sent: Thursday, April 23, 2009 10:36:19 AM GMT -06:00 US/Canada
> Central
> Subject: Re: [teiid-designer-dev] Re: [teiid-dev] 6.1 Release
>
>
> On Apr 23, 2009, at 10:29 AM, John Doyle wrote:
>
> >
> > I agree with this as long as the predicate is that there is a
> > version of tooling (Designer or other) that we have validated to
> > work with the Teiid release (excepting the new features in the Teiid
>
> > release as you described above).
> >
>
> Agreed. That's why I'm pretty much considering Teiid as a whole as
> unreleased, regardless of what version the Teiid Server team is
> working on. The difficult part is figuring out a way to convey this
>
> effectively to the community. Backing off a little on what I said
> before, it certainly would have been ideal in my mind if the very
> first version of Teiid wasn't released until Designer was ready, but
>
> that ship has sailed.
--
John Doyle
Senior Software Engineer
JBoss, a division of Red Hat
Office: 978.392.3916
Email: jdoyle(a)redhat.com
14 years, 12 months
Re: [teiid-designer-dev] Re: [teiid-dev] 6.1 Release
by Steven Hawkins
What seems to be disturbing everyone is what the definition of a community release is. Ultimately that's up to the community, so kudos to us for having this discussion. Also, I don't take John's comment below as inflammatory, rather many of you heard me say the same prior to open sourcing that notion of a Teiid only initial release was immaterial from the perspective of most end users (but not connector developers).
In a perfect world with respect to initial community releases, they would have been done at the edge of a productization cycle. Our timing was instead to go open source (or at least make public announcements) in the middle of a development cycle. The 6.0.0 release of Teiid from an product perspective would be a milestone, but was done for the community for two reasons. First it was considered desirable to have a release close to the project announcement date. The other reason, which is more important, was to establish the independent nature of Teiid development. We may not all agree with those points, but there it stands.
To sum up the best parts of this discussion:
Does the Teiid 6.0.0 release matter to most users - Not really.
Will there be synchronization between future Teiid and Teiid Designer releases - Not really.
Will we be in the habit of patch releases - Not really.
Do we need modularize our software more - Yes. A better separation of Teiid Designer's usage of Teiid's code, separating out projects for "large" connectors, soap services, etc.
All need to be explored. We've made the jump from 1 code base to 3, we can do more if needed.
----- Original Message -----
From: "John Verhaeg" <jverhaeg(a)redhat.com>
To: "John Doyle" <jdoyle(a)redhat.com>
Cc: teiid-designer-dev(a)lists.jboss.org, teiid-dev(a)lists.jboss.org, "Van Halbert" <vhalbert(a)redhat.com>, "Steven Hawkins" <shawkins(a)redhat.com>
Sent: Thursday, April 23, 2009 10:36:19 AM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] Re: [teiid-dev] 6.1 Release
On Apr 23, 2009, at 10:29 AM, John Doyle wrote:
>
> I agree with this as long as the predicate is that there is a
> version of tooling (Designer or other) that we have validated to
> work with the Teiid release (excepting the new features in the Teiid
> release as you described above).
>
Agreed. That's why I'm pretty much considering Teiid as a whole as
unreleased, regardless of what version the Teiid Server team is
working on. The difficult part is figuring out a way to convey this
effectively to the community. Backing off a little on what I said
before, it certainly would have been ideal in my mind if the very
first version of Teiid wasn't released until Designer was ready, but
that ship has sailed.
14 years, 12 months
Re: [teiid-designer-dev] Re: [teiid-dev] 6.1 Release
by Steven Hawkins
Everyone here is attempting to build a thriving community. It's just that there are differing opinions about how to do it. The major issue is whether Teiid "releases" should be mothballed prior to Designer availability. So far there is no agreement on that. Van's assertion that Teiid or the Server isn't valuable without a Designer release is really is really the same line of thought.
The Teiid lead's perspective is that we need to have defined Teiid releases - in terms of connector api, server api, functionality, etc. - so that the Designer, connector, or server developers have something stable to target. To that end a 6.0.0 release of Teiid does not impede the 6.0 release of Designer, rather it is essential. Whether it's "usable" on its own only matters to how we promote its use. Furthermore all changes made based upon Designer integration problems have been made to both 6.0.1 and 6.1.0. So we will have the ability to provide a release version of Teiid that is completely compatible with the Designer near its release. Finally the Teiid developers have been working constantly with the Designer developers to hammer out all release issues.
I should have also been more particular about the phase "forward looking". I mean to say the 7 release will have alternative metadata mechanisms.
----- Original Message -----
From: "Van Halbert" <vhalbert(a)redhat.com>
To: "John Doyle" <jdoyle(a)redhat.com>
Cc: "Steven Hawkins" <shawkins(a)redhat.com>, teiid-designer-dev(a)lists.jboss.org, teiid-dev(a)lists.jboss.org
Sent: Thursday, April 23, 2009 8:26:19 AM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] Re: [teiid-dev] 6.1 Release
Plain and simple, the server is no good without the designer. And
until we can get thru this period of getting it all to work together
as a stable set of code, it doesn't do anyone any good. I agree,
down the road, once we get this working that the 2 projects can live
independently, but it can't happen until its all working. And the
community doesn't start thriving until they can use it.
On Apr 23, 2009, at 8:16 AM, John Doyle wrote:
> I addressed the desire to have additional mechanisms to create Teiid
> artifacts, and those mechanisms don't exist yet, we shouldn't
> operate like they do.
>
> Its our job to build a thriving community, and the success of that
> effort will be determined by our ability to produce compelling high
> quality community projects, not platforms. The platform is
> immaterial to this discussion.
>
> ~jd
>
>
> ----- "Steven Hawkins" <shawkins(a)redhat.com> wrote:
>
>> We understand your perspective, but forward looking we do not see the
>> Designer as being the only metadata mechanism for Teiid.
>> Intrinsically tying the release schedules together even from the
>> start
>> does not seem helpful. I also understand that Designer feels
>> pressure
>> to release - however there is no hard requirement to do so.
>>
>> As Ramesh indicates it is already the role of the platform release to
>> put the stamp of quality across all correlated projects in that
>> platform. We do not need to reproduce that effort in the community -
>> it will already flow into the upstream.
>>
>> Also we will have a 6.1.0 release in the unstable spot starting next
>> week.
>>
>> ----- Original Message -----
>> From: "John Doyle" <jdoyle(a)redhat.com>
>> To: "Ramesh Reddy" <rareddy(a)redhat.com>
>> Cc: "Steven Hawkins" <shawkins(a)redhat.com>,
>> teiid-designer-dev(a)lists.jboss.org, teiid-dev(a)lists.jboss.org
>> Sent: Thursday, April 23, 2009 7:08:16 AM GMT -06:00 US/Canada
>> Central
>> Subject: Re: [teiid-designer-dev] Re: [teiid-dev] 6.1 Release
>>
>>
>> ----- "Ramesh Reddy" <rareddy(a)redhat.com> wrote:
>>
>>> On Wed, 2009-04-22 at 20:58 -0400, John Doyle wrote:
>>>>
>>>> I'm aware that there's an aggressive schedule, but I question
>> that
>>>> value of releasing Teiid on it's projected release date, if the
>>>> Designer is not ready to release, or vice versa.
>>>
>>> Release soon and release often is the mantra for JBoss. I do not
>>> believe
>>> either that they should be tightly dependent on release on each
>> other
>>> either. It would hard to adjust each others feature bucket, just so
>>> that
>>> they can be released together. Just think about the lost time for
>> the
>>> team waiting.
>>
>> What about leaving it on the shelf until they're both done? There's
>> no lost time if one project completes it's 6.1 work but it's not
>> 'officially' released and labeled as 6.1 until the other project is
>> ready. We already have stable and unstable slots on the community
>> site, but we're not putting any unstable out there. Put it out there
>> as unstable and move onto features for the next release. When we've
>> reach a level of quality between the two projects, then we label it
>> and post the stable version.
>>
>>>
>>> For this exact purpose we are creating branch (for example 6.0.x),
>> if
>>> you are looking for a stable branch to make such changes. Then it
>> is
>>> up
>>> us to either cut a patch or cut another release based on amount of
>>> changes.
>>>
>>> Platform releases, that tie all of them together.
>>>
>>
>> Why do we want to have a process that lends itself to the possibility
>> that we will have to patch a release just so users can have tooling
>> that works with it?
>>
>>>> I have changes coming in 6.1 to connectors that are depending
>> upon
>>>> importer changes. I can mock up tests for the connector changes,
>>> but
>>>> I won't really be able to validate a feature until I have two
>>> stable
>>>> projects in my hands that are pretty much locked down.
>>>>
>>> I understand, what you are saying, but instead of working around
>> it,
>>> we
>>> need to fix it. If you saying that we have connector changes that
>> are
>>> dependent upon tooling code to the runtime code, I we need to
>>>
>>> a) better plan according to upcoming releases
>>> b) decouple dependencies, use better abstractions
>>> c) modularize
>>>
>>> on these fronts we have stepped up and we need to to continue to
>> push
>>> further. Lets think in these terms and see if we can reduce this
>> for
>>> future releases. Can XML importer plugin can be deployed on its own
>>> without Designer stuff?
>>
>> All of these things are great, and I agree with all of these things.
>> To go further, we have wanted and and even produced alternative
>> tooling (mmshell). Someday there may be several different options
>> for
>> creating the artifacts that Teiid needs, and then your argument
>> becomes much stronger. But I don't think the projects should
>> adopt a
>> process that treats the the individual projects as independent when
>> they aren't yet. We should operate in the circumstances that exist,
>> not the ones we hope to create.
>>
>>>
>>>> We can call them independent all we want, users will disagree.
>>>> There's already traffic on the lists to demonstrate that.
>>>>
>>> The current release we are going through lot of connector type
>>> definition changes, once we stabilize embedded integration and
>>> connector
>>> integration this should reduced greatly, unless we change the vdb
>>> indexing. We got JIRAs for lot of these already.
>>
>> Yes, should, but how will we know? How do we validate that? The
>> truth is that we don't know what we're going to be changing in 18
>> months, and maybe it's going to be disruptive, maybe it's not. I
>> tend
>> to think that if it's not, then we're probably not doing very
>> interesting work. Another uncomfortable truth is that it's very hard
>> to see the full consequences of the changes we make. But either way
>> we should adopt a process that leads to higher quality, and I think
>> that posting the projects as unstable until we validate compatibility
>> achieves that without negative effect.
>>>
>>> Ramesh..
>>
>> _______________________________________________
>> teiid-dev mailing list
>> teiid-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/teiid-dev
>
> --
> John Doyle
> Senior Software Engineer
> JBoss, a division of Red Hat
> Office: 978.392.3916
> Email: jdoyle(a)redhat.com
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
Van Halbert
Principal Software Eng.
Red Hat, Inc.
------
vhalbert(a)redhat.com
14 years, 12 months
Re: [teiid-designer-dev] Re: [teiid-dev] 6.1 Release
by John Doyle
----- "John Verhaeg" <jverhaeg(a)redhat.com> wrote:
> I have to mostly agree with Hawkins on this - these projects should
> not be tied to each other's release schedules, even from the
> beginning. However, the reality is treating Teiid 6.0.0 as "released"
>
> is a misnomer until Designer 6.0.0 is released (which we should be
> very close to doing). Teiid is pretty much useless without at least
>
> *some* version of Designer being available. We want to change that
> fact in the future, but that's how things sit today. In other words,
>
> for all practical purposes - and for this very first release only - we
>
> need to treat the Teiid solution as a whole - both Teiid Server and
> Designer - as *unreleased* until Designer is released. Once Designer
>
> is out there, it shouldn't matter how often either project releases.
>
> Certainly the Designer release schedule in particular will remain
> important to the user for the short term, since Designer is, for now,
>
> the only way to produce the metadata and transformations that the
> server consumes. Another way of putting this is, for the near term,
>
> Teiid releases will be irrelevant to customers until a supporting
> version of Designer is released or unless they don't depend upon
> tooling in the first place. I definitely believe that while the
> server relies on the Designer as its sole source of input, the project
>
> needs to be diligent in documenting in its release notes what features
>
> are available and accessible, either due to their support by Designer
>
> or their independence from tooling, and those that are "available" but
>
> not accessible until a supporting version of Designer is released. If
>
> we don't do this, we'll just be creating our FUD within our own
> community.
I agree with this as long as the predicate is that there is a version of tooling (Designer or other) that we have validated to work with the Teiid release (excepting the new features in the Teiid release as you described above).
>
> Regarding the connector testing issues John originally referred to, if
>
> there really is a Designer dependency, then that connector should
> probably should even be advertised as available until a supporting
> version of the Designer is available. My disclaimer is I don't really
>
> understand the particular issue with the connector, so I might be way
>
> off here...
The general problem I'm referring to here not truly a Designer dependency, but rather a model dependency. New connector features often expect new modeling constructs that can be difficult for a user to get right. Currently Designer importers are the only solution, but with other tooling that will change.
14 years, 12 months
Re: [teiid-designer-dev] Re: [teiid-dev] 6.1 Release
by John Doyle
----- "Ramesh Reddy" <rareddy(a)redhat.com> wrote:
> On Wed, 2009-04-22 at 20:58 -0400, John Doyle wrote:
> >
> > I'm aware that there's an aggressive schedule, but I question that
> > value of releasing Teiid on it's projected release date, if the
> > Designer is not ready to release, or vice versa.
>
> Release soon and release often is the mantra for JBoss. I do not
> believe
> either that they should be tightly dependent on release on each other
> either. It would hard to adjust each others feature bucket, just so
> that
> they can be released together. Just think about the lost time for the
> team waiting.
What about leaving it on the shelf until they're both done? There's no lost time if one project completes it's 6.1 work but it's not 'officially' released and labeled as 6.1 until the other project is ready. We already have stable and unstable slots on the community site, but we're not putting any unstable out there. Put it out there as unstable and move onto features for the next release. When we've reach a level of quality between the two projects, then we label it and post the stable version.
>
> For this exact purpose we are creating branch (for example 6.0.x), if
> you are looking for a stable branch to make such changes. Then it is
> up
> us to either cut a patch or cut another release based on amount of
> changes.
>
> Platform releases, that tie all of them together.
>
Why do we want to have a process that lends itself to the possibility that we will have to patch a release just so users can have tooling that works with it?
> > I have changes coming in 6.1 to connectors that are depending upon
> > importer changes. I can mock up tests for the connector changes,
> but
> > I won't really be able to validate a feature until I have two
> stable
> > projects in my hands that are pretty much locked down.
> >
> I understand, what you are saying, but instead of working around it,
> we
> need to fix it. If you saying that we have connector changes that are
> dependent upon tooling code to the runtime code, I we need to
>
> a) better plan according to upcoming releases
> b) decouple dependencies, use better abstractions
> c) modularize
>
> on these fronts we have stepped up and we need to to continue to push
> further. Lets think in these terms and see if we can reduce this for
> future releases. Can XML importer plugin can be deployed on its own
> without Designer stuff?
All of these things are great, and I agree with all of these things. To go further, we have wanted and and even produced alternative tooling (mmshell). Someday there may be several different options for creating the artifacts that Teiid needs, and then your argument becomes much stronger. But I don't think the projects should adopt a process that treats the the individual projects as independent when they aren't yet. We should operate in the circumstances that exist, not the ones we hope to create.
>
> > We can call them independent all we want, users will disagree.
> > There's already traffic on the lists to demonstrate that.
> >
> The current release we are going through lot of connector type
> definition changes, once we stabilize embedded integration and
> connector
> integration this should reduced greatly, unless we change the vdb
> indexing. We got JIRAs for lot of these already.
Yes, should, but how will we know? How do we validate that? The truth is that we don't know what we're going to be changing in 18 months, and maybe it's going to be disruptive, maybe it's not. I tend to think that if it's not, then we're probably not doing very interesting work. Another uncomfortable truth is that it's very hard to see the full consequences of the changes we make. But either way we should adopt a process that leads to higher quality, and I think that posting the projects as unstable until we validate compatibility achieves that without negative effect.
>
> Ramesh..
14 years, 12 months
Re: [teiid-designer-dev] Re: [teiid-dev] 6.1 Release
by John Doyle
Yes, the consumers of Teiid need something stable to target, but it doesn't have to be released.
By releasing Teiid before the associated project(s)/systems we only create confusion for the community. When we release we're all going to post to our blogs, and a couple of months later a press release will happen (who could resist), and drive traffic to go and get the release. Why set up a system where brand new prospective user who just heard about us for the first time can't come and get version 6.0 of our engine, and 6.0 of our designer, and just assume that they work together? I understand that patches will happen, and we have to manage that, but why set it up that way?
Please explain to me what is the value of a released 6.0 or 6.1 Teiid if there is no tool that works with it?
I don't question that the Teiid team has been working closely with the Designer team, and I don't question that you have a bear of a schedule for 6.1 and forward. I just don't see the point on closing the door on a release with no tooling. Please explain the benefits to me.
~jd
----- "Steven Hawkins" <shawkins(a)redhat.com> wrote:
> Everyone here is attempting to build a thriving community. It's just
> that there are differing opinions about how to do it. The major issue
> is whether Teiid "releases" should be mothballed prior to Designer
> availability. So far there is no agreement on that. Van's assertion
> that Teiid or the Server isn't valuable without a Designer release is
> really is really the same line of thought.
>
> The Teiid lead's perspective is that we need to have defined Teiid
> releases - in terms of connector api, server api, functionality, etc.
> - so that the Designer, connector, or server developers have something
> stable to target. To that end a 6.0.0 release of Teiid does not
> impede the 6.0 release of Designer, rather it is essential. Whether
> it's "usable" on its own only matters to how we promote its use.
> Furthermore all changes made based upon Designer integration problems
> have been made to both 6.0.1 and 6.1.0. So we will have the ability
> to provide a release version of Teiid that is completely compatible
> with the Designer near its release. Finally the Teiid developers have
> been working constantly with the Designer developers to hammer out all
> release issues.
>
> I should have also been more particular about the phase "forward
> looking". I mean to say the 7 release will have alternative metadata
> mechanisms.
>
> ----- Original Message -----
> From: "Van Halbert" <vhalbert(a)redhat.com>
> To: "John Doyle" <jdoyle(a)redhat.com>
> Cc: "Steven Hawkins" <shawkins(a)redhat.com>,
> teiid-designer-dev(a)lists.jboss.org, teiid-dev(a)lists.jboss.org
> Sent: Thursday, April 23, 2009 8:26:19 AM GMT -06:00 US/Canada
> Central
> Subject: Re: [teiid-designer-dev] Re: [teiid-dev] 6.1 Release
>
> Plain and simple, the server is no good without the designer. And
>
> until we can get thru this period of getting it all to work together
>
> as a stable set of code, it doesn't do anyone any good. I agree,
> down the road, once we get this working that the 2 projects can live
>
> independently, but it can't happen until its all working. And the
>
> community doesn't start thriving until they can use it.
>
> On Apr 23, 2009, at 8:16 AM, John Doyle wrote:
>
> > I addressed the desire to have additional mechanisms to create Teiid
>
> > artifacts, and those mechanisms don't exist yet, we shouldn't
> > operate like they do.
> >
> > Its our job to build a thriving community, and the success of that
>
> > effort will be determined by our ability to produce compelling high
>
> > quality community projects, not platforms. The platform is
> > immaterial to this discussion.
> >
> > ~jd
> >
> >
> > ----- "Steven Hawkins" <shawkins(a)redhat.com> wrote:
> >
> >> We understand your perspective, but forward looking we do not see
> the
> >> Designer as being the only metadata mechanism for Teiid.
> >> Intrinsically tying the release schedules together even from the
> >> start
> >> does not seem helpful. I also understand that Designer feels
> >> pressure
> >> to release - however there is no hard requirement to do so.
> >>
> >> As Ramesh indicates it is already the role of the platform release
> to
> >> put the stamp of quality across all correlated projects in that
> >> platform. We do not need to reproduce that effort in the community
> -
> >> it will already flow into the upstream.
> >>
> >> Also we will have a 6.1.0 release in the unstable spot starting
> next
> >> week.
> >>
> >> ----- Original Message -----
> >> From: "John Doyle" <jdoyle(a)redhat.com>
> >> To: "Ramesh Reddy" <rareddy(a)redhat.com>
> >> Cc: "Steven Hawkins" <shawkins(a)redhat.com>,
> >> teiid-designer-dev(a)lists.jboss.org, teiid-dev(a)lists.jboss.org
> >> Sent: Thursday, April 23, 2009 7:08:16 AM GMT -06:00 US/Canada
> >> Central
> >> Subject: Re: [teiid-designer-dev] Re: [teiid-dev] 6.1 Release
> >>
> >>
> >> ----- "Ramesh Reddy" <rareddy(a)redhat.com> wrote:
> >>
> >>> On Wed, 2009-04-22 at 20:58 -0400, John Doyle wrote:
> >>>>
> >>>> I'm aware that there's an aggressive schedule, but I question
> >> that
> >>>> value of releasing Teiid on it's projected release date, if the
> >>>> Designer is not ready to release, or vice versa.
> >>>
> >>> Release soon and release often is the mantra for JBoss. I do not
> >>> believe
> >>> either that they should be tightly dependent on release on each
> >> other
> >>> either. It would hard to adjust each others feature bucket, just
> so
> >>> that
> >>> they can be released together. Just think about the lost time for
> >> the
> >>> team waiting.
> >>
> >> What about leaving it on the shelf until they're both done?
> There's
> >> no lost time if one project completes it's 6.1 work but it's not
> >> 'officially' released and labeled as 6.1 until the other project
> is
> >> ready. We already have stable and unstable slots on the community
> >> site, but we're not putting any unstable out there. Put it out
> there
> >> as unstable and move onto features for the next release. When
> we've
> >> reach a level of quality between the two projects, then we label
> it
> >> and post the stable version.
> >>
> >>>
> >>> For this exact purpose we are creating branch (for example
> 6.0.x),
> >> if
> >>> you are looking for a stable branch to make such changes. Then it
> >> is
> >>> up
> >>> us to either cut a patch or cut another release based on amount
> of
> >>> changes.
> >>>
> >>> Platform releases, that tie all of them together.
> >>>
> >>
> >> Why do we want to have a process that lends itself to the
> possibility
> >> that we will have to patch a release just so users can have
> tooling
> >> that works with it?
> >>
> >>>> I have changes coming in 6.1 to connectors that are depending
> >> upon
> >>>> importer changes. I can mock up tests for the connector
> changes,
> >>> but
> >>>> I won't really be able to validate a feature until I have two
> >>> stable
> >>>> projects in my hands that are pretty much locked down.
> >>>>
> >>> I understand, what you are saying, but instead of working around
> >> it,
> >>> we
> >>> need to fix it. If you saying that we have connector changes that
> >> are
> >>> dependent upon tooling code to the runtime code, I we need to
> >>>
> >>> a) better plan according to upcoming releases
> >>> b) decouple dependencies, use better abstractions
> >>> c) modularize
> >>>
> >>> on these fronts we have stepped up and we need to to continue to
> >> push
> >>> further. Lets think in these terms and see if we can reduce this
> >> for
> >>> future releases. Can XML importer plugin can be deployed on its
> own
> >>> without Designer stuff?
> >>
> >> All of these things are great, and I agree with all of these
> things.
> >> To go further, we have wanted and and even produced alternative
> >> tooling (mmshell). Someday there may be several different options
>
> >> for
> >> creating the artifacts that Teiid needs, and then your argument
> >> becomes much stronger. But I don't think the projects should
> >> adopt a
> >> process that treats the the individual projects as independent
> when
> >> they aren't yet. We should operate in the circumstances that
> exist,
> >> not the ones we hope to create.
> >>
> >>>
> >>>> We can call them independent all we want, users will disagree.
> >>>> There's already traffic on the lists to demonstrate that.
> >>>>
> >>> The current release we are going through lot of connector type
> >>> definition changes, once we stabilize embedded integration and
> >>> connector
> >>> integration this should reduced greatly, unless we change the vdb
> >>> indexing. We got JIRAs for lot of these already.
> >>
> >> Yes, should, but how will we know? How do we validate that? The
> >> truth is that we don't know what we're going to be changing in 18
> >> months, and maybe it's going to be disruptive, maybe it's not. I
>
> >> tend
> >> to think that if it's not, then we're probably not doing very
> >> interesting work. Another uncomfortable truth is that it's very
> hard
> >> to see the full consequences of the changes we make. But either
> way
> >> we should adopt a process that leads to higher quality, and I
> think
> >> that posting the projects as unstable until we validate
> compatibility
> >> achieves that without negative effect.
> >>>
> >>> Ramesh..
> >>
> >> _______________________________________________
> >> teiid-dev mailing list
> >> teiid-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/teiid-dev
> >
> > --
> > John Doyle
> > Senior Software Engineer
> > JBoss, a division of Red Hat
> > Office: 978.392.3916
> > Email: jdoyle(a)redhat.com
> > _______________________________________________
> > teiid-dev mailing list
> > teiid-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/teiid-dev
>
> Van Halbert
> Principal Software Eng.
> Red Hat, Inc.
> ------
> vhalbert(a)redhat.com
--
John Doyle
Senior Software Engineer
JBoss, a division of Red Hat
Office: 978.392.3916
Email: jdoyle(a)redhat.com
14 years, 12 months
Re: [teiid-designer-dev] Re: [teiid-dev] 6.1 Release
by John Doyle
I addressed the desire to have additional mechanisms to create Teiid artifacts, and those mechanisms don't exist yet, we shouldn't operate like they do.
Its our job to build a thriving community, and the success of that effort will be determined by our ability to produce compelling high quality community projects, not platforms. The platform is immaterial to this discussion.
~jd
----- "Steven Hawkins" <shawkins(a)redhat.com> wrote:
> We understand your perspective, but forward looking we do not see the
> Designer as being the only metadata mechanism for Teiid.
> Intrinsically tying the release schedules together even from the start
> does not seem helpful. I also understand that Designer feels pressure
> to release - however there is no hard requirement to do so.
>
> As Ramesh indicates it is already the role of the platform release to
> put the stamp of quality across all correlated projects in that
> platform. We do not need to reproduce that effort in the community -
> it will already flow into the upstream.
>
> Also we will have a 6.1.0 release in the unstable spot starting next
> week.
>
> ----- Original Message -----
> From: "John Doyle" <jdoyle(a)redhat.com>
> To: "Ramesh Reddy" <rareddy(a)redhat.com>
> Cc: "Steven Hawkins" <shawkins(a)redhat.com>,
> teiid-designer-dev(a)lists.jboss.org, teiid-dev(a)lists.jboss.org
> Sent: Thursday, April 23, 2009 7:08:16 AM GMT -06:00 US/Canada
> Central
> Subject: Re: [teiid-designer-dev] Re: [teiid-dev] 6.1 Release
>
>
> ----- "Ramesh Reddy" <rareddy(a)redhat.com> wrote:
>
> > On Wed, 2009-04-22 at 20:58 -0400, John Doyle wrote:
> > >
> > > I'm aware that there's an aggressive schedule, but I question
> that
> > > value of releasing Teiid on it's projected release date, if the
> > > Designer is not ready to release, or vice versa.
> >
> > Release soon and release often is the mantra for JBoss. I do not
> > believe
> > either that they should be tightly dependent on release on each
> other
> > either. It would hard to adjust each others feature bucket, just so
> > that
> > they can be released together. Just think about the lost time for
> the
> > team waiting.
>
> What about leaving it on the shelf until they're both done? There's
> no lost time if one project completes it's 6.1 work but it's not
> 'officially' released and labeled as 6.1 until the other project is
> ready. We already have stable and unstable slots on the community
> site, but we're not putting any unstable out there. Put it out there
> as unstable and move onto features for the next release. When we've
> reach a level of quality between the two projects, then we label it
> and post the stable version.
>
> >
> > For this exact purpose we are creating branch (for example 6.0.x),
> if
> > you are looking for a stable branch to make such changes. Then it
> is
> > up
> > us to either cut a patch or cut another release based on amount of
> > changes.
> >
> > Platform releases, that tie all of them together.
> >
>
> Why do we want to have a process that lends itself to the possibility
> that we will have to patch a release just so users can have tooling
> that works with it?
>
> > > I have changes coming in 6.1 to connectors that are depending
> upon
> > > importer changes. I can mock up tests for the connector changes,
> > but
> > > I won't really be able to validate a feature until I have two
> > stable
> > > projects in my hands that are pretty much locked down.
> > >
> > I understand, what you are saying, but instead of working around
> it,
> > we
> > need to fix it. If you saying that we have connector changes that
> are
> > dependent upon tooling code to the runtime code, I we need to
> >
> > a) better plan according to upcoming releases
> > b) decouple dependencies, use better abstractions
> > c) modularize
> >
> > on these fronts we have stepped up and we need to to continue to
> push
> > further. Lets think in these terms and see if we can reduce this
> for
> > future releases. Can XML importer plugin can be deployed on its own
> > without Designer stuff?
>
> All of these things are great, and I agree with all of these things.
> To go further, we have wanted and and even produced alternative
> tooling (mmshell). Someday there may be several different options for
> creating the artifacts that Teiid needs, and then your argument
> becomes much stronger. But I don't think the projects should adopt a
> process that treats the the individual projects as independent when
> they aren't yet. We should operate in the circumstances that exist,
> not the ones we hope to create.
>
> >
> > > We can call them independent all we want, users will disagree.
> > > There's already traffic on the lists to demonstrate that.
> > >
> > The current release we are going through lot of connector type
> > definition changes, once we stabilize embedded integration and
> > connector
> > integration this should reduced greatly, unless we change the vdb
> > indexing. We got JIRAs for lot of these already.
>
> Yes, should, but how will we know? How do we validate that? The
> truth is that we don't know what we're going to be changing in 18
> months, and maybe it's going to be disruptive, maybe it's not. I tend
> to think that if it's not, then we're probably not doing very
> interesting work. Another uncomfortable truth is that it's very hard
> to see the full consequences of the changes we make. But either way
> we should adopt a process that leads to higher quality, and I think
> that posting the projects as unstable until we validate compatibility
> achieves that without negative effect.
> >
> > Ramesh..
>
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
--
John Doyle
Senior Software Engineer
JBoss, a division of Red Hat
Office: 978.392.3916
Email: jdoyle(a)redhat.com
14 years, 12 months
Re: [teiid-designer-dev] Re: [teiid-dev] 6.1 Release
by Steven Hawkins
We understand your perspective, but forward looking we do not see the Designer as being the only metadata mechanism for Teiid. Intrinsically tying the release schedules together even from the start does not seem helpful. I also understand that Designer feels pressure to release - however there is no hard requirement to do so.
As Ramesh indicates it is already the role of the platform release to put the stamp of quality across all correlated projects in that platform. We do not need to reproduce that effort in the community - it will already flow into the upstream.
Also we will have a 6.1.0 release in the unstable spot starting next week.
----- Original Message -----
From: "John Doyle" <jdoyle(a)redhat.com>
To: "Ramesh Reddy" <rareddy(a)redhat.com>
Cc: "Steven Hawkins" <shawkins(a)redhat.com>, teiid-designer-dev(a)lists.jboss.org, teiid-dev(a)lists.jboss.org
Sent: Thursday, April 23, 2009 7:08:16 AM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] Re: [teiid-dev] 6.1 Release
----- "Ramesh Reddy" <rareddy(a)redhat.com> wrote:
> On Wed, 2009-04-22 at 20:58 -0400, John Doyle wrote:
> >
> > I'm aware that there's an aggressive schedule, but I question that
> > value of releasing Teiid on it's projected release date, if the
> > Designer is not ready to release, or vice versa.
>
> Release soon and release often is the mantra for JBoss. I do not
> believe
> either that they should be tightly dependent on release on each other
> either. It would hard to adjust each others feature bucket, just so
> that
> they can be released together. Just think about the lost time for the
> team waiting.
What about leaving it on the shelf until they're both done? There's no lost time if one project completes it's 6.1 work but it's not 'officially' released and labeled as 6.1 until the other project is ready. We already have stable and unstable slots on the community site, but we're not putting any unstable out there. Put it out there as unstable and move onto features for the next release. When we've reach a level of quality between the two projects, then we label it and post the stable version.
>
> For this exact purpose we are creating branch (for example 6.0.x), if
> you are looking for a stable branch to make such changes. Then it is
> up
> us to either cut a patch or cut another release based on amount of
> changes.
>
> Platform releases, that tie all of them together.
>
Why do we want to have a process that lends itself to the possibility that we will have to patch a release just so users can have tooling that works with it?
> > I have changes coming in 6.1 to connectors that are depending upon
> > importer changes. I can mock up tests for the connector changes,
> but
> > I won't really be able to validate a feature until I have two
> stable
> > projects in my hands that are pretty much locked down.
> >
> I understand, what you are saying, but instead of working around it,
> we
> need to fix it. If you saying that we have connector changes that are
> dependent upon tooling code to the runtime code, I we need to
>
> a) better plan according to upcoming releases
> b) decouple dependencies, use better abstractions
> c) modularize
>
> on these fronts we have stepped up and we need to to continue to push
> further. Lets think in these terms and see if we can reduce this for
> future releases. Can XML importer plugin can be deployed on its own
> without Designer stuff?
All of these things are great, and I agree with all of these things. To go further, we have wanted and and even produced alternative tooling (mmshell). Someday there may be several different options for creating the artifacts that Teiid needs, and then your argument becomes much stronger. But I don't think the projects should adopt a process that treats the the individual projects as independent when they aren't yet. We should operate in the circumstances that exist, not the ones we hope to create.
>
> > We can call them independent all we want, users will disagree.
> > There's already traffic on the lists to demonstrate that.
> >
> The current release we are going through lot of connector type
> definition changes, once we stabilize embedded integration and
> connector
> integration this should reduced greatly, unless we change the vdb
> indexing. We got JIRAs for lot of these already.
Yes, should, but how will we know? How do we validate that? The truth is that we don't know what we're going to be changing in 18 months, and maybe it's going to be disruptive, maybe it's not. I tend to think that if it's not, then we're probably not doing very interesting work. Another uncomfortable truth is that it's very hard to see the full consequences of the changes we make. But either way we should adopt a process that leads to higher quality, and I think that posting the projects as unstable until we validate compatibility achieves that without negative effect.
>
> Ramesh..
14 years, 12 months