I would say that thinking about Eclipse as just one of a many IDEs that people may be using is totally off the mark. In reality, there are only a very few popular Java IDEs (two, actually), and Eclipse is the free one. So, in my opinion, not accommodating Eclipse seems ludicrous - it will inconvenience a lot of people. I would think that the more productive route would be to say that we officially support Eclipse and that we file Eclipse bug reports and/or create (temporary) workarounds to make sure that it works. Saying that people have an alternative (simply shelling out $500 for IDEA) doesn't sound very convincing to me either.
Frank. Jim Marino <[EMAIL PROTECTED]> wrote on 09/07/2006 01:08:49 AM: > >>> > >> 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
