Since my name has been mentioned I feel obliged to wade in :-) ...
On 8/18/06, Eran Chinthaka <[EMAIL PROTECTED]> wrote:
Jochen Wiedmann wrote: > Eran Chintaka wrote: > >> 1. There are lot of non-eclipse users who are checking out/in code (FYI >> : most of the axiom devs are *not* using eclipse). So why bother we >> checking out eclipse junk :) > > Are you telling me, it disturbs you to have two additional files and a > folder, which are most possibly even hidden because of the .foo > convention? Come on this is not a valid argument. Do we put anything here as they are not visible and just few files? Its a question of whether we need them or not.
Sounds like Jochen needs them and it makes his life easier - lower barrier to setting up the project in Eclipse. If it makes Jochen's life easier it would make it easier for casual users (aka potential contributors) who happen to check out the code. If it's easy to check out and compile straight out of SVN then they might be more likely to stay. Before this discussion sinks into arguments about "well if they can't get past setting up eclipse what use are they as a contributor" which might lead to "alright lets make it really hard to set up a development environment so we only get clever contributors". We're talking about inclusivity and community development (which I'm sure none of us disagree with) ... So perhaps to draw this to a conclusion by putting in IDE specific files - we should think what is the net effect on our community committers and other developers as well as affect it has on bringing in new developers. ... I guess we all have our own opinions here.
> > >> 2. As Ajith also had already mentioned, maven helps you to generate the >> relevant IDE specific stuff. > > It does. However, the output of the plugins is far from acceptable. In > particular, the output folders will rarely match. Customizing them to your needs is that particular users problem. What sort of developers are you expecting here. Do you think they don't have the ability even to setup the project? > > Besides, there's more to it: Compiler settings (which should obviously > match those from the pom), formatting guidelines, and the like. These > aren't controlled by any plugin. I agree with this. But the option is not to commit IDE specific stuff here, rather to go and improve the relevant maven plugins. > > >> 3. Some one can declare a variable in Eclipse, pointing to his folder >> and can accidentally commit that in to svn. > > The files I have committed do not use any variables. No you didn't get my point. Having got the .project file from the svn, one might change it locally, adding variables, jdk locations. etc. The problem comes when it is committed to the code base. > > >> 4. If some one is having a customized version of .project and .classpath >> files, they always gets conflicts, which is un-necessary, IMO. > > IMO, that's a question of discipline. And, if it actually happens: > What prevents you from revoking or overwriting a commit? Again, you didn't get the point. I can remember Jeremy complained about this in commons-dev [1].
I was complaining about just the .project file ...
> > The point I am trying to make is that IDE specific files can be good > for some people. If they proove to be disturbing the projects work, > then I'd be the first to remove it. But so far I can only see a "we > don't like it" and no "look at this example, it has really done harm". > Which matches my personal experience with other projects. Please look at [1]. That will show you that its not that I don't like it, but its a problem.
I agree with Jochen on this - remove it if it causes harm. But saying that the .project was causing me harm even if it was less harm than a paper cut :-) I use Eclipse and there are some 'best practices' (whether they are written down or not I don't know) but for us in Woden it goes like this: use Eclipse variables in the .classpath then the barrier to buildling the project in Eclipse is lowered to: "set this Eclipse variable to where you have xyz installed". Just to recap the .project file problem: if my .project file needs to be different to the one on SVN (maybe I have called my project something different) then when I do an Eclipse 'Team->Synchronize' the .project file is out of sync. I can't add an svn:ignore for .project because it is already in the SVN repo. In any case, whenever you create a java project in Eclipse it creates a valid .project file for you. So unless I've missed something about what should be going in everybody's .project file ... something which would be easier if it were on the server rather than having to set it up every time you check the project out ... then I think .project should be excluded from SVN. From a selfish point of view I'm +1 for having .classpath in SVN ... if it causes others more harm than it does good then I'd reconsider.
BTW, if this is not settling up, I'd like to call for a vote on this.
IMO there's two decisions: do we allow IDE specific files, then if yes: which ones. What is the scope of this decision. The maximum scope we can decide on this list (I guess) is the ws-commons project ... does anyone feel strongly enough to push this up to [EMAIL PROTECTED] Alternatively we could just apply the decision to XmlSchema - but since we're applying so much energy to this why not open it up to all? Cheers, Jeremy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
