I was assuming we would check in one "default" configuration. There's nothing preventing people from running maven eclipse:eclipse or manually changing them in their own environments. We wouldn't want people to accidentally check their changes back in so we'd probably want them on the svn:ignore list.
I wasn't really implying that we need to have a policy that every Tuscany project include IDE files. I was really just wondering if it would be acceptable to allow such files to be checked in to any of the projects. For SDO, for example, the two projects that I know are currently being reused by other projects (in isolation) are sdo-api and sdo-lib. Having Eclipse files for just those two would be helpful. Frank. [EMAIL PROTECTED] wrote on 06/14/2007 05:14:44 AM: > Right thats the problem isn't it. If we check in the IDE files in we're > assuming one particular way of using the code. For the SCA project which is > quite big i've several different workspaces - one with every thing including > modules, samples and itest, another workspace just with modules, and another > just with samples etc. That wouldn't work with the IDE files checked in as > I'd have to change them for the the different workspaces and then when doing > checkin's try real hard to not accidentally commit my local changes to the > IDE files which would be a real pain and almost certainly quite often happen > by accident. > > ...ant > > On 6/14/07, kelvin goodson <[EMAIL PROTECTED]> wrote: > > > > There's pain in the process, not huge, but irritating > > > > first off there's the definition of the M2_REPO variable, not a huge > > problem, especially if you stick to just one workspace. I tend to create > > workspaces as and when I need them, and I can't see how to make my variable > > definition cross multiple workspaces. > > > > Next, and probably more significant is removing the binary dependencies > > and setting up inter project dependencies. After the maven eclipse:eclipse > > command for example, the tools project depends on the binary artifacts > > generated from the maven build of the impl, lib and api projects . What > > most developers are going to want is inter project dependencies. So there's > > quite a bit of manual deletion of jars from the class path entries, then, > > you might want for example the lib project to expose the api projects > > interface, etc. etc. > > > > I'm quite well practised at setting this up, but its still a 5 minute > > job. > > > > Regards, Kelvin. > > > > On 14/06/07, ant elder < [EMAIL PROTECTED]> wrote: > > > > > > On 6/14/07, Frank Budinsky < [EMAIL PROTECTED]> 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? > > > > > > > > > AFAIK there's no 'rule' that says this must not be done. However no > > > other > > > Apache (or non-Apache) project that i can think of does this so it would > > > be > > > unusual and that makes me wonder why. > > > > > > Is it just the extra "mvn -Pelcipse eclipse:eclipse" thats the problem > > > or is > > > there something else about it thats a pain? (Also we may be able to get > > > rid > > > of the '-Peclipse' bit now if that would make it easier to bare? > > > > > > ...ant > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
