Details
-
Type:
New Feature
-
Status:
Closed
-
Priority:
Major
-
Resolution: Won't Fix
-
Affects Version/s: 1.6
-
Fix Version/s: None
-
Component/s: Java API
-
Labels:None
-
Number of attachments :
Description
I've been moving forward on Dentaku using XDoclet2, and have come to the point that I'd like to make XDoclet2 plugins compatible with metadata provided via JMI. As you may know, the de facto interface on the MetadataProvider component for X2 is QDox, as the opaque objects that are returned by X2 QDoxMetadataProvider are QDox model elements. This means all the XDoclet2 plugins require QDox signatures to drive them, but there aren't any interfaces to do so with.
So I've generated a patch toward that end, could someone take a look at it or give me commit access so I can push them in and we can go from there? The tests run fine, but clients that create model classes on their own (generally test code) need to create *Impl classes instead.
The current X2 is revlocked to 1.4 based on the changes in http://tinyurl.com/6l5bd, and pending a better understanding of why that was done, I've reversed those changes in this patch. X2 needs to be brought up to QDox SNAPSHOT sooner than later, and it appears that there's no way get this functionality other than this reversal. I sent an email off to Mike Williams to ask him about what's going on here, but anyone can pitch in on this.
My goal with these changes are to start driving the XDoclet generators from UML metadata. It's pretty cool and I think will be a boon for the project.
thanks
Activity
Brian Topping
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Attachment | patch.txt [ 12900 ] |
The "revlock" issue should be fixed now, in CVS.
Regarding the switch to interface/impl ... I'm in favour, myself, but, this is a fairly big shift - perhaps even worthy of a new major version. Some mulling is required.
I am a bit concerned, given that part of your driver for this is to provide an alternative (JMI-based) implementation for those interfaces. QDox is not (currently) intended to provide a meta-data abstraction. If you want switchable data providers, I'd suggest it may be better to define your own set of interfaces, with bridges to concrete providers (e.g. QDOX, JMI). Or perhaps a bridge from QDox to your JMI interfaces?
Mike Williams
added a comment - The "revlock" issue should be fixed now, in CVS.
Regarding the switch to interface/impl ... I'm in favour, myself, but, this is a fairly big shift - perhaps even worthy of a new major version. Some mulling is required.
I am a bit concerned, given that part of your driver for this is to provide an alternative (JMI-based) implementation for those interfaces. QDox is not (currently) intended to provide a meta-data abstraction. If you want switchable data providers, I'd suggest it may be better to define your own set of interfaces, with bridges to concrete providers (e.g. QDOX, JMI). Or perhaps a bridge from QDox to your JMI interfaces? I'm not trying to put JMI into QDox, don't worry... 
And what I am doing is similar what you are saying at the end – a bridge from JMI to QDox. I realize what you are saying about QDox not being intended as a metadata abstraction, as what I am doing certainly starts to cement that into being, but realize that the damage has already been done here... XDoclet's QDoxMetadataProvider returns QDox model objects from opaque Object interfaces on the MetadataProvider interface. As you'll see, there isn't any way that this is going to change.
In any event, there are two solutions to being able to plug an alternate metadata provider into XDoclet. The first is to rewrite all the XDoclet plugins to use an abstracted metadata interface. This is way too much work. In some ideal world, JMI, as a JSR-standard metadata interface, would have been both provided to XDoclet plugins as well as generated by QDox itself. But the fact is, JMI is a generalist's dream and a coder's nightmare. Converting the intricacies in thousands of lines of template code, written in both Velocity and Jelly with Java support routines, would be next to impossible.
The other alternative is extracting interfaces in the QDox model and implementing them with facades or dynamic proxies on the JMI objects that I already have. There is a loose semantic coupling between the two models, and I already have dynamic proxies to wrap the JMI that comes back from the XMI parser. If these proxies could "speak QDox", an robust runtime implementation could be realized with minimal or no change to the existing XDoclet plugin source tree. But there's absolutely no way to do this as long as there are no extracted interfaces. Extracting these interfaces is an inevitablility, I've done the work, and I'd like to commit them. There's a lot of work being held up on this change.
Regarding the patch I submitted, I can regenerate the patch with the changes that I presume you committed already. There is an additional change besides the getSource, and I sent the XDoclet source reference to you in an alternate email. The changes are significant, and I spent about five hours pulling them together. But I believe the risk factor is low, since QDox clients (with the exception of test code) act as a sink for QDox objects.
I agree with you that these changes may belong in another release, but as there's no time for that in our schedule, I'd propose a fork in CVS until we can bring things back together, which shouldn't take more than an hour after a release of 1.6 is made.
Brian Topping
added a comment - I'm not trying to put JMI into QDox, don't worry... And what I am doing is similar what you are saying at the end – a bridge from JMI to QDox. I realize what you are saying about QDox not being intended as a metadata abstraction, as what I am doing certainly starts to cement that into being, but realize that the damage has already been done here... XDoclet's QDoxMetadataProvider returns QDox model objects from opaque Object interfaces on the MetadataProvider interface. As you'll see, there isn't any way that this is going to change.
In any event, there are two solutions to being able to plug an alternate metadata provider into XDoclet. The first is to rewrite all the XDoclet plugins to use an abstracted metadata interface. This is way too much work. In some ideal world, JMI, as a JSR-standard metadata interface, would have been both provided to XDoclet plugins as well as generated by QDox itself. But the fact is, JMI is a generalist's dream and a coder's nightmare. Converting the intricacies in thousands of lines of template code, written in both Velocity and Jelly with Java support routines, would be next to impossible.
The other alternative is extracting interfaces in the QDox model and implementing them with facades or dynamic proxies on the JMI objects that I already have. There is a loose semantic coupling between the two models, and I already have dynamic proxies to wrap the JMI that comes back from the XMI parser. If these proxies could "speak QDox", an robust runtime implementation could be realized with minimal or no change to the existing XDoclet plugin source tree. But there's absolutely no way to do this as long as there are no extracted interfaces. Extracting these interfaces is an inevitablility, I've done the work, and I'd like to commit them. There's a lot of work being held up on this change.
Regarding the patch I submitted, I can regenerate the patch with the changes that I presume you committed already. There is an additional change besides the getSource, and I sent the XDoclet source reference to you in an alternate email. The changes are significant, and I spent about five hours pulling them together. But I believe the risk factor is low, since QDox clients (with the exception of test code) act as a sink for QDox objects.
I agree with you that these changes may belong in another release, but as there's no time for that in our schedule, I'd propose a fork in CVS until we can bring things back together, which shouldn't take more than an hour after a release of 1.6 is made. Brian Topping
made changes -
| Status | Open [ 1 ] | Closed [ 6 ] |
| Resolution | Won't Fix [ 2 ] |
patch file for changes