> I'd like to make changes to an ESB project's structure and I want to see > if everyone here is on the same page. > Did you get any answers to this ? btw. I don't understand what the age of ESB projects has to do with your question ? Your suggestion is how it should work even for components.xml in old versions of WTP, right ? > <wb-resource deploy-path="/" source-path="/build/classes"/> > > I want to see if anyone feels one way or the other about this. It would > make our module factories cleaner and less error prone. Thoughts? > But isn't this opposite to how everything else works in WTP currently, right ? Or? /max

But isn't this opposite to how everything else works in WTP

That has nothing to do with age - no matter if it was in JBDS or just

Your suggestion is how it should work even for components.xml in old

> The age of the project type is relevant because if it's a young > project and has not made it into JBDS yet, then we can change this > project structure without worrying about converting old users to the > new structure. If the structure is old and has made it into JBDS than > such conversion would be necessary. That has nothing to do with age - no matter if it was in JBDS or just jbt it was released into a GA release long time ago (both JBT and JBDS). But isn't this about *new* esb projects ? the module factory would still just have to do its thing it is told based on the components file, is it not ? > > And no I did not receive an answer. You received my answer, and you didn't answer my questions ..? :) /max > > Max Rydahl Andersen wrote: >>> I'd like to make changes to an ESB project's structure and I want >>> to see >>> if everyone here is on the same page. >> Did you get any answers to this ? >> >> btw. I don't understand what the age of ESB projects has to do with >> your question ? >> >> Your suggestion is how it should work even for components.xml in old >> versions of WTP, right ? >> >>> <wb-resource deploy-path="/" source-path="/build/classes"/> >>> >>> I want to see if anyone feels one way or the other about this. It >>> would >>> make our module factories cleaner and less error prone. Thoughts? >>

Rob - this specific feature were spec'ed out to be so it worked as WTP does it so we would be sure it would work (equally bad/well). If that was not done then its up to the dev(s) working on it to speak up and say "heeey! This won't work!". That have happend on occasion and then we have pulled it from a release. If you think stuff is missing, then speak up - but be specific (as you are in this email)

you are saying remove the old line and add in the new one! Will both lines work in WTP today ?

i.e. is it just a matter of changing the new XYZ wizard and then the new projects will be better and the old one continues to work ?

Or are you saying lets stop supporting the old lines in components.xml, meaning our projects won't work with any modulefactories/server adapters than ours ?

i.e. as far as I understand what you are suggesting doesn't break anything (just changes how new projects are defined), but you write as if it will break stuff ?

Rob Stryker wrote: > Max Rydahl Andersen wrote: > > >> Rob - this specific feature were spec'ed out to be so it worked as WTP >> does it so we would be sure it would work (equally bad/well). If that >> was not done then its up to the dev(s) working on it to speak up and >> say "heeey! This won't work!". That have happend on occasion and then >> we have pulled it from a release. If you think stuff is missing, then >> speak up - but be specific (as you are in this email) >> >> > We cloned the WTP structure but never completed a module factory for any > of our projects yet, at least not a real one. We can't extend their jee > module factories because they're way complex and many parts don't apply > to us. Fact is we *can't* use their module factories as their module > factories simply refuse to turn our projects into modules. Basically, > our ESB project has had a tiny shell of a module factory and our BPEL > one is just really really weird. > > It doesn't have to do with the structure, either. It's just that their > module factories check specifically for JEE facets and refuse to handle > projects that are not JEE projects. > > > >> you are saying remove the old line and add in the new one! Will both >> lines work in WTP today ? >> >> > Yes I'm saying remove the old line and add the new one in the ESB > project. However, today, none of our module factories even look at the > virtual component model. It's basically 100% irrelevent. The BPEL > project is not a modulecore project, and the ESB project's module > factory 100% ignores the virtual component and doesn't traverse it > pretty much at all. > > >> i.e. is it just a matter of changing the new XYZ wizard and then the >> new projects will be better and the old one continues to work ? >> >> > 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. I admit that it really is a bug for only handling one wb-resource mapping, I appreciate if you can create a jira or let me know when you find a bug or something doesn't work. > 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 ;-) . I tried to use ComponentDeployable as ESB module delegate, so far, it works fine, it might work like what you said, using virtual component to get which resources will be deployed, not sure if it would absolutely work for ESB deployment since I can't read all its code, I will do some more tests. 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. Denny > > >> Or are you saying lets stop supporting the old lines in >> components.xml, meaning our projects won't work with any >> modulefactories/server adapters than ours ? >> >> > First and foremost, we can't use WTP's module factories. Their factories > refuse to look at our project bc we're not JEE projects. > Secondly, the module factory is what takes a project (or other module) > and turns it into the servertools API so server adapters can consume it > and publish it. I'm not suggesting making our projects unconsumable. All > server types who want to will be able to consume what we give them. That > will not change. > > I'd also like to note that I am not suggesting changing dynamic web > projects or ejb projects at this time. I am talking only about our > project types for which we control the module factory. If we control the > mod-factory, and we control the project, we can decide how we want to > use our components.xml file. But I am also not suggesting any radical > changes here. > > What I am suggesting is to change how we interpret the "old lines". If > a components.xml file says map Project/src to WEB-INF/classes, I'm > suggesting we interpret that 100% literally... and we put .java files > inside their WEB-INF/classes folder. > > What this means, though, is that old projects which map Project/src to > WEB-INF/classes (rather than mapping Project/bin to WEB-INF/classes) > would need to be changed, either automatically by us or by the user > themselves in that new mapping UI i've been making. It also means we'd > need to make the default mapping be from bin rather than from src, if > that makes sense. > > > >> i.e. as far as I understand what you are suggesting doesn't break >> anything (just changes how new projects are defined), but you write as >> if it will break stuff ? >> >> > Yes... what would break is old projects would need to make a quick > change and stop mapping src to / and change it to mapping bin to /. > Otherwise they'll end up with java files (src) in their .esb output file > root rather than .class files. Make sense? We'd still need to fix their > project for them, or them for themselves, but the fix would be really > really easy in the mapping UI. Just remove the src mapping and add the > bin mapping. > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > >

Max Rydahl Andersen wrote: > Rob - this specific feature were spec'ed out to be so it worked as > WTP does it so we would be sure it would work (equally bad/well). If > that was not done then its up to the dev(s) working on it to speak up > and say "heeey! This won't work!". That have happend on occasion and > then we have pulled it from a release. If you think stuff is missing, > then speak up - but be specific (as you are in this email) We cloned the WTP structure but never completed a module factory for any of our projects yet, at least not a real one. We can't extend their jee module factories because they're way complex and many parts don't apply to us. Fact is we *can't* use their module factories as their module factories simply refuse to turn our projects into modules. Basically, our ESB project has had a tiny shell of a module factory and our BPEL one is just really really weird. It doesn't have to do with the structure, either. It's just that their module factories check specifically for JEE facets and refuse to handle projects that are not JEE projects. > you are saying remove the old line and add in the new one! Will both > lines work in WTP today ? Yes I'm saying remove the old line and add the new one in the ESB project. However, today, none of our module factories even look at the virtual component model. It's basically 100% irrelevent. The BPEL project is not a modulecore project, and the ESB project's module factory 100% ignores the virtual component and doesn't traverse it pretty much at all. > i.e. is it just a matter of changing the new XYZ wizard and then the > new projects will be better and the old one continues to work ? 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. 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. > Or are you saying lets stop supporting the old lines in > components.xml, meaning our projects won't work with any > modulefactories/server adapters than ours ? First and foremost, we can't use WTP's module factories. Their factories refuse to look at our project bc we're not JEE projects. Secondly, the module factory is what takes a project (or other module) and turns it into the servertools API so server adapters can consume it and publish it. I'm not suggesting making our projects unconsumable. All server types who want to will be able to consume what we give them. That will not change. I'd also like to note that I am not suggesting changing dynamic web projects or ejb projects at this time. I am talking only about our project types for which we control the module factory. If we control the mod-factory, and we control the project, we can decide how we want to use our components.xml file. But I am also not suggesting any radical changes here. What I am suggesting is to change how we interpret the "old lines". If a components.xml file says map Project/src to WEB-INF/classes, I'm suggesting we interpret that 100% literally... and we put .java files inside their WEB-INF/classes folder. What this means, though, is that old projects which map Project/src to WEB-INF/classes (rather than mapping Project/bin to WEB-INF/classes) would need to be changed, either automatically by us or by the user themselves in that new mapping UI i've been making. It also means we'd need to make the default mapping be from bin rather than from src, if that makes sense. > i.e. as far as I understand what you are suggesting doesn't break > anything (just changes how new projects are defined), but you write > as if it will break stuff ? Yes... what would break is old projects would need to make a quick change and stop mapping src to / and change it to mapping bin to /. Otherwise they'll end up with java files (src) in their .esb output file root rather than .class files. Make sense? We'd still need to fix their project for them, or them for themselves, but the fix would be really really easy in the mapping UI. Just remove the src mapping and add the bin mapping.