On Sep 8, 2006, at 9:28 AM, Raymond Feng wrote:
Hi,
I'm a loyal Eclipse user (never have a chance to try IDEA) and let
me try to be constructive here.
Thanks - I appreciate the constructive comments :-)
What are issues here due to the conflict of maven and Eclipse? I
observed two:
a) Cannot use the root folder to host NOTICE, LICENSE and other files
b) Cannot automatically replace a maven property in resource files
such as SCDL
Issue a) is due to a limitation in maven-eclipse-plugin and it's
not an Eclipse problem. Eclipse does support overlapping source
folders with inclusion and exclusion patterns.
Solution: Open a JIRA against the maven-eclipse-plugin to get it
fixed. I read the source code, it's fairly simple. If time permits,
we can provide a patch.
I think this is the ideal solution but requires someone to maintain
the plugin. We still have the lag factor where some change gets made
in the build that the plugin can't handle. People can always fine-
tune the IDE setup once generated (I do that with IDEA for example)
and so the question becomes is it worth checking in the generated
artifacts to help people along (or is it even practical e.g. if they
contain absolute paths there may be problems).
Issue b): The purpose is to make it easy to keep the namespace
synchronized with the Tuscany version. I don't think the maven-
filtering is a complete solution because we still hard-code the
namespaces in the loaders anyway.
Solution: Hard-code the namespace in SCDL files for now and use the
powerful IDE "replace" function to change all the occurences when
we're ready to move up to a newer Tuscany version. :-)
I am very wary of global "replace" approaches as they so often go
awry which is why I was looking at a substitution approach in the
first place :-) At some point we will need to support multiple schema
versions in the loaders and so may need to cherry-pick which ones get
"fixed". We may also have different versions in different extensions,
again requiring a selective approach.
Also this is only one value that is being substituted. We do perform
substitution in other places but so far that is mainly for
documentation (e.g. in the NOTICE files). The "replace" approach will
not scale as we increase the number of variables.
Any other issues?
This is what is troubling me - I don't know. It means any change that
I (the de-facto build monkey) make has the potential to break an
Eclipse setup that I know nothing about. I'm not very comfortable
with that.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
