+1. This really puts some certainity into what actually gets deployed.
- Venkat On 5/17/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
ant elder wrote: > Ok, i re-read this last email again [1] and i guess i missed the > "...if we > could make it work consistently, with JARs as well as WARs" bit > before. I'm > not sure I agree with that, why should WARs be hamstrung with a less user > friendly way of working just because jars can't work as easily? If we can > have this really simple approach working in WARs why not support it, > its not > like jars and wars are interchangeable? > > ...ant > > [1] > http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200705.mbox/[EMAIL PROTECTED] > > A few more thoughts. I have 2 problems with this approach... but I think your requirement is very valid and I have a proposal at the end of this email :) 1. This approach doesn't work the same way in a JAR, a folder, a WAR, an expanded Web app folder. I'm looking for consistency in the programming model and any conventions we implement. We could probably get this working with a JAR if SCADomain.newInstance() could take as a parameter a class belonging to the SCA contribution which we could use to determine its location, but that would be one more option and too many options are just going to complicate the application developer's life IMO. 2. I find this approach a little too error prone and it may actually complicate my life as an app developer in some cases. Here are a few fun scenarios to illustrate that... - I could start developing a contribution and place my deployable composites at the root of the contribution, without an sca-contribution.xml. Then at some point, let's imagine that I need an sca-contribution.xml to import a WSDL or XSD for example, all of a sudden I'm going to have to list all my composites in sca-contribution.xml to get them deployed now (as the automatic deployment behavior won't be available to me anymore). So something that initially seemed simple, add an <import> of a namespace to a contribution, will actually require more significant development work. I'll have to open all composites, find their names and namespaces and spend some time in my sca-contribution.xml to declare them. - Another scenario, removing an sca-contribution.xml (because I don't need any XML imports or exports anymore at some point for example) may inadvertently expose all the .composites file at the root of my contribution as deployables. So I would have to move them out of there. - Another interesting one I think. SCA contributions can be used to package implementation artifacts, .java, .scripts, and .composites for example. Most of these contributions will not contribute any deployables, and will not contain an sca-contribution.xml. Then I would have to be really careful to not place any of these deployables at the root of these contributions, to prevent them to be automatically added to the SCA domain as deployables. All of that doesn't sound too good to me, but I don't like to write XML files either so, like you, I'd be happy to see a simple approach to just place deployable .composite files in a well known location instead of writing a page of angle brackets... Now here's an idea, which I think could give you what you're looking for: - Deployable .composite files could be placed in META-INF/sca-deployables. We will consider all the files in that folder as deployables. - This folder could co-exist with a META-INF/sca-contribution.xml, and it would be an extension of the <deployable> list in sca-contribution.xml. - This would be supported in the same way in all contribution types, JARs, WARs, folders, web app folders. We would just implement this behavior once in the ContributionService. I think this would give you what you're looking for (no XML, a convention location for deployables). It makes clear that these are deployables, doesn't generate more work, inconsistencies or surprises when you add/remove an sca-contribution.xml file. It's also easy to implement as it's very close to the previous code that we had in ContributionService which used to add all composites as deployables. Thoughts? -- Jean-Sebastien --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
