[jbosstools-dev] Build Question

[Rob Cernich]

> > 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.
> 
> Agreed.
> 
> > 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.
> 
> Yup - thats why I've tried rooting for getting a release train going
> of these projects but it seems like they are pulling in N different
> directions so not gonna happen without some kind of random alignment
> of the dev teams ;)

Life in the wild west. ;)

> > 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.
> 
> Yes, thats what Doug will get up and running and i've asked we get a
> basic jenkins job running which will try and use p2 director to
> install these and optimally run some basic automated tests on them
> to spot problems early on which the teams then can actively react or
> ignore ;)
> 
> > 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jbosstools-dev
> > 
> > 
> 
>