- 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.
Tuesday, September 18, 2012
Here's a garden variety of Eclipse quirks and gotschas:
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 184.108.40.206-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: 220.127.116.11)
- 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 18.104.22.168-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.
Wednesday, September 7, 2011
- How maven finds the parent pom.xml:
- by groupId/artifactId/version in the repo (local and then internal etc)
- by parentsRelativePath if the tag is present
- if both found, in some order, unknown to me.
- To do a release: use release plugin which, among others:
- verifies that not SNAPSHOT dependencies are used
- cuts of the "-SNAPSHOT" and builds the project
- tags the corresponding version
- bumps up the version number and commits the version with "-SNAPSHOT" on the Head of the SVN/CVS
- Dependency scope:
- compile - makes the dependency available to dependent projects, will be placed to all classpaths (compile, testing, runtime), it's default scope
- What are possible values for dependency versions:
- 1.0.7 - is satisfied by 1.0.7 only and once installed in local repository, it never checks again if a newer or different version 1.0.7 is available
- 1.0.7-SNAPSHOT - is satisfied by 1.0.7-SNAPSHOT only, but every so often it checks if a newer (or different) 1.0.7-SNAPSHOT is available
- RELEASE - is satisfied by the highest release version available
- none (tag skipped) - inherits the version from dependency defined in parent's pluginManagement
Sunday, September 26, 2010
Thursday, May 20, 2010
Wednesday, May 19, 2010
This post is a brief summary how we use Cairngorm 2 methodology for popups in Flex applications in the IT shop I work at:
- Three files are created for each popup:
- popup view
- Cairngorm event to initiate showing of the popup
- Cairngorm command to actually show the popup using PopupManager
- Any data that needs to be passed to the popup is attached to the event.
- When user closes the popup, the popup view simply removes itself from PopupManager.
- The results of the popup, if any, are updated (can be done via data binding) in the ModelLocator, to which other controlls are bound as well, if needed.