On Sep 6, 2006, at 8:18 PM, Jim Marino wrote:
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.
There is still only one definitive build - the Maven one. All the
others are just (unverifiable) artifacts that may work for some
developers. The compensating factor here is that presumably some
active developers are using them and will keep them current and working.
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.
The problem is that we have requirements on checked in artifacts (the
Maven POM's) that are not verifiable using the Maven build -
requirements such as we can't use Maven's resource filtering because
Eclipse also copies resources and does not filter them, or Eclipse
cannot support the resource paths that Maven uses. There may be
others (for example, I don't know how or if Eclipse recognizes code
generated as part of the Maven build).
This means people can make improvements to the build or project
layout that are fine with Maven and the definitive build but which,
for some reason, make Eclipse unhappy.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]