Re: [jdf-dev] [BRMS Quickstart] - Sandbox

On Aug 8, 2013, at 11:57 , Max Rydahl Andersen <manderse(a)redhat.com&gt; wrote: > On Tue, Aug 06, 2013 at 02:31:44PM +0200, Eric D. Schabell wrote: >> https://github.com/eschabell/brms-customer-evaluation-demo/blob/master/Qu... >> https://github.com/eschabell/brms-rewards-demo/blob/master/Quick%20Start%... >> https://github.com/eschabell/brms-coolstore-demo/blob/master/Quick%20Star... > Thanks, and now github stopped showing angry unicorns so I can actually see the examples. > > First of, i'm all for getting more examples in, but I'm also really not a fan of handing out instructions/urls that is known to be bad/too temporary. > > But lets see what we can do about them - if this just stays in the sandbox and are clearly marked experimental I don't have a problem, having it available is better than to hide it completely. > > Non-stable plugin updatesite url > ================================ > > First issue is the use of http://download.jboss.org/jbosstools/updates/integration/kepler/integration- > stack/aggregate/4.1.0/ as the updatesite url to add. This url is *not* a stable url and will not be guaranteed to exist nor contain what will work with your examples. I've asked SOA tooling guys to provide a stable url for community usage but that have not happened yet and thus i'm stuck waiting for them to release a JBDS 7 update url. > This is what is available and what we have to use. > Besides the url being non-stable it definitely should not be used together with JBDS 5 and 6 since if you add this updatesite to JBDS 5 and 6 and you run Help > Update it will pick up newer versions of eclipse/jbds which probably is *not* what the user wanted/expected. (note, the instructions just seem to talk about JBDS 7so thats fine, just referring to you saying it works on JBDS 5 and 6 too). > The demo project is around so long that we have moved (see releases) through JBDS 5 to 7 now. > Finally, that url contains *more* than what is supported - i.e. savara tooling is not a supported tech yet. It's the community version as opposed to the supported version. > Nothing I can do about that. > Non-clean pom versioning > ======================== > > Second issue is that the GAV's seem to be using the BRMS version for the jars instead of the actual base community version of the jars. > i.e. 5.3.1.BRMS seem to be the base for all in here but org.drools and org.jbpm wasn't released under a 5.3.1.* version afaics. > I am only interested in providing products, this is JBoss BRMS. The upcoming versions are supposed to start supplying maven artifacts into the central jboss repos, but until then, this is the pragmatic solution we have chosen after discussions with jBPM / Drools teams. > Can't these be updated to actually use the proper versions following the Project Wolf guidelines ? > Nope. > Note: if jbpm and drools actually released 5.3.1 and that is what BRMS 5.3.1 is based on then we are all good - but that is just not > my understanding on how BRMS was built, i.e. jbpm was 5.2.x and drools 5.3.x (according to Julien from productization) > The primary goal is to use these in the field, allowing them to demo products which we are trying to sell. The idea of GoldenGate, as preached to me, is to propogate early access to products and not projects. If this is not the case, then you will not want to be reviewing my demos for usage. Having worked with drools and jbpm in an enterprise, I don't even want to try and keep Integration & BPM projects aligned and working with the diverse components that are merged into the JBoss BRMS / BPM Suite products. These demos are specific examples of how to get things done, in JBDS with BRMS plugins as available, on EAP versions. You can't sell what you are describing here above, so no point in my moving from products over to project components. -- erics