- find folderABC -mtime -9 -- show files in and below folder ABC modified less than 9 days ago
- /bin/ps -context -www -p processID -- shows wide command line for the process
- svn status | grep '^M' -- shows files modified in the current SVN copy
- svn diff -r HEAD fileABC -- compares the file ABC to its most recent version in the repo
- tar -ztvf file.tar.gz -- list contents of gzipped tar archive file.tar.gz
- tar -czf file.tar.gz file1 file2 file3 -- create a gzipped archive file.tar.gz with three files in it
tar -xzf tar-file-name.tar.gz
Monday, January 5, 2015
Friday, November 14, 2014
- In general, even when using Hibernate or other ORM, don't have to overwrite the Object's hashCode() and equals().
- However, you need to do it if both conditions below are true in your case:
- you use dettach() with later reAttach(), and
- you use your identity in Sets
- Hibernate uses equals() (and/or hashCode() ?) only to tell that two objects represent the same entity and not whether it's values have changed (it iterates over the attributes for this purpose).
- If you use entities in a Set, never change any component of the hashCode() while the object is in the Set. The best way is to make the business key immutable.
- For overwriting hashCode()/equals(), you can use EqualsBuilder and HashCodeBuilder from the Apache Commons Lang library. Or semit-auto generate them both, always both of them, using eclipse.
Saturday, November 1, 2014
- open CMD.exe
- use command:
findstr /s /i mock *.java *.groovy
- what it does:
- in the current directory and below (/s)
- searches for the string "mock", ignoring the case (/i)
- in all .java and .groovy files
- to find a string "pink rose", do:
findstr /s /i /c:"pink rose" *.java *.groovy
Without the "/c:", you will get all occurances of pink and rose.
- more info
Monday, September 29, 2014
When you join a table with JoinType.LEFT and join another to that one, you may need to use JoinType.LEFT again, even when there should be a record in the third table for each record in the second table.
Tuesday, September 18, 2012
Here's a garden variety of Eclipse quirks and gotschas:
- A maven project got stuck with an old set of dependencies and Maven plugin Update Project Configuration doesn't help, even if repeated 7 times.
Answer: When you do the Update Project Dependencies, check the Force Update of Snapshots/Releases.
Background: May be, for maven gurus, it should have been obvious what I was missing, but that just means I'm not one of them. It's true, that only SNAPSHOT and RELEASE dependencies were stuck, and yet it took me almost two hours of tearing my hair off.
Friday, December 16, 2011
- pom.xml - defines all modules that are part of the project
- module 1
- pom.xml - points to the parent pom.xml
- module 2
- pom.xml - points to the parent pom.xml
- module ...
- Nicely groups the modules under one folder.
- Allows to build the whole project by calling "mvn clean install" from parent's folder.
- Keeps the SVN (and/or Git) operations simple, unlike the layout where the project-name-parent is the parent folder.
Thursday, November 17, 2011
- A new project starts usually as version 22.214.171.124-SNAPSHOT. Three number versions (1.0.0) are also used but, for example, ServiceMix OSGi server requires three dots.
- A new feature/fix is frequently developed on the trunk and committed there when ready for release.
- Release. It is usually done on the trunk (does it have to be? what if someone commits changes in the middle of a release?). It is all done by maven release plugin, (more datails here). Is done in two steps: mvn release:prepare i mvn release:perform. What maven does during a release:
- up the version by 1 (often on the last numbered position: 126.96.36.199)
- build, maven-release and deploy to organization's repository if any
- tag it in SCM
- up the version number on the trunk (it will become 188.8.131.52-SNAPSHOT)
- On the trunk, we have always -SNAPSHOT versions
- Each release has a tag
- If the maven release plugin fails, it usually leaves the pom.xml messed up on the trunk. Make sure to fix the version and scm tags.
- Alternatively, a new feature/bug fix can be developed on a branch. In this case, the branch needs to be merged to the trunk, when feature/bug fix is ready. I guess, this merge should happen before the release.
- In multi-module projects, if you want to give the same new version to all modules, add set the option autoVersionSubmodules to true (in parent pom? where?). Otherwise, you'll be asked for the new version for each module.