Re: svn commit: r431432 - /webservices/commons/trunk/modules/XmlSchema/.classpath
Dennis Sosnoski wrote: > How about because it creates major difficulties for other developers on > the same IDE who don't happen to use your conventions? This also creates > a problem with keeping everything up to date - how are developers who > don't use a particular IDE supposed to check that the files are still > correct after making changes (which may include changes to the actual > directory structures and such). > > I think it's a great idea to have IDE-specific project files available - > but don't put them in the root directory of the SVN image. Instead, set > up a subdirectory for the IDEs. That way you can update them whenever > you change your instance of the project, but other users are only > effected if they copy the files out of the subdirectory. Would you have > any objection to a subdirectory for IDE files, Eran? I prefer if we do not have any IDE specific stuff at all. But having considered Jeremy's comments on to make the life easier for new programmers, I +1 for the compromisation made by Dennis :) -- Chinthaka signature.asc Description: OpenPGP digital signature
Re: svn commit: r431432 - /webservices/commons/trunk/modules/XmlSchema/.classpath
How about because it creates major difficulties for other developers on the same IDE who don't happen to use your conventions? This also creates a problem with keeping everything up to date - how are developers who don't use a particular IDE supposed to check that the files are still correct after making changes (which may include changes to the actual directory structures and such). I think it's a great idea to have IDE-specific project files available - but don't put them in the root directory of the SVN image. Instead, set up a subdirectory for the IDEs. That way you can update them whenever you change your instance of the project, but other users are only effected if they copy the files out of the subdirectory. Would you have any objection to a subdirectory for IDE files, Eran? - Dennis Jochen Wiedmann wrote: Eran Chinthaka wrote: > Can we please not commit IDE specific stuff in to the code base. Why not? I'm always glad if I do checkout stuff and it is immediately ready for use. And I can't find that it disturbs other users? Jochen - 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]
Re: svn commit: r431432 - /webservices/commons/trunk/modules/XmlSchema/.classpath
Hi Jochen, Jochen Wiedmann wrote: > > Eran Chinthaka wrote: > >> Can we please not commit IDE specific stuff in to the code base. > > Why not? I'm always glad if I do checkout stuff and it is immediately > ready for use. And I can't find that it disturbs other users? I object this for couple of reasons. 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 :) 2. As Ajith also had already mentioned, maven helps you to generate the relevant IDE specific stuff. 3. Some one can declare a variable in Eclipse, pointing to his folder and can accidentally commit that in to svn. 4. If some one is having a customized version of .project and .classpath files, they always gets conflicts, which is un-necessary, IMO. 5. None or most of the WS project do not have IDE specific committed so far. Eg : Axis2, axiom, neethi, etc., Hope those reasons will help to justify not to commit IDE specific stuff in to the code. -- Chinthaka signature.asc Description: OpenPGP digital signature
Re: svn commit: r431432 - /webservices/commons/trunk/modules/XmlSchema/.classpath
Hi all, This is a somewhat sensitive issue since there are conflicting views here. My personal view is that we should not check in any IDE specific stuff. The build system is maven and maven lets you create the necessary project files if needed (both Eclipse and Idea). Otherwise users are free to have their own taste of IDE in any manner they want. Ajith On 8/16/06, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: Eran Chinthaka wrote: > Can we please not commit IDE specific stuff in to the code base. Why not? I'm always glad if I do checkout stuff and it is immediately ready for use. And I can't find that it disturbs other users? Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r431432 - /webservices/commons/trunk/modules/XmlSchema/.classpath
Eran Chinthaka wrote: > Can we please not commit IDE specific stuff in to the code base. Why not? I'm always glad if I do checkout stuff and it is immediately ready for use. And I can't find that it disturbs other users? Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r431432 - /webservices/commons/trunk/modules/XmlSchema/.classpath
Can we please not commit IDE specific stuff in to the code base. Thanks, Chinthaka [EMAIL PROTECTED] wrote: > Author: jochen > Date: Mon Aug 14 13:44:03 2006 > New Revision: 431432 > > URL: http://svn.apache.org/viewvc?rev=431432&view=rev > Log: > src/test/java is being compiled to target/test-classes in Eclipse. > > Modified: > webservices/commons/trunk/modules/XmlSchema/.classpath > > Modified: webservices/commons/trunk/modules/XmlSchema/.classpath > URL: > http://svn.apache.org/viewvc/webservices/commons/trunk/modules/XmlSchema/.classpath?rev=431432&r1=431431&r2=431432&view=diff > == > --- webservices/commons/trunk/modules/XmlSchema/.classpath (original) > +++ webservices/commons/trunk/modules/XmlSchema/.classpath Mon Aug 14 > 13:44:03 2006 > @@ -1,7 +1,7 @@ > > > > - path="src/test/java"/> > + >path="org.eclipse.jdt.launching.JRE_CONTAINER"/> >path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"/> > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > signature.asc Description: OpenPGP digital signature
