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]
