When developing on my local, I would like to automatically commit all outstanding changes to Git every time I republishing my web project in Eclipse. This way I can get a good view of the steps that I took in my development activities. I will of course rebase before pushing to the public repository. I only want to use this for local history.
Some details:
Eclipse
Weblogic 10.3.5
Web Project
I am looking for a solution that will not require me to change the project itself, so any solution that requires changes to my Servlet class, or to the web.xml will not be satisfactory, although I guess I can do that as a last resort.
Additional Information
I have found that there is a Builders section under a project's properties. This can be configure to do whatever I want, but the only options seem to be to ether run it when manually building, during or after a clean (all of which will not commit often enough), or after an automatic build (which happens every time I save a file, making it way too often too be useful).
automatically commit all outstanding changes to Git every time I republish my project.
"Automatically" and "outstanding changes" cannot coexist in the same sentence without some details about the criteria which would define an "outstanding change": an "automatic" process wouldn't know when a change is supposed to be outstanding or not.
That means an "on demand" process might be easier to implement, and call when needed.
Plus the commit message might be important to refine, as it is a big part of having a "good view of the steps that I took in my development activities."
Whatever the Eclipse project is (here a WebLogic one), that process might simply be doing a add/commit through:
EGit commands (manually called through the EGit GUI, in order to fill-in a meaningful commit message)
or a script, and which would allows (if needed) for a post-commit hook to push that commit to a remote hosting service (like GitHub for instance), since the same commit with EGit would not trigger the post-commit hook.
Since this is supposed to be fully automatic, the other approach would be to use an ant script to trigger the "redeploy" of the weblogic app.
See for instance "Weblogic hot deployment during development (like WSSD/RAD)".
That ant script (using a wdeploy ant task) could then make sure the redeploy target depends on another ant target which would commit and push first (like in this gist).
Related
We have over 100 build configurations in Team City, and I've come to realize over the past few months that these assets are just as important (if not more so) than the actual project assets (code, config, etc) we are delivering.
To that end, I know TC provides it's own build configuration version control but to me that seems a bit low on features - for example if a build stops working it would be really good to be able to diff the actual XML build configurations in my favorite diff tool rather than rely on TC's built in one, or to be able to view differences across a longer time frame than simply against the previous state.
Obviously this can be handled manually by extracting the build definition and committing, and then applying self disciple to always do this when you change the definition. Can anyone suggest a more joined up approach? We're using TeamCity Enterprise v8.0.5
Can you upgrade to TeamCity 9? TeamCity now has built in support to sync the build configurations to Git or Mercurial.
https://www.jetbrains.com/teamcity/whatsnew/
https://www.youtube.com/watch?v=zTLeCrdxGIw
As an interim solution before you upgrade to TeamCity 9, you could write a scheduled job to run every 10mins (or even every minute) and automatically commit the changes to a new repository. I'd use a new repository so TeamCity doesn't ever try and trigger off the commits.
I don't know what OS or VCS you are using, but you'd just need to commit all XML files so you get project-config.xml, build type XML, and plugin config, you don't want .properties files as the build number files will change after every build.
<TeamCityData>/config/projects/**/*.xml
If you are using Git you could easily just init a repo in the projects directory, add a .gitignore for anything other than *.xml, and run git add . and git commit -m "Build configuration settings were edited" as a scheduled job.
Is there a way to tell TFS that one or more files has been moved/renamed by another application (in our case, WebMethods 9) running in Eclipse? We have to move/rename the files using WebMethods and not TFS, because WebMethods does a whole lot of automatic reference updating. However, we haven't found a way to tell TFS "hey, trust me - I moved/renamed/deleted it outside of TFS". Instead, it refuses to commit any changes back to the repository until the old file reappears.
We're working around this at the moment by creating dummy files with the old name and then deleting them again via TFS, but you have to agree that kinda sucks. I'd be happy to treat a move/rename as a deletion of the old filename and creation of the new filename; I just don't want to have to fight TFS over it.
Eclipse: 3.6.1.M20100909-0800
TFS plugin: 11.0.0.201306181529
It depends on whether you use server workspaces or local workspaces.
In a server workspace, TFS requires that you inform the server for every change - to check out a file, rename, delete, etc. This allows TFS to avoid scanning your disk for changes, which is beneficial for large repositories. If you want to force a disk scan with Team Explorer Everywhere, because you may have made some changes outside of Eclipse, you can go to the Actions menu and select Detect Local Changes.
In a local workspace, TFS will examine your disk for changes every time you look at the pending change status. So all you have to do is run tf status or click refresh in the Pending Changes View to see changes made to files outside of Eclipse.
If your workflow involves files changed outside your IDE frequently, I would strongly recommend using local workspaces, however this requires TEE 11.0 and TFS 2012 or better.
I have a question about using Mercurial with MPLAB (which is basically just a wrapper around Eclipse).
I am wondering if it is possible to add a post-build step to commit a project to the repo.
Right now, we're just doing it the brute force way; we've taken the "commit often" part to the extreme. My co-worker has setup a Windows Event to execute every 15 mins that runs a script he wrote to commit everything in our working directory to the repo. This is great for making sure you don't miss anything (when his computer is on), but has the downside of committing broken code a lot of the time.
I can't help but think that there has to be a more streamlined way to handle our commits. I've read multiple tutorials/wikis about Hg but nothing goes this specific; everything stays much more "general overview".
If you are building via make then just add your commit script as the last stage, (after elf generation), in your makefile. For managed builds see here - assuming it is available in that version and again run your existing script. Either will result in a commit on a successful build.
The company I work for gave me the project of moving their java project from CVS to Git.
For several reasons, they don't want to use another tool than Eclipse. So we're stuck with EGit.
I know it is possible to configure Eclipse to format code. But it seems like there is nothing that would prevent someone to use his own way of formatting the code.
So my question is, is it possible to refuse a commit with EGit if the code is not formatted correctly ? The reason behind this question is that we want to avoid conflicts due to the code format, which was a really big problem in CVS.
Thank you
I recommend setting the formatter and a save action to format code as a project-specific configuration. Then tracking the .settings directory in Git.
Because it's configured in the project and in version control, developers won't have to configure Eclipse themselves, it's automatic.
We have done this with several projects and if you do it from the start, you will never have any ill-formatted code or discussions about it.
If a developer is really reluctant and even goes as far as unchecking the project-specific formatter and using another one, maybe you should have a talk.
(By the way, a recommended option in the formatter is Never join already wrapped lines, because sometimes the formatter will do weird wrapping. This option makes it possible to have control over wrapping.)
An alternative to checking the code during the commit is a scenario where gerrit is used as review system. The developers would commit their code to gerrit instead of directly to the git repository. Gerrit can then trigger a build job on a Jenkins/Hudson server and that build job can run CheckStyle or any other format checking tool you prefer.
On successful check Jenkins could then also verify the change and merge it into the git repository (most projects prefer Jenkins to only verify the correctness of the code, and a human still needs to review the code afterwards). Commits failing the check would remain in gerrit (and a mail would go to the developer).
The advantage of this approach is that you can do much more than only style checks for each commit, especially run unit tests, static code analysis and code coverage. The major drawback is that you have to set up some more tools than just a git hook.
If you know a way to determine if the code is formatted correctly you can implement this in the hook pre-commit
This hook should be placed in .git/hooks
git comes with a sample, called pre-commit.sample, it either in the hooks directory already or you can find it in the /usr/share/git-core/templates/hooks/ (On Ubuntu).
Greetings! :-)
I would like to describe a workflow strategy with some gaps in it, and I would be glad if you could fill in the gaps and otherwise give comments. If admins think that this does not validate as a question, then please delete away.
I am working on a webproject having files with PHP, Javascript (jQuery), HTML, CSS and postgresql code for in-database functions, table creation and configuration. All files are changed frequently. I use Apache.
This is what I want:
Introduce revision control.
Use build files for managing compilation and revision control.
Start using a proper IDE.
Be able to hack on my stationary and laptop with little time wasted on keeping code and IDE project configurations synchronized.
Have a setup for the project so some friends (approx 4-5) may join the project in the future.
This is what I am planning to start to use:
Bazaar for revision control and "project distribution".
Ant for build files.
Eclipse setup with proper plugins for managing Bazaar and Ant.
With Bazaar I intend to put code files, build files and even Eclipse project configuration files (configuration files of the project that I create in Eclipse to work with the webproject) under revision control. That way I can pull all that stuff from my stationary to my laptop via Bazaar.
Since I also put Eclipse's project conf files under revision control, I expect that I can without hazzle immediately open the Eclipse project directly on my laptop. So even if I make modifications to the project settings in Eclipse this should also be synchronized over laptop and host.
But I do have a few questions. Do you know how I should use bazaar so that I am notified or stopped when I try to modify the code on my stationary but have forgotten to push/check-in modifications from my laptop?
Also how should I setup Bazaar so that others can easily join the project in the future? I dont like using a service like launchpad, and would like my stationary to be the server. Is it not a bit risky to do it through ssh because I would have to create a new user account on my stationary each time a new user wants to join in?
Thoughts? Comments? It would be appreciated.
On the first question, you should consider using "checkouts", also called bound branches. That makes bzr behave more like svn in that every commit automatically goes to the "server" and you can't forget to push. Of course, bzr can't really detect if you forget to commit something.
On the second question, you can set up a bzr server that runs over HTTP/DAV and uses the web server's authentication methods. However, if you don't really like other people using your machine as a server, you might want to consider using a totally distributed approach, where your codevelopers publish their own branches and you pull in the things you want.
The Bazaar documentation is quite good and has the details on these topics.