[jbosstools-dev] How old is ESB project?

[Max Rydahl Andersen]

>> What I'm trying to say here is that, the current ones (module factories) 
>> *doesnt* work ;)  It basically 100% ignore the component xml file or 
>> uses it 100% incorrectly. For example, the current esb module factory 
>> checks for one (ONLY ONE) wb-resource mapping tag. If it finds 2 
>> (because, perhaps, the user wants 2), the code simply ignores the second 
>> mapping, and takes the first.
>>   
>>     
> Why ignore the component xml file means doesn't work, in practice, the
> component.xml file
> is impossible for users to edit it manually, you are expert ;-) , you
> know about the virtual component
> model, but most of users don't know and what it is for.
>   
true, but since it is the heart of how WTP based projects are deployed it
is an rather important part to make sure it is used correctly.

Rob helped WTP finally go forward to clean up this mess that have been
created
in WTP by ignoring the good things about component.xml and the virtual
component
model - we now just need to figure out how to get to that better place.
>> Then, rather than traversing that IVirtualFolder, the factory gets the 
>> underlying IContainer object, and just scans that folder... completely 
>> ignoring the point of using the virtual component model.
>>   
>>     
> I have not investigated WTP code deep enough so I really don't find any
> guides that told me
> I must use Virtual Component to look for all related resources in module
> factory, if you are familiar
> with it, you can speak up or create a jira, rather than so easy to be
> annoyed ;-) .
>   
...sounds like you guys talk more together now you are on different
than you did the whole last year where you where next to each other ;)
> If we change it to use ComponentDeployable as module delegate, the old
> component xml file doesn't
> work, so we have think about support of old esb project.
>   
Yes, we do.

Any suggestions ? Can we support both ? Can we add a warning for users
to migrate to the new "format", have the old deprecated and then remove
in next major release ?

Note, if it is completely impossible breaking old projects (but at least
provide a migration form) I'm willing to consider when I understand the
above since JBDS 3/JBT 3.1 is the "real" release for SOA-P ...

/max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20090729/3d786a58/attachment.html