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.
I'm not sure it's definitive anymore due to all of the "hidden"
requirements you mentioned below...Hoping people keep artifacts up to
date is what I don't like as they will invariably break since they
are not verifiable.
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).
That to me just seems wrong. We chose Maven to be our build system
and we should use its features. If a particular IDE can't handle a
basic thing thing such as resource filtering we shouldn't be
restricted by that limitation as long as there are reasonable
alternatives (and there are, e.g. IntelliJ; I switched exactly
because of these types of issues :-) ). Besides, checkins have to be
run through the mvn command line build process, not through an IDE.
Jim
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
