Yeah, I guess we can do do that. .classpath and .project that would be then (as .project defines the name).
Eelco On 12/13/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
i only said removing the .classpath is not bad im definetely +1 on keeping all other eclipse files because they define our formatting, etc -igor On 12/13/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > I'm using the same workspace too, but don't commit my differences :) > > An important thing that is not mentioned here, and that was the main > reason initially to put these files in there, was that we weren't > satisfied at how checkstyle etc worked, but wanted to have a more > direct enforcement of coding style. It is just a fact that not > everyone fires up maven before committing changes all the time (often > people even forget to run the unit test, yes including me). > > If there is a way that maven generates the IDE settings with the > specific checks and style etc as part of the project, I'm +1 for > removing the actual project files. If not, I'd like them to stay as > otherwise chances are out code will get sloppier fast. > > Eelco > > > On 12/13/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > i dont mind getting rid of them, they are a headache for me cause i use > the > > same workspace unlike ya'll :) > > > > -igor > > > > > > On 12/13/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > > > > > > We have discussed this previously, the consensus was to commit > > > .classpath to cvs/svn and use project dependencies *ALWAYS*. > > > > > > However, this was before we forked into 1.x and 2.x, so perhaps we > > > should revisit this? > > > > > > I don't think so: we refactor a lot, and refactorings don't work > > > across jar files, causing a lot of headache. Not using project > > > dependencies doesn't give a good overview of the impact of a change. > > > > > > Our official stand point is and has always been: SVN is primarily for > > > Wicket committers. If anyone else wants to use it, fine, but then he > > > has to work with *OUR* rules. This means: working with maven, > > > .classpath files and project dependencies. > > > > > > Releases are agnostic and for general consumption. They always contain > > > full sourcecode, javadoc, all dependencies, a working Ant build.xml > > > and a maven pom. We don't distribute IDE files with releases (except > > > for quickstart iirc). > > > > > > Martijn > > > > > > > > > On 12/13/06, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote: > > > > * [EMAIL PROTECTED]: > > > > > Author: ehillenius > > > > > Date: Mon Dec 11 10:44:38 2006 > > > > > New Revision: 485805 > > > > > > > > > > URL: http://svn.apache.org/viewvc?view=rev&rev=485805 > > > > > Log: > > > > > fixed classpath > > > > > > > > > > Modified: > > > > > incubator/wicket/branches/wicket-1.x > /wicket-examples/.classpath > > > > > > > > Guys, are you playing the funny commit war? > > > > > > > > IMO .classpath files should be removed from the repository as > > > > every developer has different usage: one wants JAR dependencies, > > > > one wants to reference other projects in the workspace. And > > > > apparently Igor has multiple versions of Wicket in his workspace > > > > thus needs different project names, whereas Eelco has not. > > > > > > > > I removed .classpath files from wicket-stuff dojo and velocity > > > > modules, but they were committed again. > > > > > > > > Can we definitely remove those .classpath files, please? If you > > > > need to generate .classpath files, there's always the magic «mvn > > > > eclipse:eclipse» command. > > > > > > > > Cheers, > > > > -- > > > > Jean-Baptiste Quenot > > > > aka John Banana Qwerty > > > > http://caraldi.com/jbq/ > > > > > > > > > > > > > -- > > > Vote for Wicket at the > > > http://www.thebeststuffintheworld.com/vote_for/wicket > > > Wicket 1.2.3 is as easy as 1-2-3. Download Wicket now! > > > http://wicketframework.org > > > > > > > >
