Hi,
I don't want to play role model here, but someone has to start the discussion.
For the discussion I assume, the required changes *are* significant and cn not be done in just a couple of days (less than 5).
I for myself would normally prefer a stepwise approach instead of the big change. However, working hard and replacing lots of code just for the sake of a quick release (of which we are unsure whether we will actually reach it in time) is no real alternative. We do a lot of work, which we'll throw away to a certain degree later, we will introduce bugs, which we'll have to fix, since we have released the software and we immediately create a development branch unless we tell all users up front "Don't use it for long, we'll throw it over next month and we are not going to support you then.". Telling people that they will be spending their time on something that will change significantly in the near future will probably keep many people from trying in the first place. Which will spoil our aim of getting early and rich feedback.
I might sound a bit exaggerating, but I am sure you get the point. If we need to migrate to EMF, I would not spend a large effort on a workaround, even if this would mean a later alpha release.
Best regards,
Wolfgang
Joel Rosi-Schwartz schrieb:
Hi,
We have our first existential crisis. Our model, which is obviously core to the application, has a 100% dependence on dom4j now. The code uses xpath quite heavily and it is not realistic to keep dom4j and abandon xpath. One of the more extreme architectural changes I was going to put on the table for the mid term was to replace our entire model with an EMF model. This has some very attractive benefits to it, but it will also be a big hunk of work to bite off early.
A short term solution may be to refactor dom4j to use JAXP instead of Jaxen. The Eclipse STP <http://www.eclipse.org/stp/> project did just this to change Jdom's xpath provider. *Who is willing to take on estimating the effort to do this for dom4j?*
To share a bit of the conversation B. and I had this morning: As you know already the plan is to dump Struts and our home grown XML stylesheet (XSLT) based publishing with BIRT. Since no one has commented on my earlier thread about that, I take that as agreement ;-) Seeing as we will be creating BIRT data sources based on our schema (the XML model) it does not make a lot of sense to do that work based on the exiting model if we going to migrate to EMF.
So pretty soon we have to make fundamental decision. On the one hand we can patch up everything the best we can, e.i. fixing the xpath in dom4j, using plain old servlets instead of Struts, go to Tomcat/Jetty as a first step, etc., for the sake of an early alpha preview release. On the other hand, we can tear everything apart in one go and re-architect everything at once.
So we had all best start pondering this and it would be a good idea if we started this dialogue sooner rather than later.
All the best,
Joel
P Please consider the environment before printing this e-mail. Thank you.
http://www.etish.org http://www.eclipse.org/ormf
------------------------------------------------------------------------
_______________________________________________
ormf-dev mailing list
ormf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ormf-dev
_______________________________________________
ormf-dev mailing list
ormf-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/ormf-dev
