[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ormf-dev] Jaxen woes
|
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