[jBPM Development] - Re: History related issues - API etc.
by sebastian.s
"Ronald" wrote :
| Just like with a release cycle people can rely upon, the should be able to rely on what will be in that release. In many projects I worked on, knowing 6 weeks before a release that certain functionality that was scheduled to be in that release will not be in it is not something I can work with.
|
Agreed. The release cycle was introduced exactly for this, to make releases more predictable (as stated by Tom in the wiki) and thus to allow end-users to plan, too.
"Ronald" wrote :
| Looking at the past releases, each time issues were slipping to the next release, it did not happen often that there was a plethora of time. So I'd like to propose two things.
| - Try to define (as good as possible, taking the above into account) plan at the beginning of e.g. release 4.3 the issues for 4.4, not plan them at the beginning (or half way as happened now) of 4.4
| - Take a little more time, so plan less 'issues'
|
Agreed. When you take a look at the great number of issues originally scheduled for a release it's alsmost clear that not all of them can be taken into account. But the decision which of them are needs to be made earlier (spoken from an enduser's point of view). This would help a lot.
The second thing which comes to my mind are priorities. I think bug fixes and basic features should have priority over completely new features. New features are great but from my point of view they don't have a great value for real world use unless basic process engine things were taken care of, especially a complete history and a fully functional variable logging.
Just my 2 cents. Have a nice day. :)
Sebastian
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267732#4267732
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267732
14 years, 5 months
[jBPM Development] - Re: History related issues - API etc.
by kukeltje
I know resources are limited, one of the few certainties in life. But...
Just like with a release cycle people can rely upon, the should be able to rely on what will be in that release. In many projects I worked on, knowing 6 weeks before a release that certain functionality that was scheduled to be in that release will not be in it is not something I can work with.
I know consultancy jobs can come unexpected, that is not the problem, just like huge internal discussions. But things like Javaworld, JBoss World, Devoxx and other converences/talks could, no *should* be taken into account when planning.
Looking at the past releases, each time issues were slipping to the next release, it did not happen often that there was a plethora of time. So I'd like to propose two things.
- Try to define (as good as possible, taking the above into account) plan at the beginning of e.g. release 4.3 the issues for 4.4, not plan them at the beginning (or half way as happened now) of 4.4
- Take a little more time, so plan less 'issues'
This would make for an even more reliable release schedule (less irritation) and might get others to step in if they think it is to long of for it to be fixed.
Ofcourse another solution would be to get more resources ;-)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267728#4267728
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267728
14 years, 5 months
[JBoss AS Development] - Jboss 6.0.M1 - BeanValidation deployer
by aslak
There seems to be a bug in the bean validator deployer filter config.
deployers/beanvalidation.deployer/META-INF/bv-core-jboss-beans.xml
When deploying a ear with a jar containing a beans.xml(CDI) this happens:
First the BeanValidator kicks in on the jar file, but not ear(due to filtering),
then WeldBoostrapDeployer kicks in on the Ear deployment.
The WeldBootstrapDeployer fails to start due to not finding the ValidatorFactory provided by the Bean Validator deployer..
The filer is defined as:
| <set>
| <value>org.jboss.metadata.ear.spec.EarMetaData</value>
| <value>org.jboss.metadata.web.jboss.JBossWebMetaData</value>
| <value>org.jboss.metadata.ejb.jboss.JBossMetaData</value>
| </set>
|
Changing it to this seems to work:
| <set>
| <value>org.jboss.metadata.ear.jboss.JBossAppMetaData</value>
| <value>org.jboss.metadata.web.jboss.JBossWebMetaData</value>
| <value>org.jboss.metadata.ejb.jboss.JBossMetaData</value>
| </set>
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267717#4267717
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267717
14 years, 5 months