I suppose this is kinda obvious, but I still judge it as a shortcoming...
I have 23 Mavenized projects. I'm now adding the <scm> bit because I've started using the release plugin. Here was my thought process:
I'll add the <scm> section only in my company base POM, and parameterise the URLs with properties, e.g.
<scm>
<connection>${scmBaseConnection}/${scm.module}/${scm.edition}</connection>
<developerConnection>${scmBaseConnection}/${scm.module}/${scm.edition}</developerConnection>
<url>${fisheyeBaseUrl}/${scm.module}</url>
</scm>
Then each project root (aggregator) POM need only declare its scm. <properties> accordingly (and not have to re-declare the whole <scm> section), e.g.:
<scm.module>sharktopus</scm.module>
<scm.edition>trunk</scm.edition>
But I soon realised that I can't do that: the release plugin rewrites each POM with the tag and next versions of the SCM info, so each such POM needs its own <scm> section.
Fine, so I decided I'll store the common SCM details in base POM properties, and have each project root POM declare its <scm> section using those props, plus its own specifics e.g.:
<scm>
<connection>${scmBaseConnection}/sharktopus/trunk</connection>
<developerConnection>${scmBaseConnection}/sharktopus/trunk</developerConnection>
<url>${fisheyeBaseUrl}/sharktopus</url>
</scm>
But that doesn't work either, because the release plugin rewrites using the resolved values (which is kinda obvious, in hindsight). So, e.g. for the release tag POM, the info above would be rewritten as:
<scm>
<connection>scm:svn:https://mysvnhost.net/sharktopus/tags/R1_NewStuff</connection>
<developerConnection>scm:svn:https://mysvnhost.net/sharktopus/tags/R1_NewStuff</developerConnection>
<url>https://mysvnhost.net/sharktopus</url>
</scm>
This means that each POM must have its own <scm> section with hardcoded URLs.
Is this what everyone does?
What happens if your SCM URL(s) change - do you just search/replace across all your projects?
Could it be a feature request to the release plugin to rewrite partial URLs, e.g. to keep the property references, but overwrite the 'final' specifics?
The only place to define scm part is in the project root not company root. In a multimodule build it's needed to have only a single scm part. The reason that the release plugin will replace the properties is very simple. After a release these pom's must represent that state for that software. If they would have properties in it would be imposible to gurantee the corret values etc. So the result would not reproducible...
If the SCM URL changes it will be valid only for new projects and not for the old ones, cause they are already been deployed etc.
For now it seems that there's no solution: http://jira.codehaus.org/browse/MRELEASE-128
Related
I use a project layout like the first one described in the accepted answer to this question. If my parent-pom is managed, built and deployed separate from my project POMs, how can I ensure the pluginManagement section of my parent-pom is valid?
Maven only checks plugins that actually get used in the build as far as I can tell. Since most of the plugins I'm declaring in pluginManagement don't get used when I build the parent-pom, I have no way of knowing if I have an invalid entry until a child project tries to use a plugin it expects to be managed by the parent-pom.
I've tried the versions plugin, but it seems to ignore plugins that don't exist (ex: typos). I've tried declaring the plugins in my parent-pom with inherited=false, but then I have to tie every declared plugin to a phase. Plus, I don't necessarily want to run those plugins against my parent-pom.
I know lots of people use a parent-pom or a super-pom of some type, so there has to be something I'm overlooking.
In your parent pom module create a set of test maven projects, all inheriting parent pom, using some or all of the plugins defined there, and have parent pom run and verify build success of test maven projects. maven-invoker-plugin can help you in accomplishing all this. This plugin is used a lot for testing maven core plugins so you can find more usage examples in sources of maven core plugins.
Another advice is to add plugins to parent pom pluginManagement only when you need them, then you will have opportunity to test it as well. So steps are, start building a project which uses a given plugin not yet present in parent pom, add plugin to parent pom, release parent pom snapshot, make use of that snapshot in new project, if all OK release parent pom, and adjust reference to parent pom in new project. Later for another or same project if you need additional plugin or newer version of plugin already specified in parent pom, adjust parent pom, release new parent pom snapshot, check if it works for the given project, and if it does release parent pom, and adjust parent reference to newly released parent pom.
When using the release plug-in for Maven on Hudson(1.368), I am getting an error that my distributionManagement section is missing during the deployment phase to our Nexus Maven Repository Manager. If I deploy without using release It woks just fine so should not be a misconfiguration with the server, the section or the settings.
It is worth noting that my company uses different pom files for Hudson and have named them differently. Also the settings.xml in in the individual project directories. This has never been a problem as Hudson allows for the name of the pom and the location and name of the settings file to be specified.
The reason I note the above is that when distributionManagement is moved into the regular pom.xml it does find it (but still doesn't work because its missing the username and password in the settings file). This confuses the heck out of me since for the prior parts of the release process, it uses the correct pom and settings. It just seems to forget them later on. What is going on here?
Thank you in advance.
UPDATE
It seems that the maven release plug-in spins up a new instance of maven which, it seems, is using the default pom.xml rather than our differently named pom. More testing is needed.
The answer (for any lost souls who stumble upon this question) is that maven was indeed forking out a new process which was not using the correct pom file and settings. The solution was to add a section to the pom file as thus:
<plugin>
<artifactId>maven-release-plugin</artifactId>
<version>2.0</version>
<configuration>
<goals>-f POMFILE -s SETTINGSFILE deploy</goals>
</configuration>
</plugin>
This specified those two files to the new maven process.
If I deploy without using release It woks just fine so should not be a misconfiguration with the server, the section or the settings.
Well, there is clearly a misconfiguration somewhere, be it at the Hudson level. But it will be hard to spot it without seeing the pom, the settings, the active profiles, the profiles used during the release, the Hudson setup, etc.
First step: try to reproduce the problem on the command line using the exact same configuration as Hudson.
Second step: use the Maven Help Plugin to understand and debug the issue. More specifically, the following goals:
help:active-profiles
help:effective-pom
help:effective-settings
The reason I note the above is that when distributionManagement is moved into the regular pom.xml it does find it (but still doesn't work because its missing the username and password in the settings file).
It's unclear where the distributionManagement is specified if outside the project's pom.xml (in a corporate environment, it goes typically in a corporate pom.xml, is it the case here?).
It's also unclear if you are actually providing the username and password for a server id matching the repository id of the distributionManagement.
But somehow, a wrong combination is used here. Double check what profiles/settings are active during release/deploy to spot the problem as suggested.
See also
The Maven Deploy Plugin Usage page
I changed the version from jFreeChart in the pom.xml of my maven project from 1.0.12 to 1.0.13.
Now I get the error
"The type org.jfree.ui.layer cannot be resolved to a type. It is indirectly referenced from required class files."
What does this mean? I just updated the jfreechart dependency.
The type is in the JCommons library. I think the problem is that the JFreeChart has not been properly distributed to maven in version 1.0.13. In the IBiblio directory listing, you can see that a .pom file is missing (as opposed to version 1.0.12, where it's present).
This means that maven has no ideas what the dependencies are. It still downloads the artifact through it's filename by convention, but it doesn't know anything about the context.
Now you can either complain to the vendor and demand a proper pom or create your own pom file (start with the old version and adjust it until things start working) and deploy it to your company's repository (or your local repository) using install:install-file or deploy:deploy-file.
My guess is that you'll at least have to include the following dependency
<dependency>
<groupId>jfree</groupId>
<artifactId>jcommon</artifactId>
<version>1.0.15</version>
</dependency>
(If you want to do it the easy way, just add the above dependency to your own project pom)
I have to deal with what is pretty ugly and large blob of ColdFusion code which up to this day is maintained by direct modifications on production server (don't ask). I managed to clean it up from dupes and backups and put it into Subversion, now I need tp pick a make system to be able to put this onto continuous build (TeamCity) and also scheduled releases.
To my surprise I only found pretty much a single blog article on how to retrofit CF project with Maven, so the question is - does anyone have experience successfully using Maven on CF and what in general people use to manage large CF projects?
Your suggestions, tips and links will be much appreciated
Since I don't want to start religions wars - Maven is pretty much company standard (vs Ant)
First, here's another blog you might find helpful.
build-tools-maven-and-coldfusion
I haven't tried to build ColdFusion with Maven, but I have experience with managing Maven builds for a large company. There are a few things for you to consider.
Project structure
Coldfusion cfm and cfc files should be put in src/main/resources so they are bundled in the jar (the blog referenced above overrides the Maven convention to put them in src. this is ok, but could be a problem if you later need to add anything else to the project).
I'd probably keep cfc and cfm files in separate projects with appropriate dependency declarations to link them, this keeps your cfc projects as libraries and helps reuse. It is also worth considering the granularity of the cfc projects. Generally Maven's dependency management helps you keep artifacts small, with little need to worry about finding all the jars.
Deployment
The simplest way to deliver the artifacts is to use the maven-war-plugin to create a war containing your artifacts and all their transitive dependencies. This makes each application self-contained, which can be useful. The downside of this is that you'll end up bundling the same artifacts repeatedly and they can be quite large. To mitigate this you can either use the assembly-plugin to create custom packages excluding the common components, or you can specify that certain components (e.g. ColdSpring) are scope provided, this means they won't be included in the war.
Version Management
Maven encourages a proliferation of dependencies, by default each dependency declaration has a version, this can cause maintenance issues, particularly when you want to bump the version of an external dependency. You can mitigate this by defining a parent POM or an "app" POM. Either would have a dependencyManagement section declaring the details (groupId, artifactId, and version) for common artifacts. Any POM inheriting from the parent need not declare the dependency version as it will be inherited (note this doesn't mean that all children will have all dependencies, only that any that declare a dependency don't need to declare the version). If you define an "app" project with packaging "pom" and a dependencyManagement section, you can reference it with scope import (from Maven 2.0.9 onwards), this will import the dependencyManagement section from the "app" project to the project POM. See the dependency documentation for more details.
If you declare a dependency with a scope in the dependencyManagement section, that scope will be inherited unless it is overridden in the child POM. Related to the deployment section above, this means that you can declare the common libraries scope provided in the parent to ensure they are not bundled in each applciation.
Naming Conventions
You'll need a naming convention for the packages to avoid collisions.
It's probably best to follow the Maven convention and use java package-like groupIds (org.apache.maven for maven.apache.org) and the jar name for the artifact. This convention would give the groupId "org.coldspringframework" and artifactId "coldspring" for ColdSpring.
Further distinctions might need to be made across the company. For example, if you have a web and core team, you could give the web team the groupIds com.mycompany.web.* and the core team com.mycompany.core.*
Dependency Management
You'll need to add your CFC packages to a Maven repository such as Nexus so they are accessible to other builds across the enterprise.
If you want to keep the CFC packages separate to the jars. You can specify a custom packaging type, so that they won't be mixed up with any Java artifacts. If you create a custom packaging type, the artifacts can have the ".jar" extension, but any dependency declaration must have the type set.
Here's an example following those conventions:
<dependency>
<groupId>org.coldspringframework</groupId>
<artifactId>coldspring</artifactId>
<version>1.2</version>
<!--custom packaging type helps keep separate from Java artifacts-->
<type>cfc</type>
</dependency>
There's a section in the Nexus book that describes custom lifecycles (follow the links for more details. Essentially you need to create a plugin with a META-INf/plexus/components.xml to describe the plexus mechanics (what archiver to use, what extension to output etc).
The components.xml would look something like this:
<component-set>
<components>
<component>
<role>org.apache.maven.lifecycle.mapping.LifecycleMapping</role>
<role-hint>cfc</role-hint>
<implementation>org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping</implementation>
<configuration>
<phases>
<process-resources>org.apache.maven.plugins:maven-resources-plugin:resources</process-resources>
<package>com.hsbc.maven.plugins:maven-jar-plugin:jar</package>
<install>org.apache.maven.plugins:maven-install-plugin:install</install>
<deploy>org.apache.maven.plugins:maven-deploy-plugin:deploy</deploy>
</phases>
</configuration>
</component>
<component>
<role>org.apache.maven.artifact.handler.ArtifactHandler</role>
<role-hint>cfc</role-hint>
<implementation>org.apache.maven.artifact.handler.DefaultArtifactHandler</implementation>
<configuration>
<extension>jar</extension>
<type>cfc</type>
<packaging>cfc</packaging>
</configuration>
</component>
<component>
<role>org.codehaus.plexus.archiver.Archiver</role>
<role-hint>cfc</role-hint>
<implementation>org.codehaus.plexus.archiver.zip.ZipArchiver</implementation>
<instantiation-strategy>per-lookup</instantiation-strategy>
</component>
<component>
<role>org.codehaus.plexus.archiver.UnArchiver</role>
<role-hint>cfc</role-hint>
<implementation>org.codehaus.plexus.archiver.zip.ZipUnArchiver</implementation>
<instantiation-strategy>per-lookup</instantiation-strategy>
</component>
</components>
</component-set>
Maven looked interesting to me too, but I couldn't find enough resources, and didn't have enough time to figure it out, so I moved onto what seemed to be good as well.
I understand you prefer to use Maven, I have come across several articles regarding Ant and Coldfusion, as well as a recent one about Hudson with Coldfusion.
Coldfusion also has the cfant (undocumented) tag. You can run ANT scripts right from CF?
If I have a parent pom and want to inherit this to several projects. I usually do this by adding in top of the project <parent> ... </parent>. What I don't like about this approach is that if something changes in my parent I have to edit all project which are inherited by that parent to modify the version number. Is there a better approach? I hope it is understandable what I'm trying to explain.
Thanks in advance.
What i don't like about this approach
is that if something changes in my
parent i have to edit all project
which are inherited by that parent to
modify the version number. Is there a
better approach?
Yes there is! Have a look at the Maven Versions Plugin, specifically:
versions:update-child-modules updates the parent section of the
child modules of a project so the
version matches the version of the
current project.
For example, if you
have an aggregator pom that is also
the parent for the projects that it
aggregates and the children and parent
versions get out of sync, this mojo
can help fix the versions of the child
modules.
(Note you may need to invoke
Maven with the -N option in order to
run this goal if your project is
broken so badly that it cannot build
because of the version mis-match).
Edit: Of course, using Maven3 you can now have < version >-less < parent > elements in sub modules:
Developers working in multi-module or multi-pom projects won't have to specify the parent version in every sub-module in Maven 3. Instead, you can add version-less parent elements.
Ref
You can use the Maven Release Plugin when doing a release. It will update all the version numbers automatically and create a tag in your source control (if you have SCM configured in the POM).
My commands for performing a release are typically as follows, after which I export the tag from SCM and build it with "mvn clean package" or "mvn clean deploy".
svn update (or whatever SCM you use)
mvn clean
mvn release:prepare -DautoVersionSubmodules=true
mvn release:clean
So for example if you version is first "1.0-SNAPSHOT", then the release plugin will create a tag "projectname-1.0" with version "1.0", and finally increase the current version to "1.1-SNAPSHOT". The plugin will ask you for the versions and tag name, so you can override the defaults.
Automatic Parent versioning (i.e. omission of the tag) is a contentious issue in the Maven space. There is a defect logged against it. For now, it is being considered as a fix or improvement in the 2.1 version branch,
You should keep your versions as snapshots until it's time to release. This way you won't have to change it every time you change the pom. However once you've released a parent pom, you will want to make the change to all the children (assuming the parent is outside the "reactor" build...otherwise it would have been all bumped together by the release plugin). There is a relatively new plugin called the versions-maven-plugin that can assist with changing the versions.
I think the important thing to realize is that in a multi-module build, maven always uses the the version that is from your local repository. This applies in multi-module builds too! So when you reference the "parent" pom you're getting the published parent artifact from your local maven repository. So when you do mvn install you repeatedly publish each module to your local repo.
While developing, your own modules are probably versioned to something like X.X-SNAPSHOT. The reference to the parent-pom is X.X-SNAPSHOT. Don't change these before you're ready to release.
So a simple case would be:
Before initial release all modules are called 1.0-SNAPSHOT.
When makin the initial release "golden build", rename all 1.0-SNAPSHOT modules to 1.0.
When starting development on the 1.1 release, you change all version numbers to 1.1-SNAPSHOT.
And so on...
The custom is to work with snapshot versions until you're releasing, at which point you update the version numbers everywhere. In the day-to-day development you do not change the version numbers because snapshot-releases get treated differently than hard-version releases.
Edit:
After some thought I think some of your confusion in the "comments" section arises from this: The version number in your pom reflects the overall application version. Any given pom change does not necessarily change the application version number. If you need to track changes in the pom I would suggest you use a source control system. So in the 3 month period you work on version 1.0, it's reasonable to keep the version number at 1.0-SNAPSHOT. In the (for instance) 3 week period you work on 1.1, the version number is 1.1-SNAPSHOT.