Hey all,

Since v. 5.4 is not in the nightly SOA repo, how would one go about setting up the SY tooling project to reference the Drools tools 5.4 snapshot builds?

> This is the same principle as "standard" Maven, except that instead > of Maven repositories, you use p2 repositories. This was the point of my question. So: Does such a repository exist? If so, where does it live? If a repository does not already exist, I'll simply wait until a Guvnor 5.4 release is available from the nightly SOA repo.

Thanks for the history. I certainly don't mind being the point of contact for the SwitchYard tools. My preference would be that projects adhere to the spirit of nightly, in that the nightly repo contains the most recent build, stable or not.

As for the stable repo, I'm going to guess that's going to be a bit more difficult to coordinate as all these projects are moving at different speeds.

At this point, it would probably be sufficient to simply have each project push manually when they hit a milestone. This might create an unstable set of plugins (e.g. SwitchYard 0.4 and Guvnor 5.3.1, although we'd state the SwitchYard Guvnor feature is experimental, since it relies on Guvnor nightly build), but it's simple and it's a start.

I'm guessing at some point, there will be coordinated release milestones across the SOA tools, much like the milestones for JBT.

Best, Rob ----- Original Message ----- > >>> This is the same principle as "standard" Maven, except that >>> instead >>> of Maven repositories, you use p2 repositories. >> >> This was the point of my question. So: Does such a repository >> exist? If so, where does it live? >> >> If a repository does not already exist, I'll simply wait until a >> Guvnor 5.4 release is available from the nightly SOA repo. > > Right now SOA tools have expressed the wish to be "independent" and > as such we've stopped having them as part of > jbosstools main builds. > > Right now each of these projects are just built "on its own" and we > previously just took in specific releases/builds as suggested by > the team when we *pulled*/nagged for getting such info. Before it > went to the main jbosstools site but after SOA want to be > more independent (and build "on top") they are in this "soa site" > which is updated much less. > > I personally wish that SOA tools (i.e. drools, switchyard, jbpm, > guvnor, savara etc.) would get together and help Douglas (in cc) > to setup and drive a more unified build setup of the SOA plugins so > this kind of collaboration became much easier. > > The current thinking is that Douglas will get the soa tooling site > setup so each individual team can push their own changes - > but that does not solve your problem since you all would need to > coordinate so updates to Drools doesn't break you and viceversa. > (or maybe you want it to break so you can find the issues faster and > then fix it faster ;) > > /max _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

>> I'm guessing at some point, there will be coordinated release >> milestones across the SOA tools, much like the milestones for JBT. > > Not unless the SOA tools dev get that going. > > Right now the "coordinated release" will be taking place on the > "older" plugins being used for the productized versions. > > For the new development I/we need the devs on SOA tooling to setup > such release milestones. Probably going to be tough. It might be nice if we could standardize on something like a quarterly-ish or semi-annual release. The purpose being to provide a wholesale refresh of the stable SOA repo. This could be as simple as whatever the latest "release" build is for each project. For example, if we were to do this today, that would be 0.3.0.Final for SY; next month it would be 0.4.0.Final. As the release approaches, coordination can pick up to ensure the necessary interdependencies are aligned properly. This may involve sliding the date a bit, if necessary.

Also, I think the more process that is put around this, the less likely it will be to occur.

> I'll be glad help doing that - but need the dev teams to align with. > > /max > >> >> Best, >> Rob >> >> ----- Original Message ----- >>> >>>>> This is the same principle as "standard" Maven, except that >>>>> instead >>>>> of Maven repositories, you use p2 repositories. >>>> >>>> This was the point of my question. So: Does such a repository >>>> exist? If so, where does it live? >>>> >>>> If a repository does not already exist, I'll simply wait until a >>>> Guvnor 5.4 release is available from the nightly SOA repo. >>> >>> Right now SOA tools have expressed the wish to be "independent" >>> and >>> as such we've stopped having them as part of >>> jbosstools main builds. >>> >>> Right now each of these projects are just built "on its own" and >>> we >>> previously just took in specific releases/builds as suggested by >>> the team when we *pulled*/nagged for getting such info. Before it >>> went to the main jbosstools site but after SOA want to be >>> more independent (and build "on top") they are in this "soa site" >>> which is updated much less. >>> >>> I personally wish that SOA tools (i.e. drools, switchyard, jbpm, >>> guvnor, savara etc.) would get together and help Douglas (in cc) >>> to setup and drive a more unified build setup of the SOA plugins >>> so >>> this kind of collaboration became much easier. >>> >>> The current thinking is that Douglas will get the soa tooling site >>> setup so each individual team can push their own changes - >>> but that does not solve your problem since you all would need to >>> coordinate so updates to Drools doesn't break you and viceversa. >>> (or maybe you want it to break so you can find the issues faster >>> and >>> then fix it faster ;) >>> >>> /max >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> >> > >

> Recently, we (SwitchYard) have been working on adding support for referencing artifacts from SOA repositories. Tooling has been added to allow the creation of these references in generic form or by referencing a package from a Guvnor repository. All is well and good for the generic tooling, but the Guvnor integration requires v 5.4 of the Guvnor/Drools tooling. So... You don't rely on *all* of drools 5.4 do you ? only the guvnor part correct ? > Since v. 5.4 is not in the nightly SOA repo, how would one go about setting up the SY tooling project to reference the Drools tools 5.4 snapshot builds? Answered in other thread. > P.S. The Guvnor support is contained within its own feature. Thus, the requirement on Drools 5.4 only applies if the user wishes to install the SY Guvnor integration feature. If that is the case, they will need to install v. 5.4 of the Guvnor tooling from a snapshot build (since it is not in the nightly SOA repo). This is known and acceptable to the SY team. I guess that means yes - only Guvnor part. So yeah - makes sense drools and SY team get together and work with Douglas to enable you guys to have a more recent and actively updated set of updatesites to cross-integrate on. /max _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev