soa tooling build can't aggregate runtime.{drools,esb,jbpm}.detector unless they're on an upstream site ------------------------------------------------------------------------------------------------------- Key: JBIDE-10968 URL: https://issues.jboss.org/browse/JBIDE-10968 Project: Tools (JBoss Tools) Issue Type: Bug Components: drools, esb, jbpm, runtime detection, SOA Tooling Affects Versions: 3.3.0.Beta1-soa Reporter: Nick Boldt Assignee: Douglas Palmer Priority: Blocker Fix For: 3.3.0.Beta1-soa Max, the issue is not that they need to exist on the soa side, it's that to BUILD the soa site, they need to exist upstream first. Thus, they would need to ALSO be on the JBT Core site as well as the JBT SOA site. Or else we need some other way to get them in there, like having them move from being part of Runtime to some other "Runtime-SOA" component which only SOA builds, downstream from Runtime and JBT Core aggregation. N On 02/20/2012 11:37 AM, Max Rydahl Andersen wrote: > please open jira on this - this is a technical issue on how runtime detection should work outofthebox. > > something SOA and Core engineering team need to coordinate on. > > but yes, since the runtime detectors rely on the soa stuff they need to exist on soa side of things. > > /max > > On Feb 20, 2012, at 7:32 AM, Nick Boldt wrote: > >> The JBT SOA Tooling aggregate [1] now sources from the upstream JBT Core site [2], and does NOT use the JBT Core composite staging site [3], only the JBT SOA Tooling one [4] so as to avoid getting a mismatched set of upstream plugins (eg., a newer Runtime component in staging vs. the last pulled nightly snapshot). >> >> However, this means that the build is failing because it can't find the org.jboss.tools.runtime.{drools,esb,jbpm}.detector.feature features, as they're *not currently published* to the JBT Core nightly site [2], only the composite [3] and the individual component's staging site [5]. This may be simply an oversight, or it was done intentionally because these detectors only make sense to be in the SOA Tooling site, not in Core. >> >> To solve this we should probably put these features into the JBT Aggregate site (albeit as hidden features). Then they can be found by the SOA Tooling jobs and categorized there. >> >> Does that make sense? >> >> [1] https://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_stable_branch.soa-t... >> >> [2] http://download.jboss.org/jbosstools/updates/nightly/core/3.3.indigo/ >> >> [3] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/3.3.... >> >> [4] http://download.jboss.org/jbosstools/builds/staging/_composite_/soa-tooli... >> >> [5] http://download.jboss.org/jbosstools/builds/staging/jbosstools-3.3_stable...

soa tooling build can't aggregate runtime.{drools,esb,jbpm}.detector unless they're on an upstream site ------------------------------------------------------------------------------------------------------- Key: JBIDE-10968 URL: https://issues.jboss.org/browse/JBIDE-10968 Project: Tools (JBoss Tools) Issue Type: Bug Components: drools, esb, jbpm, runtime detection, SOA Tooling Affects Versions: 3.3.0.Beta1-SOA Reporter: Nick Boldt Assignee: Nick Boldt Priority: Blocker Fix For: 3.3.0.Beta1-SOA Max, the issue is not that they need to exist on the soa side, it's that to BUILD the soa site, they need to exist upstream first. Thus, they would need to ALSO be on the JBT Core site as well as the JBT SOA site. Or else we need some other way to get them in there, like having them move from being part of Runtime to some other "Runtime-SOA" component which only SOA builds, downstream from Runtime and JBT Core aggregation. N On 02/20/2012 11:37 AM, Max Rydahl Andersen wrote: > please open jira on this - this is a technical issue on how runtime detection should work outofthebox. > > something SOA and Core engineering team need to coordinate on. > > but yes, since the runtime detectors rely on the soa stuff they need to exist on soa side of things. > > /max > > On Feb 20, 2012, at 7:32 AM, Nick Boldt wrote: > >> The JBT SOA Tooling aggregate [1] now sources from the upstream JBT Core site [2], and does NOT use the JBT Core composite staging site [3], only the JBT SOA Tooling one [4] so as to avoid getting a mismatched set of upstream plugins (eg., a newer Runtime component in staging vs. the last pulled nightly snapshot). >> >> However, this means that the build is failing because it can't find the org.jboss.tools.runtime.{drools,esb,jbpm}.detector.feature features, as they're *not currently published* to the JBT Core nightly site [2], only the composite [3] and the individual component's staging site [5]. This may be simply an oversight, or it was done intentionally because these detectors only make sense to be in the SOA Tooling site, not in Core. >> >> To solve this we should probably put these features into the JBT Aggregate site (albeit as hidden features). Then they can be found by the SOA Tooling jobs and categorized there. >> >> Does that make sense? >> >> [1] https://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_stable_branch.soa-t... >> >> [2] http://download.jboss.org/jbosstools/updates/nightly/core/3.3.indigo/ >> >> [3] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/3.3.... >> >> [4] http://download.jboss.org/jbosstools/builds/staging/_composite_/soa-tooli... >> >> [5] http://download.jboss.org/jbosstools/builds/staging/jbosstools-3.3_stable...

soa tooling build can't aggregate runtime.{drools,esb,jbpm}.detector unless they're on an upstream site ------------------------------------------------------------------------------------------------------- Key: JBIDE-10968 URL: https://issues.jboss.org/browse/JBIDE-10968 Project: Tools (JBoss Tools) Issue Type: Bug Components: drools, esb, jbpm, runtime detection, SOA Tooling Affects Versions: 3.3.0.Beta1-SOA Reporter: Nick Boldt Assignee: Nick Boldt Priority: Blocker Fix For: 3.3.0.Beta1-SOA Max, the issue is not that they need to exist on the soa side, it's that to BUILD the soa site, they need to exist upstream first. Thus, they would need to ALSO be on the JBT Core site as well as the JBT SOA site. Or else we need some other way to get them in there, like having them move from being part of Runtime to some other "Runtime-SOA" component which only SOA builds, downstream from Runtime and JBT Core aggregation. N On 02/20/2012 11:37 AM, Max Rydahl Andersen wrote: > please open jira on this - this is a technical issue on how runtime detection should work outofthebox. > > something SOA and Core engineering team need to coordinate on. > > but yes, since the runtime detectors rely on the soa stuff they need to exist on soa side of things. > > /max > > On Feb 20, 2012, at 7:32 AM, Nick Boldt wrote: > >> The JBT SOA Tooling aggregate [1] now sources from the upstream JBT Core site [2], and does NOT use the JBT Core composite staging site [3], only the JBT SOA Tooling one [4] so as to avoid getting a mismatched set of upstream plugins (eg., a newer Runtime component in staging vs. the last pulled nightly snapshot). >> >> However, this means that the build is failing because it can't find the org.jboss.tools.runtime.{drools,esb,jbpm}.detector.feature features, as they're *not currently published* to the JBT Core nightly site [2], only the composite [3] and the individual component's staging site [5]. This may be simply an oversight, or it was done intentionally because these detectors only make sense to be in the SOA Tooling site, not in Core. >> >> To solve this we should probably put these features into the JBT Aggregate site (albeit as hidden features). Then they can be found by the SOA Tooling jobs and categorized there. >> >> Does that make sense? >> >> [1] https://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_stable_branch.soa-t... >> >> [2] http://download.jboss.org/jbosstools/updates/nightly/core/3.3.indigo/ >> >> [3] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/3.3.... >> >> [4] http://download.jboss.org/jbosstools/builds/staging/_composite_/soa-tooli... >> >> [5] http://download.jboss.org/jbosstools/builds/staging/jbosstools-3.3_stable...

soa tooling build can't aggregate runtime.{drools,esb,jbpm}.detector unless they're on an upstream site ------------------------------------------------------------------------------------------------------- Key: JBIDE-10968 URL: https://issues.jboss.org/browse/JBIDE-10968 Project: Tools (JBoss Tools) Issue Type: Bug Components: drools, esb, jbpm, runtime detection, SOA Tooling Affects Versions: 3.3.0.Beta1-SOA Reporter: Nick Boldt Assignee: Libor Zoubek Priority: Blocker Fix For: 3.3.0.Beta1-SOA, 3.3.0.Beta3 Max, the issue is not that they need to exist on the soa side, it's that to BUILD the soa site, they need to exist upstream first. Thus, they would need to ALSO be on the JBT Core site as well as the JBT SOA site. Or else we need some other way to get them in there, like having them move from being part of Runtime to some other "Runtime-SOA" component which only SOA builds, downstream from Runtime and JBT Core aggregation. N On 02/20/2012 11:37 AM, Max Rydahl Andersen wrote: > please open jira on this - this is a technical issue on how runtime detection should work outofthebox. > > something SOA and Core engineering team need to coordinate on. > > but yes, since the runtime detectors rely on the soa stuff they need to exist on soa side of things. > > /max > > On Feb 20, 2012, at 7:32 AM, Nick Boldt wrote: > >> The JBT SOA Tooling aggregate [1] now sources from the upstream JBT Core site [2], and does NOT use the JBT Core composite staging site [3], only the JBT SOA Tooling one [4] so as to avoid getting a mismatched set of upstream plugins (eg., a newer Runtime component in staging vs. the last pulled nightly snapshot). >> >> However, this means that the build is failing because it can't find the org.jboss.tools.runtime.{drools,esb,jbpm}.detector.feature features, as they're *not currently published* to the JBT Core nightly site [2], only the composite [3] and the individual component's staging site [5]. This may be simply an oversight, or it was done intentionally because these detectors only make sense to be in the SOA Tooling site, not in Core. >> >> To solve this we should probably put these features into the JBT Aggregate site (albeit as hidden features). Then they can be found by the SOA Tooling jobs and categorized there. >> >> Does that make sense? >> >> [1] https://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_stable_branch.soa-t... >> >> [2] http://download.jboss.org/jbosstools/updates/nightly/core/3.3.indigo/ >> >> [3] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/3.3.... >> >> [4] http://download.jboss.org/jbosstools/builds/staging/_composite_/soa-tooli... >> >> [5] http://download.jboss.org/jbosstools/builds/staging/jbosstools-3.3_stable...

soa tooling build can't aggregate runtime.{drools,esb,jbpm}.detector unless they're on an upstream site ------------------------------------------------------------------------------------------------------- Key: JBIDE-10968 URL: https://issues.jboss.org/browse/JBIDE-10968 Project: Tools (JBoss Tools) Issue Type: Bug Components: drools, esb, jbpm, runtime detection, SOA Tooling Affects Versions: 3.3.0.Beta1-SOA Reporter: Nick Boldt Assignee: Nick Boldt Priority: Blocker Fix For: 3.3.0.Beta1-SOA, 3.3.0.Beta3 Max, the issue is not that they need to exist on the soa side, it's that to BUILD the soa site, they need to exist upstream first. Thus, they would need to ALSO be on the JBT Core site as well as the JBT SOA site. Or else we need some other way to get them in there, like having them move from being part of Runtime to some other "Runtime-SOA" component which only SOA builds, downstream from Runtime and JBT Core aggregation. N On 02/20/2012 11:37 AM, Max Rydahl Andersen wrote: > please open jira on this - this is a technical issue on how runtime detection should work outofthebox. > > something SOA and Core engineering team need to coordinate on. > > but yes, since the runtime detectors rely on the soa stuff they need to exist on soa side of things. > > /max > > On Feb 20, 2012, at 7:32 AM, Nick Boldt wrote: > >> The JBT SOA Tooling aggregate [1] now sources from the upstream JBT Core site [2], and does NOT use the JBT Core composite staging site [3], only the JBT SOA Tooling one [4] so as to avoid getting a mismatched set of upstream plugins (eg., a newer Runtime component in staging vs. the last pulled nightly snapshot). >> >> However, this means that the build is failing because it can't find the org.jboss.tools.runtime.{drools,esb,jbpm}.detector.feature features, as they're *not currently published* to the JBT Core nightly site [2], only the composite [3] and the individual component's staging site [5]. This may be simply an oversight, or it was done intentionally because these detectors only make sense to be in the SOA Tooling site, not in Core. >> >> To solve this we should probably put these features into the JBT Aggregate site (albeit as hidden features). Then they can be found by the SOA Tooling jobs and categorized there. >> >> Does that make sense? >> >> [1] https://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_stable_branch.soa-t... >> >> [2] http://download.jboss.org/jbosstools/updates/nightly/core/3.3.indigo/ >> >> [3] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/3.3.... >> >> [4] http://download.jboss.org/jbosstools/builds/staging/_composite_/soa-tooli... >> >> [5] http://download.jboss.org/jbosstools/builds/staging/jbosstools-3.3_stable...