-
1. Re: removing the sar packaging
aguizar Sep 26, 2006 3:23 PM (in response to tom.baeyens)There are a number of features we'd lose: the managed lifecycle, the nice packaging of libraries and configuration files. Not to mention consistency with the deployment model of other JBoss products (JBossWS for instance) or the clean report of missing dependencies (e.g. the datasource).
For someone who is used to these features, this will be a bad surprise. Why not retain the convenience of the service archive until the JCA-based alternative becomes available? -
2. Re: removing the sar packaging
tom.baeyens Sep 26, 2006 3:45 PM (in response to tom.baeyens)i don't think we currently use or need managed lifecycle. the thing that we might use eventually is have a convenience for verifying and optionally creating the database upon start of the sar. but that would equally be possible with a static singleton pattern.
i disagree with the nice packaging of configuration files. it's for the sar that we have to wrap the configuration files in a jar file. i would prefer them to be easier editable. (not in a jar file).
i'm not yet convinced on the consistency argument. while that is true from a jbossWS standpoint, i think that common knowledge is more important. average developers know how .war's and .ears are composed. but they typically don't know how a .sar works.
missing datasource will also be reported in case of static singlton instance.
overall, i'm just in the middle, i think. no necessity to keep it in, and not a big issue to take it out.
I didn't really specified my main argument, which is simplification of the deployment model. Reduce jBPM maintenance and reduce the ways how our users can screw up.
would you have a problem with accessing jBPM through the static singleton ? -
3. Re: removing the sar packaging
aguizar Sep 26, 2006 5:04 PM (in response to tom.baeyens)Not at all. Providing a simple, unique, portable deployment model is a good idea.
I'd like to see a model where adding bpel capabilities to a jbpm installation only required throwing in the bpel jar. The hibernate configuration is an issue. Isn't there a way to discover mapping files automatically? It'd be great if users could only specify the connection properties and let Hibernate find the mapping resources.
Suddenly I'm starting to like this 'return' to the jBPM-as-a-library-only concept. -
4. Re: removing the sar packaging
tom.baeyens Sep 27, 2006 7:56 AM (in response to tom.baeyens)i believe we should go for 2 default deployments: 1 ear file to deploy bpel and one ear file to deploy jbpm. both of these could optionally also be offered as web archives.
hibernate configurations will always have to be separate for jpdl as for bpel. so we can't offer a drop-in type of addition to enhance a jpdl to a bpel. it will always have to be a replacement. but since bpel > jpdl, this should be easy.
but we should minimize the number of variations that we offer.
the jboss packages will already have to be customized to jboss, since jboss has got hibernate in it's global class path.
so i would pick one type of package .ear or .war and use that as the default distribution package. then describe how to tweak the libs in case of deployment on other servers. then describe how to make .sar or other packages from that. optionally supported by means of ant scripts.