Jean-Sebastien Delfino 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?
I added the logic to handle this in revision r538820. It's harmless, if
people don't like that convention we don't have to follow it, but if we
like it, it's now implemented.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
