OpenJPA
  1. OpenJPA
  2. OPENJPA-779

patch for eclipse .project and .classpath files...

    Details

      Description

      these are the .project and .classpath files generated by running mvn eclipse:eclipse, so that people can develop with eclipse without any further work.

      1. .classpath
        4 kB
        Milosz Tylenda
      2. eclipse.diff
        35 kB
        Fernando Padilla
      3. fix_svn_ignore.sh
        0.3 kB
        Fernando Padilla
      4. fix_svn_ignore.sh
        0.3 kB
        Fernando Padilla
      5. openjpa-formatter.xml
        26 kB
        Milosz Tylenda

        Activity

        Hide
        Fernando Padilla added a comment -

        .project and .classpath files so that people can start developing with eclipse without anymore steps..

        Show
        Fernando Padilla added a comment - .project and .classpath files so that people can start developing with eclipse without anymore steps..
        Hide
        Fernando Padilla added a comment -

        and i can even submit a patch to add the .settings directories with default code formatting rules ( so that we have consistent automatic formatting ).

        Show
        Fernando Padilla added a comment - and i can even submit a patch to add the .settings directories with default code formatting rules ( so that we have consistent automatic formatting ).
        Hide
        Milosz Tylenda added a comment -

        I think your idea of including code formatting rules is a good one. Maybe such a file for IDE or descriptive text could be also added to [1]. Currently that page only says that the project adheres to Sun's Code Conventions for the Java Programming Language. This is too generic: it does not specify tab handling, position of braces, etc. A newcomer has to investigate quite a lot if they want their patch to be consistent with the existing code. Even after such investigation, one usually makes a few mistakes.

        [1] http://openjpa.apache.org/coding-standards.html

        Show
        Milosz Tylenda added a comment - I think your idea of including code formatting rules is a good one. Maybe such a file for IDE or descriptive text could be also added to [1] . Currently that page only says that the project adheres to Sun's Code Conventions for the Java Programming Language. This is too generic: it does not specify tab handling, position of braces, etc. A newcomer has to investigate quite a lot if they want their patch to be consistent with the existing code. Even after such investigation, one usually makes a few mistakes. [1] http://openjpa.apache.org/coding-standards.html
        Hide
        Milosz Tylenda added a comment -

        I have attached a file for Eclipse code formatter I use for OpenJPA. This was created by "investigation" and may not be 100% accurate. I have created the file by doing a code formatter export from Eclipse 3.2.2.

        Show
        Milosz Tylenda added a comment - I have attached a file for Eclipse code formatter I use for OpenJPA. This was created by "investigation" and may not be 100% accurate. I have created the file by doing a code formatter export from Eclipse 3.2.2.
        Hide
        Milosz Tylenda added a comment -

        Another way of working with OpenJPA in Eclipse is to create only one project and set multiple source and library entries. I use the attached .classpath file for that.

        Show
        Milosz Tylenda added a comment - Another way of working with OpenJPA in Eclipse is to create only one project and set multiple source and library entries. I use the attached .classpath file for that.
        Hide
        Michael Dick added a comment -

        I'm opposed to putting .classpath and .project files in svn. There are multiple ways to set up an eclipse environment and (single vs multiple project for example) and I don't want to force developers down a specific path. I've already tried convincing other devs that multiple projects is the right way to go and I haven't had much luck.

        I wouldn't mind putting example .classpath and .project files on the website if people think it would help them.

        Storing a standard set of formatting preferences is a very good idea and we should add one either to svn or to the openjpa web site (maybe on the page about code formatting).

        Show
        Michael Dick added a comment - I'm opposed to putting .classpath and .project files in svn. There are multiple ways to set up an eclipse environment and (single vs multiple project for example) and I don't want to force developers down a specific path. I've already tried convincing other devs that multiple projects is the right way to go and I haven't had much luck. I wouldn't mind putting example .classpath and .project files on the website if people think it would help them. Storing a standard set of formatting preferences is a very good idea and we should add one either to svn or to the openjpa web site (maybe on the page about code formatting).
        Hide
        Fernando Padilla added a comment -

        So.. as a group we can't decide to just pick one project or many projects?? really??

        that seems like such a trivial thing that should just get decided.

        I vote for multiple projects, just because mvn eclipse:eclipse will then maintain all of the .classpath and .project for us

        But I also use other projects ( tapestry.apache.org ) that they do one large project. And really, it doesn't make a difference to me. I can easy import/delete/close/open a list of projects just as easily as I can do it for one project. The only requirement is that all sub-projects should start with the same prefix.. to be easy to find and identify within my workspace ( and we're already doing that.. openjpa-* ).

        I've asked before, but who are the active developers on the project? how can we go about getting a vote going? any new developer should just be able to svn up, eclipse import, and go!

        Show
        Fernando Padilla added a comment - So.. as a group we can't decide to just pick one project or many projects?? really?? that seems like such a trivial thing that should just get decided. I vote for multiple projects, just because mvn eclipse:eclipse will then maintain all of the .classpath and .project for us But I also use other projects ( tapestry.apache.org ) that they do one large project. And really, it doesn't make a difference to me. I can easy import/delete/close/open a list of projects just as easily as I can do it for one project. The only requirement is that all sub-projects should start with the same prefix.. to be easy to find and identify within my workspace ( and we're already doing that.. openjpa-* ). I've asked before, but who are the active developers on the project? how can we go about getting a vote going? any new developer should just be able to svn up, eclipse import, and go!
        Hide
        David Jencks added a comment -

        I'm not very involved in openjpa but...

        I use idea, I don't appreciate people forcing configuration files for other IDEs on me. Having them in a separate area from the code checkout wouldn't disturb me.

        If I did use eclipse I expect I'd use m2eclipse rather than mvn eclipse:eclipse. I haven't tried it but have the impression that it lets you open the project via the pom rather than having to run maven to generate eclipse files. I might be dreaming since this is what IDEA lets you do.

        I also doubt that such eclipse files could be kept up to date. Certainly if I contributed something to openjpa I wouldn't be able to update the files.

        Show
        David Jencks added a comment - I'm not very involved in openjpa but... I use idea, I don't appreciate people forcing configuration files for other IDEs on me. Having them in a separate area from the code checkout wouldn't disturb me. If I did use eclipse I expect I'd use m2eclipse rather than mvn eclipse:eclipse. I haven't tried it but have the impression that it lets you open the project via the pom rather than having to run maven to generate eclipse files. I might be dreaming since this is what IDEA lets you do. I also doubt that such eclipse files could be kept up to date. Certainly if I contributed something to openjpa I wouldn't be able to update the files.
        Hide
        Michael Dick added a comment -

        As developers can't we all just agree to use vi instead of emacs ?

        I don't particularly mind how the other contributors organize their IDE, or which IDE they use so long as the code builds with maven (and it works correctly). I also don't want to worry about my IDE updating it's config file to an openjpa project (ie pydev) because I added some artifact that I haven't contributed. It's one more thing I have to revert or redo before I commit.

        Is "svn up; import" that much better than "svn up; mvn eclipse:eclipse;import" ?

        WRT the maven plugin for eclipse David's right. I don't use it at the moment because it triggers full maven builds a bit too often for me (probably configurable). It also adds a custom builder to the .project file which can be a problem if .project is in version control.

        We can certainly propose a vote on the dev mailing list though. If I'm in the clear minority then we can commit the IDE specific files.

        Show
        Michael Dick added a comment - As developers can't we all just agree to use vi instead of emacs ? I don't particularly mind how the other contributors organize their IDE, or which IDE they use so long as the code builds with maven (and it works correctly). I also don't want to worry about my IDE updating it's config file to an openjpa project (ie pydev) because I added some artifact that I haven't contributed. It's one more thing I have to revert or redo before I commit. Is "svn up; import" that much better than "svn up; mvn eclipse:eclipse;import" ? WRT the maven plugin for eclipse David's right. I don't use it at the moment because it triggers full maven builds a bit too often for me (probably configurable). It also adds a custom builder to the .project file which can be a problem if .project is in version control. We can certainly propose a vote on the dev mailing list though. If I'm in the clear minority then we can commit the IDE specific files.
        Hide
        Kevin Sutter added a comment -

        I agree with Mike that we shouldn't attempt to force an Eclipse project format on the development community. But, providing more documentation and examples on how to configure Eclipse projects that support OpenJPA would be an excellent idea. Maybe we should entertain the idea of creating a separate sub-project that could contain Eclipse-specific project files and preferences. It looks like from the activity on this Issue that we have a few people interested in helping to organize this effort. Any volunteers?

        Show
        Kevin Sutter added a comment - I agree with Mike that we shouldn't attempt to force an Eclipse project format on the development community. But, providing more documentation and examples on how to configure Eclipse projects that support OpenJPA would be an excellent idea. Maybe we should entertain the idea of creating a separate sub-project that could contain Eclipse-specific project files and preferences. It looks like from the activity on this Issue that we have a few people interested in helping to organize this effort. Any volunteers?
        Hide
        Fernando Padilla added a comment -

        well, we all agree that maven is the authoritative build. But really, eclipse, intellij, netbeans and the big three IDEs, and my guess eclipse eclipses them all In our company we use eclipse and intellij, and they do not step on each others toes.

        It's the 80/20 rule, you should support what most developers are using, without making it impossible for the others to interact (.classpath/.project files do not interfere with intellij nor netbeans ).

        But anyhow, do you know how to setup a poll? Let's just ask the first question, how many people on the mailing list use eclipse..

        but if you don't want to include .classpath/.project/.settings in the svn, then you should add them to the svn:ignore (i'll put up a patch soon)

        Show
        Fernando Padilla added a comment - well, we all agree that maven is the authoritative build. But really, eclipse, intellij, netbeans and the big three IDEs, and my guess eclipse eclipses them all In our company we use eclipse and intellij, and they do not step on each others toes. It's the 80/20 rule, you should support what most developers are using, without making it impossible for the others to interact (.classpath/.project files do not interfere with intellij nor netbeans ). But anyhow, do you know how to setup a poll? Let's just ask the first question, how many people on the mailing list use eclipse.. but if you don't want to include .classpath/.project/.settings in the svn, then you should add them to the svn:ignore (i'll put up a patch soon)
        Hide
        Fernando Padilla added a comment -

        this is a small script to apply an updated svn:ignore property to project directories

        ignores: target, .classpath, .project, .settings

        (i think openjpa-slice was missing the target svn:ignore too)

        Show
        Fernando Padilla added a comment - this is a small script to apply an updated svn:ignore property to project directories ignores: target, .classpath, .project, .settings (i think openjpa-slice was missing the target svn:ignore too)
        Hide
        Fernando Padilla added a comment -

        oops, i didn't give license on the last upload, but I meant to.. so re-uploading just to be anal.

        Show
        Fernando Padilla added a comment - oops, i didn't give license on the last upload, but I meant to.. so re-uploading just to be anal.
        Hide
        Fernando Padilla added a comment -

        so, if you're going to force developers to generate all of the .classpath/.project files, can you please fix up the svn:ignore property to ignore those files? please. So that svn status will stop complaining about those extra files.. you can even add any intellij project files.. i don't know what those are.

        it's really simple, just run that script I attached and commit the changes.

        Show
        Fernando Padilla added a comment - so, if you're going to force developers to generate all of the .classpath/.project files, can you please fix up the svn:ignore property to ignore those files? please. So that svn status will stop complaining about those extra files.. you can even add any intellij project files.. i don't know what those are. it's really simple, just run that script I attached and commit the changes.
        Hide
        Michael Dick added a comment -

        I thought .* and target were automatically ignored per the Apache SVN configuration instructions [1], but it looks like I was wrong. I must have added them to my global config at some point.

        I'll go ahead and add them in the branches that I maintain.

        [1] http://www.apache.org/dev/version-control.html#https-svn-config

        Show
        Michael Dick added a comment - I thought .* and target were automatically ignored per the Apache SVN configuration instructions [1] , but it looks like I was wrong. I must have added them to my global config at some point. I'll go ahead and add them in the branches that I maintain. [1] http://www.apache.org/dev/version-control.html#https-svn-config

          People

          • Assignee:
            Michael Dick
            Reporter:
            Fernando Padilla
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development