On Sep 6, 2006, at 6:16 PM, Jeremy Boynes wrote:

On Sep 6, 2006, at 5:07 PM, [EMAIL PROTECTED] wrote:

Author: rfeng
Date: Wed Sep  6 17:07:19 2006
New Revision: 440909

URL: http://svn.apache.org/viewvc?view=rev&rev=440909
Log:
Replace ${sca.version} in the SCDL files with 1.0-SNAPSHOT since IDEs such as Eclipse cannot honor it.

<rant>
Specifically, Eclipse can't handle it - some other IDEs (cough) don't have that problem. The result of this is that we end up with version information referenced in many files rather than one which is not very pleasant.

We made a decision early in the project that we would not tie ourselves to one IDE but we continue to work around issues/defects with Eclipse. These workarounds are not maintainable in an open project where people are free to use different development tools as a developer has no way of knowing if a change may break someone else's tool.

Rather than continue down this path I would like to suggest that we allow IDE configurations to be checked into SVN on the understanding that they are not part of the project and that changes to the Maven build or project structure may break them at any time and that it is down to some committer using that particular IDE to make it work again.

I think this is asking for trouble for several reasons. We really should have one definitive source for the build. These artifacts are bound to break and there is no realistic way to verify that they work short of loading them in the tool they were intended for.
Alternatively, if we want to keep the policy of no-IDE-specific artifacts at all, then we should bite the bullet on workarounds and say that the Maven build is definitive and that IDE setup is the responsibility of each developer - i.e. they need to set their IDE to work with the environment as defined by the Maven build.

I prefer the current policy of having Maven categorically determine the state of the build. My opinion is we should not allow checkins of unverifiable artifacts.

Jim

</rant>
--
Jeremy

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to