ah cool - and yeah I was wondering how the complexity of the example would fit.
Felt more like a "ticketmonster" like example.
With respect to the maven and eclipse stuff - I think those are minor issues that just
needs
to align the quickstart with an actual matching release (wether that is a beta or ga
release).
/max
On Thu, Aug 08, 2013 at 11:05:58AM -0300, Rafael Benevides wrote:
Hi all.
After some discussions we decided to move the BRMS quickstarts to the
sandbox repository for a while.
https://github.com/jboss-jdf/jboss-quickstarts-sandbox/pull/1
This will allow us to get more time to work on items like, BRMS server
setup, Maven dependencies setup, Folder structure, JBDS (items pointed
from Max), and use case scope (since these BRMS demos are more complete
-and complex- than our usual quickstarts).
After we move again on this, I'll send another email to communicate
Em 08/08/13 08:32, Eric D. Schabell escreveu:
> On Aug 8, 2013, at 11:57 , Max Rydahl Andersen <manderse(a)redhat.com> 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
_______________________________________________
jdf-dev mailing list
jdf-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jdf-dev