I am collaborating on a git-sourced, maven-managed Java project with differing code styling preferences with users using multiple IDE's (note 1).
Is there a tool or IDE configuration that will allow code to be viewed and edited using style-1, but committed to SCM using style-2?
My research points me to 'no', but a solution combining git hooks and Checkstyle/jrefactory might be possible.
So if 'no' to above, is there a tool/process that will perform the TBD process actions below?
The checkout process flow for User1 would be:
git pull
TBD process formats code to User1 style-1
User1 works in their preferred IDE with style-1 settings
The commit workflow for User1 would be:
User1 is ready to commit/push code
TBD process formats code to standard format style-standard
git push
Note 1: multiple IDE's = Eclipse, IntelliJ, Netbeans.
Note 2: My question differs from this question in that I'd like to focus on an IDE-related solution, since forcing the minority of standards-divergent users is probably a more efficient solution.
Note 3: Acknowledging that this shouldn't be done for best-practices-reasons. However, if you grant that it's time expect more flexibility from our IDEs and SCMs, this question is intended to explore those solutions.
First of all, you really shouldn't do that. Codestyle wars are bad for any project, and it is best to decide upon one codestyle that everybody must use. It is simple to configure IDEs to automatically apply the specified codestyle at every filesave, so the developers don't have to write code in the target codestyle themselves, they can let the IDE do that for them. True, this doesn't solve the fact that they'll have to read code in a codestyle they don't yet like, but it's a lot safer than having invisible automatic code changes; that's a major source of bugs.
Maybe you can use Eclipse's code formatter from the command line to apply a different codestyle. You'd have to set up git hooks, make sure everybody has Eclipse available, and provide the proper configuration files for their preferred codestyle. You'd need hooks both for post-checkout and pre-commit, one to set up the user's codestyle, the other to commit in the central codestyle. To go one step further, you can play with the index to add the formatted code so that it doesn't include style differences in git diff (although they will show up in git diff --staged).
Again, you shouldn't do that.
I agree with Sergiu Dumitriu in this not being a very good idea. But still git provides exactly what you are looking for. Even though this will only work if your central coding style is very well defined and strictly followed. Here’s how it works:
Git provides smudge/clean filters. They allow you to pass all code through a so-called “smudge” filter on checkout and reverse that with a “clean” filter when code is added to the staging area. These filters are set in .gitattributes, and there is a repository-local version of that file available in .git/info/attributes.
So you set your smudge filter to a tool that will change the code to your personal coding style on checkout:
And your clean filter will convert the code back to the central coding style on checkin (more precisely: when file are staged):
It is very important, that smudge -> clean is a no-op / generates the original file again. Otherwise you will still check in format changes every time you change a file.
Using smudge and clean filters will retain all the functionality of git (including git diff etc). You can find the full docu in git help attributes
Related
I am looking at getting information on all the methods/function Added , Deleted and Modified between any two commits
Notes -
Code Base is in Java and on Github
Utlimate Goal - I must be able to get all the Deleted, Modified(Both source code modification and renaming of methods) and Newly added Methods between any two commits spanning across
sub-packages and classes
More pleased if full method signature
is returned along with fully qualified method name
Things I Tried
git Diff - Link - but the Diff history is huge and I'm really only interested in the changes of methods added, deleted or modified (ie in Java lists the class but not the function)
git log -L :function:path/to/file - prints the change history of that function, doesn't do what I intend to do and watchers are on a specific function but not on whole git repo. Another limitation is of getting diff between two commits.
Desired Results
Diff between any two commits should return
Methods Added ->
myMethod12 - path/to/class
myMethod34 - path/to/class
Methods Deleted ->
myMethod3 - path/to/class
myMethod11 - path/to/class
Methods Renamed ->
(Previous Name) (Revised Name) (Path)
myMethod6 yourMethod32 path/to/class
Methods Modified (source code modifs) ->
myMethod44 - path/to/class
or ideally the fully qualified method name
ie
Methods Added ->
com.example.subp.subp2.nestedpack.addMessages(Message[] msgs)
...
Git is a general tool. It does not understand your source language (in this case Java, but what if your source language were instead Swift or Python or C++ or TypeScript or, well, whatever else you can think of?). It just understands "lines of text" and has simple (or sometimes, not-very-simple) regular expressions to recognize function / method / class / other such definitions, to annotate diffs.1
To get the kind of output you want, you need a tool that does understand the language in question.
Given such a tool, you will give it:
an older version (a commit or a file from that commit), and
a newer version (another commit, or "the same" file from that commit).
It should then read those two commits' files, figure out what methods you have, and produce whatever analysis you like.
What this tool needs from Git is two versions. When and whether it can handle just getting two files, or needs two entire snapshots, depends on that tool.
The git difftool command may, or may not, be helpful for invoking this other tool. What git difftool does is compare two entire commits, then, for each differing file, feed the old and new versions of those files to another tool. You choose that second tool, from any tool you have on your computer, anywhere. Git merely invokes that tool, on the pair of files extracted from the pair of commits. If this does what you need, you're now done. If not, you may need some more steps: for instance, you might want to run git diff --raw <commit1> <commit2> and parse its output, or just git checkout each of the two commits into some temporary locations (using a temporary index for each) and work from there.
1Note that regular expressions are not capable of proper parsing; most real languages require a grammar. See, e.g., Regular Expression Vs. String Parsing. A proper CS-theoretic discussion will get into Finite State Automata but is generally off topic on StackOverflow.
First of all, git works with text and isn't responsible for indexing
your sources, searching for methods definitions, etc.
So, probably, the best solution is diff. Here is described how to use diff between specific commits.
From myself I would like to encourage you for using diff for specific file: git diff specific-file and using grep if diff is huge:
git diff | grep -e method-name -e public -e private -e void -e etc
I hope you will invent more suitable command for your goals. Good luck!
I don’t know of a tool that does exactly that.
In order to do something like that you need a Java-aware diff tool. difftastic supports Java. You get output like this (diff on some random BSD-3 licensed code):
I'm working on a selenium framework in IntelliJ. Please let me know if there is any way to know if any step is not having its corresponding step definition. Its tedious to get into each and every feature file and see whether all the steps have step definitions.
Use case : If I delete any step definition, then I should know the feature files affected due to that, without navigating to each and every feature file
Use dryRun option, instructions in StackOverflow
Download Cucumber Plugin for IntelliJ and it should help
https://www.jetbrains.com/idea/help/navigating-from-feature-file-to-step-definition.html
Also an option - RubyMine is a great IDE from the same company as IntelliJ and natively supports Gherkin/Cucumber. It marks steps that don't have matching step definitions and can auto-generate the stub for you as well. Additionally, it supports converting Scenarios to Scenario Outlines and has a feature to check your step definition Regex against a string right in the editor.
Just a few of the things I noticed when switching from Komodo the other day. Very happy with the choice. If you are developing with a company and licensing may be an issue, you may get lucky and already have the subscription that allows for using any of JetBrain's IDEs.
I'm currently using Java and I'm looking for a program that saves a new version of what I'm doing each time I compile. I don't mind if it doesn't run, I can go in and edit the class name to make it match the .java name afterwards. As I'm a beginner, I keep getting caught by overextending myself and then breaking the project I'm working on irreparably. I'm just looking for a way to go back to a safe state.
I'm sure their are programs for this, but because I don't know the collective noun for them, finding one is next to impossible.
All help is much appreciated.
What you're looking for is revision control. This works independent of the language you're dealing with, since all the VCS is concerned with is the state of the software at a particular snapshot in time.
Some recommendations:
Subversion
Git
Mercurial
IntelliJ IDEA also comes with a built-in local revision system, which allows you to visit a particular file's history. It'd still be preferable to use either Git or Subversion.
There are also sites that you can host your project on to better preserve your project, such as Github or Google Code. Github uses...Git, but Google Code will allow you to use a few others, such as Subversion and Mercurial.
Use a Dropbox folder. If you use Eclipse, just put the entire folder in the Dropbox folder, and you are set to go with a backup-ed IDE.
Added bonus: access your project from anywhere.
You could also use GitHub, but then your source code will be open to the community unless you pay for one of their "plans".
Also, consider using Bitbucket, which isn't known as well, but is free. (Thanks to A--C for that alternative to GitHub)
I need to document a Java project. I am a C# Programmer and Systems Analyst. But I am new to Java.
I have the directories checked out of SVN.
These directories include the source directories, WEB-INF and other files required for definition of the project, classpath etc.
I understand that the files essentially belong either of the following three categories
Source code files / directories that are based on the way the packages are structured (.Java)
Directories / Files required for project definition, compiler settings etc
Files required for deployment.
The project is (as most Java projects are) an Eclipse based project designed to be hosted on Tomcat.
Now, give the above information I have decided to document the entire project into three different documents
A document explaining the source code etc.
A document explaining the purpose of the files & directories that are required for compiler settings, project definitions etc
A document that explains the deployment directory structure.
Or alternatively I could create a single document with three sections that explain 1-3 above.
Now, questions
Is this the right approach?
Are there any other methodologies that I can follow or borrow from?
Are there any other suggestions etc that you can add to this approach
Any additional info will be of use.
Thanks a ton in advance
I think you're on the right track. In a project you need to address three documentation needs
User Documentation
This include a document stating what the application is about, and how to start it/access ut.
Development Documentation
This includes at least the Javadocs, a description of the source code directory structure, the build process (ie, how to compile the project), compiler time dependencies, development standards, how to set up a database for development, and how to get the source code from the repository. These are the minimum you need to get others to work in your project. Additionally as the project complexity grows I like to put together a series of "How To" for common tasks in the system (ie: "How to leave an Audit Trail for a given Operation", "How to use the Logging framework", "How to manage exceptions", etc), a description of the main Domain classes and their relationship. If you use a database, and the database schema is not exactly one-on-one with the domain classes, I'll add a schema documentation.
Deployment Documentation
This is basically the installation manual of the application, describing any steps needed to make it run: putting the WAR in Tomcat, running scripts against a database, configuration files that needs to be modified, etc,etc.
As you see, you already partially addressed two of them. Start small and simple, and add the rest as the need arises.
It also helps to check if your organization has any documentation standard.
Try Javadocs link. Written with proper planning, it will address all your points above.
A document explaining the source code etc.
Yes. Approach this as if your reader was someone trying to get familiar with the reasons why the project was written (why was this project created), as well as the overall architecture of the project.
The Javadocs on the source classes should explain what each class does. Your document should tie the Javadocs together, like a tutorial.
A document explaining the purpose of the files & directories that are required for compiler settings, project definitions etc.
Yes.
A document that explains the deployment directory structure.
I suppose that's what your build scripts do. Perhaps I don't understand what you expect this document to accomplish.
Are there any other suggestions etc that you can add to this approach
Unless this is the first time anyone in your development group has documented a Java project, there should be other documentation. See what they've done.
If you are the first, then I'd say this was a good start. I'd be most interested in the first document. Your new programmers would like the second document.
I want to know If there are any plug-ins or tools to see the files commited to the subversion by date and committer.
we are using subversion. It will be nice, If its like a web app.
Please suggest If there are any other alternative ways to do this also.
Its for my manager. So cannot be through eclipse. :)
websvn offers a nice access to svn via web.
It offers RSS feed support so your boss gets notified on every commit.
As a commercial tool fisheye might be worth a look.
Have you tried displaying the SVN log, using any SVN client (like TortoiseSVN, I guess your PHB is using Windows)? You can easily see the time, comments and author of any given SVN commit there...
See:
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-showlog.html
Since TortoiseSVN integrates nicely into Windows Explorer, even your manager should be able to use it...
That being said, it's trivial to access the log information, for example using pysvn, and displaying it in a simple GUI, if selecting and opening the revision log via the context menu is asking too much in your given use case...
You can also take a look at svnmonitor. It will keep checking for new changes, and notify the user (this can be configured)
Trac is a wiki and issue tracking system that works well with subversion. As an example, click on the project's Browse Source link.