Sounds good to me,  we'd just have to make some decisions about the nature
of the classpath entries. I would assume that for the api, lib, impl, tools
and plugins projects we would set up inter-project dependencies,  but what
would we do about classpath entries for binary artifacts such as EMF?  The
current way we describe relies on a local maven repository,  but it would be
nice not to have to assume that the user has maven.  It would also be nice
not to have lots of red error markers over the eclipse workspace indicating
that the 3rd party dependencies need resolving. Are we allowed to put binary
3rd party dependencies into svn?

Kelvin.

On 14/06/07, Mike Edwards <[EMAIL PROTECTED]> wrote:

Frank,

I'm of the opinion that anything that makes it easier for developers to
get to grips with our stuff, the better.  Personally, having to to
create all the Eclipse stuff has been a pain, so doing this would save
me time and effort.

I agree with your sentiment that if others want to add features for
other IDE's then that should be OK too.

Yours,  Mike.

Frank Budinsky wrote:
> Hi,
>
> I remember about a year ago discussing whether or not it is
> acceptable/appropriate to check-in IDE specific files (e.g., Eclipse
> .project files) into svn, and we decided to not do it. Does anyone
> remember if this was really an Apache policy, or just a decision we made
> for Tuscany? If the latter, I wonder if we should reconsider.
Personally,
> I think it would be very convenient if we had the Eclipse .project and
> .classfile in the projects, so that people could just check out Tuscany
> projects directly into Eclipse. For people not using Eclipse, having
these
> superfluous files around really doesn't seem like a big deal. I also
> wouldn't mind if someone wants to check-in other IDE (e.g. IDEA) files
> that Eclipse users (like me) would just ignore.
>
> What do others think about this?
>
> Thanks,
> Frank.
>
> ---------------------------------------------------------------------
> 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